Microsoft Dynamics 365 supported configurations
Updated: December 9, 2016
Applies To: Dynamics 365 (on-premises), Dynamics CRM 2016
The deployment architecture you will use depends on your business needs. Examples are provided here for planning a Microsoft Dynamics 365 deployment on four representative computer system architectures: a single-computer server deployment, a two-server deployment, a five-server deployment, and a multiple-server deployment involving a minimum of six servers. These deployments are discussed in detail in Microsoft Dynamics CRM 2011 supported configurations.
Additionally, this section describes the supported network, domain, and server configurations for Microsoft Dynamics 365, which supports multiple forest and domain topologies.
The Active Directory requirements are as follows:
The computers that run Microsoft Dynamics 365 Server roles and the computer that runs SQL Server, where the Microsoft Dynamics 365 databases are located, must be in the same Active Directory domain.
The Active Directory domain where a Microsoft Dynamics 365 Server role is located must run in one of the domain modes listed in the Active Directory modes topic.
The user account that is used to run a Microsoft Dynamics 365 service must be in the same domain as the computer that is running the Microsoft Dynamics 365 Server role.
The Microsoft Dynamics 365 security groups (PrivUserGroup, SQLAccessGroup, ReportingGroup, and PrivReportingGroup) must be in the same domain as the computer that is running Microsoft Dynamics 365 Server. These security groups can be located in the same organizational unit (OU) or in different OUs. To use security groups that are located in different OUs, you must install Microsoft Dynamics 365 Server by using an XML configuration file and specify the correct distinguished name for each pre-existing security group within the <Groups> element. More information: Sample server XML configuration file for installing with pre-created groups
Direct user account membership in the Microsoft Dynamics CRM privusergroup security group is required and group membership nesting under privusergroup currently is not supported. Granting membership to privusergroup through another security group can cause system-wide failures in the CRM web application and reporting features. For example, if you add a security group named mycrmprivgroupusers to privusergroup, members of mycrmprivgroupusers will not resolve as privusergroup members. This includes the CRMAppPool or the SQL Server Reporting Services service identities.
For users who access Microsoft Dynamics 365 from another domain and are not using claims-based authentication, a one-way trust must exist in which the domain where the Microsoft Dynamics 365 Server is located trusts the domain where the users are located.
To add users to Microsoft Dynamics 365 that are not authenticated by using claims-based authentication, a two-way forest trust is required.
For small user bases, a Microsoft Dynamics 365 Server can be deployed in a single-server configuration, with Microsoft Dynamics 365 Server, SQL Server, Microsoft SQL Server Reporting Services, and optionally Microsoft Exchange Server installed and running on the same computer.
Single-server deployments are not recommended for best experience in application performance and disaster recovery.
There is one limitation to single-server deployments: the server where Microsoft Dynamics 365 Server is installed cannot also function as a domain controller. If the computer is a member server (not functioning as a domain controller), you can deploy the Microsoft Dynamics 365 Server Full Server role on a single Windows Server that is also running the additional required products.
Running Microsoft Dynamics 365 Server in a production environment on an Active Directory domain controller is not supported.
To reduce IT administration overhead, consider running Microsoft Dynamics 365 in the cloud. More information: Microsoft Dynamics
© 2016 Microsoft. All rights reserved. Copyright