PrzemyslawKlys
commented
2 hours ago I guess it's simply easier to filter post-factum and more flexible in powershell then write advanced filter for graph which many people will struggle with. I guess if one knows how to write filters it would be possible to just expose that as an option.
Feel free to propose something that will allow people to apply filtering so the "scope" is limited only to your filter ;)
Thanks for your great work. For contact-to-mobile synchronization I was afraid we had to set up third party solution like CiraSync until I came accross your module.
In my case, I wanted to filter users based on extensionAttributes which didn't seems to be available through your current filtering implementation. Also I noticed you didn't implemented odata filtering (which AFAIK may be better than filtering after getting the whole list of users).
Anyway, to quick-and-dirty implement this simple use case I only had to modify the file Private\Get-O365ExistingMembers.ps1 $getMgUserSplat = @{ Property = $Script:PropertiesUsers All = $true ErrorAction = 'Stop' <# BEGIN ADD FOR FILTERING ON extensionAttribute5 == MYFILTERCRITERIA #> 'Filter' = "onPremisesExtensionAttributes/extensionAttribute5 eq 'MYFILTERCRITERIA'"; 'CountVariable' = 'userCount'; 'ConsistencyLevel' = 'eventual'; 'PageSize' = '999'; <# END ADD FOR FILTERING ON extensionAttribute5 == MYFILTERCRITERIA #> }
I was wondering why you implemented a filtering solution after getting the whole tenant user list ? Is it only to have better Verbose logging ? Or maybe it is related to other MemberType such as Contacts, Guest, etc. ?
To avoid any break changes, I may suggest a new FilterType "Odata" generated by a cmdlet Sync-O365PersonalContactPreFilter ? Which will be added to the $getMgUserSplat ? I would be more than happy to contribute on this.