[Решено] Проблемы с настройкой обновлений через сервер WSUS

[Raistlin]

Вот нашёл: Install the WSUS 3.0 Administration Console (http://technet2.microsoft.com/windowsserver/en/library/33d292d5-f601-45c4-8dfb-472b14c199cb1033.mspx?mfr=true). Как и предполагал, предлагают использовать для установки тот же файл, что и для установки самого WSUS. Но у меня-то он сам пришёл через WSUS. Что ж теперь, качать ещё раз?

[Michael]

Тогда найди в базе WSUS все файлы размеров больше 70 Mb за период с 01.05.2007 по 31.05.2007. Их будет немного. Посмотришь по описанию в свойствах файла и найдешь 2 обновления под WSUS 3.0. Один из них по английскую версию а другой под русскую, хотя тут могу ошибаться, но это не важно - один не запустится с воплями о несовместимоси системы (кажется так).
Хотя есть вариант покороче :)
Смотри файлы 56384B071A9559D94A3819333A421CB5C387E285.exe и AD3B2D93A6C92DC8F6C817102C1F32C89D515886.exe

[Raistlin]

Спасибо, всё получилось. Мог бы и сам догадаться :).
Хотя всё же интересно, как то же самое "нормальным" способом делается.

[monkkey]

Raistlin
Например, с помощью этой (http://diksoft.5km.org/#client) программы. Достаточное количество утилит для преобразования хэша в названии WSUS-овского вида в обычный.

[Raistlin]

Спасибо, посмотрю. Однако я имел в виду другое - что сама MS по этому поводу думает.

[Samsonov]

Долгое время обновлял три машины на работе через свой домашний WSUS. Недавно на предприятии перешли от прозрачного NAT к принудительному проксированию через ISA, да плюс ещё я на своей рабочей станции систему с нуля переустанавливал. В общем, теперь надо выяснить, где же именно грабли: сейчас эта машина не может скачать ни одно обновление, хотя и определяет их наличие.

Подробности.

Все три клиентских машины работают под Windows XP SP2. Та, что переустанавливалась по-новой, имеет все интегрированные обновления вплоть до 2007-04, плюс ещё несколько (таких как Installer 3.1) установил вручную с веб-сайта Windows Update.

Две машины, которые не переустанавливались, продолжают отлично обновляться — как раз сегодня пришла очередная партия заплаток. Машина с новой системой не может качать обновления через Automatic Updates ни с моего домашнего сервера, ни с майкрософтовского, хотя наличие необходимых обновлений определяет правильно и предлагает их скачать. Через веб-интерфейс Windows Update всё работает без запинки. Отсюда остаётся сделать вывод, что если где и есть проблема, так это на самой машине и конкретно в механизме AU/BITS, а не на прокси или WSUS-сервере.

На сервере (WSUS 3.0) эта злополучная машина отображается как не отправлявшая отчёт о состоянии с тех самых времён, когда ещё стояла старая система. С остальными клиентами всё в порядке: у меня дома ещё два компьютера, соседи тоже туда ходят и т. д.

Утилита ClientDiag (WSUS 2.0) на всех трёх машинах выдаёт одну и ту же ошибку:WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL, &downloadBuffer) failed with hr=0x80190193
Так что полагаться на данное средство диагностики не получается. Есть ли какие-то ещё способы подебажить?

Сама ошибка 0x80190193, как я понял, означает невозможность разрешения DNS-имени в IP-адрес. Пробовал в качестве адреса WSUS указывать сразу IP (хотя две другие машины как-то же работают!), вручную прописывать DNS-сервер (обычно этот адрес получается через DHCP), отключать службу DNS-клиента — не помогает. К тому же начальный этап общения проходит нормально — затык только когда дело доходит до скачивания файлов.

Непосредственно в WindowsUpdate.log фигурируют ошибки 0x8024401B и 0x80190197:DnldMgr *********** DnldMgr: New download job [UpdateId = {…}.104]
DnldMgr FATAL: DM:CAgentDownloadManager::DownloadUpdate: pDownloadJob->Init failed with 0x8024401b.
DnldMgr WARNING: Got error (hr = 8024401b) starting update 0 in call 71. Notifying call.
DnldMgr Error 0x8024401b occurred while downloading update; notifying dependent calls.
AU >>## RESUMED ## AU: Download update [UpdateId = {…}]
AU # WARNING: Download failed, error = 0x8024401B
DnldMgr WARNING: BITS job {…} failed, updateId = {…}.102, hr = 0x80190197, BG_ERROR_CONTEXT = 5
DnldMgr Progress failure bytes total = …, bytes transferred = 0
DnldMgr Failed job file: URL = http://…
DnldMgr WARNING: Download job failed because of proxy auth or server auth.Как я понял, сие указывает на ошибки аутентификации на HTTP-прокси. Это, пожалуй, самый туманный момент, потому что нигде в продуктах Microsoft (да и почти всех других производителей) нет возможности указать логин-пароль для прокси-аутентификации. Я так понимаю, веб-браузеры типа IE/Firefox либо сами догадываются использовать реквизиты входа в систему (у нас тут домен), либо запрашивают эти сведения у пользователя, как обычную HTTP-аутентификацию. В общем, указать прокси через proxycfg я могу, но как проконтролировать, что за пароль оно предъявляет, и предъявляет ли вообще, не знаю. Разумеется, если обращаться к файлам на WSUS-сервере из браузера, никаких проблем не возникает. Сама Microsoft по данному случаю ничего толкового посоветовать не может, кроме как отключить на ISA необходимость авторизации для доступа к WSUS — понятно, что никто этим заниматься не будет.

