VET v1.2 Group Policy Import Bug

This post is just a heads-up on some errors we’ve seen importing Group Policy Objects into RES Workspace Manager with the latest Virtual Engine Toolkit v1.2 release. In version v1.2 we introduced the ability to convert GPO permissions and OU links. To achieve this we needed to alter the way in which we enumerated the Group Policy Objects present within the source Active Directory domain.

VET v1.2 directly scans the SYSVOL volume (this approach has changed in VET v2.0). Unfortunately, if there is an errant folder that persists in the SYSVOL (but is no longer present in Active Directory) this error is not correctly trapped. The net result is a spectacular .NET exception error!

Internally we have code that fixes this issue, but it’ll be a few days before @nathan_sperry has digitally signed the new executable and built a new MSI installer. When this update is available, you will receive an update notification informing you that there’s an update available.

SNAGHTML2c21ba

In the meantime, if you receive a crash when importing GPOs, you’ll need to track down the errant policy folder and either delete the redundant GPO folder or remove the \USER\registry.pol or \MACHINE\registry.pol file.

Whilst the VET v1.3 is primarily a bug fix we are introducing something completely new, e.g. it’s nothing to do with VET, PuU, JET or JETCMD. It’s something we have been using internally and at customers for a long time. Stay tuned for more information…

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