Unsere Geräte werden in einem sogenannten Co-Management sowohl von unserem SCCM Server als auch über Intune verwaltet. Durch die Coronakrise stehen nun aber viele unserer Geräte bei den Lehrpersonen und Schüler/-innen zuhause und haben keinen regelmässigen Kontakt mehr zu unseren Servern.

Zum Glück haben wir die Windowsupdates bereits auf Intune umgestellt, somit ist sichergestellt, dass die Geräte diese auch zuhause erhalten. Die Softwareverteilung lief bisher über den SCCM Server. Nach einem kritischen Softwareupdate für den Adobe Reader musste ich zum ersten Mal ein win32 Programm über Intune verteilen, was auch gut funktioniert hat. Trotz diesem Co-Management lässt sich aber leider nicht alles auf Intune auslagern.

Wenn sich ein Benutzer zum ersten Mal an einem unserer Geräte anmelden möchte, muss eine Verbindung zum lokalen Domänencontroller bestehen. Dieses Konto bleibt dann so, bis sich der Computer das nächste Mal mit dem lokalen AD synchronisieren kann (also in der Schule ist), unabhängig von einer Passwortänderung in Office 365. Ich weiss nicht, wie lange ein Gerät überhaupt ohne Verbindung mit dem lokalen AD benutzt werden kann, bis man sich gar nicht mehr anmelden kann. Ein anderer “Schönheitsfehler” hat sich letztes Wochenende gezeigt. Die Umstellung auf Sommerzeit kommt bei den Geräten der Schule erst an, wenn diese sich in der Schule mit dem Domänencontroller synchronisieren können. Welche weiteren Probleme noch in Zukunft kommen, weiss ich nicht.

Nur AAD joined
Aus den oben genannten Gründen habe ich mich entschieden, die Geräte von dem lokalen AD zu lösen und nur noch als Azure Active Directory (AAD) joined zu betreiben. Dies lässt sich meines Wissens nicht einfach von einem “hybrid join”, wie unsere Geräte im Moment sind, umstellen. Daher führt der Weg über ein Neuaufsetzen mit Autopilot. Das möchte ich hier dokumentieren.

Devices
Es gibt verschiedene Wege, wie man die Autopilot Geräte im “Microsoft Endpoint Manager admin center” erfassen kann.

Der wohl bequemste wäre, beim “Deployment Profile” “Convert all targeted devices to Autopilot” auszuwählen. Dies hat bei mir aber nicht funktioniert, die Geräte blieben so in ihrem “hybrid” Zustand. Funktioniert hat der Weg über einen CSV Import, wie er hier beschrieben ist. Die Frage ist nur, wie man zu den gewünschten Informationen kommt, wenn die Geräte ausser Haus sind. Zum Glück gibt es seit einiger Zeit einen entsprechenden Bericht im SCCM.

Der Bericht muss aber noch angepasst werden. Die ersten 4 Zeilen kann man löschen und durch “Device Serial Number,Windows Product ID,Hardware Hash” ersetzen. Auch die Beschreibungen am Anfang jeder Zeile müssen gelöscht werden.

So lassen sich dann die gewünschten Geräte importieren.

Autopilot Gerätegruppe
Auch hier kann man der Anleitung von Microsoft folgen.

Deployment Profile
Wie man das Profil erstellt ist hier beschrieben. Ich habe folgende Einstellungen gewählt und dann der vorher erstellten Gerätegruppe zugewiesen.

Wipe
Um nun ein Gerät ausserhalb unseres Netzwerks als nur “Azure AD joined”, also ohne Verbindung mit dem internen AD, neu aufzusetzen, muss man das Gerät vollständig löschen. Man wählt also Wipe und setzt das Häklein bei “Wipe device, but keep enrollment state and associated user account” NICHT.

Kurz danach wird der Computer neu aufgesetzt.

Sobald er fertig ist, kommt man zum OOBE (out-of-box-experience). Hier muss man die Sprache Deutsch, …

… die Region (Schweiz) …

… und das Tastaturlayout auswählen.

Danach muss man sich noch mit dem WLAN zuhause verbinden.

Kurz danach kann man sich anmelden. Neu muss man als Benutzernamen die ganze Schul-Mailadresse eingeben.

Nun ist das Gerät zweimal im Azure Active Directory vorhanden. Einmal, weil es vom lokalen AD über Azure AD Connect ins AAD synchronisiert wird. Aus diesem Grund habe ich es nun aus dem lokalen AD gelöscht.

