(2015-10-15) Remote PowerShell To Servers Fails
Posted by Jorge on 2015-10-15
Imagine you want to achieve something on a list of servers, and for that you want to use remote PowerShell. Good idea!
–
Let’s say you have some list of servers in an array, and all servers are specified with their NetBIOS name. For every server you would like to retrieve its Windows version and build number (or of course something else). You could use the following PowerShell script:
$allExistingRWDCs = @("R1FSRWDC1","R1FSRWDC2") $allExistingRWDCs | %{ $rwdc = $_ $rwdcRemotePoSHSession = New-PSSession -ComputerName $rwdc Invoke-Command -Session $rwdcRemotePoSHSession -ScriptBlock { Param( $rwdc = $rwdc ) $windowsVersion = (Get-WmiObject Win32_OperatingSystem).Version $windowsBuildNumber = (Get-WmiObject Win32_OperatingSystem).BuildNumber Write-Host "" Write-Host "Host Name................: $rwdc" -ForeGroundColor Yellow Write-Host "Windows Version..........: $windowsVersion" -ForeGroundColor Yellow Write-Host "Windows Build Number.....: $windowsBuildNumber" -ForeGroundColor Yellow } -Args $rwdc Remove-PSSession $rwdcRemotePoSHSession Write-Host "" }
You copy the script into a PowerShell command prompt window, and….., life is good!
Figure 1: Remote PowerShell By Using NetBIOS Style Server Names – Success
–
I always prefer to use FQDNs instead of NetBIOS style hostnames, therefore I adjust my script accordingly as shown below
$allExistingRWDCs = @("R1FSRWDC1.IAMTEC.NET","R1FSRWDC2.IAMTEC.NET") $allExistingRWDCs | %{ $rwdc = $_ $rwdcRemotePoSHSession = New-PSSession -ComputerName $rwdc Invoke-Command -Session $rwdcRemotePoSHSession -ScriptBlock { Param( $rwdc = $rwdc ) $windowsVersion = (Get-WmiObject Win32_OperatingSystem).Version $windowsBuildNumber = (Get-WmiObject Win32_OperatingSystem).BuildNumber Write-Host "" Write-Host "Host Name................: $rwdc" -ForeGroundColor Yellow Write-Host "Windows Version..........: $windowsVersion" -ForeGroundColor Yellow Write-Host "Windows Build Number.....: $windowsBuildNumber" -ForeGroundColor Yellow } -Args $rwdc Remove-PSSession $rwdcRemotePoSHSession Write-Host "" }
You copy the script into a PowerShell command prompt window, and….., life is suddenly not that good!
Figure 2: Remote PowerShell By Using FQDN Style Server Names – Failure
–
REMARK: depending on the situation you may see other errors messages, like for example “Access Denied”
–
What the heck! You try to troubleshoot this one, and it may appear to be a tough nut to crack! Although this error message may give you a hint in which direction you should look at, but in my personal case I got the “Access Denied” error. In summary, remote PowerShell while using NetBIOS names was successful and it failed while using FQDNs. At first I started to check the WinRM settings. Again, in my case there was nothing that gave me a hint what could be wrong, until I started to do some network traces, and that’s when I understand what could be wrong. In the network trace I saw, when using FQDNs, that the proxy server was being accessed. Now why the heck is remote PowerShell trying to access the server through the Proxy Server?
With this blog post, I want to save you a long period of swearing and hair pulling.
–
When you have configured System Wide Proxy Settings , Remote PowerShell will use its configuration accordingly. In my case, the configuration was similar to:
Figure 3: System Wide Proxy Settings – Proxy Server FQDN, Port and Bypass List
–
- Proxy Server FQDN = GATEWAY.IAMTEC.NET
- Proxy Server Port = 3128
- Do not use the proxy server for the following addresses that are also available internally:
- *.IAMTEC.NL <== FQDN of the internet domain, that’s also available internally (split DNS)
- <Local> <== Definition for locally used names
–
With <local>, I first thought that would support both FQDNs and NetBIOS names. WRONG!!!
As mentioned in MS-KBQ262981, “<local>” only covers NetBIOS name style addresses, and NOT FQDNs. Therefore, any FQDN needs to be explicitly specified or be covered by some wildcard FQDN.
So, what was the solution in my case?
Answer: Add the wildcard FQDN that covers my internal AD forest. Therefore “*.IAMTEC.NET” should be added to the bypass list!
Using the following command, I was able to reconfigure the System Wide Proxy Settings:
NETSH WINHTTP SET PROXY PROXY-SERVER="GATEWAY.IAMTEC.NET:3128" BYPASS-LIST="*.iamtec.net;*.iamtec.nl;<local>"
REMARK: when configuring the System Wide Proxy Settings, services that leverage those settings may exist that need to be restarted to consume the new configuration. One of those examples is ADFS. However, this does not apply to Remote PowerShell.
Figure 4: Setting Proxy Server FQDN, Port and Bypass List
–
Now let’s retry the script that uses the FQDN of the servers. Yes, life is good again!
Figure 5: Remote PowerShell By Using FQDN Style Server Names – Success
–
YES!
–
Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————
(2016-05-16) Azure AD Connect Health Throws An Error During Azure AD Connect Install « Jorge's Quest For Knowledge! said
[…] REMARK: Because you might use PowerShell to connect to internal resources, make sure to configure all top level domains in your internal network in the bypass-list. For every internal domain configure it as shown between the double quotes “*.domain.com”. If these proxy settings are configure PowerShell will use them. if you do not configure the internal domains in the bypass list you might experience connection issues as explained in this blog post. […]
LikeLike