Introduction

Couple weeks ago I did a cleanup on my tenant and removed some stale Intune filters. Upon trying to delete one specific filter I got the following message:

No surprises that filter was indeed assigned, so I remove the filter from the assignment and removed the filter. Fast forward 2 weeks, I was doing some testing with a Dev Box and realised my Wallpaper wasn’t being correctly applied. So I though to check the configuration profile which deploys the wallpaper and then I was faced with this:


Wait a minute, that does not sound right.

The only reason I found out about this issue is because we automate the assignment and deployment of all our (and our customers) Intune resources at Devicie.
Below I will try to explain why this issue happens and which resource types are affected.

The problem

When assigning filter via the web, a call is made to Graph to list all the available filters, and that generates a dropdown which allows us to select the AssignmentFilterType (include or exclude) and a filter by its name, which is then converted to AssignmentFilterId. Those are then saved as properties of the resource Assignment.
As you can imagine, once you delete a filter it won’t show in the query that list all filters (https://graph.microsoft.com/beta/deviceManagement/assignmentFilters?$filter=platform%20eq%20%27windows10AndLater%27&), but that doesn’t mean the filter does not exist anymore.

Note: If you are not using any kind of automation and all your interaction with Intune is via the web console this issue will not affect you since you cannot interact with deleted filters.

When assigning filters with automation, you will normally store the filter type and ID instead of its name (to prevent breakage if the filter is renamed). Unless you are validating the filter existence on every validation (lets say you have a one way sync from a known state to avoid drift), you might find yourself with the scenario above, where you can assign a ghost (deleted) filter to an existing resource via Graph.

Affected Resources

Once I identified the issue with Configuration Profiles resource type I tested every main resource by trying to POST an assignment request with a deleted filter id and below is the list of affected resources. Note a few do not support Filters currently so they are marked as N/A.

Resource Type Filter Support Affected
Windows app (Win32) Yes No
Microsoft Store app (new) Yes No
Configuration profiles Yes Yes
Scripts No N/A
Remediations Yes Yes
Update rings Yes Yes
Feature updates No N/A
Quality updates No N/A
Driver updates No N/A
Compliance policy Yes Yes

As we can see, only Applications throw an error stating the filter id could not be found (last 2 images), all the other resources can be assigned via Graph with a deleted filter.

Oh.. and the filters are evaluated. Yes that’s correct. They still apply the same as when they existed.

What now?

This issue is already raised with Microsoft and hopefully is fixed soon, but I though of making this quick post to alert the community until then.

Hope that was informative and thanks for reading.

Updated:

Comments