The following checklist guides you through the entire upgrade process. Use this process to upgrade each server set in your environment. If you have not done it yet, use the Health Check Utility to create a backup of your current AD LDS instance.
WARNING:Do not upgrade your secondary Administration servers until you have upgraded the primary Administration server for that MMS.
You can spread the upgrade process over several phases, upgrading one MMS at a time. This upgrade process also allows you to temporarily include secondary servers running a previous DRA version and secondary servers running the current DRA version in the same MMS. DRA supports synchronization between Administration servers running a previous DRA version and servers running the current DRA version. However, be aware that DRA does not support running a previous DRA version with the current DRA version on the same Administration server or client computer.
IMPORTANT:For the successful replication of temporary group assignments in the secondary server, run the Multi-master synchronization schedule manually or wait for its scheduled run.
|
Steps |
Details |
|---|---|
|
Run Health Check utility |
Install the standalone DRA Health Check utility and run it using a service account. Fix any issues. |
|
Perform a test upgrade |
Perform a test upgrade in your lab environment to identify potential issues and minimize production downtime. |
|
Determine the order of upgrade |
Determine the order in which you want to upgrade your server sets. |
|
Prepare each MMS for upgrade |
Prepare each MMS for an upgrade. For more information, see Pre-Upgrade Tasks. |
|
Upgrade primary server |
Upgrade the primary Administration server in the appropriate MMS. For information, see Upgrading the Primary Administration Server. |
|
Install new secondary server |
(Optional) To minimize downtime at remote sites, install a local secondary Administration server running the newest version of DRA. For information, see Installing a Local Secondary Administration Server for the Current DRA Version. |
|
Deploy user interfaces |
Deploy the user interfaces to your assistant administrators. For information, see Deploying the DRA User Interfaces |
|
Upgrade secondary servers |
Upgrade the secondary Administration servers in the MMS. For information, see Upgrading Secondary Administration Servers. |
|
Upgrade DRA Reporting |
Upgrade DRA Reporting. For information, see Upgrading Reporting. |
|
Run Health Check utility |
Run the Health Check Utility that was installed as part of the upgrade. Fix any issues. |
|
Update Web Console configuration (post- upgrade) |
(Conditional, post-upgrade) If you have either of the Web Console configurations below before an upgrade, they will need to be updated after the upgrade installation completes:
For more information, see Updating the Web Console Configuration - Post Installation. |
Before you upgrade, notify your assistant administrators when you plan to start this process. If you dedicated a secondary Administration server to run a previous DRA version, also identify this server so assistant administrators can continue using the previous DRA version during the upgrade.
After you successfully prepare your MMS, upgrade the primary Administration server. Do not upgrade user interfaces on the client computers until you complete upgrading the primary Administration server. For more information, see Deploying the DRA User Interfaces.
For more upgrade considerations and instructions, see the Directory and Resource Administrator Release Notes.
NOTE:Once you upgrade the primary Administration server, you cannot synchronize delegation, configuration, or policy settings from this server to secondary Administration servers running a previous DRA version.
Installing a new secondary Administration server to run the current DRA version at a local site can help you minimize costly connections to remote sites while decreasing overall downtime and allowing quicker deployment of the user interfaces. This step is optional and allows assistant administrators to use both the current DRA version and a previous DRA version throughout the upgrade process, until you are satisfied that your deployment is complete.
Consider this option if you have one or more of the following upgrade requirements:
You require little or no downtime.
You must support a large number of assistant administrators, and you are not able to upgrade all client computers immediately.
You want to continue supporting access to a previous DRA version after you upgrade the primary Administration server.
Your environment includes an MMS that spans across multiple sites.
For example, if your MMS consists of a primary Administration server at your London site and a secondary Administration server at your Tokyo site, consider installing a secondary server at the Tokyo site and adding it to the corresponding MMS. This additional server better balances the daily administration load at the Tokyo site, and allows assistant administrators from either site to use a previous DRA version as well as the current DRA version until the upgrade is complete. Additionally, your assistant administrators experience no downtime because you can immediately deploy the current DRA user interfaces. For more information about upgrading user interfaces, see Deploying the DRA User Interfaces.
Typically, you should deploy the current DRA user interfaces after you upgrade the primary Administration server and one secondary Administration server. However, for assistant administrators who must use the primary Administration server, ensure you upgrade their client computers first by installing the Delegation and Configuration console. For more information, see Planning a DRA Upgrade.
If you often perform batch processing through the CLI, the ADSI provider, PowerShell, or frequently generate reports, consider installing these user interfaces on a dedicated secondary Administration server to maintain an appropriate load balance across the MMS.
You can let your assistant administrators install the DRA user interfaces or deploy these interfaces through group policy. You can also easily and quickly deploy the Web Console to multiple assistant administrators.
NOTE:You cannot run multiple versions of DRA components side-by-side on the same DRA server. If you plan to gradually upgrade your assistant administrator client computers, consider deploying the Web Console to ensure immediate access to an Administration server running the current DRA version.
When upgrading secondary Administration servers, you can upgrade each server as needed, depending on your administration requirements. Also, consider how you plan to upgrade and deploy the DRA user interfaces. For more information, see Deploying the DRA User Interfaces.
For example, a typical upgrade path may include the following steps:
Upgrade one secondary Administration server.
Instruct the assistant administrators who use this server to install the appropriate user interfaces, such as the Web Console.
Repeat steps 1 and 2 above until you completely upgrade the MMS.
Before you upgrade, notify your assistant administrators when you plan to start this process. If you dedicated a secondary Administration server to run a previous DRA version, also identify this server so assistant administrators can continue using the previous DRA version during the upgrade. When you complete the upgrade process for this MMS, and all assistant administrator client computers are running upgraded user interfaces, take any remaining previous DRA version servers offline.
Perform either or both of the actions below, post-upgrade installation, if they apply to your DRA environment:
The DRA REST Service component is consolidated with the DRA Server beginning in DRA 10.1. If you have the default DRA Server connection configured before you upgrade from a DRA 10.0.x or earlier version, you need to review those settings post-upgrade as there is now only one connection configuration, the DRA Server Connection. You can access this configuration in the Web Console at Administration > Configuration > DRA Server Connection.
You can also update these settings post-upgrade in the web.config file at C:\inetpub\wwwroot\DRAClient\rest on the DRA Web Console server, as follows:
<restService useDefault="Never"> <serviceLocation address="<REST server name>" port="8755"/> </restService>
When upgrading from DRA 10.0.x or earlier versions, if the DRA REST Service is installed without the DRA Server, uninstalling the DRA REST Service is a prerequisite for an upgrade. A copy of files that were modified before the upgrade is made to C:\ProgramData\NetIQ\DRA\Backup\ on the server. You can use these files for reference to update any relevant ones after the upgrade.