First I strongly recommend that you do not reuse the user configuration for Windows XP for Windows 7. Group policies tend to grow over time and at most customers I have encountered a lot of rubbish in the old configuration. Starting over and migrating only what is needed minimize the risk for problem and makes the configuration slicker and more easy to manage in the long run.

But how do we make sure that users get one configuration when they log in to for instance Windows XP and another configuration when they log in to a Windows 7 or Windows 8 machine? Well, let’s have a look at the options including pros and cons followed by recommendations from the field.

1. Security group filtering

• Pros:
  - Require no change in OU structure/move of users.
• Cons:
  - Requires a lot of management and make it hard to administer.

2. Separate users into a new and old OU

• Pros:
  - Easy to do if you have very few users and no dependencies to other services or applications.
• Cons:
  - Not a manageable solution in an environment with many users.
  - There are often apps or services that rely on the users being in a certain OU which is making it hard to move users without affecting other services.

3. WMI filters

• Pros:
  - Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
  - A longterm investment in making it easy to introduce new operating system versions.
  - Quick determination (WMI is often known to be real slow but this particular query is not performance intensive).
• Cons:
  - Need changes for existing environment, i.e. for instance Windows XP user configuration.
  - Could make group policies not being applied due to problems with WMI repository or related services.

4. Loopback processing

• Pros:
  - Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
  - Very reliable solution.
• Cons:
  - If not Replace mode is used you need to handle current configuration.
  - Might become a mess to troubleshoot and maintain if naming and config is not done consistent and clear.

Recommendations from the field

In my professional opinion the only real alternatives are WMI filters or loopback processing and sometimes I recommend WMI filters for separating user settings depending on what operating system they are logging in to and sometimes I recommend loopback processing. It depends on the environment and needs for the customer. Many times moving the user accounts around is not an alternative but consider that a very good alternative if possible to accomplish.

How do I implement it in my environment?

1. WMI filters

In the Group Policy console you create multiple WMI filters for for instance Windows XP and Windows 7. You then set each WMI filter respectively on each GPO containing user settings for each operating system. NOTE: Always test it out before applying this configuration to your existing environment. Also note that this does not affect performance to any noticeable amount of time.

Windows XP:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "5.2%" AND ProductType ="1"

Windows 7:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.1%" AND ProductType ="1"

Windows 8:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.2%" AND ProductType ="1"

Basically the version is the OS version as we know it and the ProductType=1 means that it is a client operating system.

So you will end with for instance one GPO named “User Configuration – Windows 7″ which have the WMI filter for Windows 7 machines set and one GPO named “User Configuration – Windows XP” which have the WMI filter for Windows XP set.

2. Loopback processing

A prerequisite for using loopback processing is that you keep computers in separate OUs, for instance XP computer accounts in one OU and Windows 7 computer accounts in another OU.

You then create GPO objects in the OU for Windows 7 in our example and configure the user settings there. As I think you should always separate Computer and User configuration GPO:s I would say that you in a Computer configuration policy in that same OU set this setting for the user settings to be applied when users log into Windows 7 machines:

Policies – Computer configuration – Administrative templates – System – Group Policy and there set “User Group Policy loopback processing mode” to Replace or Merge, depending on what you want to achieve and how you want to handle your current configuration. Replace mode is recommended as you will have a hard time maintaining and troubleshooting the configuration otherwise.

Done! When users log on to your Windows 7 machines they will get the user settings you have defined in the user configuration GPOs located in the Windows 7 machines OU in our example.

The problem in this case was that whenever they started editing a group policy they got tens and tens of warning about various admx files along with for example resource errors. I looked into PolicyDefinitions folder in the SYSVOL share and immediately noticed that there was admx and adml files missing and that there were mismatch between the version of the admx and adml files.

I took a Windows 7 with SP1 client and added/replaced all admx files from there. After that I took the en-us folder and replaced what was in the SYSVOL folder with that one, followed by doing the same for the sv-se, i.e. the Swedish language files. While at it I installed IE9 and put in the inetres.admx and respective adml files for each language to have the capabilities of editing Internet Explorer 9 policies as that is to be included in the Windows 7 image. Voila!

