vdi

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.

Powershell: Force full update of Root CA store

By default, Windows comes only with a small set of Root CA’s in the trusted Root CA store. These are enough to get you started, but as soon as you visit a website that uses HTTPS and the Root CA that has issued the certificate is not in your trusted Root CA list, the Root CA certificate is downloaded from Windows Update.

Generally, this is a good solution, as long as your clients can reach Windows Update to start with and they aren’t non-persistent VDI clients.

Currently, we are noticing that Internet Explorer sometimes hangs for a few seconds and then continues. At the same time, an event is logged ( CAPI2 4097 ) telling you that the Root CA has been updated. Again, this works fine on persitent VDI’s, laptops, desktops and servers. On a non-persistent VDI however, this process is repeated for every CA on every session for every user. Not so nice.

Currently, we are still testing what yields the best results. I’ve written the script below, which creates a directory on the C:\ disk, downloads all root CA’s from Windows Update into this directory and then imports every .crt in the Root CA store, then removes the directory. I’ve imported this script into RES Workspace and is being run during logon. As it’s run in the background there is no noticable delay in logon time, and after logon, about 380 CA’s (we have some internal and private CA’s added as well) are visible in the certificate manager.

You could consider adding this as a step in your SCCM task sequence or however you create your VDI image, so it’s not performed during logon. However, this means that CA’s that are added later will have to be downloaded on demand, and also CA’s that are revoked or updated after you’ve made your image will have to be updated on demand as well.

md C:\Certs
certutil -syncwithWU C:\Certs
$files = Get-ChildItem -Path 'C:\certs\*' -Include '*.crt'
Foreach ($file in $files) {
$importfile = "$file"
certutil -addstore -f Root "$importfile"
write-host $importfile
}
rd c:\certs -Recurse

Update: Oh yea! As you can see, i’m using Certutil to import the certificates. That’s because my current customer is still running Windows 7. When you’re on Windows 8/2012 and higher, you should ofcourse use the PS commandlet “Import-Certificate”, together with the appropriate config ofcourse.

Powershell: Check and Toggle Numlock during logon

This is one that comes up anywhere, especially in VDI/RDS-type environments: Numlock.

In my experience there are no real good ways of controlling this without scripts, too many variables, as the final state of numlock depends on the state on the client computer, the VM and whatever settings are in the user profile.

The powershell script below first checks for the state of the numlock key: If ([console]::NumberLock -eq $False), and when False, proceeds to send the command to toggle it, turning it on.

Script:

If ([console]::NumberLock -eq $False) {
$wsh = New-Object -ComObject WScript.Shell
$wsh.SendKeys('{NUMLOCK}')}