How to speed up the group policy update process. GPUPDATE - Performing Group Policy Updates for User and Computer Updating Local Security Policy

GPUPDATE command is used to update group policies for the user and / or computer.

GPUpdate

Command line parameters:

/ Target: (Computer | User)- Update policy settings for User only or Computer only. If not specified, the settings for both policies are updated.

/ Force- Applying all policy settings. If not specified, only changed policy settings are applied.

/ Wait: value- Time to wait (in seconds) for the completion of policy processing. The default is to wait 600 seconds. The value "0" means no waiting. The value "-1" means the wait is unlimited. If the timeout is exceeded, the Command Prompt window is reactivated, but policy processing continues.

/ Logoff- Exit after updating Group Policy settings. Required for those Group Policy client extensions that do not process the policy in background, but only process it when the user logs on, such as installing programs for the user or redirecting folders. This parameter has no effect unless extensions are called that require the user to log out.

/ Boot- Reboot after applying Group Policy settings. Required for those Group Policy client extensions that do not process the policy in the background, but process it only at startup, such as installing software for a computer. This parameter has no effect unless extensions are called that require a system restart.

/ Sync- The next active policy enforcement must be synchronous. Active policy enforcement occurs when the computer is restarted or when the user logs on to the system. You can use this parameter on a user, computer, or both by specifying the / Target parameter. However, the / Force and / Wait options, if specified, are skipped.

Examples of using:

gpupdate /?- display a hint on how to use the command.

gpupdate- computer policies and user policies are being updated. Only changed policies are applied.

gpupdate / Target: computer- the update of policies is performed only for the computer.

gpupdate / Force- all policies are being updated.

gpupdate / Boot- updating group policies with a computer restart.

Summary: Microsoft Scripting Guy, Ed Wilson shows you how to trigger a Group Policy update using PowerShell.

Updating Group Policy on the Domain

Sometimes I make changes to Group Policy on the network and I need to apply the changes to all computers. And sometimes I need to update the local group policy on my computer.

To update the Group Policy settings, I use the utility GPUpdate... It has some parameters. By default, the utility updates the policy of both the computer and the user. But this can be controlled using the parameter / target... For example, if I am bored to update only the computer policy, I will specify / target: computer... To update only user policy - / target: user.

PS C: \> gpupdate / target: computer

Updating policy ...

Default GPUpdate applies only updated Group Policy settings. To apply all settings, use the parameter / force... The command below updates all Group Policy settings (regardless of whether they have been changed) for the computer and the user.

PS C: \> gpupdate / force

Updating policy ...

Computer Policy update has completed successfully.

User Policy update has completed successfully.

First, we get a list of computers in the domain

The first thing I need to do is get a list of all computers in the domain. For this I use the cmdlet Get-ADComputer included in the module Active Directory.

Note: The Active Directory module is part of RSAT.

I store the resulting computer objects in the $ cn variable.

$ cn = Get-ADComputer -filt *

Second, we create remote sessions

The next thing I need to do is create remote sessions with all computers. To do this, I need to provide credentials to connect to computers, as well as create the sessions themselves using the cmdlet New-PSSession.

First, I'll use the cmdlet Get-Credentials and store the returned object in the $ cred variable.

$ cred = Get-Credential iammred \ administrator

$ session = New-PSSession -cn $ cn.name -cred $ cred

Please be aware that the domain may have shutdown computers, so the command may return errors. However, despite the mistakes, Windows PowerShell creates sessions with work computers.

The presence of a large number of errors can inspire some concern. Since the session objects are stored in the $ sessions variable, I can easily verify that they are created.

Now let's run the command on all remote machines

To run the command GPUpdate on all remote machines i use the cmdlet Invoke-Command... It uses the sessions we saved in the $ sessions variable. Alias for cmdlet Invoke-Command – icm.

icm -Session $ session -ScriptBlock (gpupdate / force)

After running the command, the results are displayed in windows consoles PowerShell.

Verifying Group Policy Updates

When on workstation the Group Policy settings are updated successfully, event ID 1502 is written to the System log. I can use the cmdlet Invoke-Command for this information.

icm -Session $ session -ScriptBlock (Get-EventLog -LogName system -InstanceId 1502 -Newest 1)

The command and its results are shown in the figure below.

Another cool thing about Group Policy

Sometimes I have to call tech support and they ask to update the Group Policy on my local computer. This is not a problem as I can run GPUpdate straight from PowerShell. The difficulty arises when they ask me to update Group Policy 5 times with an interval of 5 minutes. But this can be solved with a single line of code.

