Skip to content
CA Spectrum - 10.3
Documentation powered by DocOps

Setting Up a Distributed SpectroSERVER Environment

Last update June 29, 2018


Name Resolution Requirements

The SpectroSERVER system or OneClick web server system must be able to resolve the host name of the SpectroSERVER to an IP address.

We recommend using hosts files for name resolution. This practice ensures that a network outage does not affect SpectroSERVER name resolution.

CA Spectrum and Multiple Interfaces

All CA Spectrum servers bind to and listen on all available interfaces and advertise themselves with host names that are not fully qualified. The result is flexibility when configuring a management topology. To establish connections, the CA Spectrum component servers try all interfaces in the order that is determined by the operating system until the connection succeeds.

Communication Among SpectroSERVERs

Install and run SpectroSERVERs in a distributed environment with the same user account. No further user model configuration is therefore required. SpectroSERVERs that are installed and run as different users cannot communicate.

Example: SpectroSERVERs A and B Cannot Communicate

In this example, SpectroSERVER A is running as “root”. SpectroSERVER B is running as Administrator. They cannot establish a connection because the request cannot pass through server security:


Example: Configuration for SpectroSERVER to SpectroSERVER Connection

This example shows a user logged in as "root" on SpectroSERVER B, and a user logged in as “Administrator” on SpectroSERVER A. This configuration enables the two SpectroSERVERs to communicate:


DSS Environment Requirements

Your distributed environment must meet the following conditions to enable multiple SpectroSERVERs and the modeling of multiple landscapes to represent those servers:

  • Each landscape must contain an identical modeling catalog of the model types in a database and their relations. This replication provides a consistent base for CA Spectrum intelligence.
  • Each landscape must contain the same user models, which you can view in the OneClick Users tab.
  • Minimize the number of connections between subnets that are modeled in different landscapes.
  • Limit the number of identical devices that are modeled in more than one landscape.
  • Assign a unique landscape handle to each modeled landscape. CA Spectrum can then distinguish it from other landscapes in the DSS environment.

Location Servers

When you install a SpectroSERVER, you also automatically install a location server. This server identifies and locates other CA Spectrum services on the network. CA Spectrum processes use the location server to determine where these services are running. Processd starts and stops the location server.

In a distributed environment, CA Spectrum uses location servers to maintain the SpectroSERVER landscape map and provide connection services to client applications. During CA Spectrum installation, you designate one of the location servers in a landscape map (or CA Spectrum domain) as the main location server (MLS).

Install the main location server on a highly reliable computer. This server propagates service advertisements among location servers and communicates service locations among the location servers.

In the following diagram, the location server on Host 1 has been configured as the main location server for this environment. Because the main location server resides on the same host as a SpectroSERVER, that SpectroSERVER is considered to be the main SpectroSERVER.

All server-to-server communication is routed through the main location server host. Two non-MLS SpectroSERVERs can communicate only through the main SpectroSERVER.

The SpectroSERVER on Host 2 in the diagram has a distributed service with a resource modeled on the SpectroSERVER on Host 3. All communications about the remote resource are routed through the main location server host. The servers on Host 2 and Host 3 do not directly communicate.

Important! This diagram reflects a two-tiered setup consisting of one MLS and multiple child SpectroSERVERs. Such a configuration is the standard, recommended configuration.

SPEC--two tiered setup_DIA

How Location Servers Interact

Every CA Spectrum installation includes the following two files:

  • .LocalRegFile lets CA Spectrum processes locate their location server.
  • LS/.locrc is the configuration file for the locally installed location server.

These files manage the location server hierarchy and the interactions between each location server and the main location server.

In a distributed SpectroSERVER deployment, the location servers interact as follows:

  1. SSAPI applications and servers read .LocalRegFile to determine the location server to use.
  2. Each local location server reads the /LS/.locrc file to determine which server is the main location server.
  3. The local location server connects to the main location server to find network services. If the main location server becomes unavailable, other location servers retain service information in memory until the main location server is available.

Main Location Server Connection

