Don’t like the way you doing it. However, I m getting output as per your code. Might be the user you are trying to filter might be residing at another domain. Try to use server parameter.
About a year ago I wrote a complex/convoluted script to go through AD and create list of users from groups. I fought the filter command for AGES, I even went as far as doing invoke-expression, and that worked. Someone on here pointed out that you didn’t need the {} around the filter and then it worked.
I used a different user name at the time, and I have NO idea what it was.
[quote quote=166657][/quote]
The weird thing is that I’ve seen so many examples of it being used with the {} and it’s worked just fine.
I can do a filter like {passwordneverexpires -eq “False”} and that works perfect. I don’t see the difference. Why would that work but not work for my previous command?
So are you saying that since DisplayName is a string, I should use the quotes (“”) instead?
That doesn’t explain why this works, since it has {} instead
It’s a quoting issue. Technically, an AD filter is a string. The Backus-Naur form in the docs is incorrect. The script block gets converted to a string easily, so people often use it. A variable needs to be inside double quotes to get interpreted.
[quote quote=166708]It’s a quoting issue. Technically, an ad filter is a string. The script block gets converted to a string easily, so people often use it.
[/quote]
In simple terms, where exactly is my thinking going off the rails here?
That clears up the difference between the brackets {} and the quotes “”. However, “$lastName$firstName*” and $name are both strings, so why would using $name work?
I think because in the first case, you don’t need to pass in a second level of quotes, but in the second case you do. Doing -like with no wildcards is really the same as -eq. Actually, I don’t know why the first case works, then.
[quote quote=166735]I think because in the first case, you don’t need to pass in a second level of quotes, but in the second case you do. Doing -like with no wildcards is really the same as -eq. Actually, I don’t know why the first case works, then.
There are times when I find powershell to be more of an art than a science. Sometimes things work when they shouldn’t, other times they don’t when they should.
I can tell you when it comes to nest " ’ and `’ " inside of anything, I start to shudder.
function runfilter {
param([string]$filter)
echo hi | where -filterscript $filter
}
PS C:\users\j> runfilter {$_ -eq "hi"}
Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the "$_ -eq "hi"" value of
type "System.String" to type "System.Management.Automation.ScriptBlock".
At C:\Users\j\runfilter.ps1:3 char:31
+ echo hi | where -filterscript $filter
+ ~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Where-Object], ParameterBindingException
+ FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereOb
jectCommand