В развернутом образе MDT появилась возможность применять накопительные обновления для Windows 10
Мое понимание проблемы изменилось, поскольку мы пытались устранить неполадки. Возможно, имеет смысл прокрутить вниз и прочитать "Обновление 6", прежде чем читать все тело.
Похоже, у нас возникли серьезные проблемы с обновлением Windows на новых машинах под управлением 1803.
KB4483234 не удается установить в цикле. Если вы удалите его из WSUS, он все равно попытается установить его на локальные ПК.
После некоторых исследований, я думаю, что KB4483234 является частью SSU KB4477137. На странице поддержки Windows для KB4483234 написано
"Если вы используете Центр обновления Windows, вам будет автоматически предложен последний SSU (KB4477137). Чтобы получить автономный пакет для последнего SSU, перейдите в каталог Центра обновления Microsoft". https://support.microsoft.com/en-us/help/4483234/december192018kb4483234osbuild17134472
Однако в WSUS были отдельные записи для 4477137 и 4483234. Я не совсем уверен, как это работает, поскольку одна была выпущена 12/11, а другая - 12/19. Но на основании того, что я могу сказать, у нас в настоящее время есть 4483234, помеченные как одобренные для удаления, и это, похоже, не потребовалось.
Даже если я сделаю
dism /online /remove-package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.472.1.0
а затем пометьте его как отклоненный в WSUS, это обновление все еще отображается, когда я запрашиваю Центр обновления Windows для запроса обновлений.
Поэтому я решил попробовать и начать удаление 4477137. Когда я пытаюсь удалить его вручную с
dism /online /remove-package /PackageName:Package_for_KB4477137~31bf3856ad364e35~amd64~~17134.464.1.0
это терпит неудачу, и полное чтение журналов показывает эту строку:
DISM DISM Диспетчер пакетов: PID=4600 TID=5116 Постоянный пакет не может быть удален. - GetCbsErrorMsg
Я понимаю, что могу отредактировать некоторые файлы MUM, чтобы удалить его, но я сомневаюсь, что это вызовет больше проблем. Мне нужно установить его в конце концов, чтобы получить следующий накопительный пакет, нет?
Итак, мне любопытно, если у кого-то еще есть проблемы с этими двумя обновлениями. Я ищу разъяснения о том, как эти два обновления связаны - в том, что статья KB, кажется, предлагает, чтобы они были вложены в одно обновление, но у меня явно есть два обновления. В конечном счете, я хочу знать, как лучше всего это исправить. На данный момент это влияет на некоторые из наших производственных машин, так как мы не можем установить функцию Windows, когда есть ожидающие обновления, но эти обновления просто терпят неудачу и возвращаются к ожиданию. Я в растерянности!
ОБНОВЛЕНИЕ 1:
Единственное сообщение об ошибке, которое появляется в журналах Центра обновления Windows, - 0x800F0922. Это, кажется, очень общее сообщение. В результате мы попытались сделать следующее:
Запустил SFC Scannow и все команды DISM cleanup-image, без изменений.
Я назначил букву диска системному зарезервированному разделу - он весело заполнен (430+ МБ без 500 МБ)
Я перезагружаю компоненты Центра обновления Windows, переименовывая их в Windows/SoftwareDistribution и Windows/System32/catroot2, без изменений.
Я включил все непроверенные функции для.NET Framework 3.5 и.NET Framework 4.7, без изменений.
Я полностью удалил все функции.NET Framework, без изменений
Я переустановил нормальные функции.NET, без изменений.
Я запустил средство устранения неполадок Центра обновления Windows.
Я пытался установить обновление прямо из каталога Windows.
ОБНОВЛЕНИЕ 2:
Комментарий предложил мне очистить временные папки. Я сделал методическую уборку;
Я допустил сбой обновления, поэтому в обновлениях Windows не было ожидающих обновлений, я вычистил папку%temp% и windows/temp. Перезагрузка, загрузка обновлений, установка, такое же поведение.
Я сделал то же самое, но выбросил очистку диска в смесь, без изменений.
Я позволяю обновлениям загружать и устанавливать до тех пор, пока они не будут перезагружены, затем я прошел и очистил временные папки и снова запустил очистку диска. Все еще никаких изменений в поведении.
ОБНОВЛЕНИЕ 3:
Еще одна вещь, которую я хотел упомянуть: я просто перечитал свой оригинальный пост, и есть небольшое упущение.
KB4471324 также не удается установить. Итак, KB4477137 установлен нормально - я неверно истолковал это как соединение с KB4483234, на который указывал один из ответов, - но KB483234 и KB4471324 оба застряли в этом цикле.
ОБНОВЛЕНИЕ 4:
Несколько строк из журнала CBS
До этого бита с ошибкой хеширования идет длинная цепочка совпадений с реестром, за которой следует короткий блок совпадений с каталогами. Что бы изменить эти файлы для изменения хэшей? Это скорее коррупция или что-то более гнусное?
2019-01-08 17:05:25, Info CSI 0000328a Warning: Overlap: Registry value collision found under key \REGISTRY\MACHINE\SOFTWARE\Classes\DeviceDisplayObject\AllItems\shellex\PropertySheetHandlers\{61F7B364-432C-4D04-BBC1-7FC1BF3807A8}\ for , only one component should set this value
2019-01-08 17:05:25, Info CSI 0000328b One of the components setting this value is Microsoft-Windows-FDBTH, version 10.0.17134.471, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2019-01-08 17:05:25, Info CSI 0000328c Previously seen component setting this value is Microsoft-Windows-FDBTH, version 10.0.17134.471, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2019-01-08 17:05:25, Info CSI 0000328d Hashes for file member [l:11]'install.ins' do not match.
Expected: {l:32 ml:4096 b:89df13e3b32a99da5730f0f3af7cef50d1eecb068ea58c377a5b797c5f592708}.
Actual: {l:32 b:775a0c4e6371ec5b3371866cae8a52e180594178c84ae96030d367a4afa2020f}.
2019-01-08 17:05:25, Info CSI 0000328e Hashes for file member [l:11]'install.ins' do not match.
Expected: {l:32 ml:4096 b:89df13e3b32a99da5730f0f3af7cef50d1eecb068ea58c377a5b797c5f592708}.
Actual: {l:32 b:775a0c4e6371ec5b3371866cae8a52e180594178c84ae96030d367a4afa2020f}.
2019-01-08 17:05:25, Info CSI 0000328f CSIPERF - RegistryPI Queue 446ms
2019-01-08 17:05:25, Info CSI 00003290 Registry installer wrote 2291 values
2019-01-08 17:05:25, Info CSI 00003291 CSIPERF - FilePI Queue 159ms
2019-01-08 17:05:25, Info CSI 00003292 Error: Overlap: Duplicate ownership for directory \??\C:\windows\SysWOW64\spp\tokens\pkeyconfig in component Microsoft-Windows-Security-SPP-Component-SKU-csvlk-pack-License, version 10.0.17134.441, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
ОБНОВЛЕНИЕ 5:
Проверены файлы install.ins. Есть 8 из них, 4 набора пар для вкуса x64 и x86. Самый последний
C:\Windows\WinSxS\amd64_microsoft-windows-ie-adminkitbranding_31bf3856ad364e35_11.0.17134.407_none_99e01535d6e245c0\install.ins
и был последний раз изменен 9/9/2018.
[Branding]
CompanyName=Microsoft Corporation
Wizard_Version=11.00.17134.407
Version=11,00,17134,407
Custom_Key=MICROSO
Global=1
IE4 Welcome Msg=1
Platform=2
GUID={7211FFE6-C149-11D0-AFF0-00AA003758BB}
Type=0
NoClear=1
ОБНОВЛЕНИЕ 6 И ВОЗМОЖНАЯ ПРИЧИНА
Итак, исходные параметры, над которыми мы работали, были неверными. Это не влияло на все машины на 1803. У нас было только несколько случайных машин на 1803, плюс большая партия идентичных новых машин. У наших двух ноутбуков, работающих под управлением 1803, возникли другие проблемы с обновлением. Описанная выше проблема совершенно уникальна для новой партии машин.
Новые машины были приобретены по двум причинам: одна для обновления двух наших высококлассных отделов, а другая для окончательного подтверждения концепции автоматизации развертывания ПК с помощью MDT. Поскольку все они были одним и тем же оборудованием, а у нас еще не было лицензии VLSC (сначала мы хотели обосновать покупку), я запечатлел их базовый образ OEM-производителя, вставил в него установку Chocolatey, ударил по ней с помощью шоколадного пакетного сценария. и поместил его в подразделение развертывания с объектами групповой политики для развертывания через MDT. Это было первое накопительное обновление, обнаруженное на этих машинах после такого развертывания.
Теперь у нас есть базовые образы VLSC, и я перенес на те же задачи на то же оборудование с новым базовым образом, и, кажется, все работает без проблем.
Мне все еще интересно узнать, смогу ли я исправить развернутый в данный момент образ. У меня развернуто 13 компьютеров и два запасных, но я не хочу прерывать работу всех наших веб-разработчиков и графических дизайнеров, выполняя еще один полный обмен. Но у меня по крайней мере есть одно "исправление" на столе.
Я изменил название поста, чтобы отразить некоторые изменяющиеся параметры
1 ответ
Вы неправильно поняли статью поддержки, в которой говорится:
Microsoft настоятельно рекомендует установить последнее обновление стека обслуживания (SSU) для вашей операционной системы перед установкой последнего накопительного обновления (LCU). SSU повышают надежность процесса обновления для уменьшения потенциальных проблем при установке LCU и применении исправлений безопасности Microsoft. Для получения дополнительной информации см. Обслуживание обновлений стека.
Если вы используете Центр обновления Windows, последний SSU (KB4477137) будет предложен вам автоматически. Чтобы получить автономный пакет для последней версии SSU, перейдите в каталог Центра обновления Майкрософт.
Другими словами, вы должны установить KB4477137 перед установкой KB4483234, и это произойдет автоматически, если вы используете Центр обновления Windows. Вам все еще нужно установить оба обновления, чтобы быть в курсе.
Даже если бы было возможно удалить KB4477137, было бы бесполезно делать это, во всяком случае, с большей вероятностью это ухудшит ситуацию.
Вместо этого вам нужно решить проблему, которая приводит к сбою установки KB4483234. Я предлагаю вам начать с загрузки ручного установщика из каталога Центра обновления Windows и посмотреть, работает ли он, а если нет, какое сообщение об ошибке выдает.
(Что касается того, почему он продолжал пытаться установить, даже после того, как вы отозвали утверждение в WSUS, это, к сожалению, типично для Windows 10. После загрузки обновления клиент Windows Update становится очень единодушным в его установке и, вероятно, игнорировать любые инструкции об обратном. Вы также можете обнаружить, что дата "последнего сообщения" на сервере WSUS для этих клиентов не меняется.)