1..5 | % ("Refreshing GP $ (Get-Date)"; gpupdate / force; sleep 300)

Ed Wilson, Microsoft Scripting Guy

Original:

In this article, we will show you an easy way to remotely update group policies on clients (computers and servers) in an Active Directory domain, without having to access the console on the remote machine and without using the gpupdate command.

One of the toughest challenges in AD Group Policy management is testing policies on the fly, without rebooting the computer or accessing the local computer and running a command.

Remote Group Policy Update provides the ability to use a single GPO Management Console (GPMC.msc) to both create, modify, and apply and test Group Policy.

The functionality of remote updating of group policies first appeared in Microsoft Windows Server 2012, in all subsequent versions (Windows Server 2016, Microsoft Windows 10), this functionality and its stability have gradually improved.

Requirements for Remote Group Policy Update to work:

Server environment requirements:

Windows Server 2012 and higher
Or Windows 10 with installed tools management RSAT (Management tools)

Requirements for clients:

Windows 7 and higher

Requirements for network communication (firewalls) between server and clients

TCP Port 135 must be open
Service included Windows Management Instrumentation (service Windows management)
Task Scheduler Service (Task Scheduler Service)

If your environment meets these requirements, open the Group Policy Management Console (GPMC.msc), select the OU (container) that contains the target computers on which you want to force the GPO update.

Right click on the desired container and select the item Group Policy Update.

In the window that opens, information about the number of objects in this OU will appear on which the GPO will be updated. To confirm the action, click on the "Yes" button.

In the Remote Group Policy update results window, you will see the status of the policy update, as well as the status of this operation (success / error, error code). Naturally, if a computer is turned off, or access to it is restricted by a firewall, a corresponding error will appear.

Configuring Windows 10 Update Policy is configuring how Windows 10 receives updates. In Windows 10, Update settings have been moved from Control Panel to System Settings. Windows 10 does not have the same settings as there were in the Control Panel, and therefore it became impossible to disable updates or choose how to receive them. However, you can use the Registry Editor and Local Group Policy Editor to disable the updates and set how they are received.

Configuring Updates Using the Local Group Policy Editor

Launch the Local Group Policy Editor by pressing two keys on the keyboard at once WIN + R gpedit.msc and click OK.

Windows 10 Upgrade Group Policy

Computer Configuration - Administrative Templates - Windows components- Windows Update... Click on the last item Windows Update and then on the right side find the item Customization automatic update and change its settings.

Configuring Windows 10 Updates Group Policy

To do this, in the window that opens, you need to put a dot at the top at the Enabled item, and then set the update settings below. Click OK. Then, to make the settings you have made work, open System Settings - Update & Security - Windows Update and press the button Checking for Updates.

When finished setting Windows policies 10, run the update

After that, the settings you made in the Local Group Policy Editor will take effect.

Configuring Updates Using Registry Editor

Launch the Registry Editor by pressing two keys on the keyboard at once WIN + R... The Run window will open in which you enter the command regedit and click OK.

Open Registry Editor and create four parameters there to control Windows updates 10

In the left part of the editor window that opens, open HKEY_LOCAL_MACHINE - SOFTWARE - Policies - Microsoft - Windows... Hover over the last Windows item and right-click. In the context menu that opens, select Create - Section. New section name WindowsUpdate.
Then hover over the newly created WindowsUpdate section and again create a section called AU.
Then hover over the newly created AU section and right-click and select New - DWORD Parameter (32-bit)... The newly created parameter will appear on the right side of the window, name it AUOptions... In the same way, hovering over the AU section, create three more parameters and name the first NoAutoUpdate, second ScheduledInstallDay and the third ScheduledInstallTime(optional NoAutoRebootWithLoggedOnUsers). Now these four new parameters need to change the value.

For the AUOptions parameter

2 - Get notified before installing and downloading any updates.
3 - Automatically receive updates and notifications about their preparation for installation.
4 - Automatically receive and install updates on a specified schedule.
5 - Allow local administrators to choose the update mode and notifications.

For the NoAutoUpdate parameter

0 - Enabled automatic installation updates that will be downloaded and installed depending on the settings made in the AUOptions parameter.
1 - Automatic installation of updates is disabled.

For the ScheduledInstallDay parameter

