25 lat programu ConfigMgr
Pod koniec zeszłego tygodnia pisałem o wyjątkowym jubileuszu ćwierćwiecza programu ConfigMgr, a dzisiaj postanowiłem zagłębić się w historię tego niezwykłego produktu, opublikować kilka ogłoszeń i po raz pierwszy pokazać niesamowity nowy film dokumentalny (strzeż się Sundance!) szczegółowo omawiający genezę i rozwój produktu, dzięki któremu powstała branża zarządzania komputerami.
A oto ogłoszenie dotyczące programu ConfigMgr:
Z okazji dzisiejszego jubileuszu przedstawiam historię, której być może jeszcze nie słyszeliście:
Jak to się wszystko zaczęło
Pod koniec ubiegłego tygodnia miałem okazję ponownie przeczytać oryginalny dokument zawierający wizję czy też „specyfikację” Projektu Hermes. Nie widziałem tego dokumentu przez kilka lat. To było niesamowite — zobaczyć, jak bardzo blisko oryginalnej wizji pozostał program ConfigMgr. Podstawowe elementy konstrukcyjne nakreślone w tym dokumencie są nadal w użyciu i wciąż stanowią fundament programu.
W 1992 r. pierwotna misja firmy Microsoft (komputer w każdym domu i na każdym biurku) właśnie osiągnęła masę krytyczną. Organizacje gremialnie przechodziły z emulacji terminali na model przetwarzania rozproszonego x86, ale nie istniało rozwiązanie umożliwiające zarządzanie komputerami w takiej skali. Zespół wiedział, że Projekt Hermes ma ogromne znaczenie.
Pierwotny zespół SMS składał się z dwóch programistów zatrudnionych na pełen etat i stażysty o nazwisku Ken Pan. Gdy dołączyłem do zespołu w 2003 r., stażysta Ken był już szefem całego zespołu złożonego z około 150 inżynierów. Ken kierował pracami inżynierów nad programem SCCM i usługą Intune odkąd pamiętam!
Ciekawostka: Pierwsza kompilacja programu Systems Management Server (SMS) nosiła numer 245. Dlaczego nie 1? Cóż… System Windows w tamtym czasie miał numer kompilacji 300, a zespół nie chciał, aby wydawało się, że jest tak daleko w tyle — członkowie zespołu wiedzieli jednak, że wybranie czegoś zbyt blisko 300 może wzbudzić podejrzenia. Dlatego wybrali 245!
Program SMS został oficjalnie wydany 7 listopada 1994 r. Przygotowanie pierwszej wersji trwało nieco ponad dwa lata — dzisiaj publikujemy nowe kompilacje dla niejawnych testerów co miesiąc!
Ważnym wydarzeniem od czasu tego wydania był e-mail wysłany przez Billa Gatesa do każdego pracownika firmy Microsoft, w którym wyjaśniał, że program SMS jest wdrażany w całej firmie. Bill, będący dawniej inżynierem, pokazywał również w tej wiadomości, jak usunąć oprogramowanie SMS z komputera, gdyby ktoś go nie chciał. (:
Jeśli chcecie przeczytać ten e-mail, znajdziecie go na końcu tego wpisu.
Rozwijanie architektury
Kolejne wersje programu SMS — 1.0, 1.1 i 1.2 — były wydawane dość szybko, co przyczyniło się do powstania nowego rynku. Zespół niezwłocznie przystąpił do pracy nad wersją SMS 2.0.
Wtedy wszystko się… skomplikowało.
I szczerze mówiąc, podjęliśmy kilka złych decyzji. Ważnym elementem mentalności wzrostu jest umiejętność szybkiego uczenia się — od samego początku była to podstawa zespołu SMS.
Od 1992 r. architektura sposobu tworzenia aplikacji klient-serwer zmieniła się tak bardzo, że w latach 1997–1998 zespół napisał infrastrukturę serwera SMS praktycznie od nowa, aby zwiększyć skalę i wydajność oprogramowania SMS, a także zintegrował program z przyszłymi możliwościami systemu Windows Server 2000. Wtedy po raz pierwszy architektura programu SMS została napisana od nowa, dzięki czemu mogła zapewnić obsługę najnowocześniejszych w owym czasie rozwiązań.
Oprogramowanie SMS 2.0 zostało wydane w styczniu 1999 r., a wdrażanie i użytkowanie przyspieszyło. Pracowałem wtedy u największego konkurenta oprogramowania SMS — w firmie Novell, kierując zespołem Novell ZENworks. Spędziłem niezliczone godziny na spotkaniach z klientami SMS, opowiadając o cechach wyróżniających oprogramowanie ZENworks, których istotą było skoncentrowanie się na użytkownikach (tożsamościach) i głęboka integracja z katalogiem!
Tworząc ten wpis, przypomniałem sobie, że w programie SMS 2.0 znajdowała się ukryta niespodzianka. Tą niespodzianką był film wideo z nazwiskami i zdjęciami osób pracujących nad produktem. Kiedy ponownie obejrzałem go w tym tygodniu, wyróżniało się jedno nazwisko:
Tak, Terry Myerson — mój szef i wiceprezes wykonawczy w firmie Microsoft. Myślę, że tak naprawdę wszyscy wielcy w jakimś momencie swojej kariery przeszli przez program SMS. (:
Ja dołączyłem do zespołu SMS, gdy zaczęły się prace nad wersją SMS 2003.
W programie SMS 2003 po raz kolejny duże fragmenty kodu zostały napisane od nowa. Dużym kamieniem milowym w tamtym czasie było dostosowanie programu SMS do poprawek WSUS. Umożliwiło to wprowadzanie poprawek firmy Microsoft z chmury (Windows Update) u klientów i w przedsiębiorstwie. WSUS to zasadniczo to samo oprogramowanie, które jest używane w usłudze Windows Update — jedynym wyjątkiem jest uruchamianie go w lokalnym centrum danych.
Windows Update jest jedną z największych na świecie usług w chmurze — każdego miesiąca aktualizuje ponad miliard urządzeń. Pomyślcie o tym przez chwilę: Jednym z kluczowych czynników wyróżniających firmę Microsoft w dzisiejszej chmurze publicznej są nasze możliwości hybrydowe i możliwość uruchamiania chmury publicznej we własnym centrum danych użytkownika. Uruchomienie usługi Windows Update w centrum danych użytkownika (WSUS) było naprawdę wydarzeniem pionierskim i być może najwcześniejszym przykładem połączenia z chmurą i rozwiązania hybrydowego. Był to także moment, w którym coraz więcej osób zaczęło korzystać z laptopów, dlatego musieliśmy stworzyć nowego klienta, który działałby w modelu bez połączenia lub z luźnym połączeniem.
Kiedy zbliżał się czas wydania programu SMS 2003, spotykaliśmy się w każdy piątek rano z grupą pracowników z całej firmy, aby ocenić stan projektu. Jedną z najważniejszych grup zapraszanych na te spotkania był dział IT firmy Microsoft (MSIT). Zrobiłem coś, co nie miało precedensu w firmie — przyznałem zespołowi IT prawo weta wobec decyzji o opublikowaniu programu SMS 2003, gdyby miał poczucie, że oprogramowanie nie jest jeszcze gotowe. Od tego czasu MSIT jest naszym pierwszym i najlepszym klientem, a także jednym z najlepszych źródeł informacji zwrotnej o wczesnych kompilacjach.
Dzisiaj w firmie Microsoft zarządzamy ponad 500 000 komputerów i urządzeń przenośnych (ta liczba nie wlicza się do 100 mln urządzeń korzystających z usługi MAD) za pomocą pojedynczego wdrożenia programu ConfigMgr. Stale wdrażamy nowy kod w firmie Microsoft, tworząc comiesięczne wersje. Zdecydowanie sami używamy własnego produktu. Kolejna ciekawostka: Mój zespół właściwie nadzoruje wewnętrzne wdrożenie programu ConfigMgr. Nie ma lepszej metody nauki niż uczenie w działaniu!
W latach 2003–2007 wydaliśmy dwa pakiety „Feature Pack”. Nie chcieliśmy czekać na zupełnie nowy produkt, aby dostarczyć nowe funkcje, dlatego wprowadziliśmy nowy sposób udostępniania nowych funkcji. Pierwszy pakiet Feature Pack zakończył prace nad dostosowaniem naszych poprawek do usługi WSUS. Drugi pakiet Feature Pack pojawił się, gdy wprowadziliśmy funkcję wdrażania systemów operacyjnych.
Jednym z moich ulubionych wspomnień z tego okresu jest pokaz, który zorganizowaliśmy w listopadzie 2003 r. na imprezie w Europie. Zaprezentowaliśmy na nim nowe możliwości wdrażania systemów operacyjnych. Bill Gates wygłaszał przemówienie, a w czasie, gdy mówił o nowościach w programie SMS, na ścianie za nim pokazaliśmy na żywo uaktualnienie 100 komputerów. Nazwaliśmy ten pokaz „ścianą ognia”.
Oto zdjęcie, które zrobiliśmy Billowi, gdy odwrócił się, aby obejrzeć nasz pokaz:
A to zdjęcie dzielnych członków zespołu SMS, którzy przeprowadzili ten pokaz:
Wywieranie wpływu
Jesienią 2004 r. Bill i Steve zorganizowali spotkanie poza siedzibą firmy ze starszą kadrą kierowniczą. Na koniec dnia odbyła się otwarta sesja pytań i odpowiedzi z udziałem Billa i Steve’a. Ktoś zapytał Billa o to, co jego zdaniem było najważniejszą rzeczą, jaka wydarzyła się w firmie Microsoft w zeszłym roku. Bill odpowiedział: „Mamy znakomite produkty SMS i Active Directory, które będą naszym ogromnym atutem.”
Do dziś jest to jeden z najpiękniejszych dni w mojej karierze!
W 2007 r. zmieniliśmy nazwę z „SMS” na „ConfigMgr”, aby dostosować ją do marki System Center. Najnowszym innowacyjnym scenariuszem, o który prosili klienci, była konfiguracja żądanego stanu (Desired State Configuration, DSC), dlatego kolejny raz rozwinęliśmy architekturę, aby rzeczywiście umożliwić działanie DSC w odpowiedni sposób. Całkowicie od nowa napisaliśmy też środowisko administracyjne.
W lutym 2011 r., w środku prac nad programem SCCM 2012, Satya przejął dział serwerów i narzędzi (Server and Tools Business, STB), zmienił jego nazwę na dział chmury i przedsiębiorstw (Cloud and Enterprise, C + E) i został moim szefem. Na nasze pierwsze spotkanie twarzą w twarz Satya przyszedł do mojego biura i spędził większość czasu, tak naprawdę poznając mnie lepiej jako osobę. Kilkuletnia praca pod bezpośrednim kierownictwem Satyi oraz możliwość wyciągania nauki z jego niewiarygodnie dociekliwej natury, mentalności rozwoju oraz skromności i służebności w kierowaniu ludźmi były dla mnie niesamowitym doświadczeniem. Satya miał ogromny wpływ na przyszłość i architekturę tej wersji programu ConfigMgr.
W programie ConfigMgr 2012 zasadniczo postawiliśmy architekturę na głowie, koncentrując architekturę i środowisko na użytkownikach, a nie tylko na urządzeniach.
Klienci mówili nam, że kluczową sprawą w przyszłości będzie mobilność, a my rozumieliśmy, że chodzi o mobilność ludzi, a nie tylko urządzeń. W odpowiedzi na te informacje drastycznie spłaszczyliśmy architekturę, aby wymagała mniejszej ilości sprzętu, i znacznie zwiększyliśmy limity skali. Właśnie wtedy naprawdę na poważnie zaczęliśmy naszą podróż do chmury. Połączyliśmy program ConfigMgr z usługą Microsoft Intune, a usługa Intune zasadniczo stała się rozwiązaniem brzegowym programu ConfigMgr.
Ta hybrydowa konfiguracja stała się modelem, który umożliwił nam wprowadzanie innowacji w chmurze, a następnie dostarczanie nowej wartości do programu ConfigMgr w środowisku lokalnym za pośrednictwem tego wdrożenia hybrydowego. Wierzyliśmy, że chmura umożliwi realizację scenariuszy, które nie byłyby możliwe w przeszłości, a Satya dostrzegł potencjalny wpływ chmury na zarządzanie urządzeniami i naprawdę zmusił nas do innowacji i eksperymentowania w tej dziedzinie.
Program ConfigMgr przechodzi do chmury
Kolejna ewolucja architektury była zdecydowanie najtrudniejsza.
Kiedy dowiedzieliśmy się, że system Windows 10 będzie dostarczany jako usługa z licznymi aktualizacjami w ciągu roku, wiedzieliśmy, że program ConfigMgr musi pójść za jego przykładem i przejść do chmury.
Wyzwanie było niezwykle trudne.
W przeszłości kolejne wersje programu ConfigMgr były publikowane raz na 2–3 lata. Pamiętam, jak patrzyłem na pierwszy kompletny plan programu SCCM 2007 i widziałem 16 miesięcy stabilizacji oraz wersji beta między deklarowanym terminem gotowości kodu a terminem wydania programu. 16 miesięcy! Było jasne, że musimy zmienić model programu ConfigMgr na SaaS (oprogramowanie jako usługa), abyśmy mogli publikować wiele wersji w ciągu roku.
Mając przed sobą tak trudne zadanie, zaczęliśmy od wybrania małego zespołu inżynierów i menedżerów programów, którzy dobrze znali program ConfigMgr, mieli mentalność rozwoju i podzielali pasję do tej bazy klientów. Wierzyliśmy, że jedynym sposobem, w jaki możemy to zrobić, jest mały i wyspecjalizowany zespół, który dokona przeglądu całej architektury i od zera stworzy usługę dostarczaną w chmurze.
Kiedy przyjrzałem się harmonogramowi tego przeglądu, muszą przyznać, że w moim zwykłym optymizmie, którego mi nie brakuje, pojawiła się domieszka sceptycyzmu. Wykonanie planu w tym tempie było niewiarygodnym przedsięwzięciem.
Teraz rezultat jest oczywisty: Zespół profesjonalnych inżynierów stworzył produkt wygrywający we wszystkich testach i dostarczył nową, opartą na chmurze metodę zarządzania komputerami, co pozwoliło nam przejść do miesięcznego cyklu wydawniczego. Aby śledzić te aktualizacje, pozbyliśmy się tradycyjnych numerów wersji (np. 2003, 2007, 2012), a zamiast tego zaczęliśmy nadawać im nazwy w konwencji rok/miesiąc. Pierwsza wersja nosiła więc numer 1511, ponieważ została opublikowana w 11-tym miesiącu 2015 r.
Od tego czasu co miesiąc wydawaliśmy nową wersję programu ConfigMgr dla niejawnych testerów, a mniej więcej co 4 miesiące — główne wersje CurrentBranch.
Jest to bez wątpienia jeden z najbardziej niewiarygodnych projektów inżynieryjnych, w których kiedykolwiek brałem udział.
Reakcja klientów na ten nowy model dostarczany w chmurze była niesamowita.
Spójrzcie na ten wykres:
Nieco ponad połowa bazy programu ConfigMgr została już uaktualniona do nowego modelu bieżącej gałęzi i obecnie ponad 100 mln urządzeń jest aktywnie zarządzanych i wysyła dane telemetryczne.
A niech mnie — 100 milionów!!!
O ile mi wiadomo, na świecie istnieją tylko 3 usługi dla przedsiębiorstw, które mają miesięcznie więcej niż 100 mln aktywnych użytkowników lub zarządzanych urządzeń wysyłających dane telemetryczne: Office 365, Azure Active Directory i ConfigMgr. Co łączy te trzy produkty? Wszystkie są częścią zintegrowanej oferty Microsoft 365.
Ten wykres pokazuje wdrażanie głównych wersji programu ConfigMgr Current Branch od numeru 1511. Dysponujemy pulpitem nawigacyjnym, który pokazuje nam te dane w czasie rzeczywistym, i wysyłamy ten wykres do całego naszego zespołu w każdy niedzielny poranek o 8:30.
Uwierzcie, że 8:30 rano w niedzielę to jeden z moich ulubionych momentów w tygodniu.
Było to najszybsze w historii uaktualnienie programu ConfigMgr. Możecie zobaczyć, że z każdą wersją szybkość wdrażania (nachylenie linii od lewej do prawej) jest coraz większa, a linia jest coraz bardziej stroma. Początkowo trochę martwiliśmy się, jak społeczność użytkowników programu ConfigMgr zareaguje na tak szybkie wydania, ale byliśmy zarówno zdumieni, jak i wdzięczni za zaufanie i wiarę w nasze możliwości.
Projekt Hermes nigdy nie cieszył się większym zainteresowaniem i pasją niż obecnie.
Co dalej
Wraz z wersją 1511 programu ConfigMgr Current Branch w listopadzie 2015 r. rozpoczęliśmy podróż do chmury. Już wtedy było dla nas jasne, że jest to duży krok w stronę celu, do którego zdążamy. Równie oczywiste było dla nas, że jest jeszcze dużo do zrobienia.
Tempo wprowadzania innowacji od wersji 1511 tylko przyspieszyło. Organizacje szybko przenoszą się do świata usług w chmurze połączonych z urządzeniami przenośnymi, a infrastruktura programu ConfigMgr dokonała ogromnego postępu, aby mógł on stać się prawdziwą usługą w chmurze i abyśmy mogli dostarczać to, czego potrzebujecie w tym coraz szybciej rozwijającym się środowisku. Teraz jest to usługa stale rozszerzana o nowe funkcje, która dzięki wykorzystaniu funkcji sztucznej inteligencji chmury dostosowuje się do potrzeb użytkowników i zapewnia wymaganą ochronę oraz jest dostępna jako usługa w chmurze, co oznacza możliwość skalowania do setek milionów urządzeń na całym świecie.
Wszystko to przypomina mi o największym problemie, o jakim często mówią liderzy rynku IT na całym świecie: są oni sfrustrowani stopniem skomplikowania produktów, z których wraz ze swoimi zespołami muszą korzystać w pracy. Organizacje szukają sposobów na uproszczenie wdrożonych rozwiązań i potrzebują na wszystkich urządzeniach ujednoliconego środowiska użytkownika, które zapewni również wymagane przez nich funkcje zarządzania i bezpieczeństwa. Dlatego stworzyliśmy rozwiązanie Microsoft 365. M365 oferuje nowoczesny, bezpieczny obszar roboczy oraz zintegrowane usługi w chmurze, które pozwalają użytkownikom osiągnąć więcej. To rozwiązanie zostało zaprojektowane tak, aby pracownicy działu IT mogli zapewnić zaawansowane i dające większe możliwości środowisko pracy, które będzie lubiane przez użytkowników i będzie cieszyło się zaufaniem działu IT.
Jest to kolejna ewolucja wszystkich produktów firmy Microsoft, których używacie od lat: Windows, Office, Active Directory, ConfigMgr. W ramach rozwiązania Microsoft 365 przenieśliśmy je wszystkie do chmury. Klienci korporacyjni na całym świecie migrują do chmury (używając usług Windows 10 as-a-Service, Office 365 i EMS) — jest to kolejna naturalna ewolucja architektury programu ConfigMgr.
Prawie każde przedsiębiorstwo i każda organizacja komercyjna na świecie zaczyna obecnie od modelu lokalnego, w którym jako narzędzi do zarządzania używa usługi Active Directory, zasad grupy i programu ConfigMgr. Pragnienie przejścia na prostszy i nowocześniejszy model jest duże, ale osiągnięcie tego nowego modelu nie było łatwe. Organizacja nie może po prostu pstryknąć palcami i przenieść użytkowników/urządzeń z modelu AD/GP/ConfigMgr do modelu AAD/Intune. Potrzebowaliście od nas pomostu, dzięki któremu ten ruch byłby prostszy, szybszy i pozbawiony ryzyka. Jest to obszar, w którym wiele się nauczyliśmy, obserwując przechodzenie organizacji z programu Exchange do usługi Exchange Online.
Dziś z przyjemnością ogłaszamy współzarządzanie, nowy zestaw funkcji i pomost, który ułatwi przyspieszenie przejścia do nowoczesnego zarządzania z chmury. Dzięki aktualizacji Fall Creators Update urządzenie z systemem Windows 10 może zostać dołączone jednocześnie do lokalnej usługi Active Directory (AD) i do usługi Azure AD.
Współzarządzanie korzysta z tego ulepszenia i umożliwia zarządzanie urządzeniem zarówno przy użyciu agenta programu ConfigMgr, jak i usługi Intune MDM. Przejście do nowoczesnego zarządzania nie jest już jak skok w przepaść. Dzięki współzarządzaniu można wyruszyć w samodzielną podróż, krok po kroku, do chmury w taki sposób i w takim tempie, które odpowiadają danej organizacji.
Uprościliśmy pracę w konsoli programu ConfigMgr, aby umożliwić zarządzanie urządzeniami i rejestrować je w celu zarządzania w usłudze Intune. Następnie można wybrać pierwsze obciążenie, które ma zostać przeniesione do chmury (jest to dosłownie pasek suwaka, który trzeba przesunąć od programu ConfigMgr do usługi Intune). Obciążenie zostanie przeniesione do chmury.
Jedną z unikatowych możliwości platformy Microsoft 365 w tym współzarządzanym scenariuszu jest to, że program ConfigMgr i usługa Intune są w stałej komunikacji. Podczas przenoszenia obciążeń rozumiemy, co jest autorytatywnym źródłem (usługa Intune czy program ConfigMgr) dla każdego atrybutu użytkowników i urządzeń, co pozwala uniknąć stosowania zasad powodujących konflikty.
Znacznie przyspiesza to przechodzenie na system Windows 10 i nowoczesne zarządzanie z poziomu chmury.
* * * * *
Pisanie tego tekstu było dla mnie niesamowitą podróżą po zakamarkach pamięci. Produkty SMS/ConfigMgr/Intune wywarły ogromny wpływ na życie moje, mojej rodziny, tysięcy inżynierów, którzy pracowali nad projektami, oraz milionów specjalistów IT, którzy używali i nadal używają tych produktów. Uwielbiam ten produkt i kocham tę społeczność.
Z przyjemnością obejrzałem także dzisiejszy film dokumentalny o historii programu ConfigMgr, ale to dopiero pierwsza część. Druga część jest dużo ważniejsza. To dlatego, że drugą część stworzycie Wy.
Będąc na konferencji Ignite, wpadnijcie do sekcji zarządzania i zabezpieczeń na stoisku firmy Microsoft, aby opowiedzieć nam o Waszych doświadczeniach. Tutaj znajdziecie proste wskazówki, jak dotrzeć.
Jeśli nie jesteście uczestnikami konferencji Ignite, wciąż z łatwością możecie wziąć w tym udział. Opowiedzcie o swoich doświadczeniach, przekazując wspomnienia i historie związane z programem ConfigMgr tutaj aka.ms/ConfigMgr25. Oto kilka podstawowych instrukcji.
Wykorzystamy te opowieści do stworzenia drugiej części filmu, którą chcielibyśmy zatytułować:
„Opowieści o programie ConfigMgr”
Nie mogę się doczekać, aby ją obejrzeć.
_______________________________________________
