Chat now with support
Chat with Support

Active Roles 7.5.2 - Quick Start Guide

Introduction Active Roles Setup package Active Roles uninstallation System Requirements Deploying the Administration Service Deploying user interfaces Installing additional components Upgrade of an earlier version Performing a pilot deployment Deployment considerations Silent installation of Active Roles components Configuring Active Roles to Manage Hybrid Active Directory Objects Active Roles on Windows Azure VM

Configuring the Administration Service account

When installing the Administration Service, you are prompted for the name and password of the Administration Service account—the account the Administration Service logs on to. This account must have sufficient permissions to:

  • Gain administrative access to the computer running the Administration Service.
  • Publish the Administration Service in Active Directory.
  • Access any managed domain for which an override account is not specified.

NOTE: When registering a domain with Active Roles, you can specify an override account. If you specify an override account, the Administration Service uses the override account rather than the service account to access the domain.

Access to managed domains

Active Roles access to a domain is limited by the access rights of the service account, or the override account, if specified. For all managed domains with no override account specified, you should configure the service account to have permissions you want Active Roles to have in those domains. If you use an override account when registering a domain with Active Roles, ensure that the override account (rather than the service account) has these permissions for the domain. In addition, the service account (or the override account, if any) must have the Read Permissions and Modify Permissions rights on the Active Directory objects and containers where you are planning to use the Active Roles security synchronization feature.

For more information, see Active Roles service account minimum permissions.

Access to Exchange Organizations

To manage Exchange recipients on Exchange Server 2019, 2016, or 2013, the service account or the override account must be configured to have sufficient rights in the Exchange organization. The rights must be delegated to the service account if an override account is not used; otherwise, the rights must be delegated to the override account. See the following steps for details.

To configure the service account or the override account

  1. Add the account to the Recipient Management role group.

For instructions for Exchange 2019, see “Add Members to a Role Group” at https://technet.microsoft.com/en-in/library/jj657492(v=exchg.160).aspx.

  1. Add the account to the Account Operators domain security group.
  2. Enable the account to use remote Exchange Management Shell.

    For instructions for Exchange 2019, see “Enable Remote Exchange Management Shell for a User” at https://technet.microsoft.com/en-us/library/dd335083(v=exchg.160).aspx.

  1. Ensure that the account can read Exchange configuration data (see Configuring the Administration Service account).
  2. Restart the Administration Service after you have changed the configuration of the account: Start Active Roles Configuration Center (see “Running Configuration Center” in the Active Roles Administration Guide), go to the Administration Service page in the Configuration Center main window, and then click the Restart button at the top of the Administration Service page.

NOTE:

  • For instructions for Exchange 2013, 2016, and 2019, see the relevant Microsoft Exchange pages at https://technet.microsoft.com/en-us/library.

  • ARS service account must be a part of Recipient Management group to run exchange hybrid commands.

The Exchange 2016 management tools are not required on the computer running the Administration Service.

Permission to read Exchange configuration data

To perform Exchange recipient management tasks, Active Roles requires read access to Exchange configuration data in Active Directory. This requirement is met if the service account (or the override account, if specified) has administrator rights (for example, is a member of the Domain Admins or Organization Management group). Otherwise, you should give the account the Read permission in the Microsoft Exchange container. You can do this by using the ADSI Edit console as follows (these instructions apply to the ADSI Edit console that ships with Windows Server 2016, Windows Server 2019, or Windows Server 2022):

  1. Open the ADSI Edit console and connect to the Configuration naming context.
  2. In the ADSI Edit console, navigate to the Configuration | Services container, right-click Microsoft Exchange in that container, and then click Properties.
  3. On the Security tab in the Properties dialog box that appears, click Advanced.
  4. On the Permissions tab in the Advanced Security Settings dialog box, click Add.
  5. On the Permission Entry page, configure the permission entry:
    1. Click the Select a principal link, and select the desired account.
    2. Verify that the Type box indicates Allow.
    3. Verify that the Applies onto box indicates This object and all descendant objects.
    4. In the Permissions area, select the List contents and Read all properties check boxes.
    5. Click OK.
  6. Click OK to close the Advanced Security Settings dialog box, and then click OK to close the Properties dialog box.
Support for remote Exchange Management Shell

When performing Exchange recipient management tasks on Exchange Server 2013 or later, Active Roles uses remote Exchange Management Shell to communicate with Exchange Server, so you do not need to install the Exchange management tools on the computer running the Administration Service.

To use remote Exchange Management Shell, the Administration Service must be running on a computer that has:

Remote Shell also requires the following:

  • TCP port 80 must be open between the computer running the Administration Service and the remote Exchange server.
  • The user account the Administration Service uses to connect to the remote Exchange server (the service account or the override account) must be enabled for remote Shell. To enable a user account for remote Shell, update that user account by using the Set-User cmdlet with the RemotePowerShellEnabled parameter set to $True.
  • Windows PowerShell script execution must be enabled on the computer running the Administration Service. To enable script execution for signed scripts, run the Set-ExecutionPolicy RemoteSigned command in an elevated Windows PowerShell window.

Access to managed AD LDS instances

Active Roles access to Active Directory Lightweight Directory Services (AD LDS) instances is limited by the access rights of the service account, or the override account, if specified. For all managed AD LDS instances with no override account specified, you should configure the service account to have permissions you want Active Roles to have in those instances. If you use an override account when registering an AD LDS instance with Active Roles, ensure that the override account (rather than the service account) has these permissions for that instance.

