80244022 ошибка обновления windows server 2008 r2

У одного из заказчиков столкнулся с интересной проблемой установки обновлений на клиентах с Windows 7. Обновления распространяются посредством сервера WSUS, интегрированного в среду System Center Configuration Manager. На SCCM сервере используется Windows Server 2008 R2, версия WSUS соответственно — WSUS 3.0 SP2. Должны обновляется клиентские ПК с Windows 7 SP (порядка 2000 компьютеров).

Клиентские компьютеры не могут получить обновления с Software Update Point, в журналах при этом фиксируется ошибка 0x80244022.

На клиентской стороне журнал WUAhandler.log содержит ошибки:

OnSearchComplete - Failed to end search job. Error = 0x80244022.


Scan failed with error = 0x80244022.

В журнале службы Windows Update WindowsUpdate.log тоже множество ошибок вида:

2017-08-09     11:02:04:371   612     4858    Setup   WARNING: SelfUpdate check failed to download package information, error = 0x80244022
2017-08-09     11:02:04:371   612     4858    Setup   WARNING: SelfUpdate check failed to download package information, error = 0x80244022
2017-08-09     11:02:04:371   612     4858    Agent    * WARNING: Skipping scan, self-update check returned 0x80244022
2017-08-09     11:02:04:371   612     4858    Agent    * WARNING: Exit code = 0x80244022
2017-08-09     11:02:04:371   612     4858    Agent  WARNING: WU client failed Searching for update with error 0x80244022
2017-08-09     11:02:04:371   612     4abc    AU        # WARNING: Search callback failed, result = 0x80244022
2017-08-09     11:02:04:371   612     4abc    AU        # WARNING: Failed to find updates with error code 80244022

На стороне сервера при этом в логе WSUSCtrl.log есть ошибка:

request failed with HTTP status 503: Service Unavailable


Failures reported during periodic health check by the WSUS Server SPB-MAN1. Will retry check in 1 minutes

