Loopback processing of Group Policy

As we know group policy has two main configurations, user and computer. Accordingly, the computer policy is applied to the computer despite of the logged user and the user configuration is applied to the user despite of the computer he is logged on.

For example we have a Domain, this Domain has two different organizational units (OU) Green and Red, Green OU contains a Computer account and Red OU contains User account. The Green policy, which has settings “Computer Configuration 2” and “User Configuration 2” is applied to the OU with the computer account. The Red policy, which has settings “Computer Configuration 1” and “User Configuration 1”, is applied to the OU with the User account. If you have a look at the picture below it will become clearer.

If Loopback processing of Group Policy is not enabled and our User logs on to our Computer, the following is true:

As we can see from the picture, the User gets Computer Configuration 2 and User Configuration 1. This is absolutely standard situation, where policies are applied according to the belonging to the OU. User belongs to the Red OU, he gets the Red User configuration 1 accordingly.

Now let’s enable the Loopback processing of Group Policy for the Green OU. In this case if the User logs on to the Computer, the policies applied in the following way:

As we can see, now the User is getting User Configuration 2 despite of the fact that he belongs to the Red OU. So, what has happened in this scenario, the User Configuration 1 was replaced with the User Configuration 2, i.e. with the configuration applied to the Computer account.

 As you have probably noticed, the picture above says “Loopback in replace mode”. I have to mention that the Loopback processing of Group Policy has two different modes, Replace and Merge. It is obvious that Replace mode replaces User Configuration with the one applied to the Computer, whereas Merge mode merges two User Configurations.

In Merge mode, if there is a conflict, for example two policies provide different values for the same configuration setting, the Computer’s policy has more privilege. For example in our scenario, in case of the conflict the User Configuration 2 would be enforced.

In the real work environment Loopback processing of Group Policy is usually used on Terminal Servers. For example you have users with enabled folder redirection settings, but you do not want these folder redirection to work when the users log on to the Terminal Server, in this case we enable Loopback processing of Group Policy in the Policy linked to the Terminal Server’s Computer account and do not enable the folder redirection settings. In this case, once the User logged on to the Terminal Server his folder redirection policy will not be applied.

How to get rid of Windows.old folder after the upgrade to Windows Server 2012?

After the server is upgraded to Windows Server 2012 there is an useless folder in the root of C:\, titled Windows.old. This folder is BIG: ranges from 10 GB to 25 GB in size, depending on the role of the upgraded server.

So it’s better to remove that folder, but how? In Windows Server 2008 R2 you had the Disk Cleanup button located in the Properties screen of every logical disk shown in the Explorer. But in Windows Server 2012 this button isn’t present any more by default:

The folder Windows.old is locked by default so it takes some time to gain permissions on ALL those folders found in the main folder Windows.old. So that’s not the way to go.

Gladly in Windows Server 2012 there is a better way: Just get the earlier mentioned button back. How?
1. Start PowerShell on the related Windows Server 2012 machine;
2. Enter: Install-WindowsFeature Desktop-Experience and hit <ENTER>;
3. It will run for some minutes and report when ready;
4. Reboot the server, the feature will be installed and initialized while rebooting. This takes some minutes as well;
5. After the server is fully functional again the button Disk Cleanup is back again:

6. Hit the button and after the scan it will show you next window;

7. Hit next button - "Clean up system files";

8. Hit the button and after the scan it will show you the option to remove the Windows.old folder;

9. OK > Delete Files;

10. It will run for some minutes;

11.After a while the Windows.old folder is deleted.
When required, the PS-cmdlet Remove-WindowsFeature Desktop-Experience will remove this feature again from your server.

Проблема с WMI на контроллере домена - Windows Server 2012 Standard

После миграции контроллеров домена, а соовтетственно и повышения уровней DFL и FFL, столкнулся с проблемой на 1 контроллере домена.
Проблема заключалась в следующем:
1. В root\cimv2 отсутствовала добрая половина классов
2. Не работал RSOP.msс - The client-side extension could not log RSoP data because it failed with error code '0x8004401e <unknown-message-text , а так же были проблемы с применением групповых политик -

Решилось перерегистрацией .dll и перекомпилированием .mofs в директории wbem и последующим перестроением WMI репозитория.

a. Re-register all of the dlls and recompile the .mofs in the wbem folder and re-registering WMI Service and Provider. You can use the following script by saving to txt file then renaming to .bat and running from command prompt with admin right and changing focus to following directory: C:\Windows\System32\Wbem.

sc config winmgmt start= disabled
net stop winmgmt /y
%systemdrive%
cd %windir%\system32\wbem
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
wmiprvse /regserver
winmgmt /regserver
sc config winmgmt start= auto
net start winmgmt
for /f %%s in ('dir /s /b *.mof *.mfl') do mofcomp %%s

  b. Reboot the machine and test WMI.

Next, check the repository for consistencies:

 winmgmt /verifyrepository

If repository is found to be inconsistent:
For Vista and newer, run from elevated command prompt:

Winmgmt /salvagerepository

Note this command will take the content of the inconsistent repository and merge it into the rebuilt repository if it is readable.
If the above doesn’t work, then run:

Winmgmt /resetrepository (This will reset repository to the initial state when the OS was first installed)

For Windows XP and Windows Server 2003, there are no built in switches to rebuild the Repository, so you must do it manually.

Warning: Rebuilding the WMI repository has resulted in some 3rd party products not working until their setup is re-run & their MOF re-added back to the repository.

If /salvagerepository or /resetrepository does not resolve the issue, then manually rebuild repository:

1. Change startup type to Window Management Instrumentation (WMI) Service to disabled
2. Stop the WMI Service; you may need to stop IP Helper Service first or other dependent services before it allows you to stop WMI Service
3. Rename the repository folder: C:\WINDOWS\system32\wbem\Repository to Repository.old
4. Open a CMD Prompt with elevated privileges
5. CD windows\system32\wbem
6. for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
7. Set the WMI Service type back to Automatic and start WMI Service
8. cd /d c:\ ((go to the root of the c drive, this is important))
9. for /f %%s in ('dir /s /b *.mof *.mfl') do mofcomp %%s
10. Reboot the server

Finally, install latest hotfixes for WMI as they can help prevent issue from recurring. If you continue to have recurring WMI repository corruption issues on same machine, please engage a Microsoft Support Engineer for further troubleshooting and assistance.