To control access to directory data, AD LDS provides four default, role-based groups: Administrators, Instances, Readers, and Users. These groups reside in the configuration partition and in each application partition, but not in the schema partition. To register an AD LDS instance with Active Roles, the service account or, if specified, the override account must, at a minimum, be a member of the following groups:

  • Instances (CN=Instances,CN=Roles) in the configuration partition
  • Readers (CN=Readers,CN=Roles) in the configuration partition and in each application partition

To allow Active Roles full access to the AD LDS instance, add the account to the following group:

  • Administrators (CN=Administrators,CN=Roles) in the configuration partition

If you add the account to the Administrators group, you don’t need to add it to the Instances or Readers group.

Access to file servers

To enable Active Roles to perform the provisioning and deprovisioning tasks related to user home folders and home shares, the service account (or the override account, if specified) must belong to the Server Operators or Administrators group on each file server that hosts the user home folders to be administered by Active Roles.

Active Roles provides the following policy categories to automate the management of user home folders and home shares:

  • Home Folder AutoProvisioning: Performs the provisioning actions needed to assign home folders and home shares to user accounts, including the creation of home folders for newly created user accounts and renaming home folders upon renaming of user accounts. Specifies the server on which to create home folders and shares, and configures access rights to the newly created home folders and shares.
  • Home Folder Deprovisioning: Makes the changes needed to prevent deprovisioned users from accessing their home folders, including the removal of the user’s permissions on the home folder, changing the ownership of the home folder, and deleting the home folder when the user account is deleted.

The service account or override account must be configured so that it has sufficient rights to perform the operations provided for by those policies: create, modify (including the ability to change permission settings and ownership), and delete folders and shares on the designated file servers.

You can give the required permissions to the service account or override account by adding that account to the appropriate administrative group (Administrators or Server Operators) on each file server where you are planning Active Roles to manage user home folders.

Access to BitLocker recovery information

Viewing BitLocker recovery passwords in Active Roles requires the domain administrator rights for the account being used by the Active Roles Administration Service to access the domain. Ensure that the service account or, if specified, the override account is a member of the Domain Admins group in each managed domain where you want to use Active Roles for viewing BitLocker recovery passwords.

With the domain administrator rights given to the Active Roles Administration Service, Active Roles allows delegated administrators to locate and view BitLocker recovery passwords held in the Active Directory domain. To view BitLocker recovery passwords, the delegated administrator must be granted the appropriate permissions in Active Roles. The following Access Template provides sufficient permissions to view BitLocker recovery passwords:

  • Computer Objects - View BitLocker Recovery Keys

In addition, viewing BitLocker recovery passwords in a given domain requires the following:

The BitLocker recovery information is displayed on the BitLocker Recovery tab in the computer object’s Properties dialog box, in the Active Roles console. It is also possible to perform domain-wide searches for BitLocker recovery passwords.

SQL Server permissions

This section discusses the SQL Server permissions required to:

  • Configure the Active Roles Administration Service (configuration permissions)
  • Run the Active Roles Administration Service (operation permissions)
  • Configure replication in Active Roles (replication configuration permissions)
  • Run Active Roles replication (replication agent permissions)

Configuration permissions

The account that you use when configuring the Administration Service must have sufficient rights on SQL Server to perform the configuration tasks.

Which account is used to access SQL Server during configuration of the Administration Service depends upon the SQL Server connection option you select in the wizard for configuring the Administration Service. If you select the option to use Windows authentication, the wizard accesses SQL Server with the Windows user account under which the wizard is running. If you select the option to use SQL Server authentication, then the wizard accesses SQL Server with the SQL login and password that you specify in the wizard.

NOTE: Windows authentication is not applicable for configuring Active Roles on Azure database server.

The required rights of the account that is used to access SQL Server during configuration vary depending on your configuration scenario:

  • If you want the wizard to create a new database for the Administration Service, then the account must be a member of the dbcreator fixed server role.

  • For Azure SQL database variants, Azure SQL database and Azure SQL on elastic pool dbmanager role should be provided to create databases.

  • However, for variant Azure SQL Managed instance, the dbcreator fixed server role should be provided.

  • If you want the wizard to import data from the Active Roles database of an earlier version, then the account must be a member of the db_datareader fixed database role in the source database.
  • If you want the wizard to configure the Administration Service to use an existing database of the current version, then the account must be a member of the db_owner fixed database role and have the default schema of dbo in that database.
  • If you want the wizard to use an existing blank database for the Administration Service, then the account must be a member of the db_owner fixed database role and have the default schema of dbo in that database.

Operation permissions

The Administration Service accesses its database with the account specified during configuration:

  • If the option to use Windows authentication is selected in the wizard for configuring the Administration Service, then the Administration Service uses its service account to access the database.
  • If the option to use SQL Server authentication is selected, then the Administration Service accesses the database with the SQL login and password supplied in the configuration wizard.

In either case, the account must have sufficient rights on SQL Server to retrieve data from, and make changes to, the database. The required rights vary depending on the role of the Administration Service’s database server in the Active Roles replication environment.

NOTE: Active Roles does not support replication on Azure SQL databases.

Standalone mode

When initially installed, the Administration Service’s database is configured not to participate in Active Roles replication. This configuration is referred to as standalone Administration Service. The account that the standalone Administration Service uses to access the database must at a minimum be a member of the db_owner fixed database role and have the default schema of dbo in that database.

Publisher mode

