UEM Network Drive Management

Traditionally you might map user network drives via a logon script or maybe a group policy preference.  VMware’s User Environment Manager (UEM) gives you some other nice options in the fun filled world of drive mappings!

We can take a conventional approach by mapping a drive for all users or targeting by an AD object such as group or OU.  OK, so far so group policy preferences!

Why don’t we map a drive on a per application basis?  Using UEM we can associate the mapped drive with an app and set it to apply ‘on demand’ when said application is launched.  This avoids the need for the drive mapping to happen at user logon but it is available when required. 

But what about my power users that want to be able to manually map drives (and persist them across devices)?  UEM does not capture these manually mapped drives by default but we can add the below registry location so this information is stored and reproduced in a different session

I’ve used network drives as an example here but by moving application settings into UEM we can optimise the logon process, provide a consistent user experience and control all relevant app settings in one place.  Very Nice!

ESXi 6.0 Update 1 Breaks Horizon View prior to 6.2

ESXi 6.0 Update 1 Breaks Horizon View prior to 6.2

Whilst out on a customer site, I had an unusual error in Horizon View 6.11. One of the pools just had “ViewCompsoer Fault:” and failed all compose jobs. Looking at the VMs in the Admin console, they all showed up as Deleting (Missing). The VMs in the vCenter didn’t exist so I had to manually delete them from the Adam Database using the VMware KBs

After trawling through the SQL Composer database to remove the Composer database entries I started to look at the error logs for View Composer. In Composer the logs had errors relating to failing to initialize the disks as it couldn’t find the path of the cloned disk. After checking the UFA logs in the View Composer log bundle, I came across an error “sslv3 Handshake Alert Error”. After a bit of digging I came across this article from VMware.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2133018

So it appears ESXi 6.0 Update 1 disables SSLv3 which is how the View Composer connects to the hosts in all versions of Horizon View prior to 6.2. Installing this update will cause the View Composer to fail on recompose tasks. This was disabled due to a vulnerability but you can re enable this as a workaround, you only need to re-enable port 902 as I have described below. .http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2121021 )

Note: to edit a file in ESXI you can use the command VI in front of the file name, to insert text once in the editor, press the insert ley on the keyboard, once finished editing press escape to exit from insert mode, then type :wqto save and exit, to save without exiting instead use :q!

1. Create a backup copy of the /etc/vmware/config file
2. Edit the /etc/vmware/config file to append the following line at the end of the file:
   
   vmauthd.ssl.noSSLv3 = false
   
   Note: If you have the line vmauthd.ssl.noSSLv3 = true in the file, change it to vmauthd.ssl.noSSLv3 = false
   
   For Example:
   
   [root@w1-fiqabj-003:~] cat /etc/vmware/config
   libdir = "/usr/lib/VMware"
   authd.proxy.nfc = "vmware-hostd:ha-nfc"
   authd.proxy.nfcssl = "vmware-hostd:ha-nfcssl"
   authd.proxy.vpxa-nfcssl = "vmware-vpxa:vpxa-nfcssl"
   authd.proxy.vpxa-nfc = "vmware-vpxa:vpxa-nfc"
   authd.fullpath = "/sbin/authd"
   vmauthd.ssl.noSSLv3 = false
3. Restart the rhttpproxy service with the command:
   
   /etc/init.d/rhttpproxy restart

Taken from VMware article here - http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2121021 )

The fix from VMware is to upgrade to Horizon View 6.2 which no longer uses SSLv3