View Logon Scripts and Client Identification

One of my customers recently asked that I make the View client’s CD-Rom accessible to the virtual desktop through a PCoIP session.  While that is, strictly speaking, not possible, the customer was adamant.  After much discussion, I eventually determined to use a network drive mapping on the VDI Desktop to the Client machine’s CD-Rom.  This doesn’t allow the customer to listen to audio CDs, however it does allow the customer to copy files off of their CDs and generally perform work functions.  In order to accomplish this, I decided to use a simple logon script that would pull the client’s identification.

Some poking around on google pointed me at the %viewclient_ip_address% environment variable, so I wrote up a quick test script (after configuring a share for my client’s CD-Rom called “CD”) that added the drive mapping.  I executed it and it ran flawlessly, so I set that as a logon script and immediately forgot about it as I went on to work on other, more pressing requirements.  Several logons later, I realized that my E: drive (the network mapped client CD-Rom) wasn’t present.  I manually kicked off the logon script and, once again, it worked just fine.  Perplexed, I logged off and back on again… my script was still failing.

Checking rsop.msc (which displays the resultant set of all group policies for the user on the machine) revealed that my logon script was supposed to be executing.  For good measure, I checked  gpresult /r, which showed that the policy was being processed, not skipped.  Despite these promising indicators, the drive mapping was still failing.

Adding some quick msgbox debug code to the script revealed to me that, when run at logon, my %viewclient_ip_address% variable was not dereferencing to the client’s IP address and so I was attempting to literally map \\%viewclient_ip_address%\CD instead of my actual IP Address.  When running the script manually, my msgbox correctly showed the client’s IP Address.  After considering this for a bit, I decided that my script must be running a bit too swiftly, arriving at that code before the variable was being set.  I added a 30 second delay by using “wscript.sleep 30000” before my attempted drive mapping, but it didn’t resolve the issue.

That’s when I realized that my script’s access to environment variables must be as of time of execution, not on a line-by-line basis (maybe a Windows admin can confirm or refute that).  I did some basic research into methods of delaying the execution of a logon script, but most of the hits that I found were about problems with them being accidentally delayed or with them causing delays during logon.  As I was searching, I remembered that the Client information is stored in the registry, as well as in those environment variables, so as a form of triage I decided to test that approach.

The View Documentation lists all of the registry entries that contain client information.  As you can see, there’s a wealth of potential information there.  I changed my logon script to read in the appropriate registry key and the manual execution worked.  Logging out and back in again revealed that it worked on logon as well!  So, that lesson is learned.  When creating logon scripts that depend on Client information, just read the registry instead of using the environment variables.

Here’s the pertinent lines from the script, in case anyone wants to see how I did any of it.

Set objShell = CreateObject("WScript.Shell")
Set objNetwork = CreateObject("Wscript.Network")
Dim strRemotePath
…
objNetwork.RemoveNetworkDrive "E:"
WScript.sleep 1000
'creates the path to the client's CD Share based on the registry
strRemotePath = "\\" & objShell.RegRead("HKEY_CURRENT_USER\Volatile Environment\ViewClient_IP_Address") & "\CD"
if bTroubleFlag then
    msgbox "Mapping: " & strRemotePath
end if
objNetwork.MapNetworkDrive "E:", strRemotePath