Т.е. по логу видно, не отвечает сайт WSUS отвечает. Действительно, если открыть URL адрес WSUS Administration (http://SCCM-Srv1:8530), появляется ошибка:

HTTP Error 503. The service is unavailable

Открыв консоль управления IIS Manager, я увидел что пул, отвечающий за работу WSUS (WsusPool) находится в отключенном состоянии.

После ручного запуска пула, через 20-30 минут он опять падет. В журнале системы при этом обнаружилось интересное сообщение Event ID 5117 WAS с текстом:

A worker process serving application pool ‘WsusPool’ has requested a recycle because it reached its private bytes memory limit

По умолчанию в системе лимит используемой памяти для пула WsusPool
ограничен 1,8 Гб. При превышении этого значения (а это может запросто случится при большом количестве клиентов WSUS, особенно при первом сканировании), пул сбрасывается. Чтобы понять сколько памяти использует ваш пул WSUS, достаточно посмотреть за процессом w3wp.exe. При превышении лимита 1,8 Гб, процесс перезапускается. Таким образом для решения проблемы нужно увеличить объем выделяемой памяти.

Примечание. Проблема отчасти напоминает рассмотренный ранее кейс с ошибкой 0x8024401 при получения обновлений c в Windows 10.

Сделать это можно из консоли IIS Manager, выбрав Application Pools -> ПКМ WsusPoll -> Recycling, увеличив значение в поле Private memory usage (in KB).

Насколько увеличить, решайте сами, рекомендую начать с 3-4 Гб. В моем случае для 2000+ клиентов WSUS, оказалось достаточно 6 Гб памяти.

Размер выделяемой памяти также можно изменить и из раздела расширенных настроек пула (Advanced Settings), увеличив значение в поле Private memory usage (KB).

Осталось перезапустить пул через кнопки Start/Stop или Recycle.

После чего процесс w3wp.exe перестал потреблять более 3 Гб RAM. А на следующий день на компьютерах стали закачиваться обновления.

I’m a SysAdmin for a small web development group.  We’re running about 65 servers and about 25 user PCs.  The servers are mostly Win 2008 R2 x64 SP1, Std. Edition, with a few Win 2008 x86 SP2 Enterprise Edition and some legacy Win 2003 x86 SP2 Std.
Edition (we’re phasing out the Win 2K3 machines as fast as we can).  The user PCs are Windows 7 Enterprise Edition x64 SP1.  Domain controllers are Win 2K8 R2 x64 SP1.

I’d been running one WSUS server for patching servers and workstations — no upstream or downstream WSUS, just the one patch server.  My WSUS server was running Windows Server 2008 R2 x64 SP1 Std. Edition, and WSUS 3.0 SP2 (with KB2720211 installed). 
It was using a locally-installed SQL Server 2008 R2 Std. Edition (10.50.2550) for a database.  This had been working well for about 3 years.

Then my WSUS server died.  O/S still ran, but the WSUS admin console just gives ‘Error: Connection Error’.  I tried the fixes suggested in the error message, and online, but couldn’t get it going again.  So, I built a new WSUS server, pretty
much identical to the old one in hardware, and in software configuration, but with a newer Win 2K8 R2 x64 O/S baseline image.

On the new machine, I installed IIS 7 according to the recommendations in
http://technet.microsoft.com/en-us/library/dd939916(v=ws.10).aspx.  I also installed ‘Application Server’, also in accordance with the recommendations in the same reference.

I installed SQL Server 2008 R2 Std. Edition on the new patch server, and applied SP2 and patches to bring it up to version 10.50.4033.  Once that was done, I took a full Acronis backup image of the machine.

I installed WSUS 3.0 SP2 from Server Manager, as outlined in that hyperlinked article above.  No problems anywhere along the line.  Once WSUS was installed, the configuration wizard ran, and I set it to update directly from Microsoft Update. 
I set my products and classifications, languages, sync schedule, etc.  It did a synchronization, and all looked good.  I made another Acronis Image backup of the server, and then backed up the SUSDB database and the D:WSUS folder.

With these safety nets in place, I tried to copy over the content from the old WSUS server to save re-approving all my patches.  I deleted the contents of D:WSUSWsusContent on the new server (to keep the ACLs intact), and copied the contents of D:WSUSWsusContent
folder from the old server to the new one.  I also restored the SUSDB database from the old server to the new one. (I did this as a ‘Overwrite the existing database (WITH REPLACE)’ and ‘Leave the database ready to use by rolling back uncommitted transactions’.)

The contents copy went without error, and the database restored without error.  After that, I rebooted the new WSUS server, and started looking at the WSUS console.

Everything looked fine.  Synchronizations, Computers, Approved patches and new patches to be approved — it was as if I had my original WSUS server back.

Now, we have two networks in place — one on a ‘real’ set of addresses, for normal use.  We added a second network to all servers, running on 192.168.1.nnn, as a private, unroutable network for stuff like tape backups, patching, etc.  Group Policy
directs all machines to use the 192.168.1.nnn address for the old patch server as the location to go to for patches.  I disabled this second NIC on the old patch server, and put that IP Address on the second NIC in the new patch server.  I made sure
SQL server was updated to have its listeners on the right addresses, just to be sure.

So, at this point, I figured I was home free.  I expected my patching to just work.  However, every time I try to run ‘Check for Updates’ on a client machine (server or PC), I quickly get an error, 80244022.  I tried deleting my test client
from the WSUS server and reconnecting to it via the command-line ‘wuauclt.exe /detectnow’.  It never showed up on the WSUS console.  I tried reapplying Group Policy and rebooting, and then running wuauclt.exe again.  Still no luck.

I looked for solutions on the web, and found references that indicated that I might need KB2720211 / KB2734608, since my WUAgent clients were likely running version 256 and my WSUS server was likely running version 226.  I installed both of those patches
on my WSUS server and rebooted it.  After the reboot, the WSUS console still reports version 226, but the list of installed patches shows both of those KBs, and indicates that my WSUS is version ‘3.2.7600.256’.  At least, after the patches, I was
able to run ‘wuauclt.exe /detectnow’ on my test PC and have it show up in the WSUS console, so that’s good.

However, running a ‘Check for Updates’ still gives me the 80244022 error.

Where can I start looking for a solution to getting my machines to resume pulling patches from my new patch server?  What logs ought I to be looking at?

Thanks in advance.