The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interface can all use the registry. In this article, you will learn how to target WSUS clients with registry keys. Please see WSUS Setup: How to configure Windows server update services, and Client Visibility Issues: Fix WSUS Clients appear then disappear in the console.
Here are some related WSUS contents. Handy WSUS Commands(Windows Server Update Services Commands, WAUACLT, PowerShell and USOClient). Also, see how to Start, Stop and Restart Windows Server Update Services (WSUS) via PowerShell and CMD.
The below syntax should be saved with the .reg extension and in order to create the registry keys. In this step. I will be using the registry key as this can also be used to point the server to the Upstream server.
Create the registry key and save it anywhere on your PC. Next, double-click to run the reg file created, and reboot your PC.
Here is what the registry settings would look like, you can modify this by specifying the IP address. In the previous example, I used the local group policy. For more articles written by me on the Windows registry, see the following hyperlinks. What is Registry Editor and how to access the registry hives? and how to search through the Windows registry.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"ElevateNonAdmins"=dword:00000001
"WUServer"="http://x.x.x.x:8530"
"WUStatusServer"="http://x.x.x.x6:8530"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000f
"AutoInstallMinorUpdates"=dword:00000001
"UseWUServer"=dword:00000001For more articles I have written, see the following hyperlinks: Configuring WSUS Email Notification to Work With Office365, How to setup and configure Windows server update services (WSUS), and Important Areas to Master on WSUS (Installed and not applicable, Install 1/4, and Installed / Not applicable 100)
Run the created Registry Key
After saving the file with the .reg extension and running it, these entries will be created in the registry
Note: You can also use the local group policy alongside additional options.
In order to be reported and have the WSUS server approve updates on the server, run the following commands below. These commands below force our servers to contact the WSUS server.
They both can also be run at the same time as shown below. Please see how to disable automatic Windows updates.
Navigate to the WSUS server and refresh the computer group, this server should appear.
Also, see How to apply Windows Updates from WSUS to the server using AWS RunCommand, and How to Configure SSL between WSUS servers (Upstream and Downstream Servers)
View WSUS Reports
Note: To view the report, you will have to download and install Microsoft Report Viewer.
With this installed reports can be generated as shown below
Windows Server Update Services: Windows 2016 Servers does not show up on WSUS console, and WSUS clients appear and disappear from the WSUS Update Services console.
FAQs
How does the AU Client work with WSUS?
The AU client understands each client setting, communicates with the WSUS server on a scheduled basis, and keeps your client up to date. Each supported Microsoft OS includes its own version of the AU client; however, the client machine updates the AU client to the latest version when it first contacts your WSUS server to ensure compatibility.
Why does the AU client need to update when connecting to a WSUS server?
The AU client must update to the latest version to ensure compatibility with WSUS and its features. This update occurs automatically when the client machine first contacts the WSUS server, allowing the AU client to apply the correct settings and manage updates effectively.
I hope you found this blog post helpful on how to target WSUS clients with the registry keys. Please refer to this article on how to disable unused Cisco Access Ports. If you have any questions, please let me know in the comment session.
Для централизованной настройки параметров получения и установки обновлений на рабочих станциях и серверах Windows можно использовать групповые политики. В этой статье мы рассмотрим базовые параметры GPO, которые позволяют управлять установкой обновлений на компьютерах, получающих обновления от локального сервера WSUS или напрямую с серверов Windows Update в интернете.
Содержание:
- Настройка параметров получения обновлений клиентам WSUS через GPO
- Назначить групповые политики WSUS на OU с компьютерами
- Применение групповых политик Windows Update на клиентах
- GPO для получения и установки обновлений Windows Update через Интернет
Настройка параметров получения обновлений клиентам WSUS через GPO
Если у вас развернут собственный сервер обновлений Windows Server Update Services (WSUS), вы должны настроить рабочие стации и сервера в вашем домене AD для получения обновлений с него (а не с серверов Microsoft Update через Интернет).
В нашем случае мы хотим создать две разные политики установки обновлений для рабочих станций и серверов. Для этого откройте консоль управления WSUS (
wsus.msc
) на сервере и создайте в разделе Computers -> All Computers две группы компьютеров:
- Workstations
- Servers
Затем перейдите в раздел настройки сервера WSUS (Options), и в параметре Computers измените значение Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).
Эта опция включает client side targeting для клиентов WSUS (таргетинг на стороне клиента). Благодаря этому вы сможете автоматически распределить компьютеры по группам обновлений в консоли WSUS по специальной метке в реестре клиента (такая метка создается через GPO или напрямую в реестре.
Теперь откройте консоль управления доменные групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.
Начнем с описания серверной политики ServerWSUSPolicy.
Настройки параметров службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies-> Administrative templates-> Windows Component-> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).
Мы хотим, чтобы продуктивные сервера не устанавливали обновления автоматически и не перезагружались без подтверждения администратора. Для этого настроим GPO так, чтобы сервера автоматически скачивали доступные обновления, но не устанавливали их. Администраторы будут запускать установку обновлений вручную (из панели управления или с помощью модуля PSWindowsUpdate) в согласованные окна обслуживания.
Настроим следующие параметры политики:
- Configure Automatic Updates (Настройка автоматического обновления):
Enable
.
3 – Auto download and notify for install
(Автоматически загружать обновления и уведомлять об их готовности к установке) – клиент автоматически скачивает новые обновлений и оповещает об их наличии; - Specify Intranet Microsoft update service location (Указать размещение службы обновлений Майкрософт в интрасети): Enable. Set the intranet update service for detecting updates (Укажите службу обновлений в интрасети для поиска обновлений):
http://srv-wsus.winitpro.ru:8530
, Set the intranet statistics server (Укажите сервер статистики в интрасети):
http://srv-wsus.winitpro.ru:8530
– здесь нужно указать адрес вашего сервера WSUS и сервера статистики (обычно они совпадают); - No auto-restart with logged on users for scheduled automatic updates installations (Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователя):
Enable
– запретить автоматическую перезагрузку при наличии сессии пользователя; - Enable client-side targeting (Разрешить клиенту присоединение к целевой группе):
Enable
. Target group name for this computer (Имя целевой группы для данного компьютера):
Servers
– в консоли WSUS отнести клиенты к группе Servers
Для рабочих станций мы хотим включить автоматическую загрузку и установку Windows Update сразу после получения новых обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически в нерабочее время (с предварительным предупреждением пользователей).
В настройках WorkstationWSUSPolicy указываем:
- Allow Automatic Updates immediate installation (Разрешить немедленную установку автоматических обновлений):
Disabled
— запрет на немедленную установку обновлений при их получении; - Allow non-administrators to receive update notifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях):
Enabled
— отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку; - Configure auto-restart reminder notifications for updates и Configure auto-restart warning notifications schedule for updates – показывать пользователям уведомления о перезагрузке
- Configure Automatic Updates:
Enabled
. Configure automatic updating:
4 — Auto download and schedule the install
. Scheduled install day:
0 — Every day
. Scheduled install time:
05:00
– при получении новых обновлений клиент скачивает в локальный кэш и планирует их автоматическую установку на 5:00 утра; - Enable client-side targeting:
Workstations
– в консоли WSUS отнести клиента к группе Workstations; - No auto-restart with logged on users for scheduled automatic updates installations:
Disabled
— система автоматически перезагрузится через 5 минут после окончания установки обновлений; - Specify Intranet Microsoft update service location: Enable. Set the intranet update service for detecting updates:
http://srv-wsus.winitpro.ru:8530
, Set the intranet statistics server:
http://srv-wsus.winitpro.ru:8530
–адрес WSUS сервера. - Включите опции Do not allow update deferral policies to cause scans against Windows Update (ссылка) и Do not connect to any Windows Update Internet locations. Это позволит предотвратить обращение клиента к серверам Windows Update в интернете.
- Turn off auto-restart for updates during active hours –
Enabled
. Отключить авто перезагрузку после установки обновлений в рабочее время (задать интервал рабочего времени в политике Active Hours Start и Active Hours End. Например, с 8 AM до 5 PM)
В обеих GPO включите принудительный запуск службы Windows Update (
wuauserv
) на компьютерах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic).
Назначить групповые политики WSUS на OU с компьютерами
Затем в консоли управления GPO прилинкуйте созданные вами политики к соответствующим контейнерам (подразумевается что для серверов и рабочих станций в AD созданы отдельные контейнеры OU).
Совет. Мы рассматриваем лишь один довольно простой вариант привязки политик WSUS к клиентам. В реальных организациях возможно привязать одну политику WSUS на все компьютеры домена (GPO с настройками WSUS вешается на корень домена), разнести различные виды клиентов по разным OU (как в нашем примере – мы создали разные политики WSUS для серверов и рабочих станций). В больших распределенных доменах можно привязывать различные WSUS сервера к сайтам AD, или же назначать GPO на основании фильтров WMI, или скомбинировать перечисленные способы.
Щелкните в консоли GPMC по нужному OU, выберите пункт меню Link as Existing GPO и привяжите нужную политику WSUS.
Совет. Также привяжите серверную политику WSUS к OU Domain Controllers.
Аналогично назначьте политику для компьютеров на OU с рабочими станциями.
Применение групповых политик Windows Update на клиентах
Дождитесь применения новых настроек GPO на клиентах или обновите их вручную:
gpupdate /force
Чтобы с клиента ускорить процесс регистрации и сканирования состояния на сервере WSUS, выполните команды:
$updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates
wuauclt /reportnow
Все настройки Windows Update, которые мы задали групповыми политиками должны появится на клиентах в ветке реестре HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.
Настройки из этой ветки можно экспортировать в REG файл и использовать его для переноса настроек WSUS на другие компьютеры, на которых нельзя задать параметры обновления с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://srv-wsus.winitpro.ru:8530"
"WUStatusServer"="http://srv-wsus.winitpro.ru:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
"ElevateNonAdmins"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000 –
"AUOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"ScheduledInstallEveryWeek"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
Через некоторое время все клиенты появятся в назначенных группах компьютеров в консоли WSUS. Здесь будут видны имена компьютеров, IP адреса, версии ОС, процент их пропатченности и дата последнего сканирования.
Клиенты скачивают CAB файлы обновлений в каталог
%windir%\SoftwareDistribution\Download
. Логи сканирования, загрузки и установки обновлений можно получить из файлов WindowsUpdate.log.
GPO для получения и установки обновлений Windows Update через Интернет
Если у вас отсутствует собственный сервер WSUS, вы можете использовать рассмотренные выше групповые политики для настройки параметров получения и установки обновлений на компьютеры из интернета (с серверов Windows Update).
В этом случае задайте в Not configured все параметры GPO, которые задают получение обновлений с WSUS:
- Specify Intranet Microsoft update service location: Not set
- Target group name for this computer: Not Set
- Do not allow update deferral policies to cause scans against Windows Update: Disabled
- Do not connect to any Windows Update Internet locations: Disabled
Такоие настройки GPO позволяет вам управлять тем, как компьютеры скачивают и устанавливают обновления Windows.
Understanding Windows Update Registry Settings
This article aims to help readers better understand where devices are pulling their Windows updates from based on the Windows Update registry settings on the local device. We will cover some of the various states the policy can be in, including Windows Server Update Services (WSUS), Microsoft Configuration Manager (ConfigMgr), Intune, and Co-managed devices.
- Windows Update Registry Settings are stored in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate registry key
- In all scenarios, we need to cover the four different topics:
- How the registry keys are controlled
- Where the device get its Updates from
- What Updates are applied
- When these Updates apply
Reviewing the registry values will allow you to quickly identify the client’s state and take appropriate troubleshooting or remediation actions.
With all of the registry settings in this article, it’s important to understand where the policy is controlled. It’s better to modify the policy controlling the registry keys instead of directly modifying the keys. Modifying the registry keys with a policy applied will likely revert back once the policy refreshes again.
This article will not cover Delivery Optimization. We will primarily focus on these updates as they are downloaded from WSUS, ConfigMgr, or Intune.
Windows Server Update Services registry settings:
When utilizing a WSUS Server, Group Policy typically handles WSUS registry settings.
You can control most aspects of how the Windows Update registry settings are set up here.
-
The Windows Update registry keys can be configured by policy here: Group Policy Management Editor > Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update.
We will use the WSUS server: wsus1.corp.contoso.com
In the WindowsUpdate.log, we can see the MoUpdateOrchestrator handles the download:
- More information on how the MoUpdateOrchestrator works can be found here.
- In the WindowsUpdate.log, we can see the DownloadManager is utilizing the registry settings controlled by the policy above.
- When the system checks in with WSUS, there is a check to see where content is going to be downloaded from; in this case, we download directly from wsus1.corp.contoso.com
- To specify which products get installed through WSUS, you need to enable them in Windows Server Update Services > Options > Products and Classifications.
- The updates must also be “Approved” either by modifying your “Automatic Approvals” or manually.
- Alternatively, to save time, you can add third-party updates to WSUS from Patch My PC using the publisher.
Configuring WSUS to automatically download and install the Windows Updates can be configured by Group Policy (notice WSUS Settings is the winning GPO) as well:
- The registry settings for Automatic Updates are listed here:HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
- The current settings being utilized lined up with the Group Policy applied.
-
You can automate the updates. However, there are limitations such as maintenance windows, update rings, scheduling reboots, and targeting specific updates. You could, in theory, control most of these options, but it’s a pain to maintain.
Microsoft Configuration Manager registry settings:
Clients will receive their policy from the Client Settings in ConfigMgr when utilizing a ConfigMgr Software Update Point. The Windows Update registry keys can be configured by the policy in Configuration Manager Console > Administration > Client Settings > Software Updates.
-
In this example, we will use the Software Update Point: cm1.corp.contoso.com
-
Whether the “Install All” button is pushed or the updates are automatically downloaded and applied, the registry entries tell the client to update from your software update point.
-
Important: Group Policy Objects will override Client Settings and can cause issues with Software Updates. It’s recommended to disable any GPO modifying the Windows Update policies on the client and allow the Client Settings to take effect. Notice here the Winning GPO is Local Group Policy (ie, the settings are coming from ConfigMgr):
-
In the WindowsUpdate.log, we can see the download is handled by CcmExec:
-
To specify what products get installed through ConfigMgr, you need to deploy the Software Updates either manually or through an Automatic Deployment Rule (ADR). We have an excellent video on how to set these up: How to Deploy Software Updates Using Microsoft SCCM (ADRs, Update Groups, and More)
-
In the lab, these are the options that were selected:
The updates and deployments run through various states depending on the deployment settings (forgive my lack of Visio skills). It will look something like this:
-
Important: A maintenance window check is applied when installing updates; if a maintenance window is not open, the computer will wait for its opening before installing the updates.
-
All of this is handled in ConfigMgr and not shown within the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key.
Intune registry settings:
-
When utilizing Intune, Windows Updates are controlled through Devices > Windows Updates:
-
For Intune Only devices, the registry keys are somewhere completely different. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update
- Unless a Group Policy or an old ConfigMgr policy is applied for Intune devices, HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate is completely blank and doesn’t exist.
-
All of these registry keys can be modified, however: when the Intune Management Extension checks in again the settings will be reverted. Modifying the settings from the Intune console is always recommended instead of manually changing them.
-
Reference this Microsoft Article on how to Troubleshoot Update Rings
In the WindowsUpdate.log, we can see the download is handled by the MoUpdateOrchestrator (same as WSUS):
-
However, this time, the update is being downloaded directly from Microsoft
When it comes to what Updates are going to apply, this depends on the Microsoft Subscription. Update rings, feature updates, quality updates, and driver updates are all applied to different tabs. Prerequisites for Autopatch, including licensing, can be found here.
It looks something like this:
In Intune, you can schedule a delay for these updates, and the reg keys at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update will reflect any policy changes made. However, there are no maintenance windows available. The IME agent checks in once a day and will automatically download and install the updates as needed based on policy.
Understanding PolicyState for Update Policies
Another critical registry key to examine during troubleshooting is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\PolicyState.
This key provides essential details about the active Windows Update policies on the device, including:
-
PolicySource: Identifies whether the policy is managed by MDM, Group Policy, or another source.
-
PolicyApplication: Confirms whether the policy has been successfully applied.
-
Policy Settings and Values: Displays the active policies, their configurations, and potential conflicts.
This is particularly useful for diagnosing devices impacted by updates such as KB4023057, which can reset MDM-managed devices to display as “Managed by Group Policy.” For example, if the device unexpectedly falls under Group Policy control, the PolicySource value will confirm the origin of the applied policies.
Administrators can use this key to quickly identify conflicts or mismatches in update management, making it an essential part of any troubleshooting process
Co-managed registry settings Part 1:
Co-Managment is where things start to get a bit strange. Let’s unpack it. This is where my current workload settings are for my test device.
It’s important to note that the registry changes will take effect on the device once the Windows Update policies are directed to Intune for that specific device. The registry keys remain the same whether the device is part of the Pilot Intune collection or if the slider is set fully to Intune for Windows Update Policies. Using the Pilot Intune setting is ideal for testing, as it only applies to the devices included in the collection under the “Staging” tab.
We have an excellent blog on Dual Scan. The purpose of this blog is to help users quickly identify where updates are coming from just by looking at the registry. However, the SCCM client will leave registry entries behind.
The first thing that usually catches my eye are these options here in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
If the following keys are set to zero, the device pulls these from Windows Update (Intune). According to Microsoft, “If no policies are configured: All of your updates will come from Windows Update.”
Again, going into the registry editor and editing the keys is not recommended. You can do it, but more often than not, the policy controlling these settings will just revert the settings that were manually changed. With the settings above, ConfigMgr is controlling these keys but the gpresult will show “Local Group Policy” as the winning policy.
But on this same device, we can review the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update location and see all of the Intune registry keys.
Looking at the WindowsUpdate.log, we can see the MoUpdateOrchestrator is taking over again.
Co-managed registry settings Part 2
To save myself from confusion later, the Client Policy was changed to Not Allow ConfigMgr to run Software Updates on Clients. After doing so, HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate was completely removed.
When Configuring Co-Management, you lose the ability to run third-party updates (unless you utilize dual scan). First-party (Microsoft) updates will work because they are downloaded directly from Microsoft. If you want third-party updates and plan on migrating workloads to Intune, enable the ClientApps workload for the same collection as your Windows Update policies. This way, if Patch My PC is building your updates in Intune, no loss of third-party patching will occur.
Summary
As you attempt to identify where the updates are coming from, run a group policy to see how these registry values are being controlled.
- HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
This location is primarily used for WSUS or ConfigMgr
- HKEY_LOCAL_MACHINESOFTWAREMicrosoftPolicyManagercurrentdeviceUpdate
This location is primarily used for Intune
Check the Windows Update Log (WindowsUpdate.log)
We’ve explored how Windows Update policies are managed across WSUS, ConfigMgr, Intune, and co-managed devices by understanding the role of registry keys. We’ve seen how to identify where updates are coming from, when they’re applied, and how they’re controlled, all while emphasizing the importance of letting policies govern these settings to avoid conflicts. By focusing on the registry paths, logs, and policy structures, we can effectively troubleshoot and manage updates without introducing unnecessary complications. This knowledge empowers us to maintain a smooth update process tailored to any organization’s needs.
If you’re looking for a faster, hassle-free way to manage application updates, Patch My PC can help. Our affordable solution simplifies app deployment, ensuring your environment stays secure and up to date with minimal effort. Book a demo today to see it in action!
