What ports does an ITSM 17.1 system use?

Document ID : KB000112054
Last Modified Date : 24/08/2018
Show Technical Document Details
Question:
What ports does an ITSM 17.1 system use?

We are going with a conventional configuration, with the following Windows application servers (3 remote Microsoft SQL servers will host the SDM, Insights & JasperSoft databases).

1 SDM Primary Server
1 SDM Secondary Server (Hosting xFlow & running 1 Web Directory & 2 Web Engines, and the attachment repository).
1 Search Server
1 Collaboration Server
1 CABI JasperSoft Server

We will NOT be using the following:

SDM Components (REST Web Services, SOAP Web Services, Federated Search, CA Support Automation, CA Service Mobile Applciation, CMDB Visualizer or populating the CMDB).
Unified Self-Service (USS)
CA Embedded Entitlements Manager (CA EEM)
CA Configuration Automation
CA Process Automation (aka Process Management For Workflows)
CA Service Catalog
CA Asset Portfolio Management (CA APM) / CA IT Asset Manager (CA ITAM)
CA Software Asset Manager (CA SAM)

We need to have TLS/SSL enabled for all traffic.

Under "CA SDM" this document lists FTP, WebEx, oaserver, qserver & Communications are you able to advise the purpose of these?
I don't believe I will be authorised to open port 21 for FTP and as stated above we aren't going to install CA Support Automation.
 
Environment:
ITSM 17.1 and most other versions.
Answer:
The best way of working out the ports is to stand up a system and then monitor with netstat or similar.

This port document is accurate and can be relied upon:
Please see https://docops.ca.com/ca-service-management/17-1/en/installing/installation-prerequisites/supported-ports-and-port-ranges

However, some of the port information though is there from legacy parts of the product.
Not every site will use all components.

So typically sites can harden ports down from this list. We recommend that a test system be "open" first and then "hardened" later. This makes sure that the integrations are all working first.

Hardening should be one of the last things done, otherwise a lot of time can be spent troubleshooting issues that are caused by ports rather than the setup.
When the failure is due to a port, the messages may not be clear that there is a port issue. However, if everything is working first, and then a range of ports is closed off, it is much more obvious that functionality stops working due to the port closures.

Here is some information on the specific ports asked about.
Each site should do their own testing for confirmation.
While the above DocOps link gives information that is completed and tested, the following information is representative only and may not be complete.

FTP
This is used mainly by CA Remote Engineer:
https://support.ca.com/us/product-content/admin-content/ca-remote-engineer-ca-re.html

This is a tool that can gather up selected/or all of the log files, patch version, NX.env, site/mods and other settings from an SDM (or other CA product) installation, and optionally automatically upload it to a ticket via FTP.

If you are not using the FTP upload for CA Remote Engineer, then you can probably block this port.

oaserver
This is a legacy component used by ODBC (for BOXI) and that it may no longer be necessary.

It is only found in  BOXI contexts like this one:
https://comm.support.ca.com/kb/When-reinstalling-the-ODBC-server-driver-the-error-used-by-another-process-or-service-already-exists-is-received/KB000009116#/

qserver

This is old functionality that is probably not needed now by many sites, but may still have some currency. Perhaps if dual NICs are used (???).
Its purpose is "NAT Support": 
"When using the qserver (for NAT Support) the default port is 2234 - This is configurable in the NX.env - parameter = NX_QSERVER_PORT = 2234"

Communications

This port 2365 appears to be used in the following scenario. It was referenced in the following post, which I've attached for reference:

----------------
In regards to Question 1) "Firewall Ports to open," please review the information below: 

Ports Necessary for communication among SDM servers: 

If you are looking to have SDM accessible from outside, you would have to put a secondary or app server in your DMZ, for which you would have to open some ports between that secondary or app server and the primary or background server: 

Service Desk needs the following ports to be open in a bi-directional flow: 
Ports 2100 through 2200 for TCP and UDP 
Port 2365 for TCP and UDP 
Port 1433 for TCP and UDP 

In addition, you need to make sure that port 2300 is also open in a bi-directional flow. 
This port is used by the proctor to initiate the connection to the daemon_mgr. 
This is configurable in the NX.env - parameter = NX_MGR_PORTNUM=2300 

To go through a firewall - You will need to set NX_SLUMP_FIXED_SOCKETS = 1 on the primary server. 
Make sure that that SQL Server is using sockets not pipes, or ODBC will not work, even though you opened port 1433. 

Below, please find some technical documents that can be relevant, this is not exactly the same thing your looking for, but maybe you will be interested also in this info: 

What happens to Service Desk Manager Secondary Servers when there is a network connection loss with the primary server? 
https://comm.support.ca.com/kb/what-happens-to-service-desk-manager-secondary-servers-when-there-is-a-network-connection-loss-with-the-primary-server/kb000019588

How does CA Service Desk Manager (SDM) behave within a network. 
https://comm.support.ca.com/kb/How-does-CA-Service-Desk-Manager-SDM-behave-within-a-network/kb000019517 
----------------

Recommendations
Some big features were ruled out in the example installation, in particular Web Services which will be a base to many of the other items if you choose to implement these later. If you add these in later, you will obviously need to revisit the ports.

Most ports will need to be configured for bi-directional use.

You may like to do is to check Options Manager and NX.env for port information, just in case there is a port configured there that is not on the list. It is unlikely, but you never know when an installed system deviates from the standard ports . . . assigning a different port is the type of thing that can happen accidentally on-the-fly during installation or configuration.

Finally, don't forget things that happen which are LIKE port closures, such as Anti-Virus and Firewalls. These are also best typically disabled when testing restricting ports, as they can have a habit of throttling/blocking ports because of "excessive use" and it is best to isolate them for testing/setup purposes.

If a site needs to know what a specific port is used for, or what port a specific function uses, then please review CA Communities https://communities.ca.com/community/ca-service-management , or log an issue with support.ca.com, if the above DocOps reference is incomplete.