ConfigMgr at 25

September 26, 2017

Azure

Late last week, I wrote about the remarkable quarter-century milestone reached by ConfigMgr, and today I wanted to dive even deeper into the backstory of this incredible product, share a couple announcements, and debut an awesome new documentary (lookout Sundance!) which offers an in-depth look at the genesis and growth of the product that created the PC Management industry.

Next, the ConfigMgr announcement:

And with this present-day milestone in mind, here’s a story you may not have heard before:

How It All Began

Late last week, I took the opportunity to re-read the original vision document or “spec” for Project Hermes. I hadn’t seen this doc in several years, and it was amazing to see how true ConfigMgr has stayed to that original vision. The fundamental building blocks outlined in that doc are still used today and are still part of its foundation.

In 1992, the original mission of Microsoft (aka, a PC in every home and on every desktop) was just hitting critical mass. Organizations were aggressively moving from terminal emulation to the x86 distributed computing model, and there was no solution to manage the PCs at scale. The team knew that Project Hermes had to be impactful.

The original SMS team was two full time developers and an intern named Ken Pan. When I joined the team in 2003, Ken the Intern was leading the entire dev team of about 150 engineers. Ken has led the engineering efforts on SCCM and Intune for me ever since!

Fun fact: The very first build of Systems Management Server (SMS) was 245. Why not 1? Well… Windows was on build 300 at that time and the team didn’t want to seem too far behind – but they knew that picking something too close to 300 would raise suspicion. So they picked 245!

SMS officially launched on November 7, 1994. That first release took a little over two years – today we release new insiders builds every month!

A big moment from that launch was an e-mail sent by Bill Gates to every Microsoft employee explaining that SMS was being deployed across the company. Ever the engineer, Bill pointed out in that e-mail how to remove SMS software from your machine if you were so inclined. (:

If you want to read that e-mail, I’ve included it at the bottom of this post.

Pushing the Architecture Forward

SMS 1.0, 1.1 and 1.2 were all released pretty quickly, and a new market was subsequently born. Without delay, the team then started working on SMS 2.0.

That’s when things got… complicated.

And, honestly, we made some poor decisions. A big part of the growth mindset is the ability to learn rapidly – this has been core in the SMS team from the beginning.

So much had changed in the architecture of how client-server applications were built since 1992 that the team essentially re-wrote the SMS server infrastructure in 1997 and 1998 to bring the scale and performance of SMS forward, and they also integrated with the upcoming capabilities of Windows Server 2000. This was the first time that the SMS architecture was rewritten to ensure it was the state-of-the-art for that time.

SMS 2.0 was released in January 1999, and the adoption and usage accelerated. At the time, I was working at SMS’s largest competitor, Novell, leading the Novell ZENworks team. I couldn’t possibly count the number of hours I spent meeting with SMS customers talking about the differentiators of ZENworks that were based in focusing on users (identities) with deep Directory integration!

While writing this post I was reminded that SMS 2.0 had an Easter egg in it. The Easter egg was a video showing the names and pictures of people who worked on the product, and, when I look another look at it this week, one name stood out:

Yup, Terry Myerson – my boss and the Executive Vice President of Microsoft. I guess all the greats really have passed through SMS at one point in their career. (:

I joined the SMS team just as efforts were ramping up for what would become SMS 2003.

In SMS 2003, there were significant portions of the product that were, again, re-written. A big milestone at the time was getting SMS aligned on WSUS for patching. This aligned the Microsoft patching from cloud (Windows Update) to consumers and the Enterprise. WSUS is essentially the same bits that are used for Windows Update – except running in your datacenter.

Windows Update is one of the world’s largest Cloud services – updating more than 1B devices every month. Think about this for a minute: One of Microsoft’s key differentiators in the public cloud today are our hybrid capabilities and the ability for you to essentially run our public cloud in your datacenter. Running Windows Update in your data center (WSUS) was really a pioneer and perhaps the earliest example of being cloud connected and hybrid. This was also the point in time when laptop usage had really accelerated, and we needed to build a new client that functioned in a disconnected or loosely connected model.

As we neared the release of SMS 2003, we would meet each Friday morning with a group from across the company to evaluate the status of the project. One of the key groups invited to that meeting was the Microsoft IT department (MSIT). In a move that had no precedent in the company, I granted the IT team veto authority over the decision to ship SMS 2003 if they did not feel it was ready. Ever since then, MSIT has been our first and best customer – as well as one of our best sources of feedback on early builds.

Today, we manage over 500,000 PCs and mobile devices here at Microsoft (this number is not included in the 100M MAD) through a single ConfigMgr deployment. We are constantly deploying new bits across Microsoft as we are building each monthly release. We definitely eat our own dogfood. Another fun cat: My team actually oversees the internal deployment of ConfigMgr. There is no better way to learn than by than doing!

Between 2003 and 2007, we released two “Feature Packs.” We didn’t want to wait for an entire new product to deliver new functionality, so we innovated this new way to release capabilities. The first Feature Pack finished up the work of aligning on WSUS for our patching. The second Feature Pack was when we released OS Deployment.

One of my favorite memories of this time was a demo we set up at an event in Europe in November 2003 to show-off the new OS Deployment capabilities. Bill Gates was delivering the keynote, and, during his section of “What Is New with SMS,” we live upgraded 100 PCs on a wall behind Bill. We called this demo the “Wall of Fire.”

Here’s a picture we took of Bill when he turned around to watch the demo execute:

Here’s a picture of the brave SMS team members that staged the demo:

Making an Impact

In the fall of 2004, Bill and Steve hosted an offsite meeting with a few of the senior leaders from across the company – and the final session of the day was open Q&A with Bill and Steve. Someone asked Bill what he thought was, “The most significant thing that has happened for Microsoft in the last year.” Bill responded: “We got SMS and Active Directory right – and they will be tremendous assets for us going forward.”

To this day, that is one of the best days of my professional career!

In 2007, we changed the name from “SMS” to “ConfigMgr,” in order to align it with the System Center brand. Desired State Configuration (DSC) was the newest innovative scenario that customers were requesting, so, once again, we evolved the architecture to really enable DSC to work the way it should. We also completely rewrote the administrative experience.

In Feb 2011, mid-way through the engineering of SCCM 2012, Satya took over the Server and Tools Business (STB), renamed it the Cloud and Enterprise (C+E), and became my boss. For our first 1:1 meeting, Satya came to my office and spent the bulk of the time really getting to know me better as a person. It was an incredible experience to work directly for Satya for several years and learn from his incredible, inquisitive nature, his growth mindset, and his humble-servant approach to leadership. Satya had a tremendous impact on the future and architecture of ConfigMgr during this release.

In ConfigMgr 2012 we essentially turned the architecture on its head by focusing the architecture and experience on users – not just devices.

Customers were telling us that mobility was going to be key in the future, and we understood that mobility was about the mobility of humans – not just devices. In response to this information, we dramatically flattened the architecture to require less hardware, and we massively increased the scale limits. This is where our journey to the cloud really, really got serious; we connected ConfigMgr to Microsoft Intune, and Intune essentially became the edge of ConfigMgr.

This hybrid configuration became the model that allowed us to innovate in the cloud, and then deliver new value to on-prem ConfigMgr via that hybrid deployment. We believed that the cloud would enable scenarios that would have been impossible in the past, and Satya could see the potential impact of the cloud for device management – and he really pushed us to innovate and experiment here.

ConfigMgr Heads to the Cloud

The next architectural evolution was the most challenging by far.

When we learned that Windows 10 would be delivered as-a-service with multiple updates delivered each year, we knew that ConfigMgr needed to follow suit and move to the cloud.

The challenge here was daunting.

Historically, ConfigMgr had released on a 2-3 year cadence. I remember looking at the first all-up plan for SCCM 2007 and seeing 16 months of stabilization and beta between the time we declared code-complete and the release. 16 months! It was clear we needed to “SaaS-ify” ConfigMgr so we could maintain a multiple-times-per-year release cadence.

With such a daunting task ahead, we set about hand-picking a small team of engineers and program managers who knew ConfigMgr deeply, had a growth mindset, and a shared a passion for this customer base. Our belief was the only way we could pull this off was for a small and focused team to overhaul the entire architecture and create a cloud-delivered service from the ground cloud up.

When I looked at our timetable for this overhaul, I will admit to having a bit of skepticism mixed in with my normal abundance of optimism. Getting things done this quickly was an unbelievable undertaking.

The outcome, now, is obvious: This hyper-focused engineering team exceeded every single benchmark and delivered a new cloud-based approach to PC management that allowed us to move to a monthly release cycle. To keep track of these updates, we did away with the traditional version numbers (e.g. 2003, 2007, 2012) and instead started naming them with a year/month convention; thus, the first release was versioned 1511 because we released it in the 11^th month of 2015.

Since then, we have released a new insider’s version of ConfigMgr every month, and major CurrentBranch releases every ~4 months.

This is – without question – one of the most incredible engineering efforts I have ever been a part of.

The customer response to this new cloud-delivered model has been incredible.

Check out this graphic:

Just over half of the ConfigMgr base has already upgraded to the new current branch model, and there are now more than 100M devices being actively managed and sending back telemetry.

Holy cow 100M!!!!

To my knowledge there are only 3 enterprise services in the world that have >100M monthly active users or devices under management and sending back telemetry: Office 365, Azure Active Directory, and ConfigMgr. What do these three things have in common? All are part of the integrated Microsoft 365 offer.

This chart shows the adoption of the major releases of ConfigMgr Current Branch since the 1511 release. We have a dashboard that shows us this data in real time, and we send out this chart to our entire team every Sunday morning at 8:30.

Believe me when I tell you that 8:30 on Sunday mornings is one of my favorite moments of every week.

This has been the fastest all-time upgrade for ConfigMgr, and you can see that with each release the rate of adoption (the slope of the line from left-to-right) gets faster and steeper. At first, we were a little nervous about how the ConfigMgr community would react to such fast releases – and we have been both amazed and grateful for your trust and confidence in us.

There has never been more interest in and passion for Project Hermes than there is right now.

What’s Next

We began the journey to the cloud with the 1511 release of ConfigMgr Current Branch in November 2015, and, at the time, it was clear to us that this was a major step towards where we needed to get. It was also clear to us that there was a lot more work to do.

The pace of innovation since 1511 has only accelerated. Organizations are rapidly moving to a world of cloud services connected to mobile devices, and, in order for us to deliver what you need in this accelerating environment, the ConfigMgr infrastructure has taken the big steps toward being a true cloud service. It is now a service that is continually updated with new capabilities, it utilizes the AI capabilities of the cloud to adjust to your needs and deliver the protection you require, and it is available to you as a cloud-based service that is able to scale to 100s of millions of devices around the globe.

All of this reminds me of the most common thing I hear from IT leaders all over the world: They are frustrated with the complexity they and their teams have to deal with in order to get work done. Organizations are looking for ways to simplify what they have deployed and they want a unified way to enable their users on all devices – that also delivers the management and security they need. This is why we have built Microsoft 365. M365 delivers the modern, secure workspace and integrated cloud services that enable users to achieve more. It has been engineered to enable IT to deliver that rich and empowering work environment that is Loved by User and Trusted by IT.

This is the next evolution of all of the products from Microsoft that you’ve been using for years – Windows, Office, Active Directory, ConfigMgr – and we’ve moved them all to the cloud with Microsoft 365. Enterprise customers around the globe are migrating to the cloud (consuming Windows 10 as-a-Service, Office 365, and the EMS services) and this is the natural next evolution of the ConfigMgr architecture.

Just about every enterprise and commercial organization on the planet is starting from an on-premises model today where they are using Active Directory, Group Policy, and ConfigMgr as their management tools. The desire to move to a simpler and more modern model is high, but getting to that new modern model hasn’t been easy. An organization can’t just snap their fingers and move users/devices from AD/GP/ConfigMgr to AAD/Intune. What you’ve needed from us is a bridge that makes this move simpler, faster and removes risk. This is an area where we learned a lot by watching organizations move from on-prem Exchange to Exchange Online.

Today, we are excited to announce Co-management, a new set of capabilities and the bridge that will help accelerate the move to modern management from the cloud. With the Fall Creators Update, a Windows 10 device can be joined to on-premises Active Directory (AD) and Azure AD at the same time.

Co-management takes advantage of this improvement and enables the device to be managed by both ConfigMgr agent and Intune MDM. The move to modern management is no longer a cliff where you have to jump. With co-management you can take your own journey, step-by-step, to the cloud in a way and at a pace that makes sense for your organization.

We’ve made it simple to work within the ConfigMgr console to take the devices under management and enroll them for management with Intune. You can then select the first workload you want to move to the cloud (it is literally a slider bar that you move over from ConfigMgr to Intune) and that workload is moved to the cloud.

One of the unique capabilities of Microsoft 365 in this co-managed scenario is that ConfigMgr and Intune are in constant communication. As workloads are moved, we understand who the authoritative source (Intune or ConfigMgr) is for every attribute on users and devices – and this avoids conflicting policies from being applied.

This will dramatically accelerate the move to Windows 10 and modern management from the cloud.

* * * * *

Writing this has been an incredible walk down memory lane for me. SMS/ConfigMgr/Intune has had a profound impact on my life, the life of my family, the lives of 1,000’s of engineers that have worked on the projects, and the lives of millions of IT Pros who have used and continue to use it today. I love this product and I love this community.

I have also really enjoyed seeing today’s documentary about the history of ConfigMgr come together – but it is only Part 1. And Part 2 is much more important. That’s because Part 2 is going to be created by you.

If you’re at Ignite, stop by the management and security section of the Microsoft booth and tell your story. Simple directions are here.

If you’re not at Ignite, taking part is still very easy. Tell your story by uploading your memories and your stories about ConfigMgr here aka.ms/ConfigMgr25. Here are some basic instructions.

We’ll use these submissions to create Part 2 – a video we’d like to call: