Sure, we've all seen and heard of Windows 2000 technologies. Many of us have even implemented it, and actually made it work. But have we really unlocked the full potential of Microsoft's most powerful OS? There are many exciting technologies in place in Windows 2000, but without some tweaking, you're just scratching the surface.
Today we are going to dig deep into what I feel is the most compelling reason for a Windows 2000 upgrade, Group Policy. With a well planned Group Policy infrastructure in place, you can really flex your administrative muscle. A bad design on the other hand, will fill up your voicemail box with more complaints than your eardrums can handle.
What is Group Policy?
Group Policy is a much improved extension of
System Policy Editor in Windows NT 4. The
implementation of Group Policy allows you to administer your network
dynamically. Applying changes to
only the groups, users, or computers that you see fit. Here is a very brief listing of just some of the areas Group
- Password policies
- Internet configuration
- Network configuration
- Approved applications
- Desktop environment
- Control panel applets
- Logon and logoff scripts
- Printer options
- Start menu options
- Offline file synchronization
- Software deployment
Group Policy allows you to manage very granular aspects of your workstation, server, and domain environments. Not only can you cover almost every aspect of network planning and administration today, you can dynamically change it in the future as the need arises, with nary a single visit to a client machine.
If you've never perused the Group Policy
settings before, now is the time to do it.
Select Start | Run and type "mmc" (without the quotes).
Next, select Console | Add / Remove Snap-in. Click the Add button, scroll
down the list and select Group Policy, click Add, then click Finish (then Close
and then OK, whew!) This will create a blank Management Console with the Local
Computer Policy Object in it. This
is the Group Policy Object for the local workstation, and where we will begin
our introduction to Group Policy. Take
the time now to save the Group Policy snap in, which by default will save to the
Administrative Tools program menu.
Start by opening the plus signs in the left pane of the Group Policy (hereafter known as GP) Snap-in, digging down to show all of the available configuration options that GP gives us. Double click on one of the policies in the right pane and click on the "Explain" tab. (see page 2) Microsoft provides full documentation of each policy object here. Before you get started with the actual implementation of GP in your environment, it is highly recommended that you read through these explanations of each policy setting. You may be surprised as to what you may find, some policies don't mean what you think at first glance.
Group Policy Object - A GPO is a policy setting. The setting of a default desktop for instance, is configured in a GPO.
Group Policy Container - Active Directory objects where GPOs are linked. Only sites, domains, and OUs can have GPOs linked to them.
Active Directory considerations
With all of the technology built into Windows 2000 you shouldn't have to set all of these options at the workstation level right? Right. GP can be applied in many different areas. In fact, some settings in GP, like Domain User Account settings, won't work unless they're set in the correct place. There are 5 major areas where you will apply GP:
- The local computer
- The site
- The domain
- The domain controller(s)
- The OU
Obviously with so many places GP can be applied, this implementation could get out of hand very quickly. Don't be disheartened, with a little patience, and by following some simple rules, even very large networks can be handled with GP relatively easily.
Group Policy inheritance
So, what if I set my users desktop
background in the local computer GPO to be red, and set it in the Domain GPO to
be yellow? What color do I get,
Here we can begin to see the complexity and
possible downfalls of GP if not designed correctly.
The answer is yellow. Here's
In order to design a robust, scalable tool for this endeavor, Microsoft formulated a set of rules that define how GP behaves. By allowing us the ability to create multiple settings in multiple areas for our domain structure, there will inevitably be some overlap. In order to make sense out of chaos, we have inheritance as our number one rule in GP. Understanding GP inheritance is critical to a successful design and implementation. GP will be applied to the user or computer object in the same order as listed above:
- The local computer
- The site
- The domain
- The domain controller(s)
- The OU
In the case of nested OU's, GP is applied
in order from the highest level OU, or parent, down to the lowest level OU.
You can also have more than one GPO applied to the site, domain, and OU
portions of the above list at the same time.
In this case, the GPO's are applied in reverse order of their listing
in the GPC properties.
Notice also that a site can span multiple
domains. This is a potentially
damaging scenario if not properly planned for in a multi-domain environment. Care needs to be taken when creating GPO's linked to site GPC's if
they span multiple domains to prevent unplanned cross domain policy
In the case of multiple settings being applied with multiple GPO's, the rule of thumb is "closest one wins". Simply put, GP is applied in order as listed above to the workstation, or user. If a setting is defined in the Domain GPO, and then defined differently at the OU level, the setting specified at the OU level takes precedence.
As with almost everything in this world,
there are exceptions to the rules:
- Computers that are members of a workgroup will only process the local computer GPO.
- At any site, domain, or OU, you can select Block Policy Inheritance. This setting is applied to the entire site, domain, or OU, not the affected GPO's. Therefore Block Policy Inheritance rejects all GP settings that reach the site, domain, or OU from above, except those specified as No Override.
- Any GPO linked to a site, domain, or OU can be set to No Override with respect to that site, domain, or OU. If more than one GPO has been set to No Override, the GPO highest in the hierarchy takes precedence.
Block Policy Inheritance can be used to
abolish GP settings for a particular OU. For
example, you can block all policy inheritance for your IT Support OU, to prevent
system lock down settings that are present in your organization.
The No Override option is useful in a distributed management environment. With the granular permission possibilities in Windows 2000, a representative from Human Resources could be responsible for administration of the HR OU. Including account creation, password resets, and GP. The IT team may want to insert a password uniqueness policy to the entire organization. By using the No Override setting, the IT team can be assured that the password uniqueness policy will be applied to everyone, even those OU's where the Block Policy Inheritance option has been set.
Group Policy design approach
As with every level of network design, you
should have a solid understanding of your end goal in mind when designing your
GP structure. Are you looking to
decentralize your administrative support of network objects?
Taking advantage of the very detailed permissions structure in Windows
2000 can allow your organization to implement "Departmental Administrators". Persons who are not in IT Support, but instead members of each
department, responsible for account creation, password resets, even file
permission administration of their assigned areas.
Or are you looking to maintain a centralized
support model? One in which all
administrative responsibility is contained within the IT Support group.
This is the traditional method of administration in most organizations.
You effectively have two choices in GP
implementation, Layered and Monolithic GPO design.
The layered approach's goal is to establish the GP settings in as few
GPOs as possible, while allowing dynamic control of your GP policy, and is best
suited for environments where change to GP may be frequent. The monolithic approach tries to apply the desired GP
settings to a given user or computer with very few GPOs. All GP settings are contained in the GPOs set specifically on the
affected user, computer, or OU, to get the desired result.
Monolithic designs are advantageous to organizations where change to GP
will be minimal. (see
The layered approach requires a base GPO
applied to the domain. This applies
desired settings to as many users and computers as possible, without overlapping
policy settings. OU specific GPOs
are created next in order to apply settings tailored to individual departments,
users, or computers, resulting in the final GP structure applied to the end user
or computer at logon. Note that
this approach does result in longer logon times, due to the number of GPOs
The monolithic approach dictates that most settings be applied to a single (or very few) GPO or GPOs. This single GPO is then applied to the site, domain, or OU where required. The monolithic design model is best suited for organizations where GP will be common among most, if not all objects in the domain, and those settings will change very infrequently, if at all. With the smaller number of GPOs to process, logon time is reduced.
Filtering your GPO's scope
You can further refine your GP settings with
standard permissions. In order for
the GPO to be applied to a particular user or security group, that user or group
needs to have Read and Apply GP permissions to it. If the user can't read it, they can't understand it, and consequently
don't apply it. Do not
automatically go out and remove the default Authenticated Users groups- Read
and Apply GP permissions to your GPO's to prevent them from seeing the
settings. This will effectively
exclude them from inheriting your GP settings that you have worked so hard to
To really utilize the full benefits of Group Policy, consider setting a permissions structure on the GPO's to filter out unwanted policies. This is a much more granular way of applying GP to your community. The use of Block Policy Inheritance to filter out inheritance is an all or nothing scenario. For example, you simply want to block a specific portion of GP, such as the denial of using registry editing tools to one OU. It is much simpler to filter out one GPO dedicated to registry settings, than to deny all GP, then recreate everything but the registry settings to get the effective inheritance. See the following example for details.
Example GPO filter
In this example, we will filter specific
portions of Group Policy in our fictional organization Trake Inc. Trake's single domain model contains OU's that house each
specific operating group (Electrical Engineering, Sales, IT Support, and CAD).
In order to create a granular implementation of GP, we have implemented
several GPO's specific to groups of intended settings.
- Password policy - GPO that specifies a minimum of 8 characters for passwords, expiring every 90 days.
- Desktop policy - GPO that specifies no Run command in the Start Menu, a default desktop background, the addition of Logoff to the Start Menu, and the denial of use for the application Microsoft Outlook Express (Trake utilizes another email system).
- Registry policy - GPO that specifies the denial of use for all registry editing tools.
- File synchronization policy - GPO that specifies the options for file synchronization of Offline Files.
- Scripts policy1 - GPO that specifies the use of a logon script to automatically map certain drive letters to data shares for the end users.
- Scripts policy2 - GPO that specifies the use of a logon script to automatically map certain drive letters to distribution share points for the IT Support staff.
In our example, the Password, Desktop, and
Registry policies will be set at the Domain level, the Scripts and File
Synchronization policies will be set at the OU level.
By setting the Password, Desktop, and
Registry policies at the Domain level, we have ensured that all security groups
in the Domain will receive these settings.
The IT Support OU requires a different logon script that maps drives to
various software distribution areas on the network. Therefore, we have set the Scripts policy 2 on the IT Support OU only.
All other OU's receive the standard Scripts policy 1.
The Sales OU contains Sales staff that travel on a regular basis. The network admin for Trake has setup the salesman's
laptops to utilize Offline Files so the sales staff can view reports and sales
figures while on the road. We have
set the File Synchronization policy on the Sales OU as well, to define the
Offline File settings for the sales staff.
However, we have a problem with our GP
implementation. The IT Support
staff requires access to the registry editing tools due to the nature of their
job troubleshooting software and hardware at the end user location.
To prevent the inheritance of the Registry policy setting, we set the
Deny permission for the IT Support security group on the Registry policy GPO. Remember, the Deny permission setting automatically overrides any other
access permission setting, in this case the Authenticated Users permission of
Read and Apply GP. This prevents
the "Disable registry editing tools" setting from being applied to the IT
Support staff security group.
If we had used the Block Policy Inheritance option to prevent this inheritance, we would also have to create the Domain GPO links specifically to the IT Support OU in order to apply the Password and Desktop policies. As you can see, filtering the scope of GPO's allows us much more flexibility in our GP design, as well as fewer steps in implementation.
A successful implementation of Windows 2000
technologies in your organization can help you realize financial and
administrative savings immediately. Windows
2000 has been designed to minimize repetitive tasks, and allow greater
flexibility in network design than was present with NT 4.0.
However, no Windows 2000 rollout would be complete without taking
advantage of Group Policy. Administrative
control over your environment has never been simpler, or as far reaching.
With a well designed implementation of Group Policy, you can assure your organization an environment of stability, user friendliness, and the ability to change dynamically as the need requires.
More to come-
This article covered the design and implementation of Group Policy within a given organization. The purpose of this article was to give the reader a sense of the overall strategy of Group Policy design. As I mentioned earlier in the article, GP can also control software deployment. This is a very exciting proposition for those organizations where software deployment mechanisms such as Microsoft's Systems Management Server is not in place. I will cover this topic in a future article, as the software deployment technologies in Group Policy are certainly worthy of their own article.