Постой и послушай. Это будет долгий вопрос. Последние пару месяцев у нас были проблемы с обновлениями на очень определенных машинах Microsoft Server 2003 R2. Эта проблема до бесконечности смутила меня и нашего администратора постоянного сервера, поскольку мы не можем понять, что именно вызывает проблему.
Вот подробности:
Наша сеть: Эта сеть представляет собой организацию среднего / малого размера с примерно (500) компьютерами и 20+ серверами. Все основные DC и критические службы находятся на Server 2012 (r1), в то время как некоторые из старых приложений / служб работают на 2008 R2. Кроме того, на некоторых машинах Server 2003 R2 работают в основном устаревшие приложения и службы, которые будут либо заменены, либо устареют в следующем году.
Проблема: Проблема в том, что среди этих нескольких серверов 2003 R2 три из них демонстрируют странное поведение. Мы были впервые предупреждены об этом поведении, когда они внезапно (в том же цикле обновления) не смогли правильно установить обновления, и мы были предупреждены через наше программное обеспечение для мониторинга.
Центр обновления Windows: На проблемных машинах мы можем без проблем подключиться к URL-адресу Центра обновления Windows, но любая попытка проверить наличие обновлений приведет к
Номер ошибки: 0x80244016
на странице Центра обновления Windows. Этот код ошибки соответствует недопустимому URL-адресу. Поскольку мы проходим через WSUS, URL-адрес должен быть (мы проверили на всех серверах) полным доменным именем и портом нашего сервера WSUS \ NOC3.sub.domain.com: 8888. Мы обнаружили, что в этот момент трафик блокировался через настройки прокси-сервера winHTTP. Итак, когда возникает эта проблема, мы можем использовать
proxycfg -h
и очистите настройки прокси. Запустите обновления Windows, и он успешно подключится.
Вот тут и становится интересно: Теперь все было бы хорошо, но сейчас становится лучше. Итак, следующее обновление Windows появится в прошлом месяце, и, черт возьми, та же проблема с теми же серверами возникает снова. Теперь мы немного подозреваем, почему те же настройки прокси-сервера были применены повторно. Естественно, мы полагали, что это могла быть старая политика, которая не была должным образом отключена или, возможно, просто неправильно применялась. Итак, мы оба просмотрели все применимые объекты групповой политики для серверов в GPM на контроллере домена в поисках любых примененных политик, которые могут иметь какое-либо отношение к этой странной, теперь повторяющейся политике (?), Которая заставляет наши серверы каким-то образом возвращаться к этому (неверно ) настройка прокси-сервера. Не применялись политики, в которых упоминались бы прокси-серверы. Затем я запустил RSOP на машине.
Становится страннее: Итак, после запуска RSOP все вроде загрузилось нормально. Пока я не попытался открыть папку «Локальный компьютер» -> «Административные шаблоны». Во-первых, открытие папки заняло чрезмерно много времени. Затем, когда он, наконец, запустился, появятся сообщения об ошибках, связанные с AER _ ####. Adm. Не только ошибки, но и параметры политики на нескольких языках, отображаемые в одной папке. Я не очень хорошо читаю арабский, китайский, итальянский или японский, но предполагаю, что это дубликаты настроек политики на разных языках. Я обнаружил, что удаление файлов .adm из папки% root% \ system \ inf, по крайней мере, позволит RSOP без ошибок загружать административные шаблоны. * Примечание: более позднее исследование показало, что файлы AER ####. Adm связаны с отчетами об ошибках; что странно, если учесть, что будет дальше:
Первая попытка разрешения: Итак, догадываясь, я переместил посторонние файлы .adm в другую папку; затем я запустил
gpupdate / force
на пораженном сервере. * примечание: на этом сервере все еще был установлен параметр «зависший» прокси-сервер. После перезапуска настройки прокси-сервера, казалось, остались без настройки прокси, которые мы хотели.
Но увы радость была временной: Во время этого недавнего цикла обновления мы были предупреждены о том, что серверы снова не получали обновления. Та же проблема, та же неверная настройка прокси-сервера. * Примечание: настройка прокси-сервера указывает на внутренний сервер, который мы когда-то использовали в качестве веб-прокси, поэтому мы не думаем о "угрозе безопасности" атм. Я также еще раз проверил RSOP, и лишние файлы .adm вернулись на свои места. Итак, на данный момент я убежден, что проблема заключается в том, что изменяет нашу политику, так что создаются эти новые файлы AER ####. Adm (политика или какое-то внешнее устройство / программа, которая вносит изменения в нашу политику) . Я не нашел никаких ссылок на что-либо подобное в Интернете, и я не понимаю внутренних механизмов групповой политики, поскольку они применяются к ОС Server 2003 R2, чтобы вникнуть глубже на этом этапе. Так что прошу вас, помогите!
Вывод: Вот что я знаю точно:
Любой совет или понимание этого вопроса было бы замечательно. Спасибо за ваше время!