Customers often will ask "How does Microsoft do it?" and, when it is related to ConfigMgr and Intune, we are often the folks to provide that input. Now, we all have day jobs running this complex environment, so stopping to talk about it separately to every customer, while fun, would not be very productive for us. We do some such engagements when we can, but the hope is that we can take some of our learnings and share them more broadly through this blog. Time will tell how well we do at that. I know we have a few awesome posts lined up already that we think will be useful to some of you. As you watch this space I hope we are able to provide you some interesting things to consider and think through as you do your own implementations of ConfigMgr and EMS. We have a coming blog post about configuring WSUS in Azure for high availability as well as some other work on WSUS for Business, Conditional Access, and moving our infrastructure to be hosted in Azure that we hope to blog about in future posts.
To get things started, and as a foundation for future blog posts, let me give a brief overview of our current environment. We currently manage over 400,000 devices and around 290,000 users. We do this with a Central Administration Site (CAS), 6 primary sites, and 12 secondary sites spread around the globe. One primary site is used to handle our Mobile Device Management (MDM) devices that come through our Hybrid Intune integration, while the rest are for typical on-premises device management. We do operating system deployments, software distributions, software updating, compliance settings, mobile device management, and much of what all of you do out there.
Some things we do a little differently, and while we try to stick to the best practices as outlined by the development team, the reality is that "best" does not equal "only". Occasionally we must break from those best practices to reach the end goals we want to reach. In those cases, we are often in close discussion with the developer folks (they are in the same building, you know) and providing feedback on why we need to take a different path. Sometimes we differ because of a unique need or situation, sometimes because the dev team has different priorities at that moment as they must think about what is best for ALL customers and we, well, we only care about ourselves. 🙂
Hopefully this blog series will be useful to many of you out there. Please keep reading and commenting, and we will try to keep providing useful insights to you.