Unable to aquire license for RES/Ivanti VDX in a Workspace Manager Integrated scenario.

Scenario: A fatclient/desktop with Windows 10, RES VDX 10.1 Plugin, Ivanti (RES) Workspace Control 10.2.500 and the VMWare Horizon 4.5.0 client installed. Connecting to a Windows 10 VMWare Horizon 7 VDI that runs RES VDX 10.1 Agent and Ivanti (RES) Workspace Control 10.2.500. There is no RES VDX licensing server available, but the RES VDX licenses are available from within the Workspace Manager database. VDX works, but after some time a message appears that the grace period for VDX has expired, and VDX stops working.

When you check the VDX agent on the VDI, you see that it hasn’t been able to aquire a license for VDX.

In our case, we’re running an extensive script to optimise our VDI. This script has been scavenged from several sources like the VMware OS Optimization Tool and some blogs. Somewhere along the road, we decided that most of the tweaks we do for our VDI, could benefit the fatclient/desktops as well, so during the build of these systems, the script will run as well. Of course we’ve re-enabled or disabled stuff that is obviously needed for a system with spindles, like the disk defragmenter service, but most tweaks we were happy to run on these systems.

Since VDX wouldn’t aquire a license, the first thing we did, was blame RES. When that didn’t work, we started looking for other culprits. We found quite soon that our old Windows 7 fatclients could successfully aquire a VDX license when connecting to the Windows 10 VDI, so since the effect of our script on the fatclients/desktops wasn’t really known, i decided to turn it off, and tested again; VDX could aquire a license in the new scenario.

As the script was over 200 lines long, it took some guesswork to find out the culprit, but by a stroke of good guesswork, we found the fault:

DisableTaskOffload was set to 1. This was done, probably, because using offloading for networktraffic, requires a physical networkcard. No problem for our VDI, but it appears that either RES VDX uses this function somehow, or when a pshysical NIC is actually present, Windows 10 requires task offloading to work. Anyway, removing the registry value altogether on the fatclient fixed our issues. We decided to remove it for all platforms: let Windows figure this one out.

VMWare Horizon View Client: Disable Client Drive Redirection


[HKEY_LOCAL_MACHINE\Software\Policies\VMware, Inc.\VMware VDM\Client]

VMWare has been tinkering with the name, version, function and anything other they can come up with for a while now. For example, we’ve upgraded the VMWare View Client version 5.x to VMWare Horizon Client 4.3.0 recently, i think. I get that the name “view” is disappearing from the product, but why they are **** around with versionnumbers is beyond me.

Anyway, since VMWare Horizon View 6.x the function “Client Drive Redirection” has been added, which lets you redirect local client drives and folders to your View/Horizon/whatever session. This function, frankly, is useless and I don’t want it. We use a UPM tool (RES) to map networkdrives and have USB redirection enabled. Client Drive Redirection only presents a security risk, as it seems to ignore drive restriction policies. For example, by default, the View client on our thin clients shows the “share drive” option, giving the user access to the local drive of the thinclient that they are using. They can’t do real damage because of the write-filter ofcourse, but I just dont want it.

Since the 4.x clients for VMWare Horizon. (which has VMWare-view.exe as executable.. thanks VMWare), it seems that we’ve lost all control of which components we can install: Client Drive Redirection becomes mandatory.

Searching the net, i’ve found the following registry setting: HKLM\Software\VMware, Inc.\VMware TSDR\disabled=true

Unfortunately, this seems to be an agent setting, which doesn’t remove the sharing option from the client itself.

Fortunatly, since client version 4.3.0, the people at VMWare have seen fit to supply us with an option to disable the whole option. See table 3-7 of “Using VMware Horizon Client for Windows Horizon Client 4.3”

If you open the PDF, you will find the mention of “Disable sharing files and folders” in table 3-7, and also see that this is a “User Configuration setting”.

Well, **** VMWare.

First of all, i’m configuring thin clients, which won’t be member of our Active Directory domain, so AD GPO’s are out.
Local Group policy would work, but cannot be configured programmatically, from for example, a SCCM or MDT task sequence.

As a test i’ve enabled the policy on a testing system, and found that the following registry keys and values had been created:

[HKEY_CURRENT_USER\Software\Policies\VMware, Inc.\VMware VDM\Client]

Because i’m stubborn, i tried creating the same keys and values on a system that doesn’t have the ADM-templates loaded, and also, changed HKCU to HKLM, and what do you know: IT WORKS.

So, if you are like me and only need a simple registry setting for the local machine, put the following in your installscript, and go enjoy the weekend:

[HKEY_LOCAL_MACHINE\Software\Policies\VMware, Inc.\VMware VDM\Client]