Intune Compliance Policies / Windows Feature Update - Additional filter support

FabienTschanz commented 4 months ago

Description of the issue

The following resources either do not support any filtering on the Graph level or only partial filtering:

IntuneWindowsUpdateForBusinessFeatureUpdateProfileWindows10 (no filtering at all)
IntuneDeviceCompliancePolicyWindows10 (functions not allowed)
IntuneDeviceCompliancePolicyMacOS (functions not allowed)
IntuneDeviceCompliancePolicyiOs (functions not allowed)
IntuneDeviceCompliancePolicyAndroidWorkProfile (functions not allowed)
IntuneDeviceCompliancePolicyAndroidDeviceOwner (functions not allowed)
IntuneDeviceCompliancePolicyAndroidDeviceOwner (functions not allowed)

"Functions not allowed" refers to the Odata filter functions startswith, endswith and contains. In my opinion, it would be best to add that functionality on the backend level, or alternatively on the client where we evaluate the filter query ourselves and filter afterwards using Where-Object.

The idea comes from reverting the filter capability on the IntuneWindowsUpdateForBusinessFeatureUpdateProfileWindows10 resource in #4594 because the filtering is not supported at all. A reference implementation of such a filter using contains to add support for filtering could be the following:

if (-not [System.String]::IsNullOrEmpty($Filter))
{
    $pattern = "contains\((.*), '(.*)'\)"
    if ($Filter -match $pattern) {
        $propertyName = $matches[1]
        $filterValue = $matches[2]
        $getValue = $getValue | Where-Object -FilterScript { $_.$propertyName -like "*$filterValue*" }
    }
}

What are your thoughts on that topic? Personally, I would prefer to have the filter functionality on the backend as on pretty much all other resources, but if it is not possible, we should add additional filter capability, even if it is limited in its application. Having a "basic" filter is better than having no filter at all. In my case, I want to filter for a string appearing in displayName, but that's only possible with the contains filter method, which as mentioned is not available on all resources.

Edit: Just stumbled upon more resources that do not support odata filter functions:

IntuneAppConfigurationPolicy --> Internal Server Error
IntuneAppProtectionPolicyAndroid --> Internal Server Error
IntuneAppProtectionPolicyiOS --> Internal Server Error
IntuneWindowsInformationProtectionPolicyWindows10MdmEnrolled --> Internal Server Error

Microsoft 365 DSC Version

V1.24.417.1

Which workloads are affected

Intune

The DSC configuration

No response

Verbose logs showing the problem

No response

Environment Information + PowerShell Version

No response

FabienTschanz commented 4 months ago

@NikCharlebois @andikrueger @William-Francillette Any thoughts on that? If the idea is bad, then that's also ok. But it would be great to have a bit of a discussion, because for me that functionality would actually be great to have, as I imagine for some others too.

William-Francillette commented 4 months ago

My 2 cents on this issue would be to ensure we have consistency across all resources (not only Intune). If we can abstract the filter so that the end user doesn't realise the filtering is occurring on the server or the client side then it would be ideal. Of course priority should be filtering on the server side for performance concerns.

FabienTschanz commented 4 months ago

@William-Francillette I agree. What if a resource doesn't support the provided filter query(ies)? Above I listed some resources for Intune, but of course they are nowhere near complete. Can we raise an issue in the team responsible for that API?

microsoft / Microsoft365DSC