SteadyState ADM breaks GPMC?

[PreviousPoster]

I posted this problem a couple months ago, but the thread appears to have disappeared, so just for the record (and maybe an answer)...

We're trying to implement Windows Steady State (WSS) v2.5, and we're having a problem with the ADM template that comes with the WSS install.

We take the "SCTsettings.adm" that installs with WSS, copy it to a Vista (or Server 2008) machine running GPMC v6 and add the template to a new, blank GPO. If we then look at the settings tab for the GPO, it looks fine (with no settings yet).

The problem occurs once some of the WSS ADM settings are enabled. I didn't get very granular in my testing, but the problem is easily reproducible for us. Edit the ADM settings in User Config->Policies->Admin Templates->Classic Admin Templates->"All Windows SteadyState Restrictions"of the GPO. Some changes (default "Start menu Restrictions" as an example) still allow the GPO settings to be viewed in the GPMC. If you enable the "General Windows Restrictions" something breaks, and the GPO settings tab only gives a message:

An error occurred while generating report:
Object reference not set to an instance of an object.

This occurs in both x86 and x64 flavors of Vista and Server 2008, and if we remove the ADM, the GPO remains "broken". We can continue to edit the GPO and it appears to function. We just can't get a report on the settings.

Frustratingly, if we bring up GPMC in XP, it displays all the settings without a hitch. We are not using the GPMC in XP anymore per Jeremy's recommendation that once you start working with GPOs in Vista, you should not attempt to also edit them from XP. Here is a screenshot showing the same GPO settings in XP.

When this thread existed before, Jeremy suggested that this is a bug in the GPMC, but as I have found absolutely zilch about anyone else seeing this, I would really like someone to verify (or deny) it for me before I embarrass myself calling MS. If nobody has an answer, could someone at least check to see if it happens to them too?

Thanks.

[mrvincentb]

Hi, phew, just registered to answer ;-)

Please note what I found out and posted at http://social.microsoft.com/Forums/en-US/windowssteadystate/thread/c4db97d3-edf9-48a4-9d06-fd61bd5d2247?prof=required - thanks to your great initial troubleshooting work:

Same problem here, too - Windows Server 2008 DC environment and Vista clients.

As I found out in another thread (cached page on Google), the "General Windows Restrictions" from the SteadyState policy break the view!

I took a look at the SteadyState .adm file which settings were made by the "General Windows Restrictions". The only values standing out as being a bit odd were the GUID like "CodeIdentifiers" structure (Software Restriction policy - user).

In fact, the CodeIdentifiers section is populated with partially incorrect values. You will get an exception in the policy editor when double-clicking on the user's Software Restriction Policy, "Designated File Types". Opening the "Designated File Types Properties", clicking on OK twice may already fix the policy/issue.

(You could also click through all items within the rules section (Banner.wsf, CACLS.exe, ...) in order to correct the timestamps which are quite odd, too (1/1/1601). Just set each item to standard or something like that, OK, double-click again, revert to original value, click OK.)

Alternatively you might even reset/delete the user-based Software Restriction completely and rebuild it by hand. Thing is, creating a fresh policy would properly populate the "Designated File Types" properties with some default values. Take a look at the machine-based Software Restriction policy for reference. Or here: http://technet.microsoft.com/en-us/library/bb457006.aspx

I can only speculate that Windows XP had a different CodeIdentifiers format and that the policy was written in regard to the XP registry structure. Or XP just handles the erroneous/incomplete settings better. But as a conclusion I would say this is actually a template problem and is not a GPMC bug or malfunction. It should be fixed by the SteadyState team.

Another culprit beaten! Such a bastard! ;-)

Now I can lunch in peace :-)

Regards, Markus