The (member:1.2.840.113556.1.4.1941:=) search filter is invalid.

[Bowerz]

Hi Team,

Whilst i appreciate this is probably an issue with my setup rather than the script itself, it isn't clear what the issue is. I have a couple of users that when they run the script the log gives the following error (other users are just fine). If i break down the script step by step, I seem to get an issue around the 2 lines:

$distinguishedName = $searcher.FindOne().Properties.distinguishedname $searcher.Filter = "(member:1.2.840.113556.1.4.1941:=$distinguishedName)"

_PS C:\ProgramData\intune-drive-mapping-generator> $distinguishedName = $searcher.FindOne().Properties.distinguishedname Exception calling "FindOne" with "0" argument(s): "The (member:1.2.840.113556.1.4.1941:=) search filter is invalid." At line:1 char:5

• ... $distinguishedName = $searcher.FindOne().Properties.disti ...
• CategoryInfo : NotSpecified: (:) [], MethodInvocationException
• FullyQualifiedErrorId : ArgumentException_

It isn't clear to me what isn't working here beyond it attempting to match the DN of the user and if it exists in a group - however the user is a member of at least one of the specified groups for the drive maps.

Any assistance is much apprecated in troubleshooting and hoping that anyone else who gets this error may also find this help when googling.

[mikew-gnet]

I had this issue crop up while testing with nested groups. Tried manually defining the AD Search filter in the script to no avail. I noticed that this error appears in the log regardless on if I was using Group Filters or not. Then it dawned on me, the test account I was using was using the vanity .onmicrosoft domain, which doesn't exist as a UPN suffix on prem in AD. When the script attempts to find the user with it's LDAP search function, it calls upon the UPN to find the Distinguished Name for the user and subsequently do the group lookups. The error was happening because the Azure AD joined computer was looking for user@company.onmicrosoft.com, but in AD the user was user@company.local.

Hope this helps.

[taraldjoh]

This is most likely the correct assumption. I had a similar issue trying to implement this in my own environment. It does in fact seem to be related to the lookup of the UPN suffix. If you're having issues with the lookup, try overriding the active directory domain name using the "$searchRoot" variable and set it to the local AD domain name.

This worked for me atleast, after changing the variable I got no message and the output logs all the direct and nested groups the user account is a member of.

Hope this helps a little too.

[majorpaynedof]

I have seen this also when you have to be on VPN to reach the domain and to get the drives to map.