windows

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”

Windows Driver Installation: Searching Windows Update..

PolicyBy default, when you plug in a USB device, Windows will search Windows Update for the latest drivers. While this might be a fantastic solution for your home computer, it’s useless in an organization, because usually Windows Update is blocked so it will sit for about 5 minutes searching, until it times out and uses the locally available driver or tell you that you need to go get some drivers yourself.

So, lazy admin as you are, you fire up Google, and find a policy:

Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings\Turn off Windows Update device driver searching.

Well.. wrong. This policy has been deprecated and will only work up to Vista. For some reason the new policy has had very little coverage on the web, so it took some time to find it.

The new policy, which you should use with Windows 7 or later, can be found at:

Computer Configuration\Administrative Templates\System\Device Installation\Specify Search Order for device driver source locations

Select the option “Do not search Windows Update” and you’re gold.

First of many: excellent SCCM Variables

Every now and then you think “wouldn’t that be a nice feature”. You fire up Google, spend some time browsing the net, end up looking at pictures of kittens and then finally somewhere deep down an archived website build in the late nineties you find what you’re looking for.

These are two features that I needed when working on SCCM task sequences. My first problem was that we had some tasks that couldn’t be part of the task sequence it self, but had to be available immediately after running the task sequence. The folks at Microsoft thought about this, and created the SMSTSPostAction variable. I won’t bore you with the actual implementation of the variable, so here’s the short version: define the variable at your favorite place (somewhere in the TS itself or as a variable on your collection), set the value to be the task that you want to be processed at the end of the TS. For example, “gpupdate /force /boot” or “c:/temp/postosdscripts.bat”. After running a deployment, you will see in your SMSTS.log that your value is the last task that is executed. This occurs after the SCCM client has been taken out of provisioning mode.

My second problem was.. well, forgetful onsite support colleagues. Every once in a while, your SCCM deployment will fail. An error message is displayed for 15 minutes after which the system will reboot and, depending on where it fails, will show a CTRL+ALT+DEL login screen. This might be just the old OS in case of preinstalled systems or redeployments, or the new OS without the rest of your TS. Originally, we tried to solve this issue by setting the background of the computer to “Deployment Successful” when it was successful. The onsite support guys know this, but still occasionally give uses a half-deployed system and then complain that OSD isn’t working as it should. So, to fix this, I decided that the task sequence error message should stay indefinitely. Again, there’s a TS variable for that! SMSTSErrorDialogTimeout. Again, add this to your deployment and decide on your value. 0 is forever(-enough), the rest is the time in seconds. Personally, I cannot think of a reason the error message should ever disappear without user interaction, but that might be me.

Any additions?