Tracking down deployment errors in The New Dynamics AX

When we started using AXUtil.exe in Dynamics AX 2012 it was a bit scary in the beginning but I consider it easy to use after having spent hours upon hours massaging model files on different installations. It is a bit of a black-box, I know. But still it went from causing sweaty armpits to being easy-peasy handling modelstore updates using AXutil.

Now with the New Dynamics AX we are introduced to AXUpdateInstaller.exe and we are back to dark spots on the t-shirt where the arms meet the torso. But I bet that we will get used to this like we did with AXutil … I hope …

One thing that I have learned the hard way is to not have Visual Studio and the Application View opened on the same machine I am deploying to. That gives an error when the installer tries to unzip the files from the package to the service folders.

The error is something like this:

 <Log>
     <Time>2016-03-02T09:32:43.5149415+00:00</Time>
     <MachineName>mymachine</MachineName>
     <StepID>3</StepID>
     <Message>The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: A positional parameter cannot be found that accepts argument 'Package deployment failed as the extraction of the package zip file failed.'.</Message>
 </Log>

The text is picked up from the runbook file.

So I went through all the normal stuff such as disk space, access rights to the folder, test-expanding the folder and so on. Nothing looked suspicious.

Next step was to look at what step 3 actually does that makes it stop. Going a bit upwards in the runbook file we get the actual contents of each step. For step 3 it is:

<Step>
    <ID>3</ID>
    <Description>Update script for service model: AOSService on machine: AX7SORAS02-1</Description>
    <MachineName>AX7SORAS02-1</MachineName>
    <ServiceModelName>AOSService</ServiceModelName>
    <ScriptToExecute>
        <FileName>AutoUpdateAOSService.ps1</FileName>
        <Automated>true</Automated>
        <Description>update AOS service</Description>
        <RetryCount>0</RetryCount>
        <InvokeWithPowershellProcess>false</InvokeWithPowershellProcess>
    </ScriptToExecute>...

The interesting part is the filename AutoUpdateAOSService.ps1. The scripts run by AXUpdateInstaller for this is located in the deployment folder in AOSService\Scripts.

Using Windows PowerShell ISE you are actually able to debug your way through the script.

When you have located the error you can use AXUpdateInstaller to mark the step as completed and it will automatically move on to the next step.

Advertisements

How to delete a label file in AX 2012

If you end up with an obsolete label file in AX 2012 and want to delete it you cannot just right click and select delete from the popup menu.

To get rid of the label file you can do the following:

  1. Create a new model. In this example named DeleteMe
  2. Move your label file to the DeleteMe model
  3. Use AXUTILs delete function to delete DeleteMe
  4. Restart the AOS

You have successfully removed the label file from your installation.

AOS cannot start after extending string length on EDT

All though AX 2012 is constantly moving the boundaries for what we can do we ended up hitting the roof on field/record sizes the other day.

After heavily increasing the string length on an EDT and a crashed synchronisation the AOS was unable to start up again. The error message received in the Event log was this:

Object Server 01: Unexpected situation
More Information: Total field length cannot exceed 64K. Please re-factor your table <tablename>

The obvious solution is to decrease the length of the EDT to get below the 64K limit.

But – to cut this short –  we now have an AOS that cannot start due to an error we need the AOS running to fix. Well, we knew that we had a backup taken a couple of hours ago giving us a loss of changes that we could deal with if it were. However, it was worth giving it a shot trying to fix this.

The solution was quite simple. We found a similar versioned environment and did the following:

  1. Create a new model
  2. Make a small customisation to the EDT giving us the problems putting it in the new model
  3. Export the model
  4. Import the model in the model database of the AOS that will not start
  5. Start the AOS
  6. Skip the models changed dialog and do a full synchronisation from the AOT

Voila! We are back on track with no loss except for the time spent doing the above thanks to the model concept and AXUtil.