ConfigMgr @ 25

En fin de semaine dernière, j’ai écrit un billet sur la remarquable évolution de ConfigMgr au cours du quart de siècle passé, et aujourd’hui, j’aimerais revenir plus en détail sur cet incroyable produit, partager quelques annonces et donner le coup d’envoi à un nouveau documentaire (Sundance, attention !), retraçant de manière approfondie la genèse et l’évolution du produit à l’origine de la gestion PC.

Ensuite, l’annonce ConfigMgr :

Et avec cet important jalon à l’esprit, voici une histoire que vous n’avez peut-être jamais entendue :

Comment tout a commencé

En fin de semaine dernière, je me suis replongé dans le document d’origine qui décrivait la vision du projet Hermes. Je n’étais pas revenu sur ce document depuis plusieurs années et j’ai été surpris de constater à quel point ConfigMgr est resté fidèle à cette vision d’origine. Les éléments de création de base décrits dans ce document sont toujours utilisés aujourd’hui, et continuent de faire partie de ses fondements.

En 1992, la mission que s’était fixé Microsoft (un ordinateur sur chaque bureau et dans chaque foyer) enregistrait un franc succès. Les organisations évoluaient brutalement de l’émulation de terminal au modèle d’informatique distribuée x86, et aucune solution ne permettait de gérer les PC à grande échelle. L’équipe savait que le projet Hermes devait être percutant.

L’équipe SMS d’origine était composée de deux développeurs à plein temps et d’un stagiaire du nom de Ken Pan.  En 2003, lorsque j’ai rejoint l’équipe, Ken le stagiaire dirigeait l’équipe de développement composé de quelque 150 ingénieurs. Depuis, Ken mène toujours les efforts d’ingénierie portant sur SCCM et Intune !

Anecdote :  Le tout premier serveur de gestion de systèmes (Systems Management Server – SMS) était appelé 245. Pourquoi pas 1 ? Eh bien… Windows en était à la build 300 à l’époque, et l’équipe ne voulait pas paraître trop en retard, mais elle savait aussi qu’un numéro trop proche de 300 susciterait la méfiance. Nous avons donc choisi 245 !

SMS a été officiellement lancé le 7 novembre 1994. La première version avait pris un peu plus de deux ans. Aujourd’hui, nous publions de nouvelles builds tous les mois !

