Ни для кого не секрет, что в том случае, если Ваш ПК с ОС Microsoft выходит в интернет с помощью прокси-сервера, то служба обновления системы Windows Update по-умолчанию не работает. Эта заметка о том, как можно настроить работу системы обновлений Windows на ПК, находящимся за прокси-сервером.
Служба обновлений Windows Update может использовать HTTP прокси-сервер. Однако указания прокси-сервера в настройках Windows Internet Explorer недостаточно для работы службы обновления через проксю. Дело в том, что Windows Update использует Windows HTTP Services (WinHTTP) для поиска обновления, а для загрузки обновлений используется BITS. Служба Windows Update по-умолчанию настроена так, что всегда пытается попасть на сервер обновлений Microsoft напрямую, не используя прокси-сервер, даже если в настройках Internet Explorer он указан.
Однако данная проблема решаема, достаточно настроить системный WinHttp прокси. В ОС Windows XP/2003 WinHttp прокси задавался с помощью утилиты proxycfg.exe. В новых ОС Windows Vista/7/2008 данная утилита упразднена и настройка WinHttp прокси выполняется при помощи команды netsh.
Настройка выполняется при помощи следующей команды: netsh winhttp set proxy <адрес_прокси_сервера>:<порт_прокси_сервера>.
После того, как вы выполните данную команду, ваша ОС Windows 7 будет обновляться, даже находясь за прокси-сервером.
Как вариант, если вы хотите взять настройки прокси из Internet Explorer, можно воспользоваться командой:
netsh winhttp import proxy source=ie
Как вариант возможна также ситуация, когда необходимо перенаправить весь трафик, кроме трафика на Microsoft (системные обновления, активация) на прокси-сервер, тогда можно воспользоваться следующей командой обхода прокси для обновлений Windows.
Сделайте обход прокси для активации и обновлений вот так:
netsh winhttp set proxy proxy-server="your-proxy-srv:3128" bypass-list="*.windowsupdate.com;*.microsoft.com"
Текущие настройки WinHttp можно посмотреть командой:
netsh winhttp show proxy
Сбросить же настройки прокси сервера можно при помощи команды:
Netsh winhttp reset proxy
Кстати netsh отличная утилита командной строки для работы с сетевыми службами и настройками, и каждый профессиональный Windows админ должен уметь ею пользоваться. Я уже не раз упоминал о ней, в статье о графической диагностике сети при помощи netsh, или про управление сервером DHCP Windows Server из командной строки PowerShell.
It is not a secret for anyone that in the event that your PC running Microsoft OS is connected to the Internet using a proxy server, the Windows Update service doesn’t work by default. This note is about how you can configure the Windows Update system on a PC behind a proxy server.
The Windows Update service can use an HTTP proxy server. However, specifying the proxy server in the Windows Internet Explorer settings is not enough for the update service to work through the proxy. The fact is that Windows Update uses Windows HTTP Services (WinHTTP) to look for updates, and BITS is used to download updates. The Windows Update service is configured by default so that it always tries to access the Microsoft update server directly, without using a proxy server, even if it is specified in Internet Explorer settings.
The configuration is performed using the following command:
netsh winhttp set proxy
After you run this command, your Windows 7 OS will be updated, even when you are behind a proxy server.
Alternatively, if you want to take proxy settings from Internet Explorer, you can use the command:
netsh winhttp import proxy source = ie
As an option, it is also possible that you need to redirect all traffic except for Microsoft traffic (system updates, activation) to a proxy server, then you can use the following proxy bypass command for Windows updates.
Do a proxy bypass for activation and updates like this:
netsh winhttp set proxy proxy-server = “your-proxy-srv: 3128” bypass-list = “*. windowsupdate.com; *. microsoft.com”
The current WinHttp settings can be viewed with the command:
netsh winhttp show proxy
You can reset the proxy server settings using the command:
Netsh winhttp reset proxy
Related post : Windows 7 RSAT for Windows Server
The dumbest thing… you are installing your brand new Windows Server 2016 machines and then you realize that Windows Update doesn’t work. It just gets stuck on Checking for updates/Downloading updates… for days.
Of course, you have some sort of proxy on your network, and you start troubleshooting this issue by testing on a proxy-free network… and without proxy, Windows Update works just as it should!
So, the next logical next step is to blame “those networking guys”, because updating your machine works fine, when not behind their “fancy proxy thing”.
But no.
You will soon realize that you have some “old” Windows Server 2012 R2 (or even Windows 10) machines, which are updating just fine… even through the “fancy proxy thing”.
And then you start asking yourself why.
You are checking the configuration of older machines by opening up Internet Explorer and double-checking proxy settings… and then you make sure that your new machines are having the same configuration – they have. Then you are just confused. It’s not networking, it’s not proxy settings… what could it be???
Still a bit confused, you have a great idea to check system proxy settings by running netsh winhttp show proxy – on older machines you’ll probably see something like this (which is probably OK, because you’ve just seen the Proxy Settings in IE, which are set to correct values):
So, you’re (naturally) configuring new machines accordingly. Still doesn’t work.
What next?
You can do further reading & testing, but the thing that helped in our case was setting the system (winhttp) proxy with netsh command, so that it actually imports IE proxy settings.
Basically, you need to run netsh winhttp import proxy source=ie (after you’ve set the right proxy settings through IE dialog, of course) or set your system proxy by using the netsh winhttp set proxy proxy.mydomain.com:8080 command.
After that, Windows Update starts working again!
So, remember – when using Windows Server 2016, set your system proxy settings by using the netsh command and everything will work just fine!
Cheers!
P.S. Of course, if you have another trick to make it work, please comment.
Reading Time: 6 minutes
Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.
In this part of the series, we’ll look at best practices to handle Windows activation on non-domain-joined Web Application Proxy servers.
Note:
This blogpost assumes you’re running Web Application Proxies as non-domain-joined Server Core Windows Server 2016 installations.
If your Web Application Proxy servers are domain-joined, you can use Group Policy and Windows Server Update Services (WSUS) to take care of Windows Update. However, this option can’t be used for Web Application Proxy servers that are non-domain-joined and/or placed on a perimeter network (also commonly referred to as a DMZ network).
Why look at Windows Update for Web Application Proxies
Every software has bugs. It’s still a human job to produce code. Developers, testers and even quality assurance people also work on Monday mornings. We all make mistakes. It’s how we deal with failure, that defines us.
Microsoft software has bugs. Bugs may be innocent, or they may lead to serious problems like remote code execution, elevation of privilege, information disclosure, security feature bypasses, denial of service, spoofing and/or tampering. However, the way Microsoft handles fixing these bugs, stands out. In 2003, Microsoft started with a repetitive predictable and reported way of announcing and releasing updates to its software, including Windows, Windows Server, Office, Visual Studio, SQL Server, Exchange Server and many others: Patch Tuesday.
Below is a graphical representation of the problems solved in the September 10, 2019 update:
In recent years, Microsoft has split up the security updates from the quality improvement updates. Now, the second Tuesday of each month brings security updates. Quality updates are also released on Tuesday, but usually a week or two weeks after the security updates.
Web Application Proxies need the free updates Microsoft distributes.
Possible negative impact (What could go wrong?)
When Web Application Proxies do not install Windows Updates, they may remain vulnerable for common problems. While many admins think that a proper firewall rule prevents these attacks, some attacks operate at a higher layer than most firewalls operate; When the firewall allows TCP 443, it doesn’t merely allow the proper traffic for the Web Application Proxy. Similarly, next-generation firewalls and web application firewalls may inspect the flow of https traffic between the Internet and Web Application Proxies but may not detect the newest threats.
When Windows Servers do not install Windows Updates, their functionality may break, as fixes to the role are not added to the Operating System. This holds strongly for Windows Server 2012 R2-based Web Application Proxies, as the role was first introduced in this version and many updates were made to the role in the first year.
When Windows Servers do not install Windows Updates, they may lack new security features and settings. Updates to Root Certification Authorities (CAs), time zone updates and cipher suite updates are common updates that add to the information security baseline. The Extranet Smart Account Lockout feature in AD FS was distributed with a Windows Update to Windows Server 2016.
Four solutions for Windows Updates
There are four solutions to apply Windows Updates to non-domain-joined Web Application Proxies:
- Configure to use Windows Update on the web
- Configure to use your organization’s WSUS implementation
- Manually install Windows updates
- Use an update solution
How to do it
To apply Windows Updates to non-domain-joined Web Application Proxies, perform these actions, per scenario:
Configure to use Windows Update on the web
Microsoft offers a standardized method for downloading Windows updates from its webservers. This method is built-in, even in Server Core.
For this scenario, the following requirements need to be met:
- Each Web Application Proxy needs to be able to communicate to the following URLs using TCP 443 and TCP80, respectively:
- http://download.windowsupdate.com
- http://*.download.windowsupdate.com
- http://download.microsoft.com
- https://*.update.microsoft.com
- http://*.update.microsoft.com
- https://update.microsoft.com
- http://update.microsoft.com
- http://*.windowsupdate.com
- http://*.windowsupdate.microsoft.com/li>
- http://windowsupdate.microsoft.com
- https://*.windowsupdate.microsoft.com
- http://ntservicepack.microsoft.com
- http://wustat.windows.com
- Each Web Application Proxy needs to be able to verify the communication certificates and update signatures, by allowing access to the Certification Authorities (CAs) used.
- DNS-based name resolution to the Internet for each Web Application Proxy.
- An account with local administrator privileges on each Web Application Proxy.
Configuring automatic updates
Perform the following steps to configure a Server Core installation to use Windows Update on the web:
- Sign in with an account with local administrator privileges.
- Run sconfig.cmd.
The Server Configuration utility starts. - Enter the number 5, followed by pressing the Enter key on the keyboard to enter the Windows Update Settings sub menu.
- Press A for Automatic updates, followed by pressing Enter on the keyboard.
- In the Update Settings dialog screen, click OK.
The Web Application Proxy will check for and install updates every day at 3:00 AM. The settings take effect immediately. No reboot is required. Repeat the above steps on each Web Application Proxy.
Configure to use your organization’s WSUS implementation
Windows Server Update Services (WSUS) enables admins to deploy the latest Microsoft product updates with full manageability of the distribution of updates in their networks.
Note:
WSUS can be deployed in a disconnected scenario, where updates and metadata are exported on one WSUS server and imported on another disconnected WSUS server. This scenario makes WSUS useable in highly-restricted perimeter networks, too.
For this scenario, the following requirements need to be met:
- A fully functional WSUS server needs to be implemented and synchronized with Microsoft Update.
- DNS-based name resolution to the Internet for each Web Application
Proxy. - An account with local administrator privileges on each Web Application
Proxy.
Where the WSUS server addresses are commonly deployed using Group Policy, Web Application Proxies are typically not domain-joined. The following lines of Windows PowerShell ass the registry settings to point a Web Application Proxy to a WSUS server
Stop-Service -Name wuauserv
$Path = «HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate»
$WSUSAddress = «WSUSSERVER»
New-ItemProperty -Path $SChannelRegPath -Name DisableWindowsUpdateAccess `
–Value 1 -PropertyType DWORD
New-ItemProperty -Path $SChannelRegPath -Name WUServer `
-Value $WSUSAddress -PropertyType String
New-ItemProperty -Path $SChannelRegPath -Name WUStatusServer `
-Value $WSUSAddress -PropertyType String
New-ItemProperty -Path $SChannelRegPath+»\AU» -Name AUOptions `
-Value 5 -PropertyType DWORD
New-ItemProperty -Path $SChannelRegPath+»\AU» -Name NoAutoUpdate `
-Value 0 -PropertyType DWORD
New-ItemProperty -Path $SChannelRegPath+»\AU» -Name UseWUServer `
-Value 1 -PropertyType DWORD
Start-Service -Name wuauserv
The Windows Update client is now configured with Automatic Updates and polls the WSUS server for approved updates every 22 hours minus a random offset.
Repeat the above steps on the other Web Application Proxies.
Manually install Windows updates
In either of both scenarios, admins can manually check for updates and install updates.
For this scenario, the requirements need to be met for the previous scenarios, but most importantly an account with local administrator privileges on each Web Application Proxy is needed.
Perform these steps:
- Sign in with an account with local administrator privileges.
- Run sconfig.cmd.
The Server Configuration utility starts. - Enter the number 6, followed by pressing the Enter key on the keyboard.
- Choose between Search for (A)ll Updates or (R)ecommended Updates only by pressing either A or R on the keyboard, followed by pressing Enter on the keyboard.
- Then, select between (A)ll updates, (N)o updates or (S)elect a single update, by pressing A, N or S on the keyboard, followed by pressing Enter on the keyboard.
- Press Yes in the Restart Required dialog screen to restart the Web Application Proxy.
Repeat the above steps on the other Web Application Proxies.
Use an Update solution
3rd party patching solution might offer functionality to update Web Application Proxies. However, I would like to share a really simple solution: WSUSOffline.net,
Using «WSUS Offline Update», you can update any computer running Microsoft Windows and Office safely, quickly and without an Internet connection, for free.
Especially its option to create an ISO file, that you can easily mount on virtual machines makes it a fast solution to update hosts in the perimeter network.
Checking which updates are installed
Throughout the lifetime of a Web Application Proxy, you might need to troubleshoot Windows Updates. It might help when you are trying to figure out whether an update is installed and the server needs rebooting or whether an update is not installed. (in which case you probably won’t need to reboot) The command to use is:
wmic.exe qfe list
Concluding
It’s your choice to create media to manually update your Web Application Proxies, or let them download updates from the Internet or WSUS Servers automatically. However, please remember to implement something to keep the systems in your Hybrid Identity implementation up to date.
Further reading
Windows Update troubleshooting
Fix Windows Update errors
Registry keys for configuring Automatic Updates & WSUS
WSUS Offline Update
How To: Remove WSUS Settings and Restore Windows Update Defaults
Configure a Server Core installation of Windows Server 2016, with Sconfig.cmd
How to Patch Windows Server Core 2016
null
В случае, если в инфраструктуре не используется свой WSUS сервер, возможно появление ошибок получения обновлений для Windows Server 2016. При этом процесс обновления зависает на этапе скачивания обновлений и остается на уровне 0%, после чего сваливается с ошибкой.
Открываем файл журнала с помощью командлета Get-WindowsUpdateLog (причем надо учесть, что созданный файл WindowsUpdate.log является статическим и не обновляется в реальном времени как в предыдущих версиях Windows, поэтому для его обновления приходится запускать командлет заново)
Get-WindowsUpdateLog -logpath C:\Logs\WindowsUpdate.log
Открываем сам файл журнала
Invoke-Item -Path C:\Logs\WindowsUpdate.log
Видим сообщения вида
2018/09/04 16:24:21.8734472 588 4116 DownloadManager Failed creating DO job with hr 80246008 2018/09/04 16:24:21.8772521 588 4116 DownloadManager DO download failed with error 80246008[Extended: 80040154], falling back to BITS and retrying with new Download Job.
Т.е. BITS не может закачать сами фалы обновлений с ошибкой 80246008, при этом сами параметры системного прокси указаны в IE правильно и он работает корректно.
Выяснилось, что недостаточно просто задать параметры прокси через IE – вводим команду
netsh winhttp show proxy
и получаем в результате сообщение
Current WinHTTP proxy settings: Direct access (no proxy server).
Задаем параметры прокси вручную:
netsh winhttp set proxy proxy-server="192.168.x.x:xxx" bypass-list="*.XXX.xx"
где 192.168.x.x:xxx – адрес прокси-сервера, *.XXX.xx – байпас-лист(если он используется)
Также, если в системе используется раздача параметров прокси через GPO, можно просто импортировать настройки из IE принудительно с помощью
netsh winhttp import proxy source=ie
Обязательно преезапускаем службу обновлений
Restart-service wuauserv
Т.к. клиент Windows Update не поддерживает возможность авторизации на прокси, обязательно нужно разрешить на прокси возможность анонимной авторизации на серверах обновлений Microsoft.
Список серверов обновлений приведен на https://social.technet.microsoft.com/Forums/ru-RU/7b6efbb2-d94a-44f6-b994-eca645874aed/104310761077-10741079110310901100-ip?forum=windows7ru.
После перезапуска обновления должны скачиваться корректно.
