Windows patchelés Intune segítségével – Case Study

Az előző cikkemben értekeztem a modern megközelítésű patch menedzsmentről (Intune) , itt mutatnék részletes levezetést, ügyféltörténet segítségével.

Az adott ügyfélnél vegyes környezet volt, kb. 400 db on-premise domaines gép, és a felhős iránynak megfelelően, kb. 150 db Azure AD-joined eszköz is, Intune menedzsment alá bevonva.

Az AAD-eszközök viszonylag friss Windows 10 verzióval futtottak (1809-1903), de az onprem gépeknél nagy szórást tapasztaltunk (1703-1803). Itt a patch menedzsmentet az SCCM biztosította.

Problémák

Az ügyféllel a következő fájdalompontokat azonosítottuk:

  • zavaróan nagy a verzió fragmentáció, nincsenek egy szinten a gépek
  • nehézkes az SCCM-oldali adminisztráció (deployment csomagok összeállítása, kiküldése gépekre, monitorozás)
  • nagy a hálózat terhelése a laptopok miatt (home office és VPN)
  • szintén nagy terhelés és sok hibás deployment, ha SCCM-mel próbálták a feaure update-et teríteni
  • nagy a késleltetés, mire egy gép megkapja a csomagot (ha nem használ VPN-t)
  • lassú a visszariportálás (szintén a VPN hiánya miatt)
  • AAD-joined gépeknél nincs riport lehetőség

Megoldás

A megoldási javaslatunk a felhőalapú Intune-patch menedzsment volt, aminek alapja, hogy az update beállításokat az MDM-ből szedik a gépek, a frissítéseket pedig a Microsoft Update szerverekről töltik. A folyamatot a Windows 10 beépített Windows Update workflow vezérli.

Előkészületek

  • Hybrid Azure AD-join kialakítása (hogy az Azure AD-ban tudjuk az on-prem gépeket csoportokba sorolni)
  • Intune automatic enrollment beállítása (onprem gépek bevonása az MDM alá)
  • SCCM Co-management kialakítása (ennek segítségével definiálható, hogy az Update workloadot az Intune kezeli)
  • Intune-ban Windows Update Ringek kialakítása (teszt -és production gépek)
  • Windows 10 Feature Update policy beállítás (a gépek érjék el a cél 1909-es patch levelt, és a további feature update-eket ne telepítsék, evvel biztosítva a szinten maradást)
  • Update Riporting fukció beállítása

Technikai feladatok

Hybrid Azure AD-join kialakítása

Az ügyfélnél federált domaint használtak, ezért az AD Connect segítségével konfiguráltuk be a hybrid joint.

Ezután a Windows 10 eszközöknek definiáltunk egy Group Policyt, hogy regisztrálják be magukat az AzureAD-ba:

Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration > Register domain-joined computers as devices = Enabled

A sikeres device regisztráció után látható a gép az Azure AD portalon, mint Hybrid Azure AD joined

A kliensgépen pedig egy admin cmd-ben futtatott dsregcmd /status paranccsal ellenőrizhető:

Intune auto-enrollment beállítása

Az auto-enrollment segítségével az onprem gépeket be lehet vonni az MDM-felügyelet alá automatikusan

Az Azure Portalon ellenőriztük, hogy az MDM scope All-ra legyen állítva:

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Mobility

A GPO-ban definiáltuk az automatic enrollmentet:

Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> MDM > Enable automatic MDM enrollment using default Azure AD Credentials

Az enrollment sikerességét a kliensen a következő módon lehet ellenőrizni:

Start > Settings > Accounts > Access work or school

A Sync gomb segítségével lekérhetők a policyk:

SCCM Co-Management kialakítása

A 1910-es verziójú SCCM-mel könnyű munka volt a co-management kialakítása.

A gépeknek definiáltuk a windows update beállításokat.

Ilyenkor az SCCM kliensek bekapcsolják az ún. dual scan módot, azaz minden csomagot az SCCM-tól kapnak, kivéve a windows frissítéseket, ott a Microsoft Update-hez fordulnak.

Intune Windowsupdate ring

Az Intune-ban összeállítottunk egy policyt, ami a következő beállításokat tartalmazta a production gépek számára:

  • Windows- és egyéb Microsoft termékekhez való frissítések telepítése (pl. Office 2016)
  • A Quality kiadásától számított 7 napig nem ajánlja fel a telepítést. Ez lehetőséget nyújt az üzemeltetőknek, hogy teszteljék az update-eket és szükség esetén megállítsák a deploymentet (Pause Ring funkcióval)
  • A feature update-eket külön policy vezérli (lásd később)
  • Az aktív időszak 8:00-16:00 között tart. Ez idő alatt nincs letöltés, telepítés és reboot üzenet a felhasználó felé.
  • A telepítések után 7 napig a rendszer figyelmezteti a felhasználót, hogy szükséges az újraindítás. Ha nem teszi meg, akkor felugró üzenetben értesíti, hogy kötelező reboot lesz, és előtte 30 perccel egy kikapcsolhatatlan figyelmeztetést tesz a sarokba

End-user experience

A projekt során a felhasználókat tájékoztattuk, hogy a Windows fog figyelmeztetéseket megjeleníteni, ami a telepítésre-újraindításra hívja fel a figyelmet. A szövegpanelek ismerősek voltak mindenkinek

Windows 10 Feature Update policy

