Home / News / What to do when package deployment fails
4 June 2019
By: Jorgen Tol

What to do when package deployment fails

Featured image for blog about Package deployment failed

What to do if the package deployment failed?

In Dynamics 365 for Finance and Operations we have to deploy changes to environments by creating deployable packages and installing these via Lifecycle Services (LCS). This usually works pretty well, but sometimes it can fail.

In this blog I would like to explain the normal development process and explore what we can do to remedy the errors that can occur during this.

 

The development process

The idea is that you develop on development Virtual Machines and from there check in your code into Azure DevOps. Afterwards, you start a Builds, which runs on a Build machine. This is a development Virtual Machine which takes all code from DevOps, compiles the application, synchronizes the database, and deploys reports.

The build results in a deployable package, which you upload to Lifecycle Services (Either manually or automatically).

From Lifecycle Services (LCS) you can deploy to the sandbox environments you wish to update.

 

Possible errors

This process usually works pretty well, but sometimes errors can arise. Because of this, it’s always advisable to monitor the process after you’ve started it. Don’t start it and ignore it until the next workday or you may have a non-working environment on your hands.

Now that I have been working with these for a while I would like to point out a few errors that I have found and what you can do to resolve these.

1. If it fails, just press continue
Sometimes the solution is simply to press the continue button. Only if it fails a consecutive time should you look for issues in the log. Why the system fails I do not know, but continuing often solves the issue.

 

2. Your next step should always be to check the log files.
Download the logs, by clicking the following button in Lifecycle Services (LCS).

3. Unzip the zip file

4. The zip file contains folders which are named according to the steps in the deployment process.

5. Inside these folders there’s .log, .error and .output files

6. Your best bet is the error files, but the output files sometimes have useful information too.

Search for possible issues

Search these files for possible issues. A few of these are the following:

1. Out of space

    • The VM could be out of space. The error message in the files will be something like “System.Management.Automation.RuntimeException: 7Zip failed to extract package”.
    • To resolve this issue clear space on the Service Volume (usually G drive) by emptying the DeployablePackages folder.

 

2. The log has a message like “Attempting to resolve dependency ‘dynamicsax-applicationfoundationformadaptor’.”

    • This means you have included a reference to the formadaptor modules. These modules are used by the automated testing framework and thus are not included in Sandbox environments, only in OneBox environments. In our case it did build in the Devbox and Nuild environment, but then it failed on the test environment.

3. SQL errors about fields

      • These are usually caused by replacing existing fields with fields with the same name but a different datatype. To solve these, rename the new field to a name not previously used in the table. In my opinion this is a bug in how Dynamics 365 for F&O handles new fields, but thankfully this doesn’t happen all that often.

 

What if you’re unable to resolve the errors

If these errors are not resolved and you’d like to rollback, never click the abort button. This will abort the update process and you’ll be left with a non-functioning environment to fix yourself.
Instead, you should always use the rollback button. This will take steps to rollback the environment to the state it was in before the update. It performs this by taking the files the system has backed up before the update and restores these to their correct locations.

 

Conclusion

The Dynamics 365 for Finance and Operations deployment process works pretty well but it’s not quite mature enough to be left unmonitored. In the future I hope that Microsoft will continue to improve the process and add the possibility to automate the process even further by automatically scheduling updates from nightly builds.

This is it for now, should I come across any more issues I’ll be sure to update this post.