When installing the Administration Service, you now have the option to specify a separate database for storing Management History data. This installation option is intended to support advanced deployment scenarios where it is impractical to use the same database for both Management History data and Configuration data. The use of a separate Management History database could be justified by reducing replication traffic when multiple Administration Service instances synchronize their configuration data via ActiveRoles Server replication, or by reducing database size when multiple Administration Service instances share the same Configuration database.
It is important to note that multiple Administration Service instances can be configured to share common Management History data only if they share common configuration data. Data sharing may be achieved by means of ActiveRoles Server replication or by having multiple Administration Service instances use the same Configuration or Management History database. For example, if you want two instances of the Administration Service to use the same Management History database, you have to ensure that any one of these conditions is fulfilled: (1) both instances use the same Configuration database or (2) if each of the two instances uses its own Configuration databases, the two databases are synchronized by using ActiveRoles Server replication; otherwise, the Administration Service will fail to start.
The Management History data includes:
• Information about the changes to directory data that were made by ActiveRoles Server users.
This information is used to prepare the Change History and User Activity reports.
• Information about the approval, attestation, temporal group membership, and deprovisioning tasks. This information is used by the ActiveRoles Server features such as Approval Workflow, Attestation Review, Temporal Group Memberships, and Undo Deprovisioning.
Many important features and functions of ActiveRoles Server heavily rely on consistency and availability of Management History data. With multiple Administration Service instances of common configuration, it is highly advisable for the Administration Service instances to share the same Management History data. The default installation of the Administration Service meets this requirement by using a single database to store both Configuration data and Management History data.
However, if you decide to separate the Management History data store from the Configuration data store, you can do this when installing the Administration Service: the option to store Management History in a separate database is available on the Database and Connection Settings page in the Administration Service Installation Wizard.
The behavior of the option depends upon whether you choose to create a new database or use an existing database for the Administration Service you are installing.
Creating a New Database
The Administration Service Setup program creates a new Configuration database in the following deployment scenarios:
• Installation of the new Administration Service instance on a clean computer.
• Upgrade of the Administration Service instance that uses the database of an earlier schema version.
In both scenarios, the Installation Wizard provides the option to create a separate Management History database. By default, that option is not selected with the first scenario: we recommend that the same database be used to hold both Configuration and Management History data. As for the second scenario, the Setup program checks to see whether the Administration Service instance you are upgrading is already configured to use a separate Management History database. If so, the option is selected by default; otherwise, the option is not selected.
During the upgrade, the Installation Wizard creates a new Configuration database and, if the option to use a separate Management History database is selected, it also creates a new Management History database. The default behavior of the Installation Wizard in this scenario is to import the existing configuration data to the new Configuration database. However, the existing Management History data is not imported during the upgrade. You have to use the Management History Migration Wizard to import the Management History data after the upgrade. The data should be imported to the database you chose to store Management History: the database that also stores Configuration data or a separate database.
For more information and instructions, see the “Importing Management History Data” section in the ActiveRoles Server Quick Start Guide.
Using an Existing Database
Another deployment scenario that involves the use of a separate Management History database is as follows:
• You already have an Administration Service instance deployed that stores Management History in a separate database.
• You want to install an additional Administration Service instance and configure the new instance to use the same Management History database as the existing instance.
In this scenario, when installing the new Administration Service, you select the corresponding option on the Database and Connection Settings page in the Installation Wizard, and then specify the location and the name of the Management History database that is used by the existing instance of the
Administration Service.
With this scenario, you configure two instances of the Administration Service to use the same
Management History database, so you need to ensure that both instances have the same configuration data. When installing the additional Administration Service instance, choose the option to share common configuration database.
For more information and instructions on how to separate the Management History data store from the Configuration data store, see the “Replication of Management History Data” and “Centralized
Management History Storage” sections in the ActiveRoles Server Administrator Guide.
How to Start
Use the following steps to upgrade an Administration Service instance of an earlier version in the situation where the instance is configured to use a separate Management History database.
1. Ensure that the Administration Service instance you are going to upgrade does not participate in ActiveRoles Server replication:
a) In the ActiveRoles Server console connected to that Administration Service instance, and inspect the contents of the Configuration/Server Configuration/Configuration Databases container to verify that the replication role of the database server is Standalone.
b) If the database server has the replication role of Subscriber, connect to the Publisher Administration Service and delete that Subscriber from the Configuration Databases container.
c) If the database server has the replication role of Publisher, delete all the Subscribers from the Configuration Databases container and then run the Demote command on the Publisher in that container.
2. Start the Administration Service Setup program from the ActiveRoles Server page in the ActiveRoles Server CD Autorun window (click the corresponding link on that page).
3. Follow the steps in the Installation Wizard until you reach the Database and Connection Settings step.
4. Verify the settings on the Database and Connection Settings page to ensure that the Store Management History in a separate database check box is selected, and then click Next.
5. On the Management History Database page, specify the location and name of the database to be used for storing Management History by the Administration Service after the upgrade.
This cannot be the database that is used by the Administration Service instance you are upgrading. Setup needs to create a new database since the existing one is incompatible with the new version of ActiveRoles Server.
6. Follow the steps in the Installation Wizard to complete the upgrade.
During the upgrade, the Setup program imports the Configuration data from the database of the earlier version. To import the Management History data, use the Management History Migration Wizard after the upgrade of the Administration Service is completed.