Category: Group Policy

If you’re already familiar with using Group Policy Objects in Active Directory environments, then you no doubt already know that GPOs can only be applied to 3 types of objects – sites, domains, and organizational units. You cannot apply a GPO to a user account object, nor to a security group.

While the rules are the rules, there are ways to “filter” GPOs for a more granular level of control over whom (or what) they actually apply to. For example, the Security tab in the Properties of a GPO dictates the permissions that users and groups have to a GPO. Any objects to which the Read and Apply Group Policy permissions are allowed will have the policy settings applied to them.

So, let’s say that you have a GPO that you want to apply to all user accounts in a particular OU, except for 2 specific users. You would create the policy, apply it to the OU, and then set the permissions on the GPO such that these 2 users are denied the Apply Group Policy permission. The policy’s settings will then apply to all other users in the OU, but not impact your 2 special-case users. This permission filtering method can be used with both Windows 2000 and Windows Server 2003 forests.

While filtering by permissions certainly gives you more flexibility over how policies are applied, an even more powerful alternative exists. In Windows Server 2003, you can also filter the objects to which Group Policy settings apply by using what it known as a WMI Filter. If you open the properties of a GPO and click the WMI Filter tab, you can then select or define your filter settings.

Of course, you’re going to need to know a little about WMI to create your filters, but the documentation is out there. Here’s a great example of how WMI filters can be used, compliments of Alan Finn:

WMI filters are configured by defining both the namespace and a WMI query. The following examples are formatted with the appropriate namespace listed first, followed by the WMI query that defines the filter:

1. Applies only to machines with the KB890175 hotfix installed:

root\CIMV2; SELECT * FROM Win32_QuickFixEngineering WHERE HotFixID = ‘KB890175’

2. Might be used on machines to launch a removal package for iTunes:

root\CIMV2; SELECT * FROM Win32_StartupComman WHERE Name = ‘iTunesHelper’

3. Can be used to filter machines with more than 256MB of RAM installed:

root\CIMV2; SELECT * FROM Win32_LogicalMemoryConfiguration WHERE TotalPhysicalMemory > 256000

4. A filter for XP machines with SP 2 installed:

(“root\CIMV2; SELECT * FROM Win32_OperatingSystem WHERE Caption = ‘Microsoft Windows XP Professional’ AND TargetInstance.CSDVersion = ‘Service Pack 2′”)

So, the next time that someone tells you that “you can’t do that with Group Policy”, you might want to dig a little deeper for the truth. With even a basic knowledge of WMI, you can filter your policies on just about any settings imaginable.

Tip provided by Dan DiNicolo and Alan Finn

The purpose of this article is not to provide you with an overview of all the new features of Windows Server 2003. Instead, in this article I have decided to concentrate on one important new tool that specifically deals with ‘results’, in this case with respect to group policy settings. In a followup article I will cover a new feature that allows the cumulative permissions that apply to users, groups, and computers to be easily obtained.

The new tool covered in this article is known as Resultant Set of Policy, or RSoP. Resultant Set of Policy is an administrative tool provided as an MMC snap-in that allows an administrator to easily gauge the cumulative group policy settings that apply to a user or computer. If you’ll recall from Windows 2000, group policy settings in a domain environment are usually set at three different levels, namely sites, domains, and OUs. While this model provides a great deal of flexibility, it can also make understanding the actual settings that apply to a user or computer difficult to discern.

For example, the first major issue is the order of group policy processing – site GPOs, followed by domain GPOs, followed by OU GPOs. At any given level, multiple policies may apply, in different orders according to manner in which they are ordered for a particular container. Confusing things further is the fact that certain policies can be blocked or set to no override, which impacts whether the policy settings can be changed or overwritten at a lower level, or whether they should be processed at all. Going a step further, GPOs can also be filtered through the use of permissions, allowing group policy settings to either be applied to users or computers within a container or not, according to your specific needs or requirements. When all is said and done, determining the actual settings that will ultimately apply to a user or computer can be at best difficult, if not impossible, especially in large environments.

