With the development of the Internet, constantly updating the operating system has become commonplace. Now developers can fix and improve the system throughout its entire support period. But frequent Windows 10 updates are not always convenient. That's why it would be good to be able to turn them off.

Reasons for turning off automatic updates

The reasons can be very different, and only you can decide how much you need to disable updates. It is worth considering that along with improvements to certain capabilities, important fixes for system vulnerabilities are supplied. And yet, situations when independent updates should be disabled arise quite often:

• paid Internet - sometimes the update is quite large and downloading it can be expensive if you pay for traffic. In this case, it is better to postpone the download and download later under other conditions;
• lack of time - after downloading, the update will begin to install while the computer is turned off. This can be inconvenient if you need to quickly shut down work, such as on a laptop. But what’s even worse is that sooner or later Windows 10 will require you to restart your computer, and if you don’t do this, then after some time the restart will be forced. All this distracts and interferes with work;
• security - although the updates themselves often contain important system changes, no one can ever foresee everything. As a result, some updates may open your system to virus attack, while others will simply break it right after installation. A reasonable approach in this situation is to update some time after the release of the next version, having previously studied the reviews.

Disable automatic Windows 10 updates

There are many ways to turn off Windows 10 updates. Some of them are very simple for the user, others are more complex, and others require the installation of third-party programs.

Disabling via Update Center

Using Update to disable it is not the best option, although Microsoft developers offer it as an official solution. You can actually turn off automatic downloading of updates through their settings. The problem here is that this solution will be temporary one way or another. The release of a major Windows 10 update will change this setting and bring back system updates. But we will still study the shutdown process:

After these changes, minor updates will no longer be installed. But this solution will not help you get rid of downloading updates forever.

When solving computer system security problems, one has to take into account a whole range of problems, one of which is timely updating of operating systems and software.

Introduction

To maintain the current state of the company's operating systems and information system software, they should be updated regularly. These actions can be performed from the Microsoft Update site on each client computer or through the use of the Windows Server Update Services (WSUS) server(s). If we are talking about a corporate network, then the recommended option is to use a WSUS server. When working with the above-mentioned service, a significant reduction in Internet traffic is achieved and the ability to centrally manage the process of deploying system patches and software received from Microsoft is provided.

I would like to additionally note that on March 23, 2011, Microsoft announced the release of a new product “Windows Intune”, one of the functions of which will be to perform those tasks for which WSUS was previously responsible.

To ensure that client computers can be updated, you must:

1. Design the solution

2. Deploy the WSUS server/servers;

3. Ensure regular synchronization of the WSUS server with the Microsoft Update resource;

4. Configure the operating parameters of the WSUS server/servers;

5. Create target groups and place client computers in target groups on the WSUS server.

6. Configure clients to use WSUS servers;

7. Ensure the security of the WSUS server/servers.

In this article we do not consider the stages of design and deployment, synchronization; we will talk about setting up clients and ensuring the security of the WSUS server.

Configuring update server clients without using group policies

There are three ways to configure clients to use a WSUS server:

1. Using Group Policy;
2. Using local computer policy;
3. Direct changes to the register of client stations.

The best way is to use Group Policy Objects, see fig. 1 associated with the required AD (Windows 2003) or AD DS (Windows 2008) container, but this option is only available if your organization has Active Directory deployed. Group Policy's capabilities for setting up interaction with the management server and managing client update procedures fully meet the administrator's needs. What we can verify by looking at Fig. 1. The list of available settings is quite wide.

Rice. 1. WSUS client settings.

If the directory service is not deployed in the organization, then the ability for the client to interact with WSUS can be implemented either through a local policy or by “directly” making changes to the system registry of the workstation or server whose state we want to ensure is up to date. In essence, a policy is nothing more than an interface to the registry.

Circumstances in which workstations and servers are not AD clients can arise in a variety of cases, for example:

· Use of third-party directory services, however, solutions based on Microsoft operating systems are used as application servers, file servers, and client workstations;

· The need to build a “guest” zone to provide access to “external” users to the Internet;

· Insufficient maturity of the company, due to which a centralized directory service has not been deployed, or lack of need for this service.

1. It is necessary to host the update service on the intranet and a statistics server, as well as distribute clients into groups.

In the registry section

you will need to specify the address or name of the update server to which the client will connect and the port number that is selected to work with the WSUS server. By default, port 80 is assumed.

"WUStatusServer"=http://192.168.1.100

Since it is required to place client computers into target groups, we must indicate which of the target groups the computer should be placed in:

"TargetGroupEnabled"=dword:00000001

In our version, the target group is called “WSUS-Test-WKS”. For clients whose target group name will be different, this field will have a different value. The TargetGroupEnabled parameter in this case provides control of placement in a group from the client side.

To do this, in the registry section

"TargetGroup"="WSUS-Test-WKS"

"TargetGroupEnabled"=dword:00000001

"WUServer"="http://192.168.1.100"

"WUStatusServer"="http://192.168.1.100"

"NoAutoUpdate"=dword:00000000

"AUOptions"=dword:00000004

"ScheduledInstallDay"=dword:00000000

"ScheduledInstallTime"=dword:00000009

"UseWUServer"=dword:00000001

"RescheduleWaitTime"=dword:00000001

" NoAutoRebootWithLoggedOnUsers"=dword:00000000

By ensuring that the specified file is delivered and executed, we can configure WSUS server clients without resorting to using group policies. A description of all registry variables that can be used to work with the update server and their possible values ​​is provided in the Windows Server Update Services 3.0 SP2 Deployment Guide.

To ensure the security of the update server itself, it makes sense to follow a number of simple recommendations:

1. If we need to ensure secure information exchange between clients and servers and/or between WSUS servers, then it is possible to use the SSL protocol. See "Securing WSUS with the Secure Sockets Layer" in the Windows Server Update Services Deployment Guide (). In the absence of network exchange between servers, data transfer is provided via external media. An alternative method of protection, if it is not possible to use SSL, is to use the IPsec protocol. See "Overview of IPsec Deployment" http://go.microsoft.com/fwlink/?LinkId=45154.

2. The WSUS server that synchronizes with Microsoft Update should be placed behind a firewall and should only be accessible to hosts that actually need it. See "Configure the Firewall" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

3. Regarding file access, you should not grant excessive permissions to resources; a description of access rights requirements is given in the “Before You Begin” section in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/ ?LinkId=79983).

4. If the update server has access to the Internet (in some cases this may not be the case, for example, synchronization is being performed with another WSUS server that has this capability), then it is recommended to place its database on another computer, which cannot be accessed from outside. See "Appendix B: Configure Remote SQL" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

5. To manage the WSUS server, it is wise to use the built-in WSUS Administrators group, which will be created during deployment.

Leonid Shapiro.

Bibliography.

Anita Taylor Windows Server Update Services 3.0 SP2 Deployment Guide.

Anita Taylor Windows Server Update Services 3.0 SP2 Operations Guide

[i]DMZ - demilitarizedzone

Not everything is covered here, but only the basic settings for configuring the WSUS client.

You can specify the path to the required servers either using the address, which was done in the example given, or using the server name, while providing for the possibility of resolving the server name to its IP address.

This is the abstract name of the test group.

In one of the previous articles we described the procedure in detail. After you have configured the server, you need to configure Windows clients (servers and workstations) to use the WSUS server to receive updates, so that the clients receive updates from the internal update server rather than from Microsoft Update servers over the Internet. In this article, we will walk through the procedure for configuring clients to use a WSUS server using Active Directory domain group policies.

AD Group Policies allow an administrator to automatically assign computers to different WSUS groups, eliminating the need to manually move computers between groups in the WSUS console and keep those groups up to date. Assignment of clients to different WSUS target groups is based on a registry label on the client (labels are set by Group Policy or by directly editing the registry). This type of assignment of clients to WSUS groups is called clientsidetargeting(Client-side targeting).

It is assumed that our network will use two different update policies - a separate update installation policy for servers ( Servers) and for workstations ( Workstations). These two groups need to be created in the WSUS console in the All Computers section.

Advice. The policy for how clients use the WSUS update server largely depends on the organizational structure of the OU in Active Directory and the organization's update installation rules. In this article, we will look at just a particular option that allows you to understand the basic principles of using AD policies to install Windows updates.

First of all, you need to specify a rule for grouping computers in the WSUS (targeting) console. By default, in the WSUS console, computers are manually distributed by the administrator into groups (server side targeting). We are not happy with this, so we will point out that computers are distributed into groups based on client side targeting (by a specific key in the client registry). To do this, in the WSUS console, go to the section Options and open the parameter Computers. Change the value to Use Group Policy or registry setting on computers(Use Group Policy or registry settings on computers).

You can now create a GPO to configure WSUS clients. Open the domain Group Policy Management console and create two new group policies: ServerWSUSPolicy and WorkstationWSUSPolicy.

