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

У одного из заказчиков столкнулся с интересной проблемой установки обновлений на клиентах с 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. А на следующий день на компьютерах стали закачиваться обновления.

• Question

• 

  

  0

  
  Sign in to vote
  

  Hello i am unable to update my server which is Windows Server 2008 R2 x64

  I am getting Error Code :  80246002

  please guide me

  Thursday, August 28, 2014 11:36 PM

Сейчас еще множество пользователей обладают операционной системой Windows 7 и регулярно устанавливают на нее вышедшие обновления. Однако не всегда получается удачно осуществить данную процедуру, иногда юзер сталкивается с возникновением ошибок, сопровождающихся различными кодами. Один из них имеет обозначение 80244022 и может свидетельствовать о самых разных проблемах, от неполадок с интернет-подключением, до отсутствия определенных системных файлов. В этой статье мы хотим помочь начинающим и опытным пользователям разобраться с этой трудностью, подобрав оптимальный метод решения.

Поскольку однозначно сказать, какой из вариантов решения подойдет в той или иной ситуации, нельзя, вам остается перебирать каждый способ по очереди, начав с самого простого и действенного, и закончив более сложными и редко встречающимися методами. Только путем проб можно понять, что именно мешает обновлению, а само исправление уже не займет много времени.

Способ 1: Проверка даты и времени

Для Виндовс очень важно, чтобы дата и время были установлены правильно. Если значения этих параметров не соответствуют действительности, вы можете получить ряд неполадок, среди которых и ошибка с кодом 80244022. В таком случае от вас лишь требуется проверить корректность упомянутых параметров и при необходимости изменить их:

1. Откройте меню «Пуск» и переходите в раздел «Панель управления».



2. Переместитесь в раздел «Дата и время».



3. Откроется небольшое новое окно, в котором следует кликнуть на «Изменить дату и время».



4. Используйте появившееся меню, чтобы выставить правильные значения.

Однако не всегда банальное изменение времени проходит удачно. Не исключены ситуации, когда возникают трудности с синхронизацией или дата вовсе сбивается после перезагрузки компьютера. Более детальную информацию по этим темам вы найдете в других наших статьях, перейдя по указанным ниже ссылкам.

Подробнее:
Синхронизируем время в Windows 7
Решаем проблему сброса времени на компьютере

Способ 2: Использование средства устранения неполадок

В каждой актуальной версии Виндовс присутствует встроенная система обнаружения и исправления неполадок. Работает она в разных направлениях, потому помогает исправить ошибки и с обновлениями. Нет стопроцентных гарантий, что этот метод точно сработает, однако от вас не потребуется практически никаких усилий, потому это обязательно надо попробовать.

1. Снова переместитесь в «Панель управления», где выберите раздел «Центр поддержки».



2. Опуститесь в самый низ окна, где найдите категорию «Устранение неполадок».



3. В открывшемся окне нажмите по надписи «Система и безопасность», чтобы получить полный список всех вариантов исправлений.



4. В появившемся меню понадобится выбрать «Центр обновления Windows».





5. Ознакомьтесь с информацией, которая отображена в мастере исправления неполадок, а затем перемещайтесь далее.



6. Ожидайте завершения сканирования и следуйте отобразившимся на экране инструкциям.

Обычно после окончания сканирования вы получаете уведомление о том, что ошибок не было найдено или обнаруженные проблемы успешно исправлены. Дополнительно могут появиться и отдельные указания, которые нужно выполнить для того, что бы средство завершило свою работу.

Способ 3: Настройка параметров подключения IE

Не секрет, что для загрузки обновлений в Виндовс 7 используется интернет, а подключение к нему осуществляется через стандартный браузер Internet Explorer. Иногда конфигурация обозревателя не позволяет корректно работать системным средствам ОС, потому необходимо проверить их и настроить вручную:

1. Запустите Internet Explorer, щелкните по значку в виде шестеренки, который находится справа вверху, и в открывшемся контекстном меню выберите вариант «Свойства браузера».



2. Переместитесь во вкладку «Подключения» и в разделе «Настройки параметров локальной сети» кликните по кнопке «Настройка сети».



3. Отметьте галочкой «Использовать прокси-сервер для локальных подключений» и нажмите на активную кнопку «Дополнительно».



