I'd like to check if a user account already exists in the system.
$SamAc = Read-Host 'What is your username?'
$User = Get-ADUser -Filter {sAMAccountName -eq "$SamAc"}
I'm not sure why, but $User
will always return null even if {sAMAccountName -eq "$SamAc"}
is supposed to be true.
What am I missing here?
Edit:
This is what was missing:
$User = Get-ADUser -Filter "sAMAccountName -eq '$SamAc'"
Editor's note: The script block ({ ... }
) was replaced with a string.
There is valuable information in the existing answers, but I think a more focused summary is helpful. Note that the original form of this answer advocated strict avoidance of script blocks and AD-provider variable evaluation, which has been replaced with more nuanced recommendations.
tl;dr
Get-ADUser -Filter 'sAMAccountName -eq $SamAc'
Do not quote the variable reference ()."$SamAc"
Only use simple variable references (e.g, $SamAc
); expressions are not supported (e.g., $SamAc.Name
or $("admin_" + $SamAc)
); if necessary, use an intermediate, auxiliary variable; e.g.:
$name = "admin_" + $SamAc; Get-ADUser -Filter 'sAMAccountName -eq $name'
Generally, only a subset of PowerShell operators are supported, and even those that are do not always behave the same way - see bottom section.
Use '...'
to quote the -Filter
argument as a whole.
{ ... }
),Get-ADUser -Filter { sAMAccountName -eq $SamAc }
, technically works too, it is conceptually problematic - see bottom section.Caveat: If you use Get-ADUser
via an implicitly remoting module - whether self-created via Import-PSSession
or, in PowerShell v7+, via the Windows Compatibility feature - neither '...'
nor { ... }
works, because the variable references are then evaluated on the remote machine, looking for the variables there (in vain); if (Get-Command Get-ADUser).CommandType
returns Function
, you're using an implicitly remoting module.
"..."
) or string concatenation from literals and variable references / expressions in order to "bake" any variable / expression values into the string, up front:Get-ADUser -Filter "sAMAccountName -eq `"$SamAc`""
`
-escape constants such as $true
, $false
, and $null
inside the "..."
string, so that PowerShell doesn't expand them up front.[datetime]
instance (e.g., 01/15/2018 16:00:00
is not recognized by the AD provider; in this case, embedding the result of a call to the instance's .ToFileTime()
method into the string may help (untested); I'm unclear on whether there are other data types that require similar workarounds.Any argument you pass to -Filter
is coerced to a string first, before it is passed to the Get-ADUser
cmdlet, because the -Filter
parameter is of type [string]
- as it is for all cmdlets that support this parameter; verify with Get-ADUser -?
With -Filter
in general, it is up to the cmdlet (the underlying PowerShell provider) to interpret that string, using a domain-specific (query) language that often has little in common with PowerShell.
In the case of Get-ADUser
, that domain-specific language (query language) is documented in Get-Help about_ActiveDirectory_Filter
.
With Get-AdUser
, this language is certainly modeled on PowerShell, but it has many limitations and some behavioral differences that one must be aware of, notably:
Only a limited subset of PowerShell operators are supported, and some exhibit different behavior; here's a non-exhaustive list:
-like
/ -notlike
only support *
in wildcard expressions (not also ?
and character sets/ranges ([...]
)
'*'
by itself represents any nonempty value (unlike in PowerShell's wildcard expressions, where it also matches an empty one).
* Instead of -eq ""
or -eq $null
to test fields for being empty, use -notlike '*'
.DistinguishedName
, only support '*'
by itself, not as part of a larger pattern; that is, they only support an emptiness test.-lt
/ -le
and -gt
/ -ge
only perform lexical comparison.Get-ADUser
command to quietly return $null
.Enabled
property cannot be tested for with -eq $true
- see this answer.As stated, only simple variable references are supported (e.g, $SamAc
), not also expressions (e.g., $SamAc.Name
or $("admin_" + $SamAc)
)
While you can use a script block ({ ... }
) to pass what becomes a string to -Filter
, and while this syntax can be convenient for embedding quotes, it is problematic for two reasons:
It may mislead you to think that you're passing a piece of PowerShell code; notably, you may be tempted to use unsupported operators and expressions rather than simple variable references.
It creates unnecessary work (though that is unlikely to matter in practice), because you're forcing PowerShell to parse the filter as PowerShell code first, only to have the result converted back to a string when the argument is bound to -Filter
.