MMS 2018 Recap: A Day Life in the Life of an OSD Guru

At MMS, I presented a session with Johan Arwidmark called "A Day in the Life of an OSD Guru." Times certainly are changing, and unless you’ve been living under a rock, you know that the way operating systems are traditionally deployed is facing some challenges. Our session attempted to address those challenges by conveying how we think IT pros should handle deployments in their organizations and providing some forward-thinking ideas.

Policy Management
On-prem management by group policy, while still supported, is considered legacy. As an OSD guru, you need to be forward thinking when applying policy to a device. First, ideally, you should have a new OU for your Windows 10 devices and make sure you’re not trying to apply unsupported policies. If you can’t do that (typically for political reasons), at very least configure WMI filters on your policies so that a Windows 7 policy does not apply to a Windows 10 computer. While many of them are harmless, there are quite a few that can bite you.

Microsoft wants organizations to move to cloud management with Azure AD and Intune. This doesn’t mean ConfigMgr is going away. This is obvious by all the work we see around co-management and capabilities added to it with subsequent ConfigMgr Current Branch releases. That doesn’t mean you should sit on your hands and wait for the day, maybe 15 years from now, when traditional products are gone, and you make a panic move to the cloud. (Disclaimer: I do not have any information on the lifespan of ConfigMgr. I believe that if customers keep using it and keep asking for innovations/improvements, then the product team will continue their work. If you don’t believe me, start playing around with the Technical Preview builds.)

Since Microsoft is adding more and more MDM policies so that you can manage your devices from Intune, it is worth looking at what policies you are applying to your devices and if they are supported in MDM. You can use MMAT, a tool that helps transition from legacy group policy to MDM by analyzing policy applied to a device and providing a report that maps those policies to MDM, if they exist. The MMAT tool can be downloaded from the GitHub link, which includes instructions on prerequisites and use: https://github.com/WindowsDeviceManagement/MMAT.

It is also possible to create a custom CSP using an ADMX-backed policy. This means you could download the latest ADMX templates for Office and create an MDM policy for it. For information on how to do that, Microsoft has created a blog post and video that is easy to follow: https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies.

Patch Management

ConfigMgr offers patch management so that technicians can secure servers and workstations with the latest updates with greater control and under a single pane of glass. There are plenty of posts and sessions available talking about how to set up software updates, things to watch out for and various tips and tricks.
Intune also provides patch management with the ability to update via deployment rings. You simply create rings and add devices to them. Patch compliance and minimal reporting is available under a single pane of glass. Detailed reports will require Update Compliance. With deployment rings, technicians can:

Using Windows Update for Business group policy settings allows organizations to manage patches in rings using the normal Windows Update client. There is no reporting available outside of Update Compliance, which requires telemetry data to be sent to the OMS cloud platform.

Deployment

Now for the fun part of the session. Intune has brought changes that lead many spectators and keyboard warriors to believe that this is the beginning of the end for ConfigMgr. Traditional deployment looks something like this:

This will continue to work well for organizations that are infrastructure-heavy because they can use traditional or third-party methods to manage the content transfer as well as deployment method. This does not work well for organizations lacking infrastructure, or those wanting to reduce infrastructure. I once worked for a very well-established global architecture firm that wanted to remove all dependency on on-prem infrastructure--this is a thing companies are doing. Running a task sequence from the cloud can be very expensive because of compute, storage and network costs. What works in that scenario are the device reset features that Intune provides. With Intune, a technician can:

You can read about why Microsoft rebranded Automatic Redeployment to AutoPilot reset here: https://docs.microsoft.com/en-us/education/windows/autopilot-reset.

Looking back again at on-premises deployments, I need to address the argument of servicing versus task sequences for moving between versions of Windows. In general, I recommend the task sequence approach because it gives you so much control. That can be a very good thing in environments that are complex. Task sequences allow you to plan for failure and adjust accordingly. Task sequences also allow you to put in a pause to debug issues.

You can’t do that with servicing. Using servicing in ConfigMgr is allowing software updates features to move between versions. While there is no way to plan for failure or add pauses for debugging, it is a great option for a collection of machines with very little likelihood of failure. It also works well in environments where software updates are already working quite well and perhaps the team has little time for developing and testing sequences. The Windows team at Microsoft added in a ton of new features for Windows 10 1803 for deployment, including new DISM command line options that can possibly start paving the way for a switch from sequences to servicing. You can read about all the changes in this blog post: https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/What-s-new-for-IT-pros-in-Windows-10-version-1803/ba-p/188568.

Now, to answer the question, “Should I use sequences or servicing?” I say in general to use sequences until it stops making sense for your organization. If sequences add in too much complexity for creation, edits and troubleshooting, then perhaps servicing is your best option.

Looking Forward

For most organizations, it would be nearly impossible to make an immediate shift to the cloud. Many can’t simply because of privacy regulations. This post isn’t about arguing for or against governing policies, but it’s worth considering that some IT shops are governed by policies written for the industry by fairly non-technical individuals or organizations. They simply can’t move at light speed to new technology.

That is where the Cloud Management Gateway (CMG) and co-management fit very nicely into the picture. Technicians can shift certain workloads to cloud MDM via co-management that would traditionally be solely managed by ConfigMgr. CMG provides a means to manage ConfigMgr clients over the internet without the need for additional on-premises infrastructure or exposing the on-premises infrastructure to the Internet.

You can read about CMG and co-management from the following two links:
https://docs.microsoft.com/en-us/sccm/core/clients/manage/cmg/plan-cloud-management-gateway
https://docs.microsoft.com/en-us/sccm/core/clients/manage/co-management-overview

As workers become more mobile, cloud access is becoming a necessity. In poorly connected areas or places where VPN is blocked, it is difficult if not impossible for the ConfigMgr agent to call home. A Cloud Management Gateway or CMG removes the limitation by allowing the ConfigMgr clients on Internet-based networks to perform many of the normal actions. A CMG is not required for co-management, and co-management isn’t just for clients that roam. Both features lessen the likelihood that a device remains completely unmanaged.

This means that the argument stops being MDM vs ConfigMgr but rather, more of a question of which scenario is best for an organization. The end goal isn’t to shift from one technology to another in the blink of an eye--it’s for Microsoft to provide ways for organizations to efficiently manage devices in their entire lifecycle regardless of their geographic location. By cutting infrastructure and other IT costs where necessary, IT is free to spend time and money on other--dare I say--more interesting efforts.

Oh, and Writing!

While doing all this, Microsoft MVPs and OSD experts often share with the community. This includes writing blogs, books and e-books. Last week, I completed an e-book that leverages the expertise of many gurus in the community. If driver management in ConfigMgr gives you pain, you may find it helpful.

E-book
ConfigMgr Driver Management Primer: From Total Chaos to Total Control
Download here

Hopefully, this post provides some insight into the balancing act of an OSD guru. There are many changing parts and different fits for each organization. Fortunately, when you attend conferences like MMS, you can spend time with your peers learning new things and assessing whether your current plans are working for your organization.