Basic post installation tasks for CRM 2016

Post installation tasks for Microsoft Dynamics CRM 2016

This post will be all about post installation tasks for Dynamics CRM 2016. It's a collection of tips and tricks I've learned and used over the years. I'm assuming that you've already installed CRM 2016 on your servers, but in case you haven't and need some tips check out my previous post.

Prerequisites

As mentioned, I'm assuming you already installed MSCRM 2016 on your servers, in addition I assume you have some basic understanding of the related technologies. Because I've been a newbie and know how frustrating it can be to look up related information I've included links to good resources for learning the technologies as we bump into them.

I also assume that you will be actually reading this post, because you won't necessarily understand the context and ramifications if you cherry pick answers from inside the document.

Software

SQL Server Reporting Services data connector

In yesterday's post I went through the installation of a single server CRM 2016 deployment, and finished off on installing the actual CRM Server application. The first part today will be to install the SRS Connector for Dynamics CRM 2016.
To install this package you need to locate your installation media and copy the folder named "SrsDataConnector" over to the server running SQL Server Reporting Services (SSRS).


Run the SetupSrsDataConnector.exe file to start the installation, and head through the steps:

1. I recommend getting the updates for the Dynamics CRM installation. If there's any bugs in the installation then you might get updated installation files that fixes these. 
2. Read throught the important license requirements and rock on through. The first selection is which SQL Server is used to store the MSCRM_CONFIG database, if you can't find it on the list then it's either because SQL Server Browser isn't running or some port exclustions.
3. On the next screen you choose which SSRS Instance you want to use. Remember that SRS Data Connector can only be installed ONCE on each Windows Server, so even if you have multiple SSRS instances on one server you can only install the connector for one deployment.
4. You arrive at the system check screen, which is all greens (if not, check the next step). Hit next and install that connector.
   
5. If you receive the following error it means that SSRS isn't running in the context of a service account. Perform the steps described in this article (technet) and retry the installation.
   

CRM Trace viewer (PFE CRM Trace Tool)

Now this isn't strictly required or needed, but if you have to enable tracing in the future then I strongly advice using a good tool to read the trace logs. Trace logs are typically large and include a long call stack. Even the most seasoned developer can miss vital clues in large text files, so having a reader which allows you to filter and sort information can shorten an arduous debugging session by hours, or even days.

Head over to codeplex and get this viewer, used by Microsoft's MVPs when they're out on a mission.

Internet Information Services (IIS)

By default, MSCRM only installs the bare minimum services needed to run. If this is a development/test environment then you'll probably want to add some additional features to the webserver. Head over to server management and hit the Add Roles button to get the "Add Roles and Features Wizard". Rock on through until you get to the Server Roles window, and add the features you want to add. Heres a collection of features I like to add in addition to the default ones:

• Web Server (IIS)
• Web Server
• Health and Diagnostics
• HTTP Logging (great for debugging infrastructure-related issues, slow loading modules, etc
• Logging tools
• Request Monitor (do not use this in production without checking if you have consent. Monitoring user activity might infringe on privacy laws)
• Tracing (great for getting deep-down into the specific requests and performance related issues)
• Management Tools
• IIS Management Scripts and Tools (I love to do stuff in powershell, it allows me to save those little snippets and reuse them later. Also, more and more documentations and how-to guides gives you powershell commands to fix issues, so you might want to have IIS snappin available)

Configuration changes

Now over to the good stuff, configuration changes that I have found to help out quite a bit. I'll go into the simple configuration tips I've learned and give some details into what you should read up on if you're unsure about the settings and tools used. Performance tuning is reserved for another post, because that a whole chapter in itself.

Internet Information Services (IIS)

Didn't we just do this one? Well yes, but that was only additional features to the web server role, now we're gonna look at specific configuration options in IIS. Open up the IIS admin console (either from Start or run "inetmgr.exe").

1. First out, we're gonna go check the recycling settings. Navigate to the application pools on your server, find the one called CRMAppPool and select it. Click on the "recycling" link on the right hand side to bring up the recycling settings.
   
2. In the recycling settings, uncheck the box marked with "regular time intervals (in minutes)". This is the default IIS setting, which means the application pool will recycle every 29 hours. You probably don't want the application pool to recycle in the middle of the work day, and that will eventually happen with an odd-numbered time interval. I prefer to set it at night, maybe 2 or 3 AM. Just make sure you're not gonna have any integrations depending on the CRM Web Services running at the same time. Rock on through and complete the wizard.
   
3. Next up, click the "advanced settings..." link found just beneath the recycling setting in step #1. Locate the settings for "Idle Time-out (minutes)". This setting specifies how long the worker process, that is the process CRM is running in, can be idle before it gets terminated. The CRM installation has set this to 1500 minutes, or 25 hours. That means the worker process will be terminated if there are no activity in the specified timespan. You can leave it at this value, but I would recommend you set it to 0 (never) and rather restart the application pool manually if need be (recycling and restarting an application pool is not the same thing by the way).
   
4. If you want to you can repeat these steps for the deployment application pool as well, but you probably won't be using that service that much so it's fine to leave it with the defaults, unless you need to integrate with these services regularly (for example if your developers use it alot or if you intend to integrate with FIM)
5. Head over to "Sites" when you're done, and look at the list of sites available. For each of the sites (you might just have the one), navigate into it and locate the "Bindings..." link on the right hand side.
   
6. Open up the bindings and look for any TCP port 808 bindings. If you have any of those: delete them. The CRM services depend on this port number to work as expected, especially if you have sandbox plugins. If there are specific applications which need to have this port number, they should not be hosted on your CRM servers (or vice versa)
   

Antivirus settings

To make sure that CRM performs at it's best, you should exclude some directories from the antivirus scanning/monitoring. I won't be going into details for each possible antivirus application how to do this, I can only advice you to google (or bing) "<your antivirus application> add exclusions"

There's an excellent blog post from crminthefield on msdn regarding antivirus exclusions for Dynamics CRM found here (msdn).

The article is somewhat dated, but the information is still valid.

If you plan to/suspect you have to enable tracing in the future, you should also exclude the trace folders (configurable from powershell, but that's for another session called debugging).

The wrap-up

This started to get kind of lengthy, so I stopped at the simple configurations you can do to make your CRM environment run smoothly. The CRM installation has grown a lot since 2011 was introduced (first edition on IIS7+), and you no longer need to enable "authpersistnonntlm" og stuff like that. There's still a few options that can be done to tune the system, but you're pretty much done right now.

I'll be writing another, lengthy blog post on optimization/tuning in the future, so be sure to come back and check it out.

Tomorrow I'll be doing a blog post on backup/restore of your CRM environment, and for all you cowboys out there; it's more than just backing up a database.