GPResult is a command-line utility for determining the resultant set of policy for a given user and/or computer. In other words, it shows you what Group Policy Objects have been applied and their settings. This is typically one of the first tools I go to when troubleshooting Group Policy from a client once basic connectivity has been confirmed (e.g. Network/DNS). The tool itself is very simple to use and I will run through some common examples below.
List GPOs Applied with Summary Data
/r Displays RSOP summary data
This is pretty useful when you simply want to see what GPOs have applied and in what order. It will also display summary data, such as last time group policy was applied, which Domain Controller it was applied from, the site, security groups and if the slow link threshold has been activated. If you are unsure if a GPO has been applied, this is a quick way of checking.
Here we see that 4 GPOs have applied to the Computer settings portion.
If you don’t want to view both Computer and Users settings in the output you can request one or the other with the
gpresult /r /scope:user
gpresult /r /scope:computer
The output reads fairly well from within the command prompt, but if you need to export the output you could use either of the following.
Gpresult /r > gpresult.txt Export output to a text file
Gpresult /r |clip Export output to Windows clipboard
I can’t see the Computer Settings?
If UAC is enabled, running GPResult without elevating the command prompt will only show you the user settings. If you want to see both user and computer settings, elevate the command prompt by either tapping the winkey+cmd then ctrl+shift+enter or right click on the command prompt and select run as administrator. If you elevate with an admin account different to the currently logged in user (common if the user does not have administrator rights), then you will receive an error message stating INFO: The user “domain\user” does not have RSOP data. This is because GPResult is using the elevated user’s context. To work around this, specify the standard user that you are troubleshooting.
gpresult /r /user:sa\edward.thomas
Generate HTML Report
Gpresult /h report.html /f
Gpresult /h report.html /user:sa\edward.thomas /f
/h Saves the report in HTML format
/f Forces GPresult to overwrite the file name specified with /h
/user Specifies the user name for which the RSOP data is to be displayed
To get a more graphical view of what’s going on, you can generate a HTML report. This gives a detailed break down of each setting and the GPO from which it came. This view is particularly nice as you can show all and use ctrl+f to find a particular policy or setting.
Run GPResult on Remote Computer
Gpresult /s server1 /r
/s Specifies the remote system to connect to
This allows you to run GPResult on a remote system, all of the above applies.
The following GPOs were not applied because they were filtered out
You may see this for a few reasons. The first that the policy is empty in which case you’ll see Filtering: Not Applied (Empty), this is fairly self explanatory. The second is Filtering: Denied (Security), which typically boils down to the “Apply Group Policy” permission on the GPO. You may also see Filtering: Denied (Unknown Reason) which is similar to (Security) in that the “Read” permissions has been denied.
To review the last two examples, launch the GPMC (Group Policy Management Console). Find the offending GPO, and select Delegation- from there you may see an additional group or a single user or machine that has been added.
Click on advanced and review the permissions against the object. In this case you can see that the Seven computer object has been denied Apply Group Policy resulting in the Filtering: Denied (Security) message.
If in doubt, select Advanced -> Effective Access and enter the required computer or user object. If you scroll down to around halfway you’ll see the Apply Group Policy permission with either a green tick of a red cross against it. If deny read has been granted every permission will have a red cross next to it.
I hope this gives you the basics behind GPResult and some good real world example to aid in your Group Policy troubleshooting.
Find the default gateway on a list of remote servers.
Create a textfile with a list of servers you would like to query, use a new line for each server. If you have an OU of servers you would like to query you could use the following to create a text file with all computer accounts within an OU (requires Active Directory Module for Windows PowerShell).
Get-ADComputer -LDAPFilter "(name=*)" -SearchBase "OU=Servers,DC=domain,DC=local" | Select -expand name | Out-File -Encoding utf8 "\\server\share\Servers.txt"
This would create a textfile with every computer account in the “Servers” OU on domain.local.
I tend to put a “dummy” line at the top of the text file as PSEXEC has issues with the first entry.
Now use PSEXEC to execute the following, don’t forget to run the command prompt as administrator (using an account with the required permissions on the remote servers).
psexec @c:\Serverlist.txt ipconfig /all | findstr "Default Gateway Host" >> c:\Servergateways.txt
…and here’s the final result.
One of the choices for SCEP (System Center Endpoint Protection) definition update sources in SCCM 2012 is from a UNC file share, however in typical SCCM fashion there is a bit of leg work required to use this method. This post will explain the steps involved to make this happen.
1. Create a Folder Structure and Share
Create a folder structure to share the SCEP definition update files, the top level folder name does not matter, in this example I’m using SCEPUpdates. Within this folder create two folders, one named x86 for x86 machines and one named x64 for x64 machines. Share the SCEPUpdates folder. Ensure the client computers and the domain users connecting to the share have read permissions to the share. During an automatic update, the client computer account is used to authenticate to the share. When a user manually updates their definitions by clicking Update, that user account is used to authenticate to the share. You will want to use DFS or similar if you have multiple locations to distribute the files.
2. Powershell Script to Automate Definition File Downloads
There are 6 files in total to download, 3 for x64 machines and 3 for x86 machines.
- Mpam-fe.exe – Full Definitions
- Mpam-d.exe – Delta Definitions
- Nis_full.exe – Network-based exploit definitions
For more information and direct links to the definition files see here (or refer to the Powershell script below).
I’ve put together a Powershell script to download the 6 definition update files to a UNC path.
$x64S1 = "http://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x64" $x64D1 = "\\server\SCEPUpdates\x64\mpam-fe.exe" $x64S2 = "http://go.microsoft.com/fwlink/?LinkId=211054" $x64D2 = "\\server\SCEPUpdates\x64\mpam-d.exe" $x64S3 = "http://go.microsoft.com/fwlink/?LinkId=197094" $x64D3 = "\\server\SCEPUpdates\x64\nis_full.exe" $x86S1 = "http://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86" $x86D1 = "\\server\SCEPUpdates\x86\mpam-fe.exe" $x86S2 = "http://go.microsoft.com/fwlink/?LinkId=211053" $x86D2 = "\\server\SCEPUpdates\x86\mpam-d.exe" $x86S3 = "http://go.microsoft.com/fwlink/?LinkId=197095" $x86D3 = "\\server\SCEPUpdates\x86\nis_full.exe" $wc = New-Object System.Net.WebClient $wc.DownloadFile($x86S1, $x86D1) $wc.DownloadFile($x86S2, $x86D2) $wc.DownloadFile($x86S3, $x86D3) $wc.DownloadFile($x64S1, $x64D1) $wc.DownloadFile($x64S2, $x64D2) $wc.DownloadFile($x64S3, $x64D3)
This is great for one off downloads, but we want to automate the task. The next step is to create a schedule task to the run the script every x hours. The action should point towards the Powershell script above, you can simply use powershell -file “script.ps1″ as the action.
This schedule kicks the first download off every day at 12:05am and updates the definition files every 4 hours.
Confirm the scheduled task is running every 4 hours and updating the files correctly before moving onto the next step.
3. Configure Definition Update Sources
Open the System Center 2012 Configuration Manager console and browse to Assets and Compliance -> Endpoint Protection -> Antimalware Policies and select the policy you would like to configure.
From the left hand menu choose Definition Updates and choose “Set Source”. Tick “Updates from UNC File Shares” and move to the top of the list, un-tick other sources if necessary. Click OK.
Choose Set paths, add the UNC path and OK.
To confirm the clients are pointing to the right location and using the UNC share configured above, wait (or manually) update the client’s policy and browse to the following registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Signature Updates (or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Microsoft Antimalware\Signature Updates) and review DefinitionUpdateFileSharesSources.
When PXE booting and deploying a task sequence you receive the error “Failed to resolve selected task sequence dependencies” and no dependency or package IDs are displayed.
1. Press F8 when in the WinPE environment to open the command prompt – Click here if you have not enabled the command support console.
2. You can view the SMSTS.log file on the live system, or move it to another machine to interrogate. To open the SMSTS.log which is responsible for deployment and task sequence log events type notepad X:\Windows\Temp\SMSTS\SMSTS.log (the task sequence dependency check happens prior to any formatting of the HDD, hence the location of the log file). At this stage you can also plug in a USB drive and copy/save the log onto it.
3. Open the log file with the Configuration Manager Trace Log Tool aka CMTrace.exe, this will make it a lot easier to view and find the offending errors. If you do not have CMTrace, you can grab it from the SCCM media under SMSSETUP\TOOLS. It’s a single executable so can be copied and moved around as necessary.
4. Near the bottom of the log file you should observe similar errors:
Failed to find CCM_ApplicationCIAssignment object for AdvertID=”12003A”, ModelName=”ScopeId_59CA012F-1C99-45CD-9184/Application_64ff713e-87d1-40dc-8d24-16961ccff5bb”
Failed to resolve selected task sequence dependencies. Code(0×80040104)
ThreadToResolveAndExecuteTaskSequence failed. Code(0×80040104)
The part we’re interested in is the second part of the ScopeId, in this case: Application_64ff713e-87d1-40dc-8d24-16961ccff5bb. To find out which application this refers to open the System Center 2012 configuration manager console. Browse to Software Library, Operating Systems, Task Sequences and select the required task sequence. At the bottom choose “References”, this will show you all applications assigned to the task sequence and their Object IDs. Match this up with the error found from the SMSTS.log.
In my case the offending application was Sage Accounts 2014. Things to check:
- Make sure the application has been distribution to the required distribution point(s).
- Try removing it from the distribution point(s) and re-distributing.
- If the above fails, simply remove the application from the task sequence and re-add it (this was my issue!).
Troubleshooting SCCM Operating System Deployments can be tough, to ease the pain you can enable the command support console for use within the Windows Preinstallation Environment. Doing so will give you access to the command prompt, the SMSTS.log and the ability to launch various other applications to aid in troubleshooting. I will show you how to enable the console, then give a couple of examples.
Enabling Command Support Console (F8)
1. Open the System Center Configuration Manager Console.
2. Browse to Software Library -> Operating Systems -> Boot Images and select the boot image you would like to add command support to.
3. Right Click the boot image and select properties.
4. Head to the Customization Tab and tick “Enable command support (testing only)”.
You will then be prompted with “You have made changes that require you to update distribution points with a new version of this package – Do you want ConfigMgr to update the distribution points now?”.
5. Click Yes.
6. Work will then be done on the Boot.wim, which will in turn be re-distributed. Current size of the boot.wim without any additional drivers added is around 160MB so distribution shouldn’t take too long- even with slow links. Next, next until the process is completed.
Once the updated boot.wim has been distributed, PXE boot into WinPE. You will now be able to access the command prompt by pressing F8.
Open the SMSTS.log
The SMSTS.log is the main log file for diagnosing OSD and Task Sequences client side. The location of this file changes through various steps of the task sequence.
WinPE Before HDD is formatted: x:\windows\temp\smstslog\smsts.log
WinPE After HDD is formatted: x:\smstslog\smsts.log
Windows, SCCM agent not installed: c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Windows, SCCM agent installed: c:\windows\system32\ccm\logs\Smstslog\smsts.log
Windows x64, SCCM agent installed: c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
1. Press F8 when in the WinPE environment to open the command prompt.
2. You can view the SMSTS.log file on the live system, or move it to another machine to interrogate. To open the SMSTS.log type notepad X:\Windows\Temp\SMSTS\SMSTS.log (in this case this is the SMSTS.log prior to formatting the HDD). At this stage you can also plug in a USB drive and copy/save the log onto it.
Taking a screenshot
It can be useful to have the ability to take screenshots from within WinPE. To do so, you can map a drive (or use a USB stick) and use a utility called nircmd.
Here we map a drive with net use j: \\server\share password /user:user then run nircmd from the mapped drive.
Savescreenshotwin will only capture the command prompt window, whereas savescreenshotfull will capture the entire environment (probably more useful).
Hopefully this post will have improved your ability to troubleshoot OSD and task sequence issues, and open up the possibility of running other applications (e.g. process monitor) from within WinPE.
In the last few posts we’ve looked at moving away from Internet Explorer Maintainence within Group Policy as it has been deprecated from Internet Explorer 10 and above. There are two clean methods to remove these settings from Group Policy, the first is simply unlinking the GPO that has been configured with these settings. However if you have configured IEM within your Default Domain Policy or another GPO that you’d like to continue using, you are able to remove any settings configured with Internet Explorer Maintenance by right clicking and choosing Reset Browser Settings.