Gerätename
Bei dem oben beschriebenen Wipe Vorgang verliert das Gerät den Gerätenamen. Man kann das Gerät aber über die Seriennummer suchen und wieder auf den ursprünglichen Namen zurücksetzen.

Windows Lizenzierung
Unsere Geräte sind wurden mit einem generischen Schlüssel lizenziert, damit sie sich bei einem internen Server melden und sich so lizenzieren können. Früher lief das über einen KMS Server, seit 2015 haben wir auf Active Directory Based Activation umgestellt. Nun können sich die Geräte aber nicht mehr im internen Netzwerk melden und sich also auch nicht mehr korrekt lizenzieren.

Weil wir unsere Computer jeweils direkt mit dem neuen Image über OSD neu aufgesetzt haben, wurden sie nie mit dem in der Firmware hinterlegten Windows 10 Pro Key aktiviert. Microsoft stellt für diesen Fall auf dieser Seite ein Skript zur Verfügung. Zuerst habe ich dieses Skript als Intune App verteilt. Aber obwohl es von Hand funktioniert hat und auch die Logdatei geschrieben wurde, hat es nicht funktioniert.

Nach ein wenig Recherche und einigen Tests konnte ich dann ein Skript in PowerShell erstellen.

 $license = (Get-CimInstance -Query 'select * from SoftwareLicensingService').OA3xOriginalProductKey
Start-Process -filepath c:\Windows\System32\changepk.exe -ArgumentList "/ProductKey $license"

Dieseses kann man dann über „Devices“ -> „Scripts“ -> „+Add“ hinzufügen und der Gruppe mit den Autopilot Geräten zuweisen.

Autopilot Reset
Wenn man die Umstellung fertig hat, sind die Geräte vom lokalen AD getrennt. Ausserdem hat man nun die Möglichkeit, ein solches Gerät über “Autopilot Reset” zurückzusetzen.

Fazit
Microsoft hat gestern eine Anleitung für genau dieses Szenario veröffentlicht. Dort wird ein Cloud Management Gateway installiert. Ich bin nicht sicher, ob das dann alle Probleme wie die Authentifizierung am lokalen AD (für Passwortänderung, Umstellung auf Sommerzeit,…) löst, aber ich habe mich schon vorher dagegen entschieden. Unser langfristiges Ziel ist ein Übergang zu “modern management”, also dem Betrieb unserer IT ohne lokalen Server. Also wollte ich einen Weg suchen, bei dem die investierten Stunden und vielen Tests nicht “verloren” sind nach der Coronakrise (weil ich noch einen weiteren Server installieren und konfigurieren musste). Das was ich jetzt gemacht habe, stand sowieso auf meiner langfristigen ToDo Liste. Nur wäre es gut gewesen, wenn es nicht so pressiert hätte und wenn die Geräte in der Schule wären, falls irgendwo dann doch was schief läuft.

Nachtrag 1
Leider läuft der Vorgang nicht bei allen Geräten problemlos durch. Roger Zander hat eine geniale Lösung für ein Neuaufsetzen eines Gerätes unter dem Namen mOSD publiziert. Ich habe sie für unsere Zwecke angepasst und nun läuft ein Neuaufsetzen über einen so aufbereiteten Stick auf unseren Surfaces in unter 10 Minuten durch. Danach müssen sie, ähnlich wie frisch gekauft, noch den Autopilot Vorgang durchführen, bis sie voll einsatzfähig sind. Damit ist gerade auch eine meiner Fragen auf dem Weg zu modern management geklärt, nämlich wie man Geräte mit nicht mehr lauffähigem (oder wegen Malware nicht mehr vertrauenswürdigem) Windows ohne SCCM neu aufsetzen kann. Vielen Dank für die tolle Lösung an dieser Stelle.

Nachtrag 2
Einzelne Geräte haben den Autopilot Vorgang innerhalb unseres Netzwerks mit einem Fehler  0x800705b4 ab. Über diesen Beitrag bin ich dann auf den Beitrag von Michael Niehaus gestossen, in dem beschrieben wird, dass manchmal noch ein Update der TPM Firmware oder des EKPub Zertifikates benötigt wird. Und das hat der Contentfilter unserer Schule blockiert. Nach Sichtung der entsprechenden Logfiles musste ich eine Ausnahme für nuvoton.com, microsoftaik.azure.net und pki.infineon.com einrichten.