|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,|
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
- Enter a name for the file and save it in HTML format. (XML is also an
- 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.
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.
GROUP POLICY BASICS FOR WINDOWS VISTA
Tip 1: A basic primer on Microsoft Group Policy
Tip 2: How to configure GPOs
Tip 3: What's new with Vista Group Policy?
Tip 4: How to manage GPOs
Tip 5: Troubleshooting GPOs for Vista
Tip 6: Group Policy best practices
ADVANCED GROUP POLICY FOR WINDOWS VISTA
Tip 1: Which GPOs are available
Tip 2: Further understanding GPOs in Vista
Tip 3: Examples of useful GPOs in Vista
Tip 4: Moving policies between domains
Tip 5: Recommended practices with Vista Group Policy
This was first published in January 2008