To solve this, rather than chase down the specific layer causing the problem, put in a special registry entry that will prevent Unidesk from honoring the device deletion.

Connection broker agents generally provide software-only audio and USB redirection devices to facilitate interaction with the end-user client machine.  In VMware View, for instance, it provides its own virtual USB hub device, and Teradici audio driver.  Unlike other devices, which have some kind of concept of plugging the physical device in, these software-only devices exist entirely in the registry and their software drivers.

When Windows boots with these virtual devices present, their existence is captured in the device database.  However, if Windows later boots without the broker agent software available, then Windows will recognize that the drivers are missing, and will uninstall the virtual device.

In Unidesk, this can happen under two circumstances: if you have a desktop that includes the broker agent layer, and then you edit the desktop to remove the broker agent; or if you have an application layer that was created (or edited) with the broker agent as a prerequisite, and later edited again without the broker agent as a prerequisite.  You can also induce this if your broker agent was initially in the OS layer, and you later choose to uninstall it from there and create a separate agent layer. Then every layer was effectively created with the broker agent as a prerequisite, but the later edit happened without the agent software present.

In both cases, the desktop or the layer winds up recording the un-installation of the device.  If you look in the Device Manager in Windows, the entire device class is missing,  With a physical device, these come back as soon as you plug the device back in.  But since these devices have no physical existence, normally the only way to get them back is to reinstall the driver software.  But in Unidesk, you don't want to do that in a desktop either, so you have devices that have disappeared completely from Windows that you cannot resurrect with layering operations.

But rather than try to chase down the offending layer, or try to surgically repair the damaged desktop, we've made a mechanism for us to just ignore the record of deleting the devices, effectively resurrecting them.  This happens during a desktop build, so simply assigning the new OS version with the fix will fix broken desktops.  And new desktops will work immediately.

From our perspective, the device nodes for the audio device (and often the virtual USB hub) in the registry are replaced by "delete tokens", instructing the CachePoint to remove them during a rebuild. We can resurrect the devices that Windows deletes if we simply ignore those delete tokens during a desktop rebuild.

This has to be done as an edit to the OS layer. To fix it, Add Version (or Edit Latest Version) of the OS layer, run RegEdit, and add the following Multi-String value:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\UniService]
"IgnoreDeleteTokenKeys"

IgnoreDeleteTokenKeys is a Multi-String value where each line is a partial string to match in the registry where we will then ignore the delete tokens. For instance, to keep us from deleting USB and MEDIA keys, put in Enum\Root\Media and Enum\Root\USB like this:

Enum\Root\Media
Enum\Root\USB

Once the key has been added to the registry of a new OS layer, finalize the layer and apply it to a broken desktop. It should immediately resurrect the missing devices when the machines boot back up.