none
WSUS + Win7 SP1 x64 + 80072ee2 RRS feed

  • Общие обсуждения

  • Проблемы с обновление Windows 7 x64 любых редакций.

    Суть проблемы: Устанавливается Windows Server 2012 r2 core (на Hyper-v) подымается роль Wsus через GPO раздаеться в сеть. все компы обновляются нормально кроме Win7 x64. Т.е. и 2012 сервера, и 8.0 и 8.1 и Win7 x86 все в порядке, не хотят обновляться только Win7 x64? Причем те компьютеры которые с Win7 x64, которые до этого исправно получали обновления с предыдущего wsus (на windows server 2008 r2), так же продолжают обновляться, а те кто обновлялся не периодически или имели ошибки при установки каких то обновлений, так же не хотят обновляться.

    Перепробованы ВСЕ советы которые можно найти в интернете: манипуляции с очисткой SoftwareDistribution, установка Windows6.1-KB947821-v34-x64, регистрация dll, восстановление bits, WSUS Client Diagnostics Tool - все в норме, проверка целостности системы, устанавливался wsus на новый свежеустановленный сервер, устанавливались и удалались антивирусы, прокси не испульзуются, файровы отключали, указание wsus и по ip и по DNS имени, манипуляции с MTU, win7 x64 обновлялись с Microsoft по полной и только потом подключались к WSUS - в общем все что можно было нарыть в инете пробовалось, ничего не помогает и проблема только с семеркой х64. Т.е. даже комбинация новая виртуалка с WSUS + новая Win7 x64 - не работает.

    Машина регистрируется в WSUS, но не может отправить "отчет".

    кусок проблемы в логе:

    2016-03-01    14:27:13:753     984    dc0    PT      + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://192.168.69.2:8530/ClientWebService/client.asmx
    2016-03-01    14:28:15:954     984    dc0    Misc    WARNING: Send failed with hr = 80072ee2.
    2016-03-01    14:28:15:954     984    dc0    Misc    WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2016-03-01    14:28:15:954     984    dc0    Misc    FATAL: SOAP/WinHttp - SendRequest: SendRequestUsingProxy failed. error 0x80072ee2
    2016-03-01    14:28:15:954     984    dc0    PT      + Last proxy send request failed with hr = 0x80072EE2, HTTP status code = 0
    2016-03-01    14:28:15:954     984    dc0    PT      + Caller provided credentials = No
    2016-03-01    14:28:15:954     984    dc0    PT      + Impersonate flags = 0
    2016-03-01    14:28:15:954     984    dc0    PT      + Possible authorization schemes used =
    2016-03-01    14:28:15:954     984    dc0    PT    WARNING: SyncUpdates failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
    2016-03-01    14:28:15:954     984    dc0    PT    WARNING: PTError: 0x80072ee2
    2016-03-01    14:28:15:954     984    dc0    PT    WARNING: SyncUpdates_WithRecovery failed.: 0x80072ee2
    2016-03-01    14:28:15:954     984    dc0    PT    WARNING: Sync of Updates: 0x80072ee2
    2016-03-01    14:28:15:954     984    dc0    PT    WARNING: SyncServerUpdatesInternal failed: 0x80072ee2
    2016-03-01    14:28:15:954     984    dc0    Agent      * WARNING: Failed to synchronize, error = 0x80072EE2
    2016-03-01    14:28:15:954     984    dc0    Agent      * WARNING: Exit code = 0x80072EE2
    2016-03-01    14:28:15:954     984    dc0    Agent    *********
    2016-03-01    14:28:15:954     984    dc0    Agent    **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2016-03-01    14:28:15:954     984    dc0    Agent    *************
    2016-03-01    14:28:15:954     984    dc0    Agent    WARNING: WU client failed Searching for update with error 0x80072ee2
    2016-03-01    14:28:15:954     984    fd4    AU    >>##  RESUMED  ## AU: Search for updates [CallId = {FFB9A24F-12D4-4F7C-A598-EC53265A39FB}]
    2016-03-01    14:28:15:954     984    fd4    AU      # WARNING: Search callback failed, result = 0x80072EE2
    2016-03-01    14:28:15:954     984    fd4    AU      # WARNING: Failed to find updates with error code 80072EE2
    2016-03-01    14:28:15:954     984    fd4    AU    #########
    2016-03-01    14:28:15:954     984    fd4    AU    ##  END  ##  AU: Search for updates [CallId = {FFB9A24F-12D4-4F7C-A598-EC53265A39FB}]
    2016-03-01    14:28:15:954     984    fd4    AU    #############
    2016-03-01    14:28:15:954     984    fd4    AU    Successfully wrote event for AU health state:0
    2016-03-01    14:28:15:954     984    fd4    AU    AU setting next detection timeout to 2016-03-01 12:28:07
    2016-03-01    14:28:15:954     984    fd4    AU    Setting AU scheduled install time to 2016-03-02 02:00:00
    2016-03-01    14:28:15:954     984    fd4    AU    Successfully wrote event for AU health state:0
    2016-03-01    14:28:15:954     984    fd4    AU    Successfully wrote event for AU health state:0
    2016-03-01    14:28:20:955     984    dc0    Report    REPORT EVENT: {63D80998-4E6D-4EB7-8E0D-1C947570B94B}    2016-03-01 14:28:15:954+0300    1    148    101    {00000000-0000-0000-0000-000000000000}    0    80072ee2    AutomaticUpdates    Failure    Software Synchronization    Windows Update Client failed to detect with error 0x80072ee2.
    2016-03-01    14:28:20:955     984    dc0    Report    CWERReporter::HandleEvents - WER report upload completed with status 0x8
    2016-03-01    14:28:20:955     984    dc0    Report    WER Report sent: 7.6.7601.19116 0x80072ee2(0) 0000000-0000-0000-0000-000000000000 Scan 0 1 AutomaticUpdates {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} 0
    2016-03-01    14:36:43:084     984    dc0    Report    Uploading 1 events using cached cookie, reporting URL = http://192.168.69.2:8530/ReportingWebService/ReportingWebService.asmx
    2016-03-01    14:36:45:631     984    dc0    Report    Reporter successfully uploaded 1 events.


    1 марта 2016 г. 12:19

