For the past year, my primary project at work has been to engineer, develop, and deploy a VMware View virtual desktop infrastructure for the hospital and its dozen off site locations.
I realize that this parody video may be only funny to those who work with VDI solutions, but I just had to share. The best line of them all… “Don’t worry, he won’t get us Google Chromebooks.”
Hilarious. BTW. I wrote this via my work’s VMware View desktop running on my home laptop.
I have a vendor with a web-based SAS service that requires a password encrypted .PFX certificate to be imported into the user’s Personal certificate store.
For physical desktops, this is a one-time import procedure. But for VMware View VDI desktops that are non-persistent, users receive a new desktop every day and would thus have to import this certificate over and over again. I needed a way to automatically import the certificate into the vendor-required store automatically.
When I opened up Group Policy Management and navigated to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies, I found several certificate stores that I could import the .PFX file into. The Trusted Root Certification Authorities or Trusted Publishers stores would seem like good places to import this vendor certificate, but neither are the correct store that the vendor requires.
User Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies also had a few stores I could target, but none contain the User’s Personal store. The correct store can be found via Internet Explorer -> Internet Options -> Content -> Certificates -> Personal. Unfortunately, Group Policy isn’t able to target this certificate store.
Since Group Policy and Group Policy Preferences didn’t offer a way to import a .PFX certificate into a user’s Personal certificate store, I turned to scripting the solution.
I first placed the vendorcertificate.pfx on a network share (e.g. %LOGONSERVER%\netlogon\certificates\vendorcertificate.pfx).
Next I created a .BAT script named import-certificate.bat which runs this command:
certutil -f -user -p "CertificatePassword" -importpfx "%LOGONSERVER%\netlogon\certificates\vendorcertificate.pfx"
I then created a .VBS script named import-certificate-silently.vbs that will run the import-certificate.bat script silently (so the user does not see a flash of the CMD window when this runs):
Set oShell = CreateObject ("Wscript.Shell")
Dim strArgs
strArgs = "cmd /c %LOGONSERVER%\netlogon\certificates\import-certificate.bat"
oShell.Run strArgs, 0, false
Since I want my script to run only for subset of my VMware View users, I created an Active Directory Security Group that contains the users who need access to this SAS web-based application (e.g. APP-InstallVendorCertificate).
I then returned to Group Policy Management and navigated to User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks. I created a Scheduled Task that runs 30 seconds after the user logs in if they are a member of the APP-InstallVendorCertificate security group. The schedule task runs %LOGONSERVER%\netlogon\certificates\import-certificate-silently.bat.
The result is that when a VMware View user who belongs to the APP-InstallVendorCertificate security group in Active Directory logs into their virtual desktop, the required SSL Certificate is automatically installed in their User -> Personal certificate store.
In my previous article “Using BgInfo with VMware View,” I discuss how to use Microsoft’s BgInfo utility within a VMware View desktop pool to write the following information to a user’s wallpaper:
My BgInfo solution is great. It helps users know they are accessing their own virtual desktop (nurses and doctors frequently move from one PC to the next) and helps the Help Desk identify who is working where (by computer name, IP, or MAC address).
The primary problem is that my initial solution ran BgInfo only at logon. When nurses and doctors switch from one physical client to another (typically stationary thin or zero clients), BgInfo’s values are not updated and were now displaying stale IP/MAC values for the physical client.
The secondary problem was that monitor resolutions vary, sometimes forcing the BgInfo content out of view.
The solution was to leverage Group Policy Preferences, Scheduled Tasks, and Event Logs. I wanted to use these three tools to trigger BgInfo to run whenever a user moved their VMware View virtual desktop from one location to another. Here’s how I did it.
Open your Group Policy Management Editor, create a new Group Policy, and click Edit. Navigate to User Configuration > Preferences > Control Panel Settings > Scheduled Tasks. Right-click > New > Scheduled Task for Windows Vista or greater.
Give it a useful name and then stick with the defaults.
Create a new Trigger to run GpUpdate 30 seconds after logon. When using the PCoIP protocol, I’ve found that some zero and thin clients resize shortly after logging the user into their desktop. Having BgInfo run 30 seconds after login makes sure it appears in the right spot.
This was my first solution. If I could get BgInfo to randomly run several times a day, I’d have more accurate information. Since Group Policy updates occur about every 90 minutes, I configured this Scheduled Task to run after EventID 5315 (Log: Microsoft-Windows-GroupPolicy/Operational; Source: Microsoft-Windows-GroupPolicy) appeared in the virtual machine’s Event Logs. Additionally, the Help Desk could ask a user to run “gpupdate” to refresh BgInfo at will.
This proved to be the better solution. When a user logs into their VMware View desktop from another location, EventID 25 (Log: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational; Source: Microsoft-Windows-TerminalServices-LocalSessionManager) appears in the virtual machine’s Event Logs. If I could get BgInfo to run every time this event occurred in the logs, then the BgInfo would remain accurate as the user moves from one location to another.
Create a new Action that silently runs BgInfo from a network share. I use a VB Script that silently launches a BAT file.
Set oShell = CreateObject ("Wscript.Shell")
Dim strArgs
strArgs = "cmd /c \%LOGONSERVER%\netlogon\Bginfo-nonpersistent.bat"
oShell.Run strArgs, 0, false
@echo off
%logonserver%\netlogon\bginfo.exe %logonserver%\netlogon\Bginfo-nonpersistent.bgi /Timer:0 /NoLicPrompt /silent
I’m not using these tabs.
By using Group Policy Preferences to create a Scheduled Task that monitors specific Event Logs, we’re able to have BgInfo run and update a user’s VMware View desktop wallpaper each time they move from one location to another.
VMware View Security Servers require an SSL certificate to be installed for mobile VMware View clients to function properly. It’s also a good practice.
Chapter 7 of the VMware View 4.6 Installation manual attempts to document the procedure of how to export a certificate from a Windows 2008 IIS server and import it into a Windows 2008 VMware View Security Server, which happens to rely on Apache Tomcat.
The instructions and examples of the VMware View Installation manual are incomplete and its examples are sometimes misleading. After spending days of experimentation, all while working with VMware Support, I finally figured out how to properly perform this procedure.
In my example, I’m using a wildcard certificate from GoDaddy (*.example.com) that has been pre-installed on a Windows 2008 R2 IIS server in our domain. My objective was to export this wildcard certificate from our IIS server and use it for our VMware View Security Server at desktops.example.com.
By adding the “keytool” folder to the system environment Path variable, we will be able to run this utility from any directory on the host.
We already own a GoDaddy wildcard SSL certificate (*.example.com) that is installed on a Windows 2008 server running IIS. We want to export this certificate from IIS and install it on the VMware View Security Server.
IIS exports certificates in the .pfx format, which is a PKCS#12 file format. The PKCS#12 format includes both the server certificate and the private key, but not the intermediate certificates.
GoDaddy wildcard certificates are signed by an intermediate GoDaddy CA rather than by a GoDaddy root CA. Before doing anything with our “desktops.example.com.pfx” certficate, we must first add the intermediate certificate to a keystore file. This process will also create our Tomcat keystore file for us.
Visit https://certs.godaddy.com/anonymous/repository.seam to find a list of GoDaddy intermediate certificates. In our case we want “Go Daddy Certificate Bundles (for cPanel, Plesk, Apache 1.x and 2.x installation only)”, which is the file “gd_bundle.crt.”
Once you have the intermediate GoDaddy certificate in place, it’s time to import the “desktop.example.com.pfx” server certificate you exported from your ISS server. Your .pfx export contains both the server certificate and the private key.
To configure a View Security Server to use the SSL certificate, we must create a “locked.properties” file on the View Security Server and provide it some values.
If you have been following along, your “c:\Program Files\VMware\VMware View\Server\sslgateway\conf” folder on your VMware View Security Server should have these newly added files:
keyfile=keystore.jks keypass=P@ssw0rd storetype=jks
GoDaddy offers a “SSL Installation Tool” that will remotely check to see if a publicly facing web server has its certificates properly installed.
At VMware’s VMworld 2011 conference in August, VMware announced the forthcoming release of VMware View 5. At the same time, thin client vendor Wyse made this announcement, saying that their thin client devices will have “Day One” support for VMware View 5 upon release:
SAN JOSE, Calif. – 08/30/2011 – Today at VMworld® 2011, Wyse Technology, the global leader in cloud client computing, announced support for VMware View™ 5 upon release. … Day One support for VMware View 5 validates the close technology partnership between the two companies.
Wyse hardware and software that support VMware View 5 include:
My beef is that VMware View 5 was released two weeks after the conference (VMware Announces General Availability of View 5 – View 5 in the House!) and yet, Wyse still has not provided a VMware View 5 client for their C50LE thin clients, which run the SUSE Linux OS that was specifically mentioned in their “Day One” press release.
When I called Wyse tech support, they explained that my confusion is that while VMware View 5 is available, the Linux-based thin client is not yet available. Once VMware provides Wyse a View 5 client for Linux, Wyse will make it available for its C50LE thin clients.
Fine. I think it was sleazy for Wyse to include the “Wyse-enhanced SUSE Linux thin client family” devices in their press release when they knew a VMware View 5 client wouldn’t be ready on “Day One,” but they are sticking to their position.
