nekoal:
[more] Хочу тоже поделиться наблюдениям по долгому поиску обновлений.
Скажу сразу предысторию: что система была не из чистого образа, а поработавшая пару лет, обновлялась (в том числе и по советам данной темы) до июня прошлого года, потом начались эти долгие поиски обновлений и я отложил обновления до лучших времен. 25 мая сего года, вдохновившись новыми инструкциями решил разобраться с обновлениями.
Начал с удаления нерекомендуемых (скрывал я их конечно, но все равно пролезли) и напоролся-таки на грабли с удалением всего журнала обновления при удалении агента обновления. Год назад про это читал и забыл. После этого, пробовал много чего - КВ 3112343 по совету из шапки, потом 3138612, 947821, MsFix, WindowsUpdateDiagnostic, проверку dism - обновление не хотело работать и даже журнал не сохранялся. Впечатление что каждая диагностика первым делом выполняла сброс данных об обновлениях и начинала их снова формировать. Помогло кумулятивное обновление для IE 11 (3154070 на тот момент) - начал сохраняться журнал. После 40 минут поиска появился список обновлений, в том числе обновления .Net 3.5.1 за год и MSXML (973688 и 954430). После этого поиск прошел минут за 15. Мое предположение, что IE и MSXML были каким-то образом повреждены и поэтому средства диагностики тоже работали неправильно. При этом хочу заметить, что по работе у меня используются самописные скрипты с использованием MSXML для загрузки страниц и проблем с этим не было. Даже скрипт загрузки обновлений из данной темы сработал - обновления с download.microsoft.com по прямой ссылке загрузились на отлично.
Далее я наивно подумал что 15 минут слишком долго и решил, что может быть банерорезный прокси замедляет поиск, переключил на прямое соединение (сервер организации как работает как невидимый прокси и браузеры отлично работают на прямом соединении), и на удивление WU вообще отказался соединяться. После долгих экспериментов настроил командой netsh winhttp set proxy на сервер организации явным образом). Жирным выделил свой рецепт успешного обновления. После установки майских время сократилось до 5-10 минут, сейчас с неустановленным июньским списком снова минут 20. Соединение теперь работает, но видимо зависит от серверов Майкрософт, пару часов соединение есть, потом 3-4 часа нет. По наблюдениям часто есть связь в 3-5 утра мск (у меня не московское время, здесь пересчитано по москве), в 8-10 утра мск. Что похоже на издевательство так это работа заданий по расписанию с учетом часового пояса - в 17 часов мск прекрасно находит обновления, потом в 22 часа мск не может их загрузить и соответственно установить. Все время выдает отказ. В целом можно сказать что теперь это ручное обновление - мне нужно кликнуть установку когда связь заведомо есть, чтобы автоматически установилось. Хотелось бы сравнить наблюдения у кого в каком часу работает. Предполагаю, что в некоторых случаях 5 часов уходят как раз на попытки соединиться, поэтому время когда они нашлись тоже хотелось бы сравнить.
Про 3138612 - нужное для поиска обновлений, но отношусь с осторожностью. Так как в Windows\Temp лежит пустая папка MPTelemetrySubmit. Да, пустая, и в службах телеметрии не нашел и вроде бы нерекомендуемых не установлено, но дата изменения этой папки 3 дня назад. Может ли кто-нибудь пояснить по этому поводу?
Еще кое-что, до 25 мая я не ставил обновления которые есть в списке 1, если WU их не предлагала. На волне всех этих экспериментов с обновлениями, решил сверить что совпадает: из 216 Msu пакетов майского списка 1 (исключая 3 exe и 3 отсутствующие на download.microsoft.com), оказалось ранее установлено 184, неприменимо 5 (Media Center в основном), установилось 27 (в том числе необязательная ветка RDP 8, турецкая лира, индийский рупий, смена валюты латвии, справка HLP и т.п.). После их установки тормоза с поиском вернулись, пришлось откатить систему на точку перед их установкой. Полагаю, их просто нежелательно ставить поверх текущих, но для себя я их тоже наметил в черный список.
По поводу прошивок BIOS не совместимых с Win 8 и Win 10 - не удивлюсь, если в ближайшем будущем Агент обновления сможет и биос прошивать. В таком случае там наверняка будет возможность игнорировать номера версий - или как в случае с ветками обновлений версий GDR 18xxx и LDR 23xxx, переключился раз файл на LDR и уже не поставит этот файл GDR, так и версия для Win 10 всегда будет считаться новее. [/more]
[more] Хочу тоже поделиться наблюдениям по долгому поиску обновлений.
Скажу сразу предысторию: что система была не из чистого образа, а поработавшая пару лет, обновлялась (в том числе и по советам данной темы) до июня прошлого года, потом начались эти долгие поиски обновлений и я отложил обновления до лучших времен. 25 мая сего года, вдохновившись новыми инструкциями решил разобраться с обновлениями.
Начал с удаления нерекомендуемых (скрывал я их конечно, но все равно пролезли) и напоролся-таки на грабли с удалением всего журнала обновления при удалении агента обновления. Год назад про это читал и забыл. После этого, пробовал много чего - КВ 3112343 по совету из шапки, потом 3138612, 947821, MsFix, WindowsUpdateDiagnostic, проверку dism - обновление не хотело работать и даже журнал не сохранялся. Впечатление что каждая диагностика первым делом выполняла сброс данных об обновлениях и начинала их снова формировать. Помогло кумулятивное обновление для IE 11 (3154070 на тот момент) - начал сохраняться журнал. После 40 минут поиска появился список обновлений, в том числе обновления .Net 3.5.1 за год и MSXML (973688 и 954430). После этого поиск прошел минут за 15. Мое предположение, что IE и MSXML были каким-то образом повреждены и поэтому средства диагностики тоже работали неправильно. При этом хочу заметить, что по работе у меня используются самописные скрипты с использованием MSXML для загрузки страниц и проблем с этим не было. Даже скрипт загрузки обновлений из данной темы сработал - обновления с download.microsoft.com по прямой ссылке загрузились на отлично.
Далее я наивно подумал что 15 минут слишком долго и решил, что может быть банерорезный прокси замедляет поиск, переключил на прямое соединение (сервер организации как работает как невидимый прокси и браузеры отлично работают на прямом соединении), и на удивление WU вообще отказался соединяться. После долгих экспериментов настроил командой netsh winhttp set proxy на сервер организации явным образом). Жирным выделил свой рецепт успешного обновления. После установки майских время сократилось до 5-10 минут, сейчас с неустановленным июньским списком снова минут 20. Соединение теперь работает, но видимо зависит от серверов Майкрософт, пару часов соединение есть, потом 3-4 часа нет. По наблюдениям часто есть связь в 3-5 утра мск (у меня не московское время, здесь пересчитано по москве), в 8-10 утра мск. Что похоже на издевательство так это работа заданий по расписанию с учетом часового пояса - в 17 часов мск прекрасно находит обновления, потом в 22 часа мск не может их загрузить и соответственно установить. Все время выдает отказ. В целом можно сказать что теперь это ручное обновление - мне нужно кликнуть установку когда связь заведомо есть, чтобы автоматически установилось. Хотелось бы сравнить наблюдения у кого в каком часу работает. Предполагаю, что в некоторых случаях 5 часов уходят как раз на попытки соединиться, поэтому время когда они нашлись тоже хотелось бы сравнить.
Про 3138612 - нужное для поиска обновлений, но отношусь с осторожностью. Так как в Windows\Temp лежит пустая папка MPTelemetrySubmit. Да, пустая, и в службах телеметрии не нашел и вроде бы нерекомендуемых не установлено, но дата изменения этой папки 3 дня назад. Может ли кто-нибудь пояснить по этому поводу?
Еще кое-что, до 25 мая я не ставил обновления которые есть в списке 1, если WU их не предлагала. На волне всех этих экспериментов с обновлениями, решил сверить что совпадает: из 216 Msu пакетов майского списка 1 (исключая 3 exe и 3 отсутствующие на download.microsoft.com), оказалось ранее установлено 184, неприменимо 5 (Media Center в основном), установилось 27 (в том числе необязательная ветка RDP 8, турецкая лира, индийский рупий, смена валюты латвии, справка HLP и т.п.). После их установки тормоза с поиском вернулись, пришлось откатить систему на точку перед их установкой. Полагаю, их просто нежелательно ставить поверх текущих, но для себя я их тоже наметил в черный список.
По поводу прошивок BIOS не совместимых с Win 8 и Win 10 - не удивлюсь, если в ближайшем будущем Агент обновления сможет и биос прошивать. В таком случае там наверняка будет возможность игнорировать номера версий - или как в случае с ветками обновлений версий GDR 18xxx и LDR 23xxx, переключился раз файл на LDR и уже не поставит этот файл GDR, так и версия для Win 10 всегда будет считаться новее. [/more]