Using Group Policy preferences (GPP) is a great way to configure computer and user settings like mapped drives, printers, scheduled tasks, services, and Start menu settings. However, when using GPP in a non-persistent VDI environment, you have to be careful with one specific feature…
** If you want to know more about VDI in general and the different kind of VDI’s, you should read the VDI Smackdown whitepaper. Basically, when talking about server hosted VDI you have two options: persistent and non-persistent desktops. Persistent desktops are desktops which will keep the changes made to the system (installed software for example). Non-persistent desktops are deleted after the user logs off, or the desktop is reverted to the original state. A non-persistent desktop has the benefit of maintaining a single disk-image and re-deploy it to all the non-persistent desktops in the pool. This is the reason why a non-persistent desktop is used 80% of the time in a VDI-environment.
What’s import to remember for this article is that when the user logs off, the changes to the system are deleted.
User profile and setting management
Group Policies and Group Policy Preferences can be used to manage the user’s profile and settings. When combined with folder-redirection you have a decent “user environment management” system. There are other solutions which are probably more flexible, easier to manage and have lots of other advantages, but Group Policies and Group Policy Preferences are free (as long as you have Active Directory) so why not give it a try?
**Difference between Group Policy settings and Group Policy Preferences?
** The key difference between policy settings and preferences is enforcement. Group Policy strictly enforces policy settings while Group Policy preferences enable you to deploy settings to client computers without restricting the users from changing the settings. Group Policy Preferences are not removed when the GPO is removed from the user or the computer. However, there is this one setting that changes this default behavior:
Remove this item when it is no longer applied
For example: you can add a shortcut to a user’s start menu, and when this specific GPP doesn’t apply to the user anymore, the shortcut will be removed. This works fine with “regular” desktops and persistent desktops, but not always with non-persistent desktops.
When is this a problem? When redirecting the start menu to a network location (because you allow users to add their own shortcuts to the start menu or desktop) or when using roaming profiles. In these situations shortcuts will not be removed on a non-persistent desktop when the GPP doesn’t apply to the user anymore. Why? Because the setting “Remove this item when it is no longer applied” uses the group policy history file which is located in the %commonappdata% directory. This directory is located in the All users\Appdata (XP) or c:\Programdata (windows 7) and changes to this directory are deleted when a user logs off from a non-persistent desktop.
And this is not only a problem with shortcuts, but also other settings that can be applied with Group Policy Preferences, like registry settings. For example, if you want to set a user registry setting and you use roaming profiles, the registry setting will be saved in the roaming user profile. But when you use the setting “Remove this item when it is no longer applied“, and you remove the user from the scope of this registry setting, this registry key will not be removed because it isn’t located in the GPP history file.
There is a workaround. If you create a shortcut and apply this shortcut when a user is member of a group, create the same shortcut in Group Policy Preferences, but with a delete action when the user is NOT a member of that group.