GPO update. GPUPDATE—performing group policy updates for the user and computer

Resume: Microsoft Scripting Guy, Ed Wilson shows how to force a Group Policy update using PowerShell.

Updating Group Policy in a Domain

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

To update Group Policy settings I use the utility GPUpdate. It has some parameters. By default, the utility updates both the computer and user policies. But this can be controlled using the parameter /target. For example, if I need to update only the computer policy, I will specify /target:computer. To update only the 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 following command updates all Group Policy settings (whether or not they have been changed) for the computer and 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 Active module Directory.

Note: The Active Directory module is included with RSAT.

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

$cn = Get-ADComputer -filt *

Secondly, 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.

To start, I'll use the cmdlet Get-Credentials and store the object returned by it in the $cred variable.

$cred = Get-Credential iammred\administrator

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

You must remember that there may be computers in the domain that are turned off, so when executing the command, errors may be returned. However, despite the errors, Windows PowerShell creates sessions with work computers.

Availability large number errors may cause some concern. Since the session objects are stored in the $sessions variable, I can easily verify that they have been 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 the cmdlet Invoke-Command – icm.

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

After running the command, the results are displayed in Windows console PowerShell.

Checking for a Group Policy update

When on workstation Group Policy settings are successfully updated and an event with code 1502 is recorded in the System log. I can use the cmdlet Invoke-Command to obtain 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 interesting thing about Group Policy

Sometimes I have to call tech support and they ask me to update Group Policy on my local computer. This is not a problem since I can run GPUpdate straight from PowerShell. The difficulty comes when they ask me to update Group Policy 5 times at 5 minute intervals. But this can also be solved with one 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 a simple way to update remotely. group policies on clients (computers and servers) of the Active Directory domain, without the need to access the console of the remote machine and without using the gpupdate command.

One of the most difficult problems in managing AD group policies is testing policies on the fly, without rebooting the computer or accessing the local computer and running the command.

The Remote Group Policy Update feature provides the ability to use a single GPO management console (GPMC.msc) to create, edit, apply, and test group policies.

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

Requirements for Remote Group Policy Update to work:

Server environment requirements:

• Windows Server 2012 and higher
• Or Windows 10 with RSAT management tools installed

Requirements for clients:

• Windows 7 and above

Requirements for network communication (firewalls) between the server and clients

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

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

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

In the window that opens, information will appear on the number of objects in this OU 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 limited by a firewall, a corresponding error will appear.

· No comments

Updating Microsoft Windows Group Policy settings on a local machine is not very difficult to do using a tool like Gpupdate, but updating these policies on remote computers in a domain cannot be done using either the Microsoft Management Console (MMC) or any currently available Microsoft products. In this article, I'll walk you through various tricks, scripts, and free tools that let you update group policy settings on remote computers in a 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 that GP group policy to appear on the 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 left to our own devices. Of course, there is a reason why policies are not simply updated every five minutes or even in real time. The load on the domain controllers and network will be too much to handle in most environments. But if you need to quickly apply a very important security setting to a large number of clients, then it would be a good idea to prepare for this situation.

What we really need is to provide the ability for an administrator to update policies on Computer1, Computer2, and/or Computer3—as well as policies for Users A, B, and C—from a centralized point—the administrator's workstation—if the administrator deems it necessary . Look at Figure 1.

Figure 1: Scenario

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

If your network does not have such a system, then you should try more creative approaches - because... The alternative is to log into all the necessary computers using a tool like Remote Assistance, or send all email asking you to run the Gpupdate command... So look for more creative approaches.

Problems

Before we get into details, I want to mention common problems problems that people encounter when trying to use the methods mentioned in this article.

Firewall issues:

As with other connections that are initiated on a network, packets that attempt to update policy settings on remote computers will not be able to penetrate the local firewall on the remote computers (such as the firewall that is built into the Windows operating system starting with Windows XP Service Pack 2 and higher) unless the firewall is configured to allow such incoming traffic (from a selected subnet, IP, or something like that). Built into the operating system Windows firewall must be configured to allow incoming traffic that we shape using the group policy object, so, ironically, this policy is the only one that we cannot use for remote computers with the firewall enabled.

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

