Server-side Synchronization in Dynamics 365

This is a brief summary for a while paper released Aug 2016 explaining how the server side synchronization works:

Server-side synchronization, also known as Server-Side sync or Exchange sync, is a server-side process for synchronizing appointments, contacts, tasks (ACTs), and email messages between Exchange Server and Microsoft Dynamics CRM Server. Server-side sync runs as part of the Asynchronous Processing Service.

Since the server-side sync component is hosted on the server running the Microsoft Dynamics CRM Asynchronous Service server role, it brings some advantages. First, the current Microsoft Dynamics CRM Asynchronous Service already loads the full set of organization metadata-caches. If server-side sync ran in another process, these large caches would have to be loaded a second time resulting in sub-optimal memory use. Second, it gives server-side sync access to the full set of organization metadata-caches that’s loaded in the Microsoft Dynamics CRM Asynchronous Service process.

Unlike Outlook synchronization, which requires CRM for Outlook to support synchronization, server-side sync can support synchronizing activities between Dynamics CRM and Exchange without running CRM for Outlook.

Typically, the server-side sync loading mechanism makes sure each mailbox that needs processing is serviced within 15 minutes.

When queuing mailboxes to process, server-side sync provides some configurable values located in the DeploymentProperties table of the configuration database that you can adjust by using Windows PowerShell to customize the queueing capacity in your environment. Notice that this configuration is available for on-premises deployments of Dynamics CRM only.

The default in memory queue settings are configured for mid-size organizations, which typically work best for organizations that have between 3,000-5,000 users.

Queue performance depends on the number of users and item workloads across the servers running the Asynchronous Processing role. You can use Windows PowerShell to either increase or decrease the settings, depending on the number of users and email or activity synchronization experienced.

When the Asynchronous Processing Service server role is deployed on more than one Windows Server there is no affinity between mailboxes and the servers on which they will be processed.

Dynamics CRM Server Setup facilitates administrators by allowing the selection the of Email Integration Service capabilities as a separate server role. This can help improve performance and scalability by isolating email integration specific operations for on-premises deployments during installation. The server role can be isolated by selecting only Email Integration Service.

One of the first steps to successfully run server-side sync involves configuring an email server profile. In Dynamics CRM on-premises, the email server profile facilitates administrators to specify configuration settings such as server types, server locations, and authentication details.

You can find in this MSDN article the complete steps for configuring Server side synchronization to connect Dynamics 365 on-premise with Exchange Server on-premise.

 

 

Advertisements

CRM 2016 ADFS Configuration for Internal Access

We had a unique Dynamics CRM implementation in which we had a requirement for enabling external Active directory users connected to CRM environment using vpn tunnel to authenticate with CRM without exposing CRM over the internet, this lead us to utilize the enabling claims based authentication for internal access CRM configuration with configuring IFD, below are some hints and hard lesson learned to achieve such authentication requirements:

  • Host the CRM web services on a port other than 443 as per Microsoft guidelines for claims based authentication for internal access, port 443 can be used for the web application access normally.
  • We managed hosting the CRM web services on port 444 while the CRM web client was hosted on different port which is 443 and CRM worked normally.
  • Ensure that any client that is trying to access CRM web interface or use CRM web services is having access to the CRM front end servers and to the ADFS servers as well due to the fact that the authentication is happening through a re-direction to the ADFS landing page.
  • For any custom web services or SSIS sychronization packages integrating with Dyanmics CRM, make sure they have the appropriate access to the ADFS servers.
  • In plugin registration tool you may need to use a special format for the username depending on the UPN claim format which is configured in ADFS when adding the CRM as a relaying party.
  • The default session timeout period is very small and controlled from ADFS, it is advised to increase the token lifetime for a better user experience as when the session times out, the client must close all opened browser sessions and open it again to re-authenticate.

I will try to update this post with any new hints that I missed.

Dynamics CRM Form Ajax Update

Microsoft released since CRM 2013 new client APIs, some of them are the Xrm.Page.data.refresh and Xrm.Page.data.save methods.

The refresh method Asynchronously refreshes and optionally saves all the data of the form without reloading the page as per MSDN and has the following signature:

Xrm.Page.data.refresh(save).then(successCallback, errorCallback);

This function has a better user experience than the old form refresh method which reloads the whole form and fires the on-load events that might not be needed.

Also, in the case we wanted to perform asynchronous save of data we can utilize the save function which saves the record asynchronously with the option to set callback functions to be executed after the save operation is completed as per MSDN and has the following signature:

Xrm.Page.data.save(saveOptions).then(successCallback, errorCallback)

Joining a New CRM Server to an Upgraded CRM Deployment

