CA Service Desk Manager Considerations
For a successful CA Service Desk Manager (CA SDM) implementation in your environment, review the following points before starting the installation:
For a successful CA Service Desk Manager (CA SDM) implementation in your environment, review the following points before starting the installation:
Review the following points for Advanced Availability and Conventional Configuration considerations:
When planning for CA SDM deployment from a Scalability perspective, ensure that the upper limit of 64 processes is adhered to on the Primary Server. If the number of processes exceeds 64 on a Primary Server, plan to have the additional processes on a CA SDM secondary server. CA SDM Out of the box installation can ideally have up to 40 Processes on a server. Note that adding a new web engine domserver results in 3 more processes.
If you have installed xFlow Interface with CA SDM and when you restart CA SDM Services, ensure to restart the xFlow Analyst Interface Services too.
Consider dedicating a server to install the Search Server. The search server has built-in clustering feature and can be installed on a standalone setup. For large customers, we recommend installing the search server on three or more servers and manually configure it to a fault-tolerant cluster.
Default User Information
The following table lists default user information for a typical CA SDM implementation:
How it is Created?
Created while configuring CA EEM.
Microsoft SQL Server
Created in Microsoft SQL Server during configuration.
Created in Oracle database during configuration.
CA Service ManagementAdmin User
Created in the MDB during configuration.
CA Service ManagementAdmin User
Created in the database during configuration.
CA Service ManagementAdmin User
User authentication does not work if the system is using shadow files and there is an x in the password field of the /etc/passwd file. Users cannot log in to CA SDM. The password that you have specified for the CA SDM privileged user must conform to the password policy imposed by the network domain. If the password confirms to the policy, then only CA SDM configuration works.
- When installing CA SDM, do not install the CA Shared Components in the same directory as the CA SDM installation directory (NX_ROOT).
- References to NX_ROOT pertain to the environmental variable containing the installation path of CA SDM. The NX_ROOT variable is set in the NX.env configuration file that is used to set environment variables for CA SDM.Example:NX_ROOT Definition @NX_ROOT=C:\Program Files(x86)\CA\Service Desk Manager
- Do not specify spaces in the installation media path and folder name to avoid installation failure.
When you are installing CA Service Desk Manager for the first time, the Options Manager
copy_inactiveweb option is not installed by default. The links to inactive objects are not copied. Consider the following information when you do not install the copy_inactive option:
- CA SDM copies SRELs that point to inactive objects when SREL is required. For example, Organization org1 has an inactive Location. When you copy org1, the new organization does not have a location. However, if SREL is required, CA SDM ignores this rule and copies the location. CA SDM ignores the rule and you can copy a CI with an inactive class.
- CA SDM does not copy LREL (many-to-many) relationships to inactive objects. For example, the CI namedCITest1has a relationship to the inactive Organization org2. When you copyCITest1, org2 does not link to the new CI.
- These rules also apply when you copy a ticket, even when you create a ticket from a template. Even if you have installed copy_inactive, the exception to the rule is for Inactive Areas and Categories, which are not copied from existing tickets or populated from the templates.
- If CA SDM has been configured with one database, and then the configuration is run a second time with a different database type, the configuration does not work. For example, you initially configure the Microsoft SQL Server and then, you configure again for an Oracle database. The workaround is to restart the computer before the second configuration is run.
- Database connection information, if different, is not accepted in subsequent configurations. If an extra configuration is needed as a result of a change in the database connection information, delete the $NX_ROOT\NX.env file before proceeding.
- For configuring a 64-bit Oracle 11g database on a 64-bit computer, you must also install the Oracle 32-bit Client on the server. When configuring the database, the system library path must point to the 32-bit Oracle libraries. This step is required for both configuration and runtime. Also, create a net service name on the Oracle client to point to the Oracle database server instance.
- Suppose that you are using an Oracle database and you want to use existing tablespaces. Create a Data tablespace that is at least 400 MB, and an Index tablespace that is at least 100 MB before configuring CA SDM.
- Set the Oracle environment variables before you install or migrate CA SDM, as follows:
- Verify that the ORACLE_HOME variable is set correctly. You must export TWO_TASK variable when Oracle 32-bit client variables are exported on non-windows.
- Include the 32-bit Oracle libraries (commonly $ORACLE_HOME/lib32 for 64-bit Oracle) in the library path variable LD_LIBRARY_PATH.
Web Server Considerations
- Tomcat is set as the default CA SDM web server during the product installation. You can also use the following web servers based on your requirement:
- Internet Information Services (IIS)Applicable only on Windows. If you want to use IIS as the CA SDM web server, you must configure the IIS before installing CA SDM. For more information about how to configure IIS, see Configuring IIS.
- ApacheApplicable only on Linux and Solaris. If you want to use Apache as the CA SDM web server, you must configure the Apache before installing CA SDM.
- If Tomcat is configured with the external authentication on the primary server, set up a secondary server with a webengine and repository daemon. This setup allows users that are not authenticated to use attachments. The Tomcat installation on the secondary server cannot use external authentication.
- The CA SDM installation uses the Tomcat port8080. Other CA products, such as CA Asset Portfolio Management or the Service Delivery Suite of products also uses Tomcat port to 8080. If you are installing multiple CA products on the same server, select a port number other than 8080 for subsequent CA product installations. Selecting a different port number helps the products function properly together. To change the Tomcat port number to something other than 8080 for CA SDM, install the product and if the product is already installed, re-run the product configuration and specify an available port number for Tomcat when prompted.
- After CA SDM restart, the CA SDM Tomcat process may not start properly. To start Tomcat properly, stop and restart Tomcat using the following commands:pdm_tomcat_nxd -c STOPpdm_tomcat_nxd -c START
Configuring Internet Information Services (IIS)
Follow these steps:
- Launch theServer Manageron the IIS installed server.Server ManagerDashboardscreen opens.
- Navigate toLocal Serverand go toROLES AND FEATURESsection.
- SelectAdd Roles and Featuresoption from theTASKSdrop-down list.The Add Roles and Features wizard opens.
- ClickNexton theBefore You Beginscreen.The Select installation type screen opens.
- Select theRole-based or feature-based installationradio button and click Next.The Select destination server screen opens.
- Select theSelect a server from the server poolradio button and ensure that the local server is listed in the Server Pool section. ClickNext.
- TheSelect server rolesscreen opens.
- SelectWEB SERVER (IIS)from the Roles list.The Add features that are required for Web Server (IIS)? window opens.
- ClickAdd Featuresand then clickNext.The Select features page opens.
- Select the additional IIS features as required and clickNext.The Web Server Role (IIS) screen opens.
- ClickNext.The Role Services page opens.
- Select the following from theRole Servicesand clickNext.You can optionally select the other role services as required.
The Confirm installation sections screen opens.
- Web Server
- Common HTTP Features
- Default Document
- Directory Browsing
- HTTP Errors
- Static Content
- Health and Diagnostics
- HTTP Logging
- Static Content Compression
- Request Filtering
- Management Tools
- IIS Management Console
- Application Development
- Server Side IncludesIf you do select CGI, then only the web browser launches CA Service Desk Manager. The web browser attempts to open PDMWEB.EXE file.
- Review the roles and features you selected to install, and clickInstall.
- ClickClosewhen the installation is completed.
- Launch theCommand Line Interfaceand run the following command:pdm_configureTo run the command pdm_configure, you must have the privileged user access or root access on the CA SDM server.
- Multi-byte Characters -You cannot use multi-byte characters for the user you are logged in as or for the CA SDM privileged username. This applies when you install on multi-byte operating systems such as Simplified Chinese and Japanese. Knowledge searches containing multi-byte Japanese characters works properly with SQL Server only when SQL Server is installed with Windows collation. Ensure to specify the Collation option for your data during the SQL Server installation.Do not specify multi-byte characters in the file path names during installation and configuration. Doing so causes failure.
- UTF-8- CA SDM must run on UTF-8 locale on Linux and UNIX platforms.
- TimespanSymbol names that are provided with the default CA SDM installation (Administrationtab,Service Desk,Application Data,Codes,Timespans) are in English. For example, TODAY, YESTERDAY, THIS MONTH.For localized versions of the product, administrators may want to define new localized Timespans as required. Do not delete or modify the default Timespans.
- Date formats-in CA SDM do not support international specifiers such as, localized date-picture specifiers. For example, "jj/MM/AAAA" for French. The syntax is limited to generic specifiers such as "DD/MM/YYYY". However, many international short date-time patterns can be constructed from these generic specifiers (for example, "YYYY.MM.DD" would supply a common Japanese short date format).International users may want to adjust theDateFormatproperty inweb.cfgto use the date and date-time formats.
- For outbound plain-text email notifications, theNX_SMTP_HEADER_CHARSETandNX_SMTP_BODY_CHARSEToptions may have to be adjusted in the NX.env file. Adjusting the options helps to tag the email message correctly with the character encoding used by the international operating environment. The default values for these options are set to UTF-8 on all platforms.
- International users may want to change the default spell check locale in lexicon to a regional locale. Use theLEX_LANGoption in the Options Manager.
- Short File Names-TEMPandTMPenvironment variables to a short file name. For example,c:\temp, after enabling short file names. For more information, see Microsoft Knowledge Base Article 121007.
- Web Interface and Internet Information Services (IIS):
- Localized releases of CA SDM are supported only on the matching localized Windows server operating environment. In all cases, configure theLanguage for non-Unicode programsfor your system to support the target certified language. This setting is available in theRegional and Language Optionswindow in the Control Panel.For more information about the localized releases of Windows Server operating systems, see the Microsoft Global Development and Computing Portal.
Support Automation Considerations
You can use the following information to research and can gather information to help you plan for a successful Support Automation configuration.
- Server and Network
- Main ServerSupport Automation uses main application server. The server provides socket-based and HTTP-based communications.
- Socket Proxy ServerSupport Automation uses a socket proxy on the same tier as the web server. The web server off-loads encryption/decryption processing from the main server for direct socket connections to support scalability.
- Message Routing Server (MRS)Support Automation segregates high bandwidth and unpredictable traffic from the main application server. This segregation helps in supporting server scalability and provides a network routing shortcut for geographical scalability using the remote control connections.
- Server Sizing
- Network characteristics of end-user and analyst connectionsThe server load is directly proportional to the data of the message routing component. Low bandwidth, high latency, and high packet loss contribute significantly to lowering the load on the server. When network conditions are optimal (high bandwidth, low latency, low packet loss), the speed on the server is much higher. The total number of concurrent analyst users and end-user logins per minute, including self-service user, can place a heavy load on the server.
- Connection typeThe number of socket connections, as opposed to the number of HTTP connections, affects the servers as follows:
- When you connect predominantly through socket connections, the load on the servers is light. If we assume powerful hardware, the application is network bound rather than CPU bound. The hardware does not limit the number of concurrent connections but rather the network can limit the connections.
- When you connect through HTTP, the load on the web and application servers is higher and the application is CPU bound unless scaled significantly.
- Remote Control usageRemote Control uses significant network bandwidth in a sustained way whenever it is running. All traffic that is routed between end users and analysts flows through the server. The number of concurrent Remote Control connections has a significant role in any sizing assessments.Remote Control is the only high-bandwidth tool in the Live Assistance tool set. Chat and Automation are low bandwidth. Screenshot and File Transfer can use high bandwidth for short periods while files are transferred.
- Network and BandwidthThe amount of bandwidth a system consumes depends on the tools that you employ.
The following chart illustrates the required bandwidth depending on the tools that you:Tools/BandwidthChat/AutomationRemote Control< 3 KBps (28.8 kbps dial-up)Very fast and responsiveSlow< 5 KBps (< 56 kbps dial-up)Very fast and responsiveAdequate with image degradation< 50 KBps (Cable/ADSL)Very fast and responsiveVery fast and responsive< 100 KBps (LAN)Very fast and responsiveVery fast and responsive
- For the Chat and Automation features, the bandwidth requirement is small. A dial-up modem of 56 kbps or less is adequate to support these functions.
- For theRemote Controlfeature, the bandwidth requirement is more. However, Live Assistance Remote Control automatically adapts to low-bandwidth environments by reducing the image quality and refresh rate of the remote control session.
- The amount of bandwidth also depends on the connection models that you employ. Two connection models are available:
- HTTP connectivity -- Use HTTP when behind a restrictive firewall and the firewall allow HTTP connections to the server.
- SSL direct socket -- Use SSL direct socket when you connect to the server using a connection on the SSL port443.
CA SDM Server Components
CA SDM includes components that work together and run on different servers, depending on the CA SDM configuration. Before you begin your implementation, ensure that you have a basic understanding of the following components:
Daemon Manager (pdm_d_mgr)
Starts process sets as defined in the startup file, pdm_startup. By default, the daemon manager tries to start a failed component up to 10 times. To check the status of all CA SDM components, use the
pdm_d_refreshutility instructs the daemon manager to start a new cycle of 10 attempts to start any process marked as previously failed.
The daemon manager runs on all CA SDM servers.
Message Dispatcher (sslump_nxd)
Acts as a common bus or message passing system. Components that require to communicate with each other first register with the Message Dispatcher. When a component sends a message, the Message Dispatcher delivers it to those components that have registered to receive that type of message. If two components communicate so much that it would be inefficient to pass the messages through the Message Dispatcher, they create a fast channel between them. You can view a list of registered components using theslstatutility.
The message dispatcher runs on the following servers, depending on your CA SDM configuration:
Database Agent (platform_agent)
Performs Microsoft SQL Server queries on the database. Database agents adhere to the logical schema of CA SDM and translate the SQL at this level to the physical database platform SQL.
The database agent detects momentary disconnection and failed queries, and attempts to reconnect and communicate with the database. This is only meant for short outages, such as for a brief network outage and momentary disconnection. It is not meant for long outages such as taking down a database service for maintenance and so forth. The agent only retries the connection for a defined number of times (the default is 3 times), and only for a short time period of a few minutes interval. If the outage is longer thanfew minutes, the agent stops trying to connect. CA SDM must be recycled after the database is made available again.
The database agent runs on the following servers based the CA SDM configuration:
Virtual Database (bpvirtdb_srvr)
Enables the operation of multiple Object Managers. All Object Managers running on primary or secondary servers connect to the Virtual Database, which arbitrates their access to database agents. For example, when retrieving a new range of ticket reference numbers, the Virtual Database ensures that only one Object Manager at a time accesses the table containing the reference numbers. The Virtual Database also performs caching of database information for Object Managers.
The Virtual Database runs on the following servers:
Continuous Archive and Purge (arcpur_srvr)
Runs the archive and purge rules as configured by the CA SDM administrator.
The Continuous Archive and Purge runs on the following servers:
Database Monitor (dbmonitor_nxd)
Monitors changes to common tables in CA MDB, for example, ca_contact.
The Database Monitor runs on the following servers:
Mail Daemon (pdm_mail_nxd)
Sends outbound email notifications.
The Mail Daemon runs on the following servers:
Mail Eater (pdm_maileater_nxd)
Accepts inbound email for ticket creation and updates.
The Mail Eater daemon runs on the following servers:
Notification Manager (bpnotify_nxd)
Manages notifications in a Windows environment.
The Notification Manager runs on the following servers:
Spell Checker (lexagent_nxd)
Performs spell checking as requested by users. The Spell Checker runs on all CA SDM servers.
Text API Daemon (pdm_text_nxd)
Creates and updates tickets by external interfaces, such as command line and email. The Text API daemon runs on all CA SDM servers.
Timed Event (animator_nxd)
Runs the delay times of events. If an implementation has many service types or contracts, the Timed Event engine tracks the active events. You must dedicate the primary server Object Manager entirely to the Timed Event engine. You can configure other Object Managers on the primary or secondary servers for product access as appropriate.
The Timed Event daemon runs on the following servers:
Calculates projected violation times for service types.
The Time-To-Violation daemon runs on the following servers:
Proctor Daemon (pdm_proctor_nxd)
(For Windows only) Starts and restarts the CA SDM components, as instructed by the Daemon Manager, on primary and secondary servers. When you install a secondary server, the
pdm_proctor_nxdprocess is installed as the CA SDM Remote Daemon Proctor service. When the primary server starts, the Daemon Manager instructs the Remote Daemon Proctor to connect to the Message Dispatcher. The Daemon Manager then instructs the Remote Daemon Proctor to start components on the secondary server. The process for starting the components is defined by the Process Sets in the startup file
The Proctor daemon runs on all the CA SDM servers in advanced availability configuration.
Object Manager (domsrvr)
Acts as the server process of CA SDM. When you install a primary server, by default, two Object Managers are installed: one for connections to the product, and one dedicated to the Web Screen Painter. Having multiple Object Managers helps you test your modifications without affecting the production environment. When you install a secondary server, you can configure more Object Managers.
There must always be a default Object Manager running on the primary server to which clients such as the Timed Event engine can connect.
The Object Manager also caches various records and tables for clients. If you use
pdm_userloadto manipulate these records, you can also use the
pdm_cache_refreshutility to make the Object Manager retrieve the new data.
The Object Manager runs on all the CA SDM servers in advanced availability configuration.
The dedicated object managers have been added for heat weather daemon and reminder daemon.
Method Engine (spel_srvr)
Runs SPEL code, event, macros, and so forth, for an Object Manager. We recommend that you run every Object Manager with its own method engine.
The Method Engine runs on all CA SDM servers.
Login Server (boplgin)
Manages authenticated user sessions.
The Login Server runs on the following servers:
LDAP Virtual Database (ldap_virtdb)
Interfaces with an LDAP directory.
The Method Engine runs on the following servers:
Knowledge Management Search Daemon (bpebr_nxd)
Performs knowledge base searches. Upon CA SDM startup, the
bpebr_nxddaemon caches Knowledge Document data in its memory from the database. With a large document base, you might have memory resource issues. The
bpebr_nxddaemon has the following size requirements:
Knowledge Management Search
The Knowledge Management daemon runs on the following servers:
Knowledge Management/Keyword Indexing Daemon (bpeid_nxd)
Indexes the knowledge base
The Keyword Index daemon runs on the following servers:
Knowledge Management FAQ Ratings Daemon (bu_daemon)
The bu_daemon runs on the following servers:
Knowledge Report Card Daemon (krc_daemon)
Performs the calculations for the Knowledge Management Knowledge Report Card (KRC) feature. This feature enables analysts and managers to display different matrix views of their knowledge contributions and provide feedback about which documents are most effective. The information that is provided can be used to improve the processes of creating knowledge documents and providing the best support to customers.
The Knowledge Report Card daemon runs on the following servers:
Knowledge Management Daemon (kt_daemon)
Manages knowledge base administration and knowledge management logic. It also manages notifications and the document approval process.
The Knowledge Management daemon runs on all CA SDM servers.
Repository Daemon (rep_daemon)
Manages the attachment repositories for CA SDM and the Knowledge Management/Keyword Search Daemon.
The Repository Daemon runs on the following servers:
Version Control Daemon (pdm_ver_nxd)
Synchronizes the schema files between a primary and secondary server to ensure that they are using the same schema.
The Version Control Daemon runs on the following servers:
Apache Tomcat Web Server (javaw)
Enables certain features to be implemented, regardless of whether Microsoft Internet Information Server (IIS) is used as the web server for access to CA SDM. These features include Graph Items, Attachments, and Web Services.
The Apache Tomcat web server can be administered with the Apache Tomcat controller (
The Apache Tomcat Web Server runs on all CA SDM servers.
Web Engine (webengine)
Connects to web browsers through apdmwebcgirunning on a Microsoft IIS or Apache Tomcat web server. There must be at least one web engine for WSP on the following servers.
This process ensures that Web Screen Painter Schema Designer can write schema files. Web engines are the true client of an Object Manager, which the web browser uses to access the product. Web engine uses cache.htmplweb forms for connected users. You can manipulate the cache using the
pdm_webcacheutility and can see connection statistics using the
The Web Engine runs on all CA SDM servers.
RF Broker (pdm_rfbroker_nxd)
(Applicable for advanced availability configuration only). Manage the roles of the servers and controls them across the configuration. This daemon runs on all servers in advanced availability configuration and performs the following tasks:
Login User Authentication (bopauth_nxd)
This daemon performs the operating system user account validation. To match a user with an access type, the contact record lookups using the System Login field.
If your business provides CA SDM for other client businesses, place the Login server on a secondary server at a single client location. The external authentication is then enabled in access types. Based on the CA SDM configuration, the daemon runs on the following servers:
Interval Logger (pdm_intrvlog_nxd)
The interval logger daemon gathers the debugging information for debugging the system. Runs on all CA SDM servers.
QRY KPI Daemon (kpi_qry_daemon)
Executes the SQL queries for updating the Key Performance Indicators (KPIs) in the database. The QRY KPI daemon runs on the following servers:
SYS KPI Daemon (kpi_sys_daemon)
Daemon to collect system type key performance indicators and write to the database. The SYS KPI daemon runs on the following servers:
Confirm Database (confirm_db)
A utility to verify database access that runs on all CA SDM servers.
Data Dictionary (ddictbuild)
A utility to build the data dictionary and runs on all CA SDM servers.
Set LogFile (pdm_logfile)
A utility to display or set the log file size limits. The
pdm_logfiledaemon runs on all CA SDM servers.
Report Manager (pcrpt_nxd)
A utility for PC reporting that runs on all CA SDM servers.
RPC Server (rpc_srvr)
Used for making outbound SOAP web service calls and runs on all CA SDM servers.
CA SA Tomcat (sa_tomcat)
CA SATomcat to run support automation and can be configured on any CA SDM server.
Visualizer Tomcat (viz_tomcat)
The Tomcat instance to run visualizer and can be configured on the following servers:
Event Manager (ehm_nxd)
The Event Manager manages events coming from CA NSM. The Event Manager runs on the following servers:
Knowledge Management Indexing Daemon (bpeid_nxd)
Responsible for indexing the knowledge documents and runs on the following servers:
Registration Server (mdb_registration_nxd)
An agent for handling MDB registration requests. The Registration Server runs on the following servers:
Search Deamon (es_ebl)
Responsible for the CA SDM data sync with the elastic search server.
Deamon syncs new log comments & attachments with Catalog.
: Sync only happens for Incidents/Change Order created by Catalog.
SDM Telemetry Deamon
New singleton process which will read kpi data and push into the segment for Telemetry.
Heat Weather Deamon (pdm_hw_nxd)
Calculates the heat of tickets and weather for analysts.
: The Demon runs only when the xFlow is enabled.
Reminder Deamon (reminder_nxd)
Responsible for triggering the follow-up reminders for tickets.
: The Demon runs only when the xFlow is enabled.