In my last post, I explained how you can remotely update Group Policy settings on multiple machines in your network with PowerShell. Today, I will show you how to leverage PsExec and gpupdate for this purpose and discuss the advantages and disadvantages of this method.

Firewall settings ^

Like with Invoke-GPUpdate, you have to change the firewall settings on your clients. Since PsExec uses the SMB protocol, you have to open the TCP port 445. This can be done with Group Policy:

  1. In the Group Policy Management editor, navigate to Computer > Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security LDAP… > Inbound Rules and select New Rule in the context menu.
    New Rule
  2. Select Port as the rule type.
    Rule Type
  3. On the Protocol and Ports screen, enter 445 in the Specific Local Ports field.
    Protocols and Ports
  4. Select Allow the connection on the next screen.
    Allow the connection
  5. Deselect the Private and Public profile and only enable Domain on the Profile screen. Group Policy updates only make sense in a corporate domain.
  6. Give the new rule a name.
  7. Click Finish. You should see the new rule in the Group Policy Management editor.
    Portt 445 added

Remote Group Policy update ^

Download the PsTools and copy them to your source computer. Once the new Windows Firewall settings have been deployed in your network, you can remotely force a Group Policy update with this command:

psexec \\ComputerName –i gpupdate

Note that the –i parameter is vital here. It ensures that PsExec “interacts with the remote desktop,” which is necessary to update user policies. If you omit the parameter, only computer configurations will be updated, although neither PsExec nor gpupdate will throw an error message. Without the –i parameter, gpupdate will refresh user settings only if you logged in with the same account on the source and target computer.

If the computer is not online, you will get this error message:

Couldn’t access ComputerName:
 The network name cannot be found.
 Make sure that the default admin$ share is enabled on ComputerName

If everything is working properly, you will see this output:

Using gpupdate with PsExec

Using gpupdate with PsExec

Don’t worry about the error message “gpupdate exited on win7 with error code 0.” This just means that gpupdate exited with no error.

During my tests, a strange window appeared on Windows 8.1 target computers for a couple of seconds. I didn’t see this window on Windows 7 computers.

Strange window

Strange window

Remotely refresh Group Policy on multiple computers ^

If you want to update Group Policy settings on multiple computers with PsExec, you can do so with the following PowerShell command:

Get-ADComputer –filter 'Name -like "win7*"' -Searchbase "ou=test, dc=domr2, dc=com" | Select-Object -ExpandProperty Name | foreach{ Invoke-Expression –Command ".\psexec.exe \\$_ -i gpupdate.exe"}

This command gets all computer objects in the Active Directory container “test” that start with “win7” and then launches PsExec with the Invoke-Expression cmdlet.

Another option is to first export all computer names from an Active Directory container to a text file using the Get-ADComputer cmdlet:

Get-ADComputer –filter 'Name -like "win*"' -Searchbase "ou=test, dc=domr2, dc=com" | Select-Object -ExpandProperty Name | Out-File -Encoding ascii c:\tmp\ComputerList.txt

Note that we have to encode the output file with ASCII so that we can read its contents from a batch file as follows:

For /f "tokens=*" %%a in (c:\tmp\ComputerList.txt) Do psexec \\%%a -i gpupdate

The advantage of this method is that you can first skim through the computer names in the text file to check if everything worked as you intended. If you often have to force a Group Policy refresh on many machines, and no new computers have been added to Active Directory, you don’t have to run the export command every time.

PsExec vs. Invoke-GPUpdate ^

A major downside of the PsExec method is that it is relatively slow. It can take 3 to 4 seconds per computer, and, for machines that are not online, it can take even longer. PsExec sometimes even foze during my tests.

Allowing inbound connections on port 445 is a security risk. Computer worms can use this port, and hackers can do many nasty things with PsExec. Opening the Task Scheduler port for Invoke-GPUpdate is also problematic, but I think port 445 is more popular among malware programmers.

Thus, in most scenarios, Invoke-GPUpdate is the better option. However, if you opened port 445 anyway for other reasons and don't want to open the Invoke-GPUpdate ports, you might prefer PsExec to force Group Policy updates.

  1. Kvad 7 years ago

    You can right click in group policy management and hit group policy update on your desired OU.

  2. Kvad, yes in most cases this is more convenient. However, you still might experience a delay of 10 minutes. I blogged about this option in detail here

  3. Chris 6 years ago

    Michael, you can let psexec enumerate the domain and run gpupdate by "psexec \\* -i gpupdate", which is a lot easier than the powershell variant.

    • S 2 years ago

      you saved me a lot of time because this is exactly what I needed. thank you

  4. Chris, thanks for the tip!

  5. AJ 5 years ago

    I want to run gpupdate for a non-admin user on Terminal Server where the user session is pretty restricted and doesn't have access to things like Command Prompt.

    How can I use PSExec in this case?

    I have tried with -u and -p but gpupdate exists the remote server with error code 1.

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account