Hardware and Software Requirements for the Install

Review the following requirements before you proceed with the installation:
casm1401
Review the following requirements before you proceed with the installation:
Operating Systems
Find more information about version numbers of each operating system in the Supportability Matrix. Depending on the operating system that you use, ensure that you read the following consideration.
IBM AIX Operating Systems
  • Before installing CA SDM (or migrating from a previous release), the IBM XL C/C++ Runtime Environment version 9.0.0.9 (or later) must be installed and running on IBM AIX servers.
  •  You can integrate CA SDM with CA Business Intelligence, which uses Business Objects Enterprise XI, although we do not support installing CA Business Intelligence on IBM AIX.
  • On IBM AIX, install CA EEM by following the instructions that are provided when CA EEM is selected during installation.
CA SDM does 
not 
provide tools.jar and javac for AIX. Configuring REST Web Services and Support Automation requires the tools.jar file. To use the REST sample files, you must install javac on AIX. You can download the Java SDK for AIX from the IBM website in the IBM Developer kits section for Linux. Download the 32-bit binaries of Java SE and install JDK 1.7 SR4 on the AIX computer at any location. Copy tools.jar from the installed JDK location to <Shared Component>\JRE\1.7.0_04\lib and copy javac to \JRE\1.7.0_04\bin. You can also find the JRE location in the NX_JRE_INSTALL_DIR variable. You 
must
 copy the tools.jar file across all AIX installation, before you run the product configuration.
Redhat Enterprise Linux Operating Systems
  • You can integrate CA SDM with CA Business Intelligence, which uses Business Objects Enterprise XI, although we do not support installing CA Business Intelligence on Red Hat Linux.
  • Verify that you have the following Java libraries on Red Hat Linux to launch the product installer:
    • java-1.4.2-gcj-compat-1.4.2.0-40jpp.115
    • java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp.115
    • java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp.115
    • java-1.4.2-gcj-compat-src-1.4.2.0-40jpp.115
  • To install CA SDM on Red Hat Enterprise Linux 6.0 successfully, verify that you have the following RPM packages and their dependencies:
Required RPM
Dependencies
libXp-1.0.0-15.1.el6.i686.rpm
    • libXau-1.0.5-1.el6.i686.rpm
    • libxcb-1.5.1-1.el6.i686.rpm
    • libXext-1.1.3-1.el6.i686.rpm
    • libX11-1.3.2-1.el6.i686.rpm
libXtst-1.0.99.2-3.el6.i686.rpm
libXi-1.3.3-3.el6.i686.rpm
openssl-1.0.0-4.el6.i686.rpm
    • zlib-1.2.3-25.el6.i686.rpm
    • libselinux-20.94-2.el6.i686.rpm
    • keyutils-libs-1.4-1.el6.i686.rpm
    • krb5-libs-1.8.2-3.el6.i686.rpm
openldap-2.4.19-15.el6.i686.rpm 
    • db4-4.7.25-16.el6.i686.rpm
    • cyrus-sasl-lib-2.1.23-8.el6.i686.rpm 
pam-1.1.1-4.el6.i686.rpm 
    • cracklib-2.8.16-2.el6.i686.rpm
    • audit-libs-2.0.4-1.el6.i686.rpm
      These 32-bit packages (pam-1, cracklib-2, and audit-libs-2) are required on both 32-bit and 64-bit systems.
    • Verify that you have the following pcre and libuuid packages:
      • pcre-7.8-3.1.el6.i686.rpm
      • libuuid-2.17.2-6.el6.i686.rpm
        These 32-bit packages (pcre-7 and libuuid-2) are required on both 32-bit and 64-bit systems.
Oracle Solaris Operating Systems
  • You can integrate CA SDM with CA Business Intelligence, which uses Business Objects Enterprise XI, although we do not support installing CA Business Intelligence on Oracle Solaris.
  • You can install CA EEM on Oracle Solaris, however CA SDM on Oracle Solaris cannot use external authentication for CA EEM on any platform. The CA EEM authentication feature requires the site to move the boplgin daemon to a Windows, Linux, or AIX operating system. The boplgin daemon on Oracle Solaris cannot integrate with the CA EEM Server on any platform.