4. Сотрите абсолютно все присутствующие параметры прокси-сервера, а затем примените настройки.



5. Откройте «Пуск», отыщите там «Командную строку» и запустите ее от имени администратора.



6. Введите там команду netsh winhttp reset proxy и нажмите на клавишу Enter. Это перезагрузит параметры прокси-сервера.



7. После этого останется только перезапустить службу обновления Windows. Для этого используйте команду net stop wuauserv, остановив службу.



8. Затем введите net start wuauserv, повторно запустив ее.



9. В новой строке должно появиться уведомление о том, что служба «Центр обновления Windows» успешно запущена.

По завершении этой процедуры можно смело переходить в раздел обновлений и запускать эту операцию повторно, в надежде на то, что данная манипуляция окажется действенной, а раздражающая ошибка 80244022 больше никогда не появится.

Способ 4: Сброс конфигурации центра обновлений

Перейдем к самому сложному, но в большинстве случаев рабочему руководству, который подразумевает полный сброс абсолютно всех настроек центра обновлений с дальнейшей регистрацией «чистых» DLL-файлов, необходимых для корректной работы системы. Весь процесс будет происходить в консоли, поэтому заранее подготовьтесь к тому, что придется копировать и вставлять множество команд, а некоторые из них вводить вручную.

1. Для начала остановите все службы, связанные с обновлением в Windows. Для этого введите команду net stop bits и нажмите на Enter.



2. Последовательно укажите еще три строки net stop wuauserv, net stop appidsvc и net stop cryptsvc, дождавшись уведомления о том, что каждая служба была остановлена.



3. Удалим служебные файлы, которые могут быть повреждены, из-за чего и возникает ошибка. В дальнейшем все это будет восстановлено, однако сейчас нужно избавиться от проблемных элементов путем ввода команды Del "%ALLUSERSPROFILE%Application DataMicrosoftNetworkDownloaderqmgr*.dat".



4. Далее переименуйте каталоги, где хранятся все конфигурационные и временные файлы. При следующем запуске служб эти директории будут созданы автоматически. Что касается переименования, то осуществляется оно через две команды:

   Ren %systemroot%SoftwareDistribution SoftwareDistribution.bak
Ren %systemroot%system32catroot2 catroot2.bak



5. Практически то же самое происходит со сбросом служб. Сначала введите sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU), а затем sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU). Вы должны получить строку с сообщением «Успех».



6. Остался самый сложный процесс — повторная регистрация важных DLL-файлов. Для этого сначала переместитесь к системному каталогу через команду cd /d %windir%system32.



7. Затем скопируйте все содержимое ниже или вводите каждую строку отдельно, чтобы создать абсолютно все необходимые DLL.

   regsvr32.exe /U /s vbscript.dll
regsvr32.exe /U /s mshtml.dll
regsvr32.exe /U /s msjava.dll
regsvr32.exe /U /s msxml.dll
regsvr32.exe /U /s actxprxy.dll
regsvr32.exe /U /s shdocvw.dll
regsvr32.exe /U /s Mssip32.dll
regsvr32.exe /U /s wintrust.dll
regsvr32.exe /U /s initpki.dll
regsvr32.exe /U /s dssenh.dll
regsvr32.exe /U /s rsaenh.dll
regsvr32.exe /U /s gpkcsp.dll
regsvr32.exe /U /s sccbase.dll
regsvr32.exe /U /s slbcsp.dll
regsvr32.exe /U /s cryptdlg.dll
regsvr32.exe /U /s Urlmon.dll
regsvr32.exe /U /s Oleaut32.dll
regsvr32.exe /U /s msxml2.dll
regsvr32.exe /U /s Browseui.dll
regsvr32.exe /U /s shell32.dll
regsvr32.exe /U /s atl.dll
regsvr32.exe /U /s jscript.dll
regsvr32.exe /U /s msxml3.dll
regsvr32.exe /U /s softpub.dll
regsvr32.exe /U /s wuapi.dll
regsvr32.exe /U /s wuaueng.dll
regsvr32.exe /U /s wuaueng1.dll
regsvr32.exe /U /s wucltui.dll
regsvr32.exe /U /s wups.dll
regsvr32.exe /U /s wups2.dll
regsvr32.exe /U /s wuweb.dll
regsvr32.exe /U /s scrrun.dll
regsvr32.exe /U /s msxml6.dll
regsvr32.exe /U /s ole32.dll
regsvr32.exe /U /s qmgr.dll
regsvr32.exe /U /s qmgrprxy.dll
regsvr32.exe /U /s wucltux.dll
regsvr32.exe /U /s muweb.dll
regsvr32.exe /U /s wuwebv.dll

   


   regsvr32.exe /s vbscript.dll
