Op basis van een recent Twittergesprek denk ik dat het de moeite waard is om te praten over een paar Microsoft onderwerpen op een hoger niveau. Ten eerste, wat zijn de doelen voor Windows Autopilot? En vervolgens, welke high-level scenario’s ondersteunt Windows Autopilot? (Ja, het woord “scenario” wordt veel te veel gebruikt, maar in deze specifieke context wil ik een helikopterview aannemen, dus ik heb het niet over feature-level scenario’s, maar over “wat zijn mogelijke” scenario’s).
Wat zijn de doelen voor Windows Autopilot?
De doelen van Windows Autopilot zijn als volgt:
- Windows Autopilot elimineert traditionele imaging. In plaats van images en drivers te beheren, gebruik je wat de OEM op het apparaat aanbiedt.
- Windows Autopilot is eenvoudig genoeg om eindgebruikers in staat te stellen het apparaat zelf in te zetten, zonder enige IT-interactie. Het doel is een set instructies van een halve pagina: Haal het apparaat uit de doos, sluit het aan, zet het aan, sluit het aan op Wi-Fi en typ je e-mailadres en wachtwoord in, en wacht terwijl het apparaat van software wordt voorzien middels provisioning.
- Windows Autopilot zorgt ervoor dat de apparaten aan het einde van het proces klaar zijn voor productief gebruik. De belangrijkste taak hier is om te voorkomen dat de gebruiker toegang krijgt tot het bureaublad totdat het redelijk klaar is – als je probeert om vroeg te beginnen en dingen zijn nog niet geconfigureerd of werken, zijn gebruikers gefrustreerd en bellen ze de helpdesk, dus we willen een meer gecontroleerde ervaring. Je moet weten wanneer het proces klaar is. Maar ook de managementtools (Intune, ConfigMgr, etc.) spelen hierbij een rol: elk apparaat moet op de juiste manier worden geconfigureerd op basis van de unieke eisen van de gebruiker, de rol van de taak, de locatie, etc.
- Windows Autopilot moet het mogelijk maken om apparaten eenvoudig te resetten (bijv. iets is kapot en je wilt het apparaat weer in een schone staat krijgen) of opnieuw te gebruiken (bijv. je wilt dat een gebruiker het apparaat aan een andere gebruiker overdraagt).
Achter de schermen gebruikt Windows Autopilot een apparaatregistratieproces dat apparaten aan organisaties koppelt (via koppelingen naar Azure AD), en een configuratieprofielmechanisme dat Windows vertelt hoe het apparaat zich moet gedragen als het wordt opgestart. (Voor degenen onder jullie die bekend zijn met niet-Windows platforms, zou dit vrij vertrouwd moeten klinken, aangezien er soortgelijke concepten bestaan voor iOS, Android, enz.)
Maar je moet Windows Autopilot niet zien als iets dat vereist dat je “all in” in de cloud bent. Het vereist zeker een zekere mate van cloud-aanhechting, maar als het jouw doel is om Windows precies zo te gebruiken als je vandaag de dag doet (met AD, GPO’s, file shares, ConfigMgr, etc.), dan kun je dat doen. Er zijn een aantal klanten die dit zien als een kans om hun hele omgeving volledig opnieuw in te richten, en een aanzienlijk aantal dat naar iets daartussenin kijkt – het beste van beide werelden.
Welke high-level scenario’s zijn mogelijk?
Het is interessant dat veel van de eisen die we van klanten hebben gehoord niet slechts kleine aanpassingen van hun bestaande processen zijn. In plaats daarvan zijn het scenario’s die voor hen vandaag de dag onmogelijk zijn. Stel je een aantal van deze voor:
- “We willen apparaten rechtstreeks van de OEM (of een reseller/distributeur) naar onze medewerkers verzenden – IT mag ze nooit aanraken.”
- “We willen apparaten overal kunnen inzetten – medewerkers hoeven niet naar kantoor te komen of verbinding te maken met ons bedrijfsnetwerk.”
- “We willen apparaten vanaf elke plek kunnen resetten – het gaat immers niet alleen mis als er apparaten op het bedrijfsnetwerk staan.”
En je kunt waarschijnlijk zien hoe producten en functies worden gecreëerd of ontwikkeld om deze scenario’s te ondersteunen – veel bouwstenen die, wanneer ze in verschillende combinaties worden samengesteld, nieuwe dingen mogelijk maken. Bedenk hoeveel moeilijker dit zou zijn zonder Azure Active Directory, OneDrive for Business, Microsoft Intune, Configuration Manager (zaken als de Cloud Management Gateway/Cloud DP), Office 365, Delivery Optimization, enz.
Als het gaat om Windows Autopilot, zijn er een paar hoofdonderdelen die worden gebruikt (met andere die eventueel kunnen worden toegevoegd). Laten we daar eens doorheen lopen.
Scenario 1: Windows Autopilot + Azure AD + Intune
Het eerste scenario dat Windows Autopilot ondersteunde was Azure AD Join voor identiteit/authenticatie, en Intune voor provisioning en doorlopende implementatie. Dat is een “cloud native” oplossing; het enige wat het nodig heeft is een internetverbinding. Windows Autopilot voert het initiële “bootstrapping” proces uit, waarbij het apparaat wordt verbonden met Azure AD en in Intune enrollt met een zeer eenvoudig proces voor gebruikers.
Toen het oorspronkelijk werd uitgebracht met Windows 10 1703, waren er uitdagingen: We hadden nog niet de Enrollment Status Page toegevoegd, waar veel klanten om vroegen (om redenen die eerder zijn besproken), en Intune had nog niet veel van de functies die het vandaag de dag heeft, zoals de mogelijkheid om Win32-apps van welke aard dan ook te installeren, PowerShell-scripts uit te voeren, Group Policy instellingen toe te passen via Administrative Templates, security baselines toe te passen, enz. Dus we hebben een lange weg afgelegd sinds die tijd.
Dit scenario heeft een aantal typische use cases:
- Bepaalde populaties gebruikers die nooit in een bedrijfskantoor komen – vaak kenniswerkers die onafhankelijke, zelfsturende rollen vervullen, of zelfs technici of chauffeurs. Echt, iedereen die moeite zou hebben om zich aan te sluiten op het bedrijfsnetwerk zou een kandidaat kunnen zijn.
- Organisaties die een schone start willen maken. Na meer dan 20 jaar is soms de enige manier om van de geaccumuleerde lagen van complexiteit af te komen, om vanaf nul te beginnen.
- Scholen. Ze hebben niet de mankracht om de on-prem infrastructuur te beheren en willen geen complexiteit.
- Startende bedrijven. Als je vandaag een nieuw bedrijf zou starten, zou je niet zeggen “laten we een stel servers opzetten.” In plaats daarvan zou je kiezen uit beschikbare cloud-diensten om de mogelijkheden te bieden die je nodig hebt.
Scenario 2: Windows Autopilot + Azure AD + Intune + ConfigMgr
Dit is een variatie op het vorige scenario, waarbij ConfigMgr aan de mix is toegevoegd. Ja, ConfigMgr kan Azure AD-gekoppelde apparaten beheren, en samen met Intune apparaten beheren door middel van co-management, waarbij je kiest welke workloads door Intune worden beheerd en welke door ConfigMgr. Intune distribueert de ConfigMgr client (agent), die idealiter gebruik kan maken van een Cloud Management Gateway om het beheer via het internet te ondersteunen.
Waarom zou je dit willen doen? Typisch, vanwege de aanzienlijke investering van de organisatie in ConfigMgr (die al 25 jaar bestaat en een enorme lijst van functies heeft). Bedenk hoe moeilijk dat zou zijn om te migreren – apps, OS-updates, gewenste configuratie, inventaris, etc. Migreer dus niet – blijf het gebruiken.
Nu wil ik graag zeggen dat er een grote mate van integratie is tussen Windows Autopilot en ConfigMgr. Sinds de eerste dagen van Windows Autopilot, heb ik gedroomd van de mogelijkheid om Windows Autopilot het apparaat te laten aansluiten op AD of AAD, het apparaat in te schrijven in Intune, de ConfigMgr-client uit te rollen en vervolgens een ConfigMgr-takenreeks uit te voeren om de provisioning van het apparaat af te ronden. We zijn er nog niet helemaal, maar het staat op de roadmap. Het zal werken, maar het vereist ofwel wat geduld (wachten tot de client geïnstalleerd is, de inventaris en discovery info rapporteren, wachten op collectie-updates, pollen voor nieuwe policies, etc.) of enige zorgvuldige configuratie en tweaking. Het sneller en eenvoudiger maken staat op de roadmap.
Scenario 3: Windows Autopilot + Intune + Active Directory
Natuurlijk, nadat Microsoft Windows Autopilot met ondersteuning voor Azure AD in Windows 10 1703 had uitgebracht, was de eerste vraag van klanten “Wanneer ga je Active Directory ondersteunen?”. Die ondersteuning kwam met Windows 10 1809. Het proces is een beetje anders dan bij Azure AD. In plaats van het apparaat te verbinden met Azure AD wat de Intune enrollment triggert, enrollt Windows Autopilot het apparaat eerst in Intune, en laat Intune dan helpen om het apparaat te verbinden met Active Directory (door gebruik te maken van een offline domein join proces dat al jaren bestaat, en dat geen inherent onveilige dingen vereist zoals gebruikersnamen en wachtwoorden in unattend.xml bestanden – als Microsoft zoiets vandaag de dag zou bouwen, zou het nooit voor de release worden goedgekeurd).
Welnu, terwijl ik zei “join Active Directory”, zul je dit scenario in de documentatie beschreven zien als “Hybrid Azure AD Join”. De naam komt verwarrend over, maar hier is een simpele uitleg: Nadat het apparaat zich bij AD heeft aangesloten, wordt het apparaatobject gesynchroniseerd in AAD (meestal met behulp van AAD Connect), en zodra dat gebeurt, is de Active Directory gebruiker ook in staat om een Azure AD gebruikerstoken te krijgen, wat verschillende voordelen heeft (bijv. single sign-on). Maar het belangrijkste is dat het de gebruiker in staat stelt om te communiceren met Intune.
Dus wat zijn de typische use cases hiervoor? Vrijwel alle gevallen die niet in de Azure AD use cases hierboven zijn opgenomen (hoewel de use cases met ConfigMgr zouden het volgende scenario gebruiken). Het is het de facto mechanisme voor klanten die niet op zoek zijn naar de sprong naar een Azure AD Join wereld. (Ik zou stellen dat meer klanten dit zouden moeten overwegen – voornamelijk als een manier om schoon te beginnen – maar de zin hebben om dit te doen varieert zeker).
Het enige ontbrekende stuk in dit scenario: Hoewel we het Active Directory join proces via het internet kunnen voltooien (met behulp van ODJ), kunnen we het volledige proces nog niet via het internet doen. We hebben een verbinding nodig met een domeincontroller om een van de belangrijkste redenen: De Active Directory gebruiker moet contact opnemen met een domeincontroller om zich voor het eerst aan te melden. Dit is iets waar Microsoft mee bezig us.
Scenario 4: Windows Autopilot + Intune + Active Directory + ConfigMgr
Nogmaals, dit is een variatie op het vorige scenario, door gewoon ConfigMgr toe te voegen aan de mix. Intune kan de ConfigMgr-agent installeren, waardoor het apparaat in een co-managed staat wordt gebracht. En het heeft dezelfde ConfigMgr integratie-uitdagingen, evenals dezelfde over-the-internet AD join beperkingen als het vorige scenario. Daar werkt Microsoft aan.
En voordat je het vraagt, ja, je kunt de ConfigMgr-agent op andere manieren installeren (startup script, client-push, enz.) – houd er alleen rekening mee dat je uiteindelijk toch wilt dat dit hele proces werkt, dus het is misschien beter om Intune het te laten doen.
Zo, gewoon een leuk, kort berichtje…