0 - updates will be installed daily with a value of 4 for the AUOptions parameter.
1 - updates will be installed every Monday with a value of 4 for the AUOptions parameter.
2 - updates will be installed every Tuesday with a value of 4 for the AUOptions parameter.
3 - updates will be installed every Wednesday with a value of 4 for the AUOptions parameter.
4 - updates will be installed every Thursday with a value of 4 for the AUOptions parameter.
5 - updates will be installed every Friday with a value of 4 for the AUOptions parameter.
6 - updates will be installed every Saturday with a value of 4 for the AUOptions parameter.
7 - updates will be installed every Sunday with a value of 4 for the AUOptions parameter.

For the ScheduledInstallTime parameter

From 0 to 23, updates will be installed at that number of hours, depending on the set parameter and when the AUOptions parameter is set to 4.

For the NoAutoRebootWithLoggedOnUsers parameter

0 - After the installation of updates is completed, the computer will automatically reboot, it works with a value of 4 for the AUOptions parameter.
1 - After the installation of updates is completed, the computer will not automatically restart, it works with a value of 4 for the AUOptions parameter.

· No comments

Updating policy settings Microsoft groups Windows Group Policy on a local machine isn't very difficult to do with a tool like Gpupdate, but updating these policies on remote computers in the domain, cannot be done using the console Microsoft management Management Console (MMC), or any Microsoft product currently available. In this article, I will guide you through various tricks, scenarios and free tools that allow you to update group policy settings on remote computers in the domain.

Introduction

Most administrators are aware of the problem of applying group policies to remote computers. After configuring some important policy, sometimes we would like this GP group policy to appear on client computers immediately. But the problem is that by default, the so-called background processing occurs only in the interval from 90 to 120 minutes (randomly) - if we want to speed up the update process, then here we are on our own. Of course, there is a reason why the policies simply don't update every five minutes or even in real time. The load on the domain controllers and the network in most environments will be too heavy to handle. But if the need arises for a quick application, very important setting for safety for a large number clients, it would be nice to prepare for such a situation.

What we really need is to enable the administrator to update policies on computers Computer1, Computer2 and / or Computer3 - as well as policies for users A, B, and C from a centralized point - the administrator workstation, in case the administrator deems it necessary. ... Take a look at Figure 1.

Figure 1: Scenario

We have a great tool called Gpupdate that's built into Microsoft Windows XP and newer operating systems - and we also have a tool called Secedit for the operating system. Windows systems 2000 - but unfortunately the Gpresult command for the Gpupdate and Secedit tools can only be processed on local machines. Of course, we already have a configured installation system, like Microsoft Systems Management Server (SMS), we can use this system to send small scripts that will run the required command for a group of users or computers.

If your network does not have such a system, then you should try more creative approaches. the alternative is to go to all required computers using a tool like Remote Assistance, or send out to all users email with a request to run the command Gpupdate ... So look for more creative approaches.

Problems

Before diving into the details, I want to mention common problems that people come across when trying to use the methods mentioned in this article.

Firewall issues:

As with other connections initiated on the network, packets that try to update policy settings on remote computers will not be able to traverse the local firewall on remote computers (such as the firewall that is built into the Windows operating system, starting with Windows XP Service Pack 2 or later) if the firewall is not configured to allow such inbound traffic (from the selected subnet, IP, or similar). The built-in firewall in Windows must be configured to allow inbound traffic that we generate using a Group Policy Object, so as ironic as it sounds, this policy is the only one that we cannot use for remote computers with firewall enabled.

The policy settings that must be set for all methods mentioned in this article are as follows:

Other devices that act as firewalls between the central computer and the remote computers must also respect the above settings (see Help test for the mentioned policy in GPEDIT.MSC).

Administrator rights:

The user who initiates the process on the remote computer must have local administrator rights on it - otherwise, everything will not work as you expect.

After you've taken care of all of this, let's go over the methods themselves.

Scripting

The scripts are free and widely distributed among software specialists. information technology on the Internet is really “Open Source”. Microsoft has provided us with several built-in capabilities to empower us operating system and Environments - In this article, we'll show you how you can use these capabilities to remotely update GP policies.

Gpupdate & secedit

We must first mention the Gpupdate and Secedit tools, without these tools, none of the following would be possible. The scripts and tools that are mentioned here all assume that one of these tools is installed on the remote client, depending on the version of the operating system. As mentioned above, the Secedit tool is included with the Windows 2000 operating system, and the Gpupdate tool was taken from the Windows XP operating system and up, it is even present in the Longhorn operating system as it is now. In the following scripts, I'll focus on Gpupdate - we can check the operating system version before running Gpupdate or Secedit, but this check can be added later without too much difficulty.

The Gpupdate.exe file is by default located in the “% windir% \ system32” folder, so we don't need to know the absolute path to its location on the remote machine. The tool can be called with a set of different keys:

