Skip navigation.
Downloads | Product Documentation | Support

Installing the Administration Server

# Installing

The following sections describe how to install the Administration Server on both Windows and UNIX systems:

- Before you Begin
- Starting the Installation Program on Windows Platforms
- Starting the Installation Program on a Sun Solaris Platform
- Starting the Installation Program on a Linux Platform
- Running the Installation Program
- Installing a Secondary Administration Server

# Before you Begin

Before you begin this installation procedure, make sure to do the following:

- Download and read the Release Notes from: http://e-docs.bea.com/ales/docs21/download.html
- Ensure that your computer meets all the prerequisites described in Preparing to Install.
- Install WebLogic Server 8.1 (with Service Pack 4 or Service Pack 5) or Apache Tomcat 5.0.28 to use as the servlet container for the Administration Server.
- Do one of the following to acquire a user account on a database server that will provide a policy data store for the Administration Server:

- If you plan to use an existing Oracle or Sybase database, get a user account on that database.
- If you plan to install an Oracle or Sybase database, install and configure a database server and set up a user account.

- Obtain secure usernames and passwords. For more information on usernames and passwords, see below.

The following topics provide additional information to assist you in preparing for an installation:

- System Security and BEA AquaLogic Enterprise Security
- Secure Usernames and Passwords
- Generating a Verbose Installation Log

## System Security and BEA AquaLogic Enterprise Security

Like any component running on a system, the infrastructure it provides is only as secure as the operating environment where it is installed. When BEA AquaLogic Enterprise Security is installed on a system, it makes use of that system's security infrastructure to lock itself down and integrate with the security of its environment. Through the use of user, group, and file system permissions, BEA AquaLogic Enterprise Security allows limited access to many operations depending upon these permissions. For more information on users, groups, and file system permission, see the following topics:

- System Users
- System Groups
- File System Permissions

### System Users

BEA AquaLogic Enterprise Security uses two user identities when installed on a system. These identities are selected when the first product in BEA AquaLogic Enterprise Security family is installed and are referred to as the Administration User and the Service Control Manager User.

The Service Control Manager user is the identity assumed by the Service Control Manager when it starts. The Service Control Manager is the component that brokers trust between the local system and the Administration Server.

The other identity on the system is the Administration User. The Administration user owns all files (other than the Service Control Manager) and, on an Administration Server, is the identity the Administration Server assumes when it starts.

### System Groups

Two groups are used in addition to the user identities to secure the Application Security Infrastructure.

- The Security Administrators Group allows users other than the Service Control Manager user or the Administrative user to perform log maintenance, creation and destruction of new instances, and other administrative tasks.
- The Security Users Group permits users on the system to have the necessary permissions to use and execute applications protected by AquaLogic Enterprise Security. All AquaLogic Enterprise Security users, including administrators, must belong to this group.

### File System Permissions

File system permissions are used to enforce user and group based restrictions. With each product, and instance a lockdown script is created and run when installation occurs: `lockdown.bat` (Windows) or `lockdown.sh` (Unix or Linux). This lockdown script can be run again at a later time to restore the installation to the recommended file system permissions.

There are two directories that contain executable tools and utilities: `adm` and `bin`. The `adm` directory contains tools and utilities that only an administrator can run, for example `enrollment`. The `bin` directory contains tools and utilities that all security users can run, for example`set-env`. The `log` directory is writable by all security users, but can only be read by security administrators (or on UNIX, only the instance owner). The `work` directory is a temporary directory that can only be read and written to by security users.

## Secure Usernames and Passwords

AquaLogic Enterprise Security implements a sophisticated username and password schema to protect the application itself and to ensure secure communications. Understanding this schema is important to installing the product and ensuring that it operates properly in either a development or production environment.

There are three levels of password protection: local system usernames and passwords (protect the AquaLogic Enterprise Security components), passwords for keystores (secure communication between components), and a password to protect the private keys (the Certificate Authority). Understanding your enterprise and how responsibilities in your organization are separated is essential to establishing a secure environment. For example, the person who maintains the database is usually not the person who designs and implements security. The person who deploys applications is usually not the person who administers system usernames and passwords. And, while you may not be as concerned with a more formal authorization scheme in your development environment, your production environment needs to be firmly secured and responsibilities clearly defined.

