Долгое время обновлял три машины на работе через свой домашний 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. Однако же две машины обновляются нормально, а третья теперь вот ну никак не может скачать ни один файл.
