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:
- Recreate your Intune compliance policies in Azure prior to the Silverlight console’s retirement; and/or
- Check stuck configuration policies over in Silverlight. While configuration policies were migrated from Silverlight to Azure, any that did not pass configuration validation checks were left in Silverlight.
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:
- In the Azure portal, the compliance policies are created separately for each supported platform. And when you look at all the platform options, you can customize a number of settings based on the platform.
- In Silverlight, one device compliance policy is common to all supported platforms.
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!
- 6/11/18 - added screenshot of the configuration policy report.