Utána szükséges a Remote Access service-t újraindítani:
Restart-Service RemoteAccess -PassThru
Ezzel a szerveroldali beállítások elkészültek. Szükséges viszont hogy a kliens oldalon is megegyezzenek az IPSec konfigurációk, itt is segítségül hívhatjuk a powershellt:
Hogy néz ki mindez, ha Intune-ból akarjuk kiküldeni az IPSec policyt? Nos, elsőre nem feltétlenül egyértelmű, hogy a fenti parancsban definiált értékek hol vannak az Intune policyban:
Hogy ne kelljen sokat keresgélni, tesztelgetni, itt egy működő beállítás:
Régi-régi igény a vállalatoknál, hogy az USB-eszközket kontroll alatt tartsák, megakadályozva az esetleges adatszivárgást. Erre jó választ ad az Intuneban is megtalálható Device Control funckió. Ugyanezt tudja biztosítani Group Policy segítségével is.
A Windows 10 21H1-gyel érkezett meg az “Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria” GPO-beállítás, ami lehetővé teszi, hogy ne csak szimpla tiltás-engedélyezés legyen, hanem kicsit granulárisabban. Például hogy tiltsunk minden USB-adathordozót, de tudjunk kivételeket is felvenni. A gyakorlati példában ezt fogom bemutatni.
Az alábbi flow mutatja a layered policy működését:
Ahogy látható, a Device Instace ID a legerősebb, ez jelenti magát az adott USB-eszközt. Ilyen példa a USBSTOR\DISK&VEN_KINGSTON&PROD_DTR30G2&REV_PMAP\001A92053F1CBF9161021EF9&0
Ezt az ID-t látjuk, ha a Device Managerben megnézzük az eszköz DeviceInstancePath értékét.
A sorrendben következő a Device ID, ami már általánosabb. Ezt a Compatible IDs kiválasztásával kérdezhetjük le
A gyakorlati példánkhoz elég ez a két érték. Most lássuk, hogyan valósítható meg Intune-managed gépeken esetén, hogy alapból tiltsunk minden USB-adathordozót, de specifikus eszközöket mégis engedélyezzünk.
Első lépésben engedélyeznünk kell az “”Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria” beállítást.
Ezt egy Custom OMA-URI beállítással tudjuk megtenni:
A Microsoft Endpoint Managerrel (régi nevén Intune) szabályozhatjuk a windows frissítések telepítését.
Az update és reboot mindig is küzdés volt a felhasználók és adminok között: “munka közben indult újra a gépem”, “frissítéskor csak teker és nem tudok dolgozni”, csak hogy pár panaszt említsünk. Sok esetben ezt a problémát a rosszul beállított update policy okozza.
Nézzük, hogy a MEM-ben milyen lehetőségeink vannak. A cikkben most csak az update telepítés és reboot részre térek ki, a többi opcióra nem.
Ha megnyitjuk a Windows 10 update ring-et, a következő beállításokat látjuk az User Experince Settings / Automatic update behavior résznél:
Az egyes beállítások részletezése:
Notify download: letöltés és telepítés előtt figyelmezteti a felhasználót, akinek kézzel kell elvégeznie a műveleteket.
Auto install at maintenance time: a maintenance időben letölti és telepíti a frissítéseket, kivéve ha a felhasználó használja a gépet, vagy pl. nincs töltőre dugva. A maintenance időt az Active hours beállítással adhatjuk meg (pl. 8-17 óra között nincs automatikus letötlés és telepítés-restart). Az újraindításhoz kéri a felhasználó engedélyét, ha ez nem történik meg 7 napig, utána magától újraindul.
Auto install and restart at maintenance time: hasonló az előző beállításhoz, csak itt a telepítés után automatikus restart következik (ha az eszköz nincsen használva). Az Active Hours megadásával a reboot itt is kontrollálható. A nem menedzselt eszközökhöz ez az alapbeállítás: telepítés után auto restart, ha nem hasznáják a gépet.
Auto install and restart at scheduled time: definiálhatjuk a telepítés napját-idejét. A telepítést követően elindul egy 15 perces visszaszámláló, amit a felhasználó elhalaszthat. Alapértelmezetten hajnali 3-kor telepít.
Auto install and reboot without end-user control: a frissítések letöltése és telepítése automatikusan megtörténik. Amikor az eszköz nincs használatban, a reboot is követi. Ennél az opciónál a felhasználónak csak read-only joga van a beállítási ablakon.
Reset to default: visszaállítja alaphelyzetre az auto update beállításokat
A fenti beállításokból kiválasztható a szervezet igényeinek megfelelő update mechanizmus.
A következőkben tekintsük át, hogy milyen figyelmeztetési lehetőségek vannak, a felhasználók felé.
Telepítés után, ha újraindításra van szükség, egy felbukkanó pop-uppal jelzi a rendszer. Ez a figyelmezetés 25 mp után eltűnik, és csak a kis ikon marad az óra mellett:
Amennyiben azt szeretnénk, hogy ez a figyelmeztetés megmaradjon és a felhasználónak kelljen nyugtáznia, kapcsoljuk be a Require user approval to dismiss restart notification részt a policyben:
Szintén egy hasznos funkció, ha a felhasználó figyelmét felhívjuk a közelgő kötelező újraindításra. Evvel lehetőséget adunk, hogy reboot előtt elmentse a megnyitott munkáit. A következő figyelmeztetéseket tudjuk megjeleníteni:
Azaz hogy az újraindulás előtt 4 órával fedobjon egy figyelmeztető üzenetet a felhasználónak, 30 perccel előtte pedig már egy elnyomhatatlan figyelmeztetés jelenik meg, visszaszámolással. Természetesen ezeket az értékeket állíthatjuk.
A frissítések telepítését és a gépek kötelező újraindítását kezelhetjük a Deadline beállításokkal is. Ennek lényege, hogy meghatározzuk, mikor kerüljenek fel az update-ek és mikor történjen az újraindítás.
A deadline a frissítés megjelenésétől számítja a megadott napokat. A fenti példa alapján, ha 10-én jön ki a frissítés a Microsoft Update-re, akkor legkésőbb 3 nap múlva automatikusan telepíti és megpróbálja az újraindítást is, ha az eszköz nincsen használatban. Ha definiáljunk Grace Period értéket, akkor annak értékével halasztja. Ez különösen hasznos, ha a felhasználó pl. szabadságról tér vissza, és így kap időt, hogy a telepítés-újraindítás kontrolláltan, pl. másnap történjen.
A deadline beállításokkal egy sokkal szorosabb frissítési ütemet tudunk kialakítani, mint az első részben taglalt beállításokkal. Amennyiben ezt a módszert választjuk, ne felejtsük el a Quality update deferral period (days) és Feature update deferral period (days) értékeket 0-ra tenni, különben policy conflict keletkezhet.
A deadline esetében max 30 napot határozhatunk meg.
Ajánlott konfiguráció: itt tennék egy szubjektív ajánlást, hogyan érdemes beállítani a teljes policyt:
Quality update deferral period (days): 7 nap. Így egy hétig nem ajánlja fel a frissítés telepítését, az IT addig tudja tesztelni a patch-et
Automatic update behavior: Auto install at maintenance time. A nem aktív időben a frissítések települnek és megjelennek a reboot kérő üzenetek, 7 napig. 7 nap után kötelező lesz a reboot, amiről figyelmeztetéseket jelenít meg.
Active hours start: 8 AM
Active hours end: 4 PM
Restart checks: Allow. Ha alacsony az akku töltöttsége, vagy presenting módban van a gép, akkor nem indul újra.
Require user approval to dismiss restart notification: Enabled. A felhasználónak kézzel kell leokéznia a pop-upot, evvel is tudatosítva benne, hogy a gépe újraindításra vár.
Remind prior to requried auto-restart with dismissible reminder: 8 óra
Remind prior to requried auto-restart with permament reminder: 1 óra
Change notification update level: Use the default Windows Update notifications
Összefoglalva: az update ring beállításkészlettel megtalálhatjuk a középutat a frissítések telepítése és felhasználói élmény negatív befolyásolása között.
Sokszor nemcsak az ügyfelek, de a tanácsadók is elveszettek lehetnek, hogy melyik M365 csomagban milyen szolgáltatás szerepel, milyen limitációkkal stb.
Az alábbi két táblázat hasznos lehet, hogy eligazodjuk a “rengetegben”
Amennyiben rendelkezünk Azure AD P1 vagy P2 és Cloud App Security licensszel (Microsoft E5, EMS E5 vagy Microsoft E5 Security), könnyen megakadályozhatjuk céges adatok letöltését, ha nem menedzselt eszközről lép be.
Nem menedzselt eszköz: ami nincs az Intune-ba bevonva vagy nem Hybrid Azure AD-tag.
A példában az Exchange Online-nál fogjuk beállítani, tehát ha nem menedzselt eszköről lépünk be az OWA-ra, akkor kötelező lesz az Azure MFA hitelesítés és nem fogjuk tudni a mellékleteket a gépre letölteni. Így megmarad a lehetőség az OWA elérésre bármilyen gépről, de csak “read-only” módban.
Azure AD Conditional Access beállítása:
Navigáljunk el a conditional access portálra és hozzunk létre egy új szabályt:
A céges hálózattól tartósan távollévő gépek menedzselésének kérdése nem újkeletű, több szervezetnek is okozott már fejfájást. Illetve új problémaként felmerült a COVID miatt, hogy sok felhasználó hirtelen távolról kényszerült dolgozni az eszközével.
Mit értünk tartósan távollévő gép alatt?
Olyan laptopokat, amik a felhasználási sajátosságok miatt alig lépnek be a céges hálózatba, legyen az irodai hálózat vagy VPN. Néhány opció:
orvoslátogatók laptopjai
biztosítási és egyéb utazó ügynökök laptojai
alvállakozók, akik kapnak céges laptopot, de nincs igény a belső hálózat elérésre
Kiemelten jó példa a gyógyszeripari cégeknék az orvoslátogatók gépei. Kapnak céges eszközt, használják a levelezést, a munkájukat tudják végezni, az irodába nagyjából sosem mennek be, hálózatra nem csatlakoznak fel.
Mi történik menedzsment szempontból egy ilyen géppel?
30 nap után megszűnik a domaines secure channel (“kiesik a domainből”)
Az előírt group policyk nem futnak le, nem frissülnek
A startup és logon scriptek nem futnak le
A wsus/sccm által kezelt frissítések nem települnek a gépre
Legrosszabb esetben akár az antivirus definiciós frissítések sem jutnak le a gépre (volt példa, ahol tiltották a frissítések internetről letöltését is)
Amint látjuk, ez a helyzet kellemetlen az IT-számára, hiszen ezen gépek felett gyakorlatilag elveszítette a kontrollt. A menedzselhetőség innetől a felhasználótól függ (mikor megy be az eszközzel céges hálózatra, mikor kapcsolja be a VPN-t stb…és milyen rossz az, mikor a céges bérelt vonalon kezd töltődni az akár több GB-os SCCM-csomag 🙂 ) A kockázat pedig adott: nem kerülnek fel a biztonsági frissítések, az IT nem értesül a gépet érintő incidensekről és lehetne sorolni.
Mi lehet a megoldás?
Toljuk ki a menedzsment határait a céges hálózaton kívülre! Gondoljuk át, hogy milyen nagyszerű lenne, ha az IT-felügyelet az Interneten kereszül történhetne! Az orvoslátogatók gépeinek üzemeltetői repesnének az örömtől.
Csináljunk Hybrid Azure AD joint, vagy akár Azure AD joint, Microsoft Endpoint Management (MEM) felügyeleti eszközzel párban. Evvel a következő lehetőséghez juthatunk (maradva az orvoslátogatók gépeinél)
Az on-premise domain gépet beléptetjük az AzureAD-ba is (ezt nevezzük Hybrid Azure AD joinnak. Innenől az AAD “ismeri” a gépobjektumot
Nincs secure channel hiba többé
A MEM segítségével teljeskörűen tudjuk menedzselni a gépet: frissítések telepítése, scriptek futtatása, VPN, emailfiók konfigurációk leküldése, megfelelőségek ellenőrzése (pl. lemeztitkosítás be van-e még kapcsolva), központi szoftvertelepítések
Jelentések-leltár futtatása a távoli gépeken, folyamatos státuszriportolással
Láthatjuk, hogy evvel a megoldással visszakapjuk az elveszett kontrollt a távollévő gépek felett.
Összegzés: érdemes átgondolni a kliensmenedzsment kérdését és válaszolni az új igényekre (céges hálózat nélkül is a kontroll megléte), erre az AzureAD és MEM egy jó alternatíva lehet.
Az utóbbi fél évben bekövetkezett távoli munkavégzés az IT-helpdeskek terhelését jelentősen megnövelte. Nézzünk pár tippet, amivel a felhasználók produktivitása is megmarad, a helpdeskről is levesz terheket és a működési költséget is csökkenti.
Elfelejett jelszavak problémája
Nagyon sok szervezetnél jelent kihívást, hogy kezeljék az elfelejettett felhasználói jelszavak resetelését. Ez mindenkinek rossz, hiszen a felhasználó addig nem tud dolgozni, az IT-helpdesknek pedig ismétlődő unalmas feladat. További kérdés, hogy a megváltoztatott jelszót hogyan juttatják el a felhasznónak (SMS, vagy magán emailcímre küldéssel? Ez vajon bizonságos?)
Azure AD Self-Service password reset szolgáltatással a felhasználó tud jelszót resetelni saját magának is, biztonságos módon (kétfaktoros hitelesítéssel)
A felhasználó pedig ezt látja:
Állítsuk be ezt szolgáltatást és oktassuk le a felhasználóknak. Megfelelő kommunikáció után akár 80%-kal is csökkenhet az “elfelejettem a jelszavam, resetet kérnék” esetek száma.
2. Windows upgrade-ek zavartalansága
A Windows 10-hez évente kétszer érkezik nagyobb frissítőcsomag, melyek telepítése minden esetben nagyon ajánlott. Érdemes up-to-date tartani az operációs rendszereket, mind a biztonsági, mind az egyéb funkcionális frissítések miatt.
Amennyiben viszont nem-Microsoft végpontvédelmi megoldás van használatban, az okozhat gondot a frissítési folyamatnál, ezáltal megint csak jelentős mennyiségű helpdesk-ticketet generálva.
Elkerülhető ez a probléma és a hosszas előzetes kompatibilitási tesztelések, ha végpontvédelmi megoldásnak a Microsoft Defender ATP-t használjuk. Az MDATP-vel nem csak a klasszikus vírusvédelmi megoldást lehet bevezetni, hanem a különböző fejlett támadási formákat is képes detektálni és megállítani.
3. Bátorítsuk a BYOD-ot!
Megint csak egy jellemző problémakör tud lenni az eszközök menedzselése. Új felhasználó érkezik a céghez, laptopra van szüksége, beállításokra, jogosultságokra stb. A gép átvételéhez személyesen kell megjelennie az irodában, várnia, ez mind-mind időveszteség.
Ezek csökkentésére egy megoldás lehet a BYOD-eszközök használata. Amennyiben van mód rá, érdemes bátorítani a felhasználókat hogy használják a meglévő eszközeiket (számítógép, mobil stb), ezáltal “önjáró” módon beálltani a munkakörnyezetét.
A Microsoft Endpoint Managerrel (régi nevén Intune), egy robosztus, biztonságos keretrendszer alakítható ki az ilyen eszközöknek (és természetesen a vállalati eszközöknek is). A MEM-mel biztosítható az eszközök felügyelet alá vonása (enrollment), különböző alap-alkalmazásokat lehet automatikusan telepíteni, VPN-beállítások leküldeni, különféle biztonsági beállításokat előírni.
A fenti környezetek kialakítása nem egyszerű, egylépéses feladat, viszont megéri a befektetést.
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 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.
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:Az 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ó:
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.
Az 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. 
Zoltan Istvanffy's IT Blog 