Each SpectroSERVER must have a connection to the SpectroSERVER running on the server that is designated as the main location server. This designation is specified in the <$SPECROOT>/LS/.locrc file.

The connection to the main location server requires the following configuration:

  • Update the ".hostrc" file of the MLS with hostnames of:
    • All child SpectroSERVERs.
    • All OneClick clients.
  • Update the ".hostrc" file of each child SpectroSERVER with hostnames of:
    • All OneClick clients.
Note: By default, the ".hostrc" file of each child SpectroSERVER contains the MLS name that you provide during the installation. By default, the ".hostrc" file on a OneClick client contains only that OneClick client hostname, do not update anything further.
  • In a fault-tolerant environment, update the ".hostrc" file of the secondary MLS with hostnames of:
    • All child SpectroSERVERs.
    • All OneClick clients.
  • In a fault-tolerant environment, update the ".hostrc" file of each secondary child SpectroSERVER with hostnames of:
    • All OneClick clients.
    • Primary child SpectroSERVER.
    • Secondary MLS.
  • Each SpectroSERVER requires a CA Spectrum user model for the user account under which the other SpectroSERVER is running.

This configuration enables the communication between <ss>s through the MLS. This configuration also enables the <oc> server connection to the MLS.

Note: The main landscape (or the value of MAIN_LOCATION_HOST_NAME in the .locrc file) is modeled in CA Spectrum. The VNM topology for each SpectroSERVER contains this landscape unless it is already modeled elsewhere. An alarm is generated on this model if the connection to the main landscape is lost.

Designate a New Main Location Server

You can change the computer that is designated as the main location server.

On the SpectroSERVER, you designate a new main location server through the Location Server Configuration dialog or through the .locrc file.

On the OneClick web server, you set the main location server information in the CA Spectrum Configuration page in the OneClick Administration pages. This action updates the name of the main location server to which the OneClick web server connects.

Note: If you change the main location server on the SpectroSERVER without updating the OneClick web server, CA Spectrum does not function properly. For more information, see the Administrating section.

Example: Designating a New Main Location Server on the SpectroSERVER

A distributed network is composed of Computers 1 through 4, with Computer 1 designated as the main location server. To make Computer 4 the main location server, first reconfigure Computer 4 as the new main location server. Then reconfigure Computers 1, 2, and 3 to point to Computer 4 as the main location server.

Follow these steps:

  1. Bring up the SpectroSERVER Control Panel.
  2. Select Location Server from the Configure menu.
    The Location Server Configuration dialog opens.
  3. Change the Main LS Host field in the Location Server Characteristics area to point to Computer 4.
Note: You can also edit the .locrc file in the < $SPECROOT>/LS directory to change the main location server. The following entry in the .locrc file identifies the main location server:

Landscape Map Integrity Preservation

CA Spectrum users commonly maintain separate production and test environments. Protect the integrity of the landscape map by preventing SpectroSERVERs in the test environment from connecting to a SpectroSERVER in the production environment SpectroSERVER as their main location server, or the reverse.

Landscape Handles

A SpectroSERVER in a distributed deployment identifies each landscape by its landscape handle. CA Spectrum r10.3, enables you to opt for increased capacity and scale by allowing you to monitor huge number of devices with fewer landscapes. Using the Huge Landscape Handle type (during installation), you can create landscapes which can support huge model count (beyond 1 Million models per SpectroSERVER). Handles are multiples of 64. 
This option is only available for fresh installs and best suited for new DSS environments and new single-server installations.

This capability is not supported for upgrade and migration scenarios to CA Spectrum 10.3 from earlier versionsFor direct upgrades and migrations, CA Spectrum automatically selects the Legacy Landscape Handle type.

Note: In a Distributed SpectroSERVER environment, you cannot select a mix of Legacy and Huge landscapes. For example, if you have an existing SpectroSERVER running in Legacy and want to add a new SpectroSERVER, you cannot add a Huge Landscape, even if you are installing it from the scratch.

In a Distributed SpectroSERVER environment, all your SpectroSERVERs should be either Legacy or Huge Landscapes.

Each landscape must have a unique landscape handle, which is either:

  • Legacy Landscape Handle: a number that is divisible by 4 and is in the range of 4 to 16,376. (In hexadecimal format, handles are in the range 0x100000 to 0xffe00000 where the lower 20 bits are set to zero). 
    Each SpectroSERVER is limited to 1 million models. Recommended option if you are using a SSdb created from any CA Spectrum version prior to r10.2.
  • Huge Landscape Handle: a number that is divisible by 64 and is in the range of 64 to 16,256. (In hexadecimal format, handles are in the range 0x1000000 to 0xfe000000 where the lower 24 bits are set to zero.) 
    Each SpectroSERVER can manage/have beyond 1 million models. Recommended for new DSS environments and single-server installations only.

After installation, the encoded landscape handle appears at the top of all views, in OneClick Console that are associated with that landscape.

Note: We recommend using a sequential numbering scheme for landscape handles. You can associate a landscape handle with a significant landscape feature, such as a building number or some portion of a subnet IP address. However, for Legacy Landscape Handle(s) your entry is encoded into the 12 most significant bits of the landscape handle, and for Huge Landscape Handle(s) your entry is encoded into the 8 most significant bits of the landscape handle. The result can therefore appear unrelated to the appropriate landscape feature.

Note: From 10.3 onwards, you can load the catalog of the Legacy Landscape on a Huge Landscape and vice versa (using SSdbload -c option). However you will not see the landscape details displayed. For more information on the landscape details, see the Known Anomalies section.

Assign Landscape Handles

Landscape handles can be assigned through the SpectroSERVER Validation dialog when installing CA Spectrum or by using a utility named lh_set.
You are allowed to set/assign the landscape handle, based on the type of Landscape handle you have opted for during installation. For instance, if you have selected Huge Landscape Handle type (multiples of 64), you cannot assign landscape handles which are multiples of 4 and not multiple of 64, (for example, 4, 16, 32, 68 and so on.)

Important! Run the lh_set utility before you run the SpectroSERVER for the first time. Otherwise, CA Spectrum assigns a default landscape handle that is the same every time that CA Spectrum assigns it. As a result, duplicate landscape handles can be created when multiple landscapes are configured. Such landscapes can never be accessed simultaneously from the same application.

Follow these steps:

  1. Navigate to the SS directory.
  2. Enter the following command:

    ../SS-Tools/lh_set <landscape handle>

    You can specify the new landscape handle in either decimal or hexadecimal notation. If you use decimal notation, the lh_set utility converts your entry into a hexadecimal landscape handle.

  3. If you assign a landscape handle which is in conflict with the Landscape Handle type you have opted for during installation, the following error might appear:
    Landscape handle must be 64 - 16256, multiples of 64 (or 0x1000000 - 0xfe000000 with low 24 bits 0).
    Unable to set SS landscape handle.
Note: For more information, see Installing and Upgrading.

Change a Landscape Handle

If a SpectroSERVER has started, the process for changing the landscape handle of the SpectroSERVER database entails more steps. The landscape handle is included in the model handle of each model in the SpectroSERVER database. Changing the landscape handle therefore requires converting all model handles from the old landscape handle to the new landscape handle.

Change the landscape handle of all models that were created automatically at startup, and update the landscape handle in several resource files.

Follow these steps:

  1. Use the Modeling Gateway tool to export the models from the SpectroSERVER whose landscape handle you want to change.
  2. Shut down the SpectroSERVER.
  3. Initialize the database with the SSdbload utility.

    Note: For more information, see Database Management.
  4. Assign the new landscape handle using the lh_set utility.
    See Assign Landscape Handles.
  5. Start the SpectroSERVER.
  6. Import the models into the SpectroSERVER using the Modeling Gateway tool.
Note: For more information, see the Modeling Gateway Toolkit.

Important! Its is mandatory to reboot the server after you complete a fresh SpectroSERVER installation while installing CA Spectrum r10.3.

Note: Running SpectroSERVER process using 'root' user instead of 'spectrum' user on linux machines may result in the following error message "The user running the parent server does not have a user model in the local landscape" on the landscape page found in the administration tab on the oneclick console.