AquaLogic Enterprise Security user accounts on Windows platforms, like `asiadmin` and `scmuser` are special (see System Users and System Groups), and cannot be used to logon to any interactive session; these passwords are used for registration purposes only. They can only be used to start and stop component services. After the installer collects all of the passwords, it encrypts them in an internal password file. Later on, the service engine uses the username and password to register AquaLogic Enterprise Security as a Windows service. Therefore, the user may not need to change the password for the newly created specific usernames like `asiadmin` and `scmuser`; but, optionally, they can be changed if necessary.

Note: If these usernames already exist (they were generated as a part of a previous install process), you must enter the correct password. Remember to write down all usernames and passwords and store them in a safe place.

Usernames and passwords are required to access the components listed and described in Table 3-1.

Table 3-1 Usernames and Passwords

Component | Description | Default
--- | --- | ---
Database Server | A database server account used to connect to the database server where the policy data is stored, and update policy data using the policy import and export tools. | none
Administration Server | A local user account used to start the Administration Server and all Administration Server components. | User: `asiadmin` Group: `asiadgrp`
Service Control Manager | A local user account used to start the Service Control Manager. | User: `scmuser`
Security Group | A local group that includes all users of AquaLogic Enterprise Security. All users of AquaLogic Enterprise Security must be members of this security group, including administrators. | Group: `asiusers`
Certificate Authority | Sets the password for the private key for the Certificate Authority. All trust within the enterprise domain originates from this authority. | Randomly generated
Identity Key Passwords (Keystore Passwords) | You also need to supply private key passwords for each of the following identities: Service Control Manager Security Service Module Administration Application Private key passwords validate process authenticity by using the Certificate Authority chain of trust. Identities with invalid or untrusted keys cannot participate in the trust relationships in the enterprise domain. | Randomly generated
Configure Keystores | You need to supply keystore passwords for each of the Identity, Peer and Trust keystores. Identity Keystore - stores and protects the private keys that represent the processes identity or identities. Peer Keystore - stores and protects the public keys for all trusted identities within the installed component (Administration Application, Security Service Module or Service Control Manager). Trust Keystore - stores and protects public keys for Certificate Authorities that originate the chain of trust. | Randomly generated

BEA recommends following these guidelines:

- Development Environment—In a development environment, you can either use the default values generated during the installation process or you can assign your own usernames and passwords to protect your public and private keys.
- Production Environment—In a production environment, you must choose all passwords explicitly. These passwords may be needed for future maintenance of the public key infrastructure (PKI), for example, in the case of a failure. Make sure to write down all password information and retain it in a secure location.

Note: BEA does not recommend the use of randomly generated passwords, as the generation mechanism for these passwords is not secure. In a production environment, BEA does not recommend installing Security Service Modules on the same machine as the Administration Server.

## Generating a Verbose Installation Log

If you start the installation process from the command line or from a script, you can specify the `-log` option to generate a verbose installation log. The installation log lists messages about events that occur during the installation process, including informational, warning, error, and fatal messages. This can be especially useful for silent installations.

Note: You may see some warning messages in the installation log. However, unless there is a fatal error, the installation program completes the installation successfully. The installation user interface indicates the success or failure of the installation, and the installation log file includes an entry indicating that the installation was successful.

To create a verbose log file during installation, use the following command lines or scripts:

- For Windows platforms:

>     ales210admin_win32.exe -log=D:\bea\logs\ales_install.log

- For the Sun Solaris platform:

>     ales210admin_solaris32.bin -log=/bea/logs/ales_install.log

>     ales210admin_solaris32.bin -log_priority=debug

- For the Linux Red Hat Advanced Server platform:

>     ales210admin_linux32.bin -log=/bea/logs/ales_install.log

>     ales210admin_linux32.bin -log_priority=debug

Note: The -`log` parameter is optional. By default, the installation log is put in the log directory where you install the Administration Server. If for some reason, the installer fails, use this switch to generate an even more verbose output:`-log_priority=debug.`

The path must be the full path to a file name. If the file does not exist, all folders in the path must exist before you execute the command or the installation program does not create the log file.

# Starting the Installation Program on Windows Platforms

Note: Do not install the software from a network drive. Download the software to a local drive on your machine and install it from there.

Before running the installer, ensure the following two things are done.

- Ensure the database client directories have the correct permissions.

Set the file permissions on the database client directories so that all users can read and execute the files. Run the following command:

>     cacls C:\oracle /T /E /G Everyone:F

>     Where:

>     C:\oracle is the location of your database application

- Ensure the PATH is set correctly.