If the Administration Service’s database server holds the role of the Publisher in Active Roles replication, then the account the Administration Service uses to access the database must at a minimum be a member of the db_owner fixed database role and have the default schema of dbo in that database. Additional rights are required if you want to see the replication status information and error messages in the Active Roles console. These additional rights are as follows:

  • Default schema of dbo in the msdb system database.
  • SELECT permission on the sysjobs, sysjobsteps and MSagent_parameters system tables in the msdb system database.
  • SELECT permission on the sysservers system view in the master system database.
  • EXECUTE permission on the xp_sqlagent_enum_jobs system extended stored procedure in the master system database.
  • SELECT permission on the MSmerge_agents, MSmerge_history, MSmerge_sessions, MSsnapshot_agents and MSsnapshot_history system tables in the distribution database (AelitaDistributionDB database by default).
Subscriber mode

If the Administration Service’s database server holds the role of a Subscriber in Active Roles replication, then the account that the Administration Service uses to access the database requires the same rights as in standalone mode: The account must at a minimum be a member of the db_owner fixed database role and have the default schema of dbo in that database.

Replication configuration permissions

After you install and configure two or more Administration Service instances, each with its own database, you can deploy replication, if necessary, to synchronize the databases so that all your Administration Service instances have the same configuration and management history. Replication deployment begins when you configure the Publisher. Once the Publisher has been configured, the next step is to configure Subscribers. The task of configuring the Publisher or a Subscriber requires more rights on SQL Server than the Administration Service needs for normal operation. To elevate the rights of the Administration Service, Active Roles prompts for an alternative account. The following topics elaborate on the permissions needed to create the Publisher or add a Subscriber.

Permissions for creating or removing the Publisher

To create the Publisher, the Administration Service needs sysadmin rights on SQL Server. If the Administration Service’s account for database access does not belong to the sysadmin role, then Active Roles prompts you to supply an alternative account. The alternative account must:

  • Be a member of the sysadmin fixed server role on the database server you are going to make the Publisher.

Active Roles does not store the login name and password of this account. It only uses the login name and password of this account to configure the Publisher.

The same permissions are required for removing (demoting) the Publisher.

Permissions for adding or removing a Subscriber

To add a Subscriber, the Administration Service’s database server must hold the Publisher role. When adding a Subscriber, the Administration Service makes changes on the Publisher database server and on the database server being configured as a Subscriber (Subscriber database server). Therefore, the Administration Service needs sufficient rights on both database servers.

On the Publisher database server, the Administration Service needs sysadmin rights. If the Administration Service’s account for database access does not belong to the sysadmin role, then Active Roles prompts you to supply an alternative account for connection to the Publisher database server. The alternative account must:

  • Be a member of the sysadmin fixed server role on the Publisher database server.

Active Roles does not store the login name and password of this account. It only uses the login name and password of this account to configure the Subscriber.

On the database server you are going to make a Subscriber, the Administration Service needs db_owner rights in the Active Roles database. If the Administration Service’s account for database access does not have sufficient rights on the Subscriber database server, then Active Roles prompts you to supply an alternative account for connection to the Subscriber database server. The alternative account must:

  • Be a member of the db_owner fixed database role in the Active Roles database on the database server you are going to make a Subscriber.
  • Have the default schema of dbo in that database.

Active Roles does not store the login name and password of this account. It only uses the login name and password of this account to configure the Subscriber.

The same permissions are required for removing a Subscriber.

Replication agent permissions

In Active Roles replication, SQL Server replication agents (Merge Agents) are used to synchronize data between the Publisher and Subscriber databases. Each Subscriber has a dedicated replication agent running on SQL Server that hosts the Publisher database. Since the agent’s role is to maintain the Publisher and Subscriber databases in sync with each other, the agent needs sufficient rights to access both the Publisher and Subscriber database servers.

The Administration Service creates and configures a replication agent when adding a Subscriber. In terms of SQL Server, this is a Merge Agent for a push subscription. According to SQL Server Books Online (see “Replication Agent Security Model” at msdn.microsoft.com/en-us/library/ms151868.aspx), Merge Agent for a push subscription requires the following permissions.

The Windows account under which the agent runs is used when it makes connections to the Publisher and Distributor. This account must:

  • At a minimum be a member of the db_owner fixed database role in the distribution database (AelitaDistributionDB database by default).
  • Be a member of the publication access list (PAL).
  • Be a login that is associated with a user in the publication database (the Active Roles database on the Publisher).
  • Have read permissions on the snapshot share (by default, this is the ReplData folder on the administrative share C$).

The account used to connect to the Subscriber must at minimum be a member of the db_owner fixed database role in the subscription database (the Active Roles database on the Subscriber).

By default, the security settings of a Merge Agent configured by Active Roles are as follows:

  • The account under which the Merge Agent runs and makes connections to the Publisher and Distributor is the Windows service account of the SQL Server Agent service.
  • The account the Merge Agent uses to connect to the Subscriber is the account under which the Merge Agent runs.

This means that, by default, Active Roles requires that the account of the SQL Server Agent service have all permissions the Merge Agent needs to make connections both to the Publisher/Distributor and to the Subscriber.

When adding a Subscriber, you have the option to supply a separate login for connection to the Subscriber. If you choose that option, the Merge Agent will use the login you supply (rather than the account of the SQL Server Agent service) to make connections to the Subscriber. In this case, it is the login you supply that must have db_owner rights in the subscription database. The SQL Server Agent service does not need to have any rights in the subscription database. However, it still must have all permissions the Merge Agent needs to make connections to the Publisher and Distributor.

