Развернутый образ MDT лишил возможности применять накопительные обновления Windows 10

Мое понимание проблемы изменилось, поскольку мы пытались устранить неполадки. Возможно, имеет смысл прокрутить вниз и сначала прочитать «Обновление 6», прежде чем читать все тело.

Похоже, у нас есть некоторые серьезные проблемы с Центром обновления Windows на новых машинах, работающих под управлением 1803.

KB4483234 не удается установить в петля. Если вы удалите его из WSUS, он все равно будет пытаться установить на локальные ПК.

После некоторого исследования я могу предположить, что KB4483234 является частью SSU KB4477137. предлагается вам автоматически. Чтобы получить автономный пакет для последнюю версию SSU, перейдите в каталог Центра обновления Майкрософт ". https://support.microsoft.com/en-us/help/4483234/de December192018kb4483234osbuild17134472

Однако в WSUS были отдельные записи для 4477137 и 4483234. Я не совсем уверен, как это работает, поскольку одна была выпущена 11 декабря, а другой - 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, без изменений.

Я назначил букву диска системному зарезервированному разделу - он, как ни странно, не заполнен (430 + МБ бесплатно 500 МБ)

Я сбросил компоненты Центра обновления Windows, переименовав Windows / SoftwareDistribution и Windows / System32 / catroot2, без изменений.

Я включил все неотмеченные функции для .NET Framework 3.5 и .NET Framework 4.7, без изменений.

Я полностью удалил все функции .NET Framework, без изменений

Я переустановил обычные функции .NET, без изменений.

Я запустил средство устранения неполадок Центра обновления Windows.

Я попытался установить обновление непосредственно из Каталога Windows.

---

ОБНОВЛЕНИЕ 2:

В комментарии предлагается очистить временные папки. Провела методичную чистку;

Я допустил сбой обновления, поэтому не было ожидающих обновлений в Windows Updates, я очистил папку% 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.11.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 компьютеров и два запасных, но я бы предпочел не отвлекать всех наших веб-разработчиков и графических дизайнеров, делая еще один полный обмен. Но у меня есть по крайней мере одно «исправление» в таблице.

Я изменил заголовок сообщения, чтобы отразить некоторые изменяющиеся параметры