A 25 éves ConfigMgr
A múlt hét végén írtam a ConfigMgr által elért jelentős negyedszázados mérföldkőről, és ma szeretnék kicsit mélyebbre ásni e hihetetlen termék történetében, megosztani pár bejelentést, és bemutatni egy kiváló új dokumentumfilmet (itt a Sundance áttekintése!), amely részletesen visszatekint a PC-kezelési iparágat létrehozó termék születésére és növekedésére.
A ConfigMgr konzollal kapcsolatos közlemény:
És a mai mérföldkő tudatában nézzük át a történetet, amelyet valószínűleg még sosem hallott:
Ahogyan minden kezdődött
A múlt hét végén alkalmam nyílt a Hermes projekt eredeti tervdokumentumának az újraolvasására. Évek óta nem láttam ezt a dokumentumot, és lenyűgöző volt látni, hogy a ConfigMgr milyen mértékben megőrizte az eredeti elgondolást. A dokumentumban körvonalazott alapvető építőelemek ma is használatosak, és még mindig azok alkotják a konzol alapjait.
1992-ben a Microsoft eredeti jövőképe (vagyis egy PC-t minden háztartásba és minden asztalra) elérte az ún. kritikus tömeget. A szervezetek agresszíven váltottak a terminálemulációról az x86-alapú számítógépmodellre, és nem állt rendelkezésre a PC-k nagy méretű kezelésére szolgáló megoldás. A csapat tudta, hogy a Hermes projektnek hatásosnak kell lennie.
Az eredeti SMS-csapat két teljes munkaidős fejlesztőből és egy Ken Pan nevű gyakornokból állt. Amikor 2003-ban csatlakoztam a csapathoz, Ken, a gyakornok vezette a körülbelül 150 mérnökből álló teljes fejlesztői csapatot. Azóta is Ken vezeti számomra az SCCM és az Intune mérnöki munkáit!
Anekdota: A Systems Management Server (SMS) első buildje a 245-ös számot kapta. Miért nem az 1-est? Nos… a Windows buildszáma ekkor 300 volt, és a csapat nem szerette volna, ha úgy tűnik, hogy nagyon lemaradtak – de tudták, hogy gyanút keltene, ha 300-hoz közeli számot választanak. Így a 245-öt választották!
Az SMS-t hivatalosan 1994. november 7-én indították útjára. Ehhez az első kiadáshoz két év kellett – ma az Insider-résztvevőknek új buildeket adunk ki minden hónapban!
Az elindulást követő nagy pillanat akkor következett be, amikor Bill Gates egy e-mailt küldött minden Microsoft-alkalmazottnak, amelyben bejelentette, hogy az SMS-t a cég egészében telepítik. A korábban mérnök Bill jelezte az e-mailben, hogy miként lehet eltávolítani az SMS szoftvert a gépről (ha valakinek ez állt szándékában). (:
A bejegyzésem alján beszúrtam az e-mailt arra az esetre, ha valaki el szeretné olvasni.
Az architektúra további fejlesztése
Az SMS 1.0, 1.1 és 1.2 verzió meglehetősen gyorsan megjelent, és következésképpen megszületett egy új piac. A csapat késlekedés nélkül elkezdett az SMS 2.0-n dolgozni.
És ekkortól váltak a dolgok… bonyolulttá.
És, őszintén bevallom, hogy hoztunk néhány rossz döntést. A fejlődési szemlélet jelentős részét a gyors tanulás képessége teszi ki – ez kezdettől fogva alapvető volt az SMS csapatának.
Sok minden változott az ügyfélkiszolgáló alkalmazások architektúrájának felépítésében 1992 óta. A csapat lényegesen átírta az SMS-kiszolgálóinfrastruktúrát 1997-ben és 1998-ban, hogy előremozdítsák az SMS méretezését és teljesítményét, és integrálták a Windows Server 2000 leendő funkcióit. Ez volt az első alkalom, hogy a csapat átírta az SMS-architektúrát, hogy az akkori állapotoknak megfelelő csúcsminőséget biztosítsa.
Az SMS 2.0-t 1999 januárjában adták ki, és a bevezetés és használat rohamosan nőtt. Akkoriban az SMS legnagyobb versenytársánál, a Novellnél dolgoztam, és a Novell ZENworks csapatát vezettem. Valószínűleg össze sem tudnám számolni, hogy hány órát töltöttem az SMS-ügyfelekkel a ZENworks újdonságait megvitatva, amelyek a felhasználókra (identitásokra) való összpontosításon alapultak, mélyreható címtárintegrálással!
A bejegyzés írása közben eszembe jutott, hogy az SMS 2.0-s verzióban elrejtettünk egy húsvéti tojást (Easter egg). A húsvéti tojás egy videó volt, amelyen a terméken dolgozók neve és képe jelent meg, és amikor még egyszer megnéztem a héten, kiemelkedett egy név:
Ah, Terry Myerson – a főnököm, aki a Microsoft ügyvezető alelnöke. Úgy hiszem, az SMS összes nagyszerű eseménye ténylegesen a karrierje egy pontján történt. (:
Akkor csatlakoztam az SMS csapatához, amikor beindultak az SMS 2003-hoz vezető munkák.
Az SMS 2003-ban a termék jelentős része ismét át lett írva. Akkoriban nagy mérföldkőnek számított az SMS igazítása a WSUS szolgáltatáson a javításhoz. Ez irányította a Microsoft-javítást a felhőből (Windows Update) az ügyfelekhez és a vállalathoz. A WSUS lényegében ugyanaz a háttérben futó intelligens átviteli szolgáltatás, amely a Windows Update-hez is használatos – kivéve hogy adatközpontban fut.
A Windows Update a világ egyik legnagyobb felhőszolgáltatása – több mint 1 m eszközt frissítve havonta. Szánjon erre egy percet: A Microsoftot a nyilvános felhőben leginkább a hibrid funkcióink és az a képesség különbözteti meg, hogy az adatközpontjában futtathatja a nyilvános felhőnket. A Windows Update futtatása az adatközpontjában (WSUS) valóban egy úttörő és talán a legkorábbi példa volt arra, hogy miként lehet a felhőhöz csatlakozni és hibridnek lenni. Ekkor gyorsult fel lényegesen a laptophasználat, és kellett készítenünk egy új ügyfelet, amely működött egy leválasztott vagy lazán csatlakoztatott modellben.
Amint közeledett az SMS 2003 kiadása, minden péntek reggel találkoztunk a cég munkatársaiból álló csoporttal, hogy értékeljük a projekt állapotát. Az értekezletre meghívott csoportok közül az egyik legfontosabb a Microsoft IT-részlege (MSIT) volt. A cégnél precedens nélküli módon, feljogosítottam az IT-csapatot, hogy megvétózzák az SMS 2003 kiadását, ha úgy érzik, hogy még nincs kész. Az MSIT az első és azóta is a legjobb ügyfelünk – valamint a legjobb forrásunk, ahonnan visszajelzést kapunk a korai buildekhez.
Napjainkban több mint 500 000 PC-t és mobileszközt kezelünk itt, a Microsoftnál (ebben a számban nincs benne a 100 m MAD) egyetlen ConfigMgr telepítésen keresztül. Folyamatosan telepítünk háttérben futó intelligens átviteli szolgáltatásokat a Microsofton keresztül, mivel minden hónapban készítünk egy kiadást. Mi valóban használjuk a termékeinket. Másik anekdota: A csapatom gyakorlatilag felügyeli a ConfigMgr belső telepítését. A tanulás legjobb módja maga a gyakorlás!
2003 és 2007 között kiadtunk két „funkciócsomagot”. Nem szerettünk volna egy teljesen új termékre várni ahhoz, hogy új funkciókat adjunk ki, ezért kitaláltuk ezt az új módot. Az első funkciócsomag befejezte a WSUS hozzáigazítását a javításunkhoz. A második funkciócsomag az operációsrendszer-telepítés kiadásakor volt.
Az egyik kedvenc emlékem ebből az időből egy demó volt, amelyet egy európai eseményen szerveztünk 2003 novemberében az új operációsrendszer-telepítési funkciók bemutatásakor. Bill Gates tartotta az előadást, és „Az SMS újdonságai” rész alatt élőben frissítettünk 100 PC-t egy Bill mögött lévő falon. A demónak a „Tűzfal” nevet adtuk.
Itt egy kép Billről, amelyet akkor készítettünk, amikor megfordult, hogy megnézze a demót:
Ez a kép pedig a demót tartó bátor SMS-csapattagokról készült:
Hatással a világra
2004 őszén Bill és Steve külső helyszíni értekezletet tartott a cég néhány vezetőjével – és a napot egy nyílt kérdés-válasz program zárta Billel és Steve-vel. Valaki megkérdezte Billt, hogy mit gondol, „mi volt a legfontosabb dolog, ami a Microsofttal történt a múlt évben”. Bill válasza: „Kész az SMS és az Active Directory – és ezek óriási előrelépést jelentenek számunkra.”
Mind a mai napig ez szakmai karrierem legszebb napjainak egyike!
2007-ben az „SMS” nevet „ConfigMgr” névre módosítottuk, hogy a System Center márkához igazítsuk. A Desired State Configuration (DSC) volt a legújabb innovatív forgatókönyv, amelyet az ügyfelek kértek, ezért ismét átalakítottuk az architektúrát, hogy valóban lehetővé tegyük a DSC működését a megfelelő módon. Emellett teljesen átírtuk a felügyeleti felületet is.
2011 februárjában, félúton az SCCM 2012 készítésekor, Satya átvette a Server and Tools Business (STB) vezetését, átnevezte Cloud and Enterprise (C+E) névre, és a főnököm lett. Az első négyszemközti megbeszélésünkön Satya bejött az irodámba, és az idő nagy részében próbált jobban megismerni. Hihetetlen élmény volt közvetlenül Satyának dolgozni néhány évig, és tanulni az ő lenyűgöző, kíváncsi természetéből, a fejlődési szemléletéből és a vezetés iránti alázatos hozzáállásából. Satya óriási hatással volt a ConfigMgr jövőjére és architektúrájára e kiadás során.
A ConfigMgr 2012-ben alapvetően a feje tetejére állítottuk az architektúrát azzal, hogy az architektúrát és a felületet tekintve a felhasználókra – és nem csak az eszközökre fókuszáltunk.
Az ügyfelek jelezték, hogy a jövőben a mobilitás fontos lesz, és megértettük, hogy ez nem csak az eszközök, hanem a felhasználók mobilitásáról szól. Erre válaszul drasztikusan egyszerűsítettük az architektúrát, hogy kisebb hardverigényű legyen, és jelentősen növeltük a méretezési korlátokat. Ez az a pont, ahol a felhőbe vezető utunk valóban, valóban komollyá vált; csatlakoztattuk a ConfigMgrt a Microsoft Intune-hoz, és az Intune lényegében a ConfigMgr pereme lett.
Ez a hibrid konfiguráció lett az a modell, amely lehetővé tette számunkra, hogy innovációkat hozzunk létre a felhőben, majd új értékkel egészítsük ki a helyszíni ConfigMgr eszközt a hibrid telepítésen keresztül. Úgy gondoltuk, hogy a felhő a múltban lehetetlen forgatókönyveket fog lehetővé tenni, és Satya látta a felhő eszközkezelésre gyakorolt lehetséges hatását – és valóban ösztönzött bennünket, hogy ezen a téren újítsunk és kísérletezzünk.
A ConfigMgr útja a felhőbe
Az architektúra következő előrelépése jelentette ezidáig a legnagyobb kihívást.
Amikor egyértelmű lett, hogy a Windows 10-et szolgáltatásként fogjuk megjelentetni évente több frissítéssel, tudtuk, hogy a ConfigMgr jövője is ez lesz, és át kell telepíteni a felhőbe.
A kihívás itt ijesztő mértéket öltött.
A ConfigMgr korábban 2–3 évente jelent meg. Emlékszem, hogy az SCCM 2007 első teljes tervét nézve 16 hónapnyi stabilizációs és bétaidőszakot láttam a kód befejezésének bejelentése és a kiadás között. 16 hónap! Világos volt, hogy szolgáltatott szoftverré kell átalakítani a ConfigMgr eszközt, hogy fenntarthassunk egy évente többszöri kiadási ütemet.
Egy ilyen ijesztő feladattal előttünk, elkezdtünk kiválasztani egy mérnökökből és programmenedzserekből álló kis csapatot, akik alaposan ismerték a ConfigMgr eszközt, fejlődési szemlélettel rendelkeztek, és osztották az ügyfélalapú megközelítés iránti szenvedélyünket. Úgy véltük, hogy ez egyedül úgy sikerülhet, ha egy kis és motivált csapat alaposan átvizsgálja az egész architektúrát, és létrehoz egy felhőalapú szolgáltatást a földről a felhőbe.
Be kell vallanom, hogy amikor megnéztem az átvizsgálás ütemtervét, némi szkepticizmust éreztem, a szokásos optimizmusommal keveredve. Hihetetlen vállalkozás volt ennek gyors kivitelezése.
A végeredmény most már egyértelmű: Ez a rendkívül a feladatra koncentráló mérnöki csapat túllépett minden egyes szintet, és olyan új felhőalapú megoldással állt elő a PC-kezelés terén, amely lehetővé tette a havi kiadási ciklus bevezetését. A frissítések nyomon követéséhez elhagytuk a hagyományos verziószámokat (pl. 2003, 2007, 2012), és helyette év/hónap szerinti elnevezést vezettünk be; az első kiadás száma így 1511 lett, mert a 2015-ös év 11. hónapjában adtuk ki.
Azóta havonta kiadjuk a ConfigMgr új Insider-verzióját, és ~4 havonta a fő Aktuális ág (CurrentBranch) kiadásokat.
Ez – kétségtelenül – az egyik leghihetetlenebb mérnöki munka, amelyben valaha is részt vettem.
Az ügyfelek reagálása erre az új felhőalapú modellre szédületes volt.
Nézze meg ezt az ábrát:
A ConfigMgr létszámának több mint a felét már frissítették az új aktuális ág modellre, és jelenleg már több mint 100 m eszközt kezelnek az új modellben, és ennyi küld vissza telemetriai adatokat.
Te jó ég, 100 m!!!!
Tudomásom szerint csak 3 nagyvállalati szolgáltatás létezik a világon, amelynek > 100 m havi aktív felhasználója vagy eszköze áll felügyelet alatt, és küld vissza telemetriai adatokat: az Office 365, az Azure Active Directory és a ConfigMgr. Mi a közös ezekben? Mind az integrált Microsoft 365-ös ajánlat részét képezik.
Ezen a diagramon látható a ConfigMgr Aktuális ág fő kiadásainak bevezetése az 1511-es kiadás óta. Egy irányítópulton vezetjük az adatokat valós időben, és ezt a diagramot minden vasárnap reggel 8:30-kor elküldjük a teljes csapatnak.
Őszintén mondom, ez a vasárnap reggeli 8:30 a hét egyik kedvenc pillanata számomra.
Ez minden idők leggyorsabb frissítése a ConfigMgr számára, és láthatja, hogy a bevezetés aránya (a vonal lejtése balról jobbra) minden kiadással egyre gyorsabb és meredekebb. Először kicsit idegesek voltunk amiatt, hogy a ConfigMgr közössége miként fog reagálni az ilyen gyors kiadásokra – de meglepődtünk, és hálásak vagyunk a bizalmukért.
Eddig még soha nem volt ekkora érdeklődés és lelkesedés a Hermes projekt iránt, mint éppen most.
Mi a következő lépés?
A felhő irányába tett lépéseink a ConfigMgr Aktuális ág modelljének 1511-es kiadásával kezdődtek 2015 novemberében, és akkor világos volt számunkra, hogy ez egy fontos lépés volt a cél felé, ahová el kellett jutnunk. Azt is tudtuk, hogy még sok munka vár ránk.
Az innováció üteme az 1511-es kiadás óta még inkább felgyorsult. A szervezetek gyorsan váltanak a mobileszközökhöz csatlakozó felhőszolgáltatások világára, és a ConfigMgr infrastruktúrája hatalmas lépéseket tett egy valódi felhőszolgáltatássá válás érdekében, hogy biztosítani tudjuk azt, amire ebben a felgyorsult környezetben szüksége van. Ez ma már egy folyamatosan új funkciókkal bővülő szolgáltatás, amely kihasználja a felhő mesterségesintelligencia-képességeit, hogy megfeleljen az igényeinek, és biztosítsa a szükséges védelmet. Felhőalapú szolgáltatásként áll a rendelkezésére, és képes eszközök százmillióit kiszolgálni szerte a világon.
Ez eszembe juttatja, amit a leggyakrabban hallok az informatikai vezetőktől: Bosszantja őket, hogy mennyire bonyolult módon tudják a csapataikkal együtt elvégezni a munkákat. A szervezetek keresik annak a módját, hogy miként egyszerűsíthetnék a telepített példányok használatát, és szeretnének egységes megoldást a felhasználók engedélyezésére az összes eszközön – amelyben a szükséges kezelés és biztonság is benne lenne. Ez az, amiért létrehoztuk a Microsoft 365-öt. A Microsoft 365 modern, biztonságos munkaterületet és integrált felhőszolgáltatásokat nyújt, amelyekkel a felhasználók még eredményesebbek lehetnek. Úgy készítettük el, hogy az IT képes legyen olyan sokoldalú és hatékony munkakörnyezetet nyújtani, amit szeretnek a felhasználók, és amelyben megbíznak az IT-üzemeltetők.
Ez az évek óta használt összes Microsoft-termék – Windows, Office, Active Directory, ConfigMgr – fejlődésének következő lépése, és a Microsoft 365-tel mindet áttelepítettük a felhőbe. A nagyvállalati ügyfelek szerte a világon áttelepülnek a felhőbe (a Windows 10-et szolgáltatásként, az Office 365-öt és az EMS-szolgáltatásokat használva). Ez a ConfigMgr architektúra következő természetes evolúciója.
Jelenleg a világon szinte minden nagyvállalat és kereskedelmi szervezet helyszíni modelleket kezd használni, ahol az Active Directoryt, csoportházirendet és a ConfigMgr eszközt használja felügyeleti eszközként. Nagy az igény egy egyszerűbb és modernebb modellre, az új modern modellre történő váltás azonban nem könnyű. A szervezetek azonban nem tudják egy csettintéssel áthelyezni a felhasználókat/eszközöket az AD/GP/ConfigMgr eszközről az AAD/Intune szolgáltatásba. Amire szükségük van, az egy híd, amely egyszerűsíti, gyorsítja és kockázatmentessé teszi a váltást. Ezzel kapcsolatban sokat tanultunk, amikor a szervezetek a helyszíni Exchange-ről az Exchange Online-ra váltottak.
A mai napon örömmel jelentem be a Megosztott kezelést, a funkciók és a híd új készletét, amely felgyorsítja a felhőbeli modern felügyeletre váltást. A Fall Creators Update segítségével a Windows 10-es eszközök egyidejűleg csatlakoztathatók az Active Directoryhoz (AD) és az Azure AD-hoz.
A Megosztott kezelés kihasználja ezt a fejlesztést, és lehetővé teszi, hogy azt eszközt úgy a ConfigMgr ügynök, mint az Intune MDM felügyelhesse. A modern felügyeletre váltás már nem egy sziklafal, ahonnan ugorni kell. A Megosztott kezelés segítségével saját utat járhat be, lépésről lépésre a felhő irányába olyan módon és ütemben, amely észszerű a szervezete számára.
Egyszerűvé tettük a ConfigMgr konzolon belüli munkát, hogy az eszközöket felügyelet alá helyezhesse, és regisztrálja az Intune szolgáltatáshoz. Ezután kiválaszthatja a felhőbe áthelyezni kívánt első feladatot – ez gyakorlatilag egy csúszka, amelyet a ConfigMgr konzoltól az Intune-hoz húzhat. Ekkor a feladat átkerül a felhőbe.
A Microsoft 365 egyedi funkcióinak egyike ebben a megosztott kezelésben a ConfigMgr és az Intune folyamatos kommunikációja. A feladatokat áthelyezve megtudjuk, hogy ki az egyes attribútumok jogosult forrása (Intune vagy ConfigMgr) a felhasználókon és eszközökön – és ezzel elkerülhető az ütköző szabályzatok alkalmazása.
Ez drámai módon felgyorsítja az áthelyezést a Windows 10-be és a modern felügyeletet a felhőből.
* * * * *
A blog megírása hihetetlen nosztalgikus élmény volt számomra. Az SMS/ConfigMgr/Intune nagy hatással volt az életemre, a családom életére, a projekten dolgozó mérnökök ezreinek életére és az IT-üzemeltetők életére, akik használták és napjainkban is használják ezeket. Szeretem ezt a terméket és szeretem ezt a közösséget.
Örültem annak is, hogy ma láthattam a ConfigMgr előzményeiről szóló dokumentumfilmet – de ez csak az 1. rész. És a 2. rész még fontosabb. Mert a 2. részt Ön fogja készíteni.
Ha az Ignite konferencián van, álljon meg a Microsoft standjának felügyeleti és biztonsági részén, és mondja el a történetét. Ehhez itt talál útmutatást.
Ha nincs jelen az Ignite konferencián, akkor is egyszerű a részvétel. A ConfigMgr konzollal kapcsolatos emlékeit és történeteit itt feltöltve aka.ms/ConfigMgr25 mesélje el a történetét. Itt talál néhány fontos utasítást.
Ezekből a beküldött dokumentumokból hozzuk létre a 2. részt – egy videót, amelynek a következő nevet szeretnénk adni:
„A ConfigMgr felhasználóinak története”
Alig várom, hogy láthassam.
_______________________________________________