Steps to deploy the Administration Service

Active Roles requires Microsoft .NET Framework 4.7.2. See https://www.microsoft.com/en-us/download/details.aspx?id=53345 for instructions on how to update .NET Framework.

The Administration Service requires Microsoft SQL Server or Azure SQL database server. SQL Server may be installed on the Administration Service computer or on a different network computer. If you do not have Microsoft SQL Server deployed in your environment, you can Microsoft SQL Server 2012 Express from “Microsoft SQL Server 2012 Service Pack 1 (SP1) Express” at http://go.microsoft.com/fwlink/?LinkID=267905.

Azure SQL Database variants supported in Active Roles are Azure SQL database, Azure SQL Managed Instance, and Azure SQL Elastic Pool.

Now that you have access to SQL Server, you can install the Administration Service.

This section provides a guidance on how to install and configure a new instance of the Administration Service. for instructions on how to upgrade an existing Administration Service instance of an earlier version, see Upgrading the Administration Service later in this document.

To install the Administration Service files

  1. Log on with a user account that has administrator rights on the computer.
  2. Navigate to the location of the Active Roles distribution package, and start the Setup wizard by double-clicking ActiveRoles.exe.
  3. Follow the instructions in the Setup wizard.
  4. On the Component Selection page, ensure that the Administration Service component is selected, and click Next.
  5. On the Ready to Install page, click Install to perform installation.
  6. On the Completion page, confirm that the I want to perform configuration check box is selected, and click Finish.

The Setup wizard only installs the files. After you have completed the Setup wizard, you need to configure the newly installed Administration Service instance by using Active Roles Configuration Center that opens automatically if you select the I want to perform configuration check box on the Completion page in the Setup wizard. Another way to open Configuration Center is by selecting Active Roles 7.5.2 Configuration Center on the Apps page or Start menu, depending upon the version of your Windows operating system.

To configure the Administration Service

  1. In Configuration Center, under Administration Service, click Configure.
  2. Perform the following steps in the Configure Administration Service wizard that appears:
    1. On the Service Account page, enter the name and password of the domain user account or the service account details of the Group Managed Service Account (gMSA), to be used as the Administration Service account.
    2. On the Active Roles Admin page, accept the default account, or click Browse and select the group or user to be designated as Active Roles Admin.
    3. On the Database Options page, select the appropriate option, and then follow the instructions in the wizard.

The database options are related to setting up the database for the Administration Service you are configuring. These options and the corresponding wizard steps are discussed in the sections that follow.

Configuring the initial Administration Service

This section covers the database-related steps of the Configure Administration Service wizard in a scenario where you are configuring the first Administration Service in your environment.

To configure the initial Administration Service

  1. On the Configure Administration Service wizard, on the Database Options page, select the New Active Roles database or the Existing Active Roles database option, and then click Next.

  2. On the Connection to Database page, specify a database type, database server instance, database name, and select the authentication option for the Configuration database:

    1. In the Database Server name box, specify a SQL Server instance in the form <Computer>\<Instance> (for named instance) or <Computer> (for default instance), where <Computer> stands for the short name of the computer running SQL Server. The wizard will create the database on the SQL Server instance you specify.

    2. In the Database box, enter a name for the database that will be created.

    3. Under Connect using, select the appropriate authentication option:

      • To have the Administration Service connect to the database using the service account, click Windows authentication.

        NOTE: Windows authentication is not applicable for configuring Active Roles in Azure database server.

      • To have the Administration Service connect to the database using an SQL Server login, click SQL Server authentication and enter the login name and password.

      • To have the Administration Service connect to the database using an Azure AD login, click Azure Active Directory authentication and provide the login name and password.

    4. (Optional) To configure advanced database settings (connection timeout intervals, failover instances and SQL database auto-shrinking), open the Advanced Database Properties dialog by clicking the Configure advanced database properties link. Configure any of the available advanced settings.

      • In the Connection Timeout text box, enter the timeout interval in seconds. This value specifies the time to wait while trying to establish a connection before terminating the attempt and generating an error. The minimum value is 1 second.

        NOTE:

        • The default connection timeout value corresponds to the SQL OLEDB connection timeout.

        • This setting is not applicable to Azure databases.

      • (Optional) Select the check box Enable faster failover for all Availability Groups and Failover Cluster instances to enable MultiSubnetFailOver, providing faster detection and connection times to active servers. For more information, see SqlClient Support for High Availability, Disaster Recovery in the Microsoft ADO.NET documentation.

      • (Optional) Select the check box Enable SQL auto shrink to allow background tasks to shrink the SQL database.

        NOTE: Consider the following when using this setting:

        • Frequent grow and shrink operations can result in performance and fragmentation issues. Therefore, the Enable SQL auto shrink setting is not selected by default. One Identity recommends selecting this setting only if your database is already pre-configured and pre-grown to the required size, as this can prevent frequent shrink and growth operations on the database file. For more information on the potential performance issues, see Recommendations and guidelines for setting the AUTO_SHRINK database option in SQL Server in the Microsoft SQL Server 2008 Enterprise documentation.

        • The Enable SQL auto shrink option is displayed only if the Administration Service is configured with the new Active Roles database option for Configuration Databases or Management History databases.

        • This option is not available if you select the Existing database or the New Active Roles database > Use pre-created blank database option during configuration.

        • This setting is not applicable to Azure databases.

  3. On the Connection to MH Database page, perform the steps a to d for the Management history database.

  4. Click Next, and then complete the Encryption Key Backup page as described in Steps to deploy the Administration Service, later in this document.

    NOTE: This <name of window> window is displayed only if the Administration Service is configured with the New Active Roles database option for either the configuration or management history database.

  1. Click Next, and follow the instructions in the wizard to complete the configuration.

