Known Issues Microsoft Dynamics 365 (On-Premise) Update 2.13 (8.2.13.21)

Since we were facing some strange issues with the latest 8.2 Update, I just recommend everyone to not go for this step and plan directly for the 9.X. We were facing some issues with Workflow Activation as part of the deployment due to custom activities and Microsoft Support told us, this Update will fix this topic.

Summary

• Problem was not fixed
• 2 new Issues were introduced

Issue 1 - Newtonsoft Missing in Installer

After installation, we found monitoring errors in the event log.

1. Error: MSCRMMonitoringRuntime
Monitoring runtime failed: Machine: << Removing the server Name >>: Exception: Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0,

2. Error: MSCRMMonitoringRuntime

Monitoring runtime failed: Machine: << Removing the server Name >> : Exception: SmokeTests failed with exception : System.TypeInitializationException: The type initializer for 'Microsoft.Crm.Monitoring.MonitoringSettings' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=.................' or one of its dependencies. The system cannot find the file specified.

After alignment with Microsoft Support, they confirmed it is a bug and recommended the following steps:

• Copy the Newtonsoft from CRM installed folder "D:\Microsoft Dynamics CRM\CRMWeb\bin\Newtonsoft.Json.dll"
• Past the dll file in "D:\Microsoft Dynamics CRM\Monitoring\bin"
• Restart the "MSCRMMonitoringRuntime" service

It was working, monitoring errors disappeared.

Issue 2 - Attachment Records not deleted

Microsoft switched the email attachment deletion pattern from a direct delete to a soft delete (most likely due to the new pattern in online which is storing the attachments in Blob Storage). Since we developed this solution for our current customer in On-Premise, we figured out that the deletion of the old attachments is not working anymore since the Update was installed.

D365 is now creating additional records in the Attachment-Table but the deletion job is not aware of deleting those records.

Also, MS informed us that they will most likely not provide a fix for 8.X since the problem is already fixed in 9.X

Microsoft shared a SQL script to get rid of the old records which must now be executed as a SQL Job.

Links:

• https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/350763/deleted-e-mail-attachments-not-removed-from-attachment-table
• https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/entities/activitymimeattachment#BKMK_ComponentState

Cheers

Azure Hybrid Connection

In the current project, we had to work around some temporary network restrictions to continue with the release. For a first test period, an endpoint had to be called from an Azure Function, which was not yet available on a public server and also this endpoint was not in the hands of our team. Calling it from our dev/test network worked fine.

To sort that out, we just enabled for a few weeks a Hybrid Connection at the required Azure Function and installed the Hybrid Connection Manager on a Machine in our dev/test network. The result is, that for the Function, the endpoint URL is reachable as it would be with a direct call. Behind the scenes, the Request is processed by an Azure Relay/Service Bus From Azure to our Test Server and from there, the request is triggered to the specific endpoint. The response is routed back the same channel so from a caller point of view, it behaves completely like calling a synchronous endpoint.

The important fact is, that there is no active call into the network but the Hybrid Connection Manager is recognizing the activity (call) to the Relay and is processing it in nearly realtime.

Since this was done in 10 minutes, it saved us a lot of time and also avoided any mocking for this endpoint.

Cheers

Get-AzKeyVaultSecret failing with 'Forbidden'

While preparing the pipeline scripts for the current project, I was not able to fetch the secrets form our KeyVault via Powershell using Get-AzKeyVaultSecret.

The Access Policies have been configured correctly and I was owner of the subscription.

Unfortunately, the KeyVault requires explicit 'owner' permissions on KeyVault level to make this work.

Error
Get-AzKeyVaultSecret : Operation returned an invalid status code 'Forbidden'

Solution
Grant owner permissions (temporarily) to your AD-User on KV-Level.

Cheers