• facebook
• twitter
• google+
• in
• Email

Sean Stecker

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.

Sure, weve 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 Microsofts most powerful OS? There are many exciting technologies in place in Windows 2000, but without some tweaking, youre 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 Policy covers: 

• 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.  

 

Definitions 

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: 

1. The local computer
2. The site
3. The domain
4. The domain controller(s)
5. 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, orange? 

Here we can begin to see the complexity and possible downfalls of GP if not designed correctly.  The answer is yellow.  Here's why: 

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:

(see page 3) 

1. The local computer
2. The site
3. The domain
4. The domain controller(s)
5. 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 implementation. 

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. 

 

Exceptions 

As with almost everything in this world, there are exceptions to the rules: 

1. Computers that are members of a workgroup will only process the local computer GPO.

2. 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.

3. 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 page 4) 

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 applied. 

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 create. 

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.  

1. Password policy - GPO that specifies a minimum of 8 characters for passwords, expiring every 90 days.
2. 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).
3. Registry policy - GPO that specifies the denial of use for all registry editing tools.
4. File synchronization policy - GPO that specifies the options for file synchronization of Offline Files.
5. Scripts policy1 - GPO that specifies the use of a logon script to automatically map certain drive letters to data shares for the end users.
6. 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.  (see page 5) 

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.

 

Summary 

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.