Speeding Up VMware View Logon Times with Windows 7 and Imprivata OneSign

Logon times are funny. It’s the first interaction that a user has with a system and they will base a lot of their opinion around the solution based on that first interaction. With a stateless VDI desktop that VMware View can provide, the user is logging onto a machine that they’ve never logged onto….every time. This creates an interesting problem. The first time you EVER log onto a PC, the experience usually stinks. It’s because your profile is being built from whatever has been defined on your box as the “default profile”, plus whatever scripts and GPOs need to be applied resulting in a 40-60 second login.

I am here to tell you today that the last few weeks of my life were dedicated to strapping a rocket to logon times with Windows 7, then adding the Imprivata solution into the mix and seeing how fast I could get logons from there. The use case that I was working with didn’t care about saving a users profile, they wanted the FASTEST VMware View logon times available no matter what it took, and Kiosk mode was not an option because user security context needed to be established. My first thought was, hey, let’s see if we can use mandatory profiles or somehow force all users to use the same profile that’s already loaded on the desktop. I was not successful with mandatory profiles or with forcing a user into a profile that was already on the machine, but during my search I was able to get connected with a Sysadmin who was able to achieve subsequent 10 second logins with Windows 7 and VMware View.

Quick breakdown on the environment I was working with: VMware View 5.1.1, ESXi 5.0, vCenter 5.0, Imprivata OneSign 4.6.

Here is what I learned during the course of my time.

  1. Windows XP is a dog. Get off it if you’re on it. You’re about to be forced to anyway, since the VMware stance is that they will not support a product that the original manufacturer itself won’t support.
  2. Establish baselines without hardware performance in the picture. If performance is an issue, troubleshoot that as well, but do it apart from your baselining. If you can’t prove what you Establish a best case for physical and virtual. Put your VDI linked clones on a flash LUN if you have one to remove the possibility of storage contention.
  3. Look at group policy and logon scripts. In my case this wasn’t the issue, but I’ve seen countless others where simply turning on asyncrhonous policy processing cut the times in half. Here’s the GPO optimization guide Microsoft has. Good stuff there. http://support.microsoft.com/kb/315418
  4. Slim and Trim down the profile. If the use case you have doesn’t need any profile data such as the desktop or documents folder? Guess what? Don’t include it.

Here are the tricks that I used to get 10 second initial logins with VMware View and Windows 7 while insuring the AppData in the profile didn’t bloat up over time and ultimately hurt login times again. Remember that in this use case, we expected that the users utilize their mapped drives to save ANY DATA that they cared about. It was understood and expected that their desktop folder and documents folder would NOT follow them around.

  1. We got group policy out of the equation. Machines were in a blocked OU. No loopback policy, only one GPO was utilized for the persona management configurations. Ensure that policy is processed and you log on with domain user in the golden image before building the pool. Let’s be honest, with refresh on logoff, how bad can a user mess up their PC?
  2. We used VMware View persona management and didn’t synchronize anything. I’ll go into the exact policy settings I utilized later and what I would have done if it were a requirement to keep the documents and desktop folders. Remember, we’re going for total speed here, not saving a user’s hello kitty wallpaper.
  3. Windows 7. Optimized for View following the guide. 2GB Memory. 1 vCPU. Initial logon times with a 1.75MB profile on a known good performance profile share. Consistently 15-17 second login.
  4. Windows 7. Optimized for View following the guide. 2GB Memory. 2 vCPU. Initial logon times with a 1.75MB profile on a known good performance profile share. Consistently 10 second login. This was one of the bigger performance notices. And before you go wild bumping your golden images to 2 vCPUs, make darn sure you’re aware of the impact that’s going to make on your hosts.

At this point we had a working solution with consistent 10 second logins post profile build. Now what do we do? We start layering in pieces of the solution and document logon times ONE BY ONE.

One such piece of of the solution was the Imprivata OneSign agent. We noticed that once we installed the OneSign agent MSI, the logon times went from 10 seconds to 30. Then we noticed that if for some reason we didn’t refresh that machine, subsequent logins were back to 10 seconds again. What the heck? We discovered that when you install the OneSign agent from the OneSign Appliance web page..it will automatically stuff the Trusted CA cert for the self signed cert on the Imprivata appliances into the machines local certificate store. This doesn’t happen when you install the MSI. So once we manually put the CA cert in the machines local store, we were back to 10 second logins. Another tip is to ensure that Domain Users have modify rights to C:\ProgramData\SSOProvider, as that’s where Imprivata keeps its DAT files which are regularly updated. Since users are the ones logging on, they should have full rights to that folder so they can be updated.

And so the story continues for me, layering in the solution one at a time. One pro-tip….do AV LAST. If you do it first it might have a performance impact that you’re confusing with application performance, when in fact it’s AV. Another pro-tip is to use a VDI optimized AV, such as a host based AV, or one that can scan and hash all the files in the golden image.

So here’s what you probably scrolled to the bottom to see: the list of Persona Management settings. Well here you go. We also ran into that “White start bar icons” with Windows 7, and were able to work around it by including the synchronization of the AppData\Local\IconCache.dll, along with the AppData\Roaming\Microsoft\Internet Explorer\Quick Launch folder. Pretty much everything else was excluded. If we would have wanted the Documents and Desktop folder redirected, we would have excluded them from the “Do not sync” policy, and redirected them either with native Windows policy or using the “VMware View Agent Configuration/Persona Management/Folder Redirection” section of the GPO.

If you have knowledge worker/power users that need all their documents and AppData redirected and are going to be using Linked Clones, my suggestion is to not go the persona management route, but to use a third party product such as Liquidware Labs, RES, or another suitable product. I’ve seen those two work well.

GPO Settings

VMware View Agent Configuration/Persona Management/Roaming & Synchronization

Manage User Persona: Enabled
Profile Upload interval (in minutes): 10

Persona Repository Location: \\servername\servershare\%USERNAME%\Personal
Override Active Directory Path if configured: enabled

Roam Local Settings Folders: enabled

Files and Folders Excluded from Roaming:
AppData
AppData\Local
Contacts
Desktop
Documents
Documents\My Music
Documents\My Pictures
Documents\My Videos
Downloads
Favorites
Links
My Documents\My Music
My Documents\My Pictures
My Documents\My Videos
My Music
My Pictures
My Videos
Saved Games 
Searches

Files and Folders Excluded from Roaming (exceptions):
AppData\Local\IconCache.db
AppData\Roaming\Microsoft\Internet Explorer\Quick Launch
Advertisement

5 thoughts on “Speeding Up VMware View Logon Times with Windows 7 and Imprivata OneSign

  1. In non-VDI environments (i.e., real hardware), have you observed noticeable increases in first-time logon speed with mandatory profiles?

    We have numerous computers that have mid-range i5 processors, 4 GB of RAM, 7200 RPM hard drive, and Windows 7 and Windows 8.1. When a user logs in the first time in Windows 7, the logon takes about 35 seconds — not terrible but not great. In Windows 8.1, it takes closer to 90 seconds.

    These are extremely basic machines: no logon scripts, nothing pushed with GPO, no programs other than Web browsers and Office 2013. In fact, even if I take the machines off of the domain, the first-time logon is about the same speed.

    Should I be seeing faster logon speeds? Your 10 seconds is astoundingly great, and that was in an VDI environment. Students will tolerate our 35-second logons in Windows 7, but they will not tolerate our 90-second logons in Windows 8.1, and I just don’t know what to do to speed it up.

  2. The big thing to note here is that we are using a profile management tool called Persona Management. It’s the one VMware includes with VMware View, but there are many similar tools (ProfileUnity by Liquidware Labs is a great cheap one). If the profile is not preserved on the network and needs to be built fresh for every user each time they log onto a new workstation, then yes, it will definitely take a long time. In order to get the logons faster, you need to preserve the profiles somehow, which is what we did with the profile tool in this article.

  3. Could you give precise instructions on the Imprivata certificate portion of your tweaking? I imported these certs into the master image used to create our linked clone pool, but saw no decrease in login speed.
    Thank you.

    1. So the way I proved it was the Imprivata cert was by starting from scratch and adding each component as it went along, verifying login speed. I suggest you do the same. I don’t have precise instructions other than export the cert from the appliance webpage and import it into the VM.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.