regsvr32.exe /s mshtml.dll
regsvr32.exe /s msjava.dll
regsvr32.exe /s msxml.dll
regsvr32.exe /s actxprxy.dll
regsvr32.exe /s shdocvw.dll
regsvr32.exe /s Mssip32.dll
regsvr32.exe /s wintrust.dll
regsvr32.exe /s initpki.dll
regsvr32.exe /s dssenh.dll
regsvr32.exe /s rsaenh.dll
regsvr32.exe /s gpkcsp.dll
regsvr32.exe /s sccbase.dll
regsvr32.exe /s slbcsp.dll
regsvr32.exe /s cryptdlg.dll
regsvr32.exe /s Urlmon.dll
regsvr32.exe /s Oleaut32.dll
regsvr32.exe /s msxml2.dll
regsvr32.exe /s Browseui.dll
regsvr32.exe /s shell32.dll
regsvr32.exe /s Mssip32.dll
regsvr32.exe /s atl.dll
regsvr32.exe /s jscript.dll
regsvr32.exe /s msxml3.dll
regsvr32.exe /s softpub.dll
regsvr32.exe /s wuapi.dll
regsvr32.exe /s wuaueng.dll
regsvr32.exe /s wuaueng1.dll
regsvr32.exe /s wucltui.dll
regsvr32.exe /s wups.dll
regsvr32.exe /s wups2.dll
regsvr32.exe /s wuweb.dll
regsvr32.exe /s scrrun.dll
regsvr32.exe /s msxml6.dll
regsvr32.exe /s ole32.dll
regsvr32.exe /s qmgr.dll
regsvr32.exe /s qmgrprxy.dll
regsvr32.exe /s wucltux.dll
regsvr32.exe /s muweb.dll
regsvr32.exe /s wuwebv.dll



8. Дополнительно рекомендуется сбросить параметры интернет-протоколов через netsh winsock reset.



9. Напоследок запустите все остановленные службы, введя поочередно такие строки:

   sc.exe config wuauserv start= auto
sc.exe config bits start= delayed-auto
sc.exe config cryptsvc start= auto
sc.exe config TrustedInstaller start= demand
sc.exe config DcomLaunch start= auto
net start bits
net start wuauserv
net start appidsvc
net start cryptsvc

После выполнения этих действий обычно не нужно перезагружать компьютер, поскольку они применяются автоматически. Как видите, данный вариант является довольно сложным и займет определенное время, однако после вы получите полностью рабочие файлы, предотвращающие появление рассматриваемой проблемы.

Способ 5: Редактирование параметров реестра

Метод с редактированием параметров реестра подразумевает активацию резервного сервера, с которого и будут скачиваться обновления. Это поможет на время избавиться от рассматриваемой ошибки, однако после инсталляции нововведений сервер рекомендуется выбрать основной, чтобы в дальнейшем проверить, была ли исправлена неполадка после добавления последних файлов. Для этого выполните такие действия:

1. Откройте утилиту «Выполнить», воспользовавшись стандартной комбинацией клавиш Win + R. В появившемся поле ввода напишите regedit и нажмите на Enter.



2. Если появится окно контроля учетных записей, выберите в нем вариант «Да».



3. Перейдите по пути HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU.



4. Щелкните по любому пустому месту правой кнопкой мыши. В появившемся контекстном меню выберите «Создать» и «Параметр DWORD (32 бита)».



5. Назовите его «UseWUServer», а затем дважды щелкните ЛКМ, чтобы открыть свойства.



6. Установите значение 1 для активации резервного сервера. При необходимости это значение можно поменять на 0, чтобы деактивировать параметр.

Изменения будут применены только после перезапуска ПК. Затем можно смело переходить к попытке инсталляции обновлений через резервный сервер. Не забудьте только отключить его, если этот вариант не принес результата или же нововведения были добавлены правильно.

