More remote Group Policy Object settings and checking refresh status

Admins can refresh Group Policy Object settings across multiple computers, but they must verify that Group Policy settings have successfully changed.

Refreshing Group Policy Object settings across multiple computers can be a challenge, but there are a lot of ways to do it. In my previous article, we looked at how to remotely refresh Group Policy settings in Windows 8 and Windows Server 2012 via the Group Policy Management Console and the Invoke-GPUpdate PowerShell cmdlet.

Here, we'll examine how to use the PSExec.exe and Windows Management Instrumentation Command-line (WMIC) tools. Each tool has its own tricks, steps and limitations.

Using PSExec.exe

PSExec.exe is a tool included in PSTools that is available for download from Microsoft. PSExec.exe allows you to execute a command on remote computers interactively. It also supports running commands on remote computers specified in a text file.

To execute GPUpdate.exe on a remote computer, use the following command: PSExec.exe \\ComputerName GPupdate.exe /force.

To execute GPUpdate.exe on a group of computers specified in a text file, use the PSExec.exe command: PSExec.exe @Computers.TXT GPUpdate.exe /force.

PSExec.exe does not require any ports to be opened; instead, it uses default Remote Procedure Call ports to communicate with the remote computer and then execute the instruction specified in the command line.

Using the WMIC tool

With the Windows Management Instrumentation Command-line tool, you can create a process on remote computers to execute GPUpdate.exe remotely. Since WMIC doesn't support processing computers mentioned in a text file, you must use a FOR loop.

To run GPUpdate.exe on a remote computer, use the following WMIC command: WMIC /Node:ComputerName Process Call Create "CMD.exe /c GPUpdate.exe /force".

To run GPUpdate.exe on multiple remote computers, use this technique: FOR /F "Tokens=*" %L IN (C:\Temp\Computers.TXT) DO WMIC /Node:%L Process Call Create "CMD.exe /c GPUpdate.exe /force".

The above command executes GPUpdate.exe on each computer specified in the Computers.TXT file. The first part (FOR loop) gets a computer name from Computers.TXT one by one, and the second part executes the WMIC command on the computer name supplied by the FOR Loop.

Both PSExec.exe and WMIC methods create a process on the remote computer, as opposed to GPMC and Invoke-GPUpdate methods, which create a scheduled task. Some environments do not allow a process to be created on a remote computer, but many organizations want to be able to disable creation of scheduled tasks.

Similarly, you must open the firewall rules on each remote computer, as mentioned earlier, for GPMC and Invoke-GPUpdate methods to work. However, there is no need to open any firewall rules for PSExec.exe and WMIC.

Each method of refreshing Group Policy Object (GPO) settings on remote computers has its own advantages and disadvantages. The best configuration method will depend on your specific IT environment.

Reporting changed Group Policy Object settings

The overall objective of refreshing Group Policy settings on client computers is to make sure that any changes are successfully applied. Just executing the GPUpdate.exe won't tell you if a new or changed policy setting has been applied. None of the four methods I've described reports any failure with the GPO application.

For example, you cannot know on how many computers the Group Policy settings have been refreshed successfully or how many failed. There are, however, PowerShell commands to get a report in a CSV file.

Read more on Windows Group Policy:

Windows 8 Group Policy settings provide user interface control

FAQ: Why Windows Group Policy settings matter

Lock down enterprise desktops with Group Policy settings

Make virtual desktops consistent by managing Windows Group Policy

How does Group Policy differ among Windows editions?

When Group Policy settings are refreshed manually using GPUpdate.exe on a client computer, two event messages are generated in the event viewer of the client computer. Event ID 4004 is logged for Computer Configuration, and Event ID 4005 is logged for User Configuration. These two event IDs indicate that the Group Policy settings were refreshed manually using the GPUpdate.exe command.

This actually doesn't tell whether GPO refresh was successful or not. Two other event IDs generated at the client computers can show whether or not the GPO refresh was successful. Event ID 8004 is generated if computer configuration was applied successfully, and Event ID 8005 is logged if a user configuration was applied successfully from the GPOs. This is what you need to check on client computers.

Note: No matter what method you use to refresh the GPO settings, these event IDs will be generated if GPO settings are applied successfully.

Before you use the PowerShell command below, make sure to use one of the four methods I've explained to execute the GPUpdate.exe on remote computers. Once executed, run the command, assuming that you have created Computers.TXT already and that it contains the names of computers on which it will be executed.

1. Store the contents of Computers.TXT in a variable by executing this command:

$ComputerList=Get-Content C:\Temp\Computers.TXT

The above command stores the contents of Computers.TXT in $ComputerList variable, which will be used by the command in Step 3.

2. Next, store today's date in a variable. Since you want to see the Event IDs generated for the date when you executed the GPUpdate.exe, you need to create a variable with today's date stored.

$ThisDate = (Date).AddDays(0)

The "0" indicates that you want to check the Event IDs on the remote computers for the current date. You can also specify –number (for example -2).

3. Next, execute the Get-WinEvent PowerShell cmdlet with ForEach cmdlet to collect the Event ID 8004 and 8005 from remote computers, as listed below:

ForEach ($Computer in $ComputerList) {$Computer; $Result=Get-WinEvent -ComputerName $Computer -FilterHashtable @{ logname = "Microsoft-Windows-GroupPolicy/Operational" ; StartTime = $ThisDate; ID = 8004, 8005 } | Select-Object TimeCreated, Message, ID, MachineName}

The above command processes the Get-WinEvent cmdlet on each computer specified in the C:\Temp\Computers.TXT file. The command checks only for Event ID 8004 and 8005 on remote computers and results are stored in a variable called $Result.

4. Finally, run the command below to export the results from the $Result variable into a CSV file:

$Result | Export-CSV C:\Temp\RefreshStatus.CSV -NoTypeInformation

Open C:\Temp\RefreshStatus.CSV file, and the result should look like this screenshot (Figure 1):

export the results from the $Result variable
Figure 1

As shown in the report above, the PowerShell command executed in Step 3 was able to collect the Event IDs and message reported by the Event IDs successfully for two computers: ComputerName.DomainName.com and ComputerName2.DomainName.com.

The report does not show any failure while running Step 3. Not only should remote desktop administrators be familiar with these four ways to remotely refresh Group Policy Object settings on multiple machines, but they should also know how to verify that such refreshes are successful.

About the author:
Nirmal Sharma is a MCSEx3, MCITP and was awarded Microsoft MVP award in Directory Services. He specializes in Directory Services, Microsoft Clustering, Hyper-V, SQL and Exchange and has been involved in Microsoft technologies since 1994. Sharma can be reached at [email protected].

Dig Deeper on Unified endpoint management

Virtual Desktop