2.1 Planning Your Environment

This section guides you through the process of planning your DRA and ExA installation in your environment.

2.1.1 Supported Environments

DRA supports several different types of environments, including the following installations:

  • Managed and trusted domains

  • Microsoft Exchange support

  • Departmental support through managed subtrees

  • Multiple Administration servers

Managed and Trusted Domains

DRA lets you securely administer account and resource objects and Microsoft Exchange mailboxes from multiple managed domains. You can manage Microsoft Windows domains as well as multiple subtrees from specific Microsoft Windows domains. You can also perform the following administration tasks on objects in trusted domains:

  • View objects in trusted domains

  • Add accounts from trusted domains to groups in your managed domains

For more information about configuring managed and trusted domains, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

Microsoft Exchange Support

DRA lets you manage Microsoft Exchange Server mailboxes as you manage the associated user accounts, contacts, and groups. You can implement many integrated Microsoft Exchange management features across your enterprise, including the following functions:

  • Automatically create, move, and delete mailbox stores when managing accounts

  • Automatically generate email addresses based on account naming conventions

  • Delegate administration of specific mailbox properties, such as mailbox security settings

DRA supports and extends your security model. By integrating Microsoft Exchange management into your DRA workflow, you save time and money with streamlined administrative processes. For more information about securely managing Microsoft Exchange mailboxes and implementing Microsoft Exchange policy, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

Departmental Support through Managed Subtrees

Departmental support lets you manage multiple subtrees of specific Microsoft Windows domains. By managing a subtree, you can use DRA to secure a department or division within a larger corporate domain. Departmental support also limits your licensing requirements to only those objects you manage in the subtree.

For more information about implementing departmental support, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

Multiple Administration Servers

You can install multiple Administration servers across your managed domain. Called a Multi-Master Set (MMS), these servers help distribute administration loads and provide fault tolerance within a site. Each MMS consists of one primary Administration server and multiple secondary Administration servers.

For more information about Administration servers, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator. For more information about implementing an MMS, see Enterprise Environment Considerations.

2.1.2 Identifying Installation Scenarios

A basic environment consists of the following:

Up to four DRA servers;

A common service account used across all DRA servers;

No firewall between DRA servers;

Up to four trusted domains;

No non-trusted domains;

No multiple managed domains;

No access to the Deleted Objects Container in Active Directory.

An enterprise environment can consist of any or all of the following:

Any number of DRA servers;

A firewall between DRA servers might or might not be present;

One common service account used across all DRA servers or multiple common service accounts;

Any number of trusted domains;

Any number of non-trusted domains;

Multiple managed domains;

At least 25,000 objects;

Limited access to the Deleted Objects Container in Active Directory.

2.1.3 Basic Environment Considerations

Installing the Administration Server

Always install the Administration server on a Microsoft Windows server. You can also install more than one Administration server. The requirements for primary and secondary Administration servers are the same. If you install a single Administration server, that server must be a primary Administration server.

By default, the setup program installs the NetIQ Administration server component and Web component on the Administration server computer. You can install the Web component on any Web server in a managed or trusted domain. When you install the Web component, you also enable Web Console functionality by installing the Web Console virtual directory.

Installing the User Interfaces

You can install or upgrade the following user interfaces on any Administration server or client computer:

Product

Filename

Supported User Interfaces

DRA

NetIQAdminInstallationKit.msi

Account and Resource Management Console

Delegation and Configuration Console

NetIQ Reporting Center features (console, server, and database)

Command-line Interface (CLI)

ADSI Provider

REST Services

RESTServicesInstaller.exe

DRA Host Service

DRA REST Service

PowerShell extensions

Web Console

IMPORTANT:The PowerShell extensions require PowerShell 2.0.

Through the flexible user interfaces install option, you can install the user interfaces separately. This option lets you tailor your deployment to your specific administration needs.

NOTE:

  • You can use group policy to easily install or upgrade user interfaces on multiple client computers across your enterprise. For more information, see Deploying User Interfaces through Group Policy.

  • Directory and Resource Reporting has been replaced with DRA Reporting, which uses the NetIQ Reporting Center product to display DRA Management Reports. For more information about installing Reporting Center, see Installing Reporting Center.

Deploying User Interfaces through the Setup Program

You can deploy the user interfaces for DRA and ExA through the setup program. Use the setup program to install or upgrade the user interfaces on one or more client computers.

Deploying User Interfaces through Group Policy

You can deploy the user interfaces for DRA and ExA by distributing the appropriate files through group policy. This flexibility lets you easily install or upgrade user interfaces on multiple client computers across your enterprise. Group policy ensures the appropriate personnel can install these user interfaces.

You can run DRAInstaller.msi from the Intel folder of the installation kit. The DRAInstaller.msi file installs most DRA and ExA components, including the Administration server, user interfaces, documentation, and utilities. It does not install the optional DRA Reporting components. However, you can configure a group policy object to install specific user interfaces by specifying one of the following .mst or .msi files:

NetIQDRAUserConsole.mst

Installs the Account and Resource Management console

DRAReporting.msi

Installs the Reporting Center interface for DRA Reporting

NetIQDRACLI.mst

Installs the command-line interface

NetIQDRAADSI.mst

Installs the DRA ADSI provider

NetIQDRAClients.mst

Installs all DRA user interfaces

NRCSetup.exe

Installs Reporting Center components on 32-bit or 64-bit operating systems

NOTE:

  • For more information about giving user accounts special permissions or enabling group policy settings, see the Microsoft Knowledge Base Article Q259377.

  • For more information about group policy, see the Microsoft Windows Help. To easily and securely test and deploy group policy across your enterprise, use NetIQ Group Policy Administrator.

To deploy user interfaces through group policy:

  1. To upgrade the user interfaces, start Active Directory Users and Computers and edit the existing group policy object.

  2. To install the user interfaces, start Active Directory Users and Computers and create a new group policy object.

  3. Add the DRAInstaller.msi package to this group policy object.

  4. Ensure this group policy object has one of the following properties:

    • Each user account in the group has at least Power User permissions for the appropriate computer.

    • The Always Install with Elevated Privileges policy setting is enabled.

  5. Add the user interface .mst file, such as NetIQDRAUserConsole.mst, to this group policy object.

  6. Distribute your group policy.

Deploying the Web Console

You can run the Web Console from any computer with a supported web browser by opening the link provided in the Account and Resource Management console, or by selecting the WebConsole shortcut from the Start menu. You do not need to install additional software. The setup program automatically backs up the previous version of Web Console files to the DRAWebConsole\VersionUpgradeBackups folder under Program Files.

Installing Reporting Center

The following sections list considerations to help you plan your installation.

The Order of Your Installation

You can install the Reporting Center components individually or in any combination. If you install the components on separate computers, install the components in the following order:

  1. Configuration Database

  2. Web Service

  3. Reporting Services Data Extension

  4. Console

Configuration Database Considerations

Before you install the Configuration Database, consider the following information:

  • After installing Reporting Center, if you run the setup program to modify your installation, there is no option to install the Configuration Database. This is a safeguard that prevents you from having multiple Configuration Databases installed in a single Reporting Center environment.

  • After installing Reporting Center, set up regular SQL server backups for the Configuration Database.

  • When you uninstall Reporting Center, the setup program removes all components except the Configuration Database.

Web Service Considerations

If you install the Web Service on a non-default Web site, do not customize the corresponding Host Header value. For information about removing the Host Header, see the Troubleshooting chapter in the Reporting Center Reporting Guide.

Reporting Services Data Extension Considerations

Before you install the Reporting Services Data Extension, consider the following information:

  • You usually install the Reporting Services Data Extension on the computer hosting SSRS, your report server. However, if you are planning on using the Report Designer component of SSRS to customize reports, install the Reporting Services Data Extension on the computer hosting Report Designer.

  • If you configured SSRS with SSL, during installation you can specify the URL for the SSL-configured report server. You can also change the default SSRS URL after installation in the Console. Go to Tools > Options > Enterprise Options > Reporting Services > Default Report Server Location, and enter the URL for the SSL-configured report server.

Console Considerations

Because the Web Service is the communication layer between the Console and the database, install the Web Service before installing the Console.

Installing Reporting Center on Windows Server 2008

Install IIS on Windows Server 2008 (IIS 7.0) or Windows Server 2008 R2 (IIS 7.5) with the following Role Services selected:

  • Application Development: ASP.NET

  • Security: Windows Authentication

Installing Reporting Center with DRA Management Reports

You can install the Reporting Center components along with the DRA Management reports on a primary or secondary Administration server.

The following table lists the prerequisites you need to install each component of Reporting Center.

Component

Installation Prerequisites

Configuration Database

  • Credentials for the Database Installer Account.

  • The name of the SQL Server instance where you will install the Configuration Database, in this format: ServerName\Instance

Web Service

  • Credentials for the Web Service Installer Account.

  • The location of the Configuration Database, in this format: ServerName\Instance

  • Credentials for the Web Service User Account.

Console

  • The location of the Configuration Database, in this format: ServerName\Instance

  • The name of the Web Service server, in this format: http://ServerName/NRCWebService

Reporting Services Data Extension

  • The location of SQL Server Reporting Services (SSRS), in this format: ServerName\Instance

To install Reporting Center with DRA Management Reports:

  1. Log on the Microsoft Windows server where you have installed the SQL instance for the reporting databases with an administrator account. Ensure this account has local administrative privileges as well as System Administrator privileges on the SQL Server.

  2. Run DRAReporting.msi in the Intel folder of the installation kit.

    NOTE:To install the Administration server through a Windows Terminal Services session, run the setup program through the Add/Remove Programs application in Control Panel.

  3. Follow the instructions until the installation completes, and click Finish.

    When you click Finish, the setup utility launches the NRC Setup.

  4. Follow the instructions until the installation completes, and click Finish.

You can also install the Reporting Center console on other computers. For more information about installing Reporting Center, see the NetIQ Reporting Center Reporting Guide.

After installing Reporting Center and the DRA Management Reports, you must enable and configure reporting in DRA. For more information, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

Go to Installation Checklist.

2.1.4 Enterprise Environment Considerations

The information provided in the Basic Environment Considerations section applies to planning your enterprise environment as well.

Installing Multiple Administration Servers

A Multi-Master Set (MMS) contains a primary Administration server and one or more secondary Administration servers. You can install different server sets at different network sites, depending on your administration needs. For more information about basic Administration server requirements, see Administration Server Requirements. For more information about the benefits of an MMS and how an MMS works, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

NetIQ strongly recommends that you install the primary Administration server on a different computer than the domain controller. To better balance network loads, install your Administration servers on server computers. Also ensure each Administration server is located in the same network site as the domain controller of the managed domain. By default, the Administration server accesses the closest domain controller for all read and write operations. When performing time-sensitive or site‑specific tasks, such as password resets, you can specify a target domain controller. You can also configure the Administration server to send all write operations to a single domain controller. For more information, see Configuring the Administration Server to Write All Changes to a Specific Domain Controller.

When managing a larger enterprise, consider dedicating a secondary Administration server for your reporting, CLI or batch processing, or DRA ADSI scripting needs. In this configuration, Assistant Admins can easily connect to other secondary Administration servers to perform their daily tasks.

NOTE:

  • If you install the Administration server on a computer that is not connected to the network, you must run DCPROMO.exe and make the computer a domain controller. You must also install the Microsoft Loopback Adapter. The Network Path Not Found Error 53 message can indicate the Loopback Adapter is not correctly installed.

  • If you plan to install multiple Administration servers, start the Remote Registry Service on each Administration server computer.

Implementing Centralized Administration

Centralized administration involves one or more Administration servers at a central location managing domains or OUs that contain objects at other locations. When considering a centralized administration model, ensure you install enough secondary Administration servers to provide adequate load balancing. If a large number of AAs will be connecting to a single Administration server, consider adding a secondary server to help balance this load.

The centralized administration model can cause performance or connection issues if your client computers must connect over a slow WAN link. In this case, consider installing additional secondary Administration servers at remote sites that require more reliable connections.

Implementing Distributed Administration

Distributed administration is one or more secondary Administration servers at each site or location, with a primary Administration server at a central location. Consider installing the primary Administration server at the site where the majority of administrators who create and maintain your security definitions are located.

Be aware that DRA does not synchronize security definitions and configuration settings from one primary Administration server to another primary Administration server. That is, you cannot synchronize your security model across server sets. To move your security model from one primary server to another, back up the registry files from the source Administration server and copy that registry on to the target Administration servers. By default, the Administration server stores security data under the HKEY_LOCAL_MACHINE\SOFTWARE\Mission Critical Software\OnePoint\ Administration\Data\Modules\Security registry key. For more information about how synchronization works, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

Planning Administration Servers for Your Environment

Depending on the size of your environment, you may need to consider additional Administration server requirements. The following sections discuss these requirements.

Administration Server Location

When managing a Microsoft Windows domain, or a subtree of that domain, you can install the Administration server on a computer in the managed domain or in a different domain. However, some restrictions, such as available bandwidth, do apply.

When deciding on the Administration server location, consider the following restrictions:

  • DRA does not require a direct trust between the domain of the Administration server and the managed domain. However, to include a user account in an Assistant Admin (AA) group, the selected account should exist in a domain trusted by the domain of the primary Administration server. Likewise, to ensure client computers in the managed domain can access an Administration server, the server must be a member of a domain that trusts the managed domain.

    If the trust relationships between managed domains breaks, DRA discovers and identifies the broken trusts during the domain configuration refresh. You can schedule domain configuration refreshes to run on a routine basis, or you can perform an immediate domain configuration refresh to troubleshoot or resolve a current issue. You can also view the status of a managed domain through the Delegation and Configuration console. For more information, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

  • In a Microsoft Windows environment, a reliable connection must exist between the Administration server and a domain controller for each managed domain. If these connections are lost, the Administration server cannot update objects or provide complete reporting. Bandwidth restrictions, such as the Remote Access Service (RAS), between the Administration server and the managed domains can cause the Administration server to require more time to start and to perform some operations.

Configuring the Administration Server to Write All Changes to a Specific Domain Controller

You can configure the Administration server to read information from and write changes to a specific domain controller.

To specify the domain controller:

  1. Start the Delegation and Configuration console.

  2. In the left pane, expand Configuration Management.

  3. Click Managed Domains.

  4. In the list pane, select the domain.

  5. On the Tasks menu, click Properties.

  6. On the General tab, click the Browse button next to the Connect to domain controller field.

  7. Select the preferred domain controller from the list, and then click OK.

  8. Click Yes when the warning message displays so that DRA initiates a full accounts cache refresh.

Managing Multiple Domains and Subtrees

When you manage multiple domains and subtrees, you can configure DRA to use different accounts to access and manage these domains and subtrees. By default, DRA uses the Administration server service account to access managed domains and subtrees. However, specifying access accounts allows you to better control security across your enterprise. Using multiple access accounts to manage multiple domains or subtrees, servers, and workstations removes the concern that one account has enterprise‑wide privileges. For more information about access accounts, such as permissions requirements, see the Administrator Guide for Directory Resource Administrator and Exchange Administrator.

NOTE:The Administration server stores access account information locally. If you change the name or password of an access account, you must also update the account specifications through the Delegation and Configuration console on each Administration server.

Access Accounts and Multiple Managed Domains

You can specify one or more access accounts to manage multiple domains. If you plan to use access accounts to manage multiple domains, consider the following guidelines:

  • Configure and specify one access account for each managed domain.

  • Do not use pass-through authentication when managing multiple domains in a native environment.

Access Accounts and Multiple Managed Subtrees

You can specify one or more access accounts to manage multiple subtrees. If you plan to manage multiple subtrees of the same domain, you can use the same access account to manage each subtree. However, if you are managing multiple subtrees from different domains, configure and specify one access account for each subtree.

To retrieve group and user account information from trusted domains, ensure the access account is a member of the Domain Users group in all trusted domains.

Access Accounts and Managed Computers

When specifying access accounts to manage specific member servers or workstations, consider the following guidelines:

  • To manage servers or workstations that are members of a managed domain, the access account must be a domain account. The access account cannot be a local server or workstation account.

  • To manage resources on a local computer, ensure the access account is a domain account from the managed domain.

  • To manage workgroups the access account must be a local server account.

Access Accounts from Trusted Domains

You can use an account from a trusted domain like the access account for a managed Microsoft Windows domain. This account requires the same permissions as an account from the managed domain.

Access Accounts and Active Directory Replication

Whether you install the Administration server on a server or domain controller, the access account definition must be replicated to all domain controllers before you can use the account to access another Administration server or a managed domain. You should force Active Directory replication in Microsoft Windows environments.

The Administration server updates information only on the domain controller in the managed domain. Therefore, if you want to access user accounts from trusted domains to manage group memberships, the access account must be a User (not a Guest) in each domain trusted by the managed domain.

How DRA Uses Access Accounts in Different Environments

If your environment contains several domains, subtrees, servers and workstations, DRA supports multiple access account scenarios. Consider the following example environment:

  • NewYork and Houston domains

  • Sales subtree in Houston domain

  • SmithJ server

  • ChildsJ workstation

The following table illustrates how DRA uses the specified access account or default Administration server service account, depending on how you manage this environment:

If you specify these accounts...

And you manage...

DRA uses the following accounts...

Administration server service account

Any domain, server, or workstation

Administration server service account

Administration server service account

Any subtree of a Microsoft Windows 2000 domain

Administration server service account

Administration server service account

Access account for the Houston domain

NewYork domain

Administration server service account

Houston domain

Access account specified for the Houston domain

Administration server service account

Access account for the Houston domain

NewYork domain

Administration server service account

Sales subtree of the Houston domain

Access account specified for the Houston domain

Administration server service account

Access account for the Houston domain

NewYork domain

Administration server service account

Sales subtree of the Houston domain

Access account specified for the Houston domain

server or workstation in the Houston domain

Access account specified for the Houston domain

Administration server service account

Access account of the Houston domain

Access account for the SmithJ workstation

NewYork domain

Administration server service account

Sales subtree of the Houston domain

Access account specified for the Houston domain

server SmithJ

Access account specified for this workstation

Administration server service account

Access account for the ChildJ workstation

Any domain

Administration server service account

Workstation ChildsJ

Access account specified for this workstation

Installing the Web Application on a Dedicated Web Server

You can install the Web application on a dedicated Web server (IIS server) rather than the Administration server computer. This installation works best in a native mode environment that uses Kerberos-only authentication. The IIS server computer and the Administration server computer must belong to the same domain. For more information about Web application requirements, see Administration Server Requirements. For more information about configuring Kerberos authentication, see NETIQKB14935 and Installing the Web Application on a Server not Running the Administration Server.

If you install the Administration server and IIS server on separate computers, you should ensure the DRA ADSI provider on the IIS server uses Kerberos as the default authentication protocol. For more information about changing the default authentication protocol to Kerberos, see NETIQKB48582.

You should also check whether the NTFS permissions for the Local System account has been modified on the IIS server or the Administration server. For more information about checking NTFS permissions, see NETIQKB33414.

If you plan to manage a Microsoft Windows domain and you want to install the Administration server and Web application on different computers, ensure each domain controller in this managed domain is running the same version of the operating system as your Web server.

If you install the Web application on a computer other than the Administration server, and you want to deploy the Web Console with a supported web browser, set your browser security to support integrated Windows authentication. To set your browser security, select Enable Integrated Windows Authentication under Security on the Advanced tab of the Internet Options window. You can access Internet Options through the Tools menu.

If you select the Use fully qualified domain names (FQDN) option to specify the location of your Web server, DRA forces AAs to log in every time they access a property page. AAs can configure DRA to remember their logon name and password.

Configure the IIS server as a Local Intranet Site. To set your browser security, access the Security tab through Internet Options on the Tools menu. Under the Security tab, select Local intranet and click Sites. Type http://IIS_server_name in the Add this Web site to the zone: field.

Installing the Web Application on a Server not Running the Administration Server

You can install the Web application on a server that is not running the Administration server component.

To install the Web application on a server not running the Administration server:

  1. Run Setup.exe on the IIS server.

  2. Click the Production Setup tab.

  3. Click Begin Production Setup.

  4. Select Custom, and click Next.

  5. Select Web Component, and click Next.

  6. Add the correct license information, and click Next.

  7. Type the name of the server running the NetIQ Administration Service, and then click OK.

Deploying Multiple Web Console Applications

You can install more than one Web Console application on your Administration server or Web server computer. This flexibility allows you to deploy different, custom Web Consoles for each site or AA group. To install more than one Web Console application, set up a new virtual directory for each Web Console application you want to deploy.

Creating a Virtual Directory for the Web Console

For each Web Console application you want to deploy, create a virtual directory that references the correct files.

To create a virtual directory:

  1. Log on with an administrator account to the computer where you want to install the virtual directory.

  2. On the Start menu, click Programs > Administrative Tools.

  3. Click Internet Services Manager.

  4. Expand the server node.

  5. Select Default Web Site.

  6. On the Action menu, click New > Virtual Directory.

  7. Follow the instructions until you have finished creating the virtual directory. Ensure you specify the following settings:

    1. Specify the path of the Web Console files in the Directory field on the Web Site Content Directory window. By default, the Web Console files are located under C:\Inetpub\wwwroot\DRAWeb\WebConsole.

    2. Select Read and Run scripts on the Access Permissions window.

  8. Click Finish.

Configuring the Web Console Virtual Directory

For each Web Console application you want to deploy, ensure the virtual directory has the appropriate settings.

To configure a virtual directory:

  1. In the left pane of the Internet Services Manager window, select the new virtual directory.

  2. On the Action menu, click Properties.

  3. On the Virtual Directory tab, click Configuration.

  4. On the App Options tab, verify the following settings, and then click OK.

    • Select Enable session state.

    • Select Enable buffering.

    • Select Enable parent paths.

    • Type VBScript for the Default ASP language.

  5. On the Documents tab, ensure Default.asp is one of the listed default documents.

  6. On the Directory Security tab, click Edit under Anonymous access and authentication control.

  7. Clear Anonymous access, and then click OK.

  8. Click OK.

Testing the Web Console Virtual Directory

To test the new virtual directory before you deploy the Web Console application, type the URL of the new virtual directory in the Address field and press Enter.

For example, if you configured the WCHouston virtual directory on the server01 Administration server, type http://server01/WCHouston.