Syntax: Gpupdate

In our do-it-yourself scripts for HTML Application (HTA) and Windows Management Instrumentations (WMI), we will focus on running Gpupdate without keys - either with “/ Taget: Computer” (to update computer-specific policies) or “/ Target: User ”(to update user-specific policies). Other options can be enabled with a little work - but do we really need “/ Logoff” or “/ Boot”? This means that users can log out if necessary (setting software, changing folders, etc.) or you can even require a restart of the computer while the user is working. Is this really what we need? Anyway, we can also use a tool like Shutdown.exe for this purpose - so my opinion is not going to be too popular.

PsExec

The first method I want to talk about is very easy to use and requires little or no programming skill. Why come up with something that has already been invented, right? A tool called PsExec was developed by Mark Russinovich, the former owner of Sysinternals, which was bought out by Microsoft in July 2006. Version 1.73 is now available and can be downloaded from the Microsoft Technet website.

The PsExec tool is great when it comes about remote execution, mainly due to the fact that it does not require the installation of agents on the remote computer. You just need to specify the name of the computer and the command that you need to run along with the switches in the command line - and that's it!

A little trick is to put the PsExec.exe file in the "% windir%" directory because in this case, we do not need to specify the full path to this file when running it from the command line.

In order to update group policies on a remote machine, all we need to do is set ‘Computername’ (computer name) in the following command: “PsExec \\ Computername Gpupdate”. The user who is working on the remote machine will not even know what happened, but in the background the Gpupdate command will update the policies for the user and for the computer and apply any lost settings. You might think that the PsExec command needs to be run with the -i switch to update the user-specific policies for remote users, but testing shows that this is not necessary.

FLEX COMMAND Script

So, the method mentioned above allows you to update policies for a single user or computer, but what about updating an entire Organizational Unit (OU) by using PsExec and Gpupdate together? For this purpose, I created a demo script to show some of the possibilities that we can take advantage of through scripting. The script is called FLEX COMMAND and can be downloaded from here. You can easily open a file with HTA extension with text editor type Notepad and see the code, no hidden magic.

When FLEX COMMAND starts, it connects to the Active Directory AD-domain of the computer on which it is running. Therefore, it must be executed on a computer that is a member of the domain, otherwise the OU will not be found.

Select OU, the tool should be processed on machines that are "alive" (responding to WMI requests). The last thing to do is insert the command line that we want to run on the local machine for each object located in the selected OU. The text line “(C)” must be left as it is. it will be replaced with the name of the computer when the script is running.

Figure 2: FLEX COMMAND in action

Let's assume that the OU named “MyComputers” contains only 3 computers: Computer1, Computer2, and Computer3. The command we typed “psexec \\ (C) gpupdate” then translates into 3 following commands: “psexec \\ computer1 gpupdate”, “psexec \\ computer2 gpupdate”, “psexec \\ computer3 gpupdate” - all commands will be sequential executed (if the computers are "alive") and the deleted policies will be updated.

The tool can be modified so that the list of computers will come from a file (txt, csv, xls, etc.), a database, a special security group in AD, using manual selection from the list. The way the script is run can also be changed, it is just a demo script, the main purpose of which is to show the capabilities we have.

The script is distributed free of charge, and you can test, use and modify it at your discretion - details.

Windows Management Instrumentation (WMI)

Ok, the PsExec tool is really great, but are there any manual methods that I can use to better customize the solution for my environment? Yes, in fact there is! WMI is very powerful and easy to use after a few hours of study. If you own WMI and you are ok with firewall permissions and administrator rights, then you can do almost everything in Windows environment environment - even remotely shutting down the computer, rebooting and executing remote commands.

I created another script for demo purposes called OU GPUPDATE. This HTA script uses several different techniques Is actually a small modification of the FLEX COMMAND script. First, it parses the structure of the OU in AD (top drop-down list), gives users the ability to select computers from the OU, run Gpupdate with / Target: User or / Target: Computer or no parameters at all. Only live computers (which respond to WMI requests) will be affected by default.

Figure 3: Select what needs to be updated - User Settings, Computer Settings, or both

This script is free and you can test, use and modify it as you see fit from here.

Remote scripting

In addition to WMI, we have the ability to use conventional remote scripting (VBScript). This can be enabled by setting just one value in the HKLM part of the computer registry, and the scripting engine must support remote scripting, and from that point on, everything else becomes fairly obvious. The procedure is to copy the script file to the remote computer (this script must use Gpupdate) and then send a VBScript command that runs the script remotely.

