ConfigMgr @ 25
No final da semana passada, escrevi sobre a bela marca de um quarto de século de existência alcançada pelo ConfigMgr. Hoje, gostaria de saber ainda mais da história desse incrível produto, compartilhar comunicados e apresentar um novo e impressionante documentário (cuidado, Sundance!) que oferece uma visão detalhada sobre o início e o desenvolvimento do produto que deu início à indústria do Gerenciamento de Computadores.
A seguir, o comunicado do ConfigMgr:
Com essa conquista em mente, confira uma história que pode ser novidade para você:
Como tudo começou
No final da semana passada, aproveitei a oportunidade para reler o documento que contém a ideia original ou “especificações” do Project Hermes. Já não via esse documento há muito tempo e me surpreendi ao ver como o ConfigMgr manteve-se fiel à visão original. Os componentes fundamentais descritos nesse documento ainda são usados atualmente, além de ainda fazerem parte da base do programa.
Em 1992, a missão original da Microsoft (também conhecida como “colocar um computador em cada mesa e em cada casa”) estava chegando a esse limite crítico. A migração das organizações da emulação de terminal para o modelo de computação distribuída do x86 era intensa. Entretanto, não havia uma solução para gerenciar os computadores em escala. A equipe sabia que o Project Hermes tinha que causar um grande impacto.
A equipe original do SMS era formada por dois desenvolvedores em tempo integral e um estagiário chamado Ken Pan. Quando entrei para a equipe em 2003, Ken, o estagiário, liderava toda a equipe de desenvolvimento que contava com cerca de 150 engenheiros. Desde essa época, Ken tem estado na frente das iniciativas de engenharia no SCCM e no Intune!
Curiosidade: A primeira versão do Systems Management Server (SMS) foi a 245. E por que não a versão 1? Bem… o Windows estava na versão 300 nessa época e a equipe não queria ficar muito atrás. Eles sabiam que escolher um número próximo a 300 seria suspeito. Então, escolheram o 245!
O SMS foi oficialmente lançado no dia 7 de novembro de 1994. Esse primeiro lançamento demorou pouco mais de dois anos. Atualmente, lançamos novas versões para os participantes do Office Insider todos os meses!
Um destaque desse lançamento foi o email enviado por Bill Gates a todos os funcionários da Microsoft explicando que o SMS estava sendo implantado em toda a empresa. Como engenheiro que é, nesse email, Bill indicou como remover o software do SMS do computador caso você quisesse fazer isso. (:
Se quiser ler esse email, ele está disponível na parte inferior desta postagem.
Promover a arquitetura
Os SMSs 1.0, 1.1 e 1.2 foram lançados rapidamente e um novo mercado emergiu logo a seguir. Sem demora, a equipe começou a trabalhar no SMS 2.0.
Foi aí que as coisas complicaram.
E, para dizer a verdade, tomamos algumas más decisões. Grande parte da mentalidade de crescimento é a capacidade de aprender rapidamente e isso tem sido de suma importância para a equipe do SMS desde o início.
Houve muitas mudanças na arquitetura, na forma como os aplicativos cliente-servidor foram criados desde 1992. Por isso, que a equipe praticamente reescreveu a infraestrutura do servidor do SMS em 1997 e 1998 para alavancar o dimensionamento e o desempenho do SMS, além de integrar os recursos futuros do Windows Server 2000. Esta foi a primeira vez que a arquitetura do SMS foi reescrita para garantir sua supremacia como a tecnologia mais sofisticada daquela época.
O SMS 2.0 foi lançado em janeiro de 1999 e a adoção e o uso foram acelerados. Na época, eu trabalhava para o maior concorrente do SMS, o Novell, e liderava a equipe da ferramenta Novell ZENworks. Seria impossível contar o número de horas passados em reuniões com clientes do SMS discutindo sobre os diferenciais da ZENworks que baseava-se no foco nos usuários (identidades) com profunda integração com o Active Directory!
Enquanto escrevia este post me lembrei que o SMS 2.0 tinha um ovo de Páscoa. O ovo de Páscoa era um vídeo que exibia os nomes e fotos das pessoas que trabalharam no produto e, ao assisti-lo novamente esta semana, um nome se destacou:
Pois é, Terry Myerson, meu chefe e Vice-presidente Executivo da Microsoft. Acredito que todos os grandes nomes da tecnologia realmente passaram pelo SMS em algum momento de suas carreiras. (:
Entrei para a equipe do SMS exatamente quando os esforços estavam sendo aumentados para atender aquilo que se tornaria o SMS 2003.
No SMS 2003, houve partes importantes do produto que foram reescritas mais uma vez. Um grande marco na época foi o alinhamento do SMS no WSUS para correções. Isso conciliou as correções da Microsoft, da nuvem (Windows Update) para os clientes e o Enterprise. O WSUS tem basicamente os mesmos bits usados no Windows Update, porém, com execução no datacenter.
O Windows Update é um dos maiores serviços de nuvem do mundo e atualiza mais de 1 bilhão de dispositivos todos os meses. Pense nisso por um minuto: Atualmente, dos principais diferenciais da Microsoft na nuvem pública, destacamos nossos recursos híbridos e a capacidade de você basicamente executar nossa nuvem pública em seu datacenter. Executar o Windows Update no datacenter (WSUS) foi, sem dúvida, um recurso pioneiro e, talvez, o primeiro exemplo de estar conectado à nuvem e ser híbrido. Foi também nesse período que o uso de laptops realmente deslanchou e precisávamos criar um novo cliente que funcionasse em um modelo desconectado ou fracamente conectado.
À medida que nos aproximávamos do lançamento do SMS 2003, nos reuníamos todas as sextas pela manhã com um grupo da empresa para avaliar o status do projeto. Um dos principais grupos convidados para essa reunião foi o departamento de TI da Microsoft (MSIT). Em uma jogada sem precedentes na empresa, concedi à equipe de TI o poder de veto sobre a decisão de enviar o SMS 2003, caso não achassem que ele estava pronto. Desde então, o MSIT tem sido nosso primeiro e melhor cliente, além de uma de nossas melhores fontes para colhermos opiniões sobre as versões iniciais.
Atualmente, gerenciamos mais de 500.000 computadores e dispositivos móveis aqui na Microsoft (esse número não está incluído no MAD e 100 milhões) através de uma única implantação do ConfigMgr. Enquanto criamos cada lançamento mensal, estamos constantemente implantando novos bits na Microsoft. Nós realmente comemos nossa própria ração para cachorro. Outra curiosidade: Na verdade, minha equipe supervisiona a implantação interna do ConfigMgr. Não há melhor forma de aprender do que fazendo!
Entre 2003 e 2007, lançamos dois “Pacotes de Recursos”. Não queríamos esperar que um novo produto inteiro fornecesse novas funcionalidades, por isso inovamos e criamos essa nova maneira de lançar recursos. O primeiro Pacote de Recursos finalizou o trabalho de alinhamento no WSUS para as correções. O segundo Pacote de Recursos surgiu quando lançamos o OS Deployment.
Uma das memórias preferidas que tenho desse período foi uma demonstração que montamos em um evento na Europa em novembro de 2003 para exibir os novos recursos do OS Deployment. Bill Gates estava fazendo a apresentação e, durante a seção “Novidades do SMS”, atualizamos 100 computadores na parede que estava atrás de Bill. Chamamos essa demonstração de “Parede de fogo”.
Aqui está uma foto que tiramos de Bill quando ele se virou para assistir à execução da demonstração:
E, aqui, temos uma foto dos destemidos membros da equipe do SMS que organizaram a demonstração:
Criar um impacto
No outono de 2004, Bill e Steve organizaram uma reunião externa com alguns dos líderes seniores de toda a empresa e a última sessão do dia foi aberta a perguntas e respostas com Bill e Steve. Alguém perguntou a Bill o que ele achava que era “a coisa mais importante que havia acontecido com a Microsoft no ano anterior”. Bill respondeu: “Está tudo bem com o SMS e o Active Directory e eles serão ótimos recursos para nós daqui para frente”.
Até agora, esse é um dos melhores dias da minha carreira profissional!
Em 2007, mudamos o nome de “SMS” para “ConfigMgr” para alinhá-lo com a marca System Center. A DSC (Desired State Configuration) era o cenário mais recente e inovador que os clientes buscavam, então, mais uma vez, desenvolvemos a arquitetura para realmente permitir que a DSC funcionasse nas condições desejadas. Também reescrevemos toda a experiência administrativa.
Em fevereiro de 2011, no meio do processo de engenharia do SCCM 2012, Satya assumiu o STB (Server and Tool Business), rebatizou-o como C+E (Cloud and Enterprise) e tornou-se meu chefe. Em nossa primeira reunião a sós, Satya veio até meu escritório e passou a maior parte do tempo tentando realmente me conhecer melhor como pessoa. Foi uma experiência incrível trabalhar diretamente com Satya por vários anos e aprender com seu jeito curioso, sua mentalidade de crescimento e sua maneira humilde e simples de liderar. Satya exerceu um enorme impacto no futuro e na arquitetura do ConfigMgr durante o desenvolvimento desta versão.
No ConfigMgr 2012, basicamente transformamos o coração da arquitetura, concentrando a arquitetura e experiência em usuários e não apenas em dispositivos.
Os clientes diziam que a mobilidade seria essencial no futuro e entendemos que essa mobilidade se referia à mobilidade dos próprios humanos e não apenas dos dispositivos. Em resposta a essa informação, reduzimos drasticamente a arquitetura para exigir menos hardware e ampliamos bastante os limites de dimensionamento. É nesse ponto que nossa jornada para a nuvem realmente ficou séria. Conectamos o ConfigMgr ao Microsoft Intune e o Intune praticamente se tornou a borda do ConfigMgr.
Essa configuração híbrida tornou-se o modelo que nos permitiu inovar na nuvem e, depois, fornecer um novo valor ao ConfigMgr local através dessa implantação híbrida. Acreditávamos que a nuvem possibilitaria situações que seriam impossíveis no passado e Satya via o possível efeito da nuvem no gerenciamento de dispositivos. Satya realmente nos incentivou a inovar e experimentar nessa etapa.
O ConfigMgr migra para a nuvem
A evolução da arquitetura que veio a seguir foi, de longe, a mais desafiadora.
Quando soubemos que o Windows 10 seria oferecido como um serviço com várias atualizações lançadas todos os anos, sabíamos que o ConfigMgr precisava seguir o mesmo caminho e migrar para a nuvem.
O desafio foi assustador.
Historicamente, o ConfigMgr foi lançado em uma cadência de 2 a 3 anos. Lembro-me de olhar para o primeiro plano completo do SCCM 2007 e ver os 16 meses, da estabilização e versão beta, entre o momento que anunciamos a conclusão do código e o lançamento do produto. 16 meses! Ficou claro que precisávamos de “SaaS-ificar” o ConfigMgr para manter uma cadência de vários lançamentos por ano.
Com uma tarefa tão difícil pela frente, decidimos escolher uma pequena equipe de engenheiros e gerentes de programa que conheciam o ConfigMgr profundamente, tinham uma mentalidade de crescimento e tinham um entusiasmo comum por essa base de clientes. Acreditávamos que a única maneira de conseguirmos isso era com uma equipe pequena e focada para revisar toda a arquitetura e criar um serviço de nuvem do zero.
Quando olhei para o cronograma para encaixar essa revisão, admito que senti uma pontada de ceticismo misturado com meu habitual otimismo exagerado. Conseguir produzir tão rapidamente foi uma tarefa impressionante.
Agora, o resultado é óbvio: Essa equipe de engenharia extremamente focada excedeu todos os parâmetros e forneceu uma nova abordagem baseada em nuvem para o gerenciamento de computadores que nos permitiu passar para um ciclo de lançamento mensal. Para acompanhar essas atualizações, eliminamos os números de versões tradicionais (por exemplo: 2003, 2007, 2012). Em vez de números, passamos a dar nomes usando o formato ano/mês. Assim, o primeiro lançamento tem o nome de versão 1511 porque foi lançado no mês 11 de 2015.
Desde então, lançamos uma nova versão interna do ConfigMgr todos os meses e os principais lançamentos do CurrentBranch a cada 4 meses, mais ou menos.
Isso é, sem sombra de dúvida, um dos mais incríveis esforços de engenharia do qual já participei.
A resposta do cliente a este novo modelo fornecido pela nuvem foi incrível.
Confira este gráfico:
Pouco mais da metade da base do ConfigMgr já foi atualizada para o novo modelo do branch atual e, no momento, há mais de 100 milhões de dispositivos sendo ativamente gerenciados e transmitindo telemetria.
Puxa, 100 milhões!!!!
Que eu saiba, existem apenas 3 serviços corporativos no mundo que têm mais de 100 milhões de usuários ativos mensais ou dispositivos sob gerenciamento e que transmitem telemetria: o Office 365, o Azure Active Directory e o ConfigMgr. O que esses três têm em comum? Todos fazem parte da oferta integrada do Microsoft 365.
Este gráfico mostra a adoção dos principais lançamentos do Branch Atual do ConfigMgr desde a versão 1511. Temos um painel que exibe esses dados em tempo real e o enviamos para toda a equipe todos os domingos às 8:30.
Acredite em mim quando digo que 8:30 da manhã de domingo é um dos meus momentos preferidos da semana.
Esta foi a atualização mais rápida de todos os tempos do ConfigMgr e você pode ver que a cada lançamento a taxa de adoção (a inclinação da linha da esquerda para a direita) torna-se mais rápida e mais acentuada. No começo, ficamos um pouco apreensivos sobre como a comunidade do ConfigMgr reagiria a versões tão rápidas, mas ficamos surpresos e gratos pela sua confiança e pelo crédito depositado em nós.
Nunca houve tanto interesse e entusiasmo pelo Project Hermes do que há agora.
O que vem a seguir
Começamos a jornada para a nuvem com o lançamento da versão 1511 do Branch Atual do ConfigMgr em novembro de 2015 e, na época, ficou claro para nós que esse era um passo importante em direção àquilo que almejávamos. Também ficou claro para nós que havia muito mais trabalho a ser feito.
O ritmo da inovação desde a versão 1511 só acelerou. As organizações têm migrado rapidamente para um mundo de serviços em nuvem conectados a dispositivos móveis e, para oferecer aquilo que você precisa neste ambiente acelerado, a infraestrutura do ConfigMgr tomou medidas importantes para se tornar um verdadeiro serviço em nuvem. Atualmente, o ConfigMgr é um serviço que tem atualizações contínuas com novos recursos, que utiliza os recursos de IA da nuvem para se ajustar às suas necessidades e fornecer a proteção necessária. Além disso, está disponível como um serviço baseado em nuvem que pode ser dimensionado para centenas de milhões de dispositivos em todo o mundo.
Tudo isso me faz lembrar da coisa mais comum que ouço de líderes de TI em todo o mundo: Eles sentem-se frustrados com a complexidade com que eles e suas equipes têm que lidar para trabalhar. As organizações buscam formas de simplificar os serviços implantados e querem um método unificado para habilitar seus usuários em todos os dispositivos, mas que também ofereça o gerenciamento e a segurança necessários. É por isso que criamos o Microsoft 365. O M365 oferece um espaço de trabalho moderno e seguro e serviços de nuvem integrados que permitem aos usuários alcançar mais. Ele foi projetado para permitir que a TI ofereça um ambiente de trabalho avançado e fortalecedor que seja apreciado pelo usuário e de confiança da TI.
Esta é a próxima evolução de todos os produtos da Microsoft que você já usa há anos: Windows, Office, Active Directory, ConfigMgr, e migramos todos para a nuvem com o Microsoft 365. Clientes corporativos de todo o mundo estão migrando para a nuvem (consumindo o Windows 10 como um serviço, o Office 365 e os serviços do EMS). Essa é a próxima evolução natural da arquitetura do ConfigMgr.
Atualmente, quase todas as empresas e organizações comerciais do planeta começam a partir de um modelo local em que usam o Active Directory, a Política de Grupo e o ConfigMgr como ferramentas de gerenciamento. O desejo de mudar para um modelo mais simples e moderno é grande. No entanto, o acesso a esse modelo novo e moderno não tem sido fácil. Uma organização não pode simplesmente estalar os dedos e migrar usuários/dispositivos do AD/PG/ConfigMgr para o AAD/Intune. Era preciso que fornecêssemos uma ponte para simplificar e acelerar essa migração, além de remover riscos. Esse é o tipo de área em que aprendemos muito observando a mudança das organizações do Exchange local para o Exchange Online.
No momento, estamos animados em anunciar o cogerenciamento, um novo conjunto de funcionalidades que ajudarão a acelerar a mudança para o gerenciamento moderno a partir da nuvem. Com o Fall Creators Update, um dispositivo com Windows 10 pode ingressar no Active Directory (AD) e no Azure AD ao mesmo tempo.
O cogerenciamento aproveita essa melhoria e possibilita que o dispositivo seja gerenciado pelo agente do ConfigMgr e pelo MDM do Intune. A mudança para o gerenciamento moderno já não é uma ameaça. Com o cogerenciamento, você pode fazer sua própria jornada, passo a passo, até a nuvem de uma maneira e em um ritmo que faça sentido para sua organização.
Simplificamos o trabalho no console do ConfigMgr para colocar os dispositivos em gerenciamento e inscrevê-los no gerenciamento com o Intune. Em seguida, você escolhe a primeira carga de trabalho que deseja mover para a nuvem (literalmente uma barra deslizante que você move do ConfigMgr para o Intune) e essa carga de trabalho é movida para a nuvem.
Uma das funcionalidades exclusivas do Microsoft 365 neste cenário cogerenciado é que o ConfigMgr e o Intune estão em constante comunicação. Conforme as cargas de trabalho são movidas, entendemos quem é a fonte autorizada (Intune ou ConfigMgr) para cada atributo em usuários e dispositivos, evitando o conflito de políticas em aplicação.
Isso acelerará drasticamente a migração para o Windows 10 e o gerenciamento moderno a partir da nuvem.
* * * * *
Escrever esse artigo foi um incrível retorno ao passado para mim. O SMS/ConfigMgr/Intune afetou profundamente a minha vida, a vida de minha família, a vida de milhares de engenheiros que trabalharam nos projetos e as vidas de milhões de profissionais de TI que usaram e continuam a usá-lo atualmente. Adoro esse produto e essa comunidade.
Também gostei muito de ver o documentário de hoje sobre a história da criação do ConfigMgr. Mas essa é só a Parte 1! A Parte 2 é muito mais importante. A Parte 2 será criada por você.
Se você estiver no Ignite, visite a seção de gerenciamento e segurança do estande da Microsoft e conte sua história. Confira instruções aqui.
Mesmo que você não esteja no Ignite, participar é muito fácil. Conte sua história enviando suas memórias e suas histórias sobre o ConfigMgr aqui aka.ms/ConfigMgr25. Veja algumas instruções básicas.
Usaremos essas inscrições para criar a Parte 2, um vídeo que queremos de chamar de:
“The People’s History of ConfigMgr”
Mal posso esperar para assisti-lo.
_______________________________________________
