Profile state emulation
By James Rankin | 1st March 2012
Had a customer today who wanted their XenApp users shifting from local profiles to mandatory profiles with AppSense User Personalization. The first thing to do was get the users’ local profiles removed before we could enforce the mandatory profiles, as the customer was insisting on a “clean start”. However, the local support guys who were responsible for removing the profiles didn’t have administrative access to the XenApp servers to do so, and weren’t likely to be given it. Don’t forget, removing a user profile in Windows 2008/Vista and up isn’t as simple as deleting the folder from c:\users\%username%, unless you want to see a lot of logon failures afterwards with messages saying “the user profile service failed the logon” (which I will discuss in a later post for those who are unfamiliar with why this is).
I had two choices a) configure AppSense Application Manager to elevate the local support guys’ accounts to a temporary administrative state when using the System Properties applet, or b) find some way to get the local profiles to remove themselves. Whilst a) was a good option to showcase Application Manager’s capabilities, the Application Manager agent was not installed on their XenApp servers and getting the downtime to install it would have taken much too long, as well as causing disruption to their user base. So b) it was. Now, there are various scripted mechanisms I could have chosen to remove profiles, but as there is an HKLM Registry key to remove as well as folders, it could have gotten complicated quickly. Luckily, there’s a slightly simpler option.
The Registry keys that have to be removed from HKLM to dispose of a profile also contain a value – called State – that tells the OS what sort of profile the user has. Now some profile types – mandatory and Guest profiles, mainly – are automatically purged by the OS at logoff time. So if we can manipulate this Registry key to make the OS think the user has a Guest or mandatory profile rather than a local one, it will do our work for us! This is a familiar concept in AppSense circles and it’s referred to as profile state emulation.
0001 Profile is mandatory.
0002 Update the locally cached profile.
0004 New local profile.
0008 New central profile.
0010 Update the central profile.
0020 Delete the cached profile.
0040 Upgrade the profile.
0080 Using Guest user profile.
0100 Using Administrator profile.
0200 Default net profile is available and ready.
0400 Slow network link identified.
0800 Temporary profile loaded.
Now to set them you’ll need to convert the hex value to decimal (a quick use of calc.exe or even regedit.exe can help you with this, if you can’t do it in your head), so for the script we are using we’ve gone for 128 (which gives us Guest) but you could equally use 1 for Mandatory. However, I’ve never had any issues with Guest so I guess I’ve just stuck to what I trust to work 🙂
The script is reproduced below and can be run via a GPO, or an AppSense Environment Manager logoff action, or whichever way you feel is best. Naturally, I prefer to use the EM logoff action.
Set objNetwork = CreateObject(“WScript.Network”)
wmiQuery = “Select * From Win32_UserAccount Where Domain='” & objNetwork.UserDomain & _
“‘ And Name='” & objNetwork.UserName & “‘”
Set objWMIService = GetObject(“winmgmts:\\.\root\cimv2”)
Set colItems = objWMIService.ExecQuery(wmiQuery)
For Each objItem in colItems
NextDim objShell, RegLocate, RegLocate1
Set objShell = WScript.CreateObject(“WScript.Shell”)
On Error Resume NextRegLocate = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\” & x &”\state”
Once you’ve saved the script somewhere and set some way for your users to trigger it at logoff, that should be that! Test the script on yourself when you’re logged in before deploying though, just to be sure it works as intended. Once you run it, you should see your Profile Type in System Properties change.
There are some who use a trick like this to use local profiles instead of mandatory profiles to get the system to clear out user profiles at logoff, and save their settings into User Personalization. In fact, I’ve heard that AppSense themselves sometimes recommend it (although I can’t speak to that). The whole issue of mandatory profiles with Personalization versus temporary local profiles with Personalization is quite an interesting issue and one that I intend to delve into in a later post.