У меня есть сервер WSUS Windows Server 2008 R2, который в настоящее время отлично работает с набором клиентских серверов Windows Server 2008/2012 R2. Все отправляют отчеты и загружают / устанавливают обновления, как ожидалось.
Я недавно добавил в сеть два клиента Windows Server 2016 (1607), которые просто не хотели согласованно взаимодействовать с сервером WSUS, давая мне только две ошибки 80248014 и 8024500C неоднократно в журнале событий клиента Центра обновления Windows.
Первоначально я заметил высокий уровень ЦП / памяти на сервере WSUS после добавления этих серверов 2016 года и нашел статью, в которой объяснялись причины и предлагалось решение. Это исправление KB4039929 для WSUS 3.0 с пакетом обновления 2 (SP2) и некоторые другие предложения по изменению тайм-аута ASP.NET и настройке IIS для прекращения повторного использования пула приложений WsusPool. Я также нашел некоторые другие предлагаемые изменения, а именно:
Это позволило избавиться от высокой загрузки ЦП и ошибки 8024401c из журнала событий, но не от 80248014 и 8024500C, упомянутых выше.
Я обновил шаблоны ADMX в центральном хранилище, чтобы убедиться, что все настройки доступны, и я не упускаю никаких очевидных настроек, которые могут на это повлиять.
Оба следующих параметра GPO были изменены на указанное значение:
«Устанавливать обновления для других продуктов Microsoft» - Включено
«Не подключаться к каким-либо местам обновления Windows в Интернете» - отключено
Я пробовал следующее предложение Сброс сервера обновлений Windows и компонентов вместе с выполнением следующей команды: wuauclt / resetauthorization / reportnow / detectnow
Ни одно из вышеперечисленных вопросов не решило проблемы, которые, к сожалению, наблюдаются.
У меня возникли проблемы с созданием файла WindowsUpdate.Log atm с ошибкой «Информация о формате не найдена», поэтому я сейчас занимаюсь этим, чтобы продолжить расследование.
Одна вещь, которую я заметил, но почти уверен, что это просто косметика, заключается в том, что после присоединения к домену служба обновления Windows изменила отображаемое имя на wuauserv. Этого не происходит ни в каких других версиях Windows, однако служба запускается / останавливается нормально.
Наконец, я запустил бесплатный инструмент диагностики Solarwinds для службы обновления Windows Server на этих конечных точках 2016 года, который сообщил, что версия агента обновления Windows в настоящее время - 6.2.14393.3085 и нуждается в обновлении. Изучив, как это сделать, я вижу, что последняя версия Windows 2016 CU KB4507459 будет содержать все необходимые обновления на сегодняшний день, включая обновления агента WU, и поэтому он был установлен. Агент WU wauaeng.dll теперь сообщает о 10.0.14393.3085, однако инструмент Solarwinds все еще сообщает о старой устаревшей версии, но думаю, что это может быть просто отвлекающим маневром. Я не вижу способа обновить агент вручную, поэтому, насколько я понимаю, обновление CU кажется единственным способом.
Я наконец нашел проблему и, похоже, теперь работаю.
В конце концов мне удалось открыть WindowsUpdate.log, и я обнаружил, что следующие ошибки повторяются неоднократно.
492 9300 DownloadManager BITS job {GUID} столкнулся с временной ошибкой, updateId = {GUID} .200, error = 0x800706D9
&
492 9300 DownloadManager Ошибка 0x800706d9 при загрузке обновления; уведомление о зависимых звонках.
Затем я нашел эту очень полезную статью о MS Проблемы, связанные с настройкой межсетевого экрана что указывает на то, что отключение службы брандмауэра Windows не поддерживается и, по-видимому, является зависимостью службы Центра обновления Windows для правильной работы. Как только я снова включил эту службу и запустил ее снова, обновления начали литься, и WSUS сообщал, что все работает нормально.
Отключение фактической службы Windows никогда не было проблемой в старых операционных системах, а просто процесс, который мы всегда делали для новых серверов домена. Компоненты системы Windows, очевидно, более интегрированы, чем раньше, так что об этом следует помнить. Теперь процесс состоит в том, чтобы просто отключить профили брандмауэра через GPO.
В любом случае, спасибо, что посмотрели, и, надеюсь, это будет полезно для всех, кто столкнется с такой же проблемой.