RGPREFRESH

RGPREFRESH is a tool developed by Daren Mar-El. Its tool uses WMI and runs either Secedit or Gpupdate depending on the operating system on the remote machine, with keys selected by the user. These keys provide you with the same capabilities as when using this tool locally.

This tool processes one machine at a time, but together with a tool called FLEX COMMAND (as a shell), this tool can be used for an entire OU with just a few clicks ... Both RGPREFRESH and PsExec can also be used with DSQUERY , FOR and other command line utilities on more than one computer at a time.

Figure 4: Parameters for RGPREFRESH

This tool can be downloaded for free from this page.

Specops Gpupdate

Special Operations Software, Specops, an international software manufacturer, offers software products Active management Directory based on group policy technology. The company has released its own solution for remote policy updates, and the best part is that it is completely free. The current version of Specops Gpupdate is 1.0.2.13 (2006-10-25) and the utility itself can be downloaded from here. This tool not only has the functionality that we developed in the scenarios mentioned above, but it also adds several control capabilities. Let's take a look at this great utility ...

Installing Specops Gpupdate

Installing an MSI application is very easy - all it needs is Active Directory Users & Computers (ADUC) MMC users and computers, as well as Microsoft .NET Framework version 2.0.

Figure 5: The installation process is as easy as installation MSI packages(click on next, next, next)

After installation MSI file v graphical interface nothing changes the GUI, and only with the help of “Add / Remove Programs” you can find out that Specops is installed on our machine. Therefore, we have to do additional work for the magical transformation ...

Extension for Active Directory User & Computers

After installing Specops Gpupdate in the AD Forest, you need to run a special command

“% CommonProgramFiles% \ Specopssoft \ Specops ADUC Extension \ SpecopsAducMenuExtensionInstaller.exe” / add

This is not a schema update, although you must have corporate administrator rights to run this command. This command is completely reversible, just run it again with the “/ remove” switch. All it does is register so-called “Display Specifiers” to enhance the view with ADUC.

Then right-click on the OU or Computer object and you will see four new commands appear: Gpupdate, Restart, Shut down, and Start. It is possible to make a selection of several computers and OUs by holding down the key and pressing the right mouse button on the necessary objects.

Figure 6: ADUC MMC expanded

If you, like me, have a question whether the changes can also be applied to non-DC domain controllers, then the answer is yes! After Windows installations Server 2003 Admin Pack Service Pack 1 Administration Tools Pack on Windows client XP Professional, .NET Framework 2.0, and Specops Gpupdate, the management console looks the same as on a DC, and has the same capabilities.

Gpupdate options

The first parameter we have allows us to run the Gpupdate command remotely on selected computers. After selecting Gpupdate, we must confirm the selection, as shown in Figure 7, and check the use force option if we want to use the gain setting.

Figure 7

After clicking on the OK button, a dynamic graph will appear, see Figure 8, as well as a report on the status of the update progress.

Figure 8

Restart and Shutdown options

The next two parameters, 'Restart' and 'Shutdown', are very important to control, so we need them right in ADUC. We can run the restart or shutdown command, and also set the time interval in seconds that is given to the user to shut down everything. running applications... Writing a script that does all the same is not very difficult using WMI or using the Shutdown.exe command with the correct keys, but thanks to Specops Gpupdate, we get this functionality completely free of charge, no time or effort.

Figure 9: Reboot Message Dialog Box

Start Parameter The last of the four parameters is called 'Start' and is actually the Wake on LAN or WOL functionality built into the ADUC. After selecting and confirming this parameter, see Figure 10, the so called Magic packet will be sent to MAC addresses client computers and downloads will start. For WOL to work, the corresponding functionality must be supported BIOS of computers... Specops Gpupdate interacts with Microsoft DHCP servers in the corporation to find the information necessary to start this process, so it is possible to wake up DHCP clients and only on a network with installed servers Microsoft DHCP.

Figure 10: Confirm Start Remote WOL

By the way, you can also use scripts for WOL, examples of such code are beyond the scope of this article.

Conclusion

We looked at several ways in which you can apply group policies to remote computers. Which method is best for you depends on your environment. Personally, I love scripting, but why work hard on what other people have already created? I have two answers to this question. First, while writing such scripts, we learn, and the second - special conditions or custom-made. Scripting improves our skills as IT professionals and also allows for customization ready-made solutions to better suit specific conditions.

Specops has developed a very good free utility, which performs the main functions of updating policies on network clients... I recommend you try it!

Source www.windowsecurity.com