The number of domains that your organization has depends on a series of business and technical
requirements that are outside the scope of Microsoft CRM. Before you deploy Microsoft CRM across your organization it is important that you understand the limitations of Microsoft CRM for users who are in an Active Directory mixed-mode domain.
The starting point for every Active Directory forest design is to have a single domain. Multiple domains should be defined only when business or technical requirements make it necessary. Most of the time, a single domain is the easiest to manage and requires the fewest domain controllers.
Chapter 6 Planning Microsoft CRM and Active Directory
Planning native mode
Some organizations may have complex domain topologies. Domains can be spread across several locations and separated by varying network connection speeds. A common domain topology is to have an empty Active Directory root domain that contains the Enterprise Administrators groups and nothing else. The child domains of the root domain may contain users and computers from different business units, physical locations, or subsidiaries, depending on the technical and business requirements of your organization. The following figure shows an example of a complex domain topology.
Complex Active Directory domain topology
Microsoft CRM will work in this kind of Active Directory environment, but there are some limitations. In Active Directory forests that are made up of several domains, you can switch each domain to native mode when all the Windows NT 4.0 BDCs have been upgraded or have been replaced by Active Directory domain
controllers. For Microsoft CRM, you need only one domain in native mode. The Microsoft CRM server and SQL Server must be in that domain.
For more information about Windows 2000 mixed and native mode, see Chapter 2, "Domain Upgrade,"
(http://go.microsoft.com/fwlink/?LinkId=51849) of the Domain Migration Cookbook.
Namespace
A namespace is a set of unique names for resources or items used in a shared computing environment.
Namespaces can be found in most systems—network operating systems, software tools, directories, Domain Name System (DNS), messaging systems, database systems, and so on. The names in a namespace can be resolved to the objects that they represent. For DNS, the namespace is the vertical or hierarchical structure of the domain name tree. For example, each domain label, such as host1, used in a fully qualified domain name (FQDN), such as host1.crm.adventure-works.com, indicates a CRM domain in the domain namespace tree.
Although there are no Microsoft CRM–specific requirements for the Active Directory namespace, the namespace is an important consideration when planning Active Directory.
For more information about namespace and namespace design, see Chapter 4, "Active Directory Design,"
(http://go.microsoft.com/fwlink/?LinkId=51924) of the Exchange 2000 Server Resource Kit.
Chapter 6 Planning Microsoft CRM and Active Directory
DNS
The resolution of names through DNS is central to the operation of Windows 2000 Server or Windows Server 2003, Active Directory, Exchange 2000 Server or Exchange Server 2003, and Microsoft CRM. Without correct name resolution, users cannot locate resources on the network. This includes Microsoft CRM servers. When you design the DNS namespace, it is very important to plan for Active Directory and to make sure that the larger namespace that exists on the Internet does not conflict with a company's internal namespace.
The recommended approach to DNS design is to design the Active Directory environment first and then support that design with the DNS structure. However, the DNS namespace might already be in place. In such a configuration, you should design the Active Directory environment independently and then implement it either as a separate namespace or as a subdomain of the existing namespace. If the namespace that you choose already exists on the Internet, it could cause name resolution problems for internal clients. Consider the following when you plan the DNS namespace:
● Identify the DNS namespace that you will be using for your domain. Identify the name that your company has registered for use on the Internet (for example, adventure-works.com). If your company does not have a registered name, but you will be connected to the Internet, you may want to register a name on the Internet.
● Use different internal and external namespaces. Internally, you could use company.tld or a
subdomain of the external name, such as corp.adventure-works.com. The subdomain structure could be useful if you already have an existing DNS namespace. Different locations or departments can be named with different subdomains to ease administration, such as <nameone>.adventure-works.com or <nametwo>.adventure-works.com.
● Make Active Directory child domains immediately subordinate to their parent domains in the DNS namespace. You can choose to create subdomains for departments or locations within your company. For example, leveltwo.levelone.corp.adventure-works.com.
● Put internal and external names on separate servers. External servers should include only those names that you want to be visible to the Internet. Internal servers should contain names that are for internal use. You can set your internal DNS servers to forward to external servers all requests that they cannot resolve. Different types of clients require different kinds of name resolution. Web proxy clients, for example, do not require external name resolution because the proxy server does this on their behalf.
● Do not overlap internal and external namespaces. Most of the time, the result of overlapping is that computers cannot locate resources because they receive incorrect Internet Protocol (IP) addresses from DNS. This is specifically a concern when network address translation is involved and the external IP address is in an unreachable range for internal clients.
● When you run the Active Directory Installation Wizard (Dcpromo.exe), configure a DNS server on the local computer and configure the forward lookup zones. The wizard examines the Transmission Control Protocol/Internet Protocol (TCP/IP) configuration on the computer and determines whether the computer is configured to use any DNS servers. If it is, the wizard queries the root servers. If the computer is not configured to use any DNS servers, the wizard queries the Internet root servers. If it cannot contact any root servers, the Active Directory Installation Wizard configures the local computer as a root server and creates the "." (root domain) zone.
● Make sure that you do not create root servers unintentionally. The Active Directory Installation Wizard can create root servers. This results in internal clients being able to reach external clients or parent domains. If the "." zone exists, a root server has been created. You may have to remove this for name resolution to work.
Note DNS is a critical component of Active Directory and, therefore, Microsoft CRM. DNS problems will cause Active Directory problems that can affect all users, including Microsoft CRM users. In an environment that uses Active Directory, you must plan and deploy DNS very carefully.
For information about Windows 2000 DNS, see the Windows 2000 Domain Name System Center
For information about integrating Active Directory, see the TechNet article, "Integrating Active Directory with an Existing DNS Structure (http://go.microsoft.com/fwlink/?LinkId=51925),"
For non-Microsoft-specific DNS information, see the book DNS and BIND (Liu, Cricket, Paul Albitz, and Mike Loukides (editor). DNS and BIND. Third Edition. O'Reilly and Associates, 1998.).