25 años de ConfigMgr

A finales de la semana pasada, escribí sobre el notable hito de 25 años alcanzado por ConfigMgr, y hoy me gustaría profundizar aún más en la historia de este increíble producto, compartir un par de anuncios y presentar un nuevo y espectacular documental (¡prepárate, Sundance!), el cual ofrece una visión en profundidad de la génesis y del crecimiento del producto que creó el sector de la administración de equipos.

A continuación, el anuncio de ConfigMgr:

Y con este hito actual en mente, te voy a contar una historia que quizás no hayas escuchado antes.

Cómo empezó todo

La semana pasada, aproveché la oportunidad para volver a leer el documento original de la visión o las “especificaciones” del proyecto Hermes. No había revisado este documento desde hacía años y fue asombroso ver cómo ConfigMgr ha mantenido esa visión original. Los pilares fundamentales que se describen en ese documento todavía se usan en la actualidad y aún forman parte de sus bases.

En 1992, la misión original de Microsoft (un equipo PC en cada hogar y en cada escritorio) estaba llegando a una masa crítica. Las organizaciones estaban pasando de forma agresiva de la emulación de terminal al modelo x86 de computación distribuida, y no había una solución para administrar los equipos PC a escala. El equipo sabía que el proyecto Hermes tenía que causar impacto.

Este equipo original de SMS estaba formado por dos desarrolladores a tiempo completo y un becario llamado Ken Pan.  Cuando me uní al equipo en 2003, Ken “el becario” lideraba a todo el equipo de desarrollo, unos 150 ingenieros. Ken ha liderado los esfuerzos de ingeniería en SCCM e Intune para mí desde entonces.

Un dato curioso:  La primera compilación de Systems Management Server (SMS) fue la 245. ¿Por qué no la número uno? Windows estaba en la compilación 300 en ese momento y el equipo no quería que pareciera demasiado atrasado, pero sabían que elegir un número muy cerca del 300 generaría sospechas. De modo que eligieron el número 245.

SMS fue publicado oficialmente el siete de noviembre de 1994. El primer lanzamiento tardó en llegar un poco más de dos años. Hoy lanzamos nuevas compilaciones internas cada mes.

Un momento importante de ese lanzamiento fue un correo electrónico enviado por Bill Gates a cada empleado de Microsoft en el que explicaba que SMS se estaba implementando en toda la empresa. Bill, ingeniero desde siempre, señalaba en ese correo electrónico cómo podías eliminar el software de SMS de tu máquina si así lo deseabas.

Si quieres leer ese correo electrónico, lo he incluido al final de esta publicación.

El impulso de la arquitectura

SMS 1.0, 1.1 y 1.2 se lanzaron con bastante rapidez y, entonces, nació un nuevo mercado. Así que el equipo comenzó a trabajar en SMS 2.0 de inmediato.

Ahí es cuando las cosas se complicaron.

Sinceramente, tomamos algunas malas decisiones. Una parte importante de la mentalidad de crecimiento es la capacidad de aprender rápidamente, y esto ha sido vital para el equipo de SMS desde el principio.

Han cambiado muchas cosas en la arquitectura de cómo se creaban las aplicaciones cliente-servidor desde 1992. Básicamente, el equipo reescribió la infraestructura del servidor de SMS en 1997 y en 1998 para aumentar la escala y el rendimiento de SMS, y también integró las funcionalidades futuras de Windows Server 2000. Esta fue la primera vez que se reescribió la arquitectura de SMS para garantizar que fuera vanguardista en aquel momento.

SMS 2.0 se publicó en enero de 1999, y su adopción y su uso aumentaron rápidamente. Por entonces, yo estaba trabajando en el principal competidor de SMS, Novell, donde lideraba el equipo de Novell ZENworks. Me sería imposible contar la cantidad de horas que pasé reunido con clientes de SMS para explicarles los elementos diferenciadores de ZENworks, los cuales se basaban en un enfoque en los usuarios (identidades) con una integración de directorio profunda.

Mientras escribía esta entrada me recordaron que SMS 2.0 tenía un huevo de Pascua. El huevo de Pascua era un vídeo en el que se mostraban los nombres y las fotos de las personas que habían trabajado en el producto, y cuando lo volví a mirar esta semana, me llamó la atención un nombre:

Sí, Terry Myerson, mi jefe y el vicepresidente ejecutivo de Microsoft. Supongo que todas las grandes figuras han pasado por SMS en algún momento de su carrera.

Yo me uní al equipo de SMS justo cuando estaban intensificando los esfuerzos para lo que se convertiría en SMS 2003.

En SMS 2003, se volvieron a escribir, otra vez, partes significativas del producto. Un gran hito en ese momento fue alinear SMS en WSUS para aplicar revisiones. Esto alineaba la aplicación de revisiones de Microsoft desde la nube (Windows Update) con los consumidores y las empresas. WSUS utiliza esencialmente el mismo servicio de transferencia inteligente en segundo plano (BITS) que se usa para Windows Update, excepto que este último se ejecuta en tu centro de datos.

Windows Update es uno de los mayores servicios en la nube del mundo, ya que actualiza más de mil millones de dispositivos cada mes. Piensa en esto un momento:  uno de los diferenciadores clave de Microsoft en la nube pública hoy en día son nuestras funcionalidades híbridas y la capacidad de que puedas ejecutar nuestra nube pública en tu centro de datos. Poder ejecutar Windows Update en tu centro de datos (WSUS) fue algo realmente innovador y quizás el primer ejemplo de conexión a la nube y de una conexión híbrida. Este fue también un momento en que el uso de los portátiles había aumentado mucho y necesitábamos crear un nuevo cliente que funcionara en un modelo desconectado o conectado de forma imprecisa.

Conforme se acercaba el lanzamiento de SMS 2003, nos reuníamos cada viernes por la mañana con un grupo de trabajadores de toda la empresa para evaluar el estado del proyecto. Uno de los grupos más importantes invitados a esa reunión fue el departamento de TI de Microsoft (MSIT). En un acto sin precedentes en la empresa, concedí al equipo de TI autoridad para vetar la decisión de publicar SMS 2003 si creían que no estaba listo. Desde entonces, MSIT ha sido nuestro primer y mejor cliente, así como una de nuestras mejores fuentes de comentarios sobre compilaciones iniciales.

Hoy en día, administramos más de 500 000 equipos PC y dispositivos móviles en Microsoft (esta cantidad no está incluida en los 100 millones de dispositivos activos al mes) a través de una única implementación de ConfigMgr. Implementamos constantemente nuevos BITS en Microsoft a medida que desarrollamos cada versión mensual. Indudablemente, usamos nuestros propios productos. Otro dato curioso:  Mi equipo es el encargado de supervisar la implementación interna de ConfigMgr. No hay mejor manera de aprender que por medio de la experiencia.

Entre 2003 y 2007, lanzamos dos “Feature Packs” (paquetes de características). No queríamos tener que esperar a crear un producto completamente nuevo para ofrecer nuevas funcionalidades, por lo que innovamos esta nueva forma de lanzar capacidades. El primer Feature Pack terminaba el trabajo de alineación en WSUS para nuestra aplicación de revisiones. El segundo Feature Pack se publicó cuando lanzamos la implementación del sistema operativo.

Uno de mis recuerdos favoritos de esta época fue una demostración que organizamos en un evento en Europa en noviembre de 2003 para mostrar las nuevas funcionalidades de implementación del sistema operativo. Bill Gates dio el discurso de apertura y, durante su sección “Novedades en SMS”, actualizamos en directo 100 equipos PC en una pared detrás de él. Llamamos a esta demostración “Wall of Fire” (Muro de fuego).

Esta es una foto de Bill que tomamos cuando se giró para ver cómo se ejecutaba la demostración:

Esta es una foto de los valientes miembros del equipo de SMS que realizaron la demostración:

Cómo marcamos la diferencia

En otoño de 2004, Bill y Steve organizaron una reunión externa con algunos de los líderes principales de toda la empresa, y al final del día hubo una sesión abierta de preguntas y respuestas con los dos.  Alguien le preguntó a Bill qué era para él “lo más importante que ha sucedido en Microsoft durante el último año”. Bill respondió: “Hemos lanzado SMS y Active Directory, y serán un gran activo para nosotros en el futuro”.

A día de hoy, ese es uno de los mejores días de mi carrera profesional.

En 2007, cambiamos el nombre de “SMS” a “ConfigMgr” para alinearlo con la marca System Center. Desired State Configuration (DSC) era el escenario más nuevo e innovador que solicitaban los clientes, por lo que, una vez más, mejoramos la arquitectura para permitir que DSC funcionase como debía. También reescribimos completamente la experiencia administrativa.

En febrero de 2011, a mitad del proceso de desarrollo de SCCM 2012, Satya asumió el control de Server and Tools Business (STB), le cambió el nombre a Cloud and Enterprise (C+E) y se convirtió en mi jefe. En nuestra primera reunión cara a cara, Satya vino a mi oficina y pasó la mayor parte del tiempo conociéndome mejor como persona. Fue una experiencia increíble trabajar directamente para Satya durante varios años y aprender de su naturaleza eminentemente inquisitiva, de su mentalidad de crecimiento y de su enfoque de liderazgo humilde y servicial. Satya tuvo un impacto enorme en el futuro y en la arquitectura de ConfigMgr durante este lanzamiento.

En ConfigMgr 2012, cambiamos completamente la arquitectura al enfocarla, junto con la experiencia, en los usuarios, no solo en los dispositivos.

Los clientes nos decían que la movilidad iba a ser clave en el futuro y comprendimos que se referían a la movilidad de los seres humanos, no solo a la de los dispositivos.  En respuesta a esta información, simplificamos muchísimo la arquitectura para requerir menos hardware y aumentamos enormemente los límites de la escala. Aquí es cuando empezamos a tomarnos realmente en serio nuestro viaje a la nube; conectamos ConfigMgr a Microsoft Intune y este último se convirtió, básicamente, en la ventaja de ConfigMgr.

Esta configuración híbrida fue el modelo que nos permitió innovar en la nube y proporcionar un nuevo valor a ConfigMgr local a través de la implementación híbrida. Creíamos que la nube permitiría escenarios que hubieran sido imposibles en el pasado, y Satya veía el impacto potencial de la nube en la administración de dispositivos, por lo que realmente nos impulsó a innovar y a experimentar en este campo.

La transición de ConfigMgr a la nube

La siguiente evolución de la arquitectura fue, de lejos, la más desafiante.

Cuando nos enteramos de que Windows 10 se entregaría como un servicio con varias actualizaciones cada año, supimos que ConfigMgr debía seguir su ejemplo y moverse a la nube.

Este desafío fue abrumador.

Históricamente, ConfigMgr se había lanzado en una cadencia de entre dos y tres años. Recuerdo que leí el primer plan completo para SCCM 2007 y había 16 meses de estabilización y de desarrollo de la versión beta entre el momento en que se completaba el código y el lanzamiento. ¡16 meses!   Estaba claro que necesitábamos diseñar ConfigMgr como un software como servicio para poder realizar varios lanzamientos al año.

Con una tarea tan sobrecogedora por delante, formamos un pequeño equipo de ingenieros y administradores de programas que conocían ConfigMgr en profundidad, que tenían una mentalidad de crecimiento y que compartían una pasión por esta base de clientes.  Creíamos que la única forma de lograr esto era que un equipo pequeño y especializado revisara toda la arquitectura y creara un servicio proporcionado por la nube desde cero.

Debo admitir que, cuando miré nuestro calendario para esta revisión, aparte de manifestar mi desbordante optimismo habitual, tuve algunas dudas. Conseguir terminarlo todo tan rápido era una tarea increíble.

