How to identify failures during package deployment for Dyn365FO

In this blog I want to describe some tactics to identify failures when you do package deployment for Microsoft Dynamics 365 for Finance and Operation via Lifecycle services (LCS). 

First of all I do not want to blame any feature here in LCS. I “love” the processes of uploading deployable packages to LCS via Azure DevOps and applying them via the web UI to non-production environments. 

Recently I had the task to update an existing pre-production (sandbox) environment from 8.1.2 PU22 to 10.0.1 PU25, to follow the monthly release/OneVersion strategy. To do this step with only one package deployment I added an ISV-License file to the package which got uploaded to LCS from Azure DevOps and in addition to that a merged the “custom” deployable package with the package for updating to 10.0.1 PU25. The result of that was a deployable package which simply includes “everything”. 

One general thing you need to know for identify failures during package deployment is to find the PowerShell file which is used by a specific step. To find the right file you can search for <ID>#StepID</ID> in the current Runbook.XML file, which is located on the service volume in folder K:\DeployablePackages\#YourPackageID. Another general thing is that you can perfectly use the event viewer on the machine which executes UpdateInstaller.exe to find problems e.g. during database synchronize. 

The first failed state of the environment was because of step 115 and 119 of 852 steps were failing. After using the resume button for several attempts without any luck a solved the first two problem like this:

  • I had to RDP to the AOS where the steps failed.
  • Step 119 “Update script for service model: AOSService on machine: SAS-SB-AOS-1” could be solved by simply re-running the failed step using UpdateInstaller.exe. You can find the current deployable package and runbook on the service volume in the folder DeployablePackages. After the step has been manually completed, I inserted a simple return in the PowerShell file for step 119, to do not run the step again via LCS.
  • Step 115 “GlobalUpdate script for service model: RetailSelfService on machine: SAS-SB-AOS-1” was a bit harder to solve. When I manually executed the step using UpdateInstaller.exe I got the error message “Maximum wait time of ‘1800’ reached, process was force killed”, so I decided to run the PowerShell file (UpdateRetailSelfService.ps1) directly. After it got manually completed, I inserted a simple return in the PowerShell file for step 115, to do not run the step again via LCS.

 The second failed state of the environment was because of step 224 of 852 steps was failing.

  • I had again to RDP to the AOS where the step failed.
  • After manual retry of step 224 “GlobalUpdateConfig script for service model: AOSService on machine: SAS-SB-AOS-1” via UpdateInstaller.exe I got the error message “Import AX license file. The step execution time exceed the timeout value specified: 3min”. Step 224 was specific to the added ISV-License and had a fixed timeout of three minutes. Also in this case manually running and aft wards skipping the PowerShell file (AutoImportLicense.ps1) fixed the problem.

 Hopefully this post helps to do not waste too much time on finding the right tools for identifying failures during package deployment and I´m very interested in your approaches to solve/fix problems like this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s