Building the Environment
As the client had sufficient swing space in terms of compute, it permitted the deployment of a parallel implementation, allowing a clean slate to be deployed where required. When performing project work like this, it is always my preference to work this way so as to provide a rollback, sufficient testing time for environmental comparisons and avoid bringing in “customisation’s” that grew with the legacy environment that are no longer applicable in the new.
The underlying Hypervisor environment and swing space hosts were built from scratch and provided with sufficient storage to meet the needs of the deployment. The additional components were built out as follows:
vSphere 6 in order to meet the requirement for Instant Clones
vCenter using VCSA to reduce unnecessary Windows patch management
vShield Manager 5.x
Trend Deep Security 9.6 SP1
AppVolumes 2.11 to meet the requirement for Instant Clones (2.10 doesn’t work with Instant Clones)
Horizon 7.0.1 (latest release at the time of deployment)
Access Points 2.5.2 (latest supported release at the time of writing)
Where supported and required, virtual KEMP Load balancers were used internally in front of the Connection Servers and AppVolumes Managers as well as externally in the DMZ for the Access Points.
I won’t go into the detail of the installation as there are many online tutorials on how this is done but I will elaborate on some of the challenges and compatibility issues faced on the way.
- Instant Clones is not compatible with VMware Persona management (Page 16, under restrictions). As the initial aim was to deploy Horizon 7 to ensure support compliance, there was no quicker way than to retain Persona as UEM would take far more planning and effort than timeframes would allow. UEM would follow as a later sub-project so this took Instant Clones off the table immediately.
- Scope creep resulting in office activation prompts with certain AppStacks. During the deployment of Horizon 7, Microsoft Lync was introduced which meant that in addition to running Microsoft Office 2010 in the base image, components of Office 2013 were now present too. This resulted in applications delivered by AppVolumes needing to be re-provisioned where there was a KMS overlap as the AppStacks were originally only sealed with the presence of an Office 2010 KMS key. This resulted in the OS trying to re-activate Office applications post logon which caused no end of grief as we muddled through 100+ Appstacks to eliminate those that would present the activation prompt.
- Sessions would randomly drop and users were unable to reconnect when using PCoIP. One of the most bizarre problems would be random session disconnects which left users unable to reconnect. If the user switched to using HTML access, they were able to reconnect to their session, save their work and logoff to create a new PCoIP session. Eventually, after running process monitor against a faulting virtual machine, I identified the fault being down to excessive logging created by the TPAutoconnect service which would result in the log files filling the non-persistent disk. This only happened with users who either worked remotely or had printers attached to their endpoint device (in most cases, there were very few as 90% of the user base were on Zero client devices). To date, there hasn’t been a resolution to the growth in logging levels, but as a work around, persistent disks were removed and the OS disk size increased. It has been noted that there is an uplift in I/O and an SR is still active with GSS.
- AppVolumes 2.11 – bug with filter driver causing the error “Item not found” and “Could not find this item”. We have scripts that create and delete files to validate certain conditions for virtual desktops but randomly after introducing AppVolumes 2.11, the log files would throw up an error. We could also reproduce this problem by manually creating a file on the C: drive, then deleting it, resulting in the same Windows error. VMware subsquently issued me with AppVolumes 2.11.1 Patch release to allow us to continue with deployment.
- Error occurred during vCenter operation. This error occurred when a default linked clone Desktop Pool was configured with 3D rendering (any option) and “Allow users to choose protocol” and the option was changed to “Yes”. Bizarrely, the wizard permitted this configuration but any further actions to the pool resulted in the error. A quick check of the Logs on the Connection server, revealed the error stating that it was an invalid configuration (as per the documentation), but why this couldn’t be translated into a meaningful message from the console, I’m not quite sure.
- P25 Zero Clients, the primary monitor does not either correctly detect the resolution (going into 1024×768 rather than 1920×1200), or during login, the screen goes black, returns, hangs on Welcome, stalls back to black and eventually returns to display the desktop. (I’m guessing the sequence of events its part of the sync that takes place as it detects the primary/secondary monitor resolution). This was random and eventually by upgrading the Horizon View Agent 7.0.2, the problem appeared to be resolved.
- Remote sessions would disconnect after 10 hours – this came down to a hardcoded and unchangeable value in the VMware access point 2.5.2. This has since been resolved in VMware access point 2.7.2 and has been deployed since as users would work for 12+hours and the hardcoded value was not acceptable.
In summary, here’s where we ended up:-
Horizon View 7.0.2 (due to screen refresh problem)
VMware access point 2.7.2 (due to uncontrollable session disconnects)
VMware AppVolumes 2.11.1 (due to filter driver bug)
VMware persona management (retained due to shortened deployment window)
VMware linked clones (as Instant clones are not supported with Persona management)
50% of the Appstacks being reprovisioned due to the introduction of multiple KMS keys.
If you would like more information or details on these problems, please feel free to reach out and i’ll try and fill in the gaps or update the post where required.