Az ügyfél saját tesztelései alapján a 1909-es verziót stabilnak találta, kompatibiltási problémák nem voltak, így erre a szintre kívántak hozni minden gépet. Továbbá követelmény volt, hogy az új release-ek ne kerüljenek fel (2004), ezt a a feature update policval biztosítottuk.

Update Riporting

Az update riporting funkcióhoz igénybe vettük az Azure Log Analyitcs Workspace-t, azon belül pedig a WaaSUpdateInsights funkciót. Itt lehet nyomon követni a Security és Feature Update státuszokat, hibajelentéseket.

A log analyitcs lekérdezéssekkel részletes státusz lekérdezhető

Természetesen maga az Intune Update Ring is tud statisztikát mutatni:

Eredmények

A konfigurációt követő 7 napon belül az onprem gépek több mint 95%-a elérte a Hybrid Azure AD Join és Intune MDM-enrolled állapotot. A leglátványosabb változás a feature update terén volt megfigyelhető, a teljes géppark kb 85%-a elérte a 1909-es buildet, 25 napon belül. Az IT-helpdesk kiemelten figyelte az esetleges frissítésekkel kapcsolatos panaszokat, de nem érkezett ilyen. A monitorozás során kiderült, hogy a maradék 15%-nyi gép az a ritkábban használt kategóriába esik, így ott várhatóan lassabb lesz a frissítési tempó. Néhány frissítés hibára futott, ott az üzemeltetők megvizsgálták a problémát, túlnyomórészt a C: meghajtón lévő kevés hely okozta a gondot.

Az ügyfél az átadott megoldással elégedett volt, az eredmények az elvárásokat nagyban felülmúlták. A meglévő Intune-licenszek ilyenfajta kihasználása és a céges infrastruktúra terhelésének csökkentése is sikeres volt.

Patch menedzsment – tradicionális vs modern megoldás

A Windows patchelés mindig fontos feladat volt. Figyelemmel kellett kísérni a havonta érkező hotfixeket, és mivel ezek sokszor tartalmaznak biztonsággal kapcsolatos hibajavításokat is, gondoskodni kellett a telepítésükről. A cikkemben megmutatnék két megközelítést, illetve tennék best practice javaslatot is, hogyan csökkenthető a patchelés unalmas munkája.

Mi a tradícionális megoldás?

Nagyobb cégeknél jellemzően SCCM-mel végzik a patchelést. Az SCCM egy nagyon sokoldalú, robosztus termék, tökéletesen megfelel a célnak. Nagy előnye a granularitás, igen részletekbe menően szabályozható (milyen patcheket küldünk ki, mikor küldjük, gépcsoportok szerinti telepítések, riportolási funkciók)Hátránya viszont, hogy komoly infrastruktúrát igényel, domaines környezetet, szakembereket. A megnőtt mobilitási igényeknél (pláne a COVID okozta remote work hullám) figyelni kell a hálózattól távollévő gépek menedzsmentjére. Nehézség lehet, ha egyszerre sokszáz gép tölti a frissítéseket a belső hálózatról, VPN-en keresztül. Ez mind a céges sávszélességet terheli.A SCCM patch workflow-t az alábbi ábra szemlélteti nagy vonalakban:19Az SCCM adminisztrátornak minden hónapban össze kell állítania egy szoftvercsomagot, azt eljuttatni a disztribúciós pontokra, gépcsoportokra telepítést meghatározni, később pedig monitorozni a sikeres-sikertelen telepítéseket. 

Mi a modern megoldás?

A Microsoft által modernnek hívott megoldást az Intune biztosítja. Ebben az esetben nincs szükség helyi infrastruktúrára, disztribúciós pontokra, egyéb megoldásokra. A patch menedzsmentet az Intune-on át a Microsoft Update biztosítja, a kliensek oda fordulnak és töltik le a frissítéseket. Ez a fent részletezett remote work scenárióknál komoly sávszélesség és erőforrás-spórolás a céges infrát tekintve.Az Intune patch management workflow az alábbi képen látható:Untitled 

Melyik a jó megoldás?

 

Általánosságban elmondható, ha nem előírás a nagyfokú kontroll a patch menedzsment minden lépésében, akkor érdemes a modern (Intune) megközelítést használni. A gépek az Intune-on át megkapják a windowsupdate policyket és azok mentén töltik le a frissítéseket a Microsoft Update-ről és telepítik. Evvel a megoldással biztosítható, hogy gyors legyen az update terítés és a gépek mindig a friss patcheket telepítsék.

Üzemeltetési oldalról is jóval könnyebb ennél a forgatókönyvnél, nincs szükség a fent részletezett lépésekre (patch csomagok összeállítása, deployment stb). A céges infrastruktúrát sem terheli a patch folyamat (sávszélesség, szerverek, tárhely)

A következő cikkembe bemutatom részletesen, hogy miként lehet az Intune-ra terelni a frissítési mechanizmust.

SCCM Capture “A fatal error occurred while trying to sysprep the machine.”

Image

Yesterday I ran into a weird issue when I tried to capture a Windows 10 image with sccm.

‘A fatal error occurred while trying to sysprep the machine.’

Let’s check the logfile: c:\windows\system32\sysprep\panther\setuperr.log

Hmm, the problem is related with one of the built-in application.
I didnt want to remove these apps.

In this Windows installation, the local username created for first time was ‘User’

In this time, I had an idea…what if local username was the problem?

Immediately I installed another image where the local username was ‘SCCM’. Test with sysprep…bamm, sysprep ran without error!

 

Wrapping up: do not use built-in usernames like ‘user’ or ‘administartor’ etc. Local username should be unique