A blog with focus on Windows 10 and cloud <solutions
RSS icon Email icon Home icon

  • HOW TO: Handle user group policy settings in multiple OS environments

    Posted on December 22nd, 2011 By Andreas Stenhall + 1 comment

    This is a very common question and one that I would say all companies migrating to Windows 7 has experienced. The scenario is how do we handle user group policy settings when we have multiple operating systems such as Windows XP and Windows 7 or in the future also introduce Windows 8?

    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.

  • Busting the myths: Windows 7 require Windows Server 2008/2008 R2 domain controllers and raised functional levels

    Posted on May 26th, 2011 By Andreas Stenhall + 1 comment

    It seems a fairly common misconception is that to be able to use Windows 7 in a Windows or should I say Active Directory environment one need to have either Windows Server 2008 or Windows Server 2008 R2 domain controllers. There are also misconceptions about the need to raise the forest and domain functional levels to be able to use the full power of Windows 7. Neither of these are true.

    You can get all the same features if you are using Windows Server 2003 domain controllers and that is also regardless of which forest or domain functional levels you are running with. The most common misconceptions are:

    • Group Policy Preferences. Work very well in a 2003 domain. However you need to manage the group policies from a Windows 7 or Windows Server 2008 R2 machine using Group Policy Management Console found in the Remote Server Administration Tools.
    • BitLocker. To store recovery keys in AD you need to extend the schema. If you have a domain controller that is running Windows Server 2008 or later you have what it takes, if you are running Windows Server 2003 on your domain controllers you simply extend the schema.

    I must add that you get stronger encryption for Kerberos by using Windows Server 2008 domain functional level though but the bottom line is that the functionality of the Windows 7 client is the same regardless of forest or domain functional levels.

  • Handling the Group Policy central store with care

    Posted on April 18th, 2011 By Andreas Stenhall + No comments

    Today I visited a customer site where the customer had setup a central store, meaning all group policy defintion files and language files are placed in the SYSVOL share for better management of group policies. One benefit of that central store is that all administrators managing and editing group policies are using the same templates.

    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.

  • Active Directory Administrative Center makes you do things in fewer steps

    Posted on October 11th, 2009 By Andreas Stenhall + No comments

    A new tool in Windows Server 2008 R2 that you must not miss is the Active Directory Administrative Center. The tool is far from the speediest to load but once you’ve got it started I promise you that you will find it very convenient to use for account and other Active Directory object management. As with the user interface, new search tools and more in Windows 7 the Active Direcory Administrative Center in Windows Server 2008 R2 makes you do things in fewer steps and eases your daily work!

  • Be aware of a problem when renaming domain controllers

    Posted on September 20th, 2009 By Andreas Stenhall + No comments

    If you have renamed a Windows Server 2008 or Windows Server 2008 R2 domain controller you should be aware of  a problem. The problem is that a DFSR object is not renamed to the new name. This does not cause any problems until you remove the domain controller in question and after doing a demote or cleaning it up with metadata cleanup the object will become orphaned. So if you have renamed 2008 or 2008 R2 DCs you should follow the steps in KB2001271 to fix this.

  • Restore permissions on objects in Active Directory

    Posted on June 14th, 2009 By Andreas Stenhall + No comments

    Some time ago I had the unfortunate job to do some manual cleaning of an old and since long disconnected (and not decommissioned) Exchange Server in Active Directory using adsiedit.msc and this is not something one want to do I can promise you. Anyway during the testing phase I had to make sure that certain keys and values in adsiedit.msc were safe to be deleted and to accomplish this I removed all permissions on the keys to make sure that no one could read the information. You might think that restoring the permissions on objects in adsiedit.msc is the same as the management with file and folders but that is not the fact.

    Instead use the command DSACLS to control the access control lists of Active Directory objects and run for example the following command to let the group Everyone get full permission on the object “First administrative group”.

    DSACLS "CN=First Administrative Group,CN=Administrative groups,CN=CONTOSO,
    CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=CONTOSO,DC=LOCAL"
    /G Everyone:GA

    Beware when working in adsiedit.msc and be very certain about what you are doing before deleting stuff. Sometimes just removing all permissions on objects is the best way because then you can always use the above command to restore permission to the object(s).