Chapter 7. Profiles and Group Policy Primer

Profiles and group policies are large topics, and they are worth treating properly so that you get the most from them in your environment. The goal of policy-based administration is for an administrator to define the environment for users and computers once, then rely on the system to enforce that state. Under Windows NT, this could be very challenging, but with Active Directory group policies, this capability is much more readily available. This chapter is the introduction to the subject, and Chapter 10 builds on it to show how policies work in Active Directory, how to design an OU structure to incorporate them effectively, and how to manage them with the Group Policy Management Console, a new MMC snap-in available for Windows Server 2003 Active Directory.

In Windows NT, system policies had a number of limitations. System policies:

• Were set at the domain level

• Were not secure

• Could only apply to users, groups of users, or computers

• Tended to set values until another policy specifically unset them

• Were limited to desktop lockdown

The scope and functionality of Active Directory group policies is much greater than system policies. Group policies:

• Can be applied to individual clients, sites, domains, and Organizational Units

• Are highly secure

• Can apply to users, computers, or groups of either

• Can set values and automatically unset them in specified situations

• Can do far more than just a desktop lockdown

With group policies, an administrator can define a large number of detailed settings to be enforced on users throughout the organization, and he can be confident that the system will take care of things. Let's take a simple example from Leicester University. Administrators wanted the Systems Administrator toolset, which normally is installed only on servers, to be available on workstations also. While they could install these tools on their own PCs, they actually wanted the tools to follow them around the network and be available from any PC that they chose to log on from. However, they didn't want to leave these tools installed on that PC when they logged off. Prior to Active Directory, the admins would have had to arrive at a client, log on, install the toolset, do whatever was required at a client, uninstall the toolset, and finally log off. This would be a considerable chore for a large number of machines. Active Directory group policies can be used to specify that the toolset is to be automatically installed on any client that an administrator logs on to. That way, an administrator could go straight to the Start menu and find the tools available. After logging off, the same group policy would uninstall the toolset from the machine.

Let's take another example. At Leicester University, a central logon script was used for every user. This is no different than under Windows NT. However, extra logon scripts for some sets of users were also applied based on which Organizational Unit the users were in. So some users get more than one logon script depending on where in Active Directory their accounts reside. That's a significant step forward from Windows NT, but the possibilities don't end there. A logoff script was also specified to run when a user logged off the system. Workstations also can have scripts, but instead of executing at logon and logoff, these scripts run at startup and shutdown. Want to install a new Dynamic Link Library (DLL) on all clients? You could use a startup script to do it. Have a desire to start a normally disabled service on a series of workstations? You could create a startup script that starts that service and apply it through group policy. Of course, as you've probably guessed, this startup script runs in addition to any other startup scripts, such as a central script for all workstations. So, rather than a single user logon script available for Windows NT, we now have multiple user logon/logoff scripts and multiple workstation startup/shutdown scripts, all of which can be customized using any of the data within Active Directory. And with Windows Server 2003 Active Directory, you can even use WMI filtering, which allows you to use any of the vast amount of data available in WMI to specify criteria for when group policies are applied.

Let's consider a final example. You are required to set the RunOnce registry key value for every client in your organization so that they can all receive an organization-wide company video broadcast from the chairman and CEO. You can set up a simple group policy with the customized registry changes configured and apply it to every computer in your organization. At present, this functionality may seem no different from what you could have achieved with Windows NT system policies. You apply these changes one evening, and the next morning, 20,000 workstations across your network can be rebooted so that they receive this policy on startup. The group policy applies and the settings are changed. However, if about an hour after you made the change you realize that one of the values in the registry needs to be changed again, you don't want to force 20,000 clients to reboot, as was necessary under Windows NT. And with Active Directory you don't have to. You can specify that this policy be reapplied every 15 minutes to all workstations after they have booted. You can make the change to the group policies and sit back, knowing that within 15-45 minutes,^[1] every workstation will receive the policy again with the updated change.

^[1] A random time interval of 0-30 minutes is added so that all workstations do not attempt to download the policy at the same time.

With examples like these, it becomes quite easy to see the power of group policies. While some of the examples can be accomplished under Windows NT, it would require a lot more time and effort to achieve than with Active Directory's group policy.

Now that we've covered a few examples, let's dive into the details of profiles and group policies.

Group policies are normally referred to simply as GPOs, corresponding to the term group policy objects.