Но самое интересное в том, что, по идее, никакой аутентификации не должно требоваться, поскольку WSUS сидит на своём уникальном порту, а ISA контролирует только 80 и 443, продолжая пропускать трафик для других протоколов. Вот почему появление ошибок HTTP 407 Proxy auth req'd (якобы) мне совершенно непонятно. Специально проверял телнетом: трафик на порт WSUS не проходит через механизм прокси — это видно по тому, что можно набрать «GET / HTTP/1.0» и получить в ответ нужную страницу, а не отлуп с требованием указать заголовок «Host: wsus.domain.ru» (как это происходит при попытке обратиться на 80-й порт якобы в обход прокси).

Одним словом, куда копать — совершенно непонятно. Вроде на всех машинах столь простая конфигурация (к тому же новая инсталляция ещё совсем чистая, ничем не испорченная), все настройки минимальны и в основном получаются на автомате по DHCP, WPAD, ISA Firewall Client. Однако же две машины обновляются нормально, а третья теперь вот ну никак не может скачать ни один файл.

[monkkey]

0x80190193 (http://www.google.ru/search?hl=ru&q=0x80190193&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&lr=)

[Samsonov]

google.ru is the best chance to know about 0x80190193Ну и? А я, по вашему, где пытался информацию откопать, прежде чем сюда обратиться?
Везде одно и то же написано по поводу этой многозначной ошибки: Сервер WSUS перегружен, следует обратиться попозже — очевидно, это не мой случай. Проблемы с разрешением имени через DNS — тоже не очень похоже, тем более что все остальные фазы проходят нормально; впрочем, быть уверенным в полной логичности алгоритмов Microsoft нельзя. Аналог HTTP-кода 403 Forbidden — снова, скорее всего, мимо: с этого же сервера обновляются ещё 5 машин, включая ту же систему до переустановки Windows, и ни у одной проблем нет и не было, а никаких особенных настроек я не делал. Впрочем, опять же, нельзя исключать, что на новой системе какой-то «не такой» апдейтер, и он обращается куда-то не туда или как-то не так. Но я уже поставил почти все имеющиеся обновления через Windows Update — лишь немножко приберёг неустановленных для тестовых целей, которые явно не затрагивают механизм AU/BITS. Напрямую из браузера, повторюсь, все нужные файлы доступны, начиная с self-update и заканчивая конкретными обновлениями. Вот и вопрос, как же отследить действия клиента, если сам ClientDiag выдаёт такую ошибку на всех трёх удалённых компьютерах, даже на тех, где апдейты скачиваются нормально. С домашнего компьютера та же утилита сейчас выдаёт ошибку 0x80190194, которая вроде соответствует HTTP-коду 404 Not Found — с одной стороны, казалось бы, ошибка, а с другой, говорят, так и должно быть, когда нет новых обновлений. Подвариант предыдущей гипотезы — 403 Forbidden by proxy — тоже можно исключить: никто же не будет прописывать запрет для одной машины и тем более для обновлений Windows. Большинство обсуждений этой и других ошибок сводится к решению проблем на сервере — мол, не так что-то настроено в IIS или на уровне файловой системы, или в полномочиях пользователей. Тоже не мой случай, раз остальные машины нормально апдейтятся, и все они (почти) являются для сервера совершенными чужаками, то есть не входят в его домен.А у вас какие предположения есть, кроме «Гугл всё знает»?

[monkkey]

Удалите "проблемную" машину с сервера WSUS, пусть зарегистрируется заново.

[Samsonov]

Удалите «проблемную» машину с сервера WSUS, пусть зарегистрируется заново.Хе! Если б всё решалось так просто, я даже до Гугла не добрался бы. :)

Тем не менее, сейчас повторил фокус, предварительно вытерев на клиенте всё из папок SoftwareDistribution\Download и SelfUpdate\Default — после первого же подключения к WSUS в них появились 4 файла лицензионных соглашений и 5 файлов апдейтера соответственно. И сам список доступных обновлений тоже ведь как-то скачивается. И состояние своё серверу оно всё-таки рапортует. Проблема только при скачивании собственно файлов обновлений, причём любых.

[Samsonov]

Самое интересное забыл добавить: в логах IIS сейчас всё по нулям. То есть процесс общения со служебными страничками виден — SimpleAuthWebService, ClientWebService, ReportingWebService. Видны и скачивания вышеупомянутых файлов лицензий (/Content) и апдейтера (/selfupdate). Причём все эти операции используют самые разные HTTP-методы (HEAD, GET, POST) и все заканчиваются успешно (HTTP-статус 200 OK).

Нету в логах только ни слова про сами файлы обновлений. Вообще. А когда обновляется беспроблемный клиент, то этими строчками (/Content) усеян весь лог — не заметить было бы невозможно.

[YuriA]

Samsonov у меня таже ерунда. Если вытащить внутренний конец из ISA (WSUS у меня стоит на другом компьютере), то на двух проблемных компьютерах начинают работать обновления и ClienDiag.exe начинает всё правильно показывать (правда с задумчивостью). Я думаю где-то проблемы в настройке ISA, но где не пойму.

[YuriA]

В ISA 2000 в настройках веб-клиента надо поставить "прямо направлять всё что находится в LDT" (Local Domain Table). После этого clientdiag.exe начинает работать, но проблема остаётся :(

[GreenIce]

Добрый день! Подскажите какую команду нужно выполнить на клиентском месте для немедленного запуска связи с wsus на придмет наличия и установки обновлений?

[Petya V4sechkin]

GreenIce,
wuauclt /detectnow

Или хитрый скрипт:
WSUS: Script to Force the Update Detection from Automatic Update Client (WUA) for updates on WSUS Server (http://msmvps.com/blogs/athif/pages/66375.aspx)