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.

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

When you open the properties of CMG, the expiration date of the CMG certificate should be shown.

And there should be a console notification if the expiration of the certificate is in less than 7 days.

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.

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.

It looks like it is not possible to use the 'collection' and 'client details' tab in Intune for a co managed device with an Azure AD user.

In this article (https://docs.microsoft.com/en-us/mem/configmgr/tenant-attach/troubleshoot-client-details) is described that an account is needed which is discovered by AD and Azure AD Discovery --> 'synced Account'

We have separated the administrative accounts for our on-prem environment and Azure AD. It would be great to use an azure ad user to use the 'client detail' and 'collection' tab.

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

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.

MBAM has been integrated into SCCM really well. However, to enable tamper protection you need to co-manage devices with intune. As soon as you move the workload from SCCM to intune (device management) you lose the ability to use SCCM. This means you lose either the ability to pop up a pin dialogue in user mode or tamper protection in the Defender AV.

In this case the products become mutually exclusive. Please add an option to allow MBAM to be continued to be managed by SCCM so we can use both Tamper protection and the pin popup provided by MBAM.