So the bottom line is; keep the central store consistent and make sure that when you create the store that you populate it with admx and adml files from the latest client OS with service pack when managing Windows 7, and that you do make sure that you have the same version of all admx and adml files or else you will get errors due to mismatching files.

Log Name: Application
Source: Group Policy Printers
Event ID: 4098
Description: The user 'X' preference item in the 'Y {3EE4E80F-17CB-4E56-9237-4FC8B9FA090A}' Group Policy object did not apply because it failed with error code '0x8000ffff Catastrophic failure' This error was suppressed.

Logging in as the user on another machine did not produce the same problem and the mapping of printers work fine, as did mapping the printers when logging in using an administrator account.

This got me thinking that I should try mapping a printer manually as the standard user so I did. It got me a “You do not have permission to use the selected printer” which made me turn to the classic tool Process Monitor and to start a trace. It didn’t take long to see that after filtering all logs for a result of “denied” resulted in the following line:

Operation: CreateFile
Result: ACCESS DENIED
Path: \\printserver\print$\w32x86\3\OPLO_UM.dll
Desired access: Generic Read

Note that CreateFile does not necessarily mean to create a file, it can mean “read file” as documented by Microsoft for the CreateFile function. 

So the conclusion was that after investigating with the printer department the printer share “print$” security permissions did not match the user and the user actually did not have read permissions to read the driver which is an absolute requirement for the printer to be mapped (as the print driver is actually installed when the printer is mapped).

Also one setting that affected the behavior was that one have to set “Run in logged-on user’s security context” in the Common tab of the printer mapping Properties. This is an essential part of the solution…

Case closed!

My fellow MVP and now also colleague Johan Arwidmark has a blog post on two methods for handling problems related to group policies when dpeloying machines, either by settings filters on your group policies or postponing the domain join process.

What you have to do if you are stuck on domain controllers running Windows Server 2003 is to install the Remote Server Administration Tools on a Windows 7 (or Vista) client machine, add the feature Group Policy Management and then create a GPO in the domain and edit it, configuring the Group Policy Preferences of your choice. Voilà!

I do not know where this myth is coming from actually but the fact that GPO Preferences were introduced in Windows Server 2008 is the major reason I would assume.

Start gpedit.msc or the full Group Policy manager which is a part of Remote Server Administration Tools for Windows Vista and Windows 7 and go to Computer Configuration > (Policies >) Administrative templates and click “All settings”. Right click anywhere in the right pane to filter out only settings that you are interested in.

Once there choose to add a group and in my example find the “Remote Desktop Users” group and after that add the user or group you want to add to the local machines which that particular group policy object applies to. More information about restricted groups can be found at http://support.microsoft.com/?id=810076

One of the new features of the new Group Policy management tool is that you can filter policy settings. Directly under “Administrative templates” for both Computer and User Configuration there is a new “All settings” category which lists all settings in “Administrative templates”. If you select “All settings” you might then right click anywhere and choose “Filter options”. It looks like the screenshot below.

By entering the information you are looking for it is very easy to find the group policy settings that you are looking for. This is becoming more and more necessary as the number of policies grows by hundreds or nearly a thousand for every new Windows version released and it is hard to find the setting one is looking for.

Download Remote Server Administration Tools (x86)
Download Remote Server Administration Tools (x64)

The reason why I want to check Microsoft Update manually from time to time us is to regularly check which updates arrive to the various client computers that can be downloaded separately and then integrated into our installation media. Since opting into Microsoft Update require administrative rights on the computers I want to set Microsoft Update somehow automatically and apparently there are still no GPO settings for this, which I find rather strange. After doing some reserach I have found the solution to automatically set that Microsoft Update will be the default instead of Windows Update. The script to add is as follows:

Set ServiceManager = CreateObject(“Microsoft.Update.ServiceManager”)
ServiceManager.ClientApplicationID = “My App”
‘add the Microsoft Update Service, GUID
Set NewUpdateService = ServiceManager.AddService2(“7971f918-a847-4430-9279-4a52d1efe18d”,7,”")

Add this to a startup or login script to make sure Microsoft Update is always default.