Backup of encryption key

When you configure the initial Administration Service, Configuration Centers creates a database along with a secret key that the Administration Service will use to encrypt and decrypt sensitive data in the database, such as the credentials of the override accounts for managed domains, Azure administrator user password.

The secret key, also referred to as encryption key, is stored in the database using asymmetric cryptography so that it can only be retrieved and decrypted by the Administration Service that knows the private portion of the asymmetric key pair. Storing the secret key in this way ensures the optimal level of protection for security-sensitive data in the Active Roles database.

As the retrieval of the secret key requires knowing the private key related to the public key that was used to encrypt the secret key, you may encounter a situation where a new Administration Service instance attached to an existing Active Roles database is unable to retrieve the secret key. Typically, this is the case when you:

  • Attach a new Administration Service instance to an Active Roles database that is used by other instances of the Administration Service while there is no running instance that could decrypt the secret key.
  • Import Active Roles configuration data from another database (for example, a databases of an earlier Active Roles version). In this case, you need the secret key that is used for data encryption in the source database; otherwise, the encrypted data cannot be imported.

If the Administration Service cannot retrieve the secret key from the database, you need a backup copy of the secret key. Configuration Center prompts you to create a backup of the secret key whenever you perform initial configuration of the Administration Service with the option to create a new database.

On the Encryption Key Backup page, the Configure Administration Service wizard specifies a file to store a backup copy of the secret key. You can encrypt the backup by protecting the file with a password.

NOTE:

  • The encryption key is only used to encrypt passwords for domain override accounts (including AD LDS instances). Other than passwords, we do not encrypt any other data.
  • By default, the encryption key will be created in the following folder: C:\Pro gramData\One Identity\Active Roles with a default name of:ARServiceEncryptionKey-dj-ars<version>.bin.
  • If you lose your encryption key, you can still use Active Roles using one of the following:
    • Since the encryption key is used for the Managed Domain password encryption, you can simply install Active Roles and use a new database and import the settings from the old database. You will be prompted to create a new encryption key file.
    • Another method is to bring up an additional Active Roles service. It can retrieve the encryption key from an already running Active Roles service machine (you will be presented with the option to do so during installation).
    • In case you do not have the encryption file for your original Active Roles service, you can still upgrade to 6.9 from 6.x. You must create a new key if required.
    • If you have multiple Active Roles services sharing one database, you really do not need the encryption key as Active Roles can pull the encryption information from the existing running system.
    • Encryption key file is not used during upgrade.

  • You need Active Roles encryption key in the following cases:

    • To add another Active Roles service to existing shared database
    • There are no services connected to the same database up and running
    • You cannot afford re-typing passwords for managed domains

Additional Information

Active Roles encrypts some data, stored in the Active Roles database. Encryption is performed using a symmetric cypher. To use the encrypted data you need the encryption key as the file is password protected. Active Roles stores the encryption key inside the Active Roles database using asymmetric cypher. Thus Active Roles can get the value of this key from the database. Active Roles also has logic that allows the service to share this key with other services (like several services per single database). In case the key is lost, you need to re-type passwords for the managed domains. The only situation when you would need this file, would be when you want to use existing Active Roles database but cannot afford retyping passwords for Managed Domains.

To complete the Encryption Key Backup page

  1. If you want to change the name or location of the backup file, click the Browse button and specify the desired file name and location. The wizard will save a copy of the secret key to the file specified.
  2. If you want to encrypt the backup, select the Protect the backup file with a password check box, and then type and confirm a password. You will have to enter the specified password to retrieve the key from the backup file. If you lose or forget the password, it cannot be recovered.

Configuring an additional Administration Service

This section covers the database-related steps of the Configure Administration Service wizard in a scenario where:

  • At least one instance of the Administration Service version Active Roles is up and running in your environment.
  • You are installing one more Administration Service instance for load distribution and fault tolerance.

To configure an additional Administration Service

  1. On the Database Options page in the Configure Administration Service wizard, select one of the following options, depending upon how you want to synchronize the configuration of the new Administration Service instance with the configuration of the existing Administration Service instances:
    • Existing Active Roles database  Configures the new Administration Service instance to use the database of an existing Administration Service instance so that the new Administration Service instance has the same configuration as the existing instance.
    • New Active Roles database  After configuring the new Administration Service instance, you will need to set up Active Roles replication for the new Administration Service instance to have the same configuration as the existing instances.
  2. If you have selected the Existing Active Roles database option, follow the instructions provided later in this section (see Steps to deploy the Administration Service).
  3. If you have selected the New Active Roles database option, use the instruction provided in the previous section (see Steps to deploy the Administration Service) to complete the wizard.

The database created by this option holds the pristine configuration of the Administration Service. To update and synchronize the new database with the configuration data of the Administration Service instances that were earlier deployed in your environment, you need to use the replication function. For instructions on how to set up replication of configuration data, see the Active Roles Administration Guide.

Using common database

If you select the Existing Active Roles database option on the Database Options page, the Configure Administration Service wizard causes the new Administration Service instance to connect to the database of an existing Administration Service instance. The new instance automatically becomes a replica of the existing one.

