Setting Up a Distributed SpectroSERVER Environment

Contents
casp1032
 
 
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.
 
DX NetOps Spectrum
 and Multiple Interfaces
All 
DX NetOps 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 
DX NetOps Spectrum
 component servers try all interfaces in the order that is determined by the operating system until the connection succeeds.
Communication Among 
SpectroSERVER
s
Install and run 
SpectroSERVER
s in a distributed environment with the same user account. No further user model configuration is therefore required. 
SpectroSERVER
s that are installed and run as different users cannot communicate.
 
Example: 
SpectroSERVER
s 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:
 SPEC--spectroservers_A_and_B_no_communication 
 
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 
SpectroSERVER
s to communicate:
 SPEC--spectroservers_A_B_communicating 
DSS Environment Requirements
Your distributed environment must meet the following conditions to enable multiple 
SpectroSERVER
s 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 
    DX NetOps 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. 
    DX NetOps 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 
DX NetOps Spectrum
 services on the network. 
DX NetOps Spectrum
 processes use the location server to determine where these services are running. Processd starts and stops the location server.
In a distributed environment, 
DX NetOps Spectrum
 uses location servers to maintain the 
SpectroSERVER
 landscape map and provide connection services to client applications. During 
DX NetOps Spectrum
 installation, you designate one of the location servers in a landscape map (or 
DX NetOps 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 
SpectroSERVER
s 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.
This diagram reflects a two-tiered setup consisting of one MLS and multiple child 
SpectroSERVER
s. Such a configuration is the standard, recommended configuration.
 SPEC--two tiered setup_DIA 
How Location Servers Interact
Every 
DX NetOps Spectrum
 installation includes the following two files:
  • .LocalRegFile lets 
    DX NetOps 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.
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 
    DX NetOps 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.
The main landscape (or the value of MAIN_LOCATION_HOST_NAME in the .locrc file) is modeled in 
DX NetOps 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 
DX NetOps 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.
If you change the main location server on the 
SpectroSERVER
 without updating the OneClick web server, 
DX NetOps 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.
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:
MAIN_LOCATION_HOST_NAME=Computer 4
Landscape Map Integrity Preservation
 
DX NetOps Spectrum
 users commonly maintain separate production and test environments. Protect the integrity of the landscape map by preventing 
SpectroSERVER
s in the test environment from connecting to a 
SpectroSERVER
 in the production environment 
SpectroSERVER
 as their main location server, or the reverse.
Landscape Handles
SpectroSERVER
 in a distributed deployment identifies each landscape by its 
landscape handle
. 10.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 10.3 from earlier versions. For direct upgrades and migrations, 
DX NetOps Spectrum
 automatically selects the Legacy Landscape Handle type.
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 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.
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.
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 
DX NetOps 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.)
Run the lh_set utility before you run the 
SpectroSERVER
 for the first time. Otherwise, 
DX NetOps Spectrum
 assigns a default landscape handle that is the same every time that 
DX NetOps 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.
 For more information, see .
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.
    For more information, see .
  4. Assign the new landscape handle using the lh_set utility.
  5. Start the 
    SpectroSERVER
    .
  6. Import the models into the 
    SpectroSERVER
     using the Modeling Gateway tool.
 For more information, see the .
 It is mandatory to reboot the server after you complete a fresh SpectroSERVER installation while installing r10.3.
 
 
 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)
 
DX NetOps 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 
DX NetOps 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 
DX NetOps 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.
 You must be thoroughly familiar with 
DX NetOps 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 
DX NetOps Spectrum
 processes as the specified user. Providing the security information lets these processes run when no user is logged in.
 For more information, see .
If the password you specified in the Windows Service Configuration dialog changes or expires, you can update processd with the new password.
 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 
    DX NetOps 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*"
     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:
  • <
    Spectrum
     
    Installation 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 
DX NetOps 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.
  •  
    PARTNAME
    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.
  •  
    APPNAME
    Defines the name of the application as a multicharacter string.
  •  
    WORKPATH
    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.
  •  
    LOGNAMEPATH
    Specifies the log file for output from the application. This field must begin with 
    <$SPECROOT>
     or 
    <$WORKPATH>
    . No spaces are allowed.
  •  
    ADMINPRIVS
    Is reserved for use in Purism-supplied install tickets only. Comment it out in install tickets that you create.
  •  
    AUTORESTART
    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.
  •  
    AUTOBOOTSTART
    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.
  •  
    STATEBASED
    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.
  •  
    NUMPROCS
    Specifies the number of instances of a process that can run on one platform. Numeric values are accepted.
  •  
    RETRYTIMEOUT
    Specifies the number of seconds that processd tries to restart the application after failure.
  •  
    TICKETUSER
    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.
  •  
    RETRYMAX
    Specifies the number of times that processd tries to restart an application within the specified RETRYTIMEOUT period.
  •  
    STARTPRIORITY
    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
       
  •  
    SERVERPROCESS
    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)
  •  
    SERVICE
    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.
PARTNAME;SS;
APPNAME;SpectroSERVER Daemon;
WORKPATH;$SPECROOT/SS;
LOGNAMEPATH;$WORKPATH/VNM.OUT;
ADMINPRIVS;y;
#AUTORESTART;N;
#AUTOBOOTSTART;N;
STATEBASED;y;
NUMPROCS;3; // unlimited
RETRYTIMEOUT;0; // seconds
#TICKETUSER;$USER;
RETRYMAX;0; // retries
STARTPRIORITY;20;
SERVERPROCESS;Y;
#ENV;<var>=<value>;
ARGV;$SPECROOT/SS/SpectroSERVER<CSEXE>;
The following example shows another valid install ticket:
# Processd Install Ticket for Visibroker Naming Service
PARTNAME;NAMINGSERVICE;
APPNAME;Visibroker Naming Service;
WORKPATH;$SPECROOT/bin/VBNS;
LOGNAMEPATH;$WORKPATH/NAMINGSERVICE.OUT;
ADMINPRIVS;y;
AUTORESTART;y;
AUTOBOOTSTART;y;
#STATEBASED;N;
NUMPROCS;1; // one per host
RETRYTIMEOUT;600; // 10 minutes
#TICKETUSER;$USER;
RETRYMAX;5; // 5 retries
STARTPRIORITY;10;
SERVERPROCESS;Y;
#ENV;<var>=<value>;
ENV;CLASSPATH=$SPECROOT/lib/vbjorb.jar<CSPATHSEP>;
ENV;CLASSPATH=$SPECROOT/lib/vbsec.jar<CSPATHSEP>;
ENV;CLASSPATH=$SPECROOT/lib/lm.jar<CSPATHSEP>;
ENV;CLASSPATH=$SPECROOT/lib/sanct6.jar<CSPATHSEP>;
ARGV;
$SPECROOT/bin/JavaApps/bin/nameserv<CSEXE>
-DORBpropStorage=
$SPECROOT/.corbarc
-Dvbroker.orb.admDir=
$SPECROOT/bin/VBNS
-Dborland.enterprise.licenseDir=
$SPECROOT/bin/VBNS/license
-Dborland.enterprise.licenseDefaultDir=
$SPECROOT/bin/VBNS/license
-Djava.endorsed.dirs=
$SPECROOT/lib/endorsed
-Dorg.omg.CORBA.ORBClass=
com.inprise.vbroker.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=
com.inprise.vbroker.orb.ORB
com.inprise.vbroker.naming.ExtFactory;
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 
    DX NetOps Spectrum
     Users group.
  2. Open a command prompt.
  3. Navigate to the /lib/SDPM directory.
  4. Enter the following command:
    perl processd.pl 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 
    DX NetOps Spectrum
     Users group.
  2. Open a command prompt.
  3. Navigate to the /lib/SDPM directory.
  4. Enter the following command:
    perl processd.pl stop (or start)
 On Windows, the processd.pl 
<start/stop>
 commands also stop and start the 
DX NetOps 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 
DX NetOps Spectrum
 during installation and afterwards, when a user logs in to 
DX NetOps Spectrum
.
The userconf process performs the following tasks during 
DX NetOps 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 
    DX NetOps Spectrum
     Users Group.
     The installation program adds the current user to the 
    DX NetOps 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 
    DX NetOps 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 
    DX NetOps 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 
DX NetOps Spectrum
 Users group. The userconf process applies the following rules:
 
    • If the user is a member of the 
      DX NetOps 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 
      DX NetOps Spectrum
       SDK.
    • If the user is not a member of the Users group, a message states that 
      DX NetOps Spectrum
       is installed but the user is not in the 
      DX NetOps Spectrum
       Users group.
      To enable the user to use 
      DX NetOps Spectrum
      , add the user account to the 
      DX NetOps Spectrum
       Users group. The user must then log out and log back in.
      A user who does not want to use 
      DX NetOps 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.
       To see the message again, run the following command:
      userconf -install %SPECROOT%
Duplicate Models in a Distributed Environment
In a DSS environment, 
DX NetOps 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).
 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.
 
DX NetOps 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 
    SpectroSERVER
    s 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.
 For more information, see the .
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.
 
DX NetOps 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.
For more information, see OneClick Schedules in a DSS Environment.
SpectroSERVER Shutdown
We recommend shutting down the 
SpectroSERVER
 using the 
DX NetOps 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.
 In previous releases, landscape entries timed out after one hour, and they were removed automatically from the landscape map. Starting in 9.2.2, landscape entries do not time out by default.
 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 .
 
Follow these steps:
 
  1. Navigate to the <
    $SPECROOT
    >/LS directory.
  2. Update or add the following entry in the .locrc file:
    MET_INTERVAL=
    time_out_value
    •  
       
      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
 
Symptom:
 
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.
 
Solution:
 
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 
    SpectroSERVER
    s 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
      .
       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.
     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 
    SpectroSERVER
    s 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.
 
Troubleshooting
 
 
Problems with Purging Old Landscapes
 
 
Symptom:
 
Our production 
DX NetOps Spectrum
 environment consisted of a single distributed installation. The environment had multiple 
SpectroSERVER
s and OneClick servers, which all used the same Main Location Server.
We decided to remove two 
SpectroSERVER
s and a OneClick server from the production environment to create a separate development environment. We configured the development 
SpectroSERVER
s 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.
 
Solution:
 
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.
 
Solution:
 
You can use the following command to remove stale landscapes from the development landscape map:
MapUpdate -remove landscape handle
 
Solution:
 
You can restart all 
SpectroSERVER
 processes. Then restart the OneClick server. For more information about OneClick server administration, see OneClick Administration.
When you restart the servers, the issue is resolved.
 Its is mandatory to reboot the server after you complete a fresh SpectroSERVER installation while installing r10.3.
 
 
The landscape handle bitmask in the SpectroSERVER database file does not match the bitmask of 
DX NetOps Spectrum
 
 
Symptom:
 
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 
DX NetOps 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. 
 
Solution:
 
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 
DX NetOps 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