Fast Deployment - Dynamics 365 for Finance & Operations LBD

Greetings!

On a Dynamics 365 for Finance & Operations LBD Deployment, can occur that the Deployment fails on a certain step like the SSRS App Deployment, Synch, etc.

In order to check the Deployment status and the running task, you can run the below query against the «OrchestratorData» Database.

use OrchestratorData
select * from RunBookTask order by StartDateTime desc

In such case, just fixed the issue we can restart the Deployment in two ways:

1. Through LCS, retry button (like cloud)
• this option clear all Fabric applications and recreate them again. Time consuming
  
2. Through SQL Server, fast way
• this option avoid to recreate the Applications and rerun the last step only

About the second option, once checked the failed step with the previous query, we have to update the two tables involved in the process and move the State field from 3 to 1 for the specific JobId.

update OrchestratorJob set State = 1 where JobId = 'AXUG-028b0c39-e713-4fb9-b375-52f507df1313'

update RunBookTask set State = 1, Retries = 1 where RunbookTaskId = 'AXUG-028b0c39-e713-4fb9-b375-52f507df1313-setupModules'

About this option, take care because in some cases like Certificates update, recreation of the Credentials.json file, etc. is mandatory handle the deployment through LCS.

About that, I handled a session to the last AXUG Conference in Dublin.

Till soon!

Violation of PRIMARY KEY constraint 'I_65518FIELD' - Dynamics 365 for Finance & Operations LBD

Hi

Recently I had a Synch issue during my deployment on a Dynamics 365 FO LBD Implementation.

This is the error:

Violation of PRIMARY KEY constraint 'I_65518FIELD'. Cannot insert duplicate key in object 'dbo.SQLDICTIONARY'. The duplicate key value is (TABLEID, FIELDID, 1, 0).

It seems that already exist a field with the same FieldID!

With Microsoft Dynamics 365 FO I thought that issue like that doesn't happen anymore.

However, against the Business Database exist a table named TABLEFIELDIDTABLE that list for each table the fieldId values.

From my side I notice that some of my custom field ids present on that table was different than the Ids listed on the SqlDictionary table.

Really strange..

So, I decide to update the SQLDictionary table according with the Id values coming from the TABLEFIELDIDTABLE table.

Lastly, I restarted my deployment from the same failed step.
Take a look here in order to understand how to rerun a specific Step without to rerun the entire process.

The same issue could occur also on a Cloud Deployment, like on your Tier 1 or UAT Environment

That's it!