To help circumvent this issue, Microsoft provided a utility in the Windows 2000 resource kit know as gpresult.exe. Essentially, this command-line utility was used to discern the exact policy settings that would apply to a user or computer once group policy processing was complete. Unfortunately, the long text-based output of the tool made it difficult to grasp exact settings, and as another tool buried on the resource kit, many administrators weren’t even aware of its existence. Gpresult.exe is now included as a built-in utility with Windows Server 2003, but most administrators will probably still feel more comfortable with the Resultant Set of Policy tool.

As mentioned earlier, RSoP is simply an MMC snap-in. It can added or removed from the list of available snap-ins.

Once added to an MMC console, the RSoP interface is fairly basic. Remember that the tool’s purpose is to provide you with the list of settings that will apply to a user or computer after all group policy settings that apply have been processed. In order to see this information, you simply right-click on the Resultant Set of Policy node and click Generate RSoP Data, as shown below. Ultimately, this will walk you through the Resultant Set of Policy Wizard, allowing you to choose the user or computer for which you want to view RSoP data.

In a Windows NT 4.0 domain environment, assigning scripts to users was more of less restricted to simple logon scripts. Not particularly flexible, but generally enough to get the basic jobs done – mapping directories, printers, environment variables, and so forth. For all intents and purposes, however, you were still in a simple batch file environment. In order to get into any more advanced scripting, you needed to use an additional scripting language such as Kixstart. In a Windows 2000 domain, however, the power of Group Policy unleashes script deployment capabilities that make NT 4.0 pale in comparison.

For those who like their networks a little old school, you can still deploy logon scripts in the properties of a user account in a Windows 2000 domain. While this is still acceptable, it constitutes a waste of a wonderful opportunity. With Group Policy, not only can you deploy scripts to multiple users in a single step, you can also define scripts settings in a hierarchical fashion. Scripts can be assigned not only to all users in a domain, but also according to sites and OUs. In cases where multiple GPOs affect a user, multiple scripts can be applied. This capability represents a powerful feature that shouldn’t be overlooked by system administrators.

Logon scripts aren’t the only type that can be defined with Group Policy. GPOs can be used to apply Logon and Logoff scripts to Users, and Startup and Shutdown scripts to computers. As the names suggest:

• Logon scripts are applied once a user logs in
• Logoff scripts are applied once a user logs off
• Startup scripts are applied when a computer boots
• Shutdown scripts are applied when a computer shuts down

The ability to define scripts in these different ways provides an additional level of functionality not experiences in previous versions of Windows. Furthermore, you are no longer limited to simple batch scripts – more powerful VBScripts can be used to further extend the abilities of the administrator.

Since the basics of this topic were looked at in previous articles, my intention is to look at some of the more advanced options here. For the purpose of review, the basics of group policy are outlined below.

In an Active Directory environment, group policy allows us to distribute software to users and computers using a repackaged file format, .msi. When software is deployed using group policy, the user needs no special privileges, since the software is installed using the elevated privileges of policy. If a vendor does not provide an msi file for their software, you can use a repackaging program, such as WinInstall LE (found on the Windows 2000 CD) to create one. The two basic options when deploying software via group policy are to either Assign or Publish it. Software can be either published or assigned to users. If assigned, the software appears to ‘follow’ the user, regardless of where they log on. Shortcuts appear on the start menu, but the software isn’t actually installed until they click on the shortcut. When assigned to a computer, the software is installed on that computer the next time it reboots, and is available to all users of the system. When software is published (which can only be done to users, not computers), the software is available to install from Add/Remove programs, and can also be installed by document invocation (when a user click on a file type associated with that application). Publishing software makes it available to users, but doesn’t create the illusion that it is actually installed. An application can also be published using a .zap file, if an msi does not exist or if one cannot be created. Note that if a .zap file is used, the user will require a level of privilege suitable to install the application. Also note that software deployment options are only applicable for Windows 2000-based systems, and would not be applied if a user logged on to Windows 98, for example.

The Software Settings area of group policy is where the publishing or assigning options are set. When an application is deployed by group policy, the first option that must be chosen is whether the application will be published or assigned.

The advanced elements of software deployment can be set up when you originally choose to deploy the software (by choosing Advanced published or assigned as shown above), or later by accessing the properties of the deployed software. The advanced properties allow you to control a number of elements with respect to the deployment, including the addition of upgrades or patches, modifications, as well as uninstalling packages.

There are 6 property sheets associated with advanced application deployment, and you should be familiar with them. The general tab lists basic information about the package (such as the version number), while the security tab contains the ACL for the object. The deployment tab, shown below, controls whether the application is published or assigned (which can be changed). If published, you can control whether or not the application will be installed by document invocation (this option is grayed out when you choose to assign an application).

Note the option to uninstall the application when it falls out of the scope of management. If this is chosen, and the GPO that deployed the software no longer applies (for example if a user or computer object was moved), then the software would be automatically uninstalled. The installation user interface options allow you to control how much interaction the user will have during the installation process.

The upgrades tab (shown below) allows you to automate the deployment of patches and upgrades (such as newer versions) to applications that have already been deployed via group policy. If the upgrade is made mandatory (the required option is selected) then the upgrade will be applied, and the user will only be able to use the updated version. If it were not made mandatory, then the user would be able to use both the old and new versions of the software. This is potentially useful when a new application is not backwards compatible.

The categories tab allows you to create and control the way that applications are presented in Add/Remove programs. For example, you could create categories for each type of software, such as graphics applications, word processors, and so forth. This section would allow you to group the newly published application into one of those categories in order to make it easier for a user to install the correct application.

Finally, the modifications tab (shown below) allows you to further customize a package for users with special needs. For example if you wanted to deploy a language-specific dictionary for users in different offices, you could apply a modification to the package. Modifications are made in the form of .mst files (also known as transform files). For those who are interested, there is a utility provided with the Office 2000 resource kit to create .mst files.

As mentioned many times in previous articles, group policy settings are applied in the order Local, Site, Domain, OU. This order controls which settings end up actually applying to a user or computer. Remember that all settings merge together by default, and that in the event of conflicting settings, the one applied latest will apply.

You may have noticed what many do when first looking at group policy application – that an administrator with control of only a single OU could possibly override settings set by a domain administrator. This is absolutely true, since OU settings will ultimately override those set at the domain level in the event of a conflict. However, this behavior can be controlled via two settings, Block Inheritance and No Override.

The Block Policy Inheritance setting may seem even worse. If an OU administrator were to set this on her OU, then all policies coming from ‘above’ would be completely blocked by default. That is, she could refuse to inherit any policy settings from the site, domain, or parent OU. Note that this feature is also a powerful capability, in that if you didn’t want any domain policies to apply to your developers, for example, you could simply block inheritance of policy at particular OU.

For those who feel uncomfortable with Block Inheritance, worry not. Another setting that can be set on a GPO is No Override, and No Override always beats Block Inheritance. As such, if I created a policy at the site level set to No Override, and the administrator of the Developers OU set the OU to Block Inheritance, the settings contained in the domain policy would still be applied regardless. Note that other policies without No Override enabled would still be blocked in this scenario. The No Override setting is set using the Options button on a GPO.

One last thing that you need to know about GPOs is that they can be filtered. That is, you can control exactly who a GPO will apply to by setting the appropriate permissions in the GPO’s ACL. For example, let’s say that you had an OU called Sales, and you wanted a GPO to apply to all users in the OU except for a user called SalesAdmin. By default, the GPO is always applied to all Authenticated Users, who have the Apply Group Policy and Read permissions set to allow. For out SalesAdmin user, we could prevent the GPO settings from being applied by giving him the Deny Apply Group Policy permission.

You should use filtering of GPOs sparingly, as it can complicate GPO troubleshooting. However, you should also recognize that it provides a powerful way to control policy application to users and groups, since GPOs cannot be linked to these types of objects.

As described in previous articles, group policy in Active Directory allows us a great deal of flexibility in terms of how users and their Windows 2000 computing environment is controlled and managed. Things that can be done with group policy include software distribution, updating settings such as Internet Explorer’s proxy server settings, locking people out of Control Panel, and so forth. It is worth investigating the hundreds of settings that can be configured in group policy, but unnecessary to remember all (or even most) of them. However, be sure to at least familiarize yourself with the different possible settings and why they exist.

The main reason for the existence of group policy is to be able to control the user environment and make changes with the least amount of administrative effort. For example, I could remove the My Network Places icon from certain user desktops by setting up a group policy object applied to an OU. When users whose account exists within that OU would log on, the icon would not be available for them, regardless of what system they logged on to within the Active Directory forest (unless a conflicting policy had also been configured at another level, as we’ll discuss in a moment).

Although the idea behind group policy settings is pretty straightforward, it can be confusing to configure them correctly, since settings can be made at many different levels. Group policy objects (GPOs) can be applied at the following levels:

Local
Site
Domain
OU (and sub-OU)

The order listed above is also the order in which policy settings are applied. What that means is that policy settings at all levels merge with one another (with exceptions when Block Inheritance and No Override are used, to be discussed later). As such, if a local group policy says that I lose the Run command, site group policy says I lose access to Control Panel, domain group policy says my desktop wallpaper is the corporate logo, and the OU policy redirects my My Documents folder, then when I log on all of those things will happen. However, in the event that a conflict exists (for example the site policy takes away Run, while the OU policy says it should be available), then the lower-level policy settings take precedence.

Local GPOs are stored on the local system, and only one can exist on a Windows 2000 machine. All other GPOs – those applied to sites, domains, and OUs – are stored in Active Directory. Actually, a GPO is made up of two parts. The group policy container is stored in the AD database (this contains most settings), while larger ‘extras’ such as logon scripts are stored in the group policy template, which is stored within the Sysvol folder on a domain controller. The path to where policy templates are stored is %systemroot%\SYSVOL\sysvol\domain_name\Policies, where the folder name for the template is the globally unique identifier (GUID) of the GPO.

Group policy objects can be created by using the Group Policy MMC snap-in, but are usually created from within Active Directory Users and Computers. Remember that GPOs can only be configured and applied to the local system, sites, domains, and OUs. As such, you cannot be applied to the default built-in containers, such as Users or Computers. To create a new group policy object, right-click the appropriate container in AD Users and Computers and access the Group Policy tab. To create a new policy, click New, and give the policy a name.

You can also add an existing policy. This is useful, especially if you wanted to link the same GPO to many OUs that required identical settings. After you have named the OU, you need to click on Edit to actually configure the policy settings.

Note that settings fall into two major areas, Computer Configuration and User Configuration. Settings in the top portion apply to Computer Accounts and settings in the bottom apply to User Accounts. As such, if your computer account were in an OU called Desktops, the computer configuration settings would be applied according to the GPO settings from that OU. By the same token, if your user account were in the Sales OU, user configuration settings would be applied from that OU. If either part of the OU is not being configured in a given GPO, you should disable that portion, which will speed up group policy processing. This is done by clicking the Properties button on the Group Policy tab.

Note that multiple GPOs may exist linked to the same container. In this situation, it is possible that conflicting settings exist in the policies. When multiple GPOs exist at the same level, the policies are applied from bottom to top. That is, policies at the bottom of the list are applied before those above. The settings applied later always take precedence over those applied earlier. In the example above, User Policy 3 would be applied first, followed by User Policy 2, followed by User Policy. As such, if a site policy and domain policy also existed, the order of application would be:

Site
Domain
User Policy 3
User Policy 2
User Policy

Note that if any policies were applied to sub-OUs that existed within the Company Users OU, these would be applied after those listed above.

A Window 2000 environment running Active Directory provides the ability to use group policy to distribute software to users and computers. This allows for the distribution of software at the site, domain, and organizational unit levels (the 3 levels within Active Directory to which group policy can be applied). Note that software can only be distributed to client systems running Windows 2000.

In a group policy object, the distribution of software is handled as part of both the computer and user sections.

When distributing software, two options exist –assigning and publishing. Software can be assigned to both users and computers, but software can only be published to users. The difference between the distribution types is outlined below.

Assigning software to users: Doing this will distribute software to users, but will not actually install it on their system. When software is assigned to a user, it ‘follows’ them, or appears to be installed on every machine they logon to. In reality, only shortcuts appear on the programs menu. If they user clicks on the shortcut, then the application is actually installed on that system. Assigning software tousers gives that user access to the applications they need, even if the system doesn’t have the software already installed.

Assigning software to computers: This method actually installs the software assigned to the computer the next time the system is restarted, making it available to all users of the system.

Publishing software to users: This method adds the application to the Add/Remove programs section of control panel, allowing the user to install the application if necessary. It does not appear to be installed as software assigned to a user does. A published application can also beinstalled via document invocation. For example, if a user clicked on a zip file, WinZip would install if it had been published to the user.