Novell SUSE Linux (SLES) Operating Systems
 - You can integrate CA SDM with CA Business Intelligence, which uses Business Objects Enterprise XI, although we do not support installing CA Business Intelligence on SUSE Linux.
VMware Operating Systems
 - If you want to configure CA SDM on Windows in a network address translation (NAT) environment, modify the local HOSTS file with the hostname and IP address of your server. You can find the hosts file in the
 \system32\drivers\etc\hosts\ 
directory.
Database Management Systems
Consider the following information:
  • For UNIX/Linux Oracle implementations, set the Oracle environment variables before you install or migrate CA SDM.
  • To resolve some known issues with Oracle 11g, you 
    must
     force case sensitivity by setting the NX.env variable as NX_ORACLE_CASE_INSENSITIVE=0. We recommend that you also set NX_DSSORT to BINARY to make the domsrvr sort case sensitive. After upgrading to the latest release of Oracle 11gR2 (which 
    must
     include Oracle patch 10248523), you can reset NX_ORACLE_CASE_INSENSITIVE=1 for case insensitivity support.
  • If you want to use a remote MDB, the database client (Oracle or SQL Server) 
    must
     be installed on the same computer where you install CA SDM.
  • (For Oracle database only) 32-bit ORACLE client must be installed on all CA SDM servers.
  • We support remote MDB on HP UNIX with Oracle 11g R2.
Hardware Requirements
We recommend that at least 512 MB of temporary disk space is available for the CA SDM installation and 256 MB of temporary disk space is available for CA MDB installation. If the temporary disk space on your system is less than the recommended minimum value, use the IATEMPDIR variable to redirect this temporary space of the installer to another folder.
If you plan to install Unified Self-Service with CA Service Desk Manager, 2-GB RAM is required in addition to the listed hardware requirements.
(Advanced availability configuration) The following requirements must be met or exceeded for a CA SDM server to install and run properly:
Server Type
CPU Requirements
RAM Requirements
Disk Space Requirements
Standby or Background server
Minimum Dual Processor 2 GHz
Preferred Quad Core Processor 2 GHz 
Minimum 4 GB
Recommended 8 GB
4 GB (for product installation and for minimal application log growth.)
Application server
(minimum recommended configuration for each of the application servers must be the same)
 
Minimum Dual Processor 2 GHz
Preferred Quad Core Processor 2 GHz
Minimum 4 GB
Recommended 8 GB
(Can be increased based upon the number of *domsrvr or webengine pairs)
4 GB
Remote MDB
Minimum Dual Processor 2 GHz
Preferred Quad Core Processor 2 GHz
Minimum 4 GB
Recommended 8 GB
20 GB (recommended minimum disk space)
You must also allow for incremental growth to accommodate both new MDB table entries and to provide enough space for additional Service Desk-related documents.
 
Attachments
It is not recommended to have the attachment repository location as part of the standby or background or application server to avoid any link breakup during failover.
It is recommended to keep it on an independent file server, preferably on a shared storage location, For advanced availability configuration, you can use SAN with RAID 5 configured. Best performance is achieved by using multiple repositories on multiple application servers.
 
 
 Based on your organization requirements.
(Conventional configuration) The following requirements must be met or exceeded for a CA SDM server to install and run properly:
Server Type
CPU Requirements
RAM Requirements
Disk Space Requirements
Primary server
Minimum Dual Processor 2 GHz
Minimum 4 GB
Recommended 6 GB
(Can be increased based on the number of domsrvr or webengine pairs)
4 GB
Secondary server
Minimum Dual Processor 2 GHz
Minimum 4 GB
Recommended 6 GB
(Can be increased based on the number of *domsrvr or webengine pairs)
4 GB
Remote MDB
Minimum Dual Processor 2 GHz
Recommended: Quad Core Processor 2 GHz
Minimum 4 GB
Recommended 8 GB
20 GB (recommended minimum disk space)
You must also allow for incremental growth to accommodate both new MDB table entries and to provide enough space for additional Service Desk-related documents.
Use only one *DOM server or Web engine pair for each CPU and allocate 1-GB RAM per pair.
The following requirements must be met or exceeded for a CA SDM Web Client computer to access CA SDM with better performance:
Hardware
Requirements
CPU
Dual Processor 2.0 GHz preferred
RAM
Minimum 2-GB available free memory 
Disk Space
4 GB
Based on the size of your CA SDM environment, the following requirements must be met or exceeded for the product installation:
Database Size
Hardware
Requirements
Small—Used for installing CA SDM in a test environment.
CPU
Minimum Dual Processor 2.0 GHz
 
RAM
Minimum 2 GB
 
Disk Space
4 GB minimum. Incremental increase over time to accommodate database growth.
Medium—The CA SDM default. The recommended setting for most CA SDM installations.
CPU
Dual Processor 2.0 GHz
 
RAM
Minimum 4 GB
Recommended 6 GB
 
Disk Space
4 GB minimum. Incremental increase over time to accommodate database growth.
Large—Used for large CA SDM installations.
CPU
Quad Processor 2.0 GHz
 
RAM
Minimum 4 GB
Recommended 8 GB
 
Disk Space
4 GB minimum. Incremental increase over time to accommodate database growth.
* The domsrvr or DOM server is the internal daemon which manages the objects in the memory. The web engine is the internal daemon which generates the HTML pages and sends it to the client. A single web engine and domsrvr are deployed in pairs. Each pair requires one dedicated processor core and at least 1 GB of RAM. Each web engine or domsrvr pair can serve 200-250 users. If you need to add more than one pair for scaling up the system, ensure that you have the necessary processor and the RAM are available.
The data files directory of the database server for the MDB requires at least 2-GB of space.
When CA SDM is up and running, it is recommended that you verify/check the process memory. For optimal performance, we recommend the following method:
  1. Set a notification when the process memory exceeds 1.25-GB and begin a check on the processes that are running.
  2. Set a warning notification when the process memory exceeds 1.5 GB and take corrective actions to check the memory usage.
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 ten times. To check the status of all CA SDM components, use the pdm_status utility. The
pdm_d_refresh
utility instructs the daemon manager to start a new cycle of ten 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 need 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 the slstat utility.
 
The message dispatcher runs on the following servers, depending on your CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: All servers
 
Database Agent (platform_agent)
 
Performs SQL 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 shutting down a database service for maintenance. The agent will only retry the connection for a defined number of times (the default is 3 times), and only for a short time period of a few minutes. If the outage is longer than a few minutes, the agent will stop trying to connect, and CA SDM must be recycled after the database has been made available again.
 
The database agent runs on the following servers, depending on your CA SDM configuration:
 
  • Conventional: Primary server
  • Advanced Availability: All servers
 
Agent Provider (platform_prov_nxd)
 
Starts or stops database agents. By default, several agents are running. If more are required to handle the number of database queries, the Agent Provider starts them. If the system no longer requires so many database agents, the Agent Provider terminates the unnecessary ones.
 
The agent provider runs on the following servers, depending on the CA SDM configuration:
 
  • Conventional: Primary server
  • Advanced Availability: All servers
 
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, depending on CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: All servers
 
Continuous Archive and Purge (arcpur_srvr)
Runs your archive and purge rules as configured by the CA SDM administrator.
 
The Continuous Archive and Purge runs on the following servers depending on CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
 
Database Monitor (dbmonitor_nxd)
Monitors changes to common tables in the CA MDB, for example, ca_contact.
The Database Monitor runs on the following servers depending on CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
Mail Daemon (pdm_mail_nxd)
Sends outbound email notifications.
The Mail Daemon runs on the following servers, depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: All servers
Mail Eater (pdm_maileater_nxd)
Accepts inbound email for ticket creation and updates.
The Mail Eater daemon runs on the following servers, depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
Notification Manager (bpnotify_nxd)
Manages notifications in a Windows environment.
The Notification Manager runs on the following servers, depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Application, background, and standby servers
 
Spell Checker (lexagent_nxd)
 Performs spell checking as requested by clients.
 
The Spell Checker runs on all CA SDM servers.
 
Text API Daemon (pdm_text_nxd)
Creates and updates tickets by external interfaces, such as the command line and email.
The Text API daemon runs on all CA SDM servers.
 
Timed Event (animator_nxd)
Runs the delay times of events. In an implementation that has many service types or contracts, there can be many active events that the Timed Event engine has to track. In this situation, 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, depending on CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
Time-To-Violation (ttv_nxd)
Calculates projected violation times for service types.
The Time-To-Violation daemon runs on the following servers, depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
 
Proctor Daemon (pdm_proctor_nxd)
 
(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_nxd process 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 pdm_startup.
 
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_userload to manipulate these records, you can also use the pdm_cache_refresh utility to make the Object Manager retrieve the new data.
The Object Manager runs on all the CA SDM servers in advanced availability configuration.
 
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, depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: All servers
 
LDAP Virtual Database (ldap_virtdb)
Interfaces with an LDAP directory.
The Method Engine runs on the following servers depending on the CA SDM configuration:
  • Conventional: Primary or secondary server
  • Advanced Availability: Background or application server
Knowledge Management Search Daemon (bpebr_nxd)
Performs knowledge base searches. Upon CA SDM startup, the bpebr_nxd daemon caches Knowledge Document data in its memory from the database. With a large document base, you might have memory resource issues. The bpebr_nxd daemon has the following size requirements:
Knowledge Management Search
  • 100,000 documents
  • Memory size = 332,000 KB
The Knowledge Management daemon runs on the following servers depending on the CA SDM configuration:
  • Conventional: Primary or secondary server
  • Advanced Availability: Background server
Knowledge Management/Keyword Indexing Daemon (bpeid_nxd)
Indexes the knowledge base.
The Keyword Index daemon runs on the following servers depending on the CA SDM configuration:
  • Conventional: Primary or secondary server
  • Advanced Availability: Background server
Knowledge Management FAQ Ratings Daemon (bu_daemon)
The bu_daemon runs on the following servers depending on the CA SDM configuration:
    • Conventional: Primary or secondary server
    • Advanced Availability: Background server
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 depending on the CA SDM configuration:
  • Conventional: Primary or secondary server
  • Advanced Availability: Background server
 
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 depending on the CA SDM configuration.
  • Conventional: Primary or secondary servers
  • Advanced Availability: All 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 depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
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 (
pdm_tomcat_nxd
).
The Apache Tomcat Web Server runs on all CA SDM servers.
Web Engine (webengine)
Connects to web browsers through a
pdmweb cgi
running on a Microsoft IIS or Apache Tomcat web server. There must be at least one web engine for WSP on the following servers, depending on your CA SDM configuration.
 
  • Conventional: Primary server
  • Advanced availability: Application, standby, and background servers
This process ensures that WSP 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 engines cache.htmpl web forms for connected users. You can manipulate the cache using the
pdm_webcache
utility and can see connection statistics using the
pdm_webstat
utility. 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:
 
  • Acquire information about background and standby servers.
  • Update information (such as slump ID, node name, server type) in the
    ServerStatusMonitor
    class.
  • Receive broadcast messages of server status changes.
  • Quiesce the requests. Register for SLUMP_NODE_GONE messages that are forwarded to 
    ServerStatusMonitor
    objects when the failing node is the background server. 
 
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:
  • Conventional: Primary or secondary (if configured) server
  • Advanced Availability: Background or application (if configured) server
 
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, depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
 
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, depending on your CA SDM configuration:
 
  • Conventional: Primary server
  • Advanced Availability: All 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_logfile daemon 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 SA Tomcat to run support automation and can be configured on any CA SDM server.
 
Visualizer Tomcat (viz_tomcat)
 The Tomcat instance to run the Visualizer and can be configured on the following servers:
  • Conventional: All servers
  • Advanced Availability: Application server
 
Event Manager (ehm_nxd)
The Event Manager manages events coming from CA NSM. The Event Manager runs on the following servers, depending on the CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: Background server
 
Knowledge Management Indexing Daemon (bpeid_nxd)
Responsible for indexing the knowledge documents and runs on the following servers:
  • Conventional: Primary server
  • Advanced Availability: Background server
Registration Server (mdb_registration_nxd)
An agent for handling MDB registration requests. The Registration Server runs on the following servers, depending on your CA SDM configuration:
  • Conventional: Primary server
  • Advanced Availability: All servers