Способ 6: Установка обновления вручную

Приведенные выше методы не окажутся эффективными в тех случаях, когда проблема вызвана каким-то конкретным обновлением, конфликтующим с самой системой. При возникновении таких ситуаций рекомендуется инсталлировать файлы вручную, обойдя Центр обновления Windows. Тогда имеется шанс того, что после успешного выполнения этой операции ошибка 80244022 полностью исчезнет. Более детальную информацию и все необходимые инструкции по этой теме вы найдете в другом нашем материале далее.

Подробнее: Ручная установка обновлений в Windows 7

Способ 7: Исправление ошибок и восстановление системы

Прежде чем перейти к самым радикальным мерам, рекомендуется произвести стандартную проверку операционной системы на наличие ошибок. Осуществляется это с помощью стандартных встроенных средств. Если они не обнаружили никаких неполадок, тогда уже нужно производить восстановление, откатываясь до первой резервной копии или возвращая заводские настройки. Обо всем этом в развернутом виде описано в отдельных наших статьях, которые доступны по следующим ссылкам.

Подробнее:
Проверка компьютера с Windows на ошибки
Восстановление системы в Windows 7

Выше вы были ознакомлены с самыми разнообразными методами решения ошибки 80244022, которая возникает при попытке установить обновления в Windows 7. Дополнительно следует учесть, что все это может оказаться неэффективным для пользователей пиратских версий Виндовс, поскольку часто оттуда просто вырезают Центр обновлений или просто удаляют системные файлы. Учитывайте это при решении своей проблемы.

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.

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.

После нудачной установки новых обновлений, пользователи могут столкнуться с кодом ошибки под номером 0x80244022. Проблема говорит о том, что при обновлении системы возникла проблема. К сожалению, такие ошибки случаются довольно часто. Не существует какой-то единой причины их появления. Однако есть основные проблемы, которые чаще всего вызывают такие ошибки у многих пользователей. Обычно такие ошибки появляются из-за отсутствующих или поврежденных файлов системы, неисправного ПО, проблем несовместимости и других причин, которые вызывают появление таких проблем. Найти такую причину сразу довольно трудно. Поэтому необходимо попробовать все способы решения, перечисленные в нашем руководстве ниже.

1. Воспользуйтесь средством устранения неполадок Центра обновления Windows

Как правило, первое, что советуют попробовать многим пользователям, — это Средство Устранения Неполадок Центра обновлений. Большинство людей недооценивают эту функцию, говоря, что она не помогает решить проблему. В большинстве случаев они будут правы, поскольку на такие ошибки обычно влияют другие причины. Тем не менее, все же стоит попробовать этот простой, но иногда эффективный метод, дабы избавиться от возникающей ошибки. Встроенная утилита просканирует вашу систему на предмет потенциальных проблем и попытается исправить их самостоятельно

1. Откройте Настройки , а затем в Обновление и безопасность > Устранение неполадок.
2. На правой панели найдите Центр обновления Windows и нажмите Запустить средство устранения неполадок.
3. Завершите процесс, следуя инструкциям на экране, и перезагрузите компьютер.

2. Установите время и дату на автоматическое обновление.

Хотя этот метод может показаться слишком простым и бессмысленным, но он на самом деле может решить ошибку 0x80244022. Некоторые службы Windows не могут установить правильное соединение с серверами без надлежащих настроек времени. Поэтому попробуйте сделать следующее и посмотреть, есть ли какие-то изменения. Если это не поможет, то можно уже не возвращаться к этому легкому шагу, а просто перейти к более сложным решениям, описанным ниже.

1. Нажмите Windows Key + I одновременно.
2. Выберите Время и язык.
3. In Дата и время выберите Установить время автоматически.
4. После этого закройте окна и попробуйте установить обновление еще раз.

3. Проверьте целостность системных файлов.

Как мы уже упоминали выше, проблемы с обновлением возникать из-за отсутствия или повреждения файлов. Такие файлы обычно очень важны для правильной работы служб Windows. Если некоторые из этих файлов находятся вне их родной среды, то скорее всего это и станет причиной подобных ошибок. Ниже мы будем использовать как SFC (средство проверки системных файлов), так и DISM (обслуживание и управление образами развертывания), которые помогут обнаружить и восстановить отсутствующие компоненты. Вот как:

С помощью SFC

1. Откройте Командная строка , введя cmd в поле поиска рядом с Меню Пуск кнопку.
2. Щелкните правой кнопкой мыши по Командная строка , а затем выберите Запуск от имени администратора.
3. После открытия консоли введите sfc /scannow команду и нажмите Enter.
4. Когда процесс восстановления будет завершен, перезагрузите компьютер.

С помощью DISM

1. Откройте Командная строка как мы это делали на предыдущем шаге.
2. Скопируйте и вставьте эту команду DISM.exe /Online /Cleanup-image /Restorehealth.
3. Нажмите Enter и подождите, пока Windows закончит сканирование и исправление.
4. После этого перезагрузите компьютер и снова установите обновление.

После выполнения двух этих сканирований попробуйте снова установить проблемное обновление. Если и это не поможет, переходите к другим шагам ниже.

4. Включите Чистый запуск Windows.

Ошибка 0x80244022 также может быть вызвана проблемами несовместимости. Антивирусное ПО или какая-та сторонняя программа может конфликтовать со службами Windows, вызывая данную ошибку. Чистая загрузка поможет запустить ваш компьютер только со встроенными приложениями и службами Windows. Это поможет выяснить, вызывает ли проблему какое-то стороннее приложение. Просто выполните следующие действия:

1. Нажмите Windows Key + R кнопки одновременно и вставьте msconfig.
2. Затем в открывшемся окне перейдите в Услуги сверху.
3. Установите флажок рядом с Не отображать службы Майкрософт и нажмите на Отключить все кнопку.
4. Теперь перейдите в Общие и выберите Выборочный запуск опцию. Убедитесь, что флажок установлен только рядом с Загружать системные службы.
5. Нажмите Применить и OK. Затем перезагрузите компьютер.

Теперь вы можете попробовать обновить свою систему, находясь в режиме Чистой загрузки. Независимо от того, удалось ли вам установить обновление или нет, необходимо вернуть Windows к параметрам обычного запуска. Для этого просто повторите все шаги, которые были описаны выше, включив отключенные службы и изменив параметры запуска с Выборочный запуск в нормальная.

5. Сбросьте компоненты Центра обновления Windows.

Когда дело доходит до решения проблем обновлений, хорошим способ в данной ситуации является сброс настроек Центра обновления Windows. Во многих случаях это действительно помогает решить проблему благодаря некоторым манипуляциям. Вся процедура включает перезапуск служб BITS, Cryptographic, MSI Installer и Windows Update, а также переименование некоторых папок обновлений (SoftwareDistribution и Catroot2). Эти папки содержат временные файлы, необходимые для установки обновлений Windows. Исходя из этого, мы заставим Windows удалить поврежденные элементы и создать компоненты обновления с нуля. Для этого мы воспользуемся консолью, чтобы выполнить необходимые команды. Это более продвинутый способ решения, но для этого не потребуется много времени и знаний. Просто выполните следующие действия:

1. Откройте Командная строка , введя cmd в поле поиска рядом с Меню Пуск кнопку.
2. Щелкните правой кнопкой мыши по Командная строка , а затем выберите Запуск от имени администратора.
3. Скопируйте и вставьте этот список команд одну за другой, нажимая Enter после каждой. (Это действие отключит службы, ответственные за Обновления Windows)

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

4. Затем мы должны переименовать вышеупомянутые папки. Просто вставьте эти команды, нажимая Enter после каждой.

ren C:WindowsSoftwareDistribution SoftwareDistribution.old
ren C:WindowsSystem32catroot2 Catroot2.old

5. Наконец, все, что осталось сделать, это вернуть отключенные службы. Введите эти команды так же, как мы делали ранее.

net start wuauserv
net start cryptSvc
net start bits
net start msiserver

6. На этом все. Перейдите в центр обновления Windows и попробуйте выполнить установку снова.

6. Проверьте Прокси настройки.

0x80244022 может возникнуть из-за проблем с подключением. Эксперты выяснили, что использование прокси-сервера для локальных подключений может конфликтовать с загрузкой обновлений. Поэтому мы рекомендуем вам отключить эту функцию и посмотреть, изменится ли что-то в отношении установки обновления. Вот как это можно сделать:

