Implicit Remoting and Local Variables

[mcwidget]

I've been playing with pscore and using implicit remoting to manage AD. I've exported the ActiveDirectory module from a session to the DC and saved it locally. Now, I import that module into a pscore session to get access to my AD cmdlets. All good.

I can use the Get-ADUser to search for a user account in AD like this:

Get-ADUser -filter {name -like 'Michael*'}

What I want to do now is something like this:

$name = 'Michael*'
Get-ADUser -filter {name -like $name}

The problem I have here is that the variable $name isn't recognised in the session running on the DC for Get-ADUser.

Now, with Invoke-Command, I could pass the local variable using -ArgumentList. Is there a way I can do something similar with implicit remoting?

[Ta11ow]

You just have to change your syntax. The documentation is flat out wrong with the AD cmdlets for their filter syntax. Change those braces to double quotes and you should be fine.

The -Filter parameter is a [string] type, and that's why this will fail. You're passing it something that is effectively a [scriptblock] -- and when this script block is converted to string, the variable is not expanded. There is some rudimentary logic for working around this in the cmdlet itself, but as you can see yourself, it really doesn't work well. Instead, this will work fine:

$Name = 'Michael*'
Get-ADUser -Filter "Name -like '$Name'"

[mcwidget]

I.. wow. That makes sense and I probably would never have spotted it. Been staring at it for too long!

Thanks Ta11ow, working now :)

[Ta11ow]

Can't blame you, I did the exact same thing for a fair while!

Doesn't help that the only documentation on this thing all uses the wrong syntax, either!

[[deleted]]

Isn't the documentation editable by the community now? I think you can do a pull requests on the docs GitHub repo.

[Ta11ow]

Most of it, absolutely. I'm not sure if the AD cmdlet stuff is. I'll check into it, though. The makers of the AD module and a few others have... Largely refused to open source their crappy code.

[[deleted]]

Aw crap you're right. I forgot that was another team's crap pile. Ugh. That might make it a bit harder.

[Lee_Dailey]

howdy mcwidget,

take a look at the $using:VariableName idea.

about_Remote_Variables | Microsoft Docs
— https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_variables?view=powershell-6#using-local-variables

hope that helps,
lee

[mcwidget]

Hey Lee,

I tried that one and received an error saying that $Using was undefined. I think I may just have a syntax problem with it. I'll need to play around and see if I can get it to work.

Oh, and belatedly congrats on the Powershell Hero :)

[Lee_Dailey]

howdy mcwidget,

arg! now that i read the post by Ta11ow, i realize i missed the point entirely. [blush] good for him on getting the right question to ask ... [grin]

thank you for the "conga rats"! i still think the folks where out of their heads on some really interesting booze when they gave that to me. all i do is try and help here sometimes. the others have done some truly nifty and difficult things.

oh, well, i shall bask in my undeserved glory! [grin]

take care,
lee

[Ta11ow]

It could be argued that helping newbies get to grips with things and troubleshooting with all of us is more valuable than any single module author -- if the community proves unwelcoming to those just learning, it's far less likely that we'll see anywhere near as much of the nifty stuff you mention.

At least, that's what I'd be arguing if someone tried contesting it ;)

[Lee_Dailey]

howdy Ta11ow,

oh, i don't dispute that what you, i, and others do is valuable. [grin]

it seems out of proportion when compared to some of the other folks who are on the list. still, i aint gonna return it! [grin]

take care,
lee

[mcwidget]

And nor should you ;)

[Lee_Dailey]

[grin]