I am pulling users from AD using get-aduser. In this case I need to filter by “Description”.
I have tried filtering using the filter parameter and also tried piping it into “Where”… same result.
Here is my -filter
{description -notlike “Description1*” -or description -notlike “Description2*”}
and here is my “where” filter
{$.description -notlike “Description1*” -or $.description -notlike “Description2*”}
Btw,
{$.description -like “Description1*” -or $.description -like “Description2*”} works as expected
Yes, something illogical. Need to use -and instead of -or.
Say you want to find every description that doesn’t contain bob or john
let description equal “bob” therefore we want it to evaluate to false
description is not like “john” or description is not like “bob”, evaluates to:
True (because “john” isn’t like “bob”) -or False, which evaluates to:
True
However
description is not like “john” and description is not like “bob”, evaluates to:
True -and False, which evaluates to:
False
I’m not sure the cmdlets support -notlike in the -filter parameter; keep in mind all that has to translate to LDAP query syntax under the hood. You might consider using -LdapFilter instead, so you can be more precise. The LDAP syntax is different, but it’s what AD uses natively, so you’ll be skipping a translation “layer.”
As for Where-Object, make sure that you’re specifying the Description field to be included in the query results. I’d also use parentheses around the subexpressions, personally:
But I guess I question the logic a bit. If the Description is “User,” that filter will allow it through, because it is not like “Admin*.” Conversely, if it is “Admin,” the filter will pass it because it is not like “User*.” Essentially, any description should make it through that filter.
Just tested using “-notlike” as an operator in the filter parameter and it works. Based on what you said about LDAP filters i will definitely take a look
I know about the need to specify the properties that are not returned by default. Been there, done that (ohh, yes). I hope the Powershell team will consider throwing an error when you try to use a property that is nonexistent, like “get-aduser jdoe | select name,description”.
And yes, the logic is a bit fuzzy. It makes sense when you express it using human language, but not using logical gates.
I forgot to look at the filter as a one statement that either returns true or false.
I know about the need to specify the properties that are not returned by default. Been there, done that (ohh, yes). I hope the Powershell team will consider throwing an error when you try to use a property that is nonexistent, like "get-aduser jdoe | select name,description"
