Monesti kuulee puhuttavan vain modernista päätelaitehallinnasta yleisesti, mutta itse miellän modernin päätelaiteasennuksen tästä erillään. Yleensähän se käytössä oleva päätelaite täytyy asentaa vain kerran elinkaarensa alussa, kun taas päätelaitehallintaa tehdään koko laitteen elinkaaren ajan.
Kuten monet tiedämme, Windows-käyttöjärjestelmien maailmassa laiteasennuksien modernisointiin on olemassa Microsoftin pilvipalvelu nimeltä Windows Autopilot. Windows Autopilotin pohjimmaisena tavoitteena on päästä eroon työasemamallinnuksien ja imageiden ylläpidosta esim. Microsoft Endpoint Manager Configuration Manager eli MEMCM (ent. SCCM) -järjestelmään, mikä luonnollisesti maksaa aikaa ja rahaa. Windows Autopilotin luonnollisena jatkumona laite päätyy asennuksen jälkeen myös modernin päätelaitehallinnan piiriin. Microsoft-maailmassa modernin päätelaitehallinnan virkaa hoitaa Microsoft Intune.
Tässä artikkelissa pureudun Windows-merkkisten työasema-asennuksien modernisointiin ja siihen, miten Windows Autopilot toimii.
Windows Autopilot yleiskuvaus
Windows Autopilot on periaatteessa hyvinkin yksinkertainen mekanismi. Tässä käytetään suoraan laitteelle asennettua OEM imagea, eikä varsinaista työasemamallinnusta/imagen ylläpitoa välttämättä tarvita.
Lisäksi laitekohtainen tunniste ”Hardware Hash” tulee olla toimitettuna yrityksen Windows Autopilot Deployment Servicelle. Tähän on olemassa muutamia tapoja, joista ylisimpiä:
- Otetaan laitteelta Hardware Hash manuaalisesti Powershell-komennolla
- Laitepaketin päältä löytyy usein PKID (=Microsoft Product Key ID), joka usein löytyy 13-merkkisenä numerona tai viivakoodina laitepaketin kyljestä
- CSP eli Cloud Solution Provider portaalin kautta voidaan viedä yleisimpien laitevalmistajien laitteita suoraan CSV-tiedostona sarjanumeron ja mallitietojen perusteella
- Lisäksi laitteelle voidaan viedä etukäteen tarpeelliset tiedot sisältävä JSON-tiedosto eli ns. Offline Windows Autopilot Deployment Profile
Oli tämä tapa mikä tahansa niin laitekohtaisen tunnisteen viennin jälkeen työaseman ensimmäisellä käyttöönotolla tulee kustomoitu ”OOBE”-ruutu, johon käyttäjät kirjautuvat Azure AD tunnuksin, jonka jälkeen halutut politiikat / sovellukset alkavat tippumaan Microsoft Intune -pilvipalvelun kautta työasemalle.
Kuulostaa helpolta ja yksinkertaiselta, mutta kun mennään hieman kurkistamaan konepellin alle, niin Windows Autopilotista on tarjolla useita skenaarioita, kuinka laitteet voidaan ottaa käyttöön ja juurikin tämä valittava skenaario määrittelee hyvin paljon sitä, että kuinka helposti laiteasennukset saadaan modernisoitua ja mitä kaikkia vaatimuksia tämä asettaa.
Pureudutaan näihin yleisimpiin eli Windows Autopilot – User-Driven Mode alla oleviin tapoihin:
- Azure Active Directory Join
- Hybrid Azure Active Directory Join
Valinta näiden välillä on aika helppo ja se määräytyy vastauksella muutamaan eri kysymykseen. ”Onko nykyiset laitteet liitetty on-premises Active Directoryyn?” ja jos on, niin ”Tarvitseeko Windows Autopilotin läpi käyttöönotettujen laitteiden olla siellä jatkossakin?”
Jos vastaukset ovat molempiin kysymyksiin ”Kyllä”, niin valinta on Hybrid Azure Active Directory Join -skenaario, jossa laitteet liitetään paikalliselle AD:lle ja Azure AD:lle. Tällöin meillä on pari liikkuvaa osaa enemmän kuin Azure Active Directory Join -skenaariossa, jonka myötä laitteet liitettäisiin nimensä mukaisesti vain Azure AD:lle.
Toki siirryttäessä modernien laiteasennuksien piiriin on syytä samalla katsella asiaa myös laatikon ulkopuolelta eli mihin kaikkeen paikallista AD:ta tarvitaan ja voisiko joitakin palveluita siirtää esim. Azuren pilvipalveluihin. Osa asiakkaistamme on aloittanut ympäristönsä kartoituksen, jossa puntaroidaan, mitkä järjestelmät ovat ylipäätään siirrettävissä pilvipalveluihin ja jos niin millä aikataululla. Useille toki siirtymä on hidasta tai jopa lähes mahdotonta eikä kaikki edes halua siirtyä kokonaan pilveen eli on hyvä, että Windows Autopilot tarjoaa tähän myös sen perinteisemmän vaihtoehdon.
Jotkin asiakkaamme ovat valinneet alkuun näistä jopa molemmat Windows Autopilot -skenaariot, kun tarkisteluissa on löytynyt joitakin käyttäjäryhmiä, jotka pärjäävät jo suoraan Azure AD Joined only -tyyppisillä työasemilla. Jotkut ovat valinneet tien, jossa käytetään Azure AD Joined only työasemaa ja esim. VPN-yhteydellä käytetään resursseja, jotka ovat vielä paikallisessa infrassa. Vaihtoehto toki tämäkin, mutta vierastan itse tätä ajatusmaailmaa suuresti, että miksi vain se työasema olisi pilvessä ja koko muu infra paikallinen? Mielipiteitä on toki monia, mutta tällöin loogisempi vaihtoehto on mielestäni Hybrid Azure AD Joined -työasema, kunnes ollaan oikeasti valmiimpia Azure AD Joined only -työasemiin.
Hybrid Azure Active Directory -skenaario on kumminkin vielä suurella osalla yrityksistä se ainut järkevä vaihtoehto ja tämä vaatii ympäristöön tehtäväksi myös hieman enemmän valmisteluja. Eli tarvitaan ainakin Intune Connector for Active Directory -integraatio, johon käy mikä tahansa domainissa oleva Windows Server 2016 -käyttöjärjestelmällä varustettu palvelin. Tämän avulla Windows Autopilotin läpi käyttöön otettavat laitteet liitetään paikalliselle AD:lle Offline Domain Join -tekniikan avulla. Lisäksi tarvitaan palvelin, jonka avulla paikalliselle AD:lle liitetyt työasemat synkronoidaan pilveen (esim. AAD Connect) ja sitä kautta tapahtuu laitteen Hybrid Azure AD join.
Seuraavaksi voidaan vastata kysymykseen ”Halutaanko modernisoinnin lisäksi huomioida myös hyvä käyttäjäkokemus?”. Koska olen varma, että kaikki vastaavat tähän ”Kyllä”, niin usein halutaan ottaa avuksi seuraavat Windows Autopilotin komponentit:
- Windows Autopilot for pre-provisioned deployment lyh. “Pre-provisioning” (ent. White Glove) – Varmistutaan, että sovellukset ja konfiguraatiot on asennettu jo ennen kuin käyttäjä saa työaseman.
- Enrollment Status Page (ESP) – Varmistutaan, että työasema on täysin valmis ennen kuin käyttäjä pääsee työpöydälle.
Näiden komponenttien avulla loppukäyttäjän tekemä työaseman käyttöönotto on jopa 5–15 minuutin luokkaa, eikä ylimääräisiä välikäsiä edes tarvita, kun prosessi on alusta loppuun hiottu kuntoon.
Oho! Tämä alkaa kuulostaa jo modernilta, mutta mitä seuraavaksi?
Ihan ilmaiseksi tämä ei valitettavasti kumminkaan tule.
Windows Autopilot -prosessikuvan hahmotelma voisikin olla seuraavanlainen:
Jotta ymmärretään, että miksi prosessi on näin monisäikeinen, avaan tätä hieman tarkemmalla tasolla. Onnistuneelle kokemukselle on alkuun jonkin verran esivaatimuksia itse käyttöjärjestelmältä, jonka tulee olla Windows 10 Professional, Enterprise tai Education. Näin ollen mikä tahansa marketista haettu Home-editiolla varustettu työasema ei Windows Autopilotille kelpaa.
BYOD (Bring Your Own Device) -malliin Windows Autopilot ei siis taivu vaan ennemminkin CYOD (Choose Your Own Device), jossa korporaatio antaa tietyt laitemallit tarjolle, joista voi valita haluamansa. Perinteisiin vanhoihin tapoihin verrattuna laitekirjoa voi hieman helpommin laajentaa, sillä työasemakohtaista mallinnusta ei varsinaisesti tarvitse tehdä. Korostan kumminkin, että jokainen listalle valittava työasemamalli olisi hyvä ainakin kerran testata, johon paljastuu syitä artikkelin edetessä.
Lisäksi en lähtökohtaisesti suosittele Pre-Provisioning ajoa vuosia vanhalle työaseman raudalle ja/tai vanhemmille esim. Win10 1709/1809/1909 käyttöjärjestelmille. Näistä kun saattaa seurata yllättäviä virhetilanteita johtuen esim. työasemalta puuttuvasta TPM 2.0 / TPM Attestation -ominaisuudesta tai vanhempien käyttöjärjestelmien bugeista. Lue lisätietoja.
Tilanne raudan puolesta pitäisi toki olla hyvä, jos Windows Autopilot ajetaan vain tuoreille työasemille. Käyttöjärjestelmän suhteen voi kumminkin tulla vielä vastaan kysymyksiä, jotka kannattaa varmistaa eli onhan käyttöjärjestelmä varmasti tuorein saatavilla oleva Windows 10? Jos ei ole, niin tulee miettiä että kuinkas se saataisiin siihen pudotettua ennen varsinaista Windows Autopilot -käyttöönottoa? Eihän se nimittäin ole mitenkään tavatonta, että uudetkin laitteet tulisivat 1–2 vuotta vanhalla Windows 10 käyttöjärjestelmällä esiasennettuina.
Toki teknisten esivaatimusten lisäksi yrityksen tietoturvaosasto on voinut linjata tiettyjä vaatimuksia, joista ihan esimerkkinä:
- Kaikilla laitteilla tulee olla BIOS-salasana.
Joillakin laitevalmistajilla BIOS-salasanan määritys ei ole ohjelmallisesti mahdollista, joten tämä on tehtävä käsin.
- Laitteen kovalevyn tulee olla kryptattu XTS-AES 256bit -tasoisella salauksella.
Yhtenä vaihtoehtona on käyttää BitLocker Automatic Encryption -toiminnallisuutta, jossa kryptaus käynnistyy automaattisesti käyttäjän ensimmäisen kirjautumisen yhteydessä. Kryptauksen taso on tällöin oletuksena XTS-AES 128bit eli jos vaatimus on 256bit, niin tämä voidaan toteuttaa määrittelemällä Intunesta konfiguraatiot kohdalleen ja ajamalla nämä sisään Enrollment Status Page (ESP) -vaiheessa jo ennen käyttäjän kirjautumista. Kryptauksen käynnistyksessä on toisinaan tavattu haasteita tiettyjen DMA-laitteiden kanssa ja tähän lähinnä viittasin ylempänä, että miksi olisi hyvä tehdä laitemallikohtainen testaus ennen laitteen ottamista viralliseen valikoimaan.
Kun nämä asiat ovat selvää niin tämän jälkeen tarvitaan vielä toimiva prosessi.
- Kuka vie laitekohtaiset HW hashit Windows Autopilot provisiointia varten?
- Kuka ajaa Pre-Provisioning vaiheen?
- Kuka määrittelee BIOS-salasanan?
- Kuka tekee laitemallikohtaisen testauksen?
Ylimääräisten välikäsien minimointi on ehdottomasti järkevää eli kannattaa haastaa esim. laitetoimittajaasi tai tukkuria tekemään nämä vaiheet jo ennen työaseman lähetystä, minkä jälkeen lähetys vasta käyttäjän toimistolle.
Mutta miksi toimistolle? Miksi en voi ottaa laitetta käyttöön kotisohvalta käsin?
Tämäkin on teknisesti mahdollista eli jos halutaan vielä ottaa ne laitteet kotisohvalta käsin käyttöön, niin onnistuu kyllä – tälle on vain pari teknistä vaatimusta lisää. Erityisenä huomiona, että tämä koskee vain Hybrid Azure AD Joined -skenaariota, sillä Azure AD Joined -skenaariossa tämä toimii suoraan.
Tässä Hybrid-skenaariossa, kun käyttäjä ja työasemat ovat Active Directory domainin jäseniä, niin laitteelle ei pääse ensimmäistä kertaa kirjautumaan ilman domain-yhteyttä – eli tarvitaan avuksi VPN-tunnelin muodostus. Ja koska käyttäjä ei ole vielä kirjautunut työasemalle, eikä laitteessa ole käyttäjäprofiilia, niin VPN-yhteys tulee pystyä muodostamaan suoraan kirjautumisruudusta.
Toki lisäksi saatetaan myös tarvita erillinen sovellus VPN-käyttöä varten ja VPN-asetuksia sekä usein sertifikaatti, joka on myönnetty yrityksen PKI-infralta.
Kaikki nämä yllä mainitut asetukset tulee pystyä hakemaan Pre-Provisioning ajon aikana työasemalle. Koska tämä ajo tehdään jo ennen varsinaisen käyttäjän kirjautumista, niin asetusten sekä sertifikaatin tulee olla laitepohjaisia (esim. käyttäjäsertifikaatti VPN-tunneliin ei siis toimi).
Perinteisessä IT-infrassa on yleensä paikallinen PKI-infra ja laitteille tarvittavat sertifikaatit jaetaan täältä hyödyntäen Group Policyjä. On hyvä lisäksi ymmärtää, että Pre-Provisioning-ajohan ei suoranaisesti vaadi yhteyttä domain-verkkoon vaan internet-yhteys riittää. Mutta jos ei ole domain-verkkoa, niin työasemalle ei saada myöskään tässä vaiheessa Group Policyjä ja näin ollen myöskään tarvittavaa sertifikaattia ei voida hakea.
Mikäli domain-verkon vetäminen esim. tukkurille ei onnistu, niin vaihtoehtoisia ratkaisujakin sertifikaatin toimittamiselle löytyy. Tällöin saatetaan tarvita SCEP eli Simple Certificate Enrollment Protocol -infran pystytys ja integrointi Intunen kanssa, mitä kautta tarvittava sertifikaatti saadaan toimitettua laitteelle suoraan myös internetin ylitse. Toki tämä on myös keino toimittaa sertifikaatteja tarvittaessa Azure AD Joined -tyyppisille työasemille, jotka eivät ole Group Policyjen vaikutuksen piirissä.
Pre-Provisioning-ajosta domain-verkossa on myös muita hyviä puolia, kuten laite saadaan Hybrid Azure AD Joinattua jo suoraan tässä vaiheessa, mikä edesauttaa ja nopeuttaa käyttäjäkokemusta.
Mitä jos jokin menee pieleen?
Kun on paljon liikkuvia osia, niin on mahdollista, että jokin vaihe voi toki mennä pieleen. Windows Autopilotin yhtenä huonona puolena nostankin esiin ongelmanselvityksen haasteet johon Microsoft on lupaillut parannuksia.
Artikkelin kirjoitushetkellä tämä työkalu odottaa vielä tuloaan, mutta vuoden 2020 Microsoft Ignite tapahtumassa julkaistiin, että Windows Autopilot Diagnostics -työkalu on tulossa, jolla saa ongelmatilanteessa laitteelta suoraan lisätietoja ulos CTRL + ALT + D näppäinyhdistelmällä. Tämä auttaisi paljon sillä nykyisin pitää osata avata Event Logit tai jopa suorittaa Powershell-komentoja, jonka avulla saadaan tarvittavat troubleshoot-tiedot ulos.
Kiinnostuin, kuinka tästä eteenpäin?
Hyvin suunniteltuna ja huolella tehtynä sekä huomioiden tuotteessa olevat rajoitteet Windows Autopilot on varsin toimiva keino ottaa työasemia käyttöön. Olenkin saanut todistaa asiakkaillamme jo satojen työasemien onnistuneita käyttöönottoja Windows Autopilotin kautta.
Useimmat Windows Autopilotin haasteet kumminkin liittyvät laitteen hankintamalleihin ja prosesseihin eli kuka tekee mitä, milloin ja missä.
Laitetoimituksissa voitte tarvittaessa ottaa Elisaan yhteyttä, sillä meillä näitä asioita on jo valmiiksi pureskeltu ja prosesseja on koeponnistettu toimivaksi useille eri asiakkaillemme.
Artikkelissa on kuvattu vain yleisimpiä kompastuskiviä, joihin olen eri asiakasprojekteissa törmännyt. Siihen taipuuko Windows Autopilot nimenomaan yrityksesi tarpeeseen voidaan hakea yhdessä vastausta esimerkiksi Elisan työpajan kautta.
Kysy räätälöidystä työpajakonseptistamme lisää!
Lue myös
Windows 7 vanhentuu – nyt on aika toimia
Liiketoimintatiedot turvaan Microsoftin pilvipalveluiden avulla
Laiterekisteröintiohjelmat iOS-laitteille – mitä ne ovat ja mitä hyötyä niistä on?
Surface-kannettavat ovat erinomaisia työkoneita
Kaikki artikkelitKirjoittanut
