OS Upgrade Task Sequence vs. Windows 10 pro OEM

Mit ConfigMgr Current Branch kann man ja bekannterweise mit einer „Upgrade an operating system from an upgrade package“-Task Sequenz das Betriebssystem auf eine höhere Version aktualisieren. Eigentlich keine große Zauberei, ABER …

Ich hatte genau dieses Szenario (Upgrade von Windows 10 1511 / 10586 / Threshold 2 und 1607 / 14393 / Redstone auf 1703 / Creator’s Update / 15063) probiert und hatte prompt Erfolg. Zumindest auf meinen virtuellen Testmaschinen. Ein erster Test auf „echten“ Rechnern schlug reproduzierbar fehl. Das Fehlerbild dabei: die Tasksequenz läuft an, startet das Windows Setup für das Upgrade durch den Schritt Upgrade Operating System

Executing command line: „C:\windows\ccmcache\xy\SETUP.EXE“ /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe „C:\windows\SMSTSPostUpgrade\SetupComplete.cmd“ /postrollback „C:\windows\SMSTSPostUpgrade\SetupRollback.cmd“ /DynamicUpdate Disable /compat IgnoreWarning

und initiiert dann einen Reboot. Die Tasksequenz wurde nach dem Reboot jedoch nicht fortgesetzt – das Windows Setup hingegen lief planmässig weiter, so dass das Endresultat ein Computer mit aktuellem 1703er Windows war.

Sofort zu sehen war, dass die Dienste SMS Agent Host und der Task Sequence Agent im Status „Disabled“ waren:

SMS Agent Host disabled

 

ConfigMgr Task Sequence Agent Disabled

Weiterhin befand sich der SCCM Client im Provisioning Mode (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec: ProvisioningMode: true):

Registry ProvisioningMode

Alle drei Zustände sind tatsächlich während der Task Sequenz erwünscht und korrekt, jedoch sollte ein Mechanismus dafür sorgen, dass der korrekte Zustand nach dem Betriebssystem-Upgrade wiederhergestellt wird. Einen Hinweis zur „Lösung“ (*) findet man in der Command Line, die die TS ausführt (siehe oben, Stichwort: SetupComplete.cmd und SetupRollback.cmd).

Also sorgt Windows dafür, dass die SetupComplete.cmd ausgeführt wird. Meistens. Also wirklich fast immer. Die „Lösung“ (*) steht in C:\Windows\Panther\UnattendGC\Setupact.log:

[windeploy.exe] Client OS edition and OEM license detected and no enterprise edition detected, will not run SetupComplete.cmd
[windeploy.exe] Not allowed to run the Setupcomplete.cmd, will not run SetupComplete.cmd

Die Meldung ist eindeutig. Windows meint, dass ein OEM-Lizenzkey erkannt worden und es keine Enterprise Version (Pro in meinem Fall) ist.
Das Verhalten ist laut https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/add-a-custom-script-to-windows-setup auch so gewollt:

Windows Setup scripts: Setupcomplete.cmd and ErrorHandler.cmd are custom scripts that run during or after the Windows Setup process. They can be used to install applications or run other tasks by using cscript/wscript scripts.

%WINDIR%\Setup\Scripts\SetupComplete.cmd: This script runs immediately after the user sees the desktop. This setting is disabled when using OEM product keys. It runs with local system permission.

%WINDIR%\Setup\Scripts\ErrorHandler.cmd: This script runs automatically when Setup encounters a fatal error. It runs with local system permission.

Also Sackgasse an dieser Stelle – zumindest für das Upgrade von Windows 10 Pro mit einem OEM-Key mittels Task Sequenz. Servicing Plans können als Alternative verwendet werden.

Auf meinen Test-VMs ist der Fehler nicht aufgetreten, da Windows gar nicht aktiviert worden ist.

(*) eine „Lösung“ kann ich aktuell nicht bieten. Das Thema habe ich mit der Product Group diskutiert und warte auf Feedback.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.