Our Guest Star series continues with Matt Parks, one of our first CRM MVPs and a key figure in the CRM community.
One of the many things that was introduced with Dynamics CRM 4.0 is the concept of server roles. Available only with the Enterprise license of Dynamics CRM, server roles provide quite a bit of flexibility is controlling what components of the solution run on each server in a multiple server deployment. However, with flexibility comes confusion.
With Dynamics CRM 3.0, the choice was quite simple when you had a multi-server deployment, there wasn’t one. You installed the app on the first server and chose to create your new databases. Then, on the other servers, you installed the same bits as on the first server, but you just pointed to the existing database. No decisions needed, but every server ended up doing the same types of processing. If you had a lot of workflow running on your system, the same servers that handled your end-user requests via the web pages also handled the workflow engine. As a result, user response times could be impacted when there was a heavy workload being handled by the workflow service.
Now, there are more options than most people need to care about. In my role, I interact with our various project teams working on systems that will support anywhere from a few hundred users to systems that will support several thousand users. A large number of our implementations have multiple servers more for redundancy and failover than they do for performance. In fact, if it weren’t for the need for failover, many of these would have a single server with CRM installed on it. They can exist just fine with the “all on one” installation and don’t need the extra complexity of worrying about the server roles. As user counts grow and increased complexities of the deployment come into play, splitting out the server roles onto separate hardware begins to make sense.
Available Roles
The following table lists the various server roles that are available with Dynamics CRM 4.0. The table also lists the Role Name used in the installation XML configuration file to choose the indicated role:
| Role | Config Role Name | Description |
| SRS Data Connector | SrsDataConnector | Run reports. |
| SQL Server | SqlServer | Installs the components required on the SQL Server where the Microsoft Dynamics CRM databases are maintained. |
| Application Server | Appserver | Runs the Web application server used by the end users. |
| Asynchronous Processing Service | Async | Process queued asynchronous events such as workflow, asynchronous plugins, bulk e-mail or data import. |
| Deployment Service | DeploymentService | Provides the web service end points for the Deployment Service SDK APIs. |
| Discovery Service | DiscoveryService | Provides the web service end points for the Discovery Service. |
| Help Server | HelpServer | Provides the Dynamics CRM Help. |
| SDK Server | SDKServer | Provides the web service end points for the core SDK APIs. |
The roles listed above can only be individually selected by doing a command line install and leveraging the <Roles> node. You may have noticed that the standard Application and Platform roles that you can select during the installation wizard are not listed. There is a reason for that. Those are not really roles, but are really role “groups”.
When you choose these groups, you are actually installing several of the roles from the above table. This capability makes installing easier for most situations by installing the core roles needed for the 2 most common server deployments. The following table lists which roles are installed when you choose these groups:
In general, these groups will serve the needs of most deployments that want to separate processing. The Platform Server group will be able to handle the tasks that operate in the “background”. Things like workflow, asynchronous plug-ins and bulk jobs. This separates out this “batch” processing from the Application Server machines allowing them to focus their power on servicing the end user requests.
One thing to notice is that the SDK Server is installed with both groups. This means that any server that has one of these groups installed can service standard SDK calls for the implementation. So, even though a Platform Server exists, web pages that have been developed that use the SDK APIs can be services on the same machine as the rest of the web requests. This minimizes web traffic across the servers and can be important when it comes to evaluating performance.
When would I split out the roles?
So, if many solutions can rely on a basic deployment, why would you want to separate the roles? There are definitely a few situations that come to mind where splitting out the various roles can make sense. Some of them that come to mind are listed here:
1) A deployment that is supporting several CRM Organizations leveraging the multi-tenant capability of Dynamics CRM 4.0. Focusing the different server roles on dedicated hardware can provide some better options for managing capacity within the data center and provides some better options for scaling out the infrastructure as the need arises.
2) You have a solution that includes a lot of integration with other systems that make heavy use of the CRM SDK calls. In this scenario, you might choose to install the SDK Server role on the integration server (or even a server hosting another application that makes CRM SDK calls). With this approach, the SDK calls can be made to the local SDK web service end point, eliminating a network hop to the CRM server.
3) Your solution includes heavy “batch” processing that would be handled by the Async server. When you have a high amount of processing that is being handled by the async service, and that service runs on the same machine as the web application, there will be competition for server resources between the web application and the async service. This can result in slower response times as the web application fights for resources. Moving the async processing to separate hardware allows the web server to focus its resources on servicing end user requests.
Summary
So, there are more options now than we had with Dynamics CRM 3.0. That can be both bad and good. I like the options that I now have for our larger clients. Especially those that have several internal deployments of CRM that leverage the multi-tenancy capabilities that CRM 4.0 provide us. But, as I’ve mentioned above, it’s just as important to make sure that you are using server roles for the right reasons and not just because they are there.
One really nice thing about the way they have put all this together is that it is easy to start small and add later. If you aren’t sure you need to split out the server roles, then don’t. Start with all your servers running all the roles. Then, over time, monitor the servers and determine if you need to split out the Platform Server Group from the Application Server Group (the most common next step). You can easily reconfigure your deployment to account for this later without incurring any downtime, all it takes is a little planning. You can also add additional servers to the deployment later as you decide to scale out the various components.
So, do your planning, but don’t get overwhelmed by the options. Remember, keep it simple in the beginning and add the complexity later if it’s needed.
Posts
