Repository navigation
microsoft.graph.managedDevice is missing a filter restrictions annotation. #1193
Description
Activity
I got access to a tenant with Intune and checked what the service actually does. It rejects the undocumented properties outright rather than ignoring them, which lines up with the annotation being the missing piece.
Requests against
/v1.0/deviceManagement/managedDevices:$filterDocumented as filterable Result deviceName eq '...'yes 200 model eq '...'yes 200 userId eq '...'no 400 Unsupported parameter found in querywiFiMacAddress eq '...'no 400 Unsupported parameter found in querynotes eq '...'no 400 Unsupported parameter found in queryid eq '...'no 400 So the service knows exactly which properties can be filtered and says so at request parse time, before it looks at any data. The tenant I used has no enrolled devices, which does not matter for the 400 cases since the query never gets that far.
This is the same behaviour that #225 described for
directorySetting, where filtering also failed with a 400 and the fix was to add the annotation.- added a commit that references this issue
on Aug 27, 2026 Thanks for the detailed report. I'm escalating this internally to get it fixed at the source
Filtering is only partially supported on
/deviceManagement/managedDevices(microsoft.graph.managedDevice), but there is noOrg.OData.Capabilities.V1.FilterRestrictionsannotation on the type or on thedeviceManagement/managedDevicesnavigation property. The only place the restriction is recorded is the type description:With
FilterRestrictionsabsent,Filterabledefaults to true, so the metadata advertises the collection as fully filterable. Generated clients follow the metadata:Get-MgDeviceManagementManagedDeviceexposes-Filterand the .NET client exposesFilteron the request configuration, with no machine readable signal about which properties actually work. Today a caller has to read the description of each property one at a time to find out.The per property descriptions already record which properties support
$filter, so the information needed for the annotation is already in the metadata.Same shape as #225, which was fixed by #227.