ConfigMgr erreicht Vierteljahrhundert-Marke

Ende letzter Woche schrieb ich in einem Artikel, dass ConfigMgr die legendäre Vierteljahrhundert-Marke erreicht hat. Heute möchte ich die Entstehung dieses unnachahmlichen Produkts beleuchten, einige Neuheiten ankündigen und eine neue Dokumentarreihe (Sundance, ich komme!) starten, die detaillierte Einblicke in den Ursprung und die Evolution dieses Pioniers unter den PC-Verwaltungslösungen bietet.

ConfigMgr in Zahlen:

Lassen Sie diese Zahl auf sich wirken, und lesen Sie nun meine Geschichte, die viele überraschende Fakten bereithält:

Wie alles begann

Ende letzter Woche nahm ich mir Zeit, unsere ursprüngliche Vision bzw. Eckdaten zu Project Hermes noch einmal durchzulesen. Ich hatte dieses Dokument seit Jahren nicht mehr vor Augen und war überrascht, wie nahe wir mit ConfigMgr bei der ursprünglichen Vision geblieben waren. Die Grundideen dieses Dokuments haben auch heute noch Gültigkeit und bilden teilweise immer noch das Fundament für ConfigMgr.

Im Jahr 1992 erreichten wir mit unserer damaligen Mission (ein PC in jedem Haushalt und auf jedem Schreibtisch) gerade die kritische Masse. Unternehmen stiegen in Scharen von der Terminalemulation auf das verteilte x86-Computingmodell um, und eine Lösung für die Massenverwaltung von PCs war noch nicht in Sicht. Das Project Hermes-Team wusste, dass es einen Erfolgstreffer landen musste.

Dem SMS-Team gehörten ursprünglich zwei Vollzeitentwickler und ein interner Mitarbeiter namens Ken Pan an.  Als ich 2003 zum Team stieß, führte Ken the Intern bereits ein Team von 150 Entwicklern. Ich persönlich kenne nur Ken als Entwicklungschef von SCCM und Intune!

Nebenbei bemerkt:  Der erste Build von Systems Management Server (SMS) hatte die Nummer 245. Warum nicht 1? Nun…Windows war zu dieser Zeit bereits bei Build 300 angelangt, und das Team wollte nicht zu weit hinterherhinken. Immerhin bemerkte man, dass eine Zahl um 300 herum zu großes Stirnrunzeln hervorgerufen hätte. Deshalb fiel die Entscheidung auf die Nummer 245!

SMS wurde am 7. November 1994 offiziell gestartet. Die Entwicklung des ersten Release dauerte etwas über zwei Jahre – heute veröffentlichen wir jeden Monat! neue Insider-Builds.

Ein großer Moment dieser Produkteinführung war eine E-Mail, in der Bill Gates jedem Microsoft-Mitarbeiter persönlich mitteilte, dass SMS unternehmensweit ausgerollt wird. Ganz der Entwickler, wies Bill in seiner E-Mail darauf hin, wie Nutzer die SMS-Software bei Bedarf entfernen können. (:

Die E-Mail im Original-Wortlaut habe ich am Ende dieses Artikels angefügt.

Der Weg zu einer zukunftsweisenden Architektur

SMS 1.0, 1.1 und 1.2 wurden relativ zügig freigegeben und legten den Grundstein für einen neuen Markt. Sofort danach ging es mit der Entwicklung von SMS 2.0 weiter –

und da fingen die Schwierigkeiten an.

Zugegeben, mit manchen Entscheidungen haben wir etwas daneben gelegen. Doch wachstumsorientiertes Denken hängt auch von schneller Lernfähigkeit ab, und die hat das SMS-Team von Anfang an unter Beweis gestellt.

Nach 1992 wurde die Architektur von Client-Server-Anwendungen derart revolutioniert, dass das Team die SMS-Serverinfrastruktur 1997 und 1998 praktisch von Grund auf umstrukturiert hat, um die Skalierung und Leistung von SMS voranzubringen – und um zukünftige Funktionen von Windows Server 2000 einzubinden. Zu der Zeit hatten wir erstmalig den Anspruch, mit der SMS-Architektur den damaligen Stand der Technik zu prägen.

SMS 2.0 kam im Januar 1999 auf den Markt, und Akzeptanz und Nutzung des Produkts nahmen Fahrt auf. Damals leitete ich bei Novell das ZENworks-Team, das ein ernstzunehmendes Konkurrenzprodukt zu SMS entwickelte. Ich kann gar nicht zählen, wie viele Stunden ich mit SMS-Kunden über die Unterschiede zu ZENworks debattiert habe, das auf Benutzern (Identitäten) und der tief greifenden Verzahnung mit einem Verzeichnisdienst aufbaute!

Während ich diesen Artikel schreibe, fällt mir ein, dass SMS 2.0 ein Überraschungsei für mich bereithielt, und zwar in Form eines Videos, in dem die Namen und Fotos der Teammitglieder gezeigt wurden. Als ich diese Woche noch einmal hineinschaute, fiel mir ein Name sofort ins Auge:

Yup, Terry Myerson – mein Chef und Executive Vice President bei Microsoft. Sieht so aus, als hätten alle klugen Köpfe an irgendeinem Punkt in ihrer Karriere beim SMS-Team angeheuert.  (:

Ich stieß zum SMS-Team, als die Vorbereitungen für SMS 2003 unter Hochdruck liefen.

Für SMS 2003 wurden ebenfalls große Teile des Produktcodes umgeschrieben. Ein großer Meilenstein zu dieser Zeit war die Ausrichtung von SMS auf WSUS zum Zweck der Patchverwaltung. Damit brachte Microsoft die Patchverteilung zwischen Cloud (Windows Update), Endkunden und Unternehmen auf Vordermann. WSUS ist im Prinzip ähnlich aufgebaut wie Windows Update, mit der Ausnahme, dass die Software im Rechenzentrum der Kunden ausgeführt wird.

Windows Update ist einer der weltgrößten Cloud Services, der jeden Monat mehr als 1 Mrd. Geräte mit Updates versorgt. Kurzer Einschub zwischendurch:  Eines der Alleinstellungsmerkmale von Microsoft in der Public Cloud sind unsere Hybridfunktionen und die Möglichkeit, unsere Public Cloud im Rechenzentrum des Kunden auszuführen. Die Einbindung von Windows Update in das Kundenrechenzentrum (WSUS) war wirklich eine Pioniertat und vielleicht das erste Beispiel für eine Hybridlösung mit Anbindung an die Cloud. Zeitgleich stieg auch die Nutzung von Laptops explosionsartig an, sodass wir einen neuen Client benötigten, der sowohl eigenständig als auch gekoppelt ausgeführt werden konnte.

Auf der Zielgeraden zum Release von SMS 2003 kam jeden Freitagmorgen eine Gruppe aus unternehmensweiten Vertretern zusammen, um den Projektstatus zu besprechen. Eine der wichtigsten beteiligten Gruppen war die Microsoft IT-Abteilung (MSIT). In einem bis dato einmaligen Präzedenzfall erteilte ich dem IT-Team Vetorecht für die Auslieferung von SMS 2003, falls irgendein Detail noch nicht 100-prozentig stimmen sollte. Seitdem ist das MSIT-Team unser erster und bester Kunde sowie eine unserer besten Quellen für Feedback zu frühen Builds.

Heute verwalten wir bei Microsoft in einer einzigen ConfigMgr-Implementierung mühelos mehr als 500.000 PCs und Mobilgeräte (und diese Zahl ist in den 100 Mio. Geräten nicht einmal berücksichtigt). Mit jedem monatlichen Release rollen wir auch bei Microsoft neue Funktionen aus. Wir nutzen also intern unsere eigenen Produkte. Noch ein interessantes Detail:  Mein Team überwacht selbst die interne Bereitstellung von ConfigMgr. Und wie man weiß, ist „Learning by Doing“ immer noch der schnellste Weg zum Erfolg!

Zwischen 2003 und 2007 veröffentlichten wir zwei „Feature Packs“. Um neue Funktionen nicht erst mit einem Folgeprodukt bereitzustellen, entwickelten wir diese innovative Verteilungsmethode. Gleich mit dem ersten Feature Pack erübrigte sich die Patchabstimmung unter WSUS, und mit dem zweiten Feature Pack waren wir schon beim Thema Betriebssystembereitstellung angelangt.

Eine meiner schönsten Erinnerungen an diese Zeit ist eine Demo, die wir für ein Event in Europa im November 2003 vorbereitet hatten, um die neue Art der Betriebssystembereitstellung zu präsentieren. Bill Gates hielt den Keynote-Vortrag, und während er über die Neuerungen bei SMS redete, wurde auf einer Leinwand hinter ihm ein Live-Upgrade für 100 PCs durchgeführt. Diese Demo ging als „Wall of Fire“ in unsere Firmengeschichte ein.

Hier ein Foto von Bill, wie er sich umdreht und der Demo zuschaut:

Und hier ein Foto der findigen SMS-Teammitglieder, die die Demo auf die Beine gestellt haben:

SMS – eine Innovation für die Zukunft

Im Herbst 2004 luden Bill und Steve einige Führungskräfte aus dem Unternehmen zu einem inoffiziellen Treffen ein und beendeten den Tag mit einer offenen Frage-und-Antwort-Runde.  Danach gefragt, was wohl die spannendste Entwicklung von Microsoft aus dem letzten Jahr sei, antwortete Bill: „Wir haben SMS und Active Directory den letzten Schliff gegeben und damit die Signale auf Richtung Zukunft gestellt.“

Dieser Moment war für mich einer der besten in meiner beruflichen Laufbahn!

Im Jahr 2007 änderten wir den Namen von „SMS“ in „ConfigMgr“, um ihn an das System Center-Branding anzupassen. Damals war Desired State Configuration (DSC) die neueste Innovation und ein heißer Favorit unserer Kunden, sodass wir die Architektur einmal mehr weiterentwickelten, um die besten Voraussetzungen für DSC zu schaffen. Auch die Administratoroberfläche wurde komplett umgestaltet.

Im Februar 2011, also mitten in der Entwicklung von SCCM 2012, übernahm Satya das STB (Server and Tools Business)-Segment und benannte es in C+E (Cloud and Enterprise) um. So wurde Satya mein neuer Chef. Das erste Mal traf ich Satya, als er in mein Büro kam und sich alle Zeit der Welt nahm, um mich persönlich kennenzulernen. Die Jahre, in denen ich direkt für Satya gearbeitet habe, waren eine unbeschreibliche Erfahrung. Mit seiner unvergleichlichen, wissbegierigen Art, seinem aufgeschlossenen Denken und seinem bescheidenen Führungsstil ist er ein großes Vorbild. Bei der Vorbereitung des nächsten Release hat Satya die Zukunft und die Architektur von ConfigMgr enorm beeinflusst.

In ConfigMgr 2012 stellten wir das Produkt komplett auf den Kopf, indem wir die Architektur und Erfahrung nutzerorientiert statt geräteorientiert ausrichteten.

Unsere Kunden wollten in eine mobile Zukunft starten und uns war klar, dass der Mensch im Mittelpunkt stehen muss und nicht nur die von ihm genutzten Geräte.  Als Antwort darauf haben wir die Architektur drastisch vereinfacht, sodass sie mit weniger Hardware auskommt, und die Skalierungsmöglichkeiten massiv ausgeweitet. An dieser Stelle nahm unsere Reise in die Cloud richtig an Fahrt auf. Wir brachten ConfigMgr und Microsoft Intune zusammen, woraufhin Intune zur Co-Anwendung von ConfigMgr wurde.

Die Hybridkonfiguration wurde unser Innovationssprungbrett in die Cloud und ermöglichte uns, dem lokalen ConfigMgr über die Hybridbereitstellung neues Leben einzuhauchen. Von der Cloud erwarteten wir uns Fortschritte, die in der Vergangenheit nicht möglich gewesen wären. Satya erkannte das Potenzial der Cloud für die Geräteverwaltung und hat uns dazu gebracht, innovativ zu denken und zu experimentieren.

Die Zukunft von ConfigMgr in der Cloud

Die nächste Weiterentwicklung der Architektur war mit Abstand am schwierigsten.

Als wir hörten, dass Windows 10 als „as-a-service“-Modell mit jährlich mehreren Updates bereitgestellt wird, war klar, dass wir nachziehen und auch ConfigMgr in die Cloud migrieren müssen.

Die Herausforderung war gewaltig,

da ConfigMgr bisher in Intervallen von zwei bis drei Jahren aktualisiert wurde. Ich weiß noch, wie ich den ersten Rolloutplan für SCCM 2007 in die Hände bekam, wo zwischen Ende der Programmierung und Release ganze 16 Monate für Stabilisierung und Betatests vorgesehen waren. 16 Monate!   Es gab also keine Alternative zur „SaaS-fizierung“ von ConfigMgr, um mehrere Releasezyklen pro Jahr zu gewährleisten.

Angesichts dieser gewaltigen Aufgabe stellten wir ein handverlesenes kleines Team von Entwicklern und Programm-Managern zusammen, die ConfigMgr in und auswendig kannten und eine wachstumsorientierte Denkweise sowie Leidenschaft für die Zielgruppe mitbrachten.  Allein unsere Überzeugung spornte uns an, die gesamte Architektur mit einem kleinen und fokussierten Team zu überarbeiten und von Grund auf als Clouddienst zu konzipieren.

Doch als mir dann der Zeitplan für die Umstellung vorlag, schwankte ich ehrlicherweise zwischen Skepsis und dem mir eigenen sprühenden Optimismus. Die Einhaltung einer derart kurzen Frist war wirklich eine Riesenaufgabe.

Das Ergebnis kennt inzwischen jeder:  Das hochkonzentrierte Entwicklerteam stellte jeden einzelnen Benchmark in den Schatten und realisierte eine cloudbasierte PC-Verwaltungslösung, die uns den Umstieg auf einen monatlichen Releasezyklus ermöglichte. Um Updates voneinander zu unterscheiden, schafften wir die herkömmlichen Versionsnummern (z. B. 2003, 2007, 2012) ab und starteten mit einem aus Jahr/Monat bestehenden Namenssystem. Demnach hatte das erste Release die Versionsnummer 1511, weil es im 11. Monat des Jahres 2015 veröffentlicht wurde.

Seitdem haben wir jeden Monat eine neue Insider-Version von ConfigMgr und etwa alle vier Monate Hauptversionen im CurrentBranch veröffentlicht.

Dies ist ohne Frage eines der großartigsten Entwicklerprojekte, an denen ich jemals beteiligt war.

Die Resonanz der Kunden auf dieses neue Cloudmodell war überwältigend.

Mehr dazu in dieser Grafik:

Etwas mehr als die Hälfte der ConfigMgr-Kunden hat bereits ein Upgrade auf das neue Current Branch-Modell durchgeführt. Aktuell werden mehr als 100 Mio. Geräte aktiv verwaltet, die uns Telemetriedaten zur Verfügung stellen.

100 Mio., das ist unfassbar!!!!

Meines Wissens gibt es weltweit nur drei Enterprise-Services, die monatlich über mehr als 100 Mio. aktive verwaltete Nutzer oder Geräte verfügen und Telemetriedaten übermitteln:  Office 365, Azure Active Directory und ConfigMgr. Was haben diese drei Dienste gemeinsam?  Sie sind alle in die Microsoft 365-Umgebung integriert.

Diese Grafik zeigt die Nutzungszahlen der ConfigMgr-Hauptversionen im Current Branch seit Version 1511. Wir verfügen über ein Dashboard, in dem die Daten in Echtzeit aktualisiert werden und das wir jeden Sonntagmorgen um 8:30 Uhr an das ganze Team senden.

Nicht nötig zu erwähnen, dass Sonntagmorgen, 8:30 Uhr, mit zu den besten Momenten in der Woche zählt.

Dies war das schnellste ConfigMgr-Upgrade aller Zeiten und wie aus der Grafik ersichtlich, steigt die Akzeptanzrate (die Steigung der Linie von links nach rechts) mit jedem Release noch schneller und steiler an. Zuerst waren wir etwas unsicher, wie die ConfigMgr-Community auf diese schnellen Releasezyklen reagieren würde. Letzten Endes waren wir jedoch überrascht und erfreut über das in uns gesetzte Vertrauen.

Das Interesse und die Leidenschaft für Project Hermes war noch nie so groß wie heute.

So geht es weiter

Unsere Reise in die Cloud begann im November 2015 mit ConfigMgr-Version 1511 im Current Branch. Schon damals war uns klar, dass dies ein großer Schritt in die richtige Richtung ist. Wir wussten aber auch, dass noch eine Menge Arbeit vor uns lag,

da das Innovationstempo seit Version 1511 weiter zugelegt hatte. Immer mehr Unternehmen steigen auf moderne Cloud Services und vernetzte mobile Geräte um. Um den Wünschen unserer Kunden in diesem schnelllebigen Umfeld nachzukommen, haben wir mit der ConfigMgr-Infrastruktur einen großen Schritt in Richtung eines echten Clouddiensts gemacht. Mit kontinuierlichen Funktionsupdates bieten wir Kunden dank cloudbasierter KI bedarfsgerechte Services und Sicherheit nach Maß. Als skalierbarer Clouddienst kann ConfigMgr zudem weltweit Geräte im dreistelligen Millionenbereich unterstützen.

All dies ruft mir in Erinnerung, was ich am häufigsten von IT-Führungskräften aus aller Welt höre:  Viele beklagen sich über die Komplexität, die ihnen und ihren Teams produktives Arbeiten erschwert. Unternehmen suchen nach Lösungen für eine einfachere Bereitstellung und die einheitliche Einrichtung von Nutzern auf allen Geräten – inklusive der nötigen Verwaltungs- und Sicherheitsfunktionen. Aus diesem Grund haben wir Microsoft 365 entwickelt.  Microsoft 365 bietet eine moderne, sichere Arbeitsumgebung sowie integrierte Cloud Services für höhere Produktivität. Die Suite ermöglicht der IT die Bereitstellung einer vielseitigen und leistungsfähigen Arbeitsumgebung, die die Nutzer lieben und der IT-Administratoren vertrauen.

Dies ist die nächste Entwicklungsstufe der seit vielen Jahren vertrauten Microsoft-Produkte – Windows, Office, Active Directory und ConfigMgr – die jetzt mit der Komplettlösung Microsoft 365 alle in der Cloud verfügbar sind.  Unternehmenskunden auf der ganzen Welt migrieren in die Cloud (zu Windows 10 as-a-Service, Office 365 und EMS) und läuten den nächsten logischen Entwicklungsschritt der ConfigMgr-Architektur ein.

Nahezu jedes Unternehmen aus Industrie und Handel auf der Welt startet heute von einem lokalen Modell, das mit Active Directory, Gruppenrichtlinien und ConfigMgr verwaltet wird. Der Umstieg auf ein einfacheres und moderneres Modell ist beschlossene Sache, aber der Weg dorthin war bisher schwierig. Ein Unternehmen kann Benutzer/Geräte nicht einfach per Fingerschnipp von AD/GP/ConfigMgr zu AAD/Intune migrieren. Was Kunden benötigen, ist eine Brücke zu einer einfacheren, schnelleren und risikofreien Verwaltung. Durch unsere Zusammenarbeit mit Unternehmen, die vom lokalen Exchange-Dienst auf Exchange Online umgestiegen sind, haben wir in diesem Bereich viel dazugelernt.

Deshalb freue ich mich, Ihnen heute mit der Co-Verwaltung ein neues Funktionsset vorstellen zu dürfen, das Ihnen den schnellen Wechsel zur modernen Verwaltung in der Cloud erleichtert. Mit dem Fall Creators Update kann ein Windows 10-Gerät zur gleichen Zeit mit dem lokalen Dienst Active Directory (AD) und Azure AD in der Cloud verbunden sein.

Die Co-Verwaltung nutzt diese Neuerung, indem sie die gemeinsame Geräteverwaltung durch den ConfigMgr-Agent und Intune MDM ermöglicht. Der Umstieg auf die moderne Verwaltung ist also kein Sprung mehr ins kalte Wasser. Mit der Co-Verwaltung wechseln Kunden Schritt für Schritt in die Cloud und bestimmen dabei das richtige Tempo für ihr Unternehmen.

Mit der ConfigMgr-Konsole ist es ganz einfach, Geräte unter Verwaltung zu stellen und für die Verwaltung mit Intune zu registrieren. Im nächsten Schritt wählen Sie den ersten Workload aus, der in die Cloud migriert werden soll (indem Sie ihn mit einem Schieberegler von ConfigMgr nach Intune verschieben).

Das Besondere an der Co-Verwaltung in Microsoft 365 ist, dass ConfigMgr und Intune ständig miteinander kommunizieren. Während der Migration der Workloads erkennen wir, wer die Autorität (Intune oder ConfigMgr) über die einzelnen Benutzer- und Geräteattribute hat. So werden Konflikte bei der Durchsetzung von Richtlinien vermieden.

Auch der Umstieg auf Windows 10 und die moderne Verwaltung in der Cloud erfolgt deutlich schneller.

* * * * *

Mit diesem Artikel habe ich mich auf eine Reise in die Vergangenheit begeben. SMS, ConfigMgr und Intune haben das Leben vieler Menschen nachhaltig verändert. Das gilt für mich, meine Familie, Tausende von Projektentwicklern sowie Millionen von IT-Experten, die diese Lösungen jeden Tag nutzen. Dieses Produkt und die Community liegen mir sehr am Herzen.

Ich hatte großen Spaß dabei, die Geschichte von ConfigMgr heute noch einmal Revue passieren zu lassen – aber das war erst Teil 1. Teil 2 ist sogar noch interessanter, denn bei Teil 2 werden die Nutzer selbst kreativ.

Besuchen Sie den Microsoft-Stand auf der Ignite, und erzählen Sie den Mitarbeitern der Management- und Sicherheitsteams Ihre Geschichte. Eine einfache Anleitung finden Sie hier.

Aber auch wenn wir uns nicht auf der Ignite treffen, können Sie ganz einfach teilnehmen. Erzählen Sie uns Ihre Geschichte, indem Sie Ihre Erinnerungen und Geschichten zu ConfigMgr hier aka.ms/ConfigMgr25 hochladen. Hier finden Sie einige grundlegende Schritte.

Anhand Ihrer Einsendungen gestalten wir ein Video mit dem Titel:

„The People’s History of ConfigMgr“.

Ich bin schon ganz gespannt auf unser Video.

_______________________________________________