locked
ActiveDirectory PowerShell Imported Remote Module issue RRS feed

  • Question

  • I am having an issue with passing variables to the filter parameter to functions like Get-ADUser. When I run

    $a = 'AccountNameHere'; Get-ADUser -filter {samaccountname -eq $a}


    on a computer that has the ActiveDirectory Module installed, it works! When I run it on a computer that has the module imported from a PSSession, it doesn't. I get an odd error:

    Variable: 'a' found in expression: $a is not defined.
        + CategoryInfo          : InvalidArgument: (:) [Get-ADUser], ArgumentException
        + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.ArgumentException,Microsoft.ActiveDirectory.Management.Commands.GetADUser
        + PSComputerName        : RemoteComputer


    I do have the remoting / credentialling setup properly, and passing the variable to another parameter does work, such as:

    $a = 'AccountNameHere'; Get-ADUser -Identity $a

    , the problem only surfaces in the filter block.

    I have tried to put the filter statement in a variable block, and that doesn't particularly work either:

    $a = 'AccountNameHere'; $b = {samaccountname -eq $a}; Get-ADUser -filter $b
    Variable: 'a' found in expression: $a is not defined.
        + CategoryInfo          : InvalidArgument: (:) [Get-ADUser], ArgumentException
        + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.ArgumentException,Microsoft.ActiveDirectory.Management.Commands.GetADUser
        + PSComputerName        : RemoteComputer
     

    This next one does work, but it's not usable for me because I still can't pass the filter a variable:

    $a = {samaccountname -eq 'AccountNameHere'}; Get-ADUser -filter $a


    Ian

    Wednesday, January 15, 2014 2:57 PM

Answers

All replies

  • It works fine for the rest of us.  You must be passing a wrong value.

    Try not jumbling everything on the same line.,  It serves no purpose other than making the code harder to read.

    $a='Guest'
    Get-ADUser -filter {samaccountname -eq $a}

    This will always work.  The Guest account should always exist although it can have been renamed in which case this will return nothing.


    ¯\_(ツ)_/¯


    • Edited by jrv Wednesday, January 15, 2014 3:28 PM
    Wednesday, January 15, 2014 3:27 PM
  • Sorry, no. That still does not work. Semicolons might make the code harder for you to read, but they do not change the functionality. I think you missed that I said the commands work properly when I run them on a computer that has the module directly installed. The commands to not work properly when I have imported them from another computer. I know that I have imported them properly because everything else about the commands still work, they just will not accept a variable in the filter block. For example, I said in the example above, a variable IS accepted in the identity parameter, just not the filter parameter.

    Ian

    • Marked as answer by Ian Bruckner Wednesday, January 15, 2014 3:41 PM
    • Unmarked as answer by Ian Bruckner Wednesday, January 15, 2014 3:48 PM
    Wednesday, January 15, 2014 3:36 PM
  • Hi,

    -Filter wants a string, not a scriptblock.

    Get-ADUser -Filter "SamAccountName -eq '$a'"


    Don't retire TechNet! - (Don't give up yet - 12,575+ strong and growing)

    • Marked as answer by Ian Bruckner Wednesday, January 15, 2014 3:43 PM
    Wednesday, January 15, 2014 3:36 PM
  • Bingo!


    Ian

    Wednesday, January 15, 2014 3:41 PM
  • I see no indication in your code that you have imported anything. Objects cannot be passed between sessions.


    ¯\_(ツ)_/¯

    Wednesday, January 15, 2014 3:42 PM
  • Hi,

    -Filter wants a string, not a scriptblock.

    Get-ADUser -Filter "SamAccountName -eq '$a'"


    Don't retire TechNet! - (Don't give up yet - 12,575+ strong and growing)

    A filter can take a script block.  We use them all of the time.  An LDAPFilter can only use strings.

    From docs:

     Syntax:
     The following syntax uses Backus-Naur form to show how to use the PowerShell Expression Language for this
     parameter.

     <filter>  ::= "{" <FilterComponentList> "}"

    Note that it specifically defines a script block,


    ¯\_(ツ)_/¯

    Wednesday, January 15, 2014 3:45 PM
  • A filter can take a script block.  We use them all of the time.  An LDAPFilter can only use strings.
    Sure, but there's no reason to use a scriptblock if you don't have to.

    Don't retire TechNet! - (Don't give up yet - 12,575+ strong and growing)

    Wednesday, January 15, 2014 3:46 PM
  • You're quite wrong. Objects can indeed be passed.

    Just because you didn't see it doesn't mean I haven't done it. I didn't show it because it was probably irrelevant since the rest of it worked.

    Anyways, adding single quotes around the variable worked in both use cases, when the module was directly installed and when it was imported remotely. Not using the single quotes only worked when the module was installed directly.


    Ian

    Wednesday, January 15, 2014 3:47 PM
  • The issue is really about not sending objects or local variables across session boundaries.  By using a full string it is forcing the conversion to occur before the session is invoked.  This is similar to the first example that worked.

    This:

    $a = {samaccountname -eq 'AccountNameHere'}; Get-ADUser -filter $a

    worked because it does the variable expansion before calling the CmdLet and the block is evaluated before the call too.  Placing the $a in the filter in a block causes it to be evaluated on the remote system where it does not exist.  This is always an issue with SOA and proxy code.


    ¯\_(ツ)_/¯

    Wednesday, January 15, 2014 3:53 PM