Move over CRM and AX! Dynamics 365 is here!

Microsoft Dynamics CRM has been rebranded as Dynamics 365 as of November 1.

We have been battling for years the Microsoft CRM and ERP products did not talk to each other out of the box, requiring integrations like Scribe, EOne or KingswaySoft. Other competitors provided seamless tools that often noted this as a weakness.

Microsoft has responded with Dynamics 365 or a 360 degree of customer across CRM and ERP. And they didn’t stop with that. Now, the Common Data Model will be integrated across all products and be exposed to PowerApps, PowerBI and other products. An Appstore, along with the ability to provide Micro Apps will be a great way for developers to extend Dynamics 365 and get direct audience with the users needing these apps.

Why is this important to me as a developer? Lot’s of opportunity to not only extend Dynamics 365, but also to use XRM as your development platform and get access to all these great feature sets.


Thank you to the Community. MVP renewed for 2016.

It’s that time of the year again when Microsoft MVP’s in the October renewal cycle get their Award status. I’m proud to say I have been renewed again, for my 5th consecutive year. I would like to take a moment to thank my family, co-workers and Tribridge to give me the time and opportunity to support the community I love.

A lot of people do not realize that an MVP renewal is not guaranteed each year. You must work for it each year, showing and providing details of your efforts to be involved in the community. Most of us have no problem as we love to engage with the community and love to continue learning.

This year same as last year I will be splitting time between Dynamics 365 and Azure topics, as well as launching the Azure Medics monthly meetings to help the Azure community. CRMUG Medic calls will also continue quarterly.

Speaking of learning, Dynamics 365 blitz going on right now, with the launch for Dynamics 365 at the CRMUG Summit in Tampa FL October 11. Don’t miss it or join us remotely via the link below.

Azure Medics Panel & First Webinar Date Announced!

We have several Azure MVPs & soon to be MVPS signed up to be your first panel for our upcoming Azure Medic Webinar on October 25th. Let’s introduce them here and make sure to follow them on twitter for additional content! I will be your host and moderator for these web events. More details and future webinar dates can be found on our Facebook page here:

Greg Leonardo

Kevin D. Wolf

Santoash Hari

Scott Dorman




Override CRM dashboard limit to avoid your solution failing

When trying to upload a solution with more than the maximum number of dashboard components.

Message: “The Dashboard that you are trying to save has more components than the maximum number allowed. Remove some components and try again.”



To resolve this issue, you can increase the Dashboard limit using Power

1. Retrieve and set the dashboard limit

  1. Open a Windows PowerShell command window
  2. Add the Microsoft Dynamics CRM Windows PowerShell snap-in:

2. Add-PSSnapin Microsoft.Crm.PowerShell



3. Retrieve the current setting:

$setting = Get-CrmSetting -SettingType DashboardSettings

4. Modify the current setting:

$setting.MaximumControlsLimit = 10

Set-CrmSetting -Setting $setting



How to setup load balanced SSRS Servers for CRM 2016

While not very common, there are times when a customer or client requests two servers for the CRM SRS data connector/SSRS to be installed and have load balancing configured for the servers. The idea here is failover; when one server hosting SSRS crashes, all incoming requests are routed to the secondary server. There are a couple of ways to do this, but the following method is the most straightforward and simplistic way.

1.    Create a Virtual IP(VIP) to route to each SSRS server.

In order for this method to work, a virtual IP will need to be created. The virtual IP will accept incoming data packets, then route the requests to each of the IP addresses of the physical servers that will have SSRS installed.

2.      Install and configure SSRS on each server.

Install and configure SSRS on each server as you typically would by pointing to the SQL server and/or instance where you would like the report server databases to be located.

3.    Install the CRM SRS data connector on each server.

Grab the installation files for your respective version of CRM and install the data connector on both servers. Install the data connector as you would for a typical CRM deployment.

4.      Configure the host file on each SSRS server.

On both SSRS servers, open the host file: C:\Windows\System32\Drivers\etc\hosts. Edit the host file by adding the IP and DNS name of the virtual IP created in step 1:










5.      Add the BackConnectionHostNames registry key with the server name and FQDN.

Open Registry Editor on one of the SSRS servers, and locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0.

Right click MSV1_0, point to New and then click Multi-String Value. Type BackConnectionHostNames, then press ENTER.

Right click BackConnectionHostNames, then click Modify.

