Forum Discussion
Invoke-Command does not return IIS Provider data
Mechanically, there's nothing wrong with what you're doing, as shown in my own basic replication of it:
$wap = Invoke-Command -UseSSL -ComputerName rpiis01.robertsonpayne.com -ScriptBlock {
Import-Module -Name WebAdministration;
Get-ChildItem -Path "IIS:\AppPools";
}
You might want to add an ErrorAction on the inner call to Get-ChildItem, as I get the feeling the remote script is failing for some reason while possibly under an ErrorAction mode of "SilentlyContinue".
Note: The outer ErrorAction you've specified has no bearing on the remote session.
So, try something like this and see if it's failing remotely:
$wap = Invoke-Command -UseSSL -ComputerName rpiis01.robertsonpayne.com -ScriptBlock {
Import-Module -Name WebAdministration;
Get-ChildItem -Path "IIS:\AppPools" -ErrorAction:Stop;
}
Cheers,
Lain
LainRobertson
Thank you for your analysis.
Per your suggestion, I added EA Stop within the scriptBlock.The scriptBlock seems to run without incident, but not return AppPool(s).
I added a simple file creation to the scriptBlock, and it executes as expected, indicating the connection, authentication, permissions, etc. are correct.Initially I was running Invoke-Command with an alternate credential. I moved the script to another computer where it runs with the same account required on the target server, and removed the -Credential argument from Invoke-Command. No difference.
If I run the GCI command locally on the target server it returns object(s) of type,
Microsoft.IIs.PowerShell.Framework.ConfigurationelementWhen running remotely, with Invoke-Command, it returns a single empty/null object of type,
System.Management.Automation.PSCustomObjectThe EventViewer logs, App, System and PowerShell show no errors on source or target computers. The GCI command seems to run happily and produce nothing.
I noticed a slight difference in syntax between your sample command and mine, in the -Path component. Yours includes a backslash, "IIS:\AppPool". I had used "IIS:AppPool". Testing showed both yield the same result.
This has turned into a battle of wills. I've spent more time troubleshooting this than it will eventually save, versus running locally on each server. But I am stubborn...
$sbCmdL = { $strTimeL = ( Get-Date ).ToString() $strTimeL | Out-File -FilePath 'C:\Temp\TimeStamp.txt' Import-Module WebAdministration $colPoolsL = Get-ChildItem -Path "IIS:AppPools" ` -ErrorAction 'Stop' }#End sb $colPoolsL = Invoke-command -ComputerName $Server ` -ScriptBlock $sbCmdL ` -ErrorAction 'Stop'I wasn't absolutely sure of syntax within the scriptBlock, so I added semicolon statement terminators, but they had no effect.
$sbCmdL = { $strTimeL = ( Get-Date ).ToString(); $strTimeL | Out-File -FilePath 'C:\Temp\TimeStamp.txt'; Import-Module WebAdministration; $colPoolsL = Get-ChildItem -Path "IIS:\AppPools" ` -ErrorAction 'Stop';Yeah, the semicolon is just my personal preference since it's prevalent in other languages I use, though it's quite handy when I choose to be lazy and put multiple short commands on a single line.
Looking at your last script block, there seems to be a missing closing "}". If I assume it was meant to be at the very end - let's say as line 6, then the issue you have is that on line 5, you've assigned the output to a variable but have not then re-stated that variable to send the contents of that variable onto the remote pipeline. This would be why you're only getting $null back.
Based on my assumption about the closing "}", it should looks like this:
$sbCmdL = { $strTimeL = ( Get-Date ).ToString(); $strTimeL | Out-File -FilePath 'C:\Temp\TimeStamp.txt'; Import-Module WebAdministration; $colPoolsL = Get-ChildItem -Path "IIS:\AppPools" ` -ErrorAction 'Stop'; $colPoolsL; # This is what send content to the remote pipeline. }Cheers,
Lain
- Sorry for the confusion. There was, in fact, a closing brace on the next line. Lack of the closing brace would create a compile-time error.
