Nach einer langen Pause, möchte ich euch heute zeigen, wie das Windows Autopilot Deployment funktioniert.
Das Windows Autopilot Deployment ist eine neue Möglichkeit, um einem Mitarbeiter ein neues Arbeitsgerät bereitstellen zu können. Beim bisherigen klassischen Deployment müssen viele Schritte manuell durch die IT durchgeführt werden. Das neue Windows Gerät muss mit einem entsprechenden Windows-Image installiert , in ein Client Management Tool integriert werden und noch vieles mehr. Zuletzt muss das fertig vorbereitete Windows Gerät wieder von der IT eingepackt werden und beim Benutzer wieder aufgestellt werden. Wenn sich der Benutzer an einem anderen Standort befindet, kann das schon recht aufwändig werden. Ganz abgesehen von den Firstline Workern, die sich die meiste Zeit überhaupt nicht an einem Standort des Unternehmens aufhalten.
Um dieses Deployment zu vereinfachen/automatisieren, wurde das Windows Autopilot Deployment entwickelt. Eigentlich ist das Windows Autopilot Deployment eine Sammlung von Technologien und Tools um das Windows Geräte Remote vorzubereiten, damit der Mitarbeiter direkt damit arbeiten kann.
Soviel zur Theorie, nun starten wir mit der eigentlichen Konfiguration. Um Autopilot nutzen zu können, benötigen wir folgende Voraussetzungen:
- Azure Active Directory Premium P1 oder P2
- Mobile Device Management, z.B. Microsoft Intune
- Windows 10 Professional, Enterprise oder Education Version 1709 oder höher
- Zugriff auf das Internet für die Geräte
- Die Geräte müssen für die Organisation registriert sein
- Benutzer müssen auf Geräte in Azure AD zugreifen können
Zuerst müssen die Geräte für die Organisation registriert sein. Entweder kann der Hersteller die eindeutigen IDs der Geräte direkt im Tenant ablegen oder man muss dies manuell durchführen. In diesem Artikel zeige ich euch auch den manuellen Weg. Dazu muss das Gerät aber einmalig in Betrieb genommen und dann wieder zurückgesetzt werden. Die ID kann über PowerShell ausgelesen werden. Dazu sind folgende Befehle auszuführen:
Set-ExecutionPolicy Unrestricted Install-Script -Name Get-WindowsAutopilotInfo Get-WindowsAutopilotInfo.ps1 -OutputFile C:\Autopilot\hwid.csv
Wenn man das Skript nicht aus dem Internet herunterladen kann/darf, ist dies auch in der PowerShell Gallery zu finden.
Danach haben wir eine CSV-Datei, die die entsprechende ID für Autopilot enthält. Nachdem wir die Datei gesichert haben, können wir das Windows Gerät wieder zurücksetzten.
Dazu öffnen wir die Einstellungen App und führen die Wiederherstellung durch.
Nun können wir das Gerät für die Verwendung von Autopilot konfigurieren.
Im ersten Schritt müssen wir das Gerät zu unseren Autopilot-Geräten hinzufügen. Dies geschieht im Azure Portal (Intune).
Das Hinzufügen erfolgt über die vorher erstelle CSV-Datei.
Nachdem das Gerät erfolgreich hinzugefügt wurde, können wir es auch gleich einem Benutzer zuweisen.
Jetzt benötigen wir aber auch noch ein entsprechendes Autopilot Profil, dass wir jetzt anlegen.
Zuerst müssen wir einen entsprechenden Namen für das Windows Autopilot Deployment Profil vergeben.
Danach kommen wir zur Eingabemaske, die eigentlich alle verfügbaren Autopilot Einstellungen beinhaltet.
Die Einstellungsmöglichkeiten sind eigentlich selbsterklärend, ansonsten gibt es natürlich auch immer einen entsprechenden Hilfetext, der die Einstellung noch einmal genauer erklärt. Als letzten relevanten Punkt muss das Profil noch unserem Gerät zugewiesen werden.
Hierzu wird eine ganz normale Azure AD Gruppe genutzt, die unser Autopilot Gerät beinhaltet (Azure Active Directory).
Dann können wir das Windows Autopilot Deployment Profil erstellen.
Wenn wir nun unser registriertes Windows-Gerät starten, sehen wir Autopilot in Aktion. Es müssen nun keine unzähligen Konfigurationsschritte vom Benutzer mehr durchgeführt werden, sondern die Auswahl beschränkt sich auf die Region, Tastaturlayout und ggf. Internetverbindung (wenn nicht vorhanden).
Danach wird der zugewiesene Benutzer begrüßt und muss sich mit seinem Passwort anmelden.
Nun ist das Windows Autopilot Deployment schon fertig. Jetzt stellt ihr euch bestimmt die Frage: „Das war schon alles?!“
Zumindest was Autopilot betrifft, war es das. Allerdings ist Autopilot nicht umsonst in der Kategorie Intune zu finden. Das Gerät ist jetzt in Intune registriert und wir können nun die Funktionalität von Intune für die weiteren Schritte nutzen. Mit Intune können wir nämlich auch Software auf den Clients ausrollen. Dies zeige ich euch in meinem nächsten Beitrag.
Hallo Frank, welche praktischen Erfahrungen bei der Umsetzung von Windows Autopilot in der Schule haben Sie gemacht. Ich würde das gerne auch für unsere Notebooks an meiner Schule umsetzen.
Hallo Hardy,
bei Bildungseinrichtungen gibt es erfahrungsgemäß öfters die Herausforderung, dass die Devices von mehreren Benutzern genutzt werden. Hier müssen im Nachgang mit Intune (Education) noch ein paar Optimierungen vorgenommen werden. Ansonsten ist es meist auch ein Thema, dass sich die Benutzeridentitäten zwangsläufig in der Cloud befinden bzw. synchronisiert werden müssen. Hier haben Bildungseinrichtungen meist strikte Vorgaben. Ansonsten verhält sich ein Autopilot Deployment nicht sehr viel anders, wie in anderen Unternehmen auch.
Hallo Frank,
danke für die Zeit und Geduld dies hier zu beschrieben.
Ich hätte da aber eine frage, in diesem Beispiel ist es mehr wie ein Sysprep.
Wie kann ich nun einen Nacktes System neu Betanken via. inTune?
Ein Grund könnte sein, dass die Platte defekt ist und nun eine neue eingebaut wurde.
Hättest Du dazu einen Tipp?
Gruß
Markus
Hallo Markus,
mir fällt da spontan auch nur ein, den Hash manuell neu auszulesen.
Viele Grüße
Frank
Hallo Frank,
toller Beitrag!
Eine Frage hätte ich zum Software Deployment – kann Software auch via White Glove installiert werden oder kann Software erst immer nach dem Autopilot-Prozess installiert werden?
LG,
Mike
Hallo Mike,
leider habe ich mit White Glove noch nicht wirklich viel gemacht.
Kenne hier auch nur die Aussage von Microsoft dazu: https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/white-glove
Viele Grüße
Frank
Hallo Frank,
Vielen Dank für deinen Blog.
Vielleicht kannst du mir bzgl. Autopilot mit Hybrid join weiter helfen.
Szenario
Das Gerät wird per Autopilot betankt und als Hybrid Join konfiguriert.
Das Gerat hat keinen VPN-Zugang ohne befindet sich in der Nähe ein DC.
Frage:
Wie ist es möglich, dass sich ein Anwender an einem frisch betanken Systemen mit seinen AD-Daten anmelden kann.
Hallo Patrick,
so ganz verstehe ich die Frage nicht. 🙂
Bei einem Hybrid Join sind die Benutzer durch Azure AD Connect synchronisiert. Somit sind AD-Daten identisch zum Azure AD. Habt ihr ein ADFS zur Authentifizierung am laufen?
Hallo, danke für die Anleitung!
Kommt man auch „nachträglich“ in die Domäne (ohne Wiederherstellung)? Ich habe die Seriennummern etc. in Intune geladen, als der PC schon fertig installiert war.
Würde es gehen, wenn ich mich unter „Konten“ mit einem O365-Benutzer anmelde oder ist es dann nicht ganz sauber? Danke & viele Grüße
Hallo Christian,
man kann einen Azure AD Join natürlich auch jederzeit manuell ausführen. Eine kurze Anleitung findest du z.B. hier: https://www.msxfaq.de/cloud/client/azure_ad_join.htm#azuread_join_manuell
Man hat dabei eben nur den Nachteil, dass man es manuell ausführen muss und es nicht automatisch passiert, wie bei Autopilot.
Viele Grüße
Frank
Hallo Frank, die Anleitung ist sehr professionell gemacht. Wie gehe ich vor wenn ich statt Windows Pro die Enterprise Version benötige. Alle Hersteller liefern nur Pro aus.
Bisher spielen wir mit dem MDT eine konfigurierte Enterprise .wim Datei auf und den Rest mit Ansible. So wie ich es sehe benutzt der Autopilot ja nur das vom Hersteller bereitgestellte Betriebssystem Pro. Pro mit MDT zu Enterprise dann mit Autopilot und Intune Apps und oder noch Ansible ist krank. Viele Grüße Stefan
Hallo Stefan,
ja, dass stimmt.
Nachträglich (nach dem Rollout) kannst du natürlich z.B. über Intune (Device Policy) das Upgrade auf Enterprise durchführen.
Viele Grüße
Frank
Hallo Frank,
danke dir für die gute Anleitung.
ich hätte eine frage, bezüglich der Registrierung von Geräten mittels CSV Datei.
In dem unten genannten PS Script kann ich mittels generierter CSV Geräte registrieren, funktioniert auch. Doch ich würde gerne in die CSV den GroupTag mit ergänzen ohne händisch ran zugehen.
Ich hab bereits versucht im PS Script das zu ergänzen doch ich bekomm es leider nicht hin.:
New-Item -Type Directory -Path „C:\HWID“
Set-Location -Path „C:\HWID“
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv
Zudem würde ich auch gerne wissen, wie ich in Massen vorhandene Geräte registrieren kann, ohne an jedes einzelne Gerät zu gehen. Laut Microsoft gehen bis zu 500 Geräten gleichzeitig, aber habe auch hier nichts gefunden da in einem PS Script zu ergänzen.
Wenn du für beides eine Lösung hättest und diese in einem PS Script zu mixen, würde ich mich sehr gerne freuen.
Mfg
Gülben
Hallo Gülben,
für den GroupTag gibt es einen entsprechenden Parameter bei dem PowerShell Skript:
.\Get-WindowsAutoPilotInfo.ps1 -ComputerName MYCOMPUTER -OutputFile .\MyComputer.csv -GroupTag Kiosk
Mehr Beispiele kannst du dir über Get-Help anzeigen lassen, oder dir einfach den Quellcode dazu ansehen.
Wo genau willst du die vorhandenen Geräte registrieren? Nur in Entra oder in Intune für Autopilot? Wenn es um Entra geht, sollte das am einfachsten über eine Conditional Access Regel funktionieren.
Viele Grüße
Frank