1. Откройте Панель управления введя его имя в строку поиска рядом с меню «Пуск».
2. Установите Просмотр на Крупные значки.
3. Затем, найдите Свойства обозревателя из списка и откройте его.
4. Перейдите в Коммутация и выберите Настройка сети внизу.
5. Под разделом «Прокси-сервер» снимите флажок с опции Использовать прокси-сервер для локальных подключений. Затем нажмите Применить и OK для сохранения изменений.
6. Теперь вы можете закрыть окно и попробовать установить обновление еще раз.

7. Загрузите конфликтующее обновление из каталога Microsoft.

Если вам по прежнему не удается установить необходимое обновление, тогда это можно сделать вручную. Другими словами, вы можете загрузить конфликтующее обновление прямо из каталога Microsoft. Для этого просто выполните шаги, описанные ниже:

1. Нажмите Windows key + I одновременно.
2. Затем перейдите в Обновление и безопасность.
3. В правой части окна выберите Просмотр журнала обновлений.
4. После этого найдите и запишите самое последнее обновление (вверху списка).
5. Затем загрузите записанное обновление из Microsoft Update Catalog.

8. Используйте Media Creation Tool.

И последнее, но не менее важное — это использование Media Creation Tool для получения новых обновлений. Эта утилита выступает в качестве отличной альтернативы традиционному Центру обновления Windows. Она помогает пользователям устанавливать свежие обновления в обход различных ошибок. Данная процедура не коснется ваших личных данных, а просто обновит компьютер. Для этого выполните следующие действия:

1. Сначала вам нужно скачать утилиту с веб-сайта Microsoft.
2. Затем запустите загруженный файл.
3. После того, как вы согласитесь с Условиями использования, вам будет предложено два варианта на выбор. Выберите Обновить этот компьютер сейчас.
4. Выберите Сохранить личные файлы чтобы они не пострадали.
5. Наконец, запустите процесс и дождитесь его завершения.
6. Надеемся, этот метод помог вам избавиться от ошибки 0x80244022.

Заключение

Несмотря на то, что 0x80244022 и другие подобные ошибки могут действительно раздражать, их не сложно решить благодаря эффективным инструкциям. Надеемся вы больше не сталкиваетесь с этой проблемой. Если вы когда-нибудь столкнетесь с подобными проблемами в будущем, то можете использовать те же шаги для устранения ошибки. Перечисленные нами методы универсальны для решения многих проблем обновлений, которые возникают во всех версиях Windows.

Если разливаете обновления с помощью WSUS (а WSUS еще со второй версии, для меня остается неким «котом в мешке», живущим какой-то своей известной только ему самому, жизнью. Не понимаю, что мешает сделать продукт более, логичным и информативным, ведь есть много удачных примеров…), то вроде бы при его стабильной работе, и полностью благополучно скачанных обновлениях,

на некоторых компах и серверах при обновлении выпадает ошибка Error 0x80244022.

В этом случае рекомендации типа:

https://answers.microsoft.com/en-us/protect/forum/mse-protect_updating/error-code-0x80244022-when-attempting-definitions/4958f996-08a3-46bb-b8a7-69ca6fee7032

или

https://ugetfix.com/ask/how-to-fix-windows-update-error-code-0x80244022/

в нашем случае, оказались бесполезными, исправление на ПК вроде выполняется, но обновления, как не накатывались, так и не накатываются.

На одном из форумов наткнулся на интересный совет, который и стал ключом к решению проблемы:

На сервере WSUS, открываем настройки IIS и запускаем или рестартуем св пулах приложений WSUSPool

После чего обновления начинают благополучно находиться и устанавливаться

Но есть в этом случае интересный момент, ответа на который, я пока так и не нашел: через некоторое время, служба снова останавливается сама по себе, и пока снова не запустить её руками, снова выпадает аналогичная ошибка. Если есть варианты прошу написать в комментариях?

Всем хорошей работы!!!

21.06.2017 —

Posted by |
ms windows server 2016

• Question

• 

  

  0

  
  Sign in to vote
  

  Hello i am unable to update my server which is Windows Server 2008 R2 x64

  I am getting Error Code :  80246002

  please guide me

  Thursday, August 28, 2014 11:36 PM