Co-management settings: Windows Autopilot with co-management
Published Sep 26 2022 01:40 PM 22.1K Views
Microsoft

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:

DannyGuillory_0-1664222992321.png

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.

DannyGuillory_1-1664222992325.png

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.

DannyGuillory_2-1664222992328.png

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.

DannyGuillory_3-1664222992329.png

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.

DannyGuillory_4-1664222992332.png

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:

DannyGuillory_5-1664222992344.png

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.

 

12 Comments
Copper Contributor

Has this configuration been updated to support Hybrid Azure AD deployment instances?   if not, is there a plan to?

We currently do this in a suedo way with a PSAppDeploy built package, and in which we even have a ProvTS happening.   But it is extremely messy.   it would be great to have this native for HAAD instances, as our company is still a few years from thinking of being cloud only. 

Steel Contributor

What about the scenario that we worked on Danny? I am still having to use a custom solution to flip the value of the registry to 2 for co-management to work against pre-provisioning method.

Microsoft

@Justin_Staples we have no plans to support hybrid at this time. 

@rahuljindal-MVP ping me 1:1 it’s been a while since we discussed and I could use the refresher. We don’t support pre-provisioning at the moment.

Copper Contributor

Hey Danny,

 

Is support for pre-prov on the roadmap?

 

Cheers

Paul

Brass Contributor

Danny, if we use the supported MSI line-of-business (LOB) CM Agent deployment described above, what's the official guidance with other Win32 apps?
From what MS has already documented we shouldn't mix LOB and Win32 apps. When using the Office installer wizard from MEM it installs as a LOB but seems to be managed by the IME agent when looking at the logs. Will this method for the CM agent coordinate installs with Office and other Win32 apps so they don't conflict with each other?

Microsoft

@sccmentor its on the list for us to investigate. How far we get execution depends on what the investigation turns up. 

 

@Daniel Davila In the official doc I called out not to use the MSI if you use this policy. Through testing and working with customers I found a corner case where some customers want Configuration Manager to maintain the ownership of the Authority there's some weird scripted install of the client. If that's your use case then you need to install the client, just know the orchestrated manner in which that install was going to happen you have chosen to break and the risk is that ESP could timeout because we don't know when the cm agent is going to install. @Daniel Davila if you need more then feel free to drop some time on my calendar https://bit.ly/dannygu  

Iron Contributor

Works like a charm - on our setup! ;)

 

Windows 11 AAD with Co-Management.

Iron Contributor

Hey Danny,

Thanks for documenting this!

We are looking forward to the addition of filters to the new 'co-management settings' policy so that we can retire our workaround of putting that special registry key in place.

Copper Contributor

Strange thing in our environment - we didn't have this policy created at all. We deploy the agent in Autopilot as a required app during ESP. Every single device bar one has ended up with the correct co-management settings (we have some set to pilot Intune, but by and large all clients are set to CM). 


We use mostly PXE and USB for imaging still, but autopilot is used in a few scenarios now, depending upon location and local suppliers. And 99% of our estate is W10 - however we have a few pilot W11. One of those was autopiloted in December, and that is the device where the registry key you alluded to is set to 1. We noticed it because the user received a Wifi profile that is only assigned to a few AAD joined only devices that we have. I have checked on another autopiloted device, and since we didn't have a policy set, there was no key (as I expected). 


Now I have created a policy, targeting only Autopiloted devices (existing and future) and set the value to 2. 

However I'm still confused as to why one device out of 50 or 60 that have been autopiloted so far should end up with the wrong setting. Or indeed any setting at all...

Copper Contributor

Hi Danny,

 

We have are provisioning Azure AD joined devices using autopilot and we have the set the enable comangement policy advanced setting both to yes. 

we want intune to manage all the workloads.

But the build keeps on failing at ESP when we deploy the comanagement setting and if we do not deploy this setting build works fine

Brass Contributor

Hi! Is this supported for User-driven AzureAD Hybrid Joined Autopilot devices i.e. can/should it only be targeted to devices after they have finished Autopilot? I note here it states:


You can't deploy the Configuration Manager client while provisioning a new computer in Windows Autopilot user-driven mode for hybrid Azure AD join. This limitation is due to the identity change of the device during the hybrid Azure AD-join process. Deploy the Configuration Manager client after the Autopilot process. For alternative options to install the client, see Client installation methods in Configuration Manager.

Copper Contributor

To be honest Self-Deploy is awesome. Our users get a device and they sign in at the desktop login. It is the BEST user experience. They get a device ready to use, and they FEEL it when they turn it on. When they get a device with that Welcome screen that goes into ESP they do not feel like they got a device ready to use. They have to wait. Even with Pre-Provision.
Not sure why its so hard to install CCM client during AP without a user sign-in. This would be a great tool to utilize. If user assignment could occur at desktop login instead of a MS AAD/Entra pre-desktop login that would be cool.  Just sayin! Appreciate all ya'lls hard work. It's the simple things sometimes that are the hardest. I get that.

Co-Authors
Version history
Last update:
‎Mar 08 2023 09:44 AM
Updated by: