Herättääkö mikään niin paljon tunteita käyttäjissä kuin Windows-tietokone, joka haluaa päivittyä? Päivitykset tuntuvat aina tulevan väärään aikaan: ne keskeyttävät työn tekemisen tai sitten buutti kestää tavattoman pitkään.

Pahin lienee kuitenkin tilanne, jolloin päivityksiä ei tule ollenkaan. Tilanteet, joissa työasemien tietoturva sakkaa nopeuttavat IT-päällikön hiusten ennenaikaista harmaantumista. Hätä ei kuitenkaan ole tämännäköinen, sillä ongelmaan on useitakin erilaisia ratkaisuja. Minäpä avaan asiaa käytännön esimerkin kautta.

Korona-aika ja työasemien tietoturva

Asiakkaamme lähestyi minua taannoin, ja tuskaili etänä olevien tietokoneiden tietoturvapäivitysten huonoa jamaa. Korona oli ajanut käyttäjät koteihinsa eikä työmaan sisäverkkoon ollut enää asiaa. Päivitykset eivät menneet ollenkaan perille niille käyttäjille, jotka työskentelivät sisäverkon ulkopuolella. Tovin keskusteltuamme päädyimme yksissä tuumin istumaan alas, kartoittamaan nykytilanteen ja miettimään keinoja sen parantamiseksi.

Lupasin asiakkaalle, että mitä tahansa tehdäänkin, niin voidaan tehdä se Tietokeskuksen learn by doing -menetelmällä, jolloin asiakkaalle jää parempi muistikuva ja osaaminen tehdyistä ratkaisusta.

 

Ensimmäinen istunto: alkukartoitus

Istuimme alas tutkimaan nykytilaa ja totesimme, että asiakkaalla on sisäverkossaan Microsoftin vanha kunnon työjuhta: Windows Server Update Services, eli tutummin WSUS. Lämmin ja pörröinen tuote toki, mutta Microsoft ei kuitenkaan kehitä sitä enää ollenkaan eikä se ole enää vuosikausiin tarjonnut mitään uutta tällä rintamalla.

WSUS:n avulla työasemia oli pätsätty onnistuneesti jo pitkään, mutta nyt se ei enää palvellut etäilijöitä. Samaan syssyyn todettiin, että loppukäyttäjillä ei ole käytössään VPN-yhteyttä tai Direct Accessia. WSUS:a ei oltu julkaistu ulkoverkkoon, vaan se palveli ainoastaan sisäverkon tietokoneita.  Tämän lisäksi raportointi ja jakeluiden hienosäätäminen oli aavistuksen hankalaa työkalulla, jota ei enää kehitetä. Selvää oli, että jotain pitää tehdä tilanteen parantamiseksi. WSUS:lle äänestettiin yhteistuumin: ei jatkoon.

Infraa peratessamme kävi selväksi, että asiakkaalla oleva Microsoftin Configuration Manager (MEMCM, vanhalta nimeltään SCCM) oli jo valmiiksi venytetty pilven puolelle. Sinne oli tehty Cloud Management Gateway, eli tutummin CMG (IT-alahan tunnetusti rakastaa lyhenteitä).  Tämähän kuulosti hyvältä! Kyseessä on MEMCM:n – perinteisen onprem-tuotteen – laajennus, jolla toimintoja viedään pilveen ilman tarvetta rakentaa VPN-tunneleita muualle.  Päädyimme kokeilemaan tätä lähestymiskulmaa, jonka avulla tavoittaisimme myös kaikki internetissä olevat tietsikat.

Tuumasta toimeen siis! Varasimme asiakkaan kanssa yhden workshop-päivän, jonka aikana oli tavoitteena saada Windows-päivitysten infraa muutettua WSUS:sta Configuration Managerin suuntaan. Ja vielä niin, että asiakas osaa jatkossa sitä itse käyttää.

 

Toinen istunto: hihojen kääriminen

