Export (0) Print
Expand All

Domain Controller Implementation


Applies to: Office 365

Topic Last Modified: 2014-05-30

Your organization must dedicate domain controllers in each Customer Forest to manage the service authentication load generated by Office 365 users. This requirement ensures that access to Office 365 services is not negatively impacted due to loads introduced by non-Office 365 applications. Dedicated domain controllers are required for each customer domain that contains Office 365 users, and for forest root domains, to ensure network latency requirements are met. If you are a SharePoint Online subscriber, special domain controller implementation options are available if you are unable to meet the maximum allowed network latency for the service.

To provide redundancy, your Customer Forest dedicated domain controllers must be installed in two physical locations for each continental region where Office 365 services are deployed. Continental regions with Office 365 data centers are North America (dedicated and ITAR-support plans) and Western Europe (dedicated plans only). Each location must contain dedicated domain controllers for forest root domains as well as for account domains containing Office 365 service users. The exact locations of the dedicated domain controllers are primarily driven by the requirements of your Office 365 service subscriptions as well as the physical location of your data centers.

The following table summarizes the allowed round-trip network latency between the Microsoft Managed Forest domain controllers and the Customer Forest domain controllers for each Office 365 service.


Office 365 Service Dedicated Plan Round-trip Network Latency Threshold ITAR-support Plan Round-trip Network Latency Threshold

Exchange Online

250 milliseconds

100 milliseconds

SharePoint Online

40 milliseconds

40 milliseconds

Lync OnlineLync Online

250 milliseconds

100 milliseconds

If your organization subscribes to the SharePoint Online service and does not have the ability to install dedicated domain controllers in two data centers which are within the 40 millisecond network latency threshold, you will be provided with the option to co-locate your dedicated domain controllers in an Office 365 data center where the SharePoint Online servers are deployed. See the Domain Controller Considerations for SharePoint Online Customers section for more information.

If you subscribe to Exchange Online or Lync Online without SharePoint Online, then the Customer Forest dedicated domain controllers must be deployed in two data centers that are managed by your organization and located in the same continental region as the Exchange Online and Lync Online servers. The option to co-locate dedicated domain controllers in an Office 365 data center is only available if you subscribe to SharePoint Online.

Customer Forest dedicated domain controllers must be configured as follows:

  • Dedicated domain controllers must run on a version of Windows that supports increased MaxConcurrentApi values to support the volume of NTLM pass-through authentication generated by Office 365 users. The minimum supported operating system version is Windows Server 2008 with Service Pack 2 and the hotfix available at KB975363. This hotfix also may be installed on Windows Server 2008 R2 and is included in Windows Server 2008 R2 Service Pack 1. Windows Server 2012 and above also are supported.

  • The MaxConcurrentApi registry entry must be set to 150.

  • NetBIOS over TCP/IP must be disabled on network interface cards.

  • Dedicated domain controllers must provide global catalog services to enable clients to authenticate for logon.

  • Flexible Single-Master Operations (FSMO) roles must not be held by dedicated domain controllers. Dedicated domain controllers must not be used beyond the scope of user authentication.

Installing Customer Forest dedicated domain controllers as read-only domain controllers (RODCs) may seem attractive to your organization, especially when co-location in Microsoft data centers is required. For example, administrative account passwords are not stored on RODCs and sensitive attributes are not replicated to RODCs because of the filtered attribute set (FAS). However, Microsoft does not support use of RODCs as Customer Forest dedicated domain controllers for the following reasons:

  • RODCs do not cache passwords for trusted domain objects (TDOs) and are therefore of limited use in cross-domain scenarios.

  • Some authentication-related operations can be serviced only by writeable domain controllers.

  • Placing more than one RODC in the same Active Directory site leads to increased replication traffic over the WAN.

The main technical barrier to using co-located RODCs is that RODCs never cache passwords for a trusted domain object (TDO). Therefore, writeable domain controllers are required to service cross-domain requests that need access to TDO passwords, such as setting up a secure channel between domain controllers in trusting and trusted domains, as well as encryption and decryption of Kerberos Ticket Granting Service (TGS) requests. In the Office 365 environment, this means that domain controllers in a managed environment would not be able to establish secure channels or pass through NTLM authentication requests to RODCs in the customer environment. This effectively rules out the use of RODCs because a significant portion of authentication takes place using NTLM.

A further consideration is that dedicated Active Directory sites in the Customer Forest typically contain more than one domain controller to handle the authentication load and provide redundancy. Because RODCs perform inbound replication only from a writeable domain controller, they cannot act as replication bridgeheads, and therefore Active Directory data would have to be replicated over the WAN to each co-located RODC.

It is your responsibility to ensure that your dedicated domain controllers have adequate capacity to handle the authentication load generated by Office 365 users. Office 365 personnel are not able to log on to Customer Forest domain controllers or monitor their performance. You must monitor your authentication load and, if it is required, add additional capacity for domain controllers to sustain the load.

The TechNet article Capacity Planning for Active Directory Domain Services provides generic information regarding performance monitoring and sizing of domain controllers, and can assist you in determining the configuration of domain controller hardware for components not explicitly mentioned below (for example, processor, disk, and network components).

Based upon working closely with existing Office 365 customers, Microsoft has developed a set of requirements and guidelines in order to assist you in the initial capacity planning of an Office 365 Dedicated plan deployment. The following requirements apply to each physical location where Customer Forest dedicated domain controllers will be installed.

  • A minimum of two (2) dedicated domain controllers is required for each account domain that contains Office 365 users.

  • A minimum of two (2) dedicated domain controllers is required for the forest root domain.

The recommendations below provide additional guidelines to assist you in initial capacity planning for large forests. You also should factor future growth plans into initial sizing efforts.

  • For each Customer Forest domain that contains more than 50,000 Office 365 users, it is recommended to add one (1) dedicated domain controller (per location) for every 25,000 Office 365 users. For example, if a domain contains between 50,000-75,000 users, deploy three (3) dedicated domain controllers; if a domain contains 75,000-100,000 Office 365 users, deploy four (4) dedicated domain controllers, and so on.

  • For forest root domains, it is recommended that the minimum number of dedicated domain controllers in the forest root domain equal the number of dedicated domain controllers in the largest child domain (that is, the child domain with the highest number of dedicated domain controllers). For example, if the largest child account domain has three (3) dedicated domain controllers, the forest root domain should also have a minimum of three (3) dedicated domain controllers. The purpose of this recommendation is to ensure that there is a one-to-one secure channel mapping between forest root domain controllers and child domain controllers. The same principle applies for other parent/child domain relationships within the Customer Forest.

Your organization is responsible for ensuring that secure channel mappings from trusting to trusted domain controllers in the Customer Forest are evenly distributed. As described in Microsoft TechNet, the Nltest tool can be used to reset secure channels on specific domain controllers.

For optimal performance, dedicated domain controllers should have enough memory (RAM) to contain the entire Active Directory database file (NTDS.DIT) plus fulfill the requirements of the operating system and other installed software such as antivirus and systems management agents. Typically, allocating memory based on the size of the NTDS.DIT file plus 4-6 GB is sufficient.

In order to ensure that Microsoft Managed Forest domain controllers use the Customer Forest dedicated domain controllers for authentication, your organization must create Active Directory sites in the Customer Forest with the same names as the Active Directory sites in the Managed Forest and configure the dedicated domain controllers to service the new sites. A typical Office 365 deployment requires that you create two sites in Active Directory. Microsoft will provide a list of sites for you to create as part of the Office 365 deployment process.

Creating matching Active Directory site names enables efficient domain controller location due to the way the Net Logon service uses DNS records as part of the domain controller locator process. To locate a domain controller in the Customer Forest, the locator on a Microsoft Managed Forest domain controller initiates a site-specific DNS query. The site name that is used for the query is the name of a site in the Microsoft Managed Forest. However, the domain part of the DNS query uses the Customer Forest name. If the site-specific record does not exist because the site name portion does not match, the DNS server for the Customer Forest sends a response to the DNS server in the Microsoft Managed Forest indicating that an appropriate match cannot be found. When this occurs, the Microsoft Managed Forest domain controller sends another DNS query that does not specify any site information.

After an SRV record is returned, the Net Logon service on the Microsoft Managed Forest domain controller will send an LDAP UDP search request (an LDAP ping) to the Customer Forest domain controllers that registered the records. The first Customer Forest domain controller to respond will be used for subsequent operations. If a site-specific record is not returned, this could result in a Customer Forest domain controller being chosen in a distant location with high latency and therefore negatively impact the service.

As described in the Configuration of Customer Forest Dedicated Domain Controllers section, a subscription to the SharePoint Online service requires network latency between your data centers and the Office 365 data centers of no greater than 40 milliseconds. Microsoft will assist with obtaining network latency measurements to share with you. Test results either before or after the deployment of SharePoint Online that indicate the latency threshold is consistently exceeding the threshold maximum will require the implementation of an alternative domain controller design for your organization.

If you cannot produce a plan within five (5) business days to resolve the increased network latency, Microsoft will initiate the design and deployment of co-located domain controllers for your use at the specific Microsoft data centers providing the SharePoint Online service. The design and deployment process is estimated to require 8 - 10 weeks to implement.

The following conditions apply to network latency mitigation efforts:

  • If there is a need to co-locate customer domain controllers, Microsoft will provide four (4) physical servers for a customer to configure as co-located domain controllers. The servers are procured by Microsoft and meet the Microsoft hardware design standard. Your organization will be responsible for configuring each domain controller as either a virtual server (using the virtualization technology of their choice) or as physical domain controller. We strongly recommend the use of a virtualization technology (for example, Microsoft Hyper-V) to increase the density of domain controllers installed per physical server—especially if multiple domains must be accommodated. The table that follows describes implementation options for the domain controllers.

  • If Microsoft procures hardware as a result of a decision made to co-locate customer domain controllers and the network issue is resolved before the hardware is delivered, Microsoft will proceed to deploy the servers after delivery and maintain them in the data center as backup servers.

  • In a scenario where some domain controllers do not meet the latency requirement while others do, the domain controllers that do not meet the criteria must be co-located in a Microsoft data center. The domain controllers that meet the latency criteria do not need to be co-located.





Appropriate Customers

Customer-deployed virtualization (recommended)

Customers deploy domain controllers on a virtualization technology of their choice and manage both the virtual machines (VMs) and the host servers.

Microsoft provides four physical servers: two in the primary and two in the secondary data center.

Customers deploy the virtualization technology of their choice.

Customers manage the host machine and VMs.

Customers deploy their own virtual design and divide host resource among VMs as needed to meet proper authentication requirements.

Customers with multiple domains and/ or forests.

Customers who want to run their choice of virtual technologies based on their own design.

Customer-deployed with no virtualization (not recommended in most circumstances)

Customers deploy domain controllers directly on physical hardware

Microsoft provides four physical servers: two in the primary and two in the secondary data center.

Customers manage the server.

Customers have only one Active Directory domain per server.

Customers that have more than one Active Directory domain with users using Office 365 services will incur additional hardware costs and monthly fees.

Customers with very large domain controllers, and a single Active Directory domain.

Note: This option is not recommended for any customer with more than one Active Directory domain, because this configuration would require additional servers to be deployed.

  • The domain controller co-location requirement is not intended for authentication redundancy or to mitigate the loss of connectivity to the customer network.

  • You will be responsible for operational management of the domain controller servers. Microsoft will provide hardware and data center support for the purpose of hardware life-cycle management or to address a specific request from the customer for support assistance. Microsoft will not at any time have administrative access to the customer co-located domain controllers.

  • For each physical server that is required in excess of the four (4) provided by Microsoft, you will incur a monthly service charge. The charge covers hardware, hosting costs, and break-fix support. An additional monthly service charge may be incurred if data center resources in excess of those provided for a base Microsoft hardware configuration are required.

Microsoft Responsibilities

  • Assist your organization with identifying network latency degradation between Microsoft domain controllers and customer domain controllers.

  • Assist your organization with resolution of network latency issues, if requested, by providing network monitoring data as your organization directs issue resolution.

  • If you cannot resolve the network latency issue within five (5) business days, Microsoft will address the following:

    • Arrange to provide four (4) co-located physical servers as dedicated domain controllers for your organization’s use.

    • Configure integrated lights-out (iLO) remote management for the domain controller servers and connect the servers to your VLAN.

    • Provide hardware break-fix support for the newly installed domain controller servers at your request.

Customer Responsibilities

  • Monitor network latency between your on-premises domain controllers and Microsoft domain controllers.

  • Immediately address any network latency increase that exceeds Microsoft defined thresholds for domain controllers located on-premises or produce a plan to remediate the problem within five (5) business days.

  • If the network latency issue cannot be resolved within five (5) business days, address the following:

    • Collaborate with Microsoft to develop and implement a solution to co-locate dedicated domain controllers at specific Microsoft data centers.

    • On the dedicated domain controller hardware provided by Microsoft, install and configure each domain controller operating environment (that is, a dedicated operating system or a virtualized configuration).

    • Acquire licenses for all software to be installed on the co-located domain controllers.

    • Monitor the performance of the co-located domain controllers to ensure that the number of domain controllers is sufficient to meet the authentication demands of the Office 365 services.

    • Update the Active Directory sites and subnet configuration in each Customer Forest.

    • Manage the domain controllers remotely and provide monitoring, antivirus updates, and software updates for all physical servers. The same management responsibilities apply if you choose to run the domain controllers on a virtualization technology.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft