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.

Our on-premises firewall configured to allow only traffic from specific IP addresses. By using reserved public IP we don't need to update our firewall rules due to an IP change in cloud service.
We have an open case regarding the CMG issue - Ticket #:16891245

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.

With 1902 the reserved IP address was not an issue, but wit upgrade to 1906 the deployment upgrade fails with below message

tatusMessage":{"error":{"code":"DeploymentSlotUpdateOperationFailed","message":"The update deployment operation failed for the domain 'domain.com' in the deployment slot 'Production' with the name 'domain.com-deployment': 'A reserved IP cannot be added, removed or changed during deployment update or upgrade. '."}},"targetResource":{"id":"/subscriptions/xxxxxxx-xxxxx-xxxxxx/resourceGroups

We have a firewall in place which we configure it using IP addressing.

I've experienced this situation on a few customer sites. I've been unable to "fix" a broken Cloud Management Gateway which was previously working. On these occasions the easiest way to resolve is to remove and re-deploy the CMG. This always fixes the problem but seems a little extreme. I'd like to see a CMG reset feature (along the same lines of the site reset feature) which resets the CMG services and permissions instead of having to remove it.

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.

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.

May I know what would be ideal time for a machine to get Co-Managed.
Starting the Client (agent) installation, registration in AAD, Workload download and update the Co-Management capabilities.

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

In the CMG Setup console it is possible to select a region for the CMG deployment which is not consistent with the p precreated resource group. Then the CMG deployment will obviously fail.