RG032 – Guide to VDX Registry settings

By Max Ranzau

 

The purpose of this article is to provide a detailed overview of the registry settings for the VDX product. The initial set of registry keys are outlined in the VDX Guide which is included in the download, except for log trace information, which is in this article and available now in the RES KB. I took the opportunity to fiddle a bit with the general registry settings and provide you with some commentary.  All settings below are listed as valid from the 9.5.0 Release.

Note: All settings for VDX can be configure as policies in: HKLM or HKCU\SOFTWARE\Policies\RES\VDX Engine. Alternatively you can configure the registry settings directly in HKLM or HKCU\SOFTWARE\RES\VDX Engine.

There is also a policy template available when you install the VDX Admin kit, found as %programfiles%\RES Software\VDX Admin Pack\SupportFiles\VDXSettings.adm. The policy template included with the 9.5.0 can be viewed here. All the VDX settings shown below can be configure as policies in HKLM or HKCU\SOFTWARE\Policies\RES\VDX Engine. Alternatively you can configure the registry settings directly in HKLM or HKCU\SOFTWARE\RES\VDX Engine.

In the table below, the DT column is the DataType: DW is short for REG_DWORD and SZ is, well you guessed it: REG_SZ. The DV column is short Default Value. If you see “” here it means a blank value. Don’t put in quotation marks though.

Registry value name
DT DV My notes
LoadConfigFromRegistry DW 0 Load VDX settings from the registry instead of the configuration.xml file. This is the master switch for usage of all the settings below.
EnableClientStartMenu DW 1 0 = Do not bring the clients startmenu into the VDX engine window. Use this to only extend local apps launched prior to the remote connection
CustomClientStartMenuTitle SZ “” Changes the window title of the VDX engine window inside the remote session,
EnableClientDesktop DW 1 0 = Hides the contens of the client desktop from the VDX engine window inside the remote session.
CustomClientDesktopTitle SZ “” Changes the display name of the folder containing the client’s desktop contens.
ShowTrayIcon DW 1 Neither 0 or 1 doesn’t seem to have any effect in 9.5.0
IgnoreWorkspaceManager DW 0 1 = Ignores any RES Workspace Manager settings for VDX. If VDX is started through RES Workspace Manager, it will still use its own settings, licenses, etc. This option is only relevant when using VDX in combination with RES Workspace Manager.
DetectAlreadyRunningClientApps DW 2 0 = Already running apps won’t be extended into remote session.  Works sorta like the opposite of setting EnableClientStartmenu=0

1 = Yes. Need clarification in difference to setting the value below

2 = Autodetect.  forces
settings to adapt to the 3 display scenarios (single monitor vs dual monitors) as described on page 6 in the VDX guide.

HideClientTaskbar DW 2 0 = Never hide the local taskbar on the client

1 = Always hide it

2 = Autodetect according to the 3 display scenarios mentioned above. Note that single monitor mode seems not to hide the local taskbar. It is however obscured by the remote desktop.

EndClientAppsOnLogoff DW 0 1 = Local apps extended into the remote session are terminated when the remote session is logged off.
EnableVDX DW 1 Appears to be an on/off switch for VDX. Setting it to 0 doesn’t appear to have any effect at the moment in V9.5.0
NoVirtualZOrderClientAppList SZ “” Example prog1.exe|prog2.exe|progn.exe

This setting disables the Virtual Z-order for the process name(s) listed in this value. It excluded specified local processes from being clipped in the the remote session if remote windows are placed on top of them.  This wil forces classic  behavior known from Workspace Extendor and Susbscriber: Application entirely on top of remote session or remote session on top of application.

This  temporary remedy if you have a special application that VDX can’t handle until we can have a look at it.

IgnoredApplications SZ “” Example prog1.exe|prog2.exe|progn.exe

With this setting you can effectively prevent local apps from being extended into the remote desktop. The shortcut for the process will not even show up in the VDX menu of locally availalbe apps.

EnableClientAppShortcuts DW 1 Doesn’t seem to do anything if set in the registry and LoadConfigFromRegistry=1 The corresponding configuration.xml setting will enable/disable the shortcuts that you set up on the Configuration tab of the VDX editor.
EnableFileTypeRedirection DW 1 Doesn’t seem to do anything if set in the registry and LoadConfigFromRegistry=1 The corresponding configuration.xml setting will enable/disable filetype redirection from remote session to local client.
InstallationFolder SZ -> Default value is C:\Program Files\RES Software\VDX Engine. This value is set during installation. You shoudn’t need to change it.
force LogOff of disconnected sessions after timeout

As stated in the How VDX Works article, the configuration.xml file offers much more granular configuration options for the VDX engine. However if you would like to poke around the VDX Engine registry settings yourself, but dont want to start setting policies or creating the values from scratch, I’ve created a .reg export which you can import where you have the VDX engine installed. This one just contains the default values. Click here or on the registry icon to download.

Below is a brief overview of what registry settings affect what part of the VDX Engines GUI to the user

As you may have figured out by now, the client menu show above pops up when you hit the VDX system tray icon () in the remote session. This window is actually an extended application itself, running on the local computer where the VDX plugin is installed. That’s why it’s fast to initialize as there’s no icon data to shuffle across the wire into the remote session.

VDX Tracing

If for some reason things do not appear to be working the way they should, you can enable a Trace/Logging file for VDX, Just like you can with the other RES products. If you open a support ticket our Support Engineers will be very happy if you’ve attached a logfile initially, as it will help to pinpoint the issue. To configure the Trace file, create the following key in either HKLM or HKCU.

SOFTWARE\RES\LoggingOptions\Enable (REG_DWORD) = 1
SOFTWARE\RES\LoggingOptions\EnableFileLogs (REG_DWORD) = 1
SOFTWARE\RES\LoggingOptions\FileLogLocation (REG_SZ) = c:\some\folder

Note that if FileLogLocation is not specified, it will default to %temp%. For your convenience, here is a registry file you can cut n paste in and use your own environment. The reg settings can be created on both the VDX Engine machine and wherever the VDX Plugin is installed.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RES\LoggingOptions]
"EnableFileLogs"=dword:00000001
"Enable"=dword:00000001
"FileLogLocation"="C:\some\folder"

A couple of important notes on the path and log files.

  • Make sure that the user who logs into the remote session actually has permission on the folder you specify. Remember that the VDX Engine runs within the user’s session with that user’s credentials.
  • The name resulting logfile for the VDX Engine will be VDX_Engine_Log_s<sessionnumber> p<explorerPID> _yyyy_mm_dd_hhmmss.txt. Like this example VDX_ Engine_ Log_ s2p6744_ 2011-02-23_ 153522.txt. Since the current session number and ProcessID of explorer.exe is part of the filename, you will get a new logfile per session. This is an important changed from the classic Workspace Manager trace log which is cyclic and constant. On the right is a sample logfile, so you can see what it looks like.
  • On the client side, where the VDX Plugin is installed, you will find 2 logfiles, one for the VDXhelper and one for  the Plugin itself.  These two logfiles are named in a similar manner as described above. Look for VDXHelper_Log*.txt and VDX_Plugin_Log*.txt. On the right are a couple of examples of their contens.

No Comments

No comments yet.

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.