This option allows you to centralize the Active Roles configuration storage. You can deploy multiple Administration Service instances of the same configuration without having to synchronize them via replication. Rather, you have the option for multiple Administration Service instances to share configuration data held in a single database on centrally deployed SQL Server.

This option also ensures that the newly deployed Administration Service instance can immediately be used as a replacement for the existing one. Switching between Administration Service instances is transparent to Active Roles users as both instances of the Administration Service have the same configuration.

To configure the Administration Service to share a database

  1. On the Database Options page in the Configure Administration Service wizard, select the Existing Active Roles database option, and then click Next.
  2. On the Connection to Database page, specify Database type, Database Server name, and Database fields. Specify the SQL Server instance and the name of the database being used by an existing instance of the Administration Service version Active Roles.

Specify the SQL Server instance in the form <Computer>\<Instance> (for named instance) or <Computer> (for default instance), where <Computer> stands for the short name of the computer running SQL Server.

  1. On the Connection to Database page, under Connect using, select the appropriate authentication option:
    • To have the Administration Service connect to the database using the service account, click Windows authentication.
    • To have the Administration Service connect to the database using an SQL Server login, click SQL Server authentication and enter the login name and password.
  2. On the Connection to MH Database page, specify the database type, database server name, and the name of the database, and select the desired authentication option for the Administration Service connection to the management history database.
  3. If you want to configure advanced database properties, click on the link displayed, and select one or both of the following options, based on the requirement, and then click Apply.:
    • On the Advanced Database Properties dialog box, in the Connection Timeout text box, enter the time in seconds. This value indicates the amount of time trying to establish a connection before terminating the attempt and generating an error.

    NOTE:

    • Default connection time out is as per the SQL OLEDB connection timeout.

    • A value of 0 indicates no limit as attempt to connect will wait indefinitely and hence input value is permitted starting from 1 second.

    • If any value populated in the field cannot be made null or empty once settings are saved and another valid value must be entered.

      If you enter a value less outside the specified range, an error is displayed.

    • Select the check box Enable faster failover for all Availability Groups and Failover Cluster instances to enable MultiSubnetFailOver.

    • The settings available on Advanced Database properties are not applicable for Azure databases.

  4. Click Next, and follow the instructions in the wizard to complete the configuration.

Advanced scenarios

This section covers the database-related steps of the Configure Administration Service wizard in the following scenarios:

  • Using the database of an earlier Administration Service installation
  • Using a pre-created, blank database
Using the database of an earlier Administration Service installation

When you deploy the Administration Service, you may need to configure it to use the database of an earlier installation of the Administration Service instead of creating a new database. You may need to do so in the following scenarios:

  • Restoring the Active Roles database from a backup, and then configuring the Administration Service to use the restored database.
  • Repairing the Active Roles installation by using Programs and Features in Control Panel.
  • Installing a maintenance release of Active Roles to update the existing Administration Service instance.

NOTE: All these scenarios assume that the database has the same version as the Administration Service you are configuring. If the Administration Service version is greater than the database version, you should choose the option to create a new database and import data from the existing database (see Steps to deploy the Administration Service later in this document).

Provided that the database is of the same Active Roles version as the Administration Service you are configuring, you can use the following steps to make the Administration Service use that database.

To use the database of an earlier Administration Service installation

  1. On the Database Options page in the Configure Administration Service wizard, select the Existing Active Roles database option, and then click Next.
  2. On the Connection to Database page, specify the Database type, Database Server name, and the name of the database. Select the desired authentication option for the Administration Service connection to the configuration database.
  3. On the Connection to MH Database page, specify the Database type, Database Server name, and the name of the database. Select the desired authentication option for the Administration Service connection to the management history database.
  4. If you want to configure advanced database properties, click on the link displayed, and select one or both of the following options, based on the requirement, and then click Apply.:
    • On the Advanced Database Properties dialog box, in the Connection Timeout text box, enter the time in seconds for the database connection to get timed out.

      If you enter a value less outside the specified range, an error is displayed.

    • Select the check box Enable faster failover for all Availability Groups and Failover Cluster instances to eable MultiSubnetFailOver.

    NOTE:

    • Default connection time out is as per the SQL OLEDB connection timeout.

    • A value of 0 indicates no limit as attempt to connect will wait indefinitely and hence input value is permitted starting from 1 second.

    • If any value populated in the field cannot be made null or empty once settings are saved and another valid value must be entered.

  5. Click Next, and follow the instructions in the wizard to complete the configuration.
Using a pre-created blank database

When you choose the option to create a new Active Roles database, the Configure Administration Service wizard uses default values for database properties, such as the location and other parameters of the database files and transaction log files. If you need specific database properties, then you can use SQL Server tools to create a blank database with the properties that meet your requirements, and have the wizard create the new Active Roles database by adding the Active Roles tables and data to that blank database. The following steps assume that you have a blank database already created.

To use a pre-created blank database

  1. On the Database Options page in the Configure Administration Service wizard, select the New Active Roles database option, select the Use a pre-created blank database check box, and then click Next.
  2. On the Connection to Database page, specify the Database type, Database Server name and the name of the database. Select the desired authentication option for the Administration Service connection to the configuration database.
  3. If you want to configure advanced database properties, click on the link displayed, and select one or both of the following options, based on the requirement, and then click Apply.:
    • On the Advanced Database Properties dialog box, in the Connection Timeout text box, enter the time in seconds. This value indicates the time to wait while trying to establish a connection before terminating the attempt and generating an error.

    NOTE:

    • Default connection time out is as per the SQL OLEDB connection timeout.

    • A value of 0 indicates no limit as attempt to connect will wait indefinitely and hence input value is permitted starting from 1 second.

    • If any value populated in the field cannot be made null or empty once settings are saved and another valid value must be entered.

