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:
Review the following for implementing CA Service Desk Manager (CA SDM):
When planning for CA SDM deployment, for Scalability purposes, ensure that the upper limit of 64 processes is adhered to for a Primary Server. If the number of processes exceeds 64 on a Primary Server, plan to have additional processes on CA SDM secondary server. CA SDM installation can ideally have up to 40 Processes on a single server. Note that adding a new web engine domserver to your existing environment results in adding 3 more processes.
Ensure to restart xFlow interface services whenever you restart CA SDM Services.This is applicable for an environment that CA SDM and xFlow Interface Installation.
Search Server
Consider dedicating a server to install Search Server. Search server has built-in clustering feature and can be installed on a standalone setup. For large setups, we recommend installing the search server on three or more servers and manually configuring it to a fault-tolerant cluster.
Default User Information
The following table lists default user information for a typical CA SDM implementation:
Default Username
OS Level
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 Management
Admin User
Manually created.
Created in the MDB during configuration.
CA Service Management
Admin User
Manually created.
Manually created.
Created in the database during configuration.
CA Service Management
Admin User
Manually created.
Password Policy
User authentication does not work if the system is using shadow files and there is an
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 password confirms to the policy, only then CA SDM configuration works.
Shared Components
  • When installing CA SDM, do not install the CA Shared Components in the same directory as the CA SDM installation directory (
  • References to NX_ROOT pertain to the environmental variable containing the installation path of CA SDM. The NX_ROOT variable is set in the
    configuration file that is used to set environment variables for CA SDM.
    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.
Options Manager
When you are installing CA Service Desk Manager for the first time, the Options Manager
web option is not installed by default. The links to inactive objects are not copied. Consider the following information when you do not install the
  • 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 named
    has a relationship to the inactive Organization org2. When you copy
    , 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.
Database Considerations
  • 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.
    • Apache
      Applicable 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 port
    . 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 STOP
    pdm_tomcat_nxd -c START
Configuring Internet Information Services (IIS)
Follow these steps:
  1. Launch the
    Server Manager
    on the IIS installed server.
    Server Manager
    screen opens.
  2. Navigate to
    Local Server
    and go to
  3. Select
    Add Roles and Features
    option from the
    drop-down list.
    The Add Roles and Features wizard opens.
  4. Click
    on the
    Before You Begin
    The Select installation type screen opens.
  5. Select the
    Role-based or feature-based installation
    radio button and click Next.
    The Select destination server screen opens.
  6. Select the
    Select a server from the server pool
    radio button and ensure that the local server is listed in the Server Pool section. Click
  7. The
    Select server roles
    screen opens.
  8. Select
    from the Roles list.
    The Add features that are required for Web Server (IIS)? window opens.
  9. Click
    Add Features
    and then click
    The Select features page opens.
  10. Select the additional IIS features as required and click
    The Web Server Role (IIS) screen opens.
  11. Click
    The Role Services page opens.
  12. Select the following from the
    Role Services
    and click
    You can optionally select the other role services as required.
    • Web Server
    • Common HTTP Features
    • Default Document
    • Directory Browsing
    • HTTP Errors
    • Static Content
    • Health and Diagnostics
    • HTTP Logging
    • Performance
    • Static Content Compression
    • Security
    • Request Filtering
    • Management Tools
    • IIS Management Console
    • Application Development
    • CGI
    • Server Side Includes
      If you do select CGI, then only the web browser launches CA Service Desk Manager. The web browser attempts to open PDMWEB.EXE file.
    The Confirm installation sections screen opens.
  13. Review the roles and features you selected to install, and click
  14. Click
    when the installation is completed.
  15. Launch the
    Command Line Interface
    and run the following command:
    To 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.
  • Timespan
    Symbol names that are provided with the default CA SDM installation (
    Service Desk
    Application Data
    ) 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 the
    property in
    to use the date and date-time formats.
  • For outbound plain-text email notifications, the
    options 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 the
    option in the Options Manager.
  • Short File Names
    If you have disabled short file names on your Windows operating system enable these before installing CA SDM. Set both the
    environment variables to a short file name. For example,
    , after enabling short file names. For more information, see Microsoft Knowledge Base Article 121007.
  • Web Interface and Internet Information Services (IIS)
    To configure the web interface with IIS 7.0 on Windows 2008, install the CGI and Metabase Compatibility components of IIS 7.0. Add these components using the Roles section of the Server Manager, after installing the IIS Management Compatibility modules.
  • Localized releases of CA SDM are supported only on the matching localized Windows server operating environment. In all cases, configure the
    Language for non-Unicode programs
    for your system to support the target certified language. This setting is available in the
    Regional and Language Options
    window 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 Server
      Support Automation uses main application server. The server provides socket-based and HTTP-based communications.
    • Socket Proxy Server
      Support 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 connections
      The 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 type
      The 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 usage
      Remote 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 Bandwidth
    The amount of bandwidth a system consumes depends on the tools that you employ.
    • 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 the
      Remote Control
      feature, 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 port
    The following chart illustrates the required bandwidth depending on the tools that you:
    Remote Control
    < 3 KBps (28.8 kbps dial-up)
    Very fast and responsive
    < 5 KBps (< 56 kbps dial-up)
    Very fast and responsive
    Adequate with image degradation
    < 50 KBps (Cable/ADSL)
    Very fast and responsive
    Very fast and responsive
    < 100 KBps (LAN)
    Very fast and responsive
    Very fast and responsive
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:
SDM Server Components Name
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
utility. The
utility 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:
  • Conventional:
    Primary server
  • Advanced Availability:
    All servers
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:
  • 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:
  • Conventional:
    Primary server
  • Advanced Availability:
    All 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:
  • Conventional:
    Primary server
  • Advanced Availability:
    Background server
Database Monitor (dbmonitor_nxd)
Monitors changes to common tables in CA MDB, for example, ca_contact.
The Database Monitor runs on the following servers:
  • Conventional:
    Primary server
  • Advanced Availability:
    Background server
Mail Daemon (pdm_mail_nxd)
Sends outbound email notifications.
The Mail Daemon runs on the following servers:
  • 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:
  • 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:
  • Conventional:
    Primary server
  • Advanced Availability:
    Application, background, and standby 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:
  • 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:
  • Conventional:
    Primary server
  • Advanced Availability:
    Background server
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
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
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
to manipulate these records, you can also use the
utility 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:
  • 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:
  • 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
daemon caches Knowledge Document data in its memory from the database. With a large document base, you might have memory resource issues. The
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:
  • 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:
  • Conventional:
    Primary or secondary server
  • Advanced Availability:
    Background server
Knowledge Management FAQ Ratings Daemon (bu_daemon)
The bu_daemon runs on the following servers:
    • 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:
  • 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:
  • 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:
  • 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 (
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.
  • Conventional:
    Primary server
  • Advanced availability:
    Application, standby, and background 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
utility 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:
  • Acquire information about background and standby servers.
  • Update information (such as slump ID, node name, server type) in the server status monitor class.
  • Receive broadcast messages of server status changes.
  • Quiesce the requests. Register for
    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:
  • 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:
  • 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
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 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:
  • 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:
  • 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:
  • Conventional:
    Primary server
  • Advanced Availability:
    All servers
Search Deamon (es_ebl)
Responsible for the CA SDM data sync with the elastic search server.
Deamon syncs new log comments & attachments with Ca
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 analyst
The Demon runs only when the xFlow is enabled.
Reminder Deamon (reminder_nxd)
Responsible for triggering the follow-up reminders for tick
The Demon runs only when the xFlow is enabled.