It is also important to include the `/bin` directory of your database client in the system`PATH` (the path available to all users) rather than the `user PATH` (the path only available to the current user). If this is changed, you must reboot before the change becomes available to processes running as services (which is how the Administration Server initializes itself).

To install the application in a Microsoft Windows environment:

1. Shut down any programs that are running.
2. Log in to the local Administrators group.
3. If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:

1. Contact BEA Sales at http://www.bea.com/framework.jsp?CNT=sales1.htm&FP=/content/about/contact/ and request a download.
2. Go to the directory where you downloaded the installation file and double-click ales210admin_win32.exe.

The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

4. If you are installing from a CD-ROM:

1. Insert Disk 1 into the CD-ROM drive.

If the installation program does not start automatically, open Windows Explorer and double-click the CD-ROM icon.

2. From the installation CD, double-click`` ales210admin_win32.exe.

The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

5. Proceed to Running the Installation Program.

Figure 3-1 AquaLogic Enterprise Security Administration Server Installer Window

# Starting the Installation Program on a Sun Solaris Platform

To run graphical-mode installation, your console must support a Java-based GUI. If the installation program determines that your system cannot support a Java-based GUI, the installation program automatically starts console-mode installation.

Before running the installer, ensure the following three things are done.

- Ensure the database client directories have the correct permissions.

Set the file permissions on the database client directories so that all users can read and execute the files. For example, if you are using Oracle 9i, run the following command:

>     chmod -R o+rx /opt/ora92

- Ensure the PATH is set correctly.

It is also important to add the `/bin` directory to `PATH` and the /lib directory to `LD_LIBRARY_PATH`. If these settings are changed, you must reboot before the changes become available to processes running as services (which is how the Administration Server initializes itself).

Note: BEA recommends setting these variables in `/etc/profile` so they are available to all processes starting from `init`.

- Ensure that the location into which you do the install is accessible to all users at both the parent and the child directory levels.

For example, if the installation directory is `/opt/beahome/ales21-admin` and the `/opt/` directory is only accessible by root, post installation scripts that run as a user other than root cannot access the directory where they reside. Therefore, the directory into which you do the install (for example, `/opt/beahome/ales21-admin`) must have execute permissions for `other.` Run the following command to reset the permissions:

>     chmod o+x /opt/

The `beahome` and `ales21-admin` directories already have permissions set appropriately.

To install the application on a Sun Solaris platform:

1. Log in to the machine as root.
2. Set your `DISPLAY` variable if needed.
3. If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:

1. Contact BEA Sales at http://www.bea.com/framework.jsp?CNT=sales1.htm&FP=/content/about/contact/ and request a download.
2. Go to the directory where you downloaded the file and change the protection on the install file:

>     chmod u+x ales210admin_solaris32.bin

3. Start the installation`:` ./ales210admin_solaris32.bin

The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

4. If you are installing from a CD-ROM:

1. Insert Disk 1 into the CD-ROM drive.
2. From the installation CD, execute ales210admin_solaris32.bin.

The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

5. Proceed to Running the Installation Program.

# Starting the Installation Program on a Linux Platform

To run graphical-mode installation, your console must support a Java-based GUI. If the installation program determines that your system cannot support a Java-based GUI, the installation program automatically starts console-mode installation.

Before running the installer, ensure the following three things are done.

- Ensure the database client directories have the correct permissions.

Set the file permissions on the database client directories so that all users can read and execute the files. Run the following command:

>     chmod -R o+rx /opt/ora92

- Ensure the PATH is set correctly.

It is also important to add the `/bin` directory to `PATH` and the /lib directory to `LD_LIBRARY_PATH`. If these settings are changed, you must reboot before the changes become available to processes running as services (which is how the Administration Server initializes itself).

Note: BEA recommends setting these variables in `/etc/profile` so they are available to all processes starting from `init`.

- Ensure that the location into which you do the install is accessible to all users at both the parent and the child directory levels.

For example, if the installation directory is `/opt/beahome/ales21-admin` and the `/opt/` directory is only accessible by root, post installation scripts that run as a user other than root cannot access the directory where they reside. Therefore, the directory into which you do the install (for example, `/opt/beahome/ales21-admin`) must have execute permissions for `other.` Run the following command to reset the permissions:

>     chmod o+x /opt/

The `beahome` and `ales21-admin` directories already have permissions set appropriately.

To install the application on a Linux platform:

1. Log in to the machine as root.
2. Set your `DISPLAY` variable if needed.
3. If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:

1. Contact BEA Sales at http://www.bea.com/framework.jsp?CNT=sales1.htm&FP=/content/about/contact/ and request a download.
2. Go to the directory where you downloaded the file and change the protection on the file:

>     chmod u+x ales210admin_linux32.bin

3. Start the installation`: ./`ales210`admin_linux32.bin`

The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

4. If you are installing from a CD-ROM:

1. Insert Disk 1 into the CD-ROM drive.
2. From the installation CD, execute ales210`admin_linux32.bin`.

The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

5. Proceed to Running the Installation Program.

# Running the Installation Program

The installation program prompts you to enter specific information about your system and configuration, as described in Table 3-2.

Note: You must install the Administration Server first, before installing your Security Service Modules. BEA does not recommend installing Security Service Modules on the same machine as the Administration Server in a production environment.

To complete this procedure you need the following information:

- For Windows, a username and password for the Administration Server account
- For Windows, a username and password for the Service Control Manager account
- Name of the `BEA HOME` directory
- Name of the product directory
- Database connection information (see your database administrator and Setting Up and Administering the Database for details).

####

Table 3-2 Administration Server Installation

In this Window: | Perform this Action:
--- | ---
Welcome | Click Next to proceed or cancel the installation at any time by clicking Exit.
BEA License Agreement | Read the BEA Software License Agreement, and then select Yes to indicate your acceptance of the terms of the agreement. To continue with the installation, you must accept the terms of the license agreement, click Yes, and then click Next.
Choose BEA Home Directory | Specify the BEA Home directory that serves as the central support directory for all BEA products installed on the target system. If you already have a BEA Home directory on your system, you can select that directory (recommended) or create a new BEA Home directory. If you choose to create a new directory, the installer program automatically creates the directory for you.
Choose Product Directory | Specify the directory in which to install the Administration Server software. You can accept the default product directory (`ales21-admin`) or create a new product directory. If you choose to create a new directory, the installation program automatically creates the directory for you, if necessary. Click Next to continue.
Choose Service Control Manager Directory | Specify the directory in which to install the Service Control Manager. You can accept the default directory (`ales21-scm`) or you can create a new one. Click Next to continue.
Choose the Web Server to install the administration application | Specify the type of servlet container (WebLogic Server or Tomcat) and the directory in which it is installed. For WebLogic Server on Microsoft Windows, the product is installed in `C:\bea` by default. For Apache Tomcat on Microsoft Windows, the product is installed in `C:\Program Files\Apache Software Foundation\Tomcat 5.0` by default. Click Next to continue.
Select Users and Groups | Specify the usernames and group names to use for the Service Control Manager and Administration Server. You can accept the default settings or create new ones. Note: When installing this product for use in a production environment, BEA recommends that you set these passwords to known values; otherwise you will not be able to modify them later. For example, you may want to modify these passwords to comply with organizational requirements. Admin User (asiadmin) A local user account used to start the Administration Server components. Admin Group (`asiadgrp`) Administration Server group. Members of this group have full access to Administration Server and log files; they can start and stop the Administration Server components. SCM User (`scmuser`) A local user account used to start the Service Control Manager. Security Group (`asiusers`) Service Control Manager Group. Members of this group are allowed to use the AquaLogic Enterprise Security product. Click Next to continue.
Confirm User Selection | If the name of the user and group do not yet exist, they are created for you. Verify the values that you entered are correct, and then click Next.
User Passwords (Windows only) | Specify the password for the Administrative User and Service Control Manager User. The passwords are automatically generated randomly. You may modify them. Note: If any of the users exist as a result of previous installations, you must enter their passwords. Note: Passwords are case sensitive. If you are installing the Administration Server in a production environment, BEA Recommends that you change the randomly generated passwords with strong passwords that meet your local system password policy. The installer will not continue if it is unable to generate the users on windows. And this normally happens because the passwords entered do not meet the password strength requirements of the local machine. Click Next to continue.
Choose Network Interfaces | Select the network interfaces to which to bind the Service Control Manager. This is the IP Address used to listen for requests to distribute policy and configuration data. Note: If you are installing the Administration Server in a production environment with more than one network card, you want to select a protected (internal) interface; you do not want to expose the Service Control Manager through a public address. Click Next to continue.
Configure Administration Application | Enterprise Domain Name Enter the name to assign to this domain. The Enterprise Domain represents the collection of Security Service Modules administered by this BEA AquaLogic Enterprise Security Administration Server. Make a note of the Enterprise Domain Name you entered as you will need this to install any subsequent security service modules. Note: The Enterprise Domain Name must be entered in all lower case; and may not contain any spaces or punctuation marks.
Configure Administration Application (Continued) | Administration Application HTTP Port Enter the HTTP port number for the Administration Console of the servlet container to use. SSL Port Enter the HTTPS port number for the Administration Server to use. When you enter the SSL port number, make sure that at least five consecutive port numbers are also available. These port numbers are used by services required by the BEA AquaLogic Enterprise Security Administration Server to operate properly, and the Administration Server always runs on a secure connection using these ports. The installer checks during installation to see if any of the ports are used, skips those that are used, and selects the next available port. Note: The installer is not be able to detect a port already assigned to another process that is currently not running. Hence there may be a port bind problem if two process try to use the same port.
Configure Administration Application (Continued) | Certificate Authority Duration (years) Enter the number of years the security certificate remains in effect. The Certificate Authority is used to generate and sign certificates for other components in the BEA AquaLogic Enterprise Security system. Secondary Server URL This URL is only necessary if you plan on installing the Security Service Modules on the same machine as your Administration Server and plan on configuring the Security Service Modules with a backup Administration Server. Otherwise, you can leave this URL blank. Click Next to continue.
Configure Database Connection | Database Client Select the type and version of database client you are using (Sybase or Oracle) on this machine. The prompts that appear differ depending on the type of client you select. Database Connection For Oracle: Oracle Service Name Local service name (Oracle System Identifier SID). Database JDBC URL Change the <`SID`> and <`SERVER`> name to complete the JDBC URL: `jdbc:oracle:thin:@<SERVER>:1521:<SID>` Database JDBC Driver The Oracle driver to use by default: `oracle.jdbc.driver.OracleDriver`
Configure Database Connection (Continued) | Database Connection For Sybase: Sybase Host Name Sybase server entry you configured in this local machine, used to connect to Sybase database server running elsewhere. Sybase Database Name Name of the Sybase database—the name of policy database. Database JDBC URL Change the <`hostname_or_IP`> and <`databaseName`> name to complete the JDBC URL, assuming the Sybase server is running on port 4100: The <`hostname_or_IP`> is the hostname or IP address of the machine running Sybase server, and <`databaseName`> is the policy database name. You may need to change port number if necessary. The Sybase server usually listens on port 5000 on the Windows platform and 4100 on other platforms: `jdbc:sybase:Tds:<hostname_or_IP>:4100/<databaseName>` or `jdbc:sybase:Tds:<hostname_or_IP>:4100` You can use the latter URL format when the default database for Login ID is set to the policy database. Database JDBC Driver The Sybase driver to use by default: `com.sybase.jdbc2.jdbc.SybDriver`
Configure Database Connection (Continued) | Database Login Login ID, Password, Confirm Password The database login id (username) and password to use to connect to the database; you must confirm the password. Note: During installation, the installer checks using the install time to see whether it can establish a JDBC connection with the parameters entered. If this test fails, then the installer does not continue until a valid JDBC URL, username, and password are supplied. Click Next to continue.
Configure Certificate Authority | The Certificate Authority is used to generate and sign certificates for other components in the BEA AquaLogic Enterprise Security system. Key Password You can either choose to use a randomly generated password or you can specify the private key password. You must confirm the password. Note: You should write down or remember all passwords and store them in a safe location should you ever need to use them again. For example, if you plan to install redundant servers, you need to use the same keystore and key passwords. Click Next to continue.
Configure Keys | Enter the following key passwords to secure communications of internal processes. These are components of the Administration Server. Private key passwords are used to validate process authenticity by using the Certificate Authority chain of trust. Identities with invalid or untrusted keys cannot participate in the trust relationships of the enterprise domain. Service Control Manager Security Service Module Administration Application
Configure Keystores | You may supply keystore passwords for each of the Identity, Peer and Trust Certificate Authority keystores or accept the randomly generated passwords. Identity Keystore—stores and protects the private keys that represent the processes identity or identities. Peer Keystore—stores and protects the public keys for all trusted identities within the installed component (Administration Application, Security Service Module or Service Control Manager). Trust Certificate Authorities Keystore—stores and protects public keys for Certificate Authorities that originate the chain of trust.
Installation Complete | This page indicates the Administration Server completed successfully. If you want to install the policy database schema now, check the Install Database Schema check box. There are two situations where you should not elect to the install the policy database schema: If you previously installed the policy database schema for the Administration Server and made modifications, you should not reinstall it again because your modifications will be lost. If you are installing a failover server for backup and failover purposes, you must not install the database schema again, because the failover server uses the same database schema. Note: Be sure to write down the Administration Server URL. You will need this URL when you are installing additional components. Click Done to complete the installation.