WSUS Group Policy for Windows Servers

Let's start with a description of the server policy ServerWSUSPolicy.

Group policy settings responsible for the operation of the Windows Update service are located in the GPO section: ComputerConfiguration -> Policies-> Administrativetemplates-> WindowsComponent-> WindowsUpdate(Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update).

In our organization, we expect to use this policy to install WSUS updates on Windows servers. It is expected that all computers covered by this policy will be assigned to the Servers group in the WSUS console. In addition, we want to prevent automatic installation of updates on servers when they are received. The WSUS client must simply download available updates to disk, display an alert for new updates in the system tray, and wait for an administrator to initiate installation (either manually or remotely using ) to begin installation. This means that productive servers will not automatically install updates and reboot without administrator approval (usually these works are performed by the system administrator as part of monthly scheduled maintenance). To implement such a scheme, we will set the following policies:

• ConfigureAutomaticUpdates(Setting automatic update): Enable. 3 – Autodownloadandnotifyforinstall(Automatically download updates and notify you when they are ready to install)– the client automatically downloads new updates and notifies about their availability;
• SpecifyIntranetMicrosoftupdateservicelocation(Specify intranet Microsoft Update location): Enable. Set the intranet update service for detecting updates: http://srv-wsus.site:8530, Set the intranet statistics server: http://srv-wsus.site:8530– here you need to specify the address of your WSUS server and statistics server (usually they are the same);
• No auto-restart with logged on users for scheduled automatic updates installations(Do not automatically reboot when installing updates automatically if there are users running on the system): Enable– prohibit automatic reboot when there is a user session;
• Enableclient-sidetargeting ( Allow client to join target group): Enable. Target group name for this computer: Servers– in the WSUS console, assign clients to the Servers group.

Note. When setting up an update policy, we recommend that you carefully familiarize yourself with all the settings available in each of the options in the GPO section WindowsUpdate and set the parameters that suit your infrastructure and organization.

WSUS Update Installation Policy for Workstations

We assume that updates on client workstations, in contrast to the server policy, will be installed automatically at night immediately after receiving updates. After installing updates, computers should reboot automatically (warning the user 5 minutes in advance).

In this GPO (WorkstationWSUSPolicy) we specify:

• AllowAutomaticUpdatesimmediateinstallation(Allow immediate installation of automatic updates): Disabled- prohibition on immediate installation of updates when they are received;
• Allownon-administratorstoreceiveupdatenotifications(Allow non-admin users to receive update notifications): Enabled- display a warning to non-administrators about new updates and allow their manual installation;
• Configure Automatic Updates:Enabled. Configure automatic updating: 4 - Auto download and schedule the install. Scheduled install day: 0 - Everyday. Scheduled install time: 05:00 – when new updates are received, the client downloads them to the local cache and schedules their automatic installation at 5:00 am;
• Target group name for this computer: Workstations– in the WSUS console, assign the client to the Workstations group;
• No auto-restart with logged on users for scheduled automatic updates installations: Disabled- the system will automatically reboot 5 minutes after the update installation is completed;
• Specify Intranet Microsoft update service location: Enable. Set the intranet update service for detecting updates: http://srv-wsus.site:8530, Set the intranet statistics server: http://srv-wsus.site:8530–address of the corporate WSUS server.

On Windows 10 1607 and above, even though you have told them to get updates from internal WSUS, they may still try to contact Windows Update servers on the Internet. This "feature" is called DualScan. To disable receiving updates from the Internet, you must additionally enable the policy DonotallowupdatedeferralpoliciestocausescansagainstWindowsUpdate ().

Advice. To improve the “level of patching” of computers in an organization, both policies can be configured to force the start of the update service (wuauserv) on clients. To do this, in the section Computer Configuration -> Policies-> Windows Settings -> Security Settings -> System Services Find the Windows Update service and set it to start automatically ( Automatic).

Assigning WSUS policies to Active Directory OUs

The next step is to assign the created policies to the appropriate Active Directory containers (OUs). In our example, the OU structure in the AD domain is as simple as possible: there are two containers – Servers (it contains all the organization’s servers, in addition to domain controllers) and WKS (Workstations – user computers).

Advice. We are considering only one fairly simple option for binding WSUS policies to clients. In real organizations, it is possible to bind one WSUS policy to all computers in a domain (a GPO with WSUS settings is attached to the root of the domain), to distribute different types of clients across different OUs (as in our example - we created different WSUS policies for servers and workstations), in large distributed domains can be linked, or assigned GPOs based on, or a combination of the above methods.

