This post has been republished via RSS; it originally appeared at: Device Management in Microsoft articles.
First published on TECHNET on Mar 27, 2017
Hello there, blog readers. My Name is Michael Griswold. You may have read my personal blog (
https://learnconfigmgrintune.wordpress.com/) at some point. I’m now on a team that is part of Enterprise Client and Mobility (ECM) group here at Microsoft. ECM is what many people would call the “product group” for System Center Configuration Manager (ConfigMgr) and Microsoft Intune. My specific team is in charge of the primary ConfigMgr and Intune service for supporting Microsoft employees. We are restarting our team blog with contributions coming from all the various team members. Things have been quiet here but we hope to add back some energy and good information to help all the various system center and Intune customers out there.
We are a unique service engineering team in that we are an extension of the Configuration Manager development team, implementing ConfigMgr and Intune services in the large and complex environment that is Microsoft. We work with developers and program managers to roll out and provide feedback on new features and functionality. We also work with Microsoft's IT group (MSIT) to support the business needs and changes that any large organization experiences. It is a fun and challenging situation as balance being on the cutting edge of new or not-yet-released technology with providing stability of services to all those who depend on us to do their daily jobs.
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.
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.
Setting the stage
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.
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.