Updating Microsoft Windows Group Policy settings on the local machine is not so hard with a tool such as Gpupdate, but updating these policies on remote domain computers is not possible from within any Microsoft Management Console (MMC) by default or with any Microsoft tool available so far. In this article we will show some tricks, scripts and free tools that makes this task possible – and even easy – for the network administrator.
What we basically want, is to make it possible for the administrator (Admin), from a central location (Admin workstation), to update policies on Computer1, Computer2 and/or Computer3 – and the user policies for User A, B and C - whenever the admin finds it necessary. See figure 1.
Figure 1: The scenario
We do have the wonderful Gpupdate tool built in to Microsoft Windows XP and newer – and we had Secedit on Windows 2000 systems - but it is unfortunately so, that unlike the Gpresult command, both Gpupdate and Secedit only handle local updates. Of course, if we have a deployment system set up already, like Microsoft Systems Management Server (SMS), we could use this system to distribute a small script that executes the necessary command for a group of users or computers.
If we do not have such a system on the network, we must try to be creative - because the alternative is to log on to all computers using tools like Remote Assistance, or sending an email to all users, to execute the Gpupdate command... So, let’s try to be creative then.
Firewall trouble:
Like with any other communication that is initiated from the network, packets that try to update policy settings on remote computers' will fail if the remote computers local firewall (like the one built in to Windows operating system from Windows XP Service Pack 2 and up) is not configured to allow such incoming traffic (from a given subnet, IP or whatever). The built in Windows firewall must be configured to allow the incoming traffic we want by using a Group Policy Object (GPO), so ironically, such a policy is the only one we definitely cannot force to firewall-enabled remote computers.
The policy settings that need to be enabled for all the mentioned methods in this article, is the following:
Computer Settings | Administrative Templates | Network | Network Connections | Windows Firewall | Domain Profile | “Windows Firewall: Allow remote administration exception”.
Other firewall devices between the central computer and the remote computers must be configured to comply with the above setting (see Help text on the mentioned policy in GPEDIT.MSC for port info etc.).
Administrator rights:
The user that initiates the processes on the remote computers must be a local administrator on those machines – or else it’s simply not going to work as expected.
After this is taken care of, let’s look at the free methods we have available.
Gpupdate.exe resides in the “%windir%\system32” folder by default, so we don't need an absolute path to its location on the remote workstation. The tool can be called with a number of different switches:
Syntax: Gpupdate [/Target:{Computer | User}] [/Force] [/Wait:] [/Logoff] [/Boot] [/Sync]
In the “do it yourself” HTML Application (HTA) and Windows Management Instrumentations (WMI) scripts we will focus on running Gpupdate without any switches – or with either “/Taget:Computer” (to update only computer related policies) or “/Target:User” (to update only user related policies). The other options could be included with some more work - but would we really use “/Logoff” or “/Boot”? This would mean that users could be logged off if required (software installation, folder redirection etc.) or the computer could even be restarted while the user is working. Is that really what we want? Anyway, we could just as well use tools like Shutdown.exe for that purpose – but my guess is that it’s not going to be popular out there (the users you know).
PsExec is ‘Heaven’ when talking remote execution, first of all because it does not require any agents installed on the remote computers. You need to specify a computer name and the command that should be executed as switches in a command prompt – that’s basically it! Behind the scenes a service is being installed ‘ad hoc’ remotely and removed again when the command has been executed.
A small tip is to place the PsExec.exe file in the “%windir%” directory, because then we don’t have to specify the complete path to this file when executing it from a command line etc.
To update group policies on the remote computer ‘Computername’ all we have to write is the following command: “PsExec \\Computername Gpupdate”. The user logged on to the remote computer will not see anything happening, but in the background Gpupdate will ‘refresh’ both user and computer policies and apply any missing settings. You would think that PsExec should run with the “-i" switch (interactive) to update the remote users specific user policies, but testing shows that this is not the case.
When FLEX COMMAND is started, it contacts the Active Directory (AD) domain of the computer it is executed on. Therefore it must be executed from a domain member – if not, no OU’s can be found of course.
Select an OU, whether computer objects in sub-OU’s should be handled, and if the tool should only handle machines that are “alive” (answering to WMI requests). The last thing to do is to insert the command line we want to execute on the local machine for each computer object found in the OU selected. The text string “{C}” must be included; this will be replaced by the name of the computer when the script is looping through the computer objects.
Figure 2: FLEX COMMAND in action
Let’s say that the OU “MyComputers” contains only 3 computers: Computer1, Computer2 and Computer3. The command we have typed in, “psexec \\{C} gpupdate”, is then translated into the following 3 commands: “psexec \\computer1 gpupdate”, “psexec \\computer2 gpupdate”, “psexec \\computer3 gpupdate” – all commands will be executed consecutively (if the computers are alive) and remote policies should be updated.
The tool could be modified to get the computers from a file (txt, csv, xls etc.), a database, a specific security group in AD, a manual selection from a list or whatever the need would be. The way the script executes the processes/commands could also be modified, but this demo script is mainly to show the possibilities we have.
The script is freely delivered ‘as-is’ for you to test, use and modify as you please - more info here.
I have created another script for demo purposes, called OU GPUPDATE. This HTA script carries some different techniques “under the hood” – it’s actually just a small modification of FLEX COMMAND. First of all it looks up the OU structure in AD (the top dropdown list), it gives the user the option to hit computer objects in sub-OU’s too, to run Gpupdate with “/Target:User” or “/Target:Computer” or without any switches. Only computers that are “alive” (responds to WMI requests) will be hit by default.
Figure 3: Select what to update – user settings, computer settings or both
The script is freely delivered ‘as-is’ for you to test, use and modify as you please. The script can be downloaded here.
Jeremy Moskowitz, a Microsoft Group Policy MVP, mentions this procedure briefly in his book “Group Policy, Profiles, and IntelliMirror for Windows 2003, Windows 2000, and Windows XP”, see his website.
Darren's tool handles one machine at the time, but combined with a tool like FLEX COMMAND (as “wrapper”) the tool can hit an entire OU of a computer with a few clicks… Both RGPREFRESH and PsExec could also be combined with DSQUERY, FOR and other command line utilities to execute on more than one host at the time.
Figure 4: The RGPREFRESH options
The tool can be downloaded for free from this webpage.
Installing Specops Gpupdate
Installing the MSI application is very easy; all it requires is the Active Directory Users & Computers (ADUC) MMC and the Microsoft .NET Framework version 2.0.
Figure 5: The install process is as simple as most MSI package installations (next, next, next)
After installing the MSI file nothing is changed in the GUI, only “Add/Remove Programs” tell us that Specops is installed. So we have to perform an additional task for the magic to appear…
Active Directory User & Computers extended
The first time Specops Gpupdate is installed in the AD Forest, a special command must be run:
“%CommonProgramFiles%\Specopssoft\Specops ADUC Extension\SpecopsAducMenuExtensionInstaller.exe” /add
This is not a schema update, even though you must be Enterprise Admin to run this. This update is completely reversible, just run it again with the “/remove” switch instead. What it does is to register so called “Display Specifiers” to extend the view from within ADUC.
When right clicking an OU or a computer object, four new options are added: Gpupdate, Restart, Shut down and Start. It’s possible to make a selection of multiple computers and OU’s by holding down [Ctrl] while left clicking the wanted objects.
Figure 6: ADUC MMC extended
If you are wondering, as I did, if the changes also apply to non-DC’s (or management computers ), the answer is: Yes! After installing the Windows Server 2003 Admin Pack Service Pack 1 Administration Tools Pack on a Windows XP Professional client, the .NET Framework 2.0 and Specops Gpupdate, the management console looked just as nice as on the DC and had the same features available.
The Gpupdate option
The first option we have is to perform a Gpupdate command remotely on the selected computers. After choosing Gpupdate we must confirm the selection, see figure 7, and select if we want to use the force option.
Figure 7
After clicking OK a dynamic graph is presented, see figure 8, and a status report on how the update went.
Figure 8
The Restart and Shutdown option
The next two options, ‘Restart’ and ‘Shutdown’ are both “nice to have” management features, right where we need them, in ADUC. We can force the restart or shutdown, specify the number of seconds the user will have to close any open applications and send the user a customized message. Scripting this is not that hard to do using WMI or sending Shutdown.exe with the proper switches – but with Specops Gpupdate we get this functionality for free, no additional work to be done.
Figure 9: The confirm restart dialog
The Start option
The last of the four options, called ‘Start’, is actually Wake on LAN (WOL) functionality built-in to ADUC. When selecting and confirming this, see figure 10, so called Magic packets are sent against the clients MAC address to make them boot. WOL must be supported by the BIOS of computers of course. Specops Gpupdate communicates with Microsoft DHCP servers in the enterprise to find the info needed to perform this process, so it’s only possible to wake DHCP clients and only in network environments with Microsoft DHCP servers deployed.
Figure 10: Confirm starting remote WOL enabled computers
By the way, scripting WOL is actually possible too, but showing how to do this is far beyond the scope of this article.
Thanks:
Jakob H. Heidelberg is an MVP: Enterprise Security, MCSA/MCSE: Security/Messaging, MCDST, MCTS, MCITP, MCT, CCNA, and a Certified Ethical Hacker, that works as a System Consultant for Interprise Consulting A/S, a Microsoft Gold Partner based in Denmark. Jakob is engaged as a writer at the largest Microsoft online community for Danish IT pros, it-experts.dk. He also writes on his own blog, and likes to catch up on as much new stuff as possible within the Microsoft world, but currently specializes in messaging, monitoring and security issues
Introduction
Most administrators know the problem of forcing Group Policy (GP) processing on remote computers. After configuring an important policy of some kind, we would sometimes like GP processing to occur immediately on client computers. The problem is that by default, the so called background processing “only” happens every 90 to 120 minutes (randomized) – if we want to force updates to occur right away we are on our own. Of course there is a reason why policies do not just update every 5 minutes or ‘real-time’. The load on Domain Controllers and the network would simply be too much to handle in most environments. But, if a very important security setting at some point needs to be pushed to a large number of clients “right away”, it’s nice to be prepared for such a situation.What we basically want, is to make it possible for the administrator (Admin), from a central location (Admin workstation), to update policies on Computer1, Computer2 and/or Computer3 – and the user policies for User A, B and C - whenever the admin finds it necessary. See figure 1.
Figure 1: The scenario
We do have the wonderful Gpupdate tool built in to Microsoft Windows XP and newer – and we had Secedit on Windows 2000 systems - but it is unfortunately so, that unlike the Gpresult command, both Gpupdate and Secedit only handle local updates. Of course, if we have a deployment system set up already, like Microsoft Systems Management Server (SMS), we could use this system to distribute a small script that executes the necessary command for a group of users or computers.
If we do not have such a system on the network, we must try to be creative - because the alternative is to log on to all computers using tools like Remote Assistance, or sending an email to all users, to execute the Gpupdate command... So, let’s try to be creative then.
Issues
Before we get into more detail I just have to mention one common issue people have when trying to implement the methods mentioned in this article.Firewall trouble:
Like with any other communication that is initiated from the network, packets that try to update policy settings on remote computers' will fail if the remote computers local firewall (like the one built in to Windows operating system from Windows XP Service Pack 2 and up) is not configured to allow such incoming traffic (from a given subnet, IP or whatever). The built in Windows firewall must be configured to allow the incoming traffic we want by using a Group Policy Object (GPO), so ironically, such a policy is the only one we definitely cannot force to firewall-enabled remote computers.
The policy settings that need to be enabled for all the mentioned methods in this article, is the following:
Computer Settings | Administrative Templates | Network | Network Connections | Windows Firewall | Domain Profile | “Windows Firewall: Allow remote administration exception”.
Other firewall devices between the central computer and the remote computers must be configured to comply with the above setting (see Help text on the mentioned policy in GPEDIT.MSC for port info etc.).
Administrator rights:
The user that initiates the processes on the remote computers must be a local administrator on those machines – or else it’s simply not going to work as expected.
After this is taken care of, let’s look at the free methods we have available.
Scripting
Scripts are free and shared heavily among IT professionals on the Internet – this is actually “Open Source” at its best. Microsoft has provided us with some built in opportunities to expand the capabilities of our operating systems (OS) and environments - in this article we will cover how these capabilities can be used in regards to updating GPs remotely.Gpupdate & Secedit
First of all we should mention Gpupdate and Secedit, without those tools none of this would be possible. The scripts and tools mentioned here all assume that one of the tools exists on the remote client, depending on the OS version. As mentioned above, Secedit was delivered with Windows 2000 and Gpupdate took over from Windows XP and above, it has even survived the trip to Longhorn as it looks right now. In the following scripts I will focus on Gpupdate – we could check for OS version before calling either Gpupdate or Secedit, but that stuff can be added later without much work.Gpupdate.exe resides in the “%windir%\system32” folder by default, so we don't need an absolute path to its location on the remote workstation. The tool can be called with a number of different switches:
Syntax: Gpupdate [/Target:{Computer | User}] [/Force] [/Wait:
In the “do it yourself” HTML Application (HTA) and Windows Management Instrumentations (WMI) scripts we will focus on running Gpupdate without any switches – or with either “/Taget:Computer” (to update only computer related policies) or “/Target:User” (to update only user related policies). The other options could be included with some more work - but would we really use “/Logoff” or “/Boot”? This would mean that users could be logged off if required (software installation, folder redirection etc.) or the computer could even be restarted while the user is working. Is that really what we want? Anyway, we could just as well use tools like Shutdown.exe for that purpose – but my guess is that it’s not going to be popular out there (the users you know).
PsExec
The first method I’ll mention is very easy to implement and requires almost no scripting abilities. Why invent something that has already been invented, right? PsExec is developed by Mark Russinovich, the former owner of Sysinternals which was acquired by Microsoft in July 2006. It is currently available in version 1.73 and can be downloaded from Microsoft Technet here.PsExec is ‘Heaven’ when talking remote execution, first of all because it does not require any agents installed on the remote computers. You need to specify a computer name and the command that should be executed as switches in a command prompt – that’s basically it! Behind the scenes a service is being installed ‘ad hoc’ remotely and removed again when the command has been executed.
A small tip is to place the PsExec.exe file in the “%windir%” directory, because then we don’t have to specify the complete path to this file when executing it from a command line etc.
To update group policies on the remote computer ‘Computername’ all we have to write is the following command: “PsExec \\Computername Gpupdate”. The user logged on to the remote computer will not see anything happening, but in the background Gpupdate will ‘refresh’ both user and computer policies and apply any missing settings. You would think that PsExec should run with the “-i" switch (interactive) to update the remote users specific user policies, but testing shows that this is not the case.
FLEX COMMAND
Well, the above mentioned method updates policies for a single user/computer only – how about updating an entire Organizational Unit (OU) by using PsExec and Gpupdate together? For that purpose I have created a “demo” script to show some of the possibilities we get with some ‘creative’ scripting. The script is called FLEX COMMAND and can be downloaded here. When opening the HTA file with a text editor like Notepad the code is revealed – no hidden magic or anything.When FLEX COMMAND is started, it contacts the Active Directory (AD) domain of the computer it is executed on. Therefore it must be executed from a domain member – if not, no OU’s can be found of course.
Select an OU, whether computer objects in sub-OU’s should be handled, and if the tool should only handle machines that are “alive” (answering to WMI requests). The last thing to do is to insert the command line we want to execute on the local machine for each computer object found in the OU selected. The text string “{C}” must be included; this will be replaced by the name of the computer when the script is looping through the computer objects.
Figure 2: FLEX COMMAND in action
Let’s say that the OU “MyComputers” contains only 3 computers: Computer1, Computer2 and Computer3. The command we have typed in, “psexec \\{C} gpupdate”, is then translated into the following 3 commands: “psexec \\computer1 gpupdate”, “psexec \\computer2 gpupdate”, “psexec \\computer3 gpupdate” – all commands will be executed consecutively (if the computers are alive) and remote policies should be updated.
The tool could be modified to get the computers from a file (txt, csv, xls etc.), a database, a specific security group in AD, a manual selection from a list or whatever the need would be. The way the script executes the processes/commands could also be modified, but this demo script is mainly to show the possibilities we have.
The script is freely delivered ‘as-is’ for you to test, use and modify as you please - more info here.
Windows Management Instrumentation (WMI)
Ok, PsExec is nice, but do we have a “do it yourself” method so I can customize the solution to fit my environment? Yes, as a matter of fact we do! WMI is extremely powerful and pretty easy to handle after a few hours of studying. With WMI, a tamed firewall scenario and administrative rights in place, almost anything is possible in a Windows environment – even remote shut down, restart or execution of commands.I have created another script for demo purposes, called OU GPUPDATE. This HTA script carries some different techniques “under the hood” – it’s actually just a small modification of FLEX COMMAND. First of all it looks up the OU structure in AD (the top dropdown list), it gives the user the option to hit computer objects in sub-OU’s too, to run Gpupdate with “/Target:User” or “/Target:Computer” or without any switches. Only computers that are “alive” (responds to WMI requests) will be hit by default.
Figure 3: Select what to update – user settings, computer settings or both
The script is freely delivered ‘as-is’ for you to test, use and modify as you please. The script can be downloaded here.
Remote scripting
Besides WMI, we have the option to use ‘plain’ remote scripting (VBScript). This must be enabled by setting one value in the HKLM part of the involved computers' registry databases, the script engines must be “remote scripting” enabled, and from that point the rest is pretty straight forward. The procedure is to copy a script file to the remote host (this script should perform Gpupdate as required), and afterwards send a VBScript command that executes the script file remotely.Jeremy Moskowitz, a Microsoft Group Policy MVP, mentions this procedure briefly in his book “Group Policy, Profiles, and IntelliMirror for Windows 2003, Windows 2000, and Windows XP”, see his website.
RGPREFRESH
RGPREFRESH is a tool developed by Darren Mar-Elia. Darren is a Microsoft Group Policy Most Valuable Professional (MVP), see his website. His tool uses WMI behind the scenes and executes either Secedit or Gpupdate as needed on the remote host, with the command line switches selected by the user. These switches give you the same possibilities as if you were using the tool locally.Darren's tool handles one machine at the time, but combined with a tool like FLEX COMMAND (as “wrapper”) the tool can hit an entire OU of a computer with a few clicks… Both RGPREFRESH and PsExec could also be combined with DSQUERY, FOR and other command line utilities to execute on more than one host at the time.
Figure 4: The RGPREFRESH options
The tool can be downloaded for free from this webpage.
Specops Gpupdate
Special Operations Software, Specops, is an international software vendor, offering management products enhancing Active Directory and Group Policy based technology. The company has released their own remote policy updating solution, and the best part is that it is completely free to use. The current version of Specops Gpupdate is 1.0.2.13 (2006-10-25) and the utility can be downloaded here. This tool not only brings the functionality we have developed in the above scripts, but also adds some more management features. Let’s take a look at this nice utility…Installing Specops Gpupdate
Installing the MSI application is very easy; all it requires is the Active Directory Users & Computers (ADUC) MMC and the Microsoft .NET Framework version 2.0.
Figure 5: The install process is as simple as most MSI package installations (next, next, next)
After installing the MSI file nothing is changed in the GUI, only “Add/Remove Programs” tell us that Specops is installed. So we have to perform an additional task for the magic to appear…
Active Directory User & Computers extended
The first time Specops Gpupdate is installed in the AD Forest, a special command must be run:
“%CommonProgramFiles%\Specopssoft\Specops ADUC Extension\SpecopsAducMenuExtensionInstaller.exe” /add
This is not a schema update, even though you must be Enterprise Admin to run this. This update is completely reversible, just run it again with the “/remove” switch instead. What it does is to register so called “Display Specifiers” to extend the view from within ADUC.
When right clicking an OU or a computer object, four new options are added: Gpupdate, Restart, Shut down and Start. It’s possible to make a selection of multiple computers and OU’s by holding down [Ctrl] while left clicking the wanted objects.
Figure 6: ADUC MMC extended
If you are wondering, as I did, if the changes also apply to non-DC’s (or management computers ), the answer is: Yes! After installing the Windows Server 2003 Admin Pack Service Pack 1 Administration Tools Pack on a Windows XP Professional client, the .NET Framework 2.0 and Specops Gpupdate, the management console looked just as nice as on the DC and had the same features available.
The Gpupdate option
The first option we have is to perform a Gpupdate command remotely on the selected computers. After choosing Gpupdate we must confirm the selection, see figure 7, and select if we want to use the force option.
Figure 7
After clicking OK a dynamic graph is presented, see figure 8, and a status report on how the update went.
Figure 8
The Restart and Shutdown option
The next two options, ‘Restart’ and ‘Shutdown’ are both “nice to have” management features, right where we need them, in ADUC. We can force the restart or shutdown, specify the number of seconds the user will have to close any open applications and send the user a customized message. Scripting this is not that hard to do using WMI or sending Shutdown.exe with the proper switches – but with Specops Gpupdate we get this functionality for free, no additional work to be done.
Figure 9: The confirm restart dialog
The Start option
The last of the four options, called ‘Start’, is actually Wake on LAN (WOL) functionality built-in to ADUC. When selecting and confirming this, see figure 10, so called Magic packets are sent against the clients MAC address to make them boot. WOL must be supported by the BIOS of computers of course. Specops Gpupdate communicates with Microsoft DHCP servers in the enterprise to find the info needed to perform this process, so it’s only possible to wake DHCP clients and only in network environments with Microsoft DHCP servers deployed.
Figure 10: Confirm starting remote WOL enabled computers
By the way, scripting WOL is actually possible too, but showing how to do this is far beyond the scope of this article.
Thanks:
Jakob H. Heidelberg is an MVP: Enterprise Security, MCSA/MCSE: Security/Messaging, MCDST, MCTS, MCITP, MCT, CCNA, and a Certified Ethical Hacker, that works as a System Consultant for Interprise Consulting A/S, a Microsoft Gold Partner based in Denmark. Jakob is engaged as a writer at the largest Microsoft online community for Danish IT pros, it-experts.dk. He also writes on his own blog, and likes to catch up on as much new stuff as possible within the Microsoft world, but currently specializes in messaging, monitoring and security issues
Comments