One of the challenges I have been dealing with recently specifically in educational establishments is how can we get location based scripts to work inside a View desktop. A number of these types of establishments already have complex login scripts to map printers, shares etc based upon the location of the desktop you are logging into. View adds a layer of complexity to these components especially one you want one desktop, e.g. staff and students. In the physical world the login scripts will look at the name of the desktops and map the resources / make the changes as required. We obviously can’t do this easily in the virtual world with a signal desktop model.
Now there are ways around this such as the ThinPrint location based printing and third party software such as RES or AppSense for persona management. But that doesn’t stop us wanting to create customised solutions based around each customers individual requirements or trying to safe some money when we already have sufficient profile redirection etc in place.
The good news with a bit of playing it is still possible, when you log into a View Desktop the View Agent populates a number of registry entries with some key information, for example see the screenshot below.
These registry settings are held in HKEY_CURRENT_USER>VOLATILE ENVIROMENT and they all will start with ViewClient, from this information we can see the IP address I am connecting from, the broker URL, the username for which I am logged into my client with, the name of the client and the type of client that I am using. So straight away from the above information we can see that I am connecting in from my Mac, from an external IP.
The next stage is to harness this information to create some location based scripts. I have only just started playing with this but there are a number of ways to do this, at the moment I am concentrating on VBS scripts as a number of customers are already utilising VBS. We could easily use Powershell to query this information but that wouldn’t be ideal for a login script situation.
Now I will start this with a caveat, I am by no means a VBS expert and the code below is something I have hacked together for an example.
This script looks in the registry for the ViewClient_MachineName registry key and displays the contents of the machine you are connecting from on the View Desktop
Option ExplicitDim WshShell, ClientName, objFSO
Set WshShell = WScript.CreateObject(“WScript.Shell”)Set objFSO = CreateObject(“Scripting.FileSystemObject”)
ClientName = WshShell.RegRead(“HKCU\Volatile Environment\ViewClient_Machine_Name”)MsgBox ClientName
When the user connects in with the script above running as a logon script they get the following message on the screen
Now by itself that is little use, but could easily be expanded to look if the IP is internal or external and display a company policy message or support message for external users.
With the script below I have expanded it to detect if the user is connecting from a client (Thin Client or PC) in the art department of the science department, it will then map the correct R: drive resource share for the specific department.
Option Explicit
Dim WshShell, ClientName, objFSO, objNetwork
On Error Resume Next
Set WshShell = WScript.CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objNetwork = CreateObject(“WScript.Network”)
‘Set the Clientname variable to look at the view registry entry
ClientName = WshShell.RegRead(“HKCU\Volatile Environment\ViewClient_Machine_Name”)
‘Disconnect the mapped drive if it exists to stop problems later
objNetwork.RemoveNetworkDrive “R:”, True, True
wscript.sleep 300
‘Map the Art drive if the client name contains art
If Instr(1, ClientName, “art”) > 0 Then
objNetwork.MapNetworkDrive “R:” , “\\file1\cwptemp\Art”
End If
‘Map the Science drive if the client name contains Science
If Instr(1, ClientName, “science”) > 0 Then
objNetwork.MapNetworkDrive “R:” , “\\file1\cwptemp\Science”
End If
The possibilities are endless with this and really comes down to your imagination for what you could create to customise a users environment based upon those parameters. One other possibility with this would be to start collecting the client type information so you can start to understand what end devices your users are connecting from. This would help significantly when it comes down to support and updates.
I would really like to hear from people that are using scripts like this or are intending to after reading this and how you intend to be using it.
I will update my blog with more use cases when I can.
Virtualised Reality 
Nice post Barry.
It would be cool to a script to detect if you come from a iPad and then it would start an alternate shell that is better suited for the iPad. This one for example: http://www.thinix.com/product.asp?p=77CBCF22-6278-4F8B-8964-C7B2CFED3A1D
// Joel
Cool idea, just had a play, if you install Thinix in your virtual desktop, configure to run in application mode. Then use this script below in your login script it should work. The ClientType value of iPhone comes from Wyse Pocket Cloud on iPad or iPhone.
Option Explicit
Dim WshShell, ClientName, objFSO, ClientType
‘On Error Resume Next
Sub Run(ByVal sFile)
Dim shell
Set shell = CreateObject(“WScript.Shell”)
shell.Run Chr(34) & sFile & Chr(34), 1, false
Set shell = Nothing
End Sub
Set WshShell = WScript.CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
‘Set the Clientname variable to look at the view registry entry
ClientType = WshShell.RegRead(“HKCU\Volatile Environment\ViewClient_Type”)
‘Start Thinix if connected from iPhone or iPad
If Instr(1, ClientType, “iPhone”) > 0 Then
run “C:\Program Files\Thinix\Thinix Touch\ThinixTouch.exe”
End If
It is strange that these variables are not accessible in windows using a simple %variablname%. For example if I go Start-Run and type %ViewClient_Machine_Name%, it won’t read the variable value, as it would do if I’d put something like %sessionname% (variable in the same Key), which will return the value that is populated inside that variable.
As I read on websites, it seems to be some kind of a bug or something in that sense.
I have succeeded in making these values readable only if I add my own user environment variable that is of the same name as the variables in the Volatile Environment. Though, the whole point of variables being in the Environment is the ability to read those values just by specifying the variable names. Using VBScripts you can access any registry key you want and read its value – howerver that is not the purpose of Environment variables. Mind you that logon scripts do make logon times longer.
I cannot map drives with the help of GP Preferences client side extensions, which are supposed to map drives much faster, using the specific variables that begin with ViewClient. If only VMware could shed light on this subject, our lives might be even simpler.