Replication is already configured
This section outlines the instructions on how to turn off replication of Management History data in case that Active Roles replication is already configured as described in Configuring replication. You need to first delete all Subscribers for Management History data, and then demote the Publisher for Management History data. This only stops replication of Management History data, leaving the other replication functions intact.
To turn off replication of Management History data
-
With the Active Roles Console, connect to the Administration Service whose SQL Server holds the Publisher role.
-
In the Console tree, expand Configuration > Server Configuration, and select the Management History Databases container.
-
Use the Delete command on each of the Subscriber databases to delete all Subscribers in the Management History Databases container.
-
Right-click the Publisher database, and click Demote.
-
Wait while the console completes the Demote operation.
Re-configuring replication of Management History data
With replication of Management History data turned off, it is still possible to have multiple Administration Services maintain the same Change History log by configuring them to use the same database. Note that the Administration Service version 6.x allows you to install multiple Services with the option to connect to a single configuration database. Thus, you can install the first Service in your environment, having the Setup program create a database. Then, you can install one more Service, having the Setup program configure the new Service to use the same database as the existing Service.
However, if different Administration Service in your environment use different database servers, you may need to re-configure replication of Management History data in order to take full advantage of the Management History feature. You can do so by managing objects in the Management History Databases container as follows.
To re-configure replication of Management History data
-
With the Active Roles Console, connect to the Administration Service whose SQL Server holds the Publisher role for configuration data.
-
In the Console tree, expand Configuration > Server Configuration, and select the Management History Databases container.
-
In the details pane, right-click the database, and click Promote.
-
Wait while the Console performs the Promote operation.
-
Use the Add Replication Partner command on the Publisher database in the Management History Databases container to add Subscribers for Management History data.
The Add Replication Partner command starts the wizard that is similar to that discussed in the Adding members to a replication group section. The only difference is that the list of Administration Services whose database servers can be designated as Subscribers for Management History data is limited to those Services that share the configuration data hosted on the Publisher you have selected.
Centralized Management History storage
With the default replication settings in Active Roles, the Management History data is synchronized between replication partners, along with the Configuration data. Given a large volume of Management History data, this behavior may result in high network traffic and may cause performance degradation of Active Roles in certain scenarios, such as when adding a new partner to the Active Roles replication group. Here you can find instruction on how to eliminate replication of Management History data by implementing a common storage of that data for all replication partners.
Synchronization of the Management History data can be removed from the Active Roles replication process by implementing a common storage of that data for all replication partners. The common storage ensures the consolidation of the portions of Management History data that are generated by different Administration Services, while eliminating the need to synchronize that data between multiple storages.
By default, Active Roles allows you to implement a centralized, common storage for the Management History data. In this way, all the Administration Services that share common configuration use the same Management History storage - the Management History database you created.
Importing Management History data
After configuring the Administration Service, the Management History data storage will be empty with the option to create a new database. During the import of configuration data, the Configuration Center transfers only the administrative right assignments, policy definitions, administrative view settings, workflow definitions and other parameters that determine the Active Roles work environment. Management History data is excluded from the import operation to reduce the time it takes to upgrade the configuration of the Administration Service.
The Management History data describes changes that were made to directory data via Active Roles. This includes information about directory data management tasks, such as:
-
The changes a user performed.
-
The users performing the changes.
-
The time the change was performed.
The Management History data is used for change history and user activity reports. In addition, the Management History data storage holds information about various tasks related to approval workflows and temporal group memberships.
After configuring the Administration Service and importing configuration data from an existing database, you must take additional steps to transfer the Management History data. You can do this using the Import Management History wizard in the Active Roles Configuration Center.
You can populate the newly-created Management History database with your existing Management History data. This ensures that the data is available in the Active Roles user interfaces after configuring the Administration Service to use the new Management History database. You can import existing Management History data with the Active Roles Configuration Center on the computer running the Administration Service instance.
IMPORTANT: The reports created by the Change History or User Activity commands (available both in the Active Roles Web Interface and the Active Roles Console components) only include information about the changes that were made using a specific Administration Service group. This group must share a common database from the connected Management History database. If the change history data is not imported from the previously available database, the data will not be included in the new database.
To import Management History data
-
From the Windows Start menu, open the Active RolesConfiguration Center.
-
In the Configuration Center main window, under Administration Service, click Manage Settings.
-
To open the Import Management History wizard, on the Administration Service page, click Import Management History.
-
On the Source database page, select the source database:
-
Database Type: Select the required database type from the drop-down:
-
On-premises
-
Azure SQL database
-
Database Server name: Enter the name of the database instance that hosts the source database.
-
Database name: Enter the name of the source database.
-
Under Connect using , select the authentication option:
-
If your Windows login account has sufficient rights to write data to the destination database, click Windows authentication.
-
If you have an SQL Server login with sufficient rights, click SQL Server authentication and enter the login name and password.
-
If you selected Azure SQL as the database type and you have an Azure AD login with sufficient rights, click Azure Active Directory authentication and enter the login name and password.
-
(Optional) Copy SQL Server users and login data after importing Management History data. This option is enabled by default, if you selected the On-premises database type.
NOTE: Due to limitations in Azure SQL, Active Roles cannot synchronize SQL Server logins to Azure SQL databases.
To synchronize SQL Server users to Azure SQL, One Identity recommends using system-provided Microsoft tools, such as Azure Data Studio or Azure Database Migration Service (DMS) Classic.
For more information on migrating Microsoft SQL Server users to Azure SQL, see the following Microsoft documentation resources:
To skip the synchronization of users and login data:
-
Click Configure advanced database properties.
-
Clear the Copy database users, permissions, logins and roles check box.
-
Click Apply.
-
Click Next.
On the Destination database page, specify the database of the Administration Service instance to which you are importing data, and select the authentication option.
-
Under Connect using, select the authentication option:
-
If your Windows login account has sufficient rights to write data to the destination database, click Windows authentication.
-
If you have an SQL Server login with sufficient rights, click SQL Server authentication and enter the login name and password.
-
If you selected Azure SQL as the database type and you have an Azure AD login with sufficient rights, click Azure Active Directory authentication and enter the login name and password.
-
Click Next.
On the Records to import page, to import all data records, select All records. To import only data records from a specific time interval, select Records in the following date range, then specify a date range.
NOTE: Consider the following when selecting whether to import all data records or only records from a specific date range:
-
If you select to import all data records, or specify a date range which also includes the current day, then the Management History wizard will create a timestamp for the current day to ensure that all data records created up to the point of starting the migration will be imported. This means that the wizard will import all data that existed in the source database at the time the migration started, but will not import any data records that have been created after starting the migration.
-
If you select a date range manually, you cannot select future dates.
-
Data for unfinished temporal group memberships are imported only if you import Management History data for a selected date range.
-
Click Next.
On the Ready to import page, review your settings. If needed, return to the previous pages and make adjustments.
-
To start the import process once your changes are finalized, click Import.
On the Run page, you can see the progress of the import process. After the operation finished, the wizard shows a summary and a link that you can use to check the import log.
NOTE: During the import process, consider the following:
-
You can cancel the import process at any time. However, the wizard will not stop the import immediately, but only after it finishes the currently performed step of the operation. Active Roles will not delete the data that the wizard has successfully imported to the destination database before canceling the operation.
-
If an SQL exception occurs during migration, the operation will not be canceled. Instead, the wizard will restart the migration of that specific batch of data. The retry policy ensures that, unless there is a persistent network or database error, you do not need to restart the import process manually.
If the SQL exception is network-related or transient, the wizard will retry the migration of the failed batch up to 3 times. If the SQL exception occurs for other reasons, the wizard will only retry the migration once.
Depending on the severity of the exception, one of the following events can occur:
-
If the error is resolved and the migration of the failed batch is successful, then the wizard proceeds with importing the remaining data.
-
If the error is not resolved after the maximum number of retries, the wizard cannot proceed with the migration and cancels the process. You can restart the migration manually, but if the issue persists, check the log for details and contact your network administrator or database administrator.
-
To check the detailed log of the import operation, click View log. To exit the wizard, click Finish.
NOTE: The Import Management History wizard only adds new data, keeping intact any data that already exists in the destination database. You can import your legacy Management History data at any time after you have configured the Administration Service, without the risk of losing any data.