To assign a policy to an OU, click on the desired OU in the Group Policy Management Console and select the menu item Link as Existing GPO and select the appropriate policy.

Advice. Do not forget about a separate OU with domain controllers (Domain Controllers); in most cases, the WSUS “server” policy should be assigned to this container.

In exactly the same way, you need to assign the WorkstationWSUSPolicy policy to the AD WKS container in which Windows workstations are located.

All that remains is to update group policies on clients to bind the client to the WSUS server:

All Windows update system settings that we set using group policies should appear in the client registry in the branch HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.

This reg file can be used to transfer WSUS settings to other computers that cannot configure update settings using GPO (computers in a workgroup, isolated segments, DMZ, etc.)

Windows Registry Editor Version 5.00

"WUServer"="http://srv-wsus.site:8530"
"WUStatusServer"="http://srv-wsus.site:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
"ElevateNonAdmins"=dword:00000000

"NoAutoUpdate"=dword:00000000 –
"AUOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"ScheduledInstallEveryWeek"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001

It is also convenient to control the applied WSUS settings on clients using rsop.msc.

And after some time (depending on the number of updates and the bandwidth of the channel to the WSUS server), you need to check in the tray for pop-up notifications about the presence of new updates. Clients should appear in the WSUS console in the appropriate groups (the table displays the client name, IP, OS, the percentage of them “patched” and the date of the last status update). Because We have assigned computers and servers to various WSUS groups by policies; they will only receive updates approved for installation in the corresponding WSUS groups.

Note. If updates do not appear on the client, it is recommended to carefully examine the Windows Update Service log on the problematic client (C:\Windows\WindowsUpdate.log). Please note that Windows 10 (Windows Server 2016) uses . The client downloads updates to the local folder C:\Windows\SoftwareDistribution\Download. To start searching for new updates on the WSUS server, you need to run the command:

wuauclt/detectnow

Also, sometimes you have to forcefully re-register the client on the WSUS server:

wuauclt /detectnow /resetAuthorization

In particularly difficult cases, you can try to fix the wuauserv service. If this occurs, try changing the frequency of checking for updates on the WSUS server using the Automatic Update detection frequency policy.

In the next article we will describe the features. We also recommend that you read the article between groups on a WSUS server.

Published on February 18, 2009 by · No comments

In this article, I will tell you about some registry keys that are associated with Windows Update. I'll show you the different options that these registry keys can take.

If you missed the second part of this article, then please read

While both Windows Update and WSUS are generally fairly easy to configure, you can sometimes gain more control by making some changes to the Windows registry. In this article, I will show you some registry keys that are associated with Windows Update. I'll show you the different options that these registry keys can take.

To start

First, I'll make the lawyers happy and warn that making changes to the registry can be very dangerous. Entering incorrect registry settings can lead to the destruction of Windows and/or any running applications on the machine. Before attempting to make changes to the registry, you must make a full backup of the system, I am ready to show you how this is done.

There is one more thing I need to tell you about. The fine-tuning that I want to tell you about only applies to computers running Windows XP. You can make changes to specific machines directly, or you can apply them as part of a login script. Also, some of the keys I'll talk about may not exist by default. If you want to use a key that doesn't exist, you must first create it. You should also know that Windows update behavior can be controlled using group policy. Group policies can sometimes modify registry keys so that they follow the behavior they specify.

Privilege escalation

One of the problems with getting updates from a WSUS server is that users cannot approve or deny updates unless they are members of the local administrators group. However, you can use the registry to elevate users' privileges so that they can install or refuse to install changes, regardless of whether they are members of the local administrator group or not. On the other hand, you can also prevent users from installing updates and leave this right to the administrator (Admin).

The registry key that is responsible for this is: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\ElevateNonAdmins

The ElevateNonAdmins key has two possible values. The default value of 1 allows non-administrator users to install updates. If you change this value to 0, only administrators will be able to install updates.

Target Groups

One of the great things with WSUS is that it allows for client side targeting. The idea with client-side positioning is that you can define different computer groups, and distribute rights to install updates depending on group membership. By default, client side positioning is not used, but if you choose to use it, there are two registry keys that will help you do this. The first of these keys includes client side targeting, and the other indicates the name of the group to which the computer belongs. Both of these keys must be created in: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\

The first key is a DWORD key called TargetGroupEnabled. You can set this key to 0, which disables client side targeting, or 1, which enables client side targeting.