# What's Next

Now that you have installed the necessary software, you must start the necessary services. For additional instructions, see Post Installation Tasks. If you want to install a second Administration Server to use as a backup, see Installing a Secondary Administration Server.

# Installing a Secondary Administration Server

You may want to install and configure a second Administration Server to support failover. For information on failover considerations, see "Failover and System Reliability in the BEA AquaLogic Enterprise Security Administration Guide.

The secondary Administration Server must be set up in the same manner as the primary and installed on a separate machine.

1. Install the servlet container, Weblogic Server 8.1 or Apache Tomcat.
2. Run the installation program to install the secondary Administration Server.
3. Enter the following information:

1. When prompted for the Enterprise Domain, make sure to enter the same domain name that you entered during the primary installation (default is `asi`).
2. When prompted for the Secondary Server URL, leave this blank, unless you plan on installing one of the Security Service Modules on the machine that hosts the backup Administration Server. In this case, specify the URL of the primary Administration Server.
3. When entering the Database Configuration, make sure to use the exact same configuration that you specified during the primary installation.
4. The database password used by the primary and backup Administration Servers are independent of each other. This allows you to use instance specific passwords to protect the various sensitive artifacts on the Administration Servers. For example, you may use different key passwords for the CA, Admin, SSM, and SCM identities that you entered in the primary installation. The same applies to the Identity, Peer, and Trust key store passwords.