If you enter a value less outside the specified range, an error is displayed.

  1. Select the check box Enable faster failover for all Availability Groups and Failover Cluster instances to enable MultiSubnetFailOver.

  2. On the MHDatabase Options page, select the New Active Roles database option, select the Use a pre-created blank database check box, and then click Next.

  3. On the Connection to MH Database page, specify the Database type, Database Server name and the name of the database. Select the desired authentication option for the Administration Service connection to the management history database.
  4. Click Next, and follow the instructions in the wizard to complete the configuration.

Importing configuration data

When deploying the Administration Service, you may need to import configuration data from an existing database in order to ensure that the new Administration Service instance has the same configuration as the existing one. Importing configuration data to a newly created database instead of attaching the Administration Service to an existing database is necessary if the version of the Administration Service you are deploying is greater than the version of the database you want to use. Some examples of such a situation are as follows:

  • Upgrading the Administration Service while preserving its configuration.
  • Restoring configuration data from a backup copy of the database whose version does not match the version of the Administration Service.

During import configuration, the import configuration page notifies you to select a tenant from the list of tenants configured in the source database, from the Azure Tenant association section and the selected tenant is associated with all Azure objects in the destination database. You can also choose to Run Azure Tenant association immediately or Schedule Azure Tenant Association, where you select the date and time from the Calendar to run the tenant association.

NOTE: If Azure Tenant association is scheduled at a certain time and the upgrade/import operation is still in progress or completes after the Azure Tenant association scheduled time, the tenants are not associated. You have to run the built-in scheduled task Update Azure Objects Associated Tenant Id from the Active Roles console to manually associate the Azure Tenants.

For in-place upgrade , in upgrade configuration page notifies you to select a tenant from the list of tenant configured in the Source database, from the Azure Tenant association section and the selected tenant is associated with all Azure objects in the destination database. You can also choose to Run Azure Tenant association immediately or Schedule Azure Tenant Association, where you select the date and time from the Calendar to run the tenant association.

