RES Workspace Manager Zones and USB Devices

Have you ever had a requirement to base a Device Zone within RES Workspace Manager on a particular hardware device? If so, you may have already discovered that if is a storage based device then you’re good to go. However, if it’s not of a “removable storage” type then we’re seemingly out of luck. Not quite..

Whilst on a customer site, a requirement arose that necessitated that we detect whether a particular USB device was connected or not so that we could configure an application for the hardware device. After a lot of digging and searching, I discovered that device information is located in the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\ENUM] registry subkey(s). The problem with these registry entries is that if the device has ever been connected then it will exist and it doesn’t indicate that the device is currently connected so it’s back to the drawing board..

On further investigation, the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\Services] key lists all the currently connected devices (all internal devices are listed in here so don’t be too surprised how many there are!). The difficult bit comes in determining how your USB device is enumerated. As a general rule all USB devices attached will probably be listed under keys beginning with USB. For example, the USB microphone I’m using is listed under the ..\Services\USBAudio subkey and a USB printer under the ..\Services\USBPrint subkey (more detail on hunting this information down might be a future blog post). In this instance I’m going to pick on the Samson C03U microphone and show you how can create a Device Zone in RES Workspace Manager that will allow you to set configurations options only when it’s connected. Looking in the registry in the [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Serices\USBAudio\Enum] key exposes the following settings:

I know that my microphone is identified as USB\VID_17A0&PID_0100&MI_00\6&1895ccd4&0&0000. We can see that the Samson microphone is listed in here. When the device is unplugged the instance disappears like so:

So to create our Device Zone in RES Workspace Manager for detecting the presence of a Samson microphone all we need to is create a zone based on the presence of this particular registry setting? Nearly! By creating a zone on the information from the first screenshot, it will only be true for the microphone on my desk, not any Samson C03U mike that might be on someone else’s desk. Experience has shown that everything listed after the ‘&MI_00\6&’ is device specific, i.e. a serial number or unique identifer and can safely be ignored (unless you want to tie the zone to a unique device). Therefore, if we create a Zone based on the presence of the ‘USB\VID_17A0&PID_0100&MI_00&6*’ (note the wildcard) value it should work for all Samson C03U microphones.

Done? Almost (and you knew I was going to say that!). The value of ‘0’ (zero) in the first screenshot depicts the order in which a device is attached. Therefore, if I just so happened to have another USB audio device, the Samson mike might be listed as the second device under ‘1’ or the third device under ‘2’ etc. In order to ensure that we account for this we need to add multiple entries in like so:

If I had 4 USB audio devices, then depending on the order they were attached my Zone may fail to detect that the Samson microphone was attached. I could have added 10 or so entries but hopefully you get the idea! If you have varying models of devices, then it’s likely that the PID_ (product ID) portion of the values will change. In this case, you’ll need to make sure the rules also incorporate any variations.

It would be nice to have pattern matching on the registry keys\values like we have within RES Automation Manager. Perhaps it’s an enhancement request, but in all honesty, why can’t we natively select any hardware devices attached rather than being restricted to USB storage devices already? Perhaps I’ll take this up with product management.

Good luck! Iain

RES Workspace Manager Registry Import Bug

[UPDATE 01/08/2011 – RES have released a fixpack for RES Workspace Manager 2011 SR1 that resolves the issues highlighted in this post. I don’t have any word on whether this fix will be rolled into the next Service Release of RES PowerFuse 2010 (SR5?). I hope so as we can then remove this post. In the meantime, please contact RES Software support to obtain this fix (assuming you’re running WM 2011 SR1!)]

An issue has been discovered in RES Workspace Manager 2011 and earlier versions (e.g. PowerFuse) when importing .REG files. Ironically, this was discovered when converting existing Group Policy Objects via the Virtual Engine Toolkit (VET). RES Workspace Manager does not implement the removal/deletion of registry keys or values correctly. It has been reported to RES Software and they have acknowledged there is an issue. It is not an issue with the Virtual Engine Toolkit but a problem with any .REG file, i.e. one’s migrated from log on scripts etc. [UPDATE – for clarification purposes, a support ticket had been raised prior to this post and RES are working on a fix.]

The following snippet from a REG file (some entries removed for clarity) should toggle the removal of NoInternetIcon and NoNetHood values and also toggle the removal of the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key.

Windows Registry Editor Version 5.00;
Created by the Virtual Engine Toolkit v0.9.7.0;
Creation date: 05-30-2011 17:04:08

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
“DisablePersonalDirChange”=dword:00000001
“NoDesktopCleanupWizard”=dword:00000001
“NoInternetIcon”=-
“NoNetHood”=-

-[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders]

What actually happens is RES Workspace Manager sets the two DWORD vales to 1 and doesn’t even import the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key as shown below. This results in complete unexpected behaviour and might impact any Proof of Concept or pilot deployments.

Hopefully this issue will get resolved promptly but in the meantime, please be vigil!

Iain