|
Patrick - yes - thats kinda what I thought - a very cool and noble cause because to be honest, I would LOVE to have such a utility as well. We got about a bazillion custom policies - and its a pain-in-the-a$$ to document them all. Plus, a reporting tool would be very usefull when double checking policy changes, after modifications are made (we all know what can happen when one forgets to include a reference to a template, when making changes) ...
Remember at the time, was thinking about writing a Kix script to do this - but the thought of parsing the ADM file - and then trying to "reverse engineer" and "match-up" the policy settings (like POLEDIT does) turned me off - imho - POLEDIT is a magic piece of software - when you really delve into it.
Another option might be a LIGHTWEIGHT reporting tool. Not too sure if you know this or not, but one can LOAD a .POL file, just like any other REGISTRY HIVE. .POL IS A registry hive actually. I load them to manually review changes - and then do an registry export on the before and after hives - just to double check that I haven't dropped anything.
Having said that, maybe you could:
1) Load the .POL hive into HKU and give it a name. Use LOADHIVE() and UNLOADHIVE()
2) Enumerate the loaded hive using READVALUE() and produce a report.
All the GROUP information is embedded in the hive, as registry keys. Lots of good stuff in there.
Problem is - you won't get all the "description strings" from the template ... but if you did want to persue parsing the ADM, this "backward" approach might help. But believe me - anyway you slice it - if you did get it going - I would be first in line to download and use it.
-Shawn [ 11 July 2002, 15:08: Message edited by: Shawn ]
|