NOTE:

  • Alternatively, Azure Tenant association can be run at any time using the template workflow Update Azure Objects Associated Tenant Id available in the Built-in Workflow Container. The parameter in the script used by the workflow can be configured with the required tenant ID. You can use the drop-down to select a default Azure Tenant from the list of available Azure Tenants. The script used by the workflow can be modified to Search Azure objects based on the requirement.

  • Depending on the infrastructure, the import operation may take several minutes to complete.
  • The Services association page allows you to configure the Administration services for executing Dynamic Groups, Group Families, and Scheduled tasks from the drop-down list.

    The available options in the drop-down list are This Server and Other, where choosing Other allows to specify any other Administration Service in fully qualified domain name (FQDN) format. If the value is empty, then the current administration service is used.

    NOTE: Services association does not update certain scheduled tasks, For example, scheduled tasks that cannot be edited (Managed Object Counter) or scheduled tasks that are set to All servers option.

    You can choose to run the Services association immediately or schedule service association.

    NOTE: Alternatively, Services association can be performed any time using the template workflow Update Services To Execute On available in the built-in Workflow Container. The parameters in the script used by the workflow can be configured to the required administration services, such as, Dynamic Group Service, Group Family Service, Scheduled Task Service. You can select the administration service from the drop-down list. The drop-down list displays all the currently running administration services that are connected to the current configuration database. If the parameter value is not selected, then the current administration service is used.

    To ensure Dynamic Groups, Group Families, and Scheduled tasks continue to function after an import the installation configures the new Active Roles server as the executing server for the tasks mentioned above. The configuration mentioned here runs after an upgrade.

    The following instructions on how to import configuration data are applicable to any situation where you choose to create a new database when configuring the Administration Service. In this case, after you have initially configured the Administration Service instance, Active Roles Configuration Center enables you to import the configuration data to the newly created database.

    To import configuration data

    1. In the Configuration Center main window, under Administration Service, click Manage Settings.

      You can start Configuration Center by selecting Active Roles 7.5.2 Configuration Center on the Apps page or Start menu, depending upon the version of your Windows operating system.

    1. On the Settings page, in the Active Roles database area, click Import configuration.
    2. On the Source database page in the Import configuration wizard that appears, specify the database from which you want to import the configuration data (source database):

      1. Select the required Database Type. In the Database Server name box, specify the SQL Server instance that hosts the source database.

      2. In the Database box, specify the name of the source database.
    3. Under Connect using, select the appropriate authentication option:

      • If your Windows logon account has sufficient rights to write data to the destination database, click Windows authentication.

      • If you have a SQL Server login with sufficient rights, click SQL Server authentication and enter the login name and password.

      • If you have an Azure AD login with sufficient rights, click Azure Active Directory authentication and enter the login name and password.

    4. Click Next to proceed to the Destination database page.

      The Destination database page identifies the database of the Administration Service to which you are going to import data (destination database), and allows you to select the authentication option.

    1. On the Destination database page, under Connect using, select the appropriate authentication option:

      • If your Windows logon account has sufficient rights to write data to the destination database, click Windows authentication.

      • If you have a SQL Server login with sufficient rights, click SQL Server authentication and enter the login name and password.

      • If you have an Azure AD login with sufficient rights, click Azure Active Directory authentication and enter the login name and password.

    2. Click Next.
    3. On the Add-on advisor page, the add-ons for the earlier version of Active Roles are displayed.

      NOTE: The Add-ons must be uninstalled manually from the earlier version using the Active Roles Add-on Manager and from the system where ever applicable, before continuing configuration import.

    4. Click Next, and then, on the Import of Encrypted Data page, choose from the following options:
      • If you have a backup of the secret key for the source database (see Steps to deploy the Administration Service), click Use a backup of encryption key to import encrypted data and then click Browse to specify the backup file. If the backup file is password-protected, type the password in the Password box.
      • If you don’t have a backup of the secret key for the source database, click Do not import encrypted data. In this case, the encrypted data from the source database, such as the override account’s password for managed domain registrations, will not be available in the destination database, so you will need to re-enter the override account’s password in the managed domain registrations with the Administration Service that uses the destination database.

    5. The Azure Tenant association page displays the lists of configured Azure tenants in the source database and options for association.

      NOTE: This page is visible only if the tenants are present in the source database.

    6. The Services association page allows you to configure the Administration services for executing Dynamic Groups, Group Families, and Scheduled tasks from the drop-down list.

    7. View the Summary page to review database configuration, Azure Tenant association and Service association details.

    8. Click Next, and follow the instructions in the wizard to complete the import operation.

    Importing management history data

    A part of the Active Roles database, the management history data storage is empty after you have configured the Administration Service with the option to create a new database. During import of configuration data (see Steps to deploy the Administration Service), 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 in order to reduce the time it takes to upgrade the configuration of the Administration Service.

    The management history data describes the changes that were made to directory data via Active Roles. This includes information about who did what and when it was done as applied to the directory data management tasks. The management history data is used as a source of information for the change history and user activity reports. In addition, the management history data storage holds information about various tasks related to approval workflow and temporal group membership.

    After you have configured the Administration Service with the option to create a new database, and imported the configuration data from an existing database, you need to take additional steps to transfer the management history data from that database to the new database. Configuration Center provides the Import Management History wizard to perform this task.

    The wizard is intended to populate a new storage of management history data with the data found in an existing Active Roles database, to make the data available to the Active Roles user interfaces after your configure a new Administration Service instance. The wizard merges the management history data from the source database with the data stored in the destination database. Note that the wizard only adds new data, keeping intact any data that already exists in the destination database. You may import your legacy management history data at any time after you have configured the Administration Service, without being afraid of losing any data.

    To import Management History data

    1. In the Configuration Center main window, under Administration Service, click Manage Settings.

      Start the Configuration Center by selecting Active Roles7.5.2 Configuration Center on the Apps page or Start menu, depending on the version of your Windows operating system.

    2. On the Administration Service page, click Import Management History to open the Import Management History wizard.

    3. On the Source database page, specify the database from which you want to import the management history data (source database):

      1. Database Type: Select the required database type from the drop-down (on premises or Azure SQL).

      2. Database Server name: Enter the name of the SQL Server instance that hosts the source database.

      3. Database: Enter the name of the source database.

    4. Under Connect using, select the authentication option:

      • If your Windows logon account has sufficient rights to write data to the destination database, click Windows authentication.

      • If you have a SQL Server login with sufficient rights, click SQL Server authentication and enter the login name and password.

      • If you have an Azure AD login with sufficient rights, click Azure Active Directory authentication and enter the login name and password.

      NOTE: Azure databases can be connected using SQL Server authentication and Azure AD authentication. Windows authentication is applicable only for on-premises databases.

      NOTE: Azure AD authentication currently does not support Multi-Factor Authentication (MFA).

    5. Click Next.

      The Destination database page identifies the database of the Administration Service to which you are going to import data (destination database), and allows you to select the authentication option.

    6. Under Connect using, select the authentication option:

      • If your Windows logon account has sufficient rights to write data to the destination database, click Windows authentication.

      • If you have a SQL Server login with sufficient rights, click SQL Server authentication and enter the login name and password.

      • If you have an Azure AD login with sufficient rights, click Azure Active Directory authentication and enter the login name and password.

      NOTE: Azure databases can be connected using SQL Server authentication and Azure AD authentication. Windows authentication is applicable only for on-premises databases.

      NOTE: Azure AD authentication currently does not support Multi-Factor Authentication (MFA).

    7. Click Next.

    8. On the Records to Import page, specify whether you want to import all data records or only a certain range of the data records.

      NOTE: The data for unfinished temporal group membership is imported when the management history data is imported for a selected date range.

      You can choose not to import all the data records as importing a large volume of data can take hours. Later, you can import additional data by choosing a different range of data records. During subsequent import sessions, the wizard only imports the data records that were not imported earlier.

    9. Click Next and follow the instructions in the wizard to complete the import operation.

    • Deploying user interfaces

    Active Roles provides user interfaces for the Windows system and the Web, allowing users with appropriate rights to perform administrative activities. The user interfaces include:

    • Web Interface  A customizable Web application for directory administration.
    • MMC Interface  A desktop console for Active Roles configuration and directory administration.

    By default, the Active Roles Setup wizard installs all core Active Roles components, including the console (MMC Interface) and Web Interface. You can choose to install individual components, if needed.

    Related Documents

    The document was helpful.

    Select Rating

    I easily found the information I needed.

    Select Rating