powershell - Get-Aduser -Filter will not accept a variable -

i'd check if useraccount exists in system.

$samac = read-host 'what username?' $user = get-aduser -filter {samaccountname -eq "$samac"} 

i'm not sure why $user return null if "{samaccountname -eq "$samac"}" suppose true.

what missing here?

edit:

this missing:

$user = get-aduser -filter "samaccountname -eq '$samac'" 

^{there valuable information in existing answers, think more focused summary helpful:}

tl;dr

• never use script block ({ ... }) construct -filter-parameter argument, for any cmdlet.

  • it works in limited circumstances - see below.
  • it gives mistaken impression filter piece of powershell code, isn't (it supports few operators behavior in part differs powershell counterparts - see get-help about_activedirectory_filter).

• always use string construct -filter-parameter argument, because parameter's actual type is [string]

  • in case @ hand: get-aduser -filter "samaccountname -eq '$samac'"
  • see get-help about_activedirectory_filter

---

the correct , robust approach construct string

• any argument pass -filter coerced string first anyway, before passed get-aduser cmdlet, because -filter parameter of type [string] - across all cmdlets support parameters; verify get-aduser -?

• with -filter in general, cmdlet interpret string, using domain-specific language has little in common powershell.

  • in case of get-aduser, domain-specific language (query language) documented in get-help about_activedirectory_filter

use powershell's string interpolation (or string concatenation literals , variable references / expressions) "bake" variable references into string, up front.

for instance, following commands work , functionally equivalent, using various powershell techniques construct string, variations in quoting styles , escape character:

get-aduser -filter "samaccountname -eq ""$samac""" get-aduser -filter "samaccountname -eq `"$samac`"" get-aduser -filter "samaccountname -eq '$samac'" get-aduser -filter ('samaccountname -eq "' + $samac + '"') 

the important part ensure $samac gets expanded front (replaced value), either via double-quoted string "..." or explicit string concatenation (+ $samac + ...).

if $samac contains jdoe instance, commands above pass 1 of following (equivalent) literals -filter:

samaccountname -eq "jdoe" samaccountname -eq 'jdoe' 

---

if specify script block - should avoid:

a script block, when converted string, results in literal contents between { , } - no variable expansion (interpolation) takes place:

 > {samaccountname -eq "$samac"}.tostring()  samaccountname -eq "$samac"  # !! $samac *not* expanded 

therefore, literal samaccountname -eq "$samac" passed get-aduser.

get-aduser, in misguided effort support script-block syntax / more powershell-like, does support referencing variable unquoted - note absence of " around $samac:

{ samaccountname -eq $samac }  # stated, get-aduser doesn't see { , } 

i.e., get-aduser own, powershell-like interpretation of string literal samaccountname -eq $samac: don't have enclose variable reference in "..." in powershell expression (e.g., 'windows_nt' -eq $env:os), don't have here either - , must not, evidenced op's attempt failing.

however, emulation of regular powershell script block not confusing - because users still think need enclosing quotes - half-baked, , therefore brittle:

• it doesn't work property references or method calls:

  { samaccountname -eq $searchobj.samaccountname } # !! not work 

• it doesn't work implicitly remoting modules, because variable expanded on remote machine.

---

the source of script-block confusion

while:

• get-help about_activedirectory_filter commendably discusses strings,

• it get-help get-aduser that, regrettably, uses script blocks examples.

with 1 exception, examples use literals, problem never surfaces. 1 exception (as of writing) is:

-filter { lastlogon -le $logondate } 

that example happens work - uses simple variable reference without quotes - but, due choosing non-string value, no 1 tempted mistakenly apply enclosing quotes in this case - unlike when comparing string fields.

the script-block syntax seductive , convenient, because quoting becomes easier: don't need nested quoting.
however, reasons discussed should avoided.