Invoke-Command URI objects instead of strings

I have this code:

$DCs = Get-ADComputer -Filter * -SearchBase “OU=Corp,OU=Domain Controllers,DC=corp,DC=com”

…that gets all the DC’s in my sub-OU that I then want to use here:

$dc = New-PSSession -ComputerName $DCs -Credential Get-Credential

…but complains with
New-PSSession : One or more computer names are not valid. If you are trying to pass a URI, use the -ConnectionUri parameter, or pass URI
objects instead of strings.

That I want to use here:

Invoke-Command -Session $dc {
Get-WindowsFeature -Name Web-Ftp-Server | select -Property PScomputerName,Installed,Name,SubFeatures

How do I massage the first statement to pipe out what the second statement needs?

Thank you

If you run your command by itself and let it output to the screen

Get-ADComputer -Filter * -SearchBase "OU=Corp,OU=Domain Controllers,DC=corp,DC=com"

You’ll see that the output is the whole computer object, not simply the name. So when you call -ComputerName $DCs, my understanding would be that its cramming the whole object into the computer name parameter which is why it errors.(someone can correct me)

If you do Get-Help on New-PSSession, you’ll find that the -Computername parameter accepts string input

New-PSSession [[-ComputerName] String[]] ]

The Name property on Get-ADComputer is a string so try inputting only the Name property of your objects:

$dc = New-PSSession -ComputerName $DCs.Name -Credential Get-Credential

Also, maybe name your session variable from $dc to $session or something more descriptive. I know that in a short script it might seem trivial and it does work your way, its just a best practice and something to think about as you move forward.

Very helpful tips, thank you.

I see my PSSessions now.

Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
 27 Session27       DCS001    RemoteMachine   Opened        Microsoft.PowerShell     Available
 26 Session26       DCS002    RemoteMachine   Opened        Microsoft.PowerShell     Available
 24 Session24       DCS003    RemoteMachine   Opened        Microsoft.PowerShell     Available
 25 Session25       DCS004    RemoteMachine   Opened        Microsoft.PowerShell     Available

…4 out of 6, because 2 of those DCs are not reachable for security reasons. However, when I run the next bit of code:

Invoke-Command -Session $session {
    Get-WindowsFeature -Name Web-Ftp-Server | select -Property PScomputerName,Installed,Name,SubFeatures

…I see a new error for 2 out of the 4 DCs:

The term ‘Get-WindowsFeature’ is not recognized as the name of a cmdlet

…I was hoping that Get-WindowsFeature cmdlet from my host where I’m doing all this scripting would pass the cmdlet/work to each of the queried DCs. Does it, in fact, require that the same version Powershell is running on those destinations? If so, is there a technique available that only uses the tools/cmdlets installed on the scripting host?

I’m not knowledgeable enough to advise on a way to do that unfortunately. You could try this as a workaround for your issue though.
Guessing that the ones that returned an error are running Server 2008 or 2008R2, you might want to try adding Import-Module ServerManager; to your script block. So:

Invoke-Command -Session $session {import-module ServerManager;
    Get-WindowsFeature -Name Web-Ftp-Server | select -Property PScomputerName,Installed,Name,SubFeatures

That would import the Get-WindowsFeature cmdlets on each server that you run it against. To my knowledge these cmdlets are not loaded by default unless the server is 2012 or higher which might be why you get the errors on some of them if they are 2008.

I think you nailed it, thank you! This is outputting more complete results. I had never previously seen the “Import-Module :” use in an Invoke-Command, so this was very helpful and useful.

I do see sometimes an error

"Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.”

…but still the script continues for the rest of the servers in the $session variable.