Run 'ps -ef | grep -i spectro' to check if the SpectroSERVER process is owned by 'root' user or other user instead of 'spectrum' user (You can check the value of 'initial_user_model_name' parameter in $SPECROOT/SS/.vnmrc file to check for the 'spectrum' user) to resolve the issue.

Follow the steps mentioned to fix the issue:

1. Launch Spectrum Control Panel using 'root' or other user who is currently owning the SpectroSERVER process. Stop SpectroSERVER process thoroughly by clicking [Stop SpectroSERVER] button.

2. Change the ownership of VNM.OUT, RCPD.OUT etc. under $SPECROOT/SS directory back to 'spectrum' user using 'chown' command. Make sure when you run 'ls -l' under $SPECROOT/SS directory all files and directories are owned by 'spectrum' user except the SpectroSERVER file. The SpectroSERVER file should be owned by 'root' user and have the following attributes:

-rwsr-x---   1 root     spectrum     12841 Nov 21 01:16 SpectroSERVER

3. Launch Spectrum Control Panel using 'spectrum' user and start SpectroSERVER process by clicking [Start SpectroSERVER] button.

Process Daemon (processd)

CA Spectrum uses a process launching and tracking daemon called Process Daemon (processd) to let you control processes on multiple servers in a DSS environment. This daemon starts processes when an application such as the CA Spectrum Control Panel makes a request. You can also configure processd with install tickets to start processes automatically at system startup. Install tickets can also automatically restart critical processes that stop unexpectedly.

The CA Spectrum installation program configures processd to start automatically (where it must run as root) and on Windows systems (where it runs as the LocalSystem account).

Process launch and monitoring with processd occur only when an application requests such actions. Typically, processd operates in the background.

If a process does not start or is not working properly, processd writes an error message to the <$SPECROOT>\lib\SDPM\processd_log file. The error message includes information to identify the problem.

When restarted, processd creates a processd_log.bak file to preserve old error messages and appends any new error messages to the processd_log file.

Important! You must be thoroughly familiar with CA Spectrum, distributed networking, and network configuration before attempting any of the procedures described in this section.

Processd Differences in Windows Environments

The processd daemon works slightly differently on Windows platforms because of differences in their native security architectures.

  • When you request a process start from a remote connection in a Windows environment, the process starts as the user who is specified in the Windows Service Configuration dialog. 
  • For server processes that must remain running after user logout (or before anyone logs in), a SERVERPROCESS field is used in the Windows environment. To prevent Windows from shutting these processes down during logout, these processes are started as the user who is specified in the Windows Service Configuration dialog. 

Change the Windows Password in Processd

During installation on Windows, you are prompted to enter a username and password in the Windows Service Configuration dialog. The processd daemon uses this username and password to start CA Spectrum processes as the specified user. Providing the security information lets these processes run when no user is logged in.

Note: For more information, see Installing.

If the password you specified in the Windows Service Configuration dialog changes or expires, you can update processd with the new password.

Important! If your password contains special characters, such as an exclamation point (!), escape these characters with a backslash (\). Or you can change the password from a command prompt.

Follow these steps:

  1. Log in as a member of the local Administrators group.
    You must be a member of the CA Spectrum Users group and an administrator to change the processd user name and password.
  2. Open a command prompt.
  3. Navigate to the /lib/SDPM directory.
  4. Enter the following command:

    processd --install --username user --password newpassword
    • user
      Specifies the user name.
    • newpassword
      Specifies the new password for this user name.

    If the user name or the password contains special characters that the shell can misinterpret, enclose the user name or password in quotation marks. For example, the user name contains a domain name and user, with a backslash (\) separator. The password contains an asterisk (*). Both of these characters are special characters. Therefore, the user name and password are enclosed in quotation marks, as in the following example:

    processd --install --username "DOMAIN\JSmith" --password "283EJ*"
    Note: If the password for the Windows user name changes but the processd service password is not updated, processd does not start. The following events are generated in the Windows event log:

Install Tickets Files

You can configure processd to start processes at system startup. You can also select processes to restart if they stop running. Files that are known as install tickets support this functionality.

