Everything can be done automatically, as long as you configure it manually :-)
Good news everyone! The feature was introduced at Ignite earlier this year and now it’s finally here. Windows AutoPilot now allows you to join your Windows 10 v1809 devices to your on-premises Active Directory (Hybrid Azure AD Join). All the magic lies in a new Intune connector for Active Directory. Sounds exciting, right? This will be everything you need to know, on how to get started with this new amazing feature.
Last week I blogged about how to get properly started with Windows AutoPilot. This week I’m continuing on the topic, and going into details on how you can deploy the SCCM (System Center Configuration Manager) client as a part of the Windows AutoPilot enrollment and thus achieve Co-management with SCCM and Microsoft Intune.
I have previously blogged a lot about Co-management. Focus here has been enrolling devices already managed by SCCM into Intune MDM.
This post is the opposite. This time we are deploying a device through Windows AutoPilot, enrolling it into Microsoft Intune and then deploying the SCCM client through the Cloud Management Gateway. Sounds interesting? Read on 🙂
It’s time for me to take on a new topic on the blog. I have been experimenting, working and blogging a lot about SCCM, Intune and Co-management, but never really touched base with Windows AutoPilot. Time is due and this will be the first in a series of posts about Windows AutoPilot and how to eventually reach Co-management with SCCM and Microsoft Intune through Windows AutoPilot.
First things first though. This post will give you everything you need to know on how to properly get started with Windows AutoPilot. Curious? Read on 🙂
Not going to do a great introduction on this one, but I think it deserves a mention anyway (I couldn’t find the situation or error explained elsewhere). More specifically, this is about an error I encountered myself in a Co-management scenario, where the computer fails the auto enrollment into Intune MDM. Let’s dig in 🙂
More Configuration Manager 1806 and more awesomeness. 1806 gives us additional improvements to the Cloud Management Gateway and removes the need for PKI in your environment. With these improvements, it has never been easier to setup the CMG. In this post I will walk you through the exact steps I went through in order to successfully deploy the CMG in a HTTP only environment.
Again, continuing the Co-management and flipping the switch journey, and moving the brand new Device Configuration workload to Intune MDM. This is the latest addition to the co-management world introduced in Configuration Manager 1806 (released 2 days ago at time of writing) and it’s absolutely amazing.
This means we finally (almost) can ditch group policies altogether and do our device configurations with Intune MDM. I will give you how to and an excellent example in this post. Read on. 🙂
Continuing on the Co-management and flipping the switch journey. I have previously been going through how to initially enable Co-management with Configuration Manager and Microsoft Intune, and how to move some of the Endpoint Protection workloads to Intune MDM.
This time I will walk you through how I moved the Software Updates workload from Configuration Manager to Intune MDM. Everything still based on a production environment and along the lines some additional ramblings on the topic.
Last week I gave an example on how to leverage Microsoft Intune and Conditional Access to restrict access to Exchange Online for iOS devices. This week, I’m continuing the use of Microsoft Intune and Conditional Access, and will give an example on how to restrict access to company e-mail if not using a Windows 10 1803 device. All of this based on a computer co-managed with both Microsoft Intune and Configuration Manager.
So basically; no e-mails if not running on the latest and greatest version of Windows 10 on my co-managed device.
Continuing the Co-management journey from last week, where I went through the steps required to setup co-management with Configuration Manager. This week I’m moving the Endpoint Protection workloads into Intune MDM. The ability to transition the Endpoint Protection workload is brand new, and became available in Configuration Manager 1802. As of now, the endpoint protection workload consists of following features:
Following walkthrough is exactly how I moved some of the Endpoint Protection features (more specifically Exploit Guard and some modifications to the Defender Security Center) into Intune MDM for at pilot group consisting of computers.
Co-management! It was announced last year at Ignite in Orlando and it’s being pushed heavily these days by Microsoft. For those who don’t know the ups and downs, co-management is basically (for those using ConfigMgr already) managing computers with both a Configuration Manager client and Intune MDM.
There are different possibilities to achieve co-management. It may sound complicated, but it’s not. I will walk you through the few steps required, as well as cover the precise prerequisites and how to troubleshoot issues if any. Note: This is precisely how I have done in a production environment. Curious? Read on 🙂
