ConfigMgr @ 25

Alla fine della settimana scorsa, ho scritto un articolo sul 25° anniversario di ConfigMgr e oggi vorrei raccontare la storia dietro questo prodotto incredibile, fare un paio di annunci e lanciare uno straordinario nuovo documentario (Sundance) che offre un approfondimento sulla genesi e sullo sviluppo del prodotto che ha creato il settore relativo alla gestione del PC.

Quindi, l’annuncio di ConfigMgr:

Tenendo presente questa pietra miliare di oggi, ecco una storia che potreste non aver mai ascoltato prima:

L’inizio di tutto

Alla fine della settimana scorsa, ho colto l’occasione per rileggere il documento o la “specifica” sulla visione originale del progetto denominato Hermes. Era da diversi anni che non mi capitava di leggere questo documento, ed è stato sensazionale rendermi conto di quanto ConfigMgr fosse rimasto fedele all’idea iniziale. Le basi descritte in quel documento vengono usate ancora oggi e sono tuttora le colonne portanti di questo prodotto.

Nel 1992, la missione originale di Microsoft (ovvero, la presenza di un PC in ogni casa e su ogni scrivania) si stava concretizzando. Le organizzazioni stavano passando rapidamente dall’emulazione terminale al modello di calcolo distribuito x86 e non c’erano soluzioni per gestire i PC su larga scala. Il team sapeva che il progetto Hermes doveva essere di forte impatto.

Il team SMS originale era costituito da due sviluppatori a tempo pieno e da uno stagista di nome Ken Pan.  Quando mi sono unito al team nel 2003, Ken lo stagista era a capo dell’intero team di sviluppo formato da circa 150 ingegneri. Da allora, Ken guida gli ingegneri per i progetti di SCCM e Intune per me!

Curiosità:  la primissima build di Systems Management Server (SMS) è stata la 245. Perché non 1? Beh… all’epoca Windows era alla build 300 e il team non voleva sembrare troppo indietro rispetto a quella versione, ma sapeva che non poteva scegliere un numero che si avvicinasse troppo a 300 per non destare sospetto. Ecco perché ha scelto il numero 245!

SMS è stato lanciato ufficialmente il 7 novembre 1994. Quel primo rilascio richiese circa due anni di lavoro, e pensare che oggi pubblichiamo nuove build per il programma Insider ogni mese!

In seguito al lancio del prodotto, c’è stato un momento indimenticabile: Bill Gates inviò un’e-mail a tutti i dipendenti Microsoft spiegando che SMS stava per essere distribuito a livello aziendale. Tra l’altro, in quell’e-mail Bill spiegò come rimuovere il software SMS dal computer se necessario. (:

Se ti interessa, ho incluso la sua e-mail alla fine di questo post.

Sviluppo dell’architettura

Le versioni 1.0, 1.1 e 1.2 di SMS sono state tutte rilasciate piuttosto rapidamente dando vita a un nuovo mercato. Senza alcun ritardo, il team ha quindi iniziato a lavorare su SMS 2.0.

È a quel punto che le cose si sono… complicate.

E, ad essere sinceri, abbiamo fatto alcune scelte sbagliate. Una parte importante della mentalità orientata alla crescita consiste nella capacità di imparare velocemente: questa è stata la vera essenza del team SMS fin dall’inizio.

Era cambiato così tanto nell’architettura originale delle applicazioni client/server dal 1992 che il team ha praticamente riscritto l’infrastruttura del server SMS nel 1997 e nel 1998 per ottimizzare la scalabilità e le prestazioni di SMS, aggiungendovi anche le funzionalità di Windows Server 2000. Era la prima volta che l’architettura di SMS veniva riscritta per garantire che fosse la tecnologia più avanzata del momento.

Rilasciato a gennaio nel 1999, l’adozione e l’utilizzo di SMS 2.0 accelerarono notevolmente. In quel periodo, lavoravo per il maggior concorrente di SMS, Novell, dove ero a capo del team Novell ZENworks. Ho perso il conto di quante riunioni ho fatto con i clienti di SMS per illustrare le peculiarità di ZENworks, che si concentrava sugli utenti (identità) con l’integrazione della directory!

Scrivendo questo post, mi è venuto in mente che SMS 2.0 conteneva un easter egg. L’easter egg era un video che mostrava i nomi e le foto delle persone che avevano lavorato al prodotto e, quando l’ho riguardato questa settimana, ho notato un nome in particolare:

Terry Myerson, il mio capo ed Executive Vice President di Microsoft. Credo che tutti i grandi abbiano avuto a che fare con SMS a un certo punto della loro carriera.  (:

Sono entrato nel team di SMS proprio quando ci si stava dedicando a quello che sarebbe diventato SMS 2003.

SMS 2003 includeva delle porzioni importanti del prodotto che, di nuovo, erano state riscritte. In quel momento, fare in modo che SMS fosse allineato a WSUS per l’applicazione di patch ha rappresentato un risultato importante. Ha permesso di allineare l’applicazione di patch di Microsoft dal cloud (Windows Update) agli ambienti consumer ed Enterprise. Fondamentalmente, WSUS sfrutta gli stessi bit che vengono usati per Windows Update, tranne per il fatto che viene eseguito nel data center.

Windows Update è uno dei servizi cloud più grandi al mondo, aggiornando più di 1 miliardo di dispositivi ogni mese. Rifletti un minuto su questo:  Alcune delle peculiarità principali che contraddistinguono Microsoft nel cloud pubblico oggi sono le nostre funzionalità ibride e la possibilità che hanno gli utenti di eseguire il nostro cloud pubblico nel proprio data center. La possibilità di eseguire Windows Update nel data center (WSUS) degli utenti è stata una soluzione letteralmente rivoluzionaria, forse il primo esempio di integrazione tra un ambiente connesso al cloud e ibrido. In quel periodo l’uso del portatile si stava diffondendo rapidamente e dovevamo creare un nuovo client che funzionasse in un modello disconnesso o poco connesso.

Mentre ci avvicinavamo al rilascio di SMS 2003, ogni venerdì mattina ci riunivamo con un gruppo di persone di vari reparti dell’azienda per valutare lo stato del progetto. Uno dei gruppi principali invitati a queste riunioni era quello del reparto Microsoft IT (MSIT). Con una mossa senza precedenti nella storia dell’azienda, ho concesso al team IT l’autorità di veto sul rilascio di SMS 2003 qualora pensasse che il prodotto non fosse ancora pronto. Da quel momento, MSIT è stato il nostro primo e miglior cliente, nonché una delle nostre fonti di feedback più importanti in merito alle build.

Oggi, gestiamo oltre 500.000 PC e dispositivi mobili presso Microsoft (questo numero non è incluso nei 100 milioni di dispositivi attivi ogni mese) attraverso un’unica distribuzione di ConfigMgr. Distribuiamo sempre nuovi bit in Microsoft mentre sviluppiamo ogni rilascio mensile. Praticamente usufruiamo degli stessi prodotti che sviluppiamo. Un’altra curiosità:  attualmente, il mio team supervisiona la distribuzione interna di ConfigMgr. Non c’è modo migliore per imparare se non dalla pratica!

Tra il 2003 e il 2007, abbiamo rilasciato due “Feature Pack”. Non volevamo aspettare il rilascio di un nuovo prodotto per offrire nuove funzionalità, così abbiamo dato vita a questo nuovo modo di rilasciare le funzionalità. Il primo Feature Pack si è concluso con l’allineamento a WSUS per l’applicazione di patch. Il secondo Feature Pack è stato quando abbiamo rilasciato Distribuzione del sistema operativo.

Uno dei ricordi di quel periodo a cui sono più legato riguarda una demo che avevamo preparato per un evento in Europa a novembre nel 2003 in cui dovevamo presentare le nuove funzionalità di Distribuzione del sistema operativo. Bill Gates stava illustrando i concetti chiave e, durante il suo intervento sulle novità di SMS, abbiamo aggiornato in tempo reale 100 PC fissati a una parete alle spalle di Bill. Abbiamo chiamato questa demo “Wall of Fire” (“muro di fuoco”).

Ecco una foto che abbiamo fatto a Bill quando si è girato per vedere la demo in esecuzione:

Ecco una foto degli audaci membri del team SMS che avevano preparato la demo:

Fare la differenza

Nell’autunno del 2004, Bill e Steve organizzarono una riunione fuori sede con alcuni dei senior leader dell’azienda; la giornata si concluse con una sessione di domande e risposte con Bill e Steve.  Qualcuno chiese a Bill quale fosse “la cosa più importante avvenuta per Microsoft nell’ultimo anno”. Bill rispose: “Abbiamo creato SMS e Active Directory, che saranno delle risorse fondamentali per la nostra crescita.”

Fino ad oggi, quello è stato uno dei giorni più belli nella mia carriera professionale!

Nel 2007, abbiamo cambiato il nome di “SMS” in “ConfigMgr” per allinearlo al marchio di System Center. Desired State Configuration (DSC) era lo scenario più innovativo che volevano i clienti, quindi abbiamo di nuovo modificato l’architettura per far sì che DSC funzionasse come previsto. Inoltre, abbiamo completamente riscritto l’esperienza amministrativa.

A febbraio nel 2011, quando eravamo a metà strada nello sviluppo di SCCM 2012, Satya assunse il controllo di Server and Tools Business (STB), lo rinominò Cloud and Enterprise (C+E) e diventò il mio capo. Per la nostra prima riunione di persona, Satya si presentò nel mio ufficio e cercò di conoscermi meglio a livello personale. È stata un’esperienza incredibile lavorare direttamente per Satya per diversi anni, ho imparato molto dalla sua straordinaria curiosità innata, dalla sua mentalità orientata alla crescita e dalla sua umiltà rispetto alla leadership. Satya ha avuto un impatto incredibile sul futuro e sull’architettura di ConfigMgr durante questo rilascio.

In ConfigMgr 2012, abbiamo praticamente rivoluzionato il prodotto concentrando l’architettura e l’esperienza sugli utenti, non solo sui dispositivi.

Secondo i feedback dei clienti, la mobilità sarebbe diventata fondamentale in futuro, non solo per quanto riguarda i dispositivi, ma anche a livello umano.  Di conseguenza, abbiamo notevolmente snellito l’architettura per ridurre l’hardware necessario e abbiamo aumentato i limiti relativi alla scalabilità in modo significativo. È a questo punto che il nostro viaggio verso il cloud è davvero entrato nel vivo; abbiamo connesso ConfigMgr a Microsoft Intune e, in sostanza, Intune è diventato la rete perimetrale di ConfigMgr.

Questa configurazione ibrida si è trasformata nel modello che ci ha permesso di modernizzare il cloud, per poi dare nuovo valore a ConfigMgr locale tramite la distribuzione ibrida. Credevamo che il cloud avrebbe consentito scenari che sarebbero stati impensabili in passato; Satya era riuscito a vedere l’impatto potenziale del cloud per la gestione dei dispositivi e ci spinse a fare innovazioni ed esperimenti in questo ambito.

Verso il cloud con ConfigMgr

L’evoluzione dell’architettura successiva è stata di gran lunga la più impegnativa.

Quando ci siamo resi conto che Windows 10 sarebbe stato reso disponibile come servizio con più aggiornamenti ogni anno, abbiamo capito che ConfigMgr avrebbe dovuto fare lo stesso e passare al cloud.

Era una sfida a dir poco ambiziosa.

Storicamente, gli aggiornamenti di ConfigMgr venivano rilasciati ogni 2-3 anni. Ricordo ancora il primo piano completo per SCCM 2007 e l’attesa di 16 mesi di stabilizzazione e versione beta nel periodo tra l’annuncio del completamento del codice e il rilascio. 16 mesi!   Era chiaro che dovevamo rendere ConfigMgr un software come un servizio, quindi avremmo dovuto garantire la pubblicazione di rilasci diverse volte l’anno.

Dovendo affrontare una sfida così impegnativa, abbiamo selezionato un piccolo team di ingegneri e program manager esperti di ConfigMgr, con una mentalità orientata allo sviluppo e una grande passione.  Eravamo convinti che l’unico modo per portare a termine la nostra missione fosse la creazione di un piccolo team di esperti che revisionasse l’intera architettura e sviluppasse un servizio fornito mediante il cloud proprio dal cloud.

Guardando le nostre tempistiche per questo tipo di revisione, devo ammettere che il mio solito ottimismo fece spazio anche a un leggero scetticismo. Finire tutto così velocemente era qualcosa di impensabile.

Il risultato, ora, è ovvio:  questo team di ingegneri super concentrati ha superato ogni singolo standard di riferimento e ha mostrato un nuovo approccio basato sul cloud per la gestione dei PC che ci ha permesso di passare a un ciclo di rilasci mensili. Per tenere traccia di questi aggiornamenti, abbiamo eliminato i numeri di versione tradizionali (ad esempio, 2003, 2007, 2012) e abbiamo iniziato a denominarli con una convenzione anno/mese; così, il primo rilascio è stato la versione 1511 perché risale all’11^° mese del 2015.

Da allora, abbiamo pubblicato una nuova versione per Insider di ConfigMgr ogni mese e i rilasci principali di CurrentBranch ogni ~4 mesi.

Senza alcun dubbio, questo è uno dei progetti tecnici più incredibili a cui abbia mai partecipato.

La risposta dei clienti a questo nuovo modello fornito mediante il cloud è stata straordinaria.

Dai un’occhiata a questo grafico:

Poco più della metà della base di ConfigMgr ha già eseguito l’aggiornamento al nuovo modello Current Branch e al momento ci sono più di 100 milioni di dispositivi che vengono gestiti attivamente e che restituiscono dati di telemetria.

Il Sacro Graal dei 100 milioni!!!!

A quanto ne sappia, esistono solo 3 servizi aziendali al mondo con più di 100 milioni di utenti attivi o dispositivi in gestione e che restituiscono dati di telemetria ogni mese:  Office 365, Azure Active Directory e ConfigMgr. Cosa hanno in comune questi tre servizi?  Fanno tutti parte dell’offerta di Microsoft 365 integrata.

Questo grafico mostra l’adozione dei rilasci principali Current Branch di ConfigMgr dalla versione 1511. Abbiamo una dashboard che ci fornisce questi dati in tempo reale e inviamo questo grafico al nostro intero team ogni domenica mattina alle 8:30.

Sono sincero quando dico che la domenica mattina alle 8:30 è uno dei miei momenti preferiti della settimana.

Questo è l’aggiornamento più veloce in assoluto per ConfigMgr e si può notare che con ogni rilascio il tasso di adozione (la linea inclinata da sinistra verso destra) aumenta sempre più rapidamente e in modo esponenziale. All’inizio, non sapevamo come avrebbe reagito la community di ConfigMgr a dei rilasci così veloci e siamo onorati dell’immensa fiducia che hanno avuto in noi.

Non c’è mai stato prima un interesse così grande per il progetto Hermes.

Prossime novità

Abbiamo iniziato il nostro viaggio verso il cloud con la versione 1511 Current Branch di ConfigMgr a novembre del 2015 e già all’epoca sapevamo che sarebbe stato un passaggio fondamentale per il nostro progetto. Sapevamo anche che c’era ancora molto da fare.

Il ritmo dell’innovazione a partire dalla versione 1511 è solo accelerato. Le organizzazioni stanno passando rapidamente all’uso di servizi cloud connessi ai dispositivi mobili e, per assisterle in questa transizione verso un mondo in continua e rapida evoluzione, l’infrastruttura di ConfigMgr ha fatto degli enormi passi avanti per diventare un autentico servizio cloud. Ora è un servizio che viene continuamente aggiornato con nuove funzionalità, sfrutta l’IA del cloud per adattarsi alle esigenze degli utenti e offrire loro la protezione necessaria ed è disponibile come servizio basato sul cloud in grado di offrire la scalabilità per centinaia di milioni di dispositivi in tutto il mondo.

Tutto questo mi fa ripensare alla cosa più comune che ho sentito dire dai leader IT a livello mondiale:  sono frustrati dalla complessità che devono affrontare insieme ai loro team per portare a termine il loro lavoro. Le organizzazioni stanno cercando dei modi per semplificare le soluzioni che hanno distribuito e vogliono uno strumento unico per la gestione e la protezione dei loro utenti su tutti i dispositivi. Ecco perché abbiamo creato Microsoft 365.  M365 fornisce un’area di lavoro sicura e moderna e servizi cloud integrati che aumentano la produttività degli utenti. È stato sviluppato per fare in modo che l’IT garantisca un ambiente di lavoro efficace e stimolante, apprezzato dagli utenti e considerato attendibile dai professionisti IT.

È l’evoluzione di tutti i prodotti Microsoft classici (Windows, Office, Active Directory, ConfigMgr), che abbiamo provveduto a spostare sul cloud con Microsoft 365.  I clienti delle aziende di ogni parte del mondo stanno eseguendo la migrazione al cloud (usando Windows 10 come servizio, Office 365 e i servizi EMS): questa è l’evoluzione naturale dell’architettura di ConfigMgr.

Quasi tutte le organizzazioni commerciali e aziendali sul pianeta stanno iniziando da un modello locale in cui si avvalgono di Active Directory, Criteri di gruppo e ConfigMgr come strumenti di gestione. Il desiderio di passare a un modello semplificato e più moderno è forte, ma realizzarlo non è affatto semplice. Un’organizzazione non può trasferire utenti/dispositivi da AD/Criteri di gruppo/ConfigMgr ad AAD/Intune con uno schiocco delle dita. Ha bisogno che le mettiamo a disposizione un ponte che renda questa transizione più facile, veloce e meno rischiosa. Si tratta di un’area in cui abbiamo acquisito una certa esperienza osservando le organizzazioni nel passaggio da Exchange locale a Exchange Online.

Oggi, siamo entusiasti di presentare Co-gestione, una nuova serie di funzionalità che farà da ponte accelerando il passaggio dal cloud alla gestione moderna. Grazie all’aggiornamento Fall Creators Update, è possibile aggiungere i dispositivi Windows 10 ad Active Directory (AD) e Azure AD in locale contemporaneamente.

Grazie a questo miglioramento, i dispositivi possono essere gestiti sia dall’agente di ConfigMgr che da Intune MDM. Il passaggio alla gestione moderna non è più un salto nel vuoto. Grazie alle funzionalità di co-gestione, puoi scegliere la strada da seguire per passare al cloud nel modo e nei tempi più adatti alle esigenze della tua organizzazione.

Abbiamo semplificato l’uso della console di ConfigMgr per gestire e registrare per la gestione i dispositivi con Intune. Puoi selezionare il primo carico di lavoro che desideri trasferire sul cloud (è presente una vera e propria barra di scorrimento da spostare da ConfigMgr a Intune) e quel carico di lavoro passa nel cloud.

Una caratteristica peculiare di Microsoft 365 in questo scenario di co-gestione è la costante comunicazione tra ConfigMgr e Intune. Durante lo spostamento dei carichi di lavoro, Microsoft 365 identifica l’origine autorevole (Intune o ConfigMgr) per ogni attributo su utenti e dispositivi, evitando così l’applicazione di criteri in conflitto.

Questo fa sì che il passaggio dal cloud a Windows 10 e alla gestione moderna sia decisamente più rapido.

* * * * *

Per scrivere questo post, ho fatto un incredibile viaggio indietro nella memoria. SMS/ConfigMgr/Intune ha avuto un profondo impatto sulla mia vita, sulla vita della mia famiglia, sulle vite di migliaia di ingegneri coinvolti nei vari progetti e sulle vite di milioni di professionisti IT che lo usano da sempre. Adoro questo prodotto e questa community.

Ho trovato molto interessante il documentario di oggi sulla storia di ConfigMgr, ma questa è solo la prima parte. E la seconda sarà ancora più importante perché dovrai crearla tu.

Se sei all’evento Ignite, fermati alla sezione dedicata alla gestione e alla sicurezza dello stand Microsoft e raccontaci la tua storia. Ecco delle semplici indicazioni.

Se non sei all’evento Ignite, puoi dare comunque il tuo contributo. Racconta la tua storia caricando dei video sull’impatto che ConfigMgr ha avuto sulla tua vita qui aka.ms/ConfigMgr25. Ecco delle istruzioni facili.

Useremo questi video per creare la seconda parte, un video che vorremmo intitolare:

“La storia delle persone di ConfigMgr”

Non vedo l’ora di vederlo.

_______________________________________________