First published on TechNet on Jun 01, 2018
Note: The Mobile Device Management (MDM) features in the legacy Intune console are now being removed October 3 - October 8, 2018. Please use portal.azure.com now for all your MDM management.
A few Intune customers recently received a message center post sharing information about Silverlight-based Intune compliance policies or configuration polices. If there was an action for you to take, that’s called out in the message center post. In this support tip, we’ll keep it up-to-date with additional screen shots as more reporting becomes available and answer any questions you have on legacy-based compliance or configuration policies. If you’ve got a message posted to you, there’s two possible actions for you to take based on which communication you received in the Message Center:
Unfortunately, compliance policies cannot be moved from Silverlight to Azure due to fundamental differences in how the policies are created. As shared over the past 18 months , there’s differences in device compliance between the two consoles:
Separating policies by platform was a major customer request. Therefore, we’re asking that you evaluate what you had in Silverlight, and then take the opportunity to rethink them as you develop them in Azure.
When Silverlight is retired, except those using the Intune software client for PC management, the compliance policies are still applied but you won’t be able to edit them. One addition note, if you’ve already taken action and created compliance policies over in Azure, the Azure policies will take precedence over the Silverlight ones; just delete the Silverlight ones when you’re ready to.
The second reason why you may have gotten a message center post requesting action is due to unhealthy configuration policies. Healthy configuration policies, such as those used to manage security settings and features on your devices, were migrated to Azure. Unhealthy configuration polices could not be migrated. We built in configuration policy checks in Azure to ensure the policies can be applied and don’t have errors in them. In Silverlight, we don’t check for errors, so the ones left have errors and didn’t migrate. Typically, a blocker is in the custom configuration field . Once blockers are removed, the policies will self-migrate.
We are introducing a report in Azure that will show you your unhealthy configuration policies. We expect that report to be available in the first half of June. Once the report is live, we’ll add screen shots to this post. Here's a screen shot of the report showing unhealthy configuration policies:
Let us know if you have any questions! We’re here to help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.