Staging Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted, Release 10.0(1)
Domain requirements and supported topologies
Downloads: This chapterpdf (PDF - 1.6 MB) The complete bookPDF (PDF - 4.21 MB) | The complete bookePub (ePub - 1.21 MB) | Feedback

Domain Requirements and Supported Topologies


Domain Requirements and Supported Topologies

Microsoft Active Directory Tools

Before you install Unified ICM in a new or existing AD environment, it is ensure that the environment be stable. As a general rule, for all domain controllers in a forest, you must monitor replication, server, and AD health on a daily basis using Microsoft Operations Manager (MOM) or an equivalent monitoring application. For information about using MOM to monitor AD, see the Active Directory Management Pack Technical Reference for the current version of MOM on the Microsoft TechNet website.

Microsoft provides several tools that you can use to ensure AD health and connectivity and that your environment is ready for Unified ICM. On Windows Server, support tools are located in the support\tools directory on the Windows Server CD. Some of these tools are listed in the following table.

Table 1 Microsoft AD Tools

Tool Name



Command Line


Windows CD in the Tools subfolder

  • Generates a report on AD health.
  • Verifies connectivity, replication, topology integrity, inter-site health, and trust verification.
  • Checks Network Card (NC) head security descriptors, net logon rights, and roles.
  • Locates or gets the domain controller.

dcdiag /v /e /f:dcdiag.txt

Note    You must run this tool on the enterprise domain.


Windows CD in the Tools subfolder

  • Retrieves the replication status of all domain controllers in a spreadsheet.
  • Verifies DNS infrastructure, Kerberos, Windows time service (W32time), remote procedure call (RPC), and network connectivity.

repadmin /showrepl * /csv >showrepl.csv


  • The reports generated by these tools need to be evaluated by your network administrator, or a qualified AD expert (for example, Microsoft Support Services).

After the tools are installed, run the following setups:

  • dcdiag.exe
  • repadmin.exe

Run dcdiag.exe

    Step 1   Choose Start > Run.
    Step 2   Type cmd.
    Step 3   Press Enter.

    A command console opens.

    Step 4   At the prompt, enter dcdiag.exe /e /v /f:dcdiag.txt.

    If you use the /e option, you must run dcdiag.exe at the root level. If you do not use the "/e" option, you must run dcdiag.exe on each individual domain controller.

    The application creates the text file dcdiag.txt in the folder containing dcdiag.exe.

    Step 5   Open the text file and note any items that are prefaced with "Warning" or "Error."
    Step 6   Correct all the issues, then rerun dcdiag.exe to ensure that no issues remain.

    Run repadmin.exe

      Step 1   Choose Start > Run.
      Step 2   Type cmd.
      Step 3   Press Enter.

      A command console opens.

      Step 4   At the prompt, enter repadmin.exe /showrepl * /csv >showrepl.csv.
      Step 5   Open Excel and choose File > Open.

      Depending on your version of Excel, the menu cascades may be slightly different.

      Step 6   In the "Files of type" section, click Text Files (*.prn;*.txt;*.csv).
      Step 7   In the "Look in" section, navigate to showrepl.csv, then click Open.
      Step 8   In the Excel spreadsheet, right-click the column heading for showrepl_COLUMNS (column A), then click Hide.
      Step 9   In the Excel spreadsheet, right-click the column heading for Transport Type, then click Hide.
      Step 10   Select the row just under the column headings, then choose Windows > Freeze Pane.
      Step 11   Click the upper-left corner of the spreadsheet to highlight the entire spreadsheet. Choose Data > Filter > AutoFilter.
      Step 12   In the heading of the Last Success column, click the down arrow, then click Sort Ascending.
      Step 13   In the heading of the Source DC column, click the down arrow, then click Custom.

      In the Custom AutoFilter dialog box, complete the custom filter as follows:

      1. Under Source DC, click does not contain.
      2. In the corresponding text box, enter del to filter deleted domain controllers from the spreadsheet.
      Step 14   In the heading of the Last Failure column, click the down arrow, then click Custom.

      In the Custom AutoFilter dialog box, complete the custom filter as follows:

      1. Under Last Failure, click does not equal.
      2. In the corresponding text box, enter 0 to filter for only domain controllers that are experiencing failures.

      For every domain controller in the forest, the spreadsheet shows the following:

      • Source replication partner
      • The time that replication last occurred
      • The time that the last replication failure occurred for each naming context (directory partition)
      Step 15   Use Autofilter in Excel to view the replication health for the following:
      • Working domain controllers only
      • Failing domain controllers only
      • Domain controllers that are the least, or most recent

      You can observe the replication partners that replicate successfully.

      Step 16   Locate and resolve all errors.
      Step 17   Rerun repadmin.exe to ensure that no issues remain.

      Domain Requirements


      The Domain Controller and DNS servers can not be co-located on any Unified ICM component and must be installed on a separate server.

      Unified ICM Requirements for AD:

      • Authenticated users require credentials of an domain account with write privileges to the ICM OU.
      • Microsoft AD tools or Domain Manager are the only supported tools for provisioning AD.


        Permissions are needed during setup for creation of Service Logon accounts.

      • You cannot create Unified ICM servers in the Unified ICM OU hierarchy.
      • You can only apply the Unified ICM group policy template to OUs containing the Unified ICM servers.
      • Single-label DNS domain names (such as "ICM") are not supported when you use them with Unified ICM/CCE & Hosted. Multi-part names such as,,, or are acceptable.


        For additional information, see Information about configuring Windows for domains with single-label DNS names.

      • No AD schema changes are required. Authenticated users require read access to the contents of AD.

      Requirements for Group Policy in AD

      Group Policy plays a pivotal role in AD management and directly affects the function of distributed applications like Unified ICM. This section explains Group Policy and defines requirements to ensure proper functioning of your Cisco applications related to Unified ICM servers.

      Group Policy Overview

      Administrators can manage computers centrally through AD and Group Policy. Using Group Policy to deliver managed computing environments allows administrators to work more efficiently because of the centralized, 'one-to-many management' it enables. Group Policy defines the settings and allows actions for users and computers. It can create desktops that are tailored to users' job responsibilities and level of experience with computers. Unified ICM uses this centralized, organized structure to help ease the administrative burden and create an easily identifiable structure for troubleshooting. However, some settings can adversely affect Unified ICM and the Unified ICM servers ability to function. As such, it is necessary to control the OU structure for Unified ICM components and ensure adherence to a standard.

      Group Policy Settings

      Administrators use Group Policy to define specific configurations for groups of users and computers by creating Group Policy settings. These settings are specified through the Group Policy Object Editor tool (known as GPedit.msc) and are present in a Group Policy object (GPO), which is in turn linked to AD containers (such as sites, domains, or OUs). In this way, Group Policy settings are applied to the users and computers in the AD containers. For additional information on Group Policy management, see http:/​/​​en-US/​windows7/​Group-Policy-management-for-IT-pros.

      Unified ICM Predefined Policies

      Unified ICM has optional predefined policies that you can choose to apply to its OU structure to ensure security. These policies do not disrupt Unified ICM functionality.

      Unified ICM Server Domain Requirements

      You can move all Unified ICM servers into a separate OU to ensure proper functioning of the Unified ICM application and to improve security. You must clearly identify the OU as Cisco_ICM_Servers (or a similar clearly identifiable name) and documented in accordance with your corporate policy.


      You must create this OU either at the same level as the computer or at the Cisco_ICM Root OU. If you are unfamiliar with AD, engage your Domain Administrator to assist you with Group Policy deployments.
      Figure 1. Group Policy Deployments

      After you apply the Group Policy to the OU, you must prevent propagation of default or custom Group Policies to this OU. You can accomplish this by using block inheritance; for details, see Block Policy Inheritance.

      You also need to verify that a global Enforced policy is not applied in the domain. For details, see Prevent Use of Improper Policies.

      GPO links that are enforced cannot be blocked from the parent container.

      Block Policy Inheritance

      You can block inheritance for a domain or organizational unit. Blocking inheritance prevents Group Policy objects (GPOs) that are linked to higher sites, domains, or organizational units from being automatically inherited by the child-level. If a domain or OU is set to block inheritance, it appears with a blue exclamation mark in the console tree.

        Step 1   In the Group Policy Management Console (GPMC) console tree, double-click the forest containing the domain or organizational unit (OU) for which you want to block inheritance for GPO links.
        Step 2   To block inheritance for an OU, double-click Domains, double-click the domain containing the OU, and then right-click the OU.
        Step 3   Choose Block Inheritance.

        Prevent Use of Improper Policies

        You must prevent improper policies from being propagated. If the Enforced option is selected in a Group Policy Object being applied to a Cisco OU, a parent object has enabled the option, which takes precedence over block policy inheritance. You must uncheck the Enforced option on all parent OUs or Group Policy Objects.
          Step 1   Select a parent OU or Group Policy Object from the Group Policy Management console tree.

          The Default Domain Policy opens in the right pane.

          Step 2   In the Links section, locate the domain, and note whether the Enforced option is enabled (Yes if enabled, No if not) .
          Step 3   If the option is enabled, right-click on Yes and deselect the Enforced option.

          Set Permissions for Administration and Data Server in a Different Domain

          If you are setting up an Administration & Data Server in a domain other than the Central Controller domain, perform the following tasks to update the NAM Unified ICM AD OU environment so that the Administration & Data Server points to the CICM Central Controller.


          The following steps are only required when the Administration & Data Server is in a different domain than the Central Controller.
            Step 1   Find the name of the Facility and instance from the CICM ICM AD Environment.

            You can find the name by running Domain Manager on a Unified ICM Server in the CICM domain.

            Step 2   Run the Domain Manager on a Unified ICM Server in the NAM domain.
            Step 3   In the Domain Manager, select the Cisco_ICM root.
            Step 4   Add a Facility with the same name used in the CICM Domain.
            Step 5   Select this Facility and add the instance with the same name that was used in the CICM Domain.
            Step 6   After the CICM Facility and instance is recreated on the NAM domain, run the Service Account Manager tool to generate the Service Account and password.

            The Service Account Manager tool sets the new service account in the Unified ICM Service Security group of the instance in the NAM domain and in the CICM domain. The service group is created in the NAM domain.

            Install the Administration Client on a Different Domain in a Single Forest

            You can install the Administration client on a different domain other than the Central Controller domain within a single forest.

            Before you begin:
            • A transitive trust must exist between the Administration client domain and Central Controller domain.
            • An ICM domain user from the Central Controller domain must be granted local administrator privilege on the Administration client machine.


            The following steps are only required when the AdminClientInstaller is in a different domain than the Central Controller.
              Step 1   Log in to the Administration client machine using the credentials from the Central Controller domain user, which is a part of local administrators group.
              Step 2   Find the fully qualified domain name of the Central Controller domain.
              Step 3   Install the Administration client.
              Step 4   Launch the Administration client setup. The Log in page appears.
              Step 5   Log in with your Active Directory user name and password. The log in fails because you are attempting to log in from a non-UCCE domain.
              Step 6   Log in again with your Active Directory user name and password and the fully qualified UCCE domain name that you obtained in step 2. You will now be able to log in to the Administration client.

              DNS Requirements

              The following are DNS requirements:

              • AD Integrated Zone for both forward and reverse lookup zones.
              • Enterprise level Standard Secondary Zone for the Unified ICM/Unified CCH Child Domain model or the Unified ICMH/ Unified CCH Domain model.
              • You must manually add all additional addresses (high, privates, private highs, and so forth) to the forward lookup zone in DNS along with associated PTR records.
              • Corporate DNS servers have forwarding enabled to the AD servers (if using Corporate DNS servers as opposed to the Domain Controllers for name resolution).

              Global Catalog Requirements

              In a multi-domain forest, Cisco requires you to have a Global Catalog at each AD site. The Global Catalog is a central repository of domain information in an AD forest. Without the local Global Catalog, AD queries cause significant performance degradations/failure—every AD query needs to search every domain in the forest, and multi-site deployments need to query across WAN links.

              Supported Topologies

              Unified ICME/Unified CCH systems support the following AD topologies:

              • Single Domain
                • Unified ICM/Unified CCH in the Corporate domain
                • Unified ICM/Unified CCH in a child domain of the Corporate domain
                • Unified ICM/Unified CCH as a standalone domain
                • Unified ICM/ Unified CCH as a tree root

              A forest is a collection of AD domains that provide a namespace and control boundary within AD.

              Unified ICMH/Unified CCH systems support the following AD topologies:

              • Single Domain
                • NAM/CICM/Customer HDSs in a single domain
              • Single Forest, Single Tree
                • NAM as a parent domain
                  • CICM as the NAM child, Customer HDSs as the CICM child
                  • CICM and Customer HDSs in a single domain as the NAM child
                • You can have an Administration client in a different domain from the Unified ICM/CCE instance in the same tree.
              • Single Forest, Multiple Tree


                You can have an Administration client in a different domain from the Unified ICM/CCE instance in the same tree.

              Use the following example to determine how your domain structure looks before installing the Domain Controller.

              This information is intended for the individuals responsible for:

              • Configuring the AD Domain and Forest Topologies
              • Staging new deployments of Unified ICMH/Unified CCH or Hosted NAM/CICM on Windows Server

              You must train the administrators of your Unified ICMH/Unified CCH system on the use and functions of:

              • Unified ICMH/Unified CCH
              • Windows Server
              • AD
              • DNS

              This section does not provide detailed Unified ICME, Hosted NAM/CICM, or Windows Server specific information. You can find this information elsewhere in specific documentation from Cisco and Microsoft. Individuals using this document must have at least intermediate knowledge and experience with AD.

              The ability to integrate Unified ICM into existing infrastructures is one of the premises of Unified ICM. You can mitigate the impact that the unique environments in these existing infrastructures has on Unified ICM with minor adjustments to the support schema.

              Related Information

              Multiple Forests Not Supported

              Multiple forests means two or more forests in a given environment that share resources through manually created trust relationships. After careful review, Cisco Systems, Inc. determined that it is necessary to constrain the deployment scenarios and ensure customers use only single forest topologies. Multiple forest topologies (in regards to Unified ICM) are not supported. All Unified ICM components must be either in the same domain or in the same forest. This allows the automatic transitive trust relationships in the forest to replace the manual external trusts. The appropriate solution will simplify, or limit, the exposure to topology based deployment problems.

              For additional information, see Security Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted .

              Use Microsoft Services or third-party Microsoft partner professional services to mitigate any Microsoft specific issues that might arise, as domain topologies vary.

              Single Forest, Single Tree, and Single Domain Benefits and Usage Scenarios

              The following are the benefits of using Single Forest, Single Tree, and Single Domain:

              • Benefits
                • Simple setup
                • High stability
                • Smallest AD footprint
                • Least deployment-to-complexity ratio
                • Easiest support profile
              • Sample usage scenarios
                • Enterprise Deployment
                • Hosted Environment Deployment

              Single Domain Model

              This type of domain structure comes with one major advantage over the other models: simplicity. A single security boundary defines the borders of the domain and all objects are located within that boundary. The establishment of trust relationships between other domains is not necessary and the execution of Group Policies is made easier by this simple structure.

              When designing the new Active Directory structure from a multiple domain NT style structure, it was generally believed you could not consolidate on a single domain model. AD changes this. The capacity to span multiple domains in a single forest is improved and simplified.

              Advantages of Single Domain Model

              The single domain model is ideal for many Unified ICM deployments. A single domain structure possesses multiple advantages, the first and foremost being simplicity. Adding unnecessary complexity to a system architecture introduces potential risk and makes troubleshooting more difficult. Consolidating complex domain structures into a simpler, single AD domain structure reduces the administration costs and minimizes setbacks in the process.

              Another advantage is centralized administration. Organizations with a strong central IT structure want the capability to consolidate their control over their entire IT and user structure. Because NT domains were lacking in their capability to scale to these levels, the central control that organizations wanted was not available. Now, AD and the single domain model allow for a high level of administrative control, including the capability to delegate tasks to lower sets of administrators.

              Unified ICM benefits from this design because AD traversal queries are limited to the single domain. As a result, request processing time is significantly reduced. AD controls access and provides security. This dramatically improves the overall performance of Unified ICM.

              Single Domain Topology Design

              Design is the most important aspect of any AD deployment. Follow Microsoft's planning and design technical documentation to ensure a smooth transition.

              Delegation of password-change control and other local administrative functions can be granted to individuals in each specific geographical OU. The delegation of administrative functions provide administrators with permissions specific to the resources within their own group while maintaining central administrative control in the root OU.

              Figure 2. Sample Single Domain Layout

              You can create several AD sites to control the frequency of replication. You must position a site to correspond with a separate geographical area, creating a site structure similar to the one shown in the following figure.

              Figure 3. Site Organization by Geographical Location

              Creating separate sites helps throttle replication traffic and reduces the load placed on the WAN links between the sites. For more details about site links and replication, see How Active Director Replication Topology Works.

              This type of single domain design is ideal for both large and small organizations. As delegation of administration is now accomplished through the use of OUs and Group Policy objects, and the throttling of replication is accomplished through AD sites, the use of multiple domains is significantly reduced.

              There are hosted scenarios where you have many instances deployed in a variety of ways (such as geographically, client size, or however this model fulfills your needs). The following figure shows an example domain layout.

              Figure 4. Hosted OU Structure for Single Domains

              A single-domain design enables AD to manage access to the domain using Group Policies, Kerberos, and ACLs. This greatly simplifies administrative overhead and provides an increased return on investment for the entire organization.

              Related Information

              Single Tree Multiple Child Domains

              For Unified ICMH/Unified CCH systems, it might be necessary to install Unified ICM in more than one domain. The addition of one or more child domains into the forest might be necessary. (Unified ICM/Unified CCH systems must be in a single domain) when you install Unified ICM in more than one domain. When adding a domain, you must consider the particular characteristics of multiple domain models.

              By default, two-way transitive trusts exist between the child domain and the parent domain in AD. However, this does not mean that resource access is automatically granted to members of other domains. For example, a user in the child domain is not automatically granted any rights in the parent domain. You need to explicitly define all rights through the use of groups. Understanding this concept helps to determine the requirements of domain addition.

              When to Add Additional Domains

              Begin design with a single domain and only add domains when absolutely necessary. Adding child domains to your existing domain structure might become necessary if the need for decentralized administration exists within your infrastructure. If your organization requires Unified ICM to be managed by its own IT structure and there are no future plans to consolidate them into a centralized model, multiple interconnected domains might be useful. A domain acts as a security boundary for most types of activities and is set up to block administration from escaping the boundaries of the domain. This approach operates in much the same way as NT domains, inheriting many of their associated limitations. It is better to try to centralize administration before deploying AD because you gain more AD advantages (for example: centralized management, a simpler deployment model, simplified user and group management, and enhanced operability). The following figure demonstrates the boundary as it exists by default in this topology. In order to give the user access to resources in the parent domain, the rights must be assigned.

              Figure 5. Active Directory Boundaries

              If there are geographic limitations (such as extremely slow or unreliable links), segment the user population into separate groups. This helps to limit replication activity between domains and makes it easier to provide support during working hours in distant time zones. Note that slow links by themselves do not necessitate the creation of multiple domains as AD sites throttle replication across slow links. Administrative flexibility is the main reason to create a domain for geographical reasons. For example, if there is a problem with the network in Asia, a local administrator has the power and resources to administer the Asia domain and has no need to contact a North American administrator.

              Figure 6. Regional Domains

              The single tree multiple child domain model allows each region to perform its own administration, creating an easily distributed and extremely flexible topology. This allows for a wide support base with immediate incident response. It also keeps the deployment clean and logical.

              For Unified ICM, the addition of multiple child domains retains some of the old familiarity of NT4 topologies but gives an ease of delegation. This topology is appealing to some service providers because the logical boundary of the domains can provide a clear delineation in the NAM/CICM relationship while still maintaining AD functionality.

              The single tree multiple child domain topology provides a contiguous namespace where the DNS domain names are related by the naming convention.

              Figure 7. Contiguous Namespace

              The flexibility in this model is apparent; however, it is important to be familiar with your organization's requirements for a distributed, collaborative application such as Unified ICM. Use the simplest possible topology that meets your requirements.

              Related References

              Multiple-Tree Topology

              A single forest with multiple trees and disjointed namespaces is a complex AD topology. This configuration can consist of one or more root domains, and one or more child domains.

              Multiple Tree Forests

              A forest is established when the first AD domain is created. This domain is known as the forest root. In a forest, any domains sharing a contiguous namespace form a tree. After a tree is established in a forest, any new domains added to an existing tree inherit a portion of its namespace from its parent domain.

              Any domain added to the forest that maintains a unique namespace form a new tree in the forest. An AD forest can consist of one or many trees in a single forest. In some instances, multiple trees are required so that a company can meet its business requirements.

              Multiple Trees in a Single Forest Model

              If your organization decides to move to an AD environment and wants to use an external namespace for its design, then you can integrate the external namespace into a single AD forest. Use multiple trees in a single forest to accommodate multiple DNS namespaces.

              One of the most misunderstood characteristics of AD is the difference between a contiguous forest and a contiguous DNS namespace. You can integrate multiple DNS namespaces into a single AD forest as separate trees in the forest as indicated by the following figure.

              Figure 8. Simple Multiple Tree Topology

              Only one domain in this design is the forest root ( in the figure above), and only this domain controls access to the forest schema. All the other domains shown (including the subdomains of, as well as the domains occupying different DNS structures) are members of the same forest. All trust relationships between the domains are transitive, and the trusts flow from one domain to another.

              Business Requirements

              Ensure that you plan a simple domain structure. If a business does not require multiple trees, do not increase the difficulty by creating an elaborate multiple-tree structure. However, sometimes multiple trees are required and this requirement is decided only after a thorough assessment of the business. When considering a multiple tree structure, keep the following requirements in mind:

              DNS Names

              If a business comprises of different subsidiaries, or has partnered with other businesses that need to maintain their distinct public identities as well as separate (noncontiguous) DNS names, you might have to create multiple trees in a single forest.

              When to Choose a Multiple Tree Domain Model

              If your organization currently operates multiple units under separate DNS namespaces, one option is to consider a multiple tree design. However, simply using multiple DNS namespaces does not automatically qualify you as a candidate for this domain design. For example, suppose that you own five separate DNS namespaces and decide to create an AD structure based on a new namespace that is contiguous throughout your organization. Consolidating your AD under this single domain simplifies the logical structure of your environment while keeping your DNS namespaces separate from AD.

              If your organization makes extensive use of its separate namespaces, consider a design like the following: each domain tree in the forest can then maintain a certain degree of autonomy, both perceived and real. Often, this type of design seeks to satisfy the needs of branch office administrators.

              The domain design described above is logically more convoluted, but technically carries the same functionality as any other single forest design model. All the domains are set up with two-way transitive trusts to the root domain and share a common schema and global catalog. The difference lies in the fact that they all utilize separate DNS namespaces, a fact that must also be reflected in the zones that exist on your DNS server.

              Additional Considerations for Topology Design

              The preceding sections provide a general overview of the considerations necessary when choosing a topology for Unified ICM in a corporate environment. Other considerations might arise, depending on a corporation's internal directives. The following topics include additional considerations for topology design.

              Single Domain

              In general, a Windows domain structure must be as simple as possible. The simplest approach is to create just one domain.

              A single domain approach benefits:

              • Most straightforward design
              • Requires the least replication traffic
              • Provides a minimum of administrative complexity
                • Requires the fewest domain administrators
                • Requires the fewest domain controllers
                • Allows administrative control at low levels in the domain by creating OUs and OU-level administrators—a domain administrator is not required to perform most tasks

              Single Tree, Multiple Domains

              A more complex structure is a root domain with domains beneath it.

              Single tree, multiple domain approach provides the following benefit: the domain administrator of the root domain has complete power over the AD tree.

              However, you must consider the following drawbacks when using the single tree, multiple domain approach:

              • More complex than a single domain
              • Creates more replication traffic
              • Requires more domain controllers than a single domain
              • Requires more domain administrators than a single domain
              • Setting tree-wide Group Policies requires using site Group Policy Objects (GPOs) or replicated domain/OU GPOs
              • Tree could become complex if you create too many child domains

              Single Forest, Multiple Trees

              All domains in a forest can belong to a single domain tree if their DNS names are contiguous. If their DNS names are not contiguous, you must create separate domain trees. Accordingly, if one domain tree is sufficient, there is no inherent need to create multiple trees.

              Before using a single forest, multiple tree approach, you need to consider the following drawbacks:

              • Far more complex than a single domain
              • Creates substantially more replication traffic
              • Requires more domain controllers than a single domain
              • Requires more domain administrators than a single domain
              • Requires using site Group Policy Objects (GPOs) to set Group Policies

              Additional Considerations


              Some organizations separate business units to provide security. This perception is a holdover from Windows NT4 where the domain boundary did provide the security. AD, however, provides layers of actual security. These layers are all customizable, and you can set them up in any of the supported topologies.

              Corporate Directives

              Many organizations have standard policies and procedures that they are accustomed to using as a Global standard. Unified ICM is a robust application and might be sensitive to some of these directives. For instance, some organizations have daily or weekly reboot policies for domain controllers. This situation requires a firm understanding of the affect AD has on the domain structure. If you turn all of the Domain Controllers off simultaneously, anything that relies on AD breaks. To avoid this problem, stagger the Domain Controller reboots so at least one domain controller per domain remains online at any given time.

              This is just one example. There are many variations and unique policies that could possibly have an impact on Unified ICM. The procedures detailed in this guide delineate the best possible methods of deploying and maintaining Unified ICM. Review your company policies and compare them with the requirements established in this guide. If conflicts arise, this allows you to correct them prior to deployment.

              Domain Name System

              AD integrates with the Domain Name System (DNS) as follows:

              • AD and DNS have the same hierarchical structure. Although separate and executed differently for different purposes, an organization's namespace for DNS and AD have an identical structure.
              • You can store DNS zones in AD. If you use the Windows Server DNS Server service, you can store primary zone files in AD for replication to other AD controllers.
              • AD uses DNS as a locator service, resolving AD domain, site, and service names to an IP address. To log on to an AD domain, an AD client queries their configured DNS server for the IP address of the Lightweight Directory Access Protocol (LDAP) service running on a domain controller for a specified domain.


                You can use dcdiag.exe to troubleshoot client computers that cannot locate a domain controller. This tool can help determine both server and client DNS mis-configurations.

              While AD is integrated with DNS and shares the same namespace structure, it is important to understand their differences:

              • DNS is a name resolution service. DNS clients send DNS name queries to their configured DNS server. The DNS server receives the name query and either resolves the name query through locally stored files or consults another DNS server for resolution. DNS does not require AD to function.
              • AD is a directory service. AD provides an information repository and services to make information available to users and applications. AD clients send queries to domain controllers using the Lightweight Directory Access Protocol (LDAP). An AD client queries DNS to locate a domain controller. AD requires DNS to function.

              Follow the Microsoft best practices for AD to create lookup zones and to configuring DNS servers:

              • Select AD Integrated Zone for both forward and reverse lookup zones.
              • Listen only on a single Visible IP address (DNS – Properties – interfaces tab).
              • Select the Allow Dynamic updates and Only Secure updates options.
              • Limit zone transfers to limited and trusted servers only.
              • Add all additional addresses manually (high, privates, private highs) in DNS as a Host record.
              • If you use Corporate DNS servers rather than the Domain Controllers for name resolution, ensure that the Corporate DNS servers have forwarding enabled to the AD servers.

              Install DNS on Additional Domain Controller

                Step 1   Choose Start > Control Panel > Add/Remove Programs.
                Step 2   On the Add/Remove Windows Components, check Networking Services and click Details.
                Step 3   Check DNS, click OK, then select Next.
                Step 4   Browse to the Windows Server CD. DNS installation begins.
                Step 5   Validate that all DNS Zones were replicated from the first DNS Server in the AD Domain to this DNS Server.
                1. Select the machine name, right-click and select Properties.
                2. On the Interfaces tab, select Listen on only the following IP addresses, remove all but the visible machine address.
                Step 6   For a Unified CCE Child Domain model, perform the following additional steps:
                1. Manually add the Enterprise level Standard Secondary Zone.
                2. Change DNS Settings on the First Domain Controller in the Child Domain to point to this additional Child Domain level DNS Server.

                Configure Active Directory Sites

                On Unified ICM Root Domain Controller:

                  Step 1   Choose Start > Programs > Administrative Tools > AD Sites and Services.
                  Step 2   Rename the default first site name as per AD Site Plan in Unified ICM System Diagram.
                  1. For a geographically separated DC, right-click Sites.
                  2. Select New Site.
                  3. Enter the site name of the additional domain controller based on the Unified ICM System Diagram.
                  Step 3   Create subnets for each DC site:
                  1. Right-click the Subnets folder and select New Subnet.
                  2. Enter the subnet address and mask, respective to the LAN at the Domain Controller Site.
                  3. Highlight the Site Name associated with that subnet.
                  Step 4   Expand the Servers folder from the original first site folder.
                  1. For each Server you need to move to a different site, right-click on server name, select Move and highlight the Site you want to move it to.
                  Step 5   Expand Inter-Site Transport under Sites.
                  1. Open the IP folder and select DEFAULTIPSITELINK from the right pane.
                  2. Right-click and select Properties. Ensure that both sites have been added as entries in the Sites in this Site Link window.
                  3. Change the Replicate Every value to 15 minutes.

                  Assign Global Catalog and Configure Time Source

                  To assign Global Catalogs and configure the time source per your Unified ICM System Diagram and the Unified ICM/CCE & Hosted System Design Specification for your setup:

                    Step 1   Open Active Directory Sites and Services.
                    Step 2   Connect to the Domain Controller designated as the Global Catalog.
                    Step 3   Right-click NTDS Settings and select Properties. Select Global Catalog.
                    Step 4   Move FSMO roles, as indicated in your Unified ICM System Diagram and the Unified ICM/CCE & Hosted System Design Specification for your setup.
                    Step 5   The Forest Time Source defaults to the PDC Emulator, which is originally created on the Forest Root Domain Controller.

                    If the PDC Emulator moved to another Domain Controller, the Time Source must be redefined as either that server or an external Time Source might be utilized. Because the PDC Emulator moved to another Domain Controller, you need to redefine the Time Source as either that server, or use an external Time Source.

                    1. On the Server currently running the PDC Emulator, run the following command: Net time /setsntp: <DNS Name of Time Source>.
                    2. To synchronize a Server to the Time source, see the procedure available on the Microsoft Website (http:/​/​​kb/​816042).

                    Configure DNS Server on Forest Root Domain Controller

                      Step 1   Choose Start > Programs > Administrative Tools > DNS.
                      Step 2   Expand Hostname Tree.
                      Step 3   Expand Forward Lookup Zones.
                      Step 4   Select the machine name, then right-click and select Properties.
                      Step 5   On the Interfaces tab, select Listen on Only the following IP addresses and remove all but the visible machine address.
                      Step 6   Complete the configuration of AD Integrated Forward and Reverse Lookup Zones.
                      • Select the Unified ICM Domain zone name under Forward Lookup Zones, right-click and select Properties.

                      • On the General tab, for Allow Dynamic Updates, select Only Secure Updates from the menu.

                      • Only use the Zone Transfers tab when there is a Trust between this domain and another domain. You need to Transfer Zone updates from this AD Integrated Zone to a Standard Secondary Zone on the DNS Servers in the other domain. Select Allow Zone Transfers, then select only to the following servers and enter the IP Addresses of the DNS Servers in the other domain.

                      • To configure the required Reverse Lookup Zones, repeat Step 13 below for each Unified ICM domain level network within the Forward Lookup Zone.


                        Networks within a Forward Lookup Zone include all visible and private networks utilized within a DNS Zone. These networks define Reverse Lookup Zones relative to the Forward Lookup Zone.

                      Step 7   Under the Server Name, right-click on Reverse Lookup Zones and select New Zone.
                      Step 8   Within the New Zone wizard, select Active Directory Integrated.
                      Step 9   In the Reverse Lookup Zone window, select Network ID and enter the required number of octets for the Reverse Lookup Zone. The Reverse Lookup Zone Name is automatically entered.
                      Step 10   Repeat the Steps below for each Unified ICM domain Reverse Lookup Zone.
                      1. Select the Zone name under Reverse Lookup Zones, then right–click and select Properties.
                      2. On the General tab, for Allow Dynamic Updates, select Only Secure Updates from the menu.
                      Step 11   Manually complete the DNS Host and PTR records.
                      1. Manually enter the hostnames for the machines that house ICM nodes, as well as all NICs and Peripherals for which Web Setup requires hostname resolution, into the appropriate DNS Forward Lookup Zone.
                      2. On the DNS Server, right-click on the Forward lookup Zone Name and select New Host. (The hostname of this Root Domain Controller is already in the file.)
                      3. Add all Unified ICM hostnames (visible, visible high, private, private high, SAN) and their associated IP Addresses. Check the box to create an associated PTR Record (reverse lookup zone record).
                      4. Manually enter any Peripherals (ACDs/VRUs) and NICs accessed by the Unified ICM using hostname resolution in the Forward Lookup Zone.

                      Create Two-Way External Trust

                      You must create a two-way trust between the service provider and the customer domain controllers for each customer instance for Unified CCDM. Before you create a two-way external trust you must Create Conditional Forwarders and Create Forwarders in both the service provider domain controller and the customer domain controller.

                      Complete the following procedure to create a two-way external trust between the service provider domain controller and the customer domain controller.

                      Create Conditional Forwarders

                      Complete the following procedure to create conditional forwarder.

                        Step 1   Go to DNS Manager.
                        Step 2   Click the Conditional Forwarder.
                        Step 3   Right-click and select New Conditional Forwarder.
                        Step 4   Enter the DNS domain name.
                        Step 5   In the IP address field, click and enter the NAT IP address of the customer domain.
                        Step 6   Click OK and then click Apply.

                        Create Forwarders

                        Complete the following procedure to create forwarders.

                          Step 1   Go to DNS Manager.
                          Step 2   Right-click the domain name.
                          Step 3   Click Properties.
                          Step 4   Click the Forwarders tab and then click Edit.
                          Step 5   In the IP address field, click and enter the NAT IP address of the customer domain.
                          Step 6   Click OK and then click Apply.

                          Create Two-Way External Trust

                          Complete the following procedure to create a two-way external trust between the service provider domain controller and the customer domain controller.

                            Step 1   Under Active Directory Domains and Trusts, right-click the domain.
                            Step 2   Right-click Properties.
                            Step 3   Click the Trust tab and then click New Trust.
                            Step 4   Click Next.
                            Step 5   Enter the customer domain name in the Name field and click Next.
                            Step 6   Select the option External Trust and then click Next.
                            Step 7   Select the option Two-way Trust and then click Next.
                            Step 8   Select the option Both this domain and specified domain and then click Next.
                            Step 9   Enter the authentication user name for the customer and a password for the specified domain and click Next.

                            You must have the administrator privileges to create the trust.

                            Step 10   Select the option Domain-wide authentication and then click Next until you reach Confirm Outgoing Trust screen.
                            Step 11   Select the option Yes, confirm the outgoing trust and then click Next.
                            Step 12   Select the option Yes, confirm the incoming trust and then click Next.
                            Step 13   Click Finish.