Today I'm sharing the details of a recent update our team released for the Windows Autopilot with co-management service. Windows Autopilot is a Microsoft cloud service that provides your organization's IT a completely hands-free, zero-touch experience for deploying new devices. Devices can be shipped directly from the hardware vendor to your employees without the need to manually setup new devices or reimage the device before delivering it to users.
This new setting can be found on the "Windows enrollment" page as shown here:
Why co-management?
As organizations embrace Microsoft 365 and Microsoft Intune, the need for device security and compliance is at an all-time high and is a top concern for all businesses. Microsoft therefore recommends that organizations still working with on-premises management solutions co-manage their endpoints. When you use co-management with Windows Autopilot together, you can make sure that new devices entering your network end up in the same state of management.
As organizations have transitioned from on-premises device provisioning to cloud provisioning with Windows Autopilot, however, they have brought two things to our attention related to compliance:
- Delays in compliance evaluation
- Delays in workload configuration
Referred to within Microsoft as "flip-flop", this delay and shift in workloads can impact organizations during , or even outside of, Autopilot provisioning, especially if they are layering in conditional access policy to measure compliance.
Managing authority settings
Now that you have a small subset of history, let's talk about what we did to resolve this flip-flop.
Your endpoints enrolled in Intune today have a concept of management authority. That authority tells the device what service owns the management of the workloads on that device. The authority owner can be tracked by a simple registry key and value.
[ HKLM\SOFTWARE\Microsoft\DeviceManageabilityCSP\Provider\MS DM Server ]
When provisioning a device with Autopilot, the above key gets created right after you enter your username and password on the enrollment screen. This key tells the device who the authority is for workload management:
1 – Intune.
2 – Configuration Manager.
After you enter credentials in Autopilot. this key is created and set to 1. In simple terms, enrolling a device creates this key and sets it to a value of 1. This value can be managed if you configure the co-management settings policy, and comes down to how you configure the "Advanced" section of the policy:
- If you leave the "Advanced" configuration at "no," the value is set to 2.
- If you move the "Advanced" configuration to "yes," the value never changes because it was already set to 1 by default.
|
Note: On Windows 10 devices this registry key is NOT created therefor not configurable by this policy. We have no plans to backport this registry key creation to Windows 10 devices. If you need to this control the current recommendation is to upgrade to Windows 11. There are other outside-the-box methods you can explore none of these methods have been tested end-to-end. |
Added benefits
You do not have to only use the co-management settings policy with provisioning. This policy could also be used outside of provisioning with pre-existing devices in your estate. Just keep the device state in mind. With existing devices, make sure your policy configuration reflects your intentions. You can configure this with the PROVISIONTS property, so make sure you consider that when deploying the policy to existing devices and the end-user experience.
Another benefit of using this policy is, if you choose to have the policy install the Configuration Manager agent, it could also help repair broken agents in your estate, which brings up a question that is asked quite a bit: Where is the agent coming from?
Using this policy to install the agent is not as complex as it sounds. When a device gets the policy from this new configuration, and the policy instructs the agent to install, the device gets the BOOTSTRAP file from a secure deep link in downloads.microsoft.com. The deep link is then connected with the information you added in the "Client installation command line arguments" section.
The binaries for the agent are retrieved from your cloud management gateway (CMG). We only use the bootstrap to point to the CMG. This means we get the binaries for your version of the agent, not some random version Microsoft is forcing you to install.
Another hidden value
If your organization has complex applications, you can also add a property in the above command line "PROVISIONTS." When the device gets to the "Device Setup" phase of the ESP (Enrollment Status Page), the task sequence called from on-premises will run and be tracked as one application. For the sake of clarity, if your task sequence installs 10 applications, the ESP will still track the task sequence as one app, because it is watching the task sequence, not each item in the task sequence.
Still want to use the supported MSI line-of-business (LOB) deployment if you choose to install the Configuration Manager agent using MSI LOB deployment? Here's what to keep in mind.
If you choose configuration A shown above, the expectation should be:
- Intune is the authority.
- All workloads are managed by Intune.
- Authority value will be 1.
If you choose configuration B shown above, the expectation should be:
- Configuration Manager will be the management authority.
- Workload management will come from Configuration Manager.
- Make the Configuration Manager agent installation "required" as part of the ESP profile.
Remember, the key defaults to the value of 1. Your authority is still going to be Microsoft Intune, and you will not experience the previous flip-flop issue. If you want the authority to be Configuration Manager, so you can choose which individual workloads come from Configuration Manager or Microsoft Intune, make sure the "Advanced" slider is set to "No." That will make the value become 2 and configuration manager sliders come into effect at that point.
Anytime the "Advanced" selection is "no" during provisioning, the ESP is expecting the Configuration Manager agent to be installed, so make sure your packaged agent is set as a required application in the ESP profile. Not configuring this way will result in a failure, leaving you stuck on a screen that looks like this:
Thanks a bunch for your time. We hope this feature assists you in your journey to the cloud and maintaining security and compliance on your device.
Have questions? Please leave them in the Comments below or find me on Twitter @sccm_avenger.