When I run
“ The RPC server is unavailable ” problem can be caused by improper functioning of RPC service on every computers connected. You may follow the steps below to ensure that all the services related to RPC run normally.
it works for both local and remote hosts.
When I do this for a list of hosts using
it returns
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
user1501778user1501778
15 Answers
Check that the 'Windows Management Instrumentation (WMI-In)' rule is enabled in the firewall for each remote machine.
Or in an Administrative Command/Powershell prompt run:
David BrabantDavid Brabant
Your code probably isn't using a correct machine name, you should double check that.
Your error is:
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
This is the result you get when a machine is not reachable. So the firewall suggestions are reasonable, but in this case probably not correct because you say this works:
So in your case it seems when this line is executed:
$_ doesn't contain a proper computer name. You could check type and contents of $_. Probably there is a problem with the file contents. If the file looks right, then maybe the lines are not properly terminated. Maybe take a closer look using Write-Host:
jimharkjimhark
It might be due to various issues.I cant say which one is there in your case.
Below given reasons may be there:
- DCOM is not enabled in host PC or target PC or on both.
- Your Firewall or even your antivirus is preventing the access.
- Any WMI related service is disabled.
Some WMI related services are as given:
- Remote Access Auto Connection Manager
- Remote Access Connection Manager
- Remote Procedure Call (RPC)
- Remote Procedure Call (RPC) Locator
- Remote Registry
For DCOM setting refer:
- Key:
HKLMSoftwareMicrosoftOLE
, Value:EnableDCOM
The value should be set to 'Y' .
Abhishek_MishraAbhishek_Mishra
I was having the same problem but only with a few machines. I found that using Invoke-Command to run the same command on the remote server worked.
So instead of:
Use this:
sxm1972sxm1972
I found this blog post which suggested adding a firewall exception for 'Remote Administration', and that worked for us on our Windows Server 2008 Enterprise systems.
AlanAlan
If you've tried some of the suggestions in the other answers, most notably:
- David Brabant's answer: confirming the
Windows Management Instrumentation (WMI)
inbound firewall rule is enabled - Abhi_Mishra's answer: confirming DCOM is enabled in the Registry
Then consider other common reasons for getting this error:
- The remote machine is OFF
- You specified an invalid computer name
- There are network connectivity problems between you and the target computer
Twisty ImpersonatorTwisty Impersonator
Solved.
I was running into the exact same error message when trying to execute the following script (partial) against a remote VM that was configured to be in the WORKGROUP.
I noticed I could run the script from another VM in the same WORKGROUP when I disabled the firewall but still couldn't do it from a machine on the domain. Those two things along with Stackflow suggestions is what brought me to the following solution:
Note: Change these settings at your own risk. You should understand the security implications of these changes before applying them.
On the remote machine:
- Make sure you re-enable your Firewall if you've disabled it during testing.
- Run Enable-PSRemoting from PowerShell with success
- Go into wf.msc (Windows Firewall with Advanced Security)
- Confirm the Private/Public inbound 'Windows Management Instrumentation (DCOM-In)' rule is enabled AND make sure the 'Remote Address' property is 'Any' or something more secure.
- Confirm the Private/Public inbound 'Windows Management Instrumentation (WMI-In)' rule is enabled AND make sure the 'Remote Address' property is 'Any' or something more secure.
Optional: You may also need to perform the following if you want to run commands like 'Enter-PSSession'.
- Confirm the Private/Public inbound 'Windows ManagementInstrumentation (ASync-In)' rule is enabled AND make sure the'Remote Address' property is 'Any' or something more secure.
- Open up an Inbound TCP port to 5985
IMPORTANT! - It's taking my remote VM about 2 minutes or so after it reboots to respond to the 'Enter-PSSession' command even though other networking services are starting up without problems. Give it a couple minutes and then try.
Side Note: Before I changed the 'Remote Address' property to 'Any', both of the rules were set to 'Local subnet'.
GrayDwarfGrayDwarf
I was having the same issue using foreach. I saved the list to $servers and used this which worked:
EricEric
Enabling following FW rules on target system resolved the problem on Win2k16:
- Windows Management Instrumentation (WMI-In)
- Distribiuted Transaction Coordinator (RPC)
- Distribiuted Transaction Coordinator (RPC-EPMAP)
TreborTrebor
Ayan MullickAyan Mullick
Thought I would add that we also ran into this issue with multiple machines in our domain. I created a list of offending machines and added them all to a text file from which to run the script. I ran this from the CMD prompt using elevated privileges.
hungry4pwrhungry4pwr
I faced the simillar issue on new server that I built through automated scripts via vcenter api. Looks like the 'Remote Procedure Call (RPC)' service may not be running on the remote machine. you need to wait for the service to come up to use the Get-WmiObject command. Hence I simply put the script into sleep for sometime and it worked.
RajaVRajaV
I had same issue, and for me, I was trying to use an IP Address instead of computer name. Just adding this as one more potential solution for people finding this down the road.
NealWaltersNealWalters
I just came to the exact same issue and found the answer here: http://powershellcommunity.org/Forums/tabid/54/aft/7537/Default.aspx
I had space characters at the end of each line the input file. If your file does too, just remove them and your script should work.
Anthony HoussaAnthony Houssa
I was doing this mistake
Which, of course, couldn't be passed, because output of the server in a csv file was @{Name=hv1g.contoso.com}
I had to call the property from csv file like this $server.Name
It fixed my issue.
Jan NevařilJan Nevařil
Not the answer you're looking for? Browse other questions tagged powershell or ask your own question.
In this scenario when are troubleshooting AD replication between 2 DCs separated by a firewall.
In order to ensure that the important well-known ports required in a domain environment are open on the firewall between these DCs, use the PortqryUI tool.
PortqryUI
http://www.microsoft.com/downloads/details.aspx?FamilyID=8355e537-1ea6-4569-aabb-f248f4bd91d0&displaylang=en
Run this tool on both these DCs to test the communication on a selected set of ports on the target DC (replication partner).
·Invoke PortqryUI.exe
·Enter replication partner’s IP or FQDN in the “Destination to query” textbox.
·Select Pre-defined query – “Domains and Trusts”.
·Hit the “Query” button and let it finish.
·Save the above output to a text file.
Go through the PortqryUI query result by searching for “Return Code” phrase in the output.
èIf the return code is 0, it indicates that this DC was able to communicate with its partner DC on that particular port.
èThe return code 2 is normally reported for UDP ports as we don’t get an ACK for that communication. This can be ignored if it’s returned for a UDP port.
èThe return code of 1 indicates that this DC was unable to talk to the target DC on the respective port. This either indicates that the service related to this port is not running on the target or that port is FILTERED on the firewall.
èAny other return code also needs investigation.
![Unavailable Unavailable](http://techgenix.com/tgwordpress/wp-content/uploads/2016/10/Screenshot-60.png)
Sample output of PortqyrUI
In our scenario, we need to ensure that the following ports are open on both these DCs.
·TCP 135 – Endpoint mapper
·TCP,UDP 389 - LDAP
·TCP, UDP 88 - Kerberos
·TCP 445 - SMB
·TCP 139 – SMB, Namepipe
·TCP, UDP 53 – if these servers are DNS servers too.
Out of the above ports, the one that is most IMP to look at in the RPC related errors is TCP 135.
à This is the Endpoint Mapper port. A DC would first communicate with its partner on port 135 to get the details of the TCP ports the NTDS and Netlogon services are listening on. It’s only when it gets this response from the Endpoint mapper that it would communicate with the NTDS (DRS) and Netlogon service on the target DC (Partner DC).
To get the list of the Endpoints on the partner DC and get the list of services and the ports associated with it, we can use another tool called RPCdump. This tool also has the capability of checking if source server can communicate with all endpoint on the destination server.
RPCdump is a part of Windows resource kit.
Command : RPCDUMP /s destination_server /v /i > RPCdump_destination.txt
In our scenario, we need to review the TCP port the DRS Interface is listening on. You can either search using the phrase DRS or using the following UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2.
Other UUIDs:
e3514235_4b06_11d1_ab04_00c04fc2dcd2DRS
12345778_1234_abcd_ef00_0123456789abLSA
12345678_1234_abcd_ef00_01234567cffbNETLOGON
12345778_1234_abcd_ef00_0123456789acSAM
When looking at this log we need to check if for the respective UUID and IsListening result.
èIsListening:YES – this means that the source server was able to communicate with target server on the respective port.
èIsListening:NO – means that this port is filtered on the firewall.
èIsListening:Unknown – this may mean that you need to investigate further as packets targeted to the respective port may not be reaching the server. In this scenario a simultaneous network trace may help.
Yon can confirm if the source server can communicate to the destination server on a particular port by using PortqryUI again. This time specify a Port instead of a predefined query.
If you find that the DRS and Netlogon service ports cannot be communicated to, from either of the 2 DCs which are suppose to replicate with each other. Then we should have the network team analyse the Firewall/network device - to allow communication on this port.
In some scenarios, you will see that the above 2 test pass and the DCs are able to communicate with each other on the required ports, but then too the AD replication fails with RPC server unavailable message.
In this scenario, we need to install Network Monitor on both the source and target DCs.
·Start network monitor capture on both these DCs simultaneously.
·Force AD replication between these DCs using “AD sites and services” snap-in.
·Leave the network monitor for 2 to 3 mins after initiating the replication and then stop it.
**The main thing to analyse in this network trace (for RPC errors) is to check if any packets between these DCs are getting dropped. This can be done by looking at the communication between these 2 DCs, in both the simultaneous network traces. If there are packets visible on 1 trace which is not reflected in the other trace, it would indicate that the packet may have got dropped.
I have seen a few firewalls with “Intrusion Prevention System” drop selective packets.
Network Monitor
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
The above troubleshooting should be able to indicate the reason behind the RPC server unavailable messages for sure.
Talking of the communication issue between the DCs specially when seperated by a firewall, I suggest you review the information below to configure you DCs and firewall. The idea is to avoid opening large number of ports to allow RPC communication, hence making your network more secure and have a better control on the communication behaviour of these DCs.
Dynamic RPC ports are used by Netlogon, NTDS, FRS, DFSR service etc. and these ports are picked from the range 1024-65535/TCP.
If you want to restrict the range of ports, the services would pick from, for RPC communication, then follow the KB article below and define a range of port to be used for RPC dynamic allocation.
How to configure RPC dynamic port allocation to work with firewalls
http://support.microsoft.com/kb/154596/
If you want to specify static ports for known services on DC like Netlogon, NTDS, FRS etc. then follow the articles below.
Restricting Active Directory replication traffic to a specific port
http://support.microsoft.com/?id=224196
How to restrict FRS replication traffic to a specific static port
http://support.microsoft.com/?id=319553
IMP: If you are modify the RPC range or assigning static RPC ports then you just need to open those port in the firewall, instead of the range 1024-65535/tcp. If you plan to place a firewall between the client and DCs in the main site, you need to allow most of the above exceptions on that firewall too.
In case you add Windows 2008 DCs in your domain, you need to know that the default dynamic port range has changed in Windows 2008 starting from 49152/tcp.
The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
http://support.microsoft.com/?id=929851