In the Value data box, type the host name of the VIP and FQDN of the VIP, and click OK.








Repeat these steps for the other SSRS server.

6.      Add hostname and URL root values.

On one of the SSRS servers, make a backup of the reportserver.config file located here: C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer.

Right click the original reportserver.config file and choose edit.

Modify the hostname and URL root tags of the .xml file located under the service tag by adding the FQDN of the VIP as shown below:



Save the file after making the changes.

Repeat these steps for the other SSRS server.

7.   Restart both SSRS servers.

8.   During the import or new creation of an organization in CRM, specify the name of the VIP.

Use the VIP created in step 1 when prompted for the reporting services URL during a new org creation or an org import:

ADFS setup error when using CRM 2016 and ADFS and Windows 2012 R2

An error occurred. Contact your administrator for more information” error when accessing CRM with ADFS/IFD set up.
After completing ADFS/IFD setup where ADFS is installed on a Windows Server 2012 R2 machine, you receive the below error:

 To resolve this issue you must enable Forms Authentication:

1.       Connect to the ADFS server

2.       Open the ADFS management console and click Authentication Policies







3.       Under Primary Authentication, click Edit next to Global Settings






4.    Put a check mark in the Forms Authentication option on the Extranet and Intranet sections

















5.    Click OK

6.       You should now be able to log in to CRM successfully

Thanks to Ian Holton, Client Field Engineer at Tribridge for putting this together!

Why You Should Have TCP Port 80 Open Outbound On Your ADFS Server?

Active Directory Federation Services (ADFS) performs a lot of tasks when it comes to authenticating users into CRM securely. One of those tasks in particular is a certification revocation check to validate that the certificates being used are still valid. ADFS completes this process by reaching out to certification revocation lists (CRLs) over TCP port 80 – basic HTTP communication.

What we’ve seen is that businesses will want to lock down their ADFS servers just to be on the “safe side” and that includes closing TCP Port 80 outbound (e.g. no internet access). If left in its default state, ADFS will break and cause authentication to fail as it knows that it is supposed to check the CLRs to validate the certificate before issuing a token to allow a user into CRM. If it cannot do this, it will not issue a token. You may see an error similar to the following in the ADFS event viewer logs after a failed authentication attempt:










Event ID: 364

Microsoft.IdentityServer.AuthenticationFailedException: MSIS3014: The encryption certificate of the relying party trust ‘’ identified by thumbprint ’01DEDF6E6F532BF7357457EBEC31DA82SFDA1234′ is not valid. It might indicate that the certificate has been revoked, has expired, or that the certificate chain is not trusted. —>

Microsoft.IdentityServer.Service.SecurityTokenService.RevocationValidationException: MSIS3014: The encryption certificate of the relying party trust ‘’ identified by thumbprint ’01DEDF6E6F532BF7357457EBEC31DA82SFDA1234′ is not valid. It might indicate that the certificate has been revoked, has expired, or that the certificate chain is not trusted.

So what are your options?

  1. Have your networking team open TCP 80 outbound on the ADFS server(s). This would also apply to all ADFS Proxies or WAP servers. While opening a port might seem less secure at face value it would actually be the opposite as ADFS is able to validate the certificates being used.


  1. The less preferred, but still acceptable, method would be turning off the Certificate Revocation Check of ADFS. The check is controlled individually for each relying party in ADFS so it would need to be turned off for all one by one. To do this open an admin PowerShell prompt and issue the following command:

                    Set-ADFSRelyingPartyTrust  -TargetName <relyingpartytrustName> -EncryptionCertificateRevocationCheck None


CRM Database Log Growth Issue

A customer of ours had come to us facing a rather interesting issue. Every night around 1am their CRM database log file would grow to 31GB and cause the log drive to fill up. When users would log into CRM in the morning, they would receive SQL errors stating that their transactions could not be completed.   Given that this issue occurred on a regular schedule, we determined that the issue had to be attributed to some sort of automated job.

Figuring the first place to check would be the out-of-the-box CRM Maintenance Jobs, we downloaded the Job Editor from Codeplex

( – Very useful tool that everyone should be using) and got to investigating.

Right off the bat, we saw our error on the Deletion Service:
Deletion Service encountered an internal error: System.Data.SqlClient.SqlException (0x80131904): Invalid object name ‘SubscriptionTrackingDeletedObject’

From here we moved to SQL and queried the SubscriptionTrackingDeletedObject table of our CRM database.