Computer Settings | Administrative Templates | Network | Network Connections | Windows Firewall| Domain Profile | “Windows Firewall: Allow remote administration exception.”

Other devices that act as a firewall between the central computer and remote computers must also respect the above settings (see the 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, things will not work as you expect.

Now that you've taken care of all that, let's look at the methods themselves.

Script writing

Scripts are free and widely distributed among software professionals. information technology the Internet is truly “Open Source”. Microsoft has provided us with several built-in features to expand our capabilities. operating system and environment - in this article we will talk about how you can use these capabilities to remotely update GP group policies.

Gupdate & Secedit

First we must 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 operating system version. 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 higher, it is even present in the Longhorn operating system as it is now. In the following scenarios 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 much difficulty.

The Gpupdate.exe file is located in the “%windir%\system32” folder by default, so we do not 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 DIY scripts for HTML Application (HTA) and Windows Management Instrumentations (WMI), we'll focus on running Gpupdate without switches—or with the switches “/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 may even require a computer restart while the user is working. Is this really what we need? In any case, we can also use a tool like Shutdown.exe for these purposes - so my opinion is that it won't be too popular.

PsExec

The first method I want to talk about is very easy to use and requires virtually no programming skills. Why invent something that has already been invented, right? The tool, called PsExec, was developed by Mark Russinovich, the former owner of Sysinternals, which was acquired by Microsoft in July 2006. Version 1.73 is currently available and can be downloaded from the Microsoft Technet website.

The PsExec tool is great when it comes to remote execution, mainly because it doesn't require any agents to be installed on the remote machine. You just need to specify the computer name and the command that needs to be run along with the switches on the command line - that's it!

A little trick is to place the PsExec.exe file in the “%windir%” directory, because in this case we don't need to specify full path to this file when running it from command line.

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

FLEX COMMAND script

So, the method mentioned above allows you to update the policies for a single user or computer, but what about updating the entire Organizational Unit (OU) thanks to sharing PsExec and Gpupdate? For these purposes, I have created a demo script to show some of the capabilities 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 using text editor like 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 a domain, otherwise the OU will not be found.

Select the OU, the tool should be processed on machines that are “live” (responding to WMI requests). The last thing to do is to insert the command line that we want to execute on the local computer for each object located in the selected OU. The text line “(C)” must be left because it will be replaced by the computer name when the script runs.

Figure 2: FLEX COMMAND in action

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

The tool can be modified in such a way 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 launched 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)

Okay, the PsExec tool is really great, but are there any manual methods I can use to better customize the solution for my environment? Yes, actually there is! WMI is very powerful and quite easy to use after a few hours of learning. If you are proficient with WMI and have your firewall permissions and administrative rights in order, then you can do almost anything in the Windows environment - even remotely shutting down the computer, rebooting, and executing remote commands.

I created another script for demonstration purposes called OU GPUPDATE. This HTA script uses several various techniques– this is actually a slight modification of the FLEX COMMAND script. First, it parses the OU structure in AD (top drop-down list), gives users the option to select computers from the OU, run Gpupdate with the “/Target:User” or “/Target:Computer” parameter, or no parameters at all. Only "live" machines (that respond to WMI requests) will be affected by default.

Figure 3: Select whether to update User Settings, Computer Settings, or both

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

Remote scripting

In addition to WMI, we have the option of using regular remote scripting (VBScript). This can be enabled by setting just one value in the HKLM portion of the computer's registry, and the scripting engine must support remote scripting, and from this point everything else becomes fairly obvious. The procedure is to copy the script file to the remote computer (the 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. His tool uses WMI and runs either Secedit or Gpupdate depending on the operating system on the remote computer, with keys selected by the user. These keys provide you with the same functionality as if you were using the tool locally.

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

Figure 4: Options for RGPREFRESH

This tool can be downloaded for free from this page.

Specops Gpupdate

Special Operations Software, Specops, an international software manufacturer, offers Active Directory management products based on group policy technology. The company has released its own solution for remote policy updating, and the best thing 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 we developed in the scripts mentioned above, but also adds several management capabilities. Let's take a look at this wonderful utility...

Installing Specops Gpupdate