Install tickets use files in the following two directories:

  • <SpectrumInstallation Directory>/lib/SDPM/partslist
  • <Spectrum Installation Directory>/lib/SDPM/runtime

The partslist directory contains the individual install ticket files.

The runtime directory contains encoded files in the form of <PID>.rt where <PID> is the process ID of the running process.

Note: SDPM stands for CA Spectrum Distributed Process Manager.

You can add install tickets to the partslist directory. New install tickets must conform to certain formatting rules. Restart processd to identify any new or modified install tickets in the partslist directory. These files are read at processd startup and are stored in cache memory for future use.

Install ticket files follow a naming convention that refers to the process whose configuration information it contains. Install ticket filenames are in the form of <PARTNAME>.idb. The <PARTNAME> variable is an internal key to identify processes that processd controls.

The following defining fields are used for install tickets. The format is <fieldname>;<value>; where <fieldname> is one of the names that are displayed below. The <value> is a string that provides a definition for the corresponding field name. Quotation marks are not supported.

    Identifies a particular process/application with a multicharacter string with no spaces. The install ticket for this application has a filename in the form <PARTNAME>.idb. <PARTNAME> is the process name.
    Defines the name of the application as a multicharacter string.
    Specifies where you want to run the application. Supply a value for this field before it can be used as part of the ARGV field that is described later.
    Specifies the log file for output from the application. This field must begin with <$SPECROOT> or <$WORKPATH>. No spaces are allowed.
    Is reserved for use in Purism-supplied install tickets only. Comment it out in install tickets that you create.
    Indicates whether a process is automatically restarted if it stops. If this field is not included in the install ticket, automatic restart is disabled by default. Accepted values are Y, y, N, n.
    Indicates whether the process is started whenever processd starts. If this field is not included in the install ticket, the function is disabled by default. Accepted values are Y, y, N, n.
    Indicates whether the process has more than one state when starting up. Usually, the process sends an “is ready” ticket when ready to communicate. This field is reserved for use in Purism-supplied install tickets only. If this field is not included in the install ticket, it is disabled by default. Accepted values are Y, y, N, n.
    Specifies the number of instances of a process that can run on one platform. Numeric values are accepted.
    Specifies the number of seconds that processd tries to restart the application after failure.
    Defines the username of the user who is authorized to run the process when the AUTOBOOTSTART and/or AUTORESTART fields are set. This field is only required when those fields are included in the install ticket. This field is not applicable on Windows because all processes run as the processd install user.
    Specifies the number of times that processd tries to restart an application within the specified RETRYTIMEOUT period.
    Indicates the relative startup priority of the process relative to other processes. The following values are used:
    • 10 for standalone processes
    • 20 for processes that depend on standalone processes
    • 30 for processes that depend on the SpectroSERVER
    Indicates to processd whether a process continues to run after the user logs out. When this field is enabled, the process is always started as the user who is authorized to run the processd service. This field is only applicable in the Windows environment. The default value is 'yes' for the following processes:
    • Archive Manager (ARCHMGR.idb)
    • Location Server (LOCSERV.idb)
    • SpectroSERVER (SS.idb)
    Indicates whether the ticket represents a Windows service. Lets processd manage Windows services from the Service Control Manager.
  • ENV
    Adds one or more variables to the application environment. Multiple values are listed on a separate line with the macro <CSPATHSEP> between the value and the semicolon that ends the line.
  • ARGV
    Defines the argument list of the process, which includes the executable path and any number of arguments (spaces are allowed).

Examples Install Tickets