Ahora, el resultado está claro:  este equipo de ingeniería superespecializado superó cada punto de referencia y proporcionó un nuevo enfoque basado en la nube para la administración de equipos, el cual nos permitió pasar a un ciclo de lanzamiento mensual. Para realizar un seguimiento de estas actualizaciones, eliminamos los números de versión tradicionales (por ejemplo, 2003, 2007, 2012) y en su lugar comenzamos a nombrarlos con una combinación del año y el mes; por lo tanto, la primera versión fue la número 1511 porque la lanzamos en noviembre de 2015.

Desde entonces, hemos lanzado una nueva versión interna de ConfigMgr cada mes y las versiones principales de Rama actual aproximadamente cada cuatro meses.

Este es, sin lugar a dudas, uno de los esfuerzos de ingeniería más increíbles en los que he participado nunca.

La respuesta de los clientes a este nuevo modelo proporcionado en la nube ha sido asombrosa.

Echa un vistazo a este gráfico:

Un poco más de la mitad de la base de ConfigMgr ya ha sido actualizada al nuevo modelo de la rama actual, y ahora hay más de 100 millones de dispositivos que se están administrando activamente y que están devolviendo telemetría.

¡100 millones!

Que yo sepa, solo hay tres servicios empresariales en el mundo con más de 100 millones de usuarios o dispositivos activos al mes, los cuales administran y les envían telemetría:  Office 365, Azure Active Directory y ConfigMgr. ¿Qué tienen estas tres cosas en común?  Todas forman parte de la oferta integrada de Microsoft 365.

Este gráfico muestra la adopción de las versiones principales de Rama actual de ConfigMgr desde la versión 1511. Tenemos un panel que nos muestra estos datos en tiempo real y enviamos este gráfico a todo nuestro equipo cada domingo por la mañana a las 8:30.

Créeme cuando te digo que uno de mis momentos favoritos de cada semana tiene lugar el domingo a esta hora.

Esta ha sido la actualización más rápida de todos los tiempos para ConfigMgr, y puedes ver que la tasa de adopción (la línea de pendiente que va de izquierda a derecha) es más rápida y más pronunciada con cada lanzamiento. Al principio, estábamos un poco nerviosos por ver cómo reaccionaría la comunidad de ConfigMgr a estos lanzamientos tan rápidos, y estamos tanto sorprendidos como agradecidos por tu confianza en nosotros.

Nunca ha habido más interés y pasión por el proyecto Hermes que en este momento.

¿Qué depara el futuro?

Comenzamos el viaje a la nube con la versión 1511 de Rama actual de ConfigMgr en noviembre de 2015 y, en aquel entonces, nos quedó claro que este era un paso importante hacia donde necesitábamos llegar. Aunque también nos quedó claro que había mucho más trabajo por hacer.

El ritmo de innovación desde 1511 no ha dejado de aumentar. Las organizaciones están pasando rápidamente a un mundo de servicios en la nube conectados a dispositivos móviles y, para que podamos ofrecer lo que necesitas en este entorno acelerado, la infraestructura de ConfigMgr ha dado grandes pasos para ser un verdadero servicio en la nube. Ahora, es un servicio que se actualiza continuamente con nuevas capacidades y que utiliza las funcionalidades de inteligencia artificial de la nube para adaptarse a tus necesidades y ofrecerte la protección que necesitas. Además, está disponible como un servicio basado en la nube que es capaz de escalar a cientos de millones de dispositivos en todo el mundo.

Esto me recuerda a lo que me comentan con más frecuencia los líderes de TI de todo el mundo:  están frustrados por la complejidad a la que se enfrentan ellos y sus equipos para poder realizar su trabajo. Las organizaciones buscan formas de simplificar lo que han implementado y quieren una manera unificada para habilitar a sus usuarios en todos los dispositivos, la cual también ofrezca la administración y la seguridad que necesitan. Por eso hemos creado Microsoft 365.  M365 ofrece un área de trabajo moderna y segura, y los servicios integrados en la nube que permiten que los usuarios sean más productivos. Ha sido diseñado para permitir que el departamento de TI proporcione el entorno de trabajo completo y avanzado que les encanta a los usuarios y en el que confían los profesionales de TI.

Esta es la siguiente evolución de todos los productos de Microsoft que has estado usando durante años (Windows, Office, Active Directory, ConfigMgr), ya que los hemos trasladado todos a la nube con Microsoft 365.  Los clientes empresariales de todo el mundo están migrando a la nube (con Windows 10 como servicio, Office 365 y los servicios de EMS) y esta es la próxima evolución natural de la arquitectura de ConfigMgr.

Actualmente, casi todas las empresas y organizaciones comerciales del planeta comienzan con un modelo local en el que usan Active Directory, directivas de grupo y ConfigMgr como sus herramientas de administración. Hay un gran deseo de pasar a un modelo más simple y moderno, pero llegar a ese nuevo modelo moderno no ha sido fácil. Una organización no puede simplemente chasquear los dedos y mover los usuarios y dispositivos de Active Directory, directivas de grupo y ConfigMgr a AAD e Intune. Lo que necesitas es un servicio puente que simplifique y acelere este movimiento y elimine riesgos. Esta es un área en la que hemos aprendido mucho al observar cómo las organizaciones pasan de Exchange local a Exchange Online.

Hoy nos complace anunciar la administración conjunta, una nueva agrupación de funcionalidades que servirá de puente para ayudar a acelerar la transición a la administración moderna desde la nube. Gracias a Windows 10 Fall Creators Update, se puede unir un dispositivo con Windows 10 a Active Directory (AD) local y a Azure AD al mismo tiempo.

La administración conjunta aprovecha esta mejora y permite que el dispositivo sea administrado tanto por el agente de ConfigMgr como por la administración de dispositivos móviles (MDM) de Intune. El cambio a la administración moderna ya no es como tirarse de cabeza a la piscina. Con la administración conjunta, puedes realizar tu propio viaje hacia la nube paso a paso, de una manera y a un ritmo que sean adecuados para tu organización.

Hemos simplificado la forma de trabajar dentro de la consola de ConfigMgr para administrar los dispositivos e inscribirlos para su administración con Intune. De este modo, puedes seleccionar la primera carga de trabajo que deseas mover a la nube y usar la barra deslizante, la cual se mueve, literalmente, desde ConfigMgr a Intune, para moverla a la nube.

Una de las funcionalidades únicas de Microsoft 365 en este escenario administrado conjuntamente es que ConfigMgr e Intune están en comunicación constante. A medida que se mueven las cargas de trabajo, entendemos cuál es el origen de autoridad (Intune o ConfigMgr) para cada atributo de los usuarios y dispositivos, lo cual evita que se apliquen directivas conflictivas.

Esto acelerará enormemente el cambio a Windows 10 y la administración moderna desde la nube.

* * * * *

Escribir esta entrada ha sido un paseo increíble por los recuerdos. SMS, ConfigMgr e Intune han tenido un profundo impacto en mi vida, en la vida de mi familia, en la vida de miles de ingenieros que han trabajado en los proyectos y en la vida de millones de profesionales de TI que los han usado y los continúan usando hoy. Me encantan este producto y esta comunidad.

También me ha gustado mucho ver el documental de hoy sobre la historia de ConfigMgr, pero esa es solo la primera parte. La segunda parte es mucho más importante, porque la vas a crear tú.

Si vas a asistir a Ignite, pasa por la sección de administración y seguridad del puesto de Microsoft y cuéntanos tu historia. Estas son algunas indicaciones sencillas.

Aunque no asistas a Ignite, sigue siendo muy fácil participar. Si quieres contarnos tu caso, carga tus recuerdos y tus historias sobre ConfigMgr en aka.ms/ConfigMgr25. Aquí encontrarás varias instrucciones básicas.

Usaremos el contenido presentado para crear la segunda parte de un vídeo que nos gustaría titular:

“The People’s History of ConfigMgr” (La historia popular de ConfigMgr).

Estoy deseando verlo.

_______________________________________________