• What happens when we delete a record in CRM after configuring the Attachment Management solution – it deletes the associated attachments on the blob storage too.

• What are the ways of authenticating the Attachment Management solution with blob storage – this is completely and only based on SAS token at the moment.

• Does the solution provide image previews – yes, it does, like below. You could also have previews of word docs, ppts, xls and pdfs.

• Can we use this as a data source to pull records from blob storage – yes, we can use it like the way we pull any records from CRM using GUIDs (for example: https://<storage account name>.blob.core.windows.net/<container name>/<GUID>_<filename>). We will have to mitigate any authentication challenges though, if any.

• What happens to the existing attachments in the Dynamics 365 after configuration of attachment management solution - it starts moving the attachments to the blob automatically, but due to Dynamics 365 limitation of moving 140 records at a time, we would need to click on Move to Blob button, after every 140 records are moved. However, there is a solution to automate that too, which is using the logic apps, available on Github: https://github.com/anilvem1/LAMoveCRMAttachmentsToBlob . This will take care of the 140 limitations and move all the existing attachments automatically to the blob storage. Once all the existing attachments are moved, we don’t have to worry about moving the attachments manually or by using the logic apps, the Attachment Management will take care of moving all the attachments thereafter automatically. The logic apps solution which is built by one of the Microsoftians is required only initially to move all the existing attachments to the blob storage. Once all the attachments are moved, Attachment Management will handle attachments automatically by its own.

• Who could configure the attachment management solution in CRM – security is controlled by the Dynamics 365 security model which by default allows system administrators and customizers to make any changes, however this could also be controlled further by controlling the security roles in Dynamics 365.

• What happens once the attachments are moved to blob storage – Dynamics 365 Customer Engagement holds a reference to the moved attachments but the body (actual attachments) moves to the blob storage, freeing up the storage in the Dynamics 365 Customer Engagement organization database.

Dynamics CRM Server-Side Sync allows you to capture logs which could help in troubleshooting any issues with users mailboxes in regards to the Server-Side Sync. The alerts are shown on the Alerts wall or the Alerts section in the mailbox or email server profile records.

The following table shows how to view the alerts and the actions you can take on these alerts.

Now I believe you would have got an idea on what is going wrong and once you decide to uncheck the Check Boxes for Warnings and Information those data would not be captured thereafter. However, you still need to clean the database with these unwanted data, isn’t it? So, you could use the Bulk Delete Job to clean the data like this.

• Login to Dynamics CRM Application as an administrator and then navigate to Settings-->Data Management

• Then click on Bulk Record Deletion

• Click on New-->Click on Next.
• In ‘Look For’, select Traces

• Select Level and then make sure to select set it Equals to Information and Warning

• Click on Ok

Then select the Regarding Object Type (In my example, I was dealing with a lot of data in regards to the Email Server Profile and Mailboxes).

Give this view a name and save it for future usage. If you wish you could also remove or add a few columns to select your data precisely.

Hope this helps and please do share your comments or feedbacks.

• Although you can upgrade any version of Dynamics CRM 2015 for Outlook to Microsoft Dynamics CRM 2016 for Outlook, we recommend that you apply the latest update rollup before you begin the upgrade. Microsoft Dynamics CRM 2015 updates and hotfixes
• Upgrade all Microsoft Dynamics CRM 2015 servers and organizations to Microsoft Dynamics CRM Server 2016.
• Upgrade Dynamics CRM for Outlook to Microsoft Dynamics CRM 2016 for Outlook to have the Go offline capability.

• Migrate by using a new instance of SQL Server. We recommend this option for upgrading Microsoft Dynamics CRM Server. Although this option requires a different computer for Microsoft Dynamics CRM 2016 and a different instance of SQL Server, it provides the least amount of potential downtime for users since the existing deployment can remain functioning until the upgrade is completed and verified.
• Migrate by using the same instance of SQL Server. This option requires a different computer for Microsoft Dynamics CRM Server 2016, but will upgrade in-place the configuration and default organization databases using the same instance of SQL Server. If issues occur during the upgrade, you must roll back to the previous Microsoft Dynamics CRM version to avoid significant downtime.
• In-place upgrade. Although this option doesn’t require a different computer for Microsoft Dynamics CRM Server 2016 or a different instance of SQL Server, it poses the greatest risk if upgrade issues occur because a roll back and reinstall of the previous version of Microsoft Dynamics CRM will be required to avoid potential downtime.

• Always run a full backup of the Microsoft Dynamics CRM databases before you upgrade to a new version of the product. For information about database backups, see Back up the Microsoft Dynamics CRM System.
• During an in-place upgrade, only the organization that you specify to upgrade is upgraded. If the deployment contains additional organizations, those organizations are disabled and are not upgraded. You must upgrade those organizations using the Import-CrmOrganization Windows PowerShell command or by using Deployment Manager. More information: CRM 2016 PowerShell Reference and Import an organization

• We recommend that you apply the latest Microsoft Dynamics CRM updates before you start the upgrade.
• Meet all requirements as specified under Microsoft Dynamics CRM Server hardware requirements and Software requirements for Microsoft Dynamics CRM Server.
• Log on to your domain as a user who has administrator-level permission.
• SQL Server replication isn’t supported with Microsoft Dynamics CRM. If you run SQL Server replication, disable it.
• Uninstall Microsoft Dynamics CRM Connector for SQL Server Reporting Services if it’s installed on the same computer where Microsoft Dynamics CRM Server is installed. More information: Uninstall or repair Microsoft Dynamics CRM Reporting Extensions

1. In the folder where the Microsoft Dynamics CRM files are located, go to the Server\amd64 folder, and then double-click SetupServer.exe.
2. On the Welcome to Microsoft Dynamics CRM Server Setup page, we recommend that you select Get updates for Microsoft Dynamics CRM to make sure that Setup has the most recent installation files. Click Next. After Setup is done checking for updates, click Next again.
3. Note: For the Get updates for Microsoft Dynamics CRM functionality to work you must, have an Internet connection on the computer where Setup is running. Enable Microsoft Update for “other Microsoft products” on the Windows Server computer where Microsoft Dynamics CRM Server Setup is running.
4. On the Product Key Information page, type your product key in the Product key boxes, and then click Next.
5. On the License Agreement page, review the information and if you accept the license agreement, click I accept this license agreement, and then click I Accept.
6. If Setup detects that components are missing, the Install Required Components page appears.
   • If you have already installed the required components, this page won’t appear.
   • If you haven’t installed the required components listed, you can install them now. Click Install. When the components are installed, the status column changes from Not Installed to Installed, and you can click Next to continue.
   • Note: If you’re prompted to restart the computer, do so, and then start Setup again.
7. On the Upgrade to Microsoft Dynamics CRM 2016 page, you can select an organization to upgrade or leave the choice <None> so that no organizations will be upgraded during Setup. Before you select an organization, consider the following:
   • Notice that any organization not upgraded will become disabled after the upgrade is complete. To upgrade organizations after Setup is complete, use the Import-CrmOrganization Windows PowerShell command. Alternatively, you can use Deployment Manager.
8. On the Specify Service Accounts page, Setup will add the service accounts used for the Microsoft Dynamics CRM Server services. You can use the existing service accounts or specify new ones. For information about the permissions required to run these services see Minimum permissions required for Microsoft Dynamics CRM Setup and services.
9. If you want to use server-side synchronization and/or Dynamics CRM for Outlook for the deployment, leave this box blank. More information: Integrate your email system with Microsoft Dynamics CRM
10. Otherwise, on the Specify E-mail Router Settings in the, Email router server name box, type the name of the computer where the Email Router will be installed. This computer will route Microsoft Dynamics CRM email messages. If you leave the box blank but decide later you want to use the Email Router, you must add the computer where the Email Router Service is running (part of the Asynchronous Service) when you use Network Service, or if you use a domain user account, the account to the PrivUserGroup security group.
11. Click Next.
12. On the Select Microsoft Update Preference page, select whether you want to use Microsoft Update for checking for updates for your Microsoft products, and click Next. We recommend that you use Microsoft Update to check for updates because this helps keep your computer up-to-date and secure. For more information about the legal terms and privacy with Microsoft Update licensing, see Windows Update FAQ.
13. The System Checks page appears. This page is a summary of all requirements and recommendations for a successful installation. Errors must be resolved before installation can continue. If no errors, or only warnings appear, you can continue with the installation. To do this, click Next.
14. The Service Disruption Warning page appears. This page lists all services that will be stopped or restarted during Setup. Verify the suitability of the services that will be stopped or restarted, and then click Next.
15. Review the Ready to Upgrade the Application page, and click Back to correct any errors. When you are ready to continue, click Upgrade.
16. When Setup completes successfully, the Microsoft Dynamics CRM Server Setup completed page appears. If the Reporting Server instance that you specified during this Setup points to the local computer where Microsoft Dynamics CRM is installed, Setup provides an option to invoke Microsoft Dynamics CRM Reporting Extensions Setup.
17. For a full server deployment running on the Microsoft SQL Server Reporting Services computer, select the Launch Microsoft Dynamics CRM Reporting Extensions Setup check box to install Microsoft Dynamics CRM Reporting Extensions. Click Finish.

• After you upgrade, you must install the Microsoft Dynamics CRM Reporting Extensions to create, run, and schedule reports in Microsoft Dynamics CRM. For instructions, see Install Microsoft Dynamics CRM Reporting Extensions in this guide.
• You can’t install the Microsoft Dynamics CRM Reporting Extensions before you install or upgrade Microsoft Dynamics CRM Server.
• If you had Language Packs provisioned in your deployment, to continue to use multiple languages, upgrade each language pack to Microsoft Dynamics CRM 2016, and then provision them. More information: Upgrade and enable a Language Pack
• Notice that Setup turns on HTTP compression on the server that’s running IIS where the web application is installed. If you use another method to compress HTTP communications, you may want to turn this feature off after Setup completes. To do this, start Internet Information Services (IIS) Manager, choose the website, double-click Compression, and then clear the compression check boxes.

1. If you have additional network load balanced servers or Microsoft Dynamics CRM server roles installed on other computers, upgrade or uninstall and reinstall Microsoft Dynamics CRM on those servers as described in Install Microsoft Dynamics CRM Front End Server and Back End Server roles.
2. Install the Microsoft Dynamics CRM Reporting Extensions. You must install Microsoft Dynamics CRM Reporting Extensions before you can import and upgrade organizations not upgraded during Microsoft Dynamics CRM Server Setup.
3. If you had Language Packs provisioned in the deployment, download and install Microsoft Dynamics CRM 2016 Language Packs for the languages that you want. More information: Upgrade and enable a Language Pack
4. Install the latest update rollup packages/service packs.
5. If needed, import organizations. During import, each organization will be upgraded. To do this, use the Import-CrmOrganization Windows PowerShell command. Alternatively, you can use Microsoft Dynamics CRM Deployment Manager.
6. In Microsoft SQL Server Reporting Services Report Manager, re-create any custom data sources under the OrganizationName_MSCRM folders.
7. Some organization data is encrypted using encryption keys. These keys should be copied as part of your failure recovery procedures. More information: Data encryption
8. Verify that the system jobs and workflows are running.

1. Check with the business and try to understand the actual need of the feature. Do they really need this?
2. There could be a possibility that they only need the Activity rules to be activated on a very few entities or they just don’t need them.
3. Now when you have a better understanding, you can follow the following quick steps:

1. Login as a Dynamics CRM System Administrator to the Application.
2. Navigate to Settings-->Activity Feeds Configuration.
3. Select the configurations which you don’t need. (Please keep in mind that there are few configurations which are there by default and are active). Or, deactivate all the configurations if you don’t need them.
4. Once that is done, do remember to Publish the customizations for the changes done, which could be done by clicking on More Commands …. and then Publish Customizations. Until you Publish the customizations, the changes won’t take effect.
5. Now when you are sure that there are no more new entries being created (only in the case when you decide to deactivate all the configurations and rules, it’s time to clean the database, for which you can use the Bulk Delete feature to create a rule which would delete all the Posts (it is always a good practice to take the latest backup of the database and then do the cleanup because if at any point in time you would like to refer the data, you would have the backup to fall back on).

I would say last week as CRM database cleanup week, where I was working on cleaning up the PrincipalObjectAccess with one of my customers.

Moving ahead after cleaning up the WorkFlowLog entries from POA table which were created due to Dialogs (please refer my previous article for more information on that: https://blogs.msdn.com/b/ritesh_ranjan/archive/2015/02/09/another-experience-with-cleaning-up-the-principalobjectaccess-table-dialogs.aspx ), now I am looking at cleaning up the POA table for the records which are with the value 135069719 for InheritedAccessRightsMask column and value 0 for AccessRightsMask. Don’t be mistaken, it should be the value 135069719 and 0  for the same record under associated mentioned columns.

Let me explain it further for your better understanding of the scenario:

On a daily basis we were noticing hundred thousands of records in the POA table for the ActivityPointer, SalesOrder, Anotation and lots of other entities. After drilling down further on what is making these entries in the table we found that all of these entries were based on the Reparent attribute set to Cascade All. As Jon clearly mentioned in his blog (https://blogs.msdn.com/b/crminthefield/archive/2010/08/16/excessive-principalobjectaccess-poa-table-growth-in-crm-4-0.aspx) that with this setting, sub records would be shared to the owner of the parent record. For example:  Let’s say that User1 owns Account1.  User2 has access to Account1 and creates a case underneath Account1.  With the out of the box Reparent options, a record would be created in the POA table that would give User1 access to the newly created case. 

After my analysis I understood that these records will have a value (135069719) which decodes to all privileges except ‘Create’ under the column InheritedAccessRightsMask. In order to control the behavior first we really need to understand and explain the behavior, so that we could understand the pros & cons of changing the sharing behavior from Cascade All to Cascade None, which will completely stop those entries into the POA table. For better understanding on this change you can refer Jon’s blog mentioned above.

By now you would understand the reason behind these entries into the PrincipalObjectAccess table but at the same time you will have a question in mind, i.e. How to clean up existing data which is already created in POA because of cascade share all, right?

Resolution:

Try out with this simple test (In my case it was Account entity and Phone Call activity which was filling up POA table)

- Assign Account from User 1 to User 3

- Then assign Account from User 3 back to User 1

- Assign PhoneCall (which was under that account record) from User 2 to User 3

- Then assign PhoneCall from User 3 back to User 2

This sets the value of InheritedAccessRightsMask to 0, which means no privileges and this also marks the record to be deleted by the deletion service. Now this was good for testing with a single record but what if you have millions of Accounts and you need to do this ownership reassignment for all of them? 

The supported way is definitely to do it through SDK, creating a dummy user 3 and assign all the records to that user and then from that user3 assign it back to the user1 and user2. This could be done as a bulk operation using CRM SDK and this would help you clean the PrincipalObjectAccess table up to a great extent. In this case it reduced the table size by 80%, yes you read it right, 80%.

Hope this helps.

Stay tuned and happy reading!

Hey! I am back with yet another interesting yet intriguing situation. Without further ado, let me straight away get to explaining the scenario for you all. Happy reading!

Today, I was working with one of my customers and got into cleaning up the PrincipalObjectAccess table cleanup. I started looking at some of the references like: https://support.microsoft.com/kb/2664150?wa=wsignin1.0 , https://blogs.msdn.com/b/crminthefield/archive/2011/06/09/principalobjectaccess-performance-recommendations.aspx and https://blogs.msdn.com/b/crminthefield/archive/2010/08/16/excessive-principalobjectaccess-poa-table-growth-in-crm-4-0.aspx .

These were the best resources I could find in my case to explain and talk about those entries in the POA table. However, I was looking for some action plan on actual possible cleanup of the records from the POA table. Hence, started looking at the number of counts of type of records in the POA table, this would give a good starting point to nail down what is causing the enormous growth of the POA table.

Query to find the number of records with the type in POA table:

USE ORGANIZATION_MSCRM (replace it with your organization database name)

Select e.Name, COUNT(PrincipalObjectAccessId) as 'cnt'

From PrincipalObjectAccess poa with (nolock)

Join EntityLogicalView e with (nolock) on e.ObjectTypeCode=poa.ObjectTypeCode

Where poa.PrincipalTypeCode=8

Group by e.Name

Order by cnt desc

Go

This certainly gave me the record count and that was in millions, as expected :).

Now, I had to plan for cleaning up possible records from the table. During the investigation, I also found that there were lots of entries in the AsynOperationBase table and WorkflowLogBase table marked with completed state. So I knew that in this environment AsyncOpeartionBase and WorkflowLogBase cleanup was never done, hence, had to do that too. So, I followed the KB article: https://support.microsoft.com/kb/968520 which talks about cleaning up the AsyncOperationBase table which also removes entries from the POA table for the completed workflows.

Thankfully, cleanup was successful. But, surprisingly, even now, there were a lot of records for the WorkflowLog in the POA table . Now, I had to investigate and see what is causing these many entries into the POA table.

I found out that every execution of a Dialog (Process of category Dialog) creates a number of entries in the PrincipalObjectAccess table and the WorkflowLogBase table. The entries created in the PrincipalObjectAccess table have objecttypecode corresponding to WorkflowLog. The creation of these entries results in an excessive growth of the PrincipalObjectAccess table, which has a negative performance impact on the CRM overall.

By now it was clear that I had to focus on cleaning up entries for the Dialogs as well. Worked on this further with a couple of support engineers to confirm on the behavior and could understand that:

The creation of these POA entries is expected behavior, as all WorkflowLogBase items also create POA entries.  When a dialog is executed, it is similar to a workflow and utilizes the WorkflowLogBase table. When a workflow is fired, it is executed in the AsyncOperationBase table, but entries are also created in WorkflowLogBase and POA.  Dialogs work the same way, except that they are executed in the ProcessSessionBase table instead of AsyncOperationBase.

Hence, had an action plan to work on which was to cleanup up the POA table, for which, one of my colleagues Erik suggested to clean it up using Bulk Delete operation as following:

The Bulk Delete job you would create here is very similar to what you would do to proactively maintain the AsyncOperationBase table via Bulk Delete.  Specific steps for Process Sessions are below:

1. Go to Settings > Data Management > Bulk Record Deletion, and click New.

2. Click Next, then on the Define Search Criteria page set the Look for selection to Process Sessions (in CRM 2013 & 2015, but in CRM 2011, it should be Dialog Sessions).

3. Define the criteria for you Bulk Delete.  For example, you could use Status Reason = Completed; Canceled.

4. After defining your criteria, click Next to get to the Select Options page.

5. Provide a name, start time, and recurrence pattern, and then click Next.

6. Click Submit.

If you already have a bulk delete job for Async Operations, or for anything else, ensure that you do not schedule the jobs to run at the exact same time.  For example, if you already have a Bulk Delete job that runs nightly, weekly, etc. at midnight; do not also schedule this one to run at midnight.  Specify a different time such as 1:00 am instead.

And, finally, this helped a lot in reducing the size of the POA table. It was also a very good learning:

Dialogs which are a kind of workflows not running under Async do not hold any entry into the AsyncOperationBase but hold an entry into the WorkFlowLogBase table. However, it was understood that Dialogs work the same way, except that they are executed in the ProcessSessionBase table instead of AsyncOperationBase. And, it also holds entries into the POA table for the associated entries.

You can try using the above mentioned steps in your environment but with proper testing and understanding of the issue/scenario. This is completely based on a specific scenario and needs to be verified against the scenario you are analyzing.

Hope this helps.

I was investigating an issue where a form load in Dynamics CRM 2013 was taking longer than expected resulting in bad user experience. I knew that the environment was highly customized with lots of jscripts, plug-ins, synchronous workflows and everything we could think of. I started monitoring HTTP traffic using IE Developer tools (F12) and Fiddler and I observed the following details in terms of actual performance with the form load:

I was focusing at the amount of Bytes received which was 24 MB and it was disturbing me. I looked at the traffic to see what best can be done in order to compress the possible traffic. I also referred ‘Enable WCF Compression to Improve CRM 2011 Network Performance’ written by Jeremy at: https://blogs.msdn.com/b/crminthefield/archive/2011/12/29/enable-wcf-compression-to-improve-crm-2011-network-performance.aspx to make sure all compressions are enabled. While validating it, I noticed that the WCF compression was not enabled, hence, I got it enabled following the steps mentioned by Jeremy. However at the same time, I also noticed that there wasn't much of the WCF calls in the captured web traffic.

Then, I thought of discussing it further with the network team to figure out other possibilities. I noticed that there is a Hardware Network Load Balancer (mentioned above) handling the web traffic and sending the request to the CRM Web Server. I started investigating it further and observed that the ‘compression was not enabled on the Load Balancer’.

I got it enabled and the results were remarkable:

Data received was reduced from 24MB to 7MB which certainly helped a lot in gaining the overall form load performance and better user experience.

Hope this helps in investigating any similar issues.

Cheers!!

Ritesh

Today, I would like to talk about something which has been making a lot of buzz lately. Just yesterday, I was reading some interesting stuff around that. Let’s begin with Concurrency Effects in SQL. Let’s say that there are a lot of users accessing the same set of data on a regular basis, and, if there is no way of maintaining concurrency, then users could face consequences like:

Lost updates – occurs when two or more transactions select the same row and then updates the row on the basis of the value originally selected. Each transaction is unaware of the other transactions.

Uncommitted dependency (dirty read) – occurs when a second transaction selects a row that is being updated by another transaction. The second transaction is reading data that has not been committed yet and may be changed by the transaction updating the row.

Inconsistent analysis (non repeatable read) - occurs when a second transaction accesses the same row several times and reads different data each time.

Phantom reads – occurs when an insert or delete action is performed against a row that belongs to a range of rows being read by a transaction.

Missing and double reads – occurs when missing a updated row or seeing an updated row multiple times and missing one or more rows that were not the target of update.

Extract from: https://msdn.microsoft.com/en-us/library/ms190805.aspx 

READ COMMITTED snapshot isolation can be used to minimize potential locking contention while protecting transactions from “dirty” reads of uncommitted data modifications. With dirty reads, data within the current transaction can potentially be modified by other transactions between individual statements, resulting in non-repeatable reads or phantom data. In simple terms I would say READ COMMITTED snapshot isolation specifies that statements cannot read data that has been modified but not committed by other transactions.

These days production databases are quickly growing in size, and data-retention periods are increasing with changing business and regulatory requirements. Additionally, with drive capacity doubling and storage costs falling, the amount of data users want to keep "online" is increasing. In this scenario we can think of separating transactional data with analysis but that would be little expensive and leaves a question there, should we…? As we all know, SQL puts a lock on every statement until explicitly mentioned, under read committed transaction isolation, which means an active Select statement releases read locks after a resource is read.

Let me also share some information on isolation levels available in SQL, in this case SQL 2012:

Extract from: https://msdn.microsoft.com/en-us/library/ms345124.aspx#sql2k5snapshotisol_topic05

In nutshell, if I may put it across to you, I would say that please analyze the scenario & work with your DBA to plan it further. Also, please keep in mind that RCSI uses TempDB and enabling it could hinder the performance of your environment if your TempDB configuration is not optimal. For TempDB, ensure you have enough disk space, disk I/O, correct number of TempDB files and that the TempDB files are on a proper physical storage configuration (such as SSD's and separate from the CRM DB Files) will help reduce risk associated with TempDB performance.

Hope I was able to explain well.

Stay tuned and enjoy reading!!

For more understanding you can also refer:

Row Versioning-based Isolation Levels in the Database Engine: https://technet.microsoft.com/en-us/library/ms177404(v=sql.105).aspx

Understanding Row Versioning-Based Isolation Levels: https://technet.microsoft.com/en-us/library/ms189050(v=sql.105).aspx

Row Versioning-based Isolation Level Example: https://technet.microsoft.com/en-us/library/ms191190(v=sql.105).aspx

Enabling Row Versioning-Based Isolation Levels: https://technet.microsoft.com/en-us/library/ms175095(v=sql.105).aspx

Hello everyone,

Today I am writing about a common scenario which I have noticed during my customer visits lately. This is primarily focused on administering Dynamics CRM. I have tried to include almost every aspect that I could recollect from my customer visits. So, whether you would like to prepare your plan for maintaining Dynamics CRM effectively or define a benchmark based on this, you could use the information listed below.

Happy reading!!

CRM Server Maintenance:

• Make sure to have windows updates reviewed, tested and installed on the servers, along with validating the common security mis-configurations. You can use Microsoft Baseline Security Analyser which provides a streamlined method to identify missing security updates and common security mis-configurations.
• Regular monitoring of event logs. For more information you can refer: https://technet.microsoft.com/en-us/library/hh206051.aspx 
• Regular monitoring of server performance counters.  For more information you can refer: https://msdn.microsoft.com/en-us/library/windows/desktop/aa371643(v=vs.85).aspx and https://technet.microsoft.com/en-us/library/bb734903.aspx
• Anti-virus exclusions for Microsoft Dynamics CRM: https://blogs.msdn.com/b/crminthefield/archive/2011/01/24/anti-virus-exclusions-for-microsoft-dynamics-crm.aspx
• Maintaining AsyncOperationBase: https://support.microsoft.com/kb/968520
• Maintaining WorkflowLogBase: https://support.microsoft.com/kb/968755
• Maintaining PrincipalObjectAccess - you may notice that the size of the SQL table PrincipalObjectAccess grows and could be using a large percentage of the database size. Unmonitored growth in this table can cause performance issues: https://support.microsoft.com/kb/2664150 and https://blogs.msdn.com/b/crminthefield/archive/2011/06/09/principalobjectaccess-performance-recommendations.aspx and https://community.dynamics.com/crm/b/cinterosab_crmblog/archive/2013/01/22/principal-object-access-table-poa-table-grows-large.aspx
• Dynamics CRM maintenance jobs: https://blogs.msdn.com/b/crminthefield/archive/2012/04/26/avoid-performance-issues-by-re-scheduling-crm-2011-maintenance-jobs.aspx and https://blogs.msdn.com/b/crminthefield/archive/2013/02/07/more-details-on-dynamics-crm-2011-async-service-maintenance-jobs.aspx
• Maintaining and managing workflows in Dynamics CRM: https://blogs.msdn.com/b/ritesh_ranjan/archive/2012/08/22/dynamics-crm-troubleshooting-workflows.aspx
• Tips and tricks from Optimizing and maintaining the performance of a Microsoft Dynamics CRM 2011 server infrastructure
• Keep yourself updated with Microsoft Dynamics CRM 2011 updates and hotfixes
• Understanding of OrgDBOrgSettings tool for Microsoft Dynamics CRM 2011: https://support.microsoft.com/kb/2691237
• Maintaining Dynamics CRM 2011 using PowerShell: https://community.dynamics.com/crm/b/c5insightblog/archive/2011/03/10/manage-dynamics-crm-2011-with-powershell.aspx and https://msdn.microsoft.com/en-us/library/hh699700(v=crm.5).aspx
• Optimizing and Maintaining a Microsoft Dynamics CRM 2011 Server Infrastructure: https://technet.microsoft.com/en-us/library/hh413200.aspx
• Operating Microsoft Dynamics CRM: https://msdn.microsoft.com/en-us/library/hh699700(v=crm.5).aspx
• Known risks and vulnerabilities: https://msdn.microsoft.com/en-us/library/hh699686(v=crm.5).aspx
• Cleaning up CRM Sync Entry tables: https://blogs.msdn.com/b/crminthefield/archive/2012/10/03/cleaning-up-crm-sync-entry-tables.aspx

SQL Server monitoring:

• Regular monitoring of event logs. For more information you can refer: https://technet.microsoft.com/en-us/library/hh206051.aspx
• SQL performance counters: https://msdn.microsoft.com/en-us/library/ms137622.aspx
• Missing Indexes: https://technet.microsoft.com/en-us/library/ms345417(v=sql.105).aspx
• Index Defragmentation: https://technet.microsoft.com/en-us/library/cc966523.aspx
• Monitoring deadlocks: https://blogs.msdn.com/b/sqlserverfaq/archive/2013/04/27/an-in-depth-look-at-sql-server-memory-part-2.aspx and https://technet.microsoft.com/en-us/library/ms178104(v=sql.105).aspx
• Monitoring SQL blockings & timeouts: https://technet.microsoft.com/en-US/2008.04.blocking.aspx and https://technet.microsoft.com/en-us/library/ms190181(v=sql.105).aspx
• Monitoring SQL_Wait_Stats: https://technet.microsoft.com/en-us/library/ms190732(v=sql.110).aspx and https://msdn.microsoft.com/en-us/library/ms179984.aspx and https://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
• Monitoring SQL long running queries: https://technet.microsoft.com/en-us/library/ms177500(v=sql.105).aspx and https://technet.microsoft.com/en-us/library/cc879320(v=sql.105).aspx
• Regular checks of SQL errors: https://technet.microsoft.com/en-us/library/ms191202(v=sql.105).aspx
• Frequently validating SQL backups: https://technet.microsoft.com/en-us/library/ms189587(v=sql.105).aspx
• Monitoring SQL DMVs: https://msdn.microsoft.com/en-us/library/ms188754.aspx
• Regular checks on the reports error: https://technet.microsoft.com/en-us/library/cc512029.aspx and https://msdn.microsoft.com/en-us/library/ms165307.aspx

IIS maintenance:

• View Currently Executing Requests in a Worker Process (IIS 7): https://technet.microsoft.com/en-us/library/c6af847b-4b49-4fd4-b7bf-c2a8152f5f9d
• Create a Tracing Rule for Failed Requests (IIS 7): https://technet.microsoft.com/en-us/library/3dbee69b-ca3b-4adf-ab9e-81a541fc908c
• Enable Trace Logging for Failed Requests (IIS 7): https://technet.microsoft.com/en-us/library/30036297-9b85-40fb-93f4-5d43a48fd7eb
• Core IIS Administration: https://technet.microsoft.com/en-us/library/bb727092.aspx
• High Availability and Scalability: https://www.iis.net/learn/extensions/configuring-application-request-routing-(arr)/achieving-high-availability-and-scalability-arr-and-hardware-load-balancer

Also, I would like to include an article written by Shawn on CRM Upgrade Best Practices which should always be considered when planning for an upgrade: https://blogs.msdn.com/b/crminthefield/archive/2012/10/10/crm-upgrade-best-practices.aspx