Base device discovery
For efficiency, BMC Discoveryuses ICMP ping to locate a device. It is possible to use other ping techniques if ICMP Echo is suppressed in your environment. To do so, on the Administration tab, scroll down to the Discovery section and click Discovery Configuration. On the Scanning section, enable the Use TCP ACK 'ping' before scanning and Use TCP SYN 'ping' before scanning check boxes, and enter the port numbers in the TCP ports to use for initial scan and UDP ports to use for initial scan fields.If you do not allow ICMP pings through the firewall and do not enable TCP Ack and Syn pings, you might lose performance. This is because the system performs a full "Access Method" nmap port scan to determine whether the host is actually present, which causes delays as it waits for requests to timeout. You must alter the "Ping hosts before scanning" setting to "No" in this situation. If there is a limited range if IPs for which ICMP Echo is suppressed, you can disable the ping behavior for these IPs by using the Exclude ranges from ping. For more information, see Configuring discovery settings.

To scan networks that do not permit ICMP ping packets, you may set Use TCP ACK ping before scanning or Use TCP SYN ping before scanning (or both of these) in your discovery settings to Yes. If BMC Discovery pings an IP address where there is no device and some firewall in your environment is configured to respond for that IP address, it may result in reporting a device which does not exist on the network rather than dark space (NoResponse). To avoid this, it is recommended to either alter such firewall configurations or not to enable TCP ACK ping or TCP SYN ping.

If BMC Discovery cannot connect to an endpoint, it uses heuristic techniques to estimate what sort of device is present. These are controlled by options in Configuring discovery settings.

Port 4 using TCP and UDP is required if using IP Fingerprinting as Discovery must observe the response from a guaranteed closed port on the endpoint.

Port 4 must be closed on the discovery target, but must be open on any firewall between the appliance and discovery target, so that the response is from the target rather than the firewall. Where this is not the case, the heuristic receives a response from two different TCP/IP stacks, leading to unpredictable results including the endpoint being classified as a firewall or an unrecognized device. This can lead to skipped devices (see UnsupportedDevice in the DiscoveryAccess page).

The ports listed in the following table are used to determine what device is present.

SNMP Ports used for discovery

The only port required for SNMP discovery is 161 UDP.

UNIX Ports used for discovery

The minimum port required for successful UNIX discovery is just the port associated with the access methods that you use. For example, if you only use ssh, this will be port 22. The following table details the assignment for each port number.

Windows Ports used for discovery 

This section describes the ports that the BMC Discovery appliance and BMC Discovery Outpost use when discovering remote Windows targets. If you intend to discover hosts behind a firewall, you must open these ports in the firewall. The ports given are outgoing (from the Windows proxy and the appliance) TCP ports.Windows targets and port 135The Outpost scans port 135 to determine whether the port is open. If port 135 is open, the target is likely to be a Windows host, and further discovery is performed accordingly. You can disable the scan of port 135. If you do so, BMC Discovery assumes that all targets are Windows hosts.To disable scanning port 135:

1. Select Administration > Discovery > Discovery Configuration.
2. Select No in the Check port 135 before using Windows access methods field.

WMI 

All WMI communication from BMC Discovery is sent with Packet Privacy enabled. If the host being discovered does not support Packet Privacy, the flag is ignored and WMI returns the requested information (for example, if you run a version earlier than Windows Server 2003 with Service Pack 1 (SP1)). In cases where a range is provided, one of the ports is used after initial negotiation.

By default, WMI (DCOM) uses a randomly selected dynamic port range for TCP between 49152 and 65535. For more information on this port range, see this Microsoft article .

To simplify the configuration of the firewall, you should restrict this usage if you scan through firewalls. See to set the DCOM Port Range for more information.

The ports that are used by WMI discovery methods and the corresponding assigned ports are described in the following table.

Windows NT4 and NT4 style domains (WMI)

TCP 139 is required instead of TCP 445 if you discover NT4 or you authenticate on an NT4-style non-AD Domain (such as a domain run using Samba 3.x or earlier).

TCP 139 is the NetBIOS Session Service. Some versions of Windows (particularly 9x/NT4) run SMB on NetBIOS over TCP using port 139. Newer versions default to running SMB directly over TCP on port 445. Windows XP/2003/Vista/2008 and later and Active Directory networks use SMB directly over TCP 445.

WMI queries from a Windows Server 2008 to a Windows NT4 host fail using the default security settings. On the Windows proxy host, turn off the requirement for 128 bit security in the Network security: Minimum session security for NTLM SSP based (including RPC) clients policy to permit this.

DCOM port range 

WMI is based on the Distributed Component Object Model (DCOM) which, by default, uses a randomly selected TCP port between 49152 and 65535 for communications. To make this more efficient for firewalls, the range can be restricted using the following procedure on each Target Host. For more information about this issue, see How to configure RPC dynamic port allocation to work with firewalls.

These settings should be restricted on the target host, not the Windows proxy host.

To set the DCOM port range:.

1. Using a registry editor, create the key HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet
2. Within that key create a REG_MULTI_SZ (Multi-String Value) called Ports.
3. Specify the port or port range to use.
   The Windows proxy uses only one port. However, if the user has other DCOM applications in use on that machine, you might need to enable a larger range.
4. Create a REG_SZ (String Value) called PortsInternetAvailable and give it the value Y.
5. Create a REG_SZ (String Value) called UseInternetPorts and give it the value Y.
6. Restart the computer.

RemQuery

Although WMI is the standard mechanism for remote system interrogation and management from Microsoft. However, some operations are not possible using WMI. Primarily netstat data in core discovery, and any additional commands run, or file content extraction, via patterns. Without RemQuery, it is not possible to determine network connection information for the discovery target, communication between that host and others, and application modelling based on network connections. Additional discovery operations using RemQuery are typically for deeper software discovery, modeling and versioning.

RemQuery is a BMC Discovery utility that uses the same basic approach as the Microsoft PSExec tool. The proxy copies the RemQuery executable to the ADMIN$ share on the target. Windows Administrator access is required to write to the ADMIN$ share and start the RemQuery service. Once the service is started on the target, the proxy sends its public key to the RemQuery service, which generates an encryption key, encrypts it with the received public key, and then sends it back. The proxy then recovers the encryption key using its private key. From that point, all proxy to RemQuery communication is secured using the encryption key and an appropriate algorithm, depending on the target system. RemQuery discovery uses AES encryption with a 256 bit key. AES is not supported in Windows 2000 so RemQuery discovery falls back to DES encryption. Windows NT does not support AES or DES so RemQuery discovery is unencrypted. The proxy communicates to the RemQuery service using a named pipe. This pipe is secured so that only an Administrator user can access it.

The ports that are used by RemQuery discovery and the corresponding port assignments are described in the following table.

Windows NT4 and NT4 style domains (RemQuery)

TCP 139 is required instead of TCP 445 if you discover NT4 or if you authenticate on an NT4-style non-AD Domain, such as a domain run using Samba 3.x or earlier.

TCP 139 is the NetBIOS Session Service. Some versions of Windows (particularly 9x/NT4) run SMB on NetBIOS over TCP using port 139. Newer versions default to running SMB directly over TCP on port 445. Windows XP/2003/Vista/2008 and later and Active Directory networks use SMB directly over TCP 445.

Mainframe Ports used for discovery 

The only port required for mainframe discovery is 3940 TCP. For more information about how to configure this port, see Discovery Configuration.

WBEM Ports used for discovery

The default ports used for WBEM discovery are described in the following table. For more information about how to configure this port, see Discovery Configuration.

Ports required for extended discovery

The following sections detail port information for extended discovery types.

SQL discovery 

The port information used for SQL discovery is derived in the patterns used to discover the particular database. This is dependent on the way that databases are configured in your organization. The following table details the default ports.

VMware ESX/ESXi discovery using vCenter 

The ports required for discovery of VMware ESX/ESXi hosts using vCenter are listed in the following table.

Discovery of vCenter

Discovery of vCenter uses standard host discovery with the creation of a vCenter SI triggered on a discovered vCenter process.

VMware ESX/ESXi discovery using vSphere

The ports required for discovery of VMware ESX/ESXi hosts are listed in the following table.