Note: Do not install the database schema at the conclusion of the backup installation process. Do not run the `initialize_backup_trust.bat` `(on Windows platforms) or initialize_backup_trust.sh (on Unix platforms)` command after installing the backup.

4. Initialize the Backup Administration Server Trust Stores.

Before starting the backup Administration Server, you must synchronize the various trust stores used by the backup Administration Server with those of the primary. If this is not done, the backup Administration Server will not trust the Security Service Modules currently enrolled with the primary, and as a result, failover will not work.

To initialize the backup Administration Server trust stores, do the following:

1. Copy the primary Administration Server and primary Service Control Manager ssl directories to the machine that hosts the backup Administration Server. One way to do this is to copy the primary Service Control Manager ssl directory onto a floppy disk or other removable media, and rename the ssl directory to scm-ssl. Likewise, copy the primary Administration Server ssl directory to the same removable media and rename the ssl directory to admin-ssl. Mount the removable media on the machine that hosts the backup Administration Server.
2. Execute the `initialize_backup_trust.bat` (on Windows platforms) or `initialize_backup_trust.sh` (on Unix platforms) command from the bin directory of the backup Administration Server install. When prompted for the primary Service Control Manager SSL directory, enter the path to the scm-ssl directory created in the previous step. Likewise, when prompted for the primary Admin SSL directory, enter the path to the admin-ssl directory created in the previous step.
3. Delete the ssl directories on the removable media.

5. Start the backup Administration Server as you normally would a primary.
6. Configure the Backup Server Trust Synchronization Mechanism.

Even though the backup Administration Server trust stores are synchronized with those of the primary in step 4, it is possible for them to become out of sync over time. This happens when a new Security Service Module or Service Control Manager is enrolled with the primary Administration Server. The trust stores of the primary Administration Server are updated with the new Security Service Module or Service Control Manager certificate during enrollment, but since an Security Service Module or Service Control Manager should only be enrolled with its primary, the backup Administration Server trust stores do not have the new certificate.

A similar trust situation occurs during Security Service Module or Service Control Manager unenrollment. To prevent the trust stores from becoming unsynchronized, the Administration Server has a trust synchronization mechanism that should be enabled on the backup Administration Server. The trust synchronization mechanism on the backup Administration Server periodically pools the primary for any updates to its trust store, and if a change has occurred, the mechanism updates the backup trust store with the contents of the primary. It is very important that you only enable the trust synchronization mechanism on the backup Administration Server.

See "Configuring the Administration Server for Failover" in the Administration Server Console Help for details on how to configure the backup server.