Installing an MSI application is very simple - all it requires is an Active Directory Users & Computers (ADUC) MMC user and a Microsoft . NET Framework version 2.0.

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

After installing the MSI file in graphical interface nothing changes in the GUI, and only with the help of “Add/Remove Programs” can we find out that Specops is installed on our machine. Therefore, we must do extra work for the magical transformation...

Extension for Active Directory Users & 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 Enterprise Administrator rights to run this command. This command is absolutely reversible, just run it again with the “/remove” switch. All it does is register so-called “Display Specifiers” to enhance viewing using 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 select several computers and OUs by holding down the key and clicking the right mouse button on the required objects.

Figure 6: ADUC MMC expanded

If you, like me, have a question about 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 a Windows XP Professional client, .NET Framework 2.0 and Specops Gpupdate, the management console looks the same as on a DC domain controller and has the same capabilities.

Gpupdate options

The first option 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 box if we want to use the gain setting.

Figure 7

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

Figure 8

Restart and Shutdown options

The next two parameters 'Restart' and 'Shutdown' are very important for control, so we need them directly in ADUC. We can run the restart (reboot) or shutdown (shutdown) command, and also set the time interval in seconds that is given to the user to close everything running applications. Writing a script that would do all the same things is not very difficult using WMI or using the Shutdown.exe command with the correct switches, but thanks to Specops Gpupdate we get this functionality completely free without the investment of time and 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 ADUC. After selecting and confirming this parameter, see Figure 10, the so-called Magic packets will be sent to the MAC addresses of the client computers and downloading will begin. For WOL to work, the corresponding functionality must be supported Computer BIOS. Specops Gpupdate interacts with the Microsoft DHCP servers in the corporation to find the information needed to run this process, so it is possible to wake up DHCP clients and only on the network with installed servers Microsoft DHCP.

Figure 10: Confirm launch of remote WOL

By the way, scripts can also be used for WOL; examples of such code are beyond the scope of this article.

Conclusion

We've looked at several ways you can apply group policies to remote computers. Which method is best for you depends on your environment. Personally, I enjoy screenwriting, but why bother working hard on something that other people have already created? I have two answers to this question. The first is that we learn while writing such scripts, and the second is special conditions or custom production. Scripting improves our skills as information technology professionals and also allows us to customize ready-made solutions to better suit specific conditions.

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

Source www.windowsecurity.com

Setting the Windows 10 update policy is setting the way Windows 10 receives updates. In Windows 10, Update settings have been moved from Control Panel to System Settings. In Windows 10, there are no such settings as there were in the Control Panel and therefore it is no longer possible to disable updates or choose how to receive them. However, you can use Registry Editor and Local Group Policy Editor to disable updates and set how you receive them.

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 update group policy

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

Setting up Windows 10 updates group policies

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

Once you've finished setting up Windows 10 policies, run the update

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

Setting Up 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 settings there to control Windows updates 10

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

For the AUOptions parameter

• 2 - Receive a notification before installing and downloading any updates.
• 3 - Automatically receive updates and notifications when they are ready for installation.
• 4 - Automatically receive and install updates according to a specified schedule.
• 5 - Allow local administrators to choose the update mode and notifications themselves.

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 if the AUOptions parameter is set to 4.
• 1—updates will be installed every Monday if the AUOptions parameter is set to 4.
• 2 — updates will be installed every Tuesday with the AUOptions parameter set to 4.
• 3 — updates will be installed every Wednesday with the AUOptions parameter set to 4.
• 4—updates will be installed every Thursday if the AUOptions parameter is set to 4.
• 5 — updates will be installed every Friday if the AUOptions parameter is set to 4.
• 6 — updates will be installed every Saturday with the AUOptions parameter set to 4.
• 7 — updates will be installed every Sunday with the AUOptions parameter set to 4.

For the ScheduledInstallTime parameter

From 0 to 23, updates will be installed in as many hours depending on the set parameter and if the AUOptions parameter is set to 4.

For the NoAutoRebootWithLoggedOnUsers parameter

• 0 — When the update installation is complete, the computer will automatically reboot; it works with the AUOptions parameter set to 4.
• 1 - When the update installation is complete, the computer will not reboot automatically; it works with the AUOptions parameter set to 4.