Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
WMI, PowerShell, and Windows Firewalls - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • WMI, PowerShell, and Windows Firewalls
KB0549828

WMI, PowerShell, and Windows Firewalls


16616 Views Last updated : Jul 22, 2025 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Issue

 

This article discusses how to open ports in Windows Firewall to access the remote server.

Release

All

Resolution

 

Windows Firewall and DCOM ports

For remote Windows machines where Windows Firewall is enabled, it is not enough just opening port 135 to have Discovery successfully discover the machine. When the MID Server knocks at the door of RPC on the remote server through port 135, the remote machine announces a (dynamic) port that the MID server must use in order to access DCOM back on the remote server. The port announced by the RPC server on the remote machine is one of a range of ports (unless RPC is configured to run with a static port).

The default ranges of DCOM ports are:

  • From 1025 to 5000: Windows 2000, Windows XP, and Windows Server 2003
  • From 49152 to 65535: Windows Server 2008 and later versions, and in Windows Vista and later versions

If the range of DCOM ports is not opened in the Windows Firewall, Discovery fails with the next error response to the WMIRunner - WMI: Classify probe:

<error>
Authentication failure with the local MID server service credential.
</error>
<error>
  Failed to access target system.  Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))  
   Stack Trace:  
      at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)  
      at System.Management.ManagementScope.InitializeGuts(Object o)  
      at System.Management.ManagementScope.Initialize()  
      at System.Management.ManagementObjectSearcher.Initialize()  
      at System.Management.ManagementObjectSearcher.Get()  
      at Microsoft.PowerShell.Commands.GetWmiObjectCommand.BeginProcessing()  
      at System.Management.Automation.Cmdlet.DoBeginProcessing()  
      at System.Management.Automation.CommandProcessorBase.DoBegin()
</error>

How to open ports to the MID Server

ServiceNow recommends that the MID Server application host machine has access to the targets on all ports due to the unique nature of the WMI requirements (see MID Server Requirements for more information). However, in cases where a customer chooses not to open all ports to the MID server, here are the alternate solutions:

1 - Open port 135 on the Windows Firewall

For Windows 2000, XP, Server 2003:

This solution consists of adding an Exception to Windows Firewall. Follow these steps:

  1. Go to Control Panel > Windows Firewall > Exceptions > Add Port...
    • Name: RPC Endpoint Mapper - TCP Port 135
    • Port: 135
    • TCP

For Windows Server 2008, Vista, and later:

This solution consists of adding a rule to Windows Firewall with Advanced Security to open the port 135/RPC. Follow these steps:

  1. Go to Administrative Tools > Windows Firewall with Advanced Security.
  2. Go to Inbound Rules (right-click) > New Rule...
  3. [Rule Type]: Select Custom and click Next.
  4. [Program]: Select All programs.
  5. [Program]: Under Services:
    1. Click Customize.
    2. Select Apply to this service: Remote Procedure Call (RPC) - RpcSs
    3. Click OK to close the dialog box.
    4. Click Next.
  6. [Protocol and Ports]: Select Protocol type: TCP.
  7. [Protocol and Ports]: Select Local port: RPC Endpoint Mapper.
  8. [Protocol and Ports]: Keep Report port: All Ports, and click Next.
  9. [Scope]: Keep Which local/remote IP addresses does this rule match: Any IP address (you might need to set it different for your security policy), and click Next.
  10. [Action]: Select Allow the connection.
  11. [Profile]: Select Domain, Private, and Public (you might need to set it different for your security policy), and click Next.
  12. [Name]: Give the rule a name (for example, RPC Endpoint Mapper - TCP Port 135), and click Finish.

It is possible that other predefined rules already allow access to 135/RPC. That is the case of the rule File and Printer Sharing - RPC-EPMAP.

2 – Open access on the Windows Firewall to the standard DCOM ports

For Windows 2000, XP, Server 2003:

This solution consists of adding exceptions to Windows Firewall. Because there are many exceptions to add, run this script to add the entries for you. Follow these steps:

  1. Ensure that port 135 is open (see section #1).
  2. Open a command line and enter:
    FOR /L %I in (1025,1,5000) do netsh firewall add portopening TCP %I "Dcom - TCP Port "%I
    This adds an entry per port to the Windows Firewall (3975 entries). If you find that there are too many entries, follow the steps in section #3  to have DCOM use only a few ports.

For Windows Server 2008, Vista, and later:

There are a couple of ways to achieve this:

  • Add the Exceptions to Windows Firewall running the command of the previous section, but this time, use the range of DCOM ports for Windows 2008. For that, substitute(1025,1,5000) in the command by (49152,1,65535). This adds an entry per port to the Windows Firewall (16383 entries). If you find that there are too many entries, follow the next steps in section #3 to have DCOM use only a few ports.
  • Add rules to Windows Firewall with Advanced Security from section #1. Follow these steps:

    1. Make sure that port 135 is open (see section #1).
    2. Go to Administrative Tools > Windows Firewall with Advanced Security.
    3. Go to Inbound Rules (right-click) > New Rule...
    4. [Rule Type]: Select Custom, and click Next.
    5. [Program]: Select All programs.
    6. [Program]: Under Services:
      1. Click Customize...
      2. Select Apply to all programs and services.
      3. Click OK to close the dialog box.
      4. Click Next.
    7. [Protocol and Ports]: Select Protocol type: TCP.
    8. [Protocol and Ports]: Select Local port: Dynamic RPC.
    9. [Protocol and Ports]: Keep Report port: All Ports, and click Next.
    10. [Scope]: Keep Which local/remote IP addresses does this rule match: Any IP address (you might need to set it differently for your security policy), and click Next.
    11. [Action]: Select Allow the connection.
    12. [Profile]: Select Domain, Private, and Public (you might need to set it differently for your security policy), and click Next.
    13. [Name]: Give the rule a name (for example, DCOM - TCP Dynamic RPC), and click Finish.

3 – Configure DCOM to use only a few ports (optional)

Configure DCOM by adding 100 ports: 65000 – 65100:

  1. Go to Administrative Tools > Component Services.
  2. Go to Console Root > Component Services > Computers > My Computer (right click) > Default Protocols > "Connection-oriented TCP/IP" > Properties...
  3. Add Port range: 65000-65100.
  4. Restart the server.
  5. Follow the steps in section #2. For Windows 2000, XP, Server 2003 substitute (1025,1,5000) in the command by (65000,1,65100). This adds 100 entries to the Windows Firewall.
 Note: This is a really low value and would result in Discovery (and other remote applications) running too slow.

Related Links

Windows Discovery – Troubleshooting WMI/Powershell issues on the remote machine 


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.