The other key you should create should be called TargetGroup and have a string value. The value of this key must be the name of the group to which the computer should be assigned.

Installing a WSUS Server

If you've been involved with the web for a bit, then you probably know that web design tends to change over time. Things like company growth, new security requirements, and corporate restrictions often form the basis for network changes. How does this apply to Windows updates? WSUS is scalable and can be installed in a hierarchical manner. This means that an organization may have multiple WSUS servers installed. If a PC is moved to another part of the company, the WSUS server that was originally defined for that computer may no longer be appropriate for the new location. Fortunately, a few simple registry modifications can change the WSUS server from which the PC receives updates.

There are two keys that are used to identify the WSUS server. Each of them is located in: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\. The first key is called WUServer. This key must be set to a text value that describes the WSUS server URL (for example: http://servername).

Another key you should change is a key called WUStatusServer. The idea with this key is that the computer (PC) should report its status to the WSUS server so that the WSUS server can know what changes have been installed on the computer. The WUStatusServer key usually contains the exact same value as the WUServer key (for example: http://servername).

Automatic Update Agent

So, I've talked about how to connect a computer (PC) to a specific WSUS server or for a specific group (target group), but that's only half the process. Windows Update uses an update agent that actually installs updates. There are several registry keys located in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU that control the automatic update agent.

The first of these keys is the AUOptions key. This DWORD value can be set to 2, 3, 4, or 5. A value of 2 means that the agent should notify the user when updates are downloaded. A value of 3 means that the update will be downloaded automatically and the user will be notified about installation. A value of 4 means that the update should be automatically downloaded and installed as scheduled. In order for this option to work, you must also set the values ​​for the ScheduledInstallDay and ScheduledInstallTime keys. I'll talk more about these keys later. Finally, a value of 5 means that automatic updating is required, but it can be configured by end users.

The next key I want to talk about is the AutoInstallMinorUpdates key. This key can have the value 0 or 1. If the key value is 0, then minor updates are processed the same as any other updates. If the key value is 1, then minor updates are installed silently in the background.

Another key related to the Automatic Update Agent is the DetectionFrequency key. This key allows you to set how often the agent should check for updates. The key value must be an integer from 1 to 22, which reflects the number of hours between attempts to request an update.

The registry key associated with it is the DetectionFrequencyEnabled key. As the name suggests, this key allows you to enable or disable the Detection Frequency function. If you set the value of this key to 0, then the value of the DetectionFrequency key will be ignored, and if you set the value of this key to 1, then the agent will have to use the value of the DetectionFrequency key.

The next key I want to talk about is the NoAutoUpdate key. If the value of this key is 0, then automatic updating is enabled. If the key value is 1, then automatic updating is disabled.

The last registry key I want to talk about is the NoAutoRebootWithLoggedOnUsers key. As you probably know, some updates may not take effect without rebooting the system. If the user is working at this time, then a reboot may be very undesirable. This is especially true if the user has walked away from their desk and has not saved their work. In this case, the NoAutoRebootWithLoggedOnUsers key will help. The value of this key can be 0 or 1. If the value of the key is 0, then users will receive a 5 minute warning before the system automatically reboots. If the key value is 1, then users will simply receive a message asking for permission to reboot, but users can choose to do so at their own discretion.

Conclusion

There are many more registry keys related to Windows Update. I will talk about the rest of them in the second part of this article.

www.windowsnetworking.com

See also:

Readers Comments (No comments)

Exchange 2007

If you would like to read the previous parts of this article series, please follow the links: Monitoring Exchange 2007 Using System Manager...

Introduction In this multi-part article, I want to show you the process I recently used to migrate from an existing Exchange 2003 environment...

If you missed the first part of this series, please read it at Using the Exchange Server Remote Connectivity Analyzer Tool (Part...

If you missed the previous part of this article series, go to Monitoring Exchange 2007 with System Center Operations Manager...

This article summarizes the methods known to me for fixing the WSUS agent.

1. The first script is the simplest, and, in fact, is not even used for treatment, but in order to forcefully run an update check, and, at the same time, cleans the folder in which distributions of already installed updates accumulate:

wsus_detect_manual.cmd

net stop wuauserv && net stop bits && net stop cryptsvc

net start wuauserv && net start bits && net start cryptsvc

wuauclt.exe /detectnow exit

2. The second script is needed in order to “revive” the idle WSUS service. It cleans out old updates, after which the SoftwareDistribution and Catroot2 folders are renamed, which will lead to their re-creation when the service is restarted. Then the system dll libraries are re-registered.

fix_wsus_service.cmd

net stop bits
net stop wuauserv
net stop cryptsvc

del /f /s /q %windir%\SoftwareDistribution\download\*.*

ren %systemroot%\System32\Catroot2 Catroot2.old
ren %systemroot%\SoftwareDistribution SoftwareDistribution.old

REM del /f /s /q %windir%\SoftwareDistribution\*.*

del /f /s /q %windir%\windowsupdate.log

%windir%\system32\regsvr32.exe /U /s %windir%\system32\vbscript.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\mshtml.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msjava.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msxml.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\actxprxy.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\shdocvw.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wintrust.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\initpki.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\dssenh.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\rsaenh.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\gpkcsp.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\sccbase.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\slbcsp.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\cryptdlg.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Urlmon.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Oleaut32.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msxml2.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Browseui.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\shell32.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Mssip32.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\atl.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\jscript.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msxml3.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\softpub.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuapi.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuaueng.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuaueng1.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wucltui.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wups.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wups2.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuweb.dll

%windir%\system32\regsvr32.exe /s %windir%\system32\vbscript.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\mshtml.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msjava.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msxml.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\actxprxy.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\shdocvw.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wintrust.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\initpki.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\dssenh.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\rsaenh.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\gpkcsp.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\sccbase.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\slbcsp.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\cryptdlg.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Urlmon.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Oleaut32.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msxml2.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Browseui.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\shell32.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Mssip32.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\atl.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\jscript.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msxml3.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\softpub.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuapi.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuaueng.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuaueng1.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wucltui.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wups.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wups2.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuweb.dll

net start bits
net start wuauserv
net start cryptsvc

wuauclt/detectnow

exit

3. This script is used in cases where the computer was recently cloned, or in cases where the computer never registered with WSUS. It differs from the previous one only in the penultimate line, in which authorization is reset and the identifier is regenerated. I'll just quote this line:

wsus_resetaut_detect_manual.cmd

wuauclt.exe /resetauthorization /detectnow

AU_Clean_SID.cmd

@echo on
net stop wuauserv
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
net start wuauserv
wuauclt /resetauthorization /detectnow

5. Sometimes, in order for everything to work, you need to reinstall the WSUS agent. First you need to download the latest Windows Update Agent, and then install the appropriate edition

for x32 versions of Windows

windowsupdateagent30-x86.exe /wuforce

for x64 versions of Windows

windowsupdateagent30-x64.exe /wuforce

If you are a happy owner of Itanium, you can guess for yourself :-)

After installing the agent, you must reboot.

6. To “treat” errors 0x80070005, i.e. access errors, the script below may be useful. It restores administrator and system access to the registry and system folders.

To run this script you will need the Microsoft utility subinacl.exe. It is included in the resource kit for Windows Server 2003, but you should not use the version that is included there, because There are some nasty bugs there. You should download subinacl.exe version 5.2.3790.1180.

Restore_registry_and_system_permission.cmd

@echo off
REM Apply for errors 0x80070005 Windows Update
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
subinacl /subdirectories %SystemDrive% /grant=administrators=f
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
subinacl /subdirectories %SystemDrive% /grant=system=f

All these scripts can be executed almost automatically if problems arise. If, as a result, the problem is not solved, then you have to look into it more closely. And here we will need the same windowsupdate.log, which is in the root of the Windows folder. If the computer is problematic, then this file is large. For simplicity, it is advisable to remove it before running scripts. Almost all scripts provide a command to remove it, but not everything is so simple. Despite the stop of the wuauserv service, usually it continues to be open in IE, etc. Therefore, there is a tricky way. I'm launching

notepad.exe %windir%\windowsupdate.log

I select all the text, delete it and save it instead of the old file (don’t forget to change the file type to *.* in the save dialog, otherwise the default is *.txt)

It is worth noting that there are cases when it is not possible to force the client to update from wsus. I have precedents with a couple of Windows Server 2003 R2 that I have not been able to overcome. That's why I update them via the Internet :-)

Fresh operating systems such as Windows 7, Windows 2008 sometimes have difficulty starting. For such cases, empirically, an algorithm like:
1. Update for the first time from the Microsoft website with agent update
2. Then we update the agent locally
3. And then everything starts working

I hope that the fruits of our labors will help someone.

For simplicity, I post all these scripts in ready-made form: