Restricting Settings by Active Directory Site with Only One GPO
Posted by Trevor Sullivan on 2011/06/30
Have you ever wanted to configure a setting using a single Active Directory (AD) Group Policy Object (GPO), but have a different value for each logical AD “site” in your IT environment? Well, even if you haven’t, there are other folks out there that do. Here is a paraphrased version of an inquiry that I received recently:
“I am working on a Windows 7 deployment, and I would like to have custom wallpapers depending on the physical location. This I am able to do but there are 20+ Active Directory sites and can do it with a GPO assigned to each site. However, it would be easier to manage just a single GPO. Is this possible?”
In short, this person wants 20+ different wallpapers, but doesn’t want to have to create 20+ unique GPOs in order to configure the wallpaper. The most common suggestion in this case, at least historically, would probably be to write a custom user-based logon script (as opposed to a computer startup script) that checks the current AD site, and sets the wallpaper based on that. Granted, that would be a pretty solid solution, however with Group Policy Preferences (GPP), we have another option that requires no knowledge of scripting!
Let’s explore how to use Group Policy Preferences to consolidate multiple desktop wallpaper configurations (per AD site) into a single GPO!
Group Policy Preferences
Group Policy Preferences are an extension to the core Group Policy Objects that existed in earlier versions of Active Directory. They allow a wider array of settings to be configured, and they also don’t lock users out from changing preferential settings (hence their name). Rather than setting policy, you’re pre-configuring a preference, and allowing the user to change it if they’d like to. One of the additional configuration options that GPP provides is the ability to specify arbitrary registry values – one of those registry values happens to be able to configure an end-user’s wallpaper. The path to that registry value is: HKEY_CURRENT_USER\Control Panel\Desktop:Wallpaper (REG_SZ / string).
The following steps will show you how to configure a test case around the topic, using a virtual lab environment.
- (optional) Configure Active Directory sites
- (optional) Configure DHCP scopes and scope options
- Deploy standard wallpaper folder to clients
- Create Group Policy Preference registry values and define WMI conditionals
Configure Multiple Active Directory Sites
Note: You can skip this section if you’re working in a properly configured Active Directory environment.
In Active Directory, we’ll need to have multiple logical sites configured to test with. In this example, I have two AD sites named:
- Main – 192.168.10.0/24
- NewYork – 192.168.23.0/24
The subnet definitions that correlate to each site, must assigned to their respective sites as well.
In my example, I have two virtual network adapters on the domain controller. The domain controller serves up two DHCP scopes for each network, so that client workstations can get IP addresses from it.
Configure DHCP Scopes
Note: You can skip this section if you’re working in a properly configured production network.
If you’re working on a lab network, make sure you have two separate DHCP scopes configured, for clients to get IP addresses on. Also, make sure that you have a scope-level (as opposed to server-level) DHCP option configured to define the appropriate IP address for clients to query the DNS service on the domain controller. This is DHCP option #6 (see screenshot).
Create a Local Wallpaper Folder
On the workstation side, the first thing you’ll want to do is to create a local wallpaper cache folder that’s standardized across your Windows workstations or servers. In this example, I’m simply using the %WINDIR%\Wallpaper folder as an example. You could use a tool such as Microsoft System Center Configuration Manager 2007 to deploy the files down to client systems, and have a script copy them from the SCCM client cache into place. Alternatively, you could use Group Policy Preferences to copy the files down to client systems.
Either way, you’ll want to make sure that these files are pre-staged on client systems, so that when the Wallpaper registry entry is configured, the file it references already exists and can be used.
Create / Edit Your GPO
Next, you’ll need to go in and create a new GPO, or edit an existing one that you want to use to set the wallpaper. Use the Group Policy Management Console (GPMC) to do this. The GPO will need to be linked to an OU where the user account you’re logging into workstations with resides.
Once you’ve created the GPO, right-click it and hit edit. In the Group Policy Editor, navigate to the User Configuration –> Preferences –> Windows Settings –> Registry node.
Right-click the Registry node, and select New –> Registry Item. Fill out the fields similar to the screenshot below.
- Action: Update
- Hive: HKEY_CURRENT_USER
- Key Path: Control Panel\Desktop
- Value name: Wallpaper
- Value type: REG_SZ
- Value data: %WINDIR%\Wallpaper\MyWallpaper.jpg
Next, head over to the “Common” tab. This tab contains settings that are common amongst all Group Policy Preferences configuration items. One of the things I really like about this tab is that it gives you an arbitrary “Description” field that allows you to leave detailed notes for other people. Please use it for the sake of your fellow / future admins!
Check the “Run in logged-on user’s security context (user policy option). Having this option enabled means that the registry value we specify will be configured in the end-user’s registry hive, rather than the system (computer) account’s user registry hive (remember that HKEY_CURRENT_USER is relative depending on the execution context of a given process).
Check the “Item-level targeting” checkbox, and then click the “Targeting” button. Create a new “WMI Query” rule (next screenshot) in the targeting editor, and fill out the fields according to the second screenshot below.
Rinse and Repeat
Once you’ve finished this, repeat the same steps in this section to create a second Group Policy Preferences registry item, but change the wallpaper to something different, and change the WMI query to look for your other Active Directory site name.
Here we change the wallpaper path to a different file:
And in the WMI query, we use ’NewYork’ as the AD site name instead of ‘Main’.
Great! Now we’ve got two unique wallpaper configurations specified, based on the Active Directory site that a client is a member of.
Now that everything’s configured, we can test out our configuration.
All we have to do is place a client in each Active Directory site, and ensure that the correct wallpaper comes up. In VMware Workstation, this is easy .. we can simply change the virtual network that a client belongs to, and allow it to think it’s in a different AD site.
With the client workstation running, open the network properties, and assign it to the network that the first of your two AD sites represents. In this case, my “Main” AD site is on my VMnet8 (NAT) virtual network:
- Wait for the client to get an IP address
- Run “gpupdate” at the command line
Once complete, the client should be assigned to the “Main” AD site. Assuming this is the case, logoff and logon to the workstation — the wallpaper for “Main” should appear.
Now, change the client’s network configuration to the virtual network that represents the other AD site.
- Wait for the client to get an IP address
- Run “gpupdate” at the command line
Once complete, the client should be assigned to the “NewYork” AD site. Assuming this is the case, logoff and logon to the workstation — the wallpaper for “NewYork” should appear.
During the course of configuring wallpapers, there may be some issues you run into.
Symptom: Wallpaper does not display properly.
Cause: Client has not detected the new Active Directory site.
Fix: Ensure network connectivity to the domain controller and run “gpupdate” from the client (you do not need to use the /force command line parameter)
Validation: Run “gpresult /r” from an administrative command prompt to ensure that the client is configured for the correct Active Directory site.
Validation #2: Use an administrative PowerShell prompt to run this command to retrieve the client’s current Active Directory site: (Get-WmiObject –Namespace root\rsop\computer –Class RSOP_Session).Site
Symptom: Wallpaper displays for some AD sites correctly, but not others.
Cause: Active Directory site was mistyped in the WMI query item-level targeting restriction
Fix: Edit the item-level targeting properties, and ensure that the WMI query conditional is typed correctly.
Symptom: Wallpaper does not display as configured.
Cause: Once GPO applies, all it does is update the registry value for the wallpaper path. It does not explicitly update the wallpaper.
Fix: The user must logoff / logon for the change to take effect.
Symptom: Wallpaper does not display as expected.
Cause: Improper file path typed in wallpaper registry value
Fix: Edit the Group Policy Preferences registry item, and set the “Value name” to the correct file path on the client. Make sure that the file exists on the client.
This article has demonstrated the use of Group Policy Preferences (GPP) to configure the wallpaper for end-users. It has also shown how to provide multiple, conditional wallpaper settings using only a single Group Policy Object (GPO).
Group Policy Preferences can be used for many other configuration items, and the conditional settings made available by item-level targeting are very powerful. For example, you could do exactly what we did above, but have a unique wallpaper for daytime and evening hours, for each Active Directory site, using the Time Range conditional! The possibilities are almost endless!