Все ответы

  • Добрый день,

    1. Пробовали отключить  TCP autotuning configuration ? Можете сделать это запустив команду "netsh int tcp set global autotuninglevel=disabled." 

    2. Запускали Windows Update Troubleshooter , какой результат ?


    3. Еще рекомендаций можете прочитать здесь.
    1 марта 2016 г. 12:37
  • 1) только что попробовал - та же ошибка

    2) запускался "везде исправлено" - но при попытке обновиться ошибка сохраняется.

    3)  пробовалось (ВСЕ советы, найденные в инете пробовал)
    • Изменено KobaLTD80 1 марта 2016 г. 13:17
    1 марта 2016 г. 13:01
  •  Спасибо за оперативность,

    1. А  после команды  "netsh winhttp show proxy" получаете такое сообщение "Current WinHTTP proxy settings:Direct access (no proxy server)."?  

    2. В случае, что нет введите:

    netsh winhttp reset proxy


    netsh interface tcp set global autotuninglevel=disabled

    1 марта 2016 г. 14:08
  • Прокси нет, команда так же говорит:

    C:\Windows\System32>netsh winhttp show proxy

    Текущие параметры WinHTTP прокси.

        Прямой доступ (без прокси-сервера).

    1 марта 2016 г. 15:10
  •  Здравствуйте,

    Запустите gpmc.msc - Default Domain Policy - Edit - Group Policy Management Editor - Computer Configuration - Administrative templates - Windows  components - Windows Update. Проверьте:

    "Specify Intranet Microsoft Update Services Location" ( правильно указан http://....?)

    и

    "No auto-restart with logged on users for scheduled automatic updates installation"

    как конфигурированы, включены ?

    В случае, что да, настройте "Not configured" и потом запускаете команду gpupdate /force.


    2 марта 2016 г. 8:03
  • Если Вы имеете ввиду "локальные" политики - то они не настраивались Win7 x64 установлен на "читую" (и много раз перевешивался)  виртуальную машину (для экспериментов, т.к. ковырять рабочие компы не могу - люди работаю)

    Все настройки раздаются через GPO домена.

    Specify Intranet Microsoft Update Services Location - указан правильно - все ОС КРОМЕ win7 x64 получают обновление, для всех в домене настройки WSUS задаются одной и той же "политикой"

    No auto-restart with logged on users for scheduled automatic updates installation - после изменения в АД, не дает результат - да и не понятно как "отключение/включение перезагрузки при наличии активного сеанса" может влиять на ERROR_INTERNET_TIMEOUT (80072EE2)?

    Сразу скажу АД тут тоже не причем - пробовал делать stand alone сервер с WSUS и  stand alone Win7 x64 точно такая же ситуация.

    А с учетом того что в сети есть машины с Win7 x64 ,которые постоянно и без проблем обновлялись с предыдущего WSUS, который стоял на win2008 R2, и нормально обновляются после этого с WSUS на 2012 R2 - то логически можно предположить что есть какое то обновление или сумма обновлений - которые распространялись через WSUS и которые позволили этим машинам взаимодействовать с WSUS на 2012 R2. Вот только как найти что это за обновление(я), чтобы их накатить "вручную". Полная накатка обновлений через "инет" не приносит результата.

    2 марта 2016 г. 10:53
  • Здравствуйте,

    Может быть я неправильно Вас понял, но в последнем абзаце пишите, что даже если совпадают на 100% обновления на win7 x64 ( штатно работающих) с проблемными машинами, то инцидент снова наблюдается ?

    На машинах где наблюдаете инцидент так настроено ?

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

    "UseWUServer"=dword:00000001


    Пробовали и все рекомендации указанные здесь ?

    2 марта 2016 г. 13:26
  • 1) Пробовал

    2 ) UseWUServer равен еденице

    3) Нет, Вы не так  поняли - описываю подробней, раньше в сети был WSUS на сервере 2008 r2, все обновлялись, кто с ошибками кто без, в общем как "обычно". Потом была пересмотрена структура организации было решено уйти на "виртуализацию", и параллельно обновить ОС "зоопарка" до однородности. Так что когда дело дошло до WSUS - сервер 2008 R2 был убит, был установлен 2012 r2 core на виртуалке и на нем поднята роль WSUS. Через 2 дня было замечено что машины с win7 x64 все на нем зарегистрировались, то большая часть из них не присылает "отчетов" и соответственно не получает обновление. Посмотрев старые отчеты (мы их сохраняли раз в месяц для отчетности отдела) было замечено что это не обновляются те машины которые по долгу не получали обновления (ноуты разъездные) или те которые имели ошибки установки каких то обновлений, но отдел HelpDesk`ка просто забил на решение этих вопросов, те компьютеры с win7 x64 которые получали и корректно обновлялись до переезда WSUS и дальше продолжают обновляться. В попытке разобраться была поднята виртуалка с win7 x64 и какого было удивление что даже "свежеустановленная" win7 x64 не хочет обновляться. После серии экспериментов, продолжавшихся около двух недель, в течении которых виртуалка с WSUS и виртуалка с win7 x64 многократно переустанавливались было выявлено:

    1) только ОС win7 x64 (Prof и Ent, других редакций просто нет на руках) не хотят обновляться с WSUS на 2012 r2, а завешанные на эту же виртуалку Win7 x86 (Prof и Ent), Win8, Win8.1, Server 2012, Server 2008 x64/x86, Server 2008 R2, Server 2012 R2  нормально начинают обновляться после установки.

    2) На такое поведение никак не влияют варианты и порядок подключения/не подключения клиента и сервера с WSUS в АД, а также порядок и способ установки и настройки ролей, служб интеграции, различных Fix`ов и даже сторонние "чистилки" и "правилки" системы, замена физического сетевого оборудования (но сути "шаманство" уже) и многое другое во всех возможных комбинация.

    3) Перепробованы ВСЕ ВОЗМОЖНЫЕ советы, найденные  в инете (к сожалению 90% из них повторяются от сайта к сайту)

    4) Накатка на свежеустановленную Win7 x64 всех или различных комбинаций (в группах от 5 за раз) обновлений, доступных в "Центре обновления Microsoft" (т.е. обновление из инета, а не через свой WSUS) так же не изменяет ситуацию

    Вывод: Собрав все это в кучу можно сделать логический вывод что те компьютеры с Win7 x64 которые и сейчас обновляются корректно, получили со "старого WSUS" какое то одно  или несколько обновлений, которое НЕ распространяется через "Центр обновления Microsoft", и которое позволяет им взаимодействовать с WSUS на 2012 r2. Только из-за разгильдяйства  HelpDesk отдела таких компов очень мало и "полноценно" поработать с ними, чтобы понять так ли это или нет, и если да, то что это за обновления, не получается - по сути это те компы за которыми следил по большей части наш отдел (на них специфический софт), и из-за этого их тяжело изъять из "оборота".

    Заранее спасибо за все попытки помочь, но ВСЕ что Вы советовали мы уже перепробовали и за две недели не по одному разу, был не опробованный совет с "netsh int tcp set global autotuninglevel=disabled", но он так же не помог исправить ситуацию.






    • Изменено KobaLTD80 2 марта 2016 г. 23:43
    2 марта 2016 г. 21:43
  • Имеется очень похожая ситуация, только на 2008 сервере. Тоже ищу способы решения.

    Увидел, что в логе IIS с промежутком в 5-10 мин идут сообщения о том что wsus выбирает всю память. 

    "A worker process with process id of '3180' serving application pool 'WsusPool' has requested a recycle because it reached its private bytes memory limit."

    В настройках IIS убрал лимит памяти на приложение WSUS'а.

    Ошибка при обновлении станции уже стала другая. "Exceeded max server round trips: 0x80244010 "


    • Изменено DaHTe 9 марта 2016 г. 10:20
    9 марта 2016 г. 9:58
  •  

    Ошибка при обновлении станции уже стала другая. "Exceeded max server round trips: 0x80244010 "


    1. Запустите команду WUAUCLT.exe /detectnow

    2. В случае, что у вас WSUS SP1, рекомендую обновиться

    3. Можете попробовать эту рекомендацию

    9 марта 2016 г. 11:29
  •  Спасибо не пригодилось. 

    Ошибка прошла после изменения в тех же настройках (IIS->Application Pools->Wsuspool->Advanced Settings) .NET Framework Version с 2.0 на 4.0 

    Станция очень долго искала обновления (96 штук, почти 3 Гб), но всё нашла и сейчас устанавливает.

    Для закрепления результата проверю еще на паре машин.


    9 марта 2016 г. 12:48