This chapter excerpt from Microsoft Windows Vista Management and Administration, by Andrew Abbate, James Walker, Scott Chimner and Rand Morimoto, is printed with permission from Pearson Education, Copyright 2007.
If you plan to use GPOs in your environment, you should develop several
habits that are useful for reducing the possibilities of negatively impacting
the user community when testing and deploying GPOs.
GPO Pilot OU
When linking a GPO in production, it is very helpful to initially limit the
scope of who will be affected by it. Although GPOs should always be tested
extensively in an isolated lab environment, in many cases a GPO can't be
fully tested without access to all the production objects in Active Directory.
For example, a GPO might include scripts that map network drives. It might
create database connectors or even redirect the user's Documents directory to
a file share. Unless all the systems involved were available in the lab, the
GPO could not be fully tested. In this case, you will want to apply the GPO
to a beta testing group in production first before linking it to a larger group.
The best way to handle this is to create an OU in the production Active
Directory where new GPOs will be initially linked and tested. Create dedicated
test accounts in addition to test workstations running the operating systems
that you support in production. Utilizing Microsoft Virtual PC is an excellent
way to deploy multiple operating systems into this testing OU without tying up
a lot of resources. After you're comfortable with the results in production, you
should then link the GPOs to the OUs they were intended to serve.
Isolating Critical Accounts
Another good habit for administrators is placing critical accounts into an OU
that is filtered from receiving Group Policies. This would include accounts
such as service accounts and administrative-level accounts. The goal here is
to ensure that GPOs can't negatively affect the accounts that would be used
to undo the negative effects.
Respecting OU Administrators
Linking a GPO can have far-reaching consequences for users. This is especially
true when a GPO is linked near the top of an OU hierarchy or even at
the domain level. In these situations, GPOs may affect users in OUs that are
controlled by other groups or other administrators.
One of the most common OU structures in Active Directory is loosely based
on geography. In these cases, different locations are separated out into OUs,
and local administrative staff is delegated control. In these environments, it's critical to properly communicate the implications of GPOs to those other
administrators and make sure they are okay with the new GPO.
The simplest way to pass the information to others is in the form of an
HTML file. HTML, or Hypertext Markup Language, can be easily viewed
from a web browser and is natively supported by the GPMC.
You can export the settings from a GPO into an XML file with the following
steps:
Launch the GPMC (Start, Run, gpmc.msc).
Expand the Forest container.
Expand the Domains container.
Expand the Domain Object that holds the GPO you are interested in.
Expand Group Policy Objects.
Right-click the GPO you want to export a summary for and choose
Save Report.
Enter a name for the file and save it in HTML format. (XML is also an
option.)
Browse to the location where you want to save the file and click Save.
This HTML file can be placed on a commonly accessible web server to act as
a quick reference for administrators who want to see what GPOs are
currently in place in the environment. Newly proposed GPOs can be placed
there as well to give OU administrators a place to look at new settings and
give them an opportunity to either authorize or deny the changes before they
are placed into production.
Leveraging Other People's Work
As you use GPOs more and more, you will likely make the discovery that
your needs are really not that different from other companies', and odds are
that most everything you are planning to implement via GPO has been done
before by someone else. Rather than always reinventing the wheel, look
around to see if the GPO you are considering has already been created by
someone else.
A good example is the set of common scenario GPOs that have already been
created by Microsoft. Many companies find themselves in need of computers
that act as common workstations that might be used by people who aren't
necessarily employees. Or perhaps they need a computer on a manufacturing floor that can be used for only one or two specific applications. Rather than
researching all the settings necessary to create a kiosk-type machine, you can
start with the work that someone else has already done.
Microsoft has published several such GPOs. This page contains descriptions of several common desktop configuration
scenarios as well as the GPOs that enforce the settings. Although these
scenarios might not be a 100% match for what a particular administrator
needs, they nonetheless provide excellent starting points where settings can
be tweaked rather than created from scratch.
Summary
This chapter has built on the information presented in Chapter 22 to help
administrators further understand how to implement and manage Group
Policy Objects in order to make the management of Vista systems easier. It
has also offered advice on how to manage users and computers to ensure that
GPO manipulation can't accidentally cause problems in the enterprise.
Administrators should take the opportunity to get more familiar and confident
with GPOs in a lab environment and use the processes given in this chapter
to implement the GPOs into production with minimal impact to the domain.
TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.