Wie in einem unserer vorangegangenen Artikel beschrieben sind verschiedene Vorarbeiten zu leisten. Wie z.B. ESD Entschlüsselungsbereitstellung für WSUS in Windows Server 2012 und Windows Server 2012 R2 sowie ggf. Update 1702 von SCCM (CB) und die Windows 10 Upgrade Unterstützung für WSUS. Aktivieren der Upgrades Klassifikation in der Software Update Komponente am Site System und nach einer erneuten Synchronisation sind diese unter „All Windows 10 Updates“ in der Software Library unter Windows 10 Servicing zu finden.

Der einfachste Weg besteht darin, mit Windows 10 Servicing in der Software Library, das entsprechende Feature Update bereitzustellen. Der Assistent funktioniert wie bei gewöhnlichen Updates und wird mit einem definierten Zeitplan, auf eine entsprechende Computersammlung gelegt.

Die Sammlung an Geräten kann z.B. mit einer automatischen Regel für einen abgelaufenen Unterstützungszustand erstellt werden.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System  LEFT OUTER JOIN SMS_WindowsServicingStates ON SMS_WindowsServicingStates.Build = SMS_R_System.build01 AND SMS_WindowsServicingStates.branch = SMS_R_System.osbranch01 where SMS_WindowsServicingStates.State = ‚4‘

Wer eine Automatisierung vorzieht generiert einen Service Plan, der im Grunde wie eine automatische Bereitstellungsregel von gewöhnlichen Updates funktioniert. Sollte jedoch unbedingt einem Releasemanagement unterzogen werden, wie in einem vorangegangen Artikel erwähnt.

Eine weitere Möglichkeit bietet sich mit einer „Upgrade an Operating System from an Upgrade Package“ Task Sequence. Diese ist vor allem sehr nützlich, wenn zusätzliche Prüfungen oder Anpassungen, Erweiterungen etc. erforderlich sind. Einziges Manko bleibt der Zeitaufwand, der deutlich über einem Service Update liegt.

Der eigentliche Zweck dieses Artikels beruht auf der Tatsache, dass innovative Neuerungen auch funktionierende Werkzeuge für Administratoren enthalten sollten, aber bei Microsoft scheinbar und offensichtlich vernachlässigt werden. So wurde seit geraumer Zeit ein Hotfix für die Windows 10 Upgrade Entschlüsselung unter WSUS veröffentlicht, mit dem die fehlenden DecryptionKey’s in der SUSDB nachgereicht werden sollen. Mit einigen Kunstgriffen funktionierte somit auch die Verteilung und man nahm an, das Problem gelöst zu haben.

Leider sind mit dem Windows 10 Creators Update 1703 erneut keine Schlüssel zur Entschlüsselung in der SUSDB hinterlegt, was zu folgender Fehlermeldung am Client führt: 0xC1800118

Überprüfung
Ergibt folgender Query eine Zahl größer 0 ist ihr System ebenfalls davon betroffen.

USE SUSDB
select TotalResults = Count(*)
from tbFile
where (IsEncrypted = 1 and DecryptionKey is NULL) or (FileName like ‚%15063%.esd‘ and IsEncrypted = 0)

Obwohl das Problem seit geraumer Zeit bekannt ist, zeigt sich der Hersteller von einer sehr nachlässigen Seite, jedoch führt wie schon oben erwähnt eine Erweiterung des Kunstgriffs zum Erfolg.

1. Powershell
   Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq „Upgrades“} | Set-WsusClassification -Disable
   $s = Get-WsusServer$1703Updates = $s.SearchUpdates(„version 1703“)
   $1703Updates | foreach { $_.Decline() }
   $1703Updates | foreach { $s.DeleteUpdate($_.Id.UpdateId) }Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq „Upgrades“} | Set-WsusClassification
2.  SQL Server Management Studio
   USE SUSDB
   declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);
   insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like ‚%15063%.esd‘ except select FileDigest from tbFileForRevision);
   delete from tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles)
   delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)
3. Powershell
   $s = Get-WsusServer
   $sub = $s.GetSubscription()
   $sub.StartSynchronization()

In unserem Fall waren nach dem Ausführen der Prozedur die DecryptionKeys in der WSUS Datenbank gesetzt und das Rollout konnte erneut gestartet werden.

Nach etwa 15 Minuten und mehreren Neustarts kann das System wieder verwendet werden.