Implementing View Persona Management
View Persona Management is a new feature to View, as of version 5.0. People have had some difficulties in getting it up and running, and I am most certainly included in that list. After more work than I’d care to admit (and several calls to VMware), we’ve gotten it up and running. Now that I’ve seen it in action, all that I can say is “wow”. It was a painful process to get it to where we are now, but now that it’s running it’s working really well and has satisfied my customer’s user customization needs spectacularly. Here’s my implementation notes, to hopefully make my (and others’) future deployments go more smoothly.
First, a brief overview of what Persona Management is, for the uninitiated (if you already know, feel free to skip this and the next paragraph). Speaking plainly, Persona Management is another option instead of Windows Roaming Profiles. It does have a few very important distinctions that make it work much better than Roaming Profiles ever have in my experience. There are two major differences, from my perspective. VPM (View Persona Management) uses Shadow Copy to synchronize the locally stored profile with the persistent network location, vs. WRP’s (Windows Roaming Profiles) use of “normal” copy. VPM has the ability to background download specific parts of the profile, whereas WRP requires that the whole profile be downloaded before logon can complete. Both solutions support (and, to greater or lesser degrees, recommend) implementing Folder Redirection in order to keep the profile size minimal.
Those two differences between VPM and WRP make a world of difference. Using WRP, I’ve seen 30 minute logons as the norm for some users (with absurdly large profiles). Anyone who’s managed a moderately sized Windows environment that uses WRP will be familiar with the profile corruption issues that can come from WRP’s synchronization attempts. These two issues have always made me extremely reluctant to implement WRP for a customer, especially in a floating desktop pool scenario where there will not be local profiles for WRP to update and it will instead need to download the full thing every time. That’s a shame, because a floating desktop pool is exactly when you want a solution such as WRP. Ok, that’s enough of that – here’s how I got it running.
VPM is a feature that gets installed as part of the VMware View Agent install. Depending on the version of the Agent that you’re installing, you may need to perform a custom install and manually ensure that it’s selected. That’s all that’s required to install it – now you just need to activate/configure it. Be aware that if you optimized your Windows 7 based on the original guide, you’ll need to re-enable some services as per this guide in order to get things working.
The View Connection Brokers have several Active Directory Admin Templates stored on them, just waiting for use. These templates are under %programfiles%\Vmware\VMware View\Server\Extras\GroupPolicyFiles. You’ll notice that there are quite a few of them to use – when you have time, I’d recommend examining them all as they give you some pretty neat control over your environment. Right now though, we’re interested in the ViewPM.adm template. If you’re using View 5.0.1 or newer, go ahead and just use this one. If you’re still on 5.0, use the updated admin template from http://kb.vmware.com/kb/2011823. Go ahead and install your template on a domain controller, as that will make it much easier to manage moving forward. Once it’s installed, you can create your GPO that will both enable and configure VPM.
In order to enable Persona Management, you need only enable a few settings in that template. You’ll want to change a few settings under Computer Configuration\Policies\Administrative Templates\Classic Administrative Templates\VMware View Agent Configuration\Persona Management\Roaming & Synchronization. First, Enable “Manage user persona”. If this is disabled, it’s not going to do anything. You’ll notice that this setting allows you to specify an upload interval; it defaults to 10 minutes. That means that after a user logs in, it will upload their profile back to the Persona Repository every 10 minutes (and perform a final upload when the user logs off).
You’ll also want to enable the “Persona repository location” policy and set your Share Path. I did not configure this customer’s Active Directory and so am not sure what other settings they may have. I found that leaving the “Override Active Directory user profile path…” option unset caused me problems, but that might be something particular to this environment. I specified a NAS device to house my Persona Repository. The syntax that you’ll probably want to use is \\Server\Share\%username% so that each user will get their own folder.
VMware has some fairly specific recommendations around Share/NTFS permissions for the Persona Repository. In addition to the WRP Required Permissions, you’ll want to follow this VMware Guide. If your storage is on a secured network, like mine is, I’d recommend setting up a test File Server on the same subnet as the desktops and using that, just to get things going. We found, after too much trial and error, that we were having issues due to a firewall. Establishing that the service works on a local subnet pretty much takes that out of the equation.
The reason that it was important to get the most up-to-date version of the Admin Template is the “Excluded Processes” setting. Microsoft Forefront Endpoint Protection (and, presumably other anti-virus solutions) can cause very slow logon times as they try to scan files that are being synchronized. As such, you can set the name of your antivirus process in this setting and VPM will ignore IO generated by that process as it tries to retrieve offline files. As a precaution, I’ve been setting it for my customers’ antivirus process.
The other folders have useful settings, especially for troubleshooting. If you enable Logging, be sure to take note that it only logs to a local path, not a UNC path. Those logs get pretty gigantic and are fairly difficult to read; I had better luck with Wireshark and firewall logs.
There are a few normal Group Policies that you’ll probably want to enable in order to make everything behave nicely. Here is what I’ve enabled:
Computer Configuration\Administrative Templates\System/Group Policy\User Group Policy loopback processing modeThese settings make sure that all of my policies are applied, ensure that Persona Management can work (as the system treats it like Roaming Profiles), ensures that I don’t accidentally blow away someone’s heretofore unknown roaming profile, disable windows update (this is a nonpersistent floating pool, so updating the members would be pointless) and disable the “Action Center” warnings about Windows Update/Firewall being disabled.
Setting: Enabled, Mode: Merge
Computer Configuration\Administrative Templates\System/User Profiles\Only allow local user profiles
Computer Configuration\Administrative Templates\System/User Profiles\Prevent Roaming Profile changes from propagating to the server
Computer Configuration\Policies\Windows Settings\Security Settings\System Services\Windows Update
Startup Mode: Disabled
User Configuration\Policies\Administrative Templates\Start Menu and Taskbar\Remove the Action Center icon
And, that’s the configuration that I needed to implement in order to get things working. I mentioned that we ran into an issue with the firewall – it turns out that ICMP Type 8 wasn’t being allowed through. Our symptom was that the user’s Persona folder was created in the repository, files were uploaded to it, but they could not be downloaded the next time the user would login and their attempted login would hang. The user had sufficient permissions (and firewall access) to manually browse their Persona files in the Repository, which threw us off of the trail of the firewall during our initial troubleshooting. Now that we’ve got the firewall sorted out and the above settings configured, I’ve been very happy with how Persona Management is functioning.