What we found was astounding – the table contained 137 MILLION records. Basically after seeing this we knew that the job had to just be timing out – we tested our theory by running the job manually and immediately saw the log file grow to the expected 31GB.

It was decided to clean this table up manually via truncating it. Before you say “Oh no! Don’t delete records via SQL directly!” let’s explain what this table actually is.

When records are deleted from CRM, there are also records that get inserted into this SubscriptionTrackingDeletedObject table. This table gives the Deletion Service Job ObjectIDs that have been removed so that further cleanup can be performed asynchronously. So essentially, it is just a table of deleted records which gives the Deletion Service knowledge to clean up some other areas of CRM (e.g. POA records, duplicate detection records, etc…) if necessary. Once cleaned up, the records from the table are removed. We understood this and decided the need to clean this table outweighed having the other areas of CRM cleaned up (as you will learn later, this wasn’t a concern for us because of how the records got in there).

Please note we cannot condone the practice of editing SQL manually without full knowledge of the possible repercussions. Always consult with Microsoft support if in doubt and remember what works in one scenario, may not work in all.

After the table was truncated, CRM was tested and the deletion service job was run manually – this time not failing with the error above and the log did not grow to 31GB. Before calling this case closed, we still needed to understand what caused this problem in the first place. What could have possibly created so many records in such a short period of time? Luckily, we had the right people involved on the customer’s end and were able to determine that there had been a malfunctioning Scribe job that was running for a while unnoticed. It was a job that was bulk creating and deleting 50,000 records at a time within CRM but the job had since been fixed. Case closed.

CRM Organization Import Issue and SSRS MaxRequestLength

When importing an organization to CRM 2011 we came across an error during the import wizard process which was causing the import to fail:

14:54:33| Info| PublishReportsFromDatabase: Creating report in Reporting Services. ReportId: 9f973403-bc84-e111-88bc-0050569e0001, Name: INVOICE PAYMENTS
14:54:34| Error| Error while updating organization information: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Crm.Reporting.RuntimeReportServer.UploadReport(String path, Byte[] reportDefinition, String name, String description, Boolean overwriteExistingReport)
at Microsoft.Crm.Reporting.RuntimeReportServer.UploadReport(SRSReport report, String reportNameOnSrs, String name, String description, Boolean isSharedReport, Boolean overwriteExistingReport)
at Microsoft.Crm.Setup.Server.Utility.ReportsUtility.OrganizationPublishReportsScaleGroup(IDbCommand command, Uri reportingUrl, String orgUniqueName, Boolean ignoreCustomReportsFailure, Boolean publishOnlyCustomReports)
at Microsoft.Crm.Tools.Admin.DBImportHelper.RePublishReports(IDbCommand command, Guid organizationId, String organizationUniqueName, Uri reportUrl)
at Microsoft.Crm.Tools.Admin.ImportOrganizationInstaller.UpdateOrganizationInfo(Guid organizationId, OrganizationGroupsInfo organizationInfo, String organizationFriendlyName, String organizationUniqueName, Uri reportServerUrl, Int32 PercentUpdateOrganization, ICollection`1 users)

This was not an upgrade of any sort – just simply a CRM migration to a new environment so there were no versioning differences from a CRM perspective. While the error above is lacking much detail, it did give us enough to begin troubleshooting. We could clearly see that this issue was occurring with a report titled “Invoice Payments” but knew nothing else. After obtaining a copy of the report’s RDL file, we didn’t notice anything wrong in particular with the way the report was written but did think it was rather large for an RDL file – nearly 5MB – there were quite a few embedded images.

We decided to attempt uploading the report directly into SSRS and were met with a much more helpful error message – “Maximum request length exceeded”. What this was telling us rang a bell with what we noticed earlier regarding the RDL file size. By default, SSRS has a limit on the report file size that it will allow to be imported. This limit is 4MB but can be increased by doing the following:

Open the web.config of the Report Manager (%\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportManager) and find the “executionTimeout” setting. It should look something like this:

On this line, add the maxRequestLength attribute with the value (in KB) needed to upload the report. This value is not in here by default. It should now look like this (this shows a 10MB limit):

Save the file and then repeat these steps in the web.config of the Report Server (%\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportServer). Once both files have been modified and saved, restart the SSRS service.

Following this change, we were able to upload the RDL to SSRS directly to verify that the change worked and then subsequently were able to complete the organization import for CRM without issue.