One of the choices  when deploying Microsoft Dynamics 4.0 is whether or not to separate server roles.

 

When you install Dynamics CRM on a server, the application layer (web server, CRM application) and the platform layer (asynchronous service, discovery service, sdk) run on the same server. 

 

There are several reasons that you would want to separate server roles.  For example, if you have a heavy quantity of asynchronous activity, such as imports, workflows or plugins, you don't want to affect availability of the application, and you don't want asynchronous operations to have a long backlog and slow down the amount of time it takes for new asynchronous operations to be processed.

 

Traditional Approach

 

The traditional way to separating server roles with Dynamics CRM 4.0 Enterprise was to select the separate server roles option when installing.  This gives you the option to install the roles that you want on a server, so you can have one server be the application role, and have another be the platform role, for example.

 

Complexity

 

Before you do this, you should be aware that going with the separate server roles may introduce some complexity into your environment.  When everything runs against one server, everything uses the same server URL; however, if the platform role is separated,  things that hit the discovery service, such as the outlook client, email router, and custom code will need to hit the URL of the platform server, not the application server URL, and having two different addresses may add some confusion for certain users.  If you elect to deploy your environment Internet facing, or IFD, so you have CRM available to people not on your network, there is a lot of complexity and frankly this option is not very well documented in the IFD scenarios documentation.

 

IFD and Separate Server Roles

 

if you have separate server roles, you will need to expose both the app server web site and the platform server website externally.  You will need to run the ifd tool on both the application and the platform server--this is not documented in the ifd scenarios document, but is required if you want external users to be able to configure Outlook clients in ifd mode, You will need to have ssl certificates on both the application and platform server, which will cost you extra.  the IFD scenarios document doesn't say this, but you will have to have your platform server URL be organization specific--if your CRM URL is myorg, for example, you will need the URL to be something like  myorg.platform.company.com.  again, not documented, but CRM will expect the org name to be in the Url when you configure the Outlook client.  Users will have to configure their outlook clients using the platform server URL, not the CRM application URL.  The reason for that is the outlook client connects to the discovery service during configuration, and the discovery service is part of the platform role, not the application.  having a different CRM URL for outlook client and web client can be very confusing to some users.

 

An Easier Approach

 

As we have seen, the traditional approach to separating server roles may add some complexity to your CRM deployment; however, that doesn't men you shouldn't do it.  Rather, there is another approach that achieves the same goals.

 

This approach is to install the full CRM application on both servers, both pointed at the same CRM databases.  On server A, stop the asynchronous service, and on server B, start the asynchronous service.  Drive all of your users to the URL of server A.

 

The end result is that, like with separate server roles, you have all application traffic handled by server A, and all asynchronous load handled by server B, but you avoid all of the complexity of traditional separate server roles.  Users will be able to use the same URL for the web and outlook interfaces, and Internet facing deployment will be much more straightforward, requiring only on URL or ssl cert.

 

This is the approach that we recommendit will make your life much easier.

 

Thanks To Alex Fagundes at Power Objects for providing input for this post.