I briefly considered calling this article The Mother of All RES Environment Variable Guides, but it has to fit on one line above ;) Anyway this is a spinoff article of the old RG006 article which covered both environment variables, tags and functions in RES Workspace Manager That article is close to 3 years old and a bit of a mess due to the many updates since then. Rather I figured it would be better to start over with a clean slate and do the environment variables by themselves. At this point in time, there are many interesting variables and functions both within RES Workspace Manager and Windows itself. These may come in very handy when you’re building a managed workspace around a desktop and/or a published application. I’m planning on doing a separate article on the functions later.
Besides that, I wanted to share with you a set of homebrew tools which may become handy when you are busy building an environment or perhaps modifying or debugging an existing one. Perhaps one time or another you stop and think to yourself; “man, it would be nice if I could see what the variables available in the user’s session contain”. Obviously you can get some of it using a SET command in a Command Prompt, but we don’t necessarily want to give the users that, do we now? Using black magic (and a pinch of notifications), I’ve created some useful tools for you. All you have to do is import the buildingblocks which contain a few managed apps, and make them available for the target users. The apps when run do nothing besides show a notification window that shows the contens of the available variables. See further down after the variable guides or jump.
RES Workspace Manager environment variables
First up, let’s start with an updated list of RES Specific environment variables per end of May 2013 for Workspace Manager 2012 SR2 (22.214.171.124). Note that even though all variables are specified in CAPS, Workspace Manager is not case sensitive to environment variables:
|RES variable name
|Returns the IP address of the Client. If this is a workstation (physical or VDI, it returns the same IP address as an IPCONFIG command would. If you are on a RDS/XA environment it will return the IP address of the connected client device.|
|%CLIENTNAME%||Works similar to the %CLIENTIPADDRESS% variable, but just returns the device/hostname instead. This is an advantage to use over the regular system variable %COMPUTERNAME%, as on a RDS/XA environment this would always return the name of the server.|
|%DESKPIC%||Use this variable to dynamically specify a desktop wallpaper or logo for given ou’s, groups, etc of your choice. In order for Workspace Manager to use the value in the variable, see the RESpedia entry for more info. NOTE: This variable does not exist per default. You must create it yourself, if needed.|
|%FULLUSERNAME%||Returns the displayname of the user. See RESpedia entry for further details.|
|%LCID%||Returns the current Microsoft LoCaleID (US English=1033 etc) For a full list of these, see MSDN. Also check out the detailed use case for the %LCID% variable here.|
|%LOADEDAPPSUP%||An internal reference to already loaded UserSettings. Not a reference to a GUID, but some sort of internal counter. In short, it’s for internal use and you can’t really use it for anything.|
|%PFAPPID%||The Application ID of the current application. Only applicable for RES managed RDS/XA published applications. The variable will be blank if you query it within a desktop OS session.|
|%PFSESSIONSTART%||Contains the timestamp for when the current WM managed session was started. The timestamp is formatted as YYYYMMDD-HHMMSS|
|%PUBLISHEDAPPNAME%||Name of the RDS/XA published application that started this session. The variable will be blank if you query it within a desktop OS session.|
Contains a reference to the HLM registry, which points to the current slot in the Access Balancing queue. This is an internal usage variable and you probably can’t use it for anything.
This variable is news to me as I have not seen it myself yet. Rather than speculate on the purpose and usage, I’ve asked my colleagues for clarification. Expect an update when I know more.
Same as above
Same as above
Contains the local folderpath on the computer where the cached Custom Resources are located.
Points to the drive letter which RES Workspace Manager has detected or configured as the user’s homedrive under Composition|Actions by type|Files and Folders|Home directory.
Ponts to the installation folder for RES Workspace Manager. See RESpedia entry for more info.
Indicates what shell is currently being used. If value is MS then Microsoft Explorer is active. If value is PF then the old RES custom shell is being used. The shell can be changed under Composition|Desktop|Shell.
This variable is identical in operation to %DESKPIC% except it specifies the picture image to be used for the old built-in static screensaver.
Holds the SID of the current user. No scripting necessary!
The above covers the RES environment variables that I am aware of at the moment. Note: The RES variables above are not to be confused with the substitution tags available within UserSettings, running in Capture-Targeted mode. Those tags (such as %FAVORITES% and %COOKIES% for example), represent a given path in the profile to pick up files from. Mentioned tags are NOT environment variables. While I’ll do my best to keep things up to date, if you do note something as missing above, please comment on this article.
The following are variables found in plain vanilla Windows. Even though you may be familiar with most of these already, I suggest you glance through it anyway as the table below contains some useful RES specific info as well. The System environment variables are included here as they can be referenced like the RES variables above, pretty much from anywhere within the Workspace Manager. Also remember you can check the contents of any environment variable for a specific or partial string within any variable using the Environment Variable Zone Rule combined with Pattern Matching. Note: The list below is not exhaustive. If there are other Windows specific environment variables that you feel are missing, let me know in the commentary below.
|Windows variable name
Points to where the common user profile is to be found. Note: . On Vista and up this variable usually points to: C:\ProgramData
|%APPDATA%||Contains the full path to the Application Data directory of the logged-in user. Note: In Workspace Manager you can pull this path with the $UserShellFolder(appdata) function. The variable usually points to: C:\Users\<username>\AppData\Roaming|
|%COMMONPROGRAMFILES%||Vendors use this folder to store components they may wish to share between their own applications. Usually points to: C:\Program Files\Common Files|
NETBIOS name of the workstation or terminal server you are logged in on. In a VDI environment this may be dynamically generated.
|%COMSPEC%||Returns full path to the command processor. On NT and newer operating systems it usually points to: C:\Windows\system32\cmd.exe|
There is hardly any info available about this variable. It’s typical value is NO, and is referenced by FP4AUTL.DLL, which identifies itself as “Microsoft FrontPage Utility DLL”. It appears to be installed as part of the support for FrontPage or Front 2000 Server Extensions.
In short, nothing to see here. Move along.
Returns drive letter which is mapped to the user’s home directory. The driveletter is defined in the user’s account properties (profile tab) in AD. The variable is set by WINLOGON.exe during logon, based on the value of the home directory field in AD:
Similar to %HOMEDRIVE% it returns the path part of the user’s home directory, as defined in the user’s account properties within AD. The %HOMEPATH% environment variable is based on the value of the home directory. If the home directory is a UNC, this variable will will return the path (example: “\<path>”) to the user’s home directory using the mapped drives as a root. IF the home directory uses a local path, it will return the drive letter of that local path
Note: In regards to the two above variables. If you prefer to have WM map the homedrive instead of AD (so you get it logged and all that) you should take care of setting both %HOMEDRIVE% and %HOMEDRIVE% via Composition|Actions by type|Environment variables. Things may go bump in the night if you don’t…
|%HOMESHARE%||Returns the network UNC path to the user’s home directory. Note: Usually only appears on Server OS’s. This variable is set based on the value of the users AD account properties on the profile tab. This variable will typically contain something like \\server\share$\<username>.|
|%LOGONSERVER%||Indicates which domain controller authenticated the client’s logon request.|
How many CPU’s (or cores) are visible to the OS. This doesn’t have a default value. The value depends on the number of physical CPUs installed combined with any Hyper-Threading features enabled.Note: There is a Number of Processors Zone rule in WM for this as well, which you may be better off using.
This variable is pretty much useless as the value has been WIN_NT since Odin knows when. If you want to precisely determine the current operating system, WM has Zone Rules for both OS bitversion and major version – For example: XP, Vista, Win7+8 and Server versions)
A list of folders for the OS to search for binaries and DLL’s. Some vendors (yes, you know who you are) go nuts and add two miles of path string here.
Note: I’ve seen some customers use a Registry zone rule + Pattern Matching to determine from within WM if some dicey software is installed by, looking at this variable.
Contains a list of the filetype extensions which the OS considers to be executable. When executing a command line that does not contain an extension, the command interpreter (cmd.exe) uses the value of this variable to determine which extensions to look for and in what order. Typicall contains something like this: .COM;.EXE;.BAT;.CMD;.VBS;.VBE; etc...
Note: If you have a good use case for querying or tinkering with this, let me know as I’ve got nothing.
Indicates the chip architecture of the CPU(s). Typical Values: x86, IA64. In the old days you could see this thing return MIPS or ALPHA as well.
Note: WM has a Processor Architecture Zone Rule for checking x86 vs. x64.
|%PROCESSOR_IDENTIFIER%||Contains a description of the CPU(s), for example: “x86 Family 6 Model 30 Stepping 5, GenuineIntel”. This variable doesn’t have default value. The value depends on the CPU installed.|
Contains a number that indicates model number of the CPU installed in the computer, including x86 = 3,4,5 and higher. (Legacy: Alpha = 21064; and MIPS = 3000 or 4000)
Note: WM has a Processor Family Zone rule for this purpose, however it hasn’t been updated in ages: It only supports checking Pentium II or less, Pentium III or Pentium 4 or higher.
Returns the revision number of the CPU. This is usually a 4 digit hex number.
Note: Someone once told me they used this to determine if they were running inside a virtual machine. I have no idea if that works, but I thought I’d pass it on.
|%PROFILEPATH%||This is different %USERPROFILE% as it holds the path to the Terminal Server profile path, specified in AD. I could be wrong about it, but it’s what Google and the voices in my head tell me…
|%PROGRAMDATA%||Points to C:\ProgramData per default. Not sure what the overall purpose is except perhaps helping the OS find specific stuff.|
Points to C:\Program Files. Same as above.
Note: For the two above variables %PROGRAMFILES% and %PROGRAMDATA% it’s considered a good practice to use these environment variables when defining managed applications. The proper variables can automatically be inserted into a managed app’s command line field just by rightclicking on it.
Stores the paths to the locations of the Windows PowerShell modules that are installed on disk. PowerShell uses this variable to locate modules when the user does not specify the full path to a module. The paths in this variable are searched in the order in which they appear.
Note: On older OS’s like XP and 2003 this variable only exists after PowerShell is installed on top of the OS.
Points to C:\Users\Public per default. The shared media folders (videos, pictures, music, downloads etc) of Windows 7 lives in %PUBLIC%
This is the name of the current session. If you log on to the console of a RDS/XA server or a regular workstation OS, the variable contains the name Console. Alternatively if you log on to a RDS/XA server, the name will be the port listener name of the server, a hashmark (#) followed by the connection. For example RDS: RDP-tcp#01 or on Citrix: ICA-tcp#01.
Note1: WM has several Zone Rules for detecting client name, client type, session type, and portlistener name.
Note2: If you are specifically interested in the sessionnumer, you could consider using the RES WM function $Endstring(%SESSIONNAME%,2) to retrieve the last two digits.
|%SYSTEMDRIVE%||Points to the driveletter where the \Windows folder is to be found. Is usually C: Note: This variable is sometimes used as part of the command line for managed apps in WM, like %PROGRAMFILES%|
|%SYSTEMROOT%||Points to C:\Windows per default. Can be used the same way as %SYSTEMDRIVE% and %PROGRAMFILES%|
|%TEMP%||Points to the user’s own Temp directory in his profile. Default is C:\Users\<username>\AppData\Local\Temp.|
|%TMP%||Same as above. Note: The reason why there is both a TMP and a TEMP allegedly goes back to the good old DOS days, where there were no standards for a temporary folder (or hardly anything else for that matter). Some programs used TEMP, others TMP. To this day both are kept for compatibility.|
|%USERDNSDOMAIN%||Contains the FQDN of the computer, such as in my case: DEMO.LAB Use case: This variable can be used together with some of of the functions in WM to generate a valid email address. See this example.|
|%USERDOMAIN%||Contains the NETBIOS domain name.|
|%USERNAME%||Contains the users logon name AKA samid. In WM we often see this being used as parts of user specific paths, but hardly ever a query as one can specify individual users in Access Control.|
|%USERPROFILE%||Path to the user’s locally stored active profile for this session. Typically contains C:\Users\<username>|
|%WINDIR||Another compatibility variable. Is identical to %SYSTEMROOT in contens and function.|
Note: The following hidden system variables are NOT supported by Workspace Manager 2012 SP2:
As mentioned above, I’ve put together a couple of small diagnostic tools that might help you when building a RES WM environment. They simply use a notify box to respectively display the current value of the RES Specific variables and the Windows system variables.
As far as Access Control goes, you probably do not want to give this app out permanently to every Tom, Dick and Harry among your users. However, you probably may want to give them tempoarily to certain users who you are trying to troubleshoot. You could of course grant them manually by changing access control on the app, or perhaps use a USB key as a security token or perhaps even grant tempoary access via the IT Service Store. There are many options available.
Below I’ve created WM buildingblocks of the Environment Variable diagnostic tools. There are more to come so stay tuned for further articles.