Windows 10 1803 hat noch einige Bugs, die vor allem in Firmenumgebungen zu Problemen führen könnten. Nachfolgend möchte ich auf zwei Themen genauer eingehen. Zum einen können 1803-Clients wohl keine Computerzertifikate von Enterprise CAs beziehen und zum anderen können BitLocker-Wiederherstellungsinformationen nicht ins Active Directory (AD) gesichert werden.

Keine Computerzertifikate von Enterprise CAs

Ein User hat im Microsoft-Forum das Problem geschildert, dass auf Windows 10-Clients nach einem Upgrade von 1709 auf 1803 keine neuen Computerzertifikate mehr angefordert werden können. Laut weiteren Kommentaren bezieht sich das Problem aber nicht nur auf PCs, die von 1709 aktualisiert wurden, sondern auch auf Neuinstallationen. Weiteren Analysen zeigen auf, dass der Ursprung des Problems vermutlich mit fehlerhaften bzw. fehlenden Zertifikat-Templates zu tun hat.

Es existieren zwar mögliche Workarounds, von denen aber keiner recht praktikabel ist. Wenn es nur um wenige Maschinen geht, können die Zertifikate beispielsweise von Hand unter 1709 exportiert und unter 1803 wieder importiert werden. Unschön aber machbar. Bei mehreren PCs rät Microsoft zur Aktivierung des Credential Guards, denn damit klappt der Bezug von Computerzertifikaten wieder. Allerdings steht der Credential Guard nur unter Windows 10 Enterprise zur Verfügung, d.h. Firmen mit Windows 10 Pro haben Pech gehabt. Des Weiteren ist die Aktivierung von Credential Guard nicht ganz trivial und sollte auch nicht unüberlegt passieren.

Die derzeit wohl beste Lösung ist die Nutzung von “certutil -pulse”, wie es der Kommentar von MelanieQu detailliert beschreibt:

Look into the SMSTSPostAction variable as one way to run commands post task sequence (Google search on “SMSTSPostAction gpupdate” should return you some useful information. You can assign that variable cmd commands and when the task sequence has released, it will run them. This is a way you can run gpupdate post imaging and it may help with this scenario also.

The may be working for us. 4 out of 4 computers I just imaged with the fix below could connect to wireless on the login screen (prior to this those 4 out of 4 computers could never connect at the login screen). Testing more now, but appears to be a workaround.

1) Delete this key somewhere in the task sequence (don’t know for sure if this is needed, but I have added this for now based on someone’s suggestion above): HKLM\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache

2) Add a “Set Task Sequence Variable” task where Task Sequence Variable = SMSTSPostAction and Value = cmd /c gpupdate /force && certutil -pulse && shutdown /r /f /t 5

After the task sequence finishes, you will be at the login screen for a little bit while GPUpdate runs then certutil -pulse will go fast then restart in 5 seconds. I think the restart time could be 0. I just currently have it set for 5 seconds. Setting SMSTSPostAction could be set anywhere in the task sequence. I am setting it as the last task and removing the normal Restart Computer last task.

Microsoft hat indes bestätigt, dass es sich um einen Bug handelt. Die Lösung sei aber sehr komplex, weshalb ein entsprechender Patch noch auf sich warten lässt.

Keine BitLocker-Wiederherstellungsinformationen im AD

Zugegeben, der Fehler tritt nur unter bestimmten Voraussetzungen auf, zeigt aber wieder einmal, wie gut die Qualitätssicherung bei Microsoft ist.

Das Speichern der BitLocker-Wiederherstellungsinformationen im AD funktioniert demnach nicht, wenn BitLocker unter lokalen Konten genutzt wird. Bei der Verwendung  von Domänenkonten funktioniert das AD-Backup problemlos. Mir ist klar, dass innerhalb einer Domäne, die wenigsten Firmen BitLocker unter lokalen Konten aktivieren. Dennoch sollte diese Konstellation trotzdem funktionieren, was sie aktuell nicht tut. Abhilfe schafft hier entweder die Aktivierung von BitLocker mit Hilfe eines Domänenkontos oder die Nutzung von Microsoft BitLocker Administration and Monitoring (MBAM).