Aloitimme päivän siivoushommilla: nurkista oli saatava kaikki vanha konfiguraatio pois, jotta se ei haittaisi uutta. Toki pidimme mielessä, että huolehdimme pilotoinnista – emme tietenkään halunneet vaikeuttaa tilannetta entisestään. Vanhan WSUS:n annettiin palvella siihen asti, kunnes uusi tekniikka olisi tuotannossa. Varovainen siivous pienellä luudalla ensi alkuun.

Huomasimme, että aiemmin tehty CMG oli mennyt rikki. Pilven ja onpremin välinen putki oli sökönä. Syy löytyi hapantuneesta sertifikaatista, jonka saimme muutamassa minuutissa korjattua. CMG oli tulilla taas ja pystyimme jatkamaan.

Asiakas teki ohjeistettuna Configuration Manageriin Software Update Pointin ja tälle Automatic Deployment Rulet. Näiden veijareiden avulla saatiin tietokoneille jaettua pätsit päivän ja minuutin tarkkuudella, toteutettiin pilotointi ja tuotanto omilla aikatauluillaan. Kaikki hoitui automaattisesti ja ennen kaikkea tavoitettiin kaikki internetissä olevat työasemat.

 

Tuomio: tuhannet koneet päivitysten piiriin

Pilotointi onnistui hyvin: internetissä olevat tietokoneet osasivat hakea omat päivityksensä CMG:ltä tulevien ohjeiden perusteella. VPN:ää tai Direct Accessia ei tarvittu, mutta silti asiakkaan onpremissä oleva MEMCM pystyi turvallisesti jakelemaan päivitykset niin sisä- kuin ulkoverkon koneille. Ja mikä parasta: asiakas osaa nyt itse hallita järjestelmää (joka ei tosin enää vaadi juurikaan hallittavaa, koska kaikki automatisoitiin). Päivitysten statusraportitkin tulevat automaattisesti sähköpostiin haluttuna ajankohtana.

Asiakas päätti onnistuneen pilotin jälkeen rollata muutokset pikaisesti tuotantoon, ja näin tuhansia koneita saatiin jälleen tuoreiden päivitysten pariin. Uskoisin, että IT-päällikön hiuksissa mahdollisesti tapahtuva harmaantuminen hidastui ainakin hetkeksi.

 

Tee loppukäyttäjäkokemuksesta paras mahdollinen

Alussa mainitsin, että ajankohta päivityksille on aina huono. Tämän projektin alussa käytimme kotvan aikaa sen miettimiseen, miten loppukäyttäjän kokemus saadaan mahdollisimman hyväksi. Kokemukseen todettiin vaikuttavan ainakin:

  • riittävän pitkä deadline ennen pakottavaa buuttia
  • informatiivinen viesti-ikkuna päivitys- tai reboot-tarpeista ja
  • mahdollisuus ajaa päivityksiä Software Centeristä ennen deadlineä itse valitsemallaan ajankohdalla.

Kaikki tämä toteutettiin Configuration Managerin työkaluilla.

 

Työskentelyä kotona tai etänä – automatisoi kaikki päivitykset

Kaiken kaikkiaan tämä on klassinen esimerkki tilanteesta, jossa olemassa oleva tekninen järjestelmä ei enää vastaa muuttuneeseen tarpeeseen. Korona-ajan poikkeustilanteen pakottomana asiakkaamme henkilöstön työt ja laitteet siirtyivät sisäverkosta työntekijöiden koteihin. Nykyisin asiakkaamme pystyy kuitenkin hoitamaan tuhansien laitteiden kriittiset päivitykset automaattisesti – huolimatta siitä tehdäänkö työtä työpaikalla vai etänä.

Sille emme kyllä keksineet kiertotietä, että joskus on vaan päivitettävä 😊 Ehkä voisi vielä tutkia miten Wake on Lan -tyyppinen ratkaisu voisi toimia koneiden uinuessa. Hmm… palataan tähän vielä myöhemmin!

 

 


 

Lasse Pasanen
Päätelaitepalvelut, esimies