Hi, Mike again. Here is the scenario: you’re sitting in front of a workstation that has been diagnosed with a Group Policy problem. You scurry to a command prompt and type the ever familiar GPRESULT.EXE and redirect the output to a text file. Then, proceed to open the file in your favorite text editor and then start scrolling through text to start your adventure in troubleshooting Group Policy. But, what if you could get an RSOP report like the one from the Group Policy Management Console (GPMC)—HTML based with sorted headings and the works? Well, you can!
Let’s face it—the output for GPRESULT.EXE is not aesthetically pleasing to the eye. However, Windows Server 2008 and Windows Vista SP1 change this by including a new version of GPRESULT that allow you to have a nice pretty HTML output of Group Policy results, just like the one created when using GPMC reporting.
Your new GPRESULT command is GPRESULT /H rsop.html . Running this command creates an .html file in the current directory that contains Group Policy results for the currently logged on user and computer. You can also add the /F argument to force Group Policy Results to overwrite the file name, should the file exist from a previous instance of GPRESULT. Also, if you or someone who signs your paycheck loves reporting and data mining, then GPRESULT has another option you’ll enjoy: change the /H argument to a /X and GPRESULT will provide Group Policy Results in .xml format (yes change the file extension to .XML too). You can then take this output (conceivably from many workstations) and store it in SQL and voila—reporting heaven.
Figure 1-HTML output from GPRESULT
Figure 2- XML output from GPRESULT
All you text-based report lovers can relax because the new version still defaults to text-based reporting.
I know I know… what about Windows Server 2003 and Windows XP? No worries, we can accomplish the same task, from the command line. We can use VBScript and the GPMC object model to provide a similar experience for those still using Windows Server 2003 or Windows XP. Both Windows Server 2003 and Windows XP are able to launch VBScripts. However, GPMC is a separate download for Windows Server 2003 and Windows XP ( http://www.microsoft.com/downloads/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en ). GPMC is a feature included in Windows Server 2008 that you can install through Server Manager.
Here is the code for the script. Copy and paste this code into a text file. Be sure to save the text file with a .vbs extension or it will not run correctly.
|
‘=====================================================================
Set oGpm = CreateObject(“GPMGMT.GPM”)
Set oRSOP = oGpm.GetRSOP( oGpConst.RSOPModeLogging, “” , 0)
oRSOP.LoggingFlags = 0
oRSOP.CreateQueryResults()
WScript.Echo “Complete” WScript.Quit() |
Figure 3- VBScript code to save Group Policy results to an HTML file
This code shown in figure 3 does not require any modification to work in your environment. Its only requirement is the computer from which the script runs must have GPMC installed. Now, let’s take a closer look at the script, which is a good introduction to GPMC scripting.( Please note that this posting is provided "AS IS" with no warranties, and confers no rights. Use of included script sample is subject to the terms specified at http://www.microsoft.com/info/cpyright.htm .)
Line 1: Set oGpm = CreateObject(“GPMGMT.GPM”)
This line is responsible for making the GPMC object model available to the VBScript. If you are going to use the functions and features of GPMC through scripting, then you must include this line in your script. Also, if your script reports and error on this line, then it is a good indication that you do not have GPMC installed on the computer from which you are running the script.
Line 2: Set oGpConst = oGpm.GetConstants()
The GPMC object model has an object that contains constants. Constants are nothing more than keywords that typical describe an option that you can use when calling one or more functions. You’ll see in Line 3 and Line 7 where we use the constant object to choose the RSOP mode and the format of the output file.
Line 3: Set oRSOP = oGpm.GetRSOP( oGpConst.RSOPModeLogging, “” , 0)
The RSOP WMI provider makes Group Policy results possible. Each client-side extension records their policy specific information using RSOP as it applies policy. GPMC and GPRESULT then query RSOP and present the recorded data as the results of Group Policy processing. RSOP has two processing mode, Logging mode and Planning mode. Planning mode is allows you to model “what if” scenarios with Group Policy and is commonly surfaced in Group Policy Modeling node in GPMC. Logging mode reports the captured results from the last application of Group Policy processing. You can see the first parameter passed to GetRSOP is a constant RSOPModeLogging. This constant directs the GetRSoP method to retrieve logging data and not planning data, which is stored in a different section within RSOP. The remaining parameters are the default values for the GetRSOP method. This function returns an RSOP object, from which we can save RSOP data to a file.
Line 4: strpath = Left(Wscript.ScriptFullName, InStrRev(Wscript.ScriptFullName,”\”, -1, vbTextCompare) )
This line simply gets the name of the folder from where the script is running and saves it into the variable strpath . This variable is used in line 7; when we save the report to the file system.
Line 5: oRSOP.LoggingFlags = 0
LoggingFlags is a property of the RSOP object. Typically, you use this property to exclude user or computer from the reporting results. Most of the time and for this example, you want to set LoggingFlags equal to zero (0). This is a perfect opportunity to use a constant (created in line 2). However, some of the values are not included in the constant object and LoggingFlags happens to be one of them. If you want to exclude computer results from the report data, then set LoggingFlags equal to 4096. If you want to exclude user results from the report data, then set LoggingFlags equal to 8192.
Line 6: oRSOP.CreateQueryResults()
The CreateQueryResults method actually copies the RSOP data logged from the last processing of Group Policy into a temporary RSOP WMI namespace. This makes the data available for us to save as a report.
Line 7: Set oResult = oRSOP.GenerateReportToFile( oGpConst.ReportHTML, strPath & “rsop.html”)
The script retrieved RSOP information in line six. In this line, we save the retrieved RSOP information into a file. The first parameter in the GenerateReprotToFile method is a value that represents the report format used by the method. This value is available from the constant object— ReportHTML . The second parameter is the path and filename of the file to which the method saves the data—rsop.html. Later, I’ll show you how you can change this line to save the report to XML. Remember, the script creates the RSOP.HTML file in the same folder from where you started the script.
Line 8: oRSOP.ReleaseQueryResults()
The ReleaseQueryResults method clears the temporary RSOP namespace that was populated with the CreateQueryResults method. Group Policy stores actual RSOP in a different WMI namespace. CreateQueryResults copies this data into a temporary namespace. This is done to prevent a user from reading RSOP data while Group Policy is refreshing the data. You should always call the ReleaseQueryResults method when you are done using the RSOP data. The remainder of the script is self explanatory.
HTML or XML
I mentioned earlier that you could also save the same data in XML as oppose to HTML. This is a simple modification to line seven.
Set oResult = oRSOP.GenerateReportToFile( oGpConst.ReportXML, strPath & “rsop.xml”)
Saving the report in XML is easy. Change the first argument to use the ReportXML constant and the file name (most importantly—the file extension) to reflect the proper file format type.
Summary
Group Policy Resultant Set of Policy (RSoP) data is critical information when you believe you are experiencing a Group Policy problem. Text formats provide you most of the information you need but, at the expense of you manually parsing through the data. HTML formats have the same portability as text formats and provide you a better experience for navigating directly to the information for which you are looking. Also, they look much better than text—so they are good for reports and presentation. Lastly, the XML format is awesome for finding things programmatically. You can also store this same information in a SQL database (for multiple clients) and run custom SQL queries to analyze Group Policy processing across multiple clients.
- Mike Stephens
Microsoft
