What happened after the upgrade is what this post is about. There are some strange things going on and documentation based misleads uncovered. In no particular order…
1. In View, one user gets assigned to multiple desktops: The production side desktop pool uses dedicated assignment with full Windows 7 clones. One afternoon I get a visit from a service desk technician, who tells me a VDI user had called to report a problem with the assigned VM. The technician checked the VM, it was a desktop with no icons and no mouse action. After a reboot, the VM seemed to return to normal, but the user had already got assigned a new desktop. Now, we use Profile Unity to synchronize application settings, desktop icons and files from a central location to the VM. The user apparently couldn’t tell the difference between machines (the whole point of Profile Unity, so yay). The user thought the problem was fixed. The technician was a bit confused, since the original assigned VM had a status of ‘Available’.
After confirming the multiple desktops assigned to one user in the View Admin console, the service desk technician reported it to me. I opened a ticket with VMware who confirmed the following: The ADAM database replication was normal and no log entries pointed to an exact cause. I ended up sending them a log bundle and am waiting for results.
This is a sporadic problem that has affected only 4 of the 300+ users currently assigned a desktop in a dedicated assignment full clone pool.
However, I was told that the new View Agent with Feature Pack (FP) 2 could be the cause. FP2 was released to add remote scanning to View pools. In some cases, VMware had recommended to downgrade the agent to 5.3. That’s a sledgehammer approach that I’m going to try and avoid, which leads me to…
2. The View Agent numbering system is complicated: After installing the latest View agent, the View admin console will report it as version 6.0.1 FP2. A Windows environment will list the same version as 6.0.2.x. So, when answering the question about which agent version you have will depend on who’s doing the asking.
3. Microsoft Lync 2010, 2013 no longer reports an accurate status during View HTML desktop sessions: This one is annoying. One big selling point of VDI is the ability to virtually be in the office from anywhere with an internet connection. One big negative point of VDI for bosses who like butts in seats and knowing where the troops are is that they could be anywhere and still get work done. Microsoft Lync is one way to tell if a person is available, away, idle, etc..
If a desktop session is initiated via HTML (which is much better performing in View 6x than 5.3) the Microsoft Lync status will inevitably change to ‘Away’. It’s as if no inputs via HTML access registers with the Microsoft OS (this happens in Windows 7 and 8.1). The user cannot manually change the status in the Lync application, which was very surprising. If a session is initiated via the View client, all returns to normal. This can be a problem in many ways, obviously. VMware said they were aware of the problem and can replicate it in-house, but have no fix in place yet.
4. In Workspace 2.1 you will probably end up doing this: KB 2091744
Synchronization with View (ironically) probably won’t work out of the box. The release notes state that this problem doesn’t apply to Microsoft DNS shops, but it does. Dust off that Linux admin guide. You’ll need it.
5. In Workspace 2.1, the AD Read Account must have specific permissions in View: In previous versions, the user account could be a low level (Domain User) account with read access to Active Directory. This holds true in version 2.1, except now that it’s querying View to present desktops and applications, this account will also need specific View permissions. Add this account to View explicitly if it isn’t already in an AD group with View access. I chose Read Only Administrator access. If the account doesn’t have the correct View permissions, the error below will be logged after a sync job:
Other Error: Failed to complete View sync due to a problem with the View Connection Server. Failed to query for View Connection Servers
To be clear, this account is in two places: The Directory and View Pools sections of the Connector Admin interface.
6. In Workspace 2.1, changing the Directory access account will remove it from the Directory Sync Rules list: I found this one while troubleshooting why my synchronizations with View were failing (see #5, which you probably just read). If you decide to change the account that connects with AD in the Directory section, you’ll need to manually change it in the Directory Sync section of the Connector Admin interface. This is because once the change in the Directory section is saved, the account is removed from the rules list, abruptly cutting off access to AD.
To change this manually, open the Directory Sync and click the Edit Directory Sync Rules button. Add the distinguished name (DN) of the user that was chosen in the Directory section.
Where’s the Joy?
There’s some joy in six for sure. The ability to advertise RDSH applications is seamless (after adding the View Agent to the RDSH servers). The HTML access is much faster as advertised. The View Admin console subtle redesigns help with organization. In Workspace, shrinking the vApp from multiple VMs to one is really nice (this is mostly because VMware kicked Horizon Files to the curb for AirWatch’s Secure Content Locker) and the ability to manage it is easier once you actually get it going. App Volumes becomes available if de-coupling applications from desktops is on the agenda. It’s been successful in initial testing, although App Volumes is exclusively for linked clones.