I was recently working with a customer who, as a lot of customers do, have a lab that also happens to be production. One of the things we were working on was implementing the configuration items and baselines needed for configuring and enabling wake on lan in the environment. However, as we were working through this we discovered that for some reason no matter what we did the CI’s would not get created.
Identifying the issue
This meant that we needed to take a trip down into the logs. After some digging around I found the following log entry in the CIAgent log.
CDCMAgent::CheckAgentEnabled - Configuration Policies are not enabled due to co-management. Request will be ignored.
That seems fairly simple enough – Co-Management is enabled and it’s set to Intune so of course, the policies from ConfigMgr would be ignored. However, when I asked my customer if they had Co-Management enabled they said nope, and when I went and looked in the console I found they, in fact, did not have Co-Management enabled. At this point, I was well and truly confused so we started with the basics maybe the client is hosed, and we re-installed the agent along with a few other basic troubleshooting steps. All of which came to nothing.
Finally, after numerous questions and digging through things in Azure, etc I found that what had happened was that Co-Management at one point had been enabled, and while enabled the compliance policies slider had been set to update via Intune. However, since it was enabled the CoMgmtSettings were deleted after testing they decided they weren’t ready to make the move to a fully co-managed environment. The challenge was that when they removed the CoMgmtSettings they did not move the workload sliders back to ConfigMgr. This caused all of the clients to assume they should still get the policy for Compliance Baselines from Intune. The hardest part is determining if this has happened and how as the only way you will know is if in the logs somewhere, or in a particular panel in Intune (like device registration) it indicates that CoMgmtSettings are in place.
Fixing the issue
In order to resolve the issue the simplest way is to re-enable Co-Management this is of course really easy but we’ll run through it quickly. In your Configuration Manager console navigate to “Administration -> Cloud Services -> Co-Management” Right-click in the pane and select “Configure Co-Management” this will open the configuration panel.
Complete your sign in additionally remember the account needs to have rights to manage Intune etc and proceed to the enablement pane and choose the enrollment option that fits your car
You will then advance to the workloads pane, and to fix the configuration item issue make sure you set the slider all the way over to Intune for the compliance policies option (as that is currently who manages the policy).
You then need to choose your Pilot collection and allow the process to finish. Once this has completed, Re-Open the pane and if you want configuration manager to be the primary for the Compliance Policies move the slider back as depicted below.
Once you have moved the slider back it will take about 5 – 10 minutes and then clients will begin using Configuration Manager for compliance policies again. While you shouldn’t ever really NEED or hopefully want to delete your co-management settings if you do make sure you document and know the locations of the sliders. If you don’t you could have unexpected challenges as removing the settings does not roll back the authority setting and there is no other way to make your on-premises clients aware of the change.