Extend co-management so that we can OSD an Win10 machine directly into AAD where it gets managed by both ConfigMgr and Intune.

Autocreate ConfigMgr Client Setup Bootstrap in Intune when setting up Co-Management.

When setting up Co-management, make it so that the Client Setup Bootstrap is auto-created in Intune with the appropriate arguements. This way can ensure also that the app is auto-updated with new realeses of ConfigMgr.

Unable Configure Co-Management grayed out on 1802.

Co-Managment Properties to enable Automatic Enrollment is not enrolling the devices. The GP setting referenced in the title had to be configured and the machine rebooted to enroll in intune.

The "Automatic Enrollment in Intune" setting on the enablement tab of the Co-Management properties should trigger the client to configure Local Group Policy similar to how the WSUS policies are set with the SCCM client.

Instead of the standard 'computer' icon with a green check mark, it should be a cloud icon with a green check mark, when the Device Online From Internet = True.

The default client policy in SCCM has Cloud Services configurated to Automatically register new Windows 10 domain joined devices with Azure Active Directory. We can only set this to Yes or No within configuration manager. Whatever it is set to it is overriding the GPO setting. It would be ideal if we have an option for Not Configured with Yes|No, so that we can manage the setting from GPO, if not by SCCM Client.

The documentation for co-management is very poor or vague in areas that makes the adoption of co-management very difficult.

Some work needs to be done on this article in particular... https://docs.microsoft.com/en-us/sccm/core/clients/manage/co-management-overview

It doesn't talk about permissions or what to do to shift workloads to Intune.

Allow a choice for Co-Management settings deployment to be able to chose the collection when not set to pilot. When we enabled and configured co-management sccm automatically used All Systems as a collection deployment. As a policy we almost never use the all systems collection to avoid incidents globally.

Expose an element in the client ui that would indicate if a CMG connection (or, really, any MP connection) is functioning and/or that communication with the MP is working. Right now, we have a box in the client UI that tells us which MP is being used, but, not if the connection is active. To actually identify if a client is able to communicate with the MP requires looking at log files. It would be nice to have a simple UI that would give us an idea if the client is able to communicate with the MP/CMG.

Right now we're limited by either using a policy from CM or a policy for Intune when using co-management. It would be great if there was a conditional access style policy that indicated when you are within these SCCM boundaries apply the policy(/ies) from SCCM and when you are outside these boundaries apply the policy(/ies) from Intune.
CMG is awesome but requires additional Azure infrastructure/cost

Co-management: get non-compliant information in ConfigMgr console when using Intune so you do not have to switch between ConfigMgr and Intune. Should be in both places. (Logging, Reporting, Information). Came from SCUGno Oktober Meeting 2018

Add a fourth stage (ConfigMgr - Intune Pilot - Cloud Users - Intune) "Cloud users" in the Co-Management GUI.
Companies might have many users who can be Intune managed without having to be part of the pilot collection or having to wait for the entire organization to move to Intune.

When deploying a device using Autopilot, the Enrollment Status Page (ESP) is used to prevent access to the desktop until the device provisioning tasks are complete. But ConfigMgr doesn't integrate with the ESP, so there's no way to wait for packages, apps, or task sequences - the user doesn't know when the process is done. Add that integration.