posts

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.

Windows 7 SCCM 16 Pre-Provision Bitlocker winload.exe 0xc0210000 error

Last monday we upgraded our SCCM environment from 2012R2 to 1610. Earlier we did the same upgrade in our test environment and didn’t have any problems at all. Unfortunately, our test environment only has one active laptop, and we never thought to test the task sequence on this laptop.

After the production upgrade we found that all task sequences worked without issues, except for our laptops: after the step “Pre-Provision Bitlocker” our windows image is loaded and windows setup should start, only it doesn’t. It throws an error saying something like this:

The operating system couldn’t be loaded because the Bitlocker key required to unlock the volume wasn’t loaded correctly.

Being a lazy admin, I googled the symptoms and of course I wasn’t the first one to get this error. In short, with the upgrade of SCCM we also upgraded ADK from 8.1 to 10. Since ADK10, Microsoft has increased the default encryption level that’s used for bitlocker. Since Windows 7 does not support this level, the setup fails.

Probably the best write-up about this issue can be found on the Configuration Manager OSD Support Team Blog.

You will find that the resolution seems simple: add a registry key just before the Pre-Provision Bitlocker step, and the encryption level should be compatible with Windows 7. Of course this didn’t work. Well it did, but created another problem. The error message disappeared, but now we cancelled the Windows setup after a couple of hours, as it was still installing devices.

The encryption method that is recommended by the blogpost mentioned earlier, is AES_128, set by the following command:

reg.exe add HKLM\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethod /t REG_DWORD /d 3 /f

I found an article, closed it and forgot where it was, but I found a reference somewhere that for Windows 7, the default encryption level was AES_128_WITH_DIFFUSER, which registry value is 1. So we tried that and lo and behold: it works.

So if you’re experiencing these issues and tried the value of 3, try a value of 1. Or upgrade to Windows 10 CB.

We used this:
reg.exe add HKLM\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethod /t REG_DWORD /d 1 /f

VMWare Horizon View Client: Disable Client Drive Redirection

TL;DR:

[HKEY_LOCAL_MACHINE\Software\Policies\VMware, Inc.\VMware VDM\Client]
“DisableSharing”=”true”

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]
“DisableSharing”=”true”

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]
“DisableSharing”=”true”