Ce lancement a été marqué par l’envoi d’un e-mail de Bill Gates à chaque employé Microsoft expliquant que SMS était déployé dans toute l’entreprise. En tant qu’ingénieur, Bill indiquait même dans cet e-mail comment supprimer le logiciel SMS de sa machine. (:

Si la lecture de cet e-mail vous intéresse, vous le trouverez à la fin de ce billet.

Évolution de l’architecture

Les versions 1.0, 1.1 et 1.2 de SMS ont été publiées rapidement, et un nouveau marché a vu le jour. Sans attendre, l’équipe s’est mise à travailler sur SMS 2.0.

C’est à ce moment-là que les choses ont commencé à se compliquer.

Et pour être tout à fait honnête, nous avons pris quelques mauvaises décisions. En matière de croissance, la capacité à apprendre rapidement est importante, un point que l’équipe SMS a d’emblée compris.

L’architecture sur laquelle repose la conception des applications client-serveur a tellement évolué depuis 1992 que l’équipe a essentiellement réécrit l’infrastructure du serveur SMS en 1997 et 1998 afin d’améliorer ses performances, et elle a aussi intégré les nouvelles fonctionnalités de Windows Server 2000. C’était la première fois que l’architecture SMS était réécrite pour être à la pointe de la technologie de l’époque.

SMS 2.0 a été publié en janvier 1999, et son adoption, de même que son utilisation se sont accélérées. À l’époque, je travaillais chez le principal concurrent de SMS, Novell, où je dirigeais l’équipe Novell ZENworks. Je passais le plus clair de mon temps à rencontrer des clients SMS qui me parlaient de ce qui différenciait ZENworks, basé sur les utilisateurs (identités) avec une intégration en profondeur d’annuaire !

En rédigeant ce billet, je me suis rappelé que SMS 2.0 était accompagné d’un bonus. Ce bonus, c’était une vidéo présentant les personnes qui avaient travaillé sur le produit, et lorsque je l’ai revisionnée cette semaine, un nom m’a interpellé :

Terry Myerson, mon responsable, également vice-président exécutif de Microsoft. Je constate que tous les plus grands ont travaillé sur SMS, à un moment ou à un autre de leur carrière. (:

J’ai rejoint l’équipe SMS alors qu’elle mettait au point ce qui allait devenir SMS 2003.

Dans SMS 2003, d’importantes parties du produit ont été, une nouvelle fois, réécrites. À l’époque, aligner SMS sur WSUS à des fins de correction était une étape importante. Cela a permis d’aligner les corrections Microsoft issues du cloud (Windows Update) sur les consommateurs et l’entreprise. WSUS est identique à ce qui est utilisé pour Windows Update, sauf qu’il s’adresse à votre centre de données.

Windows Update est un des plus grands services cloud au monde, et met à jour plus d’un milliard d’appareils tous les mois. Lorsqu’on prend le temps d’y réfléchir :  Aujourd’hui, l’un des principaux éléments différenciant Microsoft dans le cloud public réside dans ses capacités hybrides, et dans ce qui vous permet d’exécuter notre cloud public dans votre centre de données. L’exécution de Windows Update dans votre centre de données (WSUS) était vraiment novatrice et illustre peut-être le premier exemple de cloud connecté et hybride. À l’époque, l’utilisation des ordinateurs portables s’était accélérée, et nous devions créer un nouveau client fonctionnant dans un modèle déconnecté ou faiblement connecté.

À l’approche de la sortie de SMS 2003, nous nous réunissions chaque vendredi matin, entre collègues, pour évaluer l’état d’avancement du projet. Le service informatique de Microsoft (MSIT) était convié à ces réunions. Décision sans précédent au sein de l’entreprise, j’avais accordé à l’équipe informatique un droit de veto sur la publication de SMS 2003 si elle pensait qu’il n’était pas prêt. Depuis, MSIT est notre premier et notre meilleur client, de même que notre meilleure source de commentaires sur les premières builds.

Aujourd’hui, nous gérons plus de 500 000 PC et appareils mobiles, ici chez Microsoft, (ce chiffre n’est pas inclus dans les 100M MAD), via un seul déploiement ConfigMgr. Nous déployons sans cesse de nouveaux éléments dans le cadre de nos builds mensuelles. Nous utilisons vraiment ce que nous créons. Autre anecdote :  Mon équipe supervise actuellement le déploiement interne de ConfigMgr. Il n’y a pas de meilleur moyen d’apprendre que de créer !

Entre 2003 et 2007, nous avons publié deux « Packs de fonctionnalités ». Nous ne voulions pas attendre qu’un nouveau produit fournisse de nouvelles fonctionnalités. Nous avons donc innové en proposant cette nouvelle façon de proposer des capacités. Le premier pack de fonctionnalités nous a permis de nous aligner sur WSUS. Le second pack est intervenu lorsque nous avons lancé le déploiement du système d’exploitation.

Je me souviens avec plaisir d’une démonstration que nous avions faite lors d’un événement organisé en Europe, en 2003, pour présenter les capacités du nouveau déploiement du système d’exploitation. Lors du discours liminaire de Bill Gates, et plus précisément lors de la présentation des « Nouveautés de SMS », nous avons mis à niveau, en direct, 100 PC, sur un mur situé derrière Bill. Nous avons appelé cette démonstration le « Mur du feu ».

Voici une photo de Bill lorsqu’il s’est retourné pour regarder la démonstration :

Voici une photo des membres de l’équipe SMS à l’origine de cette démonstration :

Avoir un impact

À l’automne 2004, Bill et Steve ont organisé une réunion hors site avec quelques-uns des principaux dirigeants de l’entreprise, réunion qui s’est terminée par une séance de questions posées à Bill et Steve.  Quelqu’un a demandé à Bill quel avait été l’événement le plus marquant pour Microsoft au cours de l’année passée. Ce à quoi, Bill a répondu : « L’aboutissement de SMS et Active Directory, deux fantastiques ressources qui vont nous permettre de belles avancées. »

Cela reste un des plus beaux jours de ma vie professionnelle !

En 2007, nous avons rebaptisé « SMS » par « ConfigMgr » pour l’aligner à la marque System Center. La configuration d’état souhaité (DSC) était le dernier scénario innovant sollicité par nos clients. Nous avons donc une nouvelle fois modifié l’architecture pour permettre le bon fonctionnement de DSC. Nous avons aussi totalement réécrit l’expérience d’administration.

En février 2011, alors que nous étions à mi-parcours de SCCM 2012, Satya a repris la division Server and Tools Business (STB), l’a rebaptisée Cloud and Enterprise (C+E), et est devenu mon supérieur hiérarchique. Lors de notre premier entretien individuel, Satya est venu me voir dans mon bureau et nous avons fait plus ample connaissance. J’ai énormément apprécié de travailler pour Satya pendant plusieurs années, et beaucoup appris de sa nature curieuse, de son état d’esprit axé sur la croissance et de son approche modeste du leadership. Satya a considérablement influencé l’évolution et l’architecture de ConfigMgr lors de cette version.

Dans ConfigMgr 2012, nous avons fondamentalement bouleversé l’architecture pour nous concentrer sur les utilisateurs, et plus uniquement sur les appareils.

Les clients soulignaient l’importance de la mobilité dans les années à venir, et nous avons compris que cette mobilité ne se limitait plus aux appareils, mais englobait les utilisateurs.  Forts de ces informations, nous avons considérablement simplifié l’architecture pour qu’elle nécessite moins de matériel, et avons massivement augmenté les limites d’évolutivité. Notre parcours cloud a dès lors pris un tournant ; nous avons connecté ConfigMgr à Microsoft Intune, et Intune est devenu essentiellement la périphérie de ConfigMgr.

Grâce à ce modèle de configuration hybride, nous avons pu innover dans le cloud, et ce déploiement hybride nous a permis d’apporter une nouvelle valeur à ConfigMgr sur site. Nous étions persuadés que le cloud permettrait des scénarios jusque-là impossibles. Satya a bien perçu l’impact que pouvait avoir le cloud en termes de gestion des appareils, et il nous a réellement poussés à innover et à expérimenter.

ConfigMgr en route vers le cloud

L’évolution architecturale suivante a été, sans conteste, la plus difficile.

Lorsque nous avons appris que Windows 10 serait fourni en tant que service avec plusieurs mises à jour annuelles, nous avons compris que ConfigMgr devait lui emboîter le pas et migrer vers le cloud.

C’était un sacré défi.

Par le passé, ConfigMgr proposait de nouvelles versions tous les deux ou trois ans. Je me souviens avoir examiné le premier plan complet de SCCM 2007 et constaté 16 mois de stabilisation et de bêta entre le moment où nous avions déclaré le code complet et la publication. 16 mois !   Il apparaissait clair que nous devions « SaaSifier » ConfigMgr pour tenir une cadence de plusieurs publications par an.

Face à un tel défi, nous avons choisi de constituer une petite équipe d’ingénieurs et de responsables de programmes qui connaissaient bien ConfigMgr, avaient un esprit de croissance et partageaient une passion commune pour cette base de clients.  Nous étions persuadés que pour y parvenir, il nous fallait une petite équipe capable de remanier toute l’architecture et de créer un service cloud de bout en bout.

Lorsque je me suis penché sur le calendrier de ce remaniement, j’avoue que mon optimisme habituel a été sérieusement ébranlé. Travailler à un tel rythme relevait de la gageure.

Mais cela a marché.  Cette équipe d’ingénieurs ultra concentrés a dépassé tous les tests de performances, et a mis en place une nouvelle approche de gestion des ordinateurs basée sur le cloud qui nous a permis de passer à un cycle de publication mensuel. Pour suivre ces mises à jour, nous avons renoncé aux numéros de version classiques (à savoir, 2003, 2007, 2012) pour adopter une convention de nom avec année/mois. Ainsi, la première version publiée a été la version 1511 car nous l’avons publiée au cours du 11^e mois de l’année 2015.

Depuis, nous avons publié une nouvelle version Insider de ConfigMgr tous les mois, ainsi que des publications majeures Current Branch environ tous les quatre mois.

C’est indéniablement l’un des plus incroyables efforts d’ingénierie auxquels il ne m’a jamais été donné de participer.

Et la réponse des clients à ce nouveau modèle cloud s’est révélée tout aussi incroyable.

Jetez un coup d’œil à ce graphique :

Un peu plus de la moitié de la base ConfigMgr a déjà été mise à niveau vers le nouveau modèle de branche actuel et à ce jour, plus de 100 millions d’appareils sont activement gérés et renvoient des données de télémétrie.

Plus de 100 millions !!!!

À ma connaissance, seuls trois services d’entreprise dans le monde gèrent plus de 100 millions d’utilisateurs et d’appareils actifs qui leur renvoient des données de télémétrie :  Office 365, Azure Active Directory et ConfigMgr. Quel est le point commun entre ces trois services ?  Ils font tous partie de l’offre Microsoft 365.

Ce graphique illustre l’adoption des principales versions Current Branch de ConfigMgr depuis la version 1511. Un tableau de bord nous permet de consulter ces données en temps réel, et tous les membres de l’équipe reçoivent ce graphique chaque dimanche, à 8h30.

Et je peux vous dire que le dimanche matin, à 8h30, est un de mes moments préférés de la semaine.

Il s’agit de la mise à niveau la plus rapide de tous les temps pour ConfigMgr, et vous pouvez constater qu’à chaque nouvelle version, le taux d’adoption (la courbe de gauche à droite) est de plus en plus prononcée. Au début, nous étions un peu inquiets de la réaction de la communauté ConfigMgr face à des publications aussi rapides, mais nous avons été agréablement surpris de constater la confiance qui en a découlé.

Le projet Hermes n’a jamais suscité autant d’engouement qu’actuellement.

Étapes suivantes

Nous avons entamé notre parcours vers le cloud avec la version 1511 Current Branch de ConfigMgr en novembre 2015. À l’époque, nous avions bien conscience qu’il s’agissait là d’un jalon important de notre parcours. Nous mesurions aussi l’ampleur de la tâche qui nous attendait.

Depuis la version 1511, le rythme de l’innovation n’a eu de cesse de s’accélérer. Les organisations se tournent de plus en plus vers des services cloud connectés à des appareils mobiles. Et pour vous offrir ce dont vous avez besoin dans cet environnement en pleine évolution, l’infrastructure ConfigMgr a franchi une étape importante pour devenir un véritable service cloud. Désormais, le service est continuellement mis à jour avec de nouvelles fonctionnalités et utilise les fonctionnalités IA du cloud pour s’adapter à vos besoins et vous offrir la protection qu’il vous faut. Il vous est proposé sous forme de service cloud capable d’évoluer vers des centaines de millions d’appareils dans le monde entier.

Tout cela me fait penser à la remarque récurrente formulée par les responsables informatiques à travers le monde :  ils sont frustrés par la complexité à laquelle ils doivent, eux et leurs équipes, faire face pour mener la tâche qui leur incombe. Les entreprises entendent simplifier ce qu’elles ont déployé et ce faisant, recourir à un moyen unifié pour activer leurs utilisateurs sur tous les appareils, en leur offrant le niveau de gestion et de sécurité requis. C’est la raison pour laquelle nous avons créé Microsoft 365.  M365 offre un espace de travail moderne et sécurisé, ainsi que des services cloud intégrés qui permettent aux utilisateurs d’améliorer leur productivité. Il a été conçu pour mettre à la disposition des services informatiques un environnement de travail aussi riche que performant, un environnement apprécié des utilisateurs et approuvés par les professionnels de l’informatique.

C’est là la prochaine évolution de tous les produits Microsoft que vous utilisez depuis des années, Windows, Office, Active Directory, ConfigMgr, désormais disponibles dans le cloud grâce à Microsoft 365.  Les entreprises du monde entier migrent vers le cloud (et utilisent Windows 10 en tant que service, Office 365 et les services EMS). Il s’agit de la prochaine évolution naturelle de l’architecture ConfigMgr.

Partout dans le monde, la plupart des organisations et entreprises débutent avec un modèle local et utilisent Active Directory, une stratégie de groupe et ConfigMgr comme outils de gestion. Beaucoup sont tentés par un modèle plus simple et plus moderne, mais adopter ce nouveau modèle n’est pas simple. Une organisation n’est pas en mesure, en un claquement de doigts, de faire évoluer ses utilisateurs/appareils de AD/GP/ConfigMgr vers AAD/Intune. Nous devons vous aider à franchir ce pas, de manière plus simple, plus rapide, et sans risque. Dans ce domaine, nous avons beaucoup appris en observant des organisations passer d’Exchange en version locale à Exchange Online.

Aujourd’hui, nous sommes ravis d’annoncer Cogestion, un nouvel ensemble de fonctionnalités, doublé d’une passerelle visant à accélérer la transition vers une gestion moderne dans le cloud. Avec Fall Creators Update, un appareil Windows 10 peut être simultanément associé à Active Directory (AD) local et Azure AD.

La cogestion tire parti de cet avantage et permet à la fois à l’agent ConfigMgr et à Intune MDM de gérer l’appareil. Le passage à une gestion moderne ne s’apparente plus à une falaise du haut de laquelle il vous faut sauter. Avec la cogestion, vous pouvez entreprendre votre propre parcours vers le cloud, étape par étape, à un rythme adapté à votre organisation.

Nous avons simplifié l’utilisation de la console ConfigMgr de manière à l’étendre aux appareils gérés à des fins de gestion dans Intune. Vous pouvez ensuite sélectionner la première charge de travail que vous souhaitez déplacer vers le cloud (à l’aide d’un simple curseur que vous faites glisser de ConfigMgr vers Intune) et cette charge de travail sera déplacée vers le cloud.

Dans un tel scénario de cogestion, Microsoft 365 permet à ConfigMgr et Intune de communiquer en permanence. À mesure que les charges de travail sont déplacées, la source qui fait autorité (Intune ou ConfigMgr) pour chaque attribut ayant trait aux utilisateurs et appareils est déterminée, ce qui évite l’application de stratégies conflictuelles.

Cela aura pour effet de considérablement accélérer la transition vers Windows 10 et une gestion cloud moderne.

* * * * *

Rédiger ce billet m’a permis de me replonger dans de nombreux souvenirs. SMS/ConfigMgr/Intune ont eu un profond impact sur ma vie, la vie de ma famille, la vie de milliers d’ingénieurs amenés à travailler sur ces projets, et la vie de millions de professionnels de l’informatique qui ont utilisé et continuent d’utiliser ces outils aujourd’hui. J’aime ce produit autant que j’aime cette communauté.

J’ai aussi beaucoup apprécié le documentaire d’aujourd’hui sur l’histoire de ConfigMgr, mais ce n’est que la première partie. Et la seconde partie est encore plus importante. Pour la simple et bonne raison que vous allez en être les auteurs.

Si vous participez à l’événement Ignite, arrêtez-vous au point gestion et sécurité du stand Microsoft et racontez votre parcours. Vous trouverez ici des instructions claires pour vous y rendre.

Et si vous ne participez pas à cet événement, rien de plus simple. Racontez votre parcours et téléchargez votre récit sur ConfigMgr ici aka.ms/ConfigMgr25. Voici quelques instructions de base.

Nous utiliserons ces récits pour créer la seconde partie de notre vidéo que nous aimerions intituler :

« L’histoire populaire de ConfigMgr »

Je suis impatient de découvrir cette seconde partie.

_______________________________________________