Installing SharePoint Services 3 on virtual machine after NewSID

For those of us addicted to virtual machines Sysinternals' tool NewSID comes in handy every time we clone that CleanSomeOs.vhd file. It changes the SID of the virtual machine in a snap with its wizard interface and unlike sysprep you do not need to re-configure localization settings. However if you plan to install Windows SharePoint Services (WSS v3) or Microsoft Office SharePoint Server (MOSS 2007) Beta most likely you will encounter the following error after you run the configuration wizard: System.InvalidOperationException ...

After a little research I found this MSDN article, which describes similar issue with WSS when installing TFS.

One way to go is to install a brand new OS on the VM, but this seemed like a lot of work especially if I needed to install WSS repeatedly and play with it. The suggested solution in the MSDN article did not work for me either. It is possible that my clean installation VHD has already been "tainted" by NewSID, so using sysprep meant going back to square one and installing fresh OS. After a bit more searching I found this blog, which addresses the issue in more suitable way. So all boils down to two major issues: 1. LOCAL SERVICE and NETWORK SERVICE have to members of the local group WSS_WPG and they are not. 2. Multiple registry keys related to WSS have corrupted permissions. The above article describes very well how to fix most of the registry keys. Nevertheless my system had additional entries corrupted in similar way and I had to dig in the log file and fix them. In addition I noticed that there is no need to assign privileges to registry entries.

I found the following corrupted registry entries HCR\AppID\{6002D29F-1366-4523-88C1-56D59BFEF8CB} and HCR\AppID\{58F1D482-A132-4297-9B8A-F8E4E600CDF6} . In addition the whole branch HLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0 seems to be with corrupted permissions, so instead of fixing the underlying registry keys one by one I simply deleted the rouge permission entries for the whole branch.

All of the above registry keys have the same issue. They have duplicate permission entries for the same users and groups. One entry inherited from the branch above and the other was "non inherited" . To fix this I deleted all entries with "non inherited" and selected "Replace permissions..." to populate the changes to the whole branch.

If after all this you still get similar errors. Click on the link to the log file and search for "InvalidOperation".

When you find the error line, browse couple of lines above and look for "The name of the registry to be secured...". This will give you the registry key with corrupted permissions. Fix it and try again.

Dovizhdane!