Sometimes we need to scale out a CRM 2015 deployment that is having the latest update installed, when you try to join a new server you are faced with the below error in the installer checks page:

The Product key is not compatible with installed version of Microsoft Dynamics CRM.

I believe this is a bug in the installer so to workaround it add the IgnoreChecks registry key to the computer that is running Microsoft Dynamics CRM so the installation can proceed when an error is shown in the Environmental Diagnostic Wizard (EDW):

Click Start, click Run, type regedit, and then click OK.

In the registry, locate the following subkey: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM

Right-click MSCRM, point to New, click DWORD Value, and then type IgnoreChecks.

Double-click IgnoreChecks, and then type 1 in the Value data field.

Note: After including this registry value you will get the same error message in installation wizard but this time the Next> button will be enabled in Installation Wizard to complete this installation so just proceed and install the CRM latest updates at a later step.

Moving Site Collection to Different Web Application – SharePoint

We created a site collection for saving CRM documents on Intranet web application, we wanted to move that site collection to a new web application to avoid having a single point of failure for the 2 site collections and also allow the CRM administrators to control the maximum attachment size for files stored on SharePoint.

We achieved this by running the below 2 PowerShell cmdlets:

Backup-SPSite -Identity “http://intranet.domain.com/sites/CRMDocs” -Path “C:\CRMDocumentsSiteCollection.bak”

Restore-SPSite -Identity “http://intranet.domain.com:8888/sites/CRMDocs” -Path “C:\CRMDocumentsSiteCollection.bak”

The site collection will be created if not already existing, and if we want to override an already existing site collection on the specified URL then we will need to add the -force parameter.

Then we re-configured the documents management settings in CRM to point to the new site collection URL, the good thing about CRM is that it saves the document locations relatively, so such a change in the base URL only requires updating the SharePoint site URL and everything works fine.

Please note that in case you faced a SQL timeout while re-configuring the document management settings in CRM due to having large number of documents then you will need to increase the CRM SQL timeouts on the front end servers.

CRM 2015 SLA New Features – Differences

CRM 2015 SLA is now having 2 main types:

  • Standard SLA
  • Enahanced SLA

Below is a comparison between the 2 types:

Standard SLA Enhanced SLA
Populates First Response by and/or Resolve by values in the case entity. Uses a new entity (SLA KPI Instance) to store this data.
Failure time stamped on case entity attributes. Failure/Warning times stamped on related SLA KPI Instance record displayed via a sub grid in the case form
Timer control based on case entity fields; can be directly added to case form. Timer control based on related SLA KPI Instance fields; can be added using Quick From
SLA Pause/Resume is not available SLA Pause/Resume while SLA Time calculation is automatically paused when a case is put on Hold, also the amount of time on hold is also tracked.

There is system setting that allows pausing cases SLA automatically for certain case status reasons.

The ability to pause can be disabled/enabled for each SLA.

Success actions are not available. Trigger actions when an SLA is successful

Important Considerations:

  • Cannot change SLA type once created.
  • Case SLA cannot be sorted by Enhanced SLA fields as they are now on another entity.
  • Queue Item views cannot display Enhanced SLA fields.

CRM & SQL Server BizTalk Integration

We had a project in which there was a requirement for an integration between Microsoft SQL server and Microsoft Dynamics CRM 2011 using BizTalk 2013 R2, the solution in brief was Listening on SQL server using the WCF-Custom Adapter then using the orchestration to do data mapping then send the new transformed message to a custom WCF service that handles inserting the message as a new case in CRM, below are the hard learned lessons for such integration:

  • When receiving message from SQL server with a specific schema, make sure the SQL statement is returning xml results matching the same schema defined in the orchestration or the mapping process will not be able of transforming the message to the target schema.
  • When constructing a message using message assignment in an orchestration, check the message in the constructed messages property in the construct shape to resolve the build time error in case trying to assign value to a message not constructed from a receive shape.
  • When configuring the WCF-Custom SQL binding connection, if there is only one default instance on the SQL server then you need to use the below format with double slash between the server name and the database name for the URI connection string: mssql://ServerName//DatabaseName
  • When using the WCf-Custom adapter, there is an important property named UseAmbientTransaction which is defaulted to true, this property specifies whether the adapter will use DTC transactions in the communication with SQL server or use normal queries that doesn’t require DTC, you need to make sure that DTC is enabled on SQL server and is working properly by using a tool named DTCPing, sometimes the adapter will not work properly while not throwing any errors on the BizTalk server due to DTC issues like DNS name resolution that is blocking the transaction only on the SQL server side.

The experience with this integration was fruitful, interesting, and leveraged how BizTalk can be used to build robust and powerful integration solutions.