1

When using Visual Studio Code and PSverion 7.2.6 I am no longer able to use a variable in Get-ADUser Filter. Command:

Get-ADUser -server $DC  -Filter 'sAMAccountName -eq $Input'  -Properties $sProperties  | Select $sProperties

getting this error: Get-ADUser: Variable: 'Input' found in expression: $Input is not defined.

That works fine in PowerShell ISE ver 5.1.

Improve this question
4
  • Try double quotes so the variable gets interpreted. I doubt it works in powershell 5. You might need single quotes around the variable too. Commented Oct 7, 2022 at 17:32
  • 2
    Even tho using $input may work, it's definitely not recommend as this is an automatic variable Commented Oct 7, 2022 at 17:45
  • 1
    @SantiagoSquarzon, good point! thank you Commented Oct 7, 2022 at 18:18
  • @js2010, thank you. That double quotes with single quotes around the variable works in PS 7. Commented Oct 7, 2022 at 18:20

2 Answers 2

Reset to default
1

I played with the quotation marks ("sAMAccountName -eq 'Input'") and found the solution:

Get-ADUser -server $DC  -Filter "sAMAccountName -eq '$ReadInput'"  -Properties $sProperties  | Select $sProperties
Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

While that is a viable solution, your original attempt would likely have worked if you hadn't accidentally tried to use the automatic $input variable for custom purposes. For background information, see this answer.
@mklement0, Thanks for sharing. Actually, in the script my variable was called $readinput and was producing this error: Get-ADUser: Variable: 'ReadInput' found in expression: $ReadInput is not defined. When I was troubleshooting it, I used $input. I'm still wondering if newer PS version is handling quotation marks differently.
With a single-quoted string ('...'), it is the AD provider that resolves the variable reference, not PowerShell, which only works with stand-alone variable references, not also expressions (e.g., $readinput.SomeProperty), which is what makes it tricky. However, even stand-alone variable references don't work if you'r accessing AD via implicit remoting. The linked answer (hopefully) tells the full story. With string operands in your filter, up-front expansion by PowerShell via expandable strings ("...") is a safe choice, save for the potential need to escape embedded quote chars
@mklement0, Would you support your statement with an example. I used my original script, ran it again this time using Windows Powershell that is version 5.1. and the script completed without errors, then ran the same script using pwsh.exe (version 7) and it failed with the same error. This tests were done on the same Windows 11 laptop.
Oh, I see that I missed the cross-PowerShell-edition angle in your question. I can't speak to that, because I do not have access to AD any longer (my findings stem from using Windows PowerShell (5.1)). However, the error message you're getting suggests that the AD provide is still trying to resolve variables, so perhaps there is a bug (assuming you're not using implicit remoting)?
|
-1

try this

Get-ADUser -server $DC  -Filter "sAMAccountName -eq '$($Input)'"  -Properties $sProperties  | Select $sProperties
Improve this answer

1 Comment

Your answer in effect duplicates Tihomir Buncic's own (for simple variable references, "$var" is fine, no need for "$($var)"), except that the linked answer commendably avoids use of the automatic (reserved) $Input variable. In short: your answer adds nothing new and shows a practice that should be avoided.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.