Install tickets apply the following syntax conventions:

  • Any line beginning with a pound sign (#) is treated as a comment.
  • A semicolon (;) must follow all field names and all values following each field name.
  • Anything following the second semicolon is disregarded.
  • Four macros can be used: <CSEXE>,<CSBAT>,<CSCMD>, and <CSPATHSEP>. Based on the platform, the appropriate definition is substituted. Use <CSPATHSEP> instead of the actual path separator to avoid parsing conflicts.

The following example shows a valid install ticket:

# Processd Install Ticket for SpectroSERVER Daemon.
NUMPROCS;3; // unlimited
RETRYTIMEOUT;0; // seconds
RETRYMAX;0; // retries

The following example shows another valid install ticket:

# Processd Install Ticket for Visibroker Naming Service
APPNAME;Visibroker Naming Service;
NUMPROCS;1; // one per host
RETRYTIMEOUT;600; // 10 minutes
RETRYMAX;5; // 5 retries

Start a New Install Ticket Process

If you added an install ticket file, you can use the restart option to start the process specified in the ticket. With the restart option, you do not have to stop and restart processd and all of the processes that it is monitoring.

Follow these steps on Windows:

  1. Log in as a member of the CA Spectrum Users group.
  2. Open a command prompt.
  3. Navigate to the /lib/SDPM directory.
  4. Enter the following command:

    perl restart

    The process is started.

Stop and Restart Processd

If you suspect that the lib/SDPM/runtime directory has become corrupted, stop and restart processd.

Follow these steps: on Windows

  1. Log in as a member of the CA Spectrum Users group.
  2. Open a command prompt.
  3. Navigate to the /lib/SDPM directory.
  4. Enter the following command:

    perl stop (or start)
Note: On Windows, the <start/stop> commands also stop and start the CA Spectrum processes that run as NT services (such as MySQL and VisiBroker).

How the Userconf Process Works During Installation

The userconf process runs processd in the background. Userconf lets you perform user-specific configuration of CA Spectrum during installation and afterwards, when a user logs in to CA Spectrum.

The userconf process performs the following tasks during CA Spectrum installation:

  1. Runs userconf -install %SPECROOT%, which makes the following changes:
    • Adds SPECROOT and SPECPATH to the system environment.
    • Adds $SPECPATH\lib to the $PATH system variable.
    • Removes the old $SPECPATH\lib entries from the path, if the installation directory has changed.
    • Removes %SPECPATH%\lib from the path (if it exists).
    • Modifies the registry so that userconf runs each time that a user logs in (with no arguments).
  2. Runs userconf -start to start processd. The -start flag starts processd without verifying that the user is a member of the CA Spectrum Users Group.

    Note: The installation program adds the current user to the CA Spectrum Users Group. However, the change does not take effect until the user logs out and logs back in. Add the -start flag so that processd starts without verifying that the user is a member of the CA Spectrum Users Group. The installation then continues without requiring the user to log out and log back in.
  3. Runs userconf -restart to stop and restart processd if the user is installing Exceed for the first time (which occurs after the CA Spectrum installation). Processd can then update PATH environment changes that are part of the Exceed installation.

How Userconf Works When a User Logs In

The installation adds the userconf process to the registry Run key. When a user logs in, the process starts automatically and checks whether the user is a member of the CA Spectrum Users group. The userconf process applies the following rules:

    • If the user is a member of the CA Spectrum Users group, userconf verifies cygwin and Exceed and reconfigures as needed before starting processd. If Microsoft VC++ is installed, userconf configures it appropriately for use with the CA Spectrum SDK.
    • If the user is not a member of the Users group, a message states that CA Spectrum is installed but the user is not in the CA Spectrum Users group.
      To enable the user to use CA Spectrum, add the user account to the CA Spectrum Users group. The user must then log out and log back in.
      A user who does not want to use CA Spectrum can select the “user doesn't want to run Spectrum” check box. With this option, userconf continues to run when the user logs in, but the process exits silently.

      Note: To see the message again, run the following command:
      userconf -install %SPECROOT%

Duplicate Models in a Distributed Environment

In a DSS environment, CA Spectrum tracks duplicate models (for example, a user model that exists on multiple landscapes) by designating one as a "home" model. The home model resides on the SpectroSERVER that is running on the host with the "root" main location server (MLS).

Important! If you change the root MLS in a DSS environment, the state of all duplicate models is updated to match the "home" model on the MLS. The MLS is the final authority in any DSS environment.

CA Spectrum uses the home model to synchronize information for all duplicate models. Modification requests that are made to the duplicate models that are not the home models are relayed to the landscape of the home model. The home model then distributes the request to all of the other duplicate models.

Failure to Contact Home Landscape Errors

Editing operations can fail when the home landscape of the model that you are editing cannot be contacted. OneClick reports relation errors such as the following error from the SpectroSERVER:

The operation failed because the model being edited exists in multiple landscapes and its home landscape could not be contacted.

This type of error can indicate that the home model on the SpectroSERVER that is running on the "root" MLS is unreachable. When duplicate models are added or deleted in a distributed environment, they are routed through the home landscape. If that SpectroSERVER is down or cannot be contacted, the relation fails and generates an error.

Failure to contact the home landscape can occur under any of these conditions:

  • The home SpectroSERVER or an intermediate SpectroSERVER between the duplicate model and the home SpectroSERVER is not running.
  • A network problem is preventing SpectroSERVER access.
  • A security issue is preventing the SpectroSERVERs from communicating.

Host Resource Configuration File (.hostrc)

The .hostrc file restricts client application access to each local SpectroSERVER. Client applications cannot connect to the local landscape unless the .hostrc file is configured to permit this access. You can use a text editor to edit the .hostrc file.

Note: For more information, see the Administrating section.

By default, the .hostrc file is initially installed with the local hostname, which restricts all remote access. Adding an individual hostname enables connections to and from that server. Enable unrestricted access to and from all remote servers by adding a "+" symbol. Add the machine name to the .hostrc file to enable client access from individual remote servers.

CA Spectrum implements host security in multiple layers, by hostname or by IP address. We recommend listing hostnames in the .hostrc file, which includes all IP addresses that are associated with the hostnames. Connection attempts that are initiated by the hostname do not always succeed if an IP address is used to connect.

Time Zones in a DSS Environment

In DSS installations that span multiple time zones, all activities that occur on a SpectroSERVER reflect the local time of the server, including scheduled events. All schedules created in OneClick and applied to modeled devices start and end according to the local time of the SpectroSERVER or device landscape.

Note: For more information, see OneClick Schedules in a DSS Environment.

SpectroSERVER Shutdown

We recommend shutting down the SpectroSERVER using the CA Spectrum Control Panel before you shut down the server where the SpectroSERVER is running. However, if you use the operating system shutdown procedure as a way to shut down the SpectroSERVER, increase the amount of time for processd to stop.

SpectroSERVER Shutdown in a Windows Environment

In a Windows environment, processd waits until all subprocesses have shut down before it stops. However, the Windows registry setting WaitToKillServiceTimeout sets the length of time that Windows waits for all services to stop after a Windows shutdown is initiated. If a service such as processd is still running after the WaitToKillServiceTimeout elapses, Windows terminates this service. The default value is 20 seconds, which is not always enough time for the SpectroSERVER to shut down completely at system shutdown. You can increase the timeout value.

Follow these steps:

  1. Open the Registry Editor.
  2. Go to HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control.
  3. Click the Control key.
  4. Double-click the WaitToKillServiceTimeout value in the right pane.
  5. In the window, change the value to anything up to 600,000 milliseconds (10 minutes).
  6. Click OK.
  7. Restart the Windows server for the change to take effect.

Set the Landscape Map Entry Timeout

By default, each landscape entry remains in the landscape map indefinitely. Using the location server configuration file (.locrc), you can specify an amount of time after which the landscape entry times out and is removed automatically from the landscape map.

Note: In previous CA Spectrum releases, landscape entries timed out after one hour, and they were removed automatically from the landscape map. Starting in CA Spectrum 9.2.2, landscape entries do not time out by default.
Important! We do not recommend using a timeout value to automatically remove an entry from a landscape map. Instead, leave the default timeout value. Use the MapUpdate command to remove an entry from the landscape map when required. For more information, see Database Management.

Follow these steps:

  1. Navigate to the <$SPECROOT>/LS directory.
  2. Update or add the following entry in the .locrc file:
    • time_out_value
      Indicates the time in milliseconds after which a landscape entry times out and is removed automatically from the landscape map.
      Default: 0 milliseconds (no time-out)

Problems with Landscape Mapping from Existing DSS Setup


I experienced problems with the landscape map when I set up a separate distributed environment by copying from another installation. I noticed a failure to switch over to the secondary SpectroSERVER after the primary goes down and problems with user security.


To copy a landscape map, remove all references to the previous DSS setup. The landscape maps must contain no references to the previous DSS setup. Use the following procedure to map a landscape from an existing DSS setup.

Follow these steps:

  1. Decouple the SpectroSERVERs as follows:
    1. Make each SpectroSERVER a standalone server.
      The location server is now pointing to the local server where it is installed.
    2. Verify that the landscape map is distinct for each SpectroSERVER.

      Note: In the existing DSS setup, the landscape map was a single map that included all of the servers.
  2. Save the SpectroSERVER databases.
    The landscape maps are clean.
  3. Change the MLS of these SpectroSERVER to restore the original MLS.

    Note: Do not change the original DSS settings.
  4. Reload the databases of each SpectroSERVER on different hosts.
  5. Select a SpectroSERVER as your MLS in the new DSS setup, and point other SpectroSERVERs to it.
    The dupModeList in the user models updates properly.
  6. Remove secondary entries in the landscape map, if they exist.
  7. Set up secondary SpectroSERVER entries.
  8. Load the database from the primary SpectroSERVER in the new DSS.
    The landscape is mapped from the existing DSS setup.


Problems with Purging Old Landscapes


Our production CA Spectrum environment consisted of a single distributed installation. The environment had multiple SpectroSERVERs and OneClick servers, which all used the same Main Location Server.

We decided to remove two SpectroSERVERs and a OneClick server from the production environment to create a separate development environment. We configured the development SpectroSERVERs and OneClick server to reference a new Location Server. We updated the .hostrc files so that the servers in each environment only had access to their respective Location Servers. In addition, we updated the landscape map in the production environment to remove the development landscapes.

However, if I look at the list of Monitored Landscapes on development OneClick server, I still see all of the old production landscapes. They are listed as having "No permission" because of the changes to the .hostrc file.


With the setup that you describe, you now have two separate environments. However, your development landscape map is caching stale production landscapes. You removed stale landscapes from your production environment, but you did not remove them from your development environment. Therefore, you must manually remove the stale landscapes from the development environment.

You have two options for removing the stale landscapes.


You can use the following command to remove stale landscapes from the development landscape map:

MapUpdate -remove landscape handle


You can restart all SpectroSERVER processes. For more information, see Stop and Restart Processd. Then restart the OneClick server. For more information about OneClick server administration, see OneClick Administration.

When you restart the servers, the issue is resolved.

Important! Its is mandatory to reboot the server after you complete a fresh SpectroSERVER installation while installing CA Spectrum r10.3.

The landscape handle bitmask in the SpectroSERVER database file does not match the bitmask of Spectrum


When trying to load a previously saved SpectroSERVER Database (SSdb) savefile, the following error shows:
Error: Detected incompatible model mask configuration. The database is configured as 20 bits, but the server is configured as 24 bits. Database can't be loaded.

The landscape handle bitmask in the SpectroSERVER database file does not match the bitmask of Spectrum.  If the "Huge Landscape Handle" option was selected during install, this means that the SpectroSERVER database file has a legacy landscape handle. If the Legacy Landscape Handle was selected during install, this means the SpectroSERVER database file has a huge landscape handle. 


Loading a previously saved SpectroSERVER database file with a different landscape handle bit mask is not supported. Review your SpectroSERVER environment for proper configuration. If you have installed and chosen the wrong landscape option, uninstall and reinstall CA Spectrum. If you selected an incorrect handle and that SS is in a DSS, remove the incorrect entry from the map after you have reinstalled. To remove the incorrect entry from the map after you have reinstalled:

  1. Open a bash shell and navigate to the:

    <SPECROOT>/SS-Tools/ directory

  2. Run the MapUpdate command:

    ./MapUpdate -v

  3. Remove the incorrect entry:

    ./MapUpdate -remove <lh> -precedence <precedencevalue>

    For example:
    ./MapUpdate -remove 0x100000 -precedence 10

Was this helpful?

Please log in to post comments.