Enable developer mode in the MPOS without rebuilding

In the Dynamics 365 POS it’s possible to enable a developer mode that gives you some additional options like seeing the id of the strings, grid views, coloring aids and so on. To enable these features you need to rebuild the POS with the value config.isDebugMode to true in the pos.js file. That’s easy in the CPOS but requires some build/deploy in MPOS.

Our POS developer gave me a tip to shortcut that … a lot. It’s a few easy steps and they go like this:

Enable Developer mode in Windows. That’s done in settings on the box running the POS

Developer mode Windows

Start the POS and hit F12 to enable the developer aid

In the bottom of the console type in Commerce.Config.isDebugMode=true and press Enter

Set debug mode

Go to your POS settings to enable the Developer mode flag in here.

Developer mode in POS

This will make some things way easier. Notice, that when done like this it is only for the current session. Doing it in the pos.js file-way is permanent.


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:

     <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>

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:

    <Description>Update script for service model: AOSService on machine: AX7SORAS02-1</Description>
        <Description>update AOS service</Description>

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.

Troubleshooting the Commerce Data Exchange

In AX 2012 troubleshooting the Commerce Data Exchange is necessary. It’s somewhat a blackbox but we do have a few tools in the belt and handles to pull.

This post describes a couple of these in AX 2012 R2. The following versions are a bit more informative; but some of the tips are still relevant.


What’s in the queues?

The communication flow is passed through the SQL server and during installation you are asked for a message box database. When looking into this database two of the tables are showing you the flow of messages and a few related (general) pieces of information. I use the following SQL statements as a standard approach to these tables:

SELECT JobID, Status, TryCount, ErrorNo, ServerMsg, FinishedDateTime, PackageNo, ServiceName 
FROM [RetailMsgDB].[dbo].[IncomingMessages]
ORDER BY FinishedDateTime DESC
SELECT JobID, Status, TryCount, ErrorNo, ServerMsg, FinishedDateTime, PackageNo, ServiceName 
FROM [RetailMsgDB].[dbo].[OutgoingMessages]
ORDER BY FinishedDateTime DESC

delete from IncomingMessages
delete from OutgoingMessages

The result of the query looks something like this:


The first result set shows the messages going in to the server and the second result set shows the outbound. As long as the ErrorNo is 0 you are good. If it does show up with an error you need to start digging a bit. The JobID column shows you in which job to look.

Notice that I have to delete statements disabled by comment-tags. These are nice when you would like to reset the contents of the queue-tables. To execute the you need to mark them (without the /* and */) and execute.


Getting info from the log file and packages

The data exchange service offers a couple of tricks regarding its log file and the packages. The level of informations is setup in the Service Settings:


This offers lot of settings for the service but in this post I will only be touching a couple of them.


First, make sure you customize the right service and click Next until you get access to the Working Directory. This is where the files are dumped for processing by the service.


Moving on we can change the settings for the log file.


We have several relevant settings in this part. First of all the directory for the log file and the Log Level. As default it logs the errors only and that is often enough. If you want it to be more chatty you just click in what you want to know from the service. Notice, that the log file does get a bit overwhelming to look at if you click on everything.

Reading the log file can give you a very specific error to work with. With a field mismatch it could look a bit like this:

2016.2.24 9:40:27:412 (17528) [1] CSockConn::Listen: bind failed
2016.2.24 9:40:27:417 (17528) [1] AdminThread: ERROR: Listen failed on port 23. Check the Retail Store Connect setup for server HJHVIN02
2016.2.24 9:44:43:318 (14236) [1] CCommMgr::HandleException: Target request handler failed to process target request header: Microsoft.Dynamics.Retail.StoreConnect.Request.SQLHandler.ProcessTargetRequestHeaderException: ProcessTargetRequestHeader failed to execute all write requests. ---> Microsoft.Dynamics.Retail.StoreConnect.Request.SQLHandler.ProcessWriteRequestException: Write request on table:[dbo].[RETAILPOSITIONPOSPERMISSION] failed to execute. ---> Microsoft.Dynamics.Retail.StoreConnect.Request.SQLHandler.RunException: Run() failed while creating temporary table. ---> Microsoft.Dynamics.Retail.StoreConnect.Request.SQLHandler.CreateTempTableException: Query: SELECT TOP 0 [ALLOWBLINDCLOSE],[ALLOWCHANGENOVOID],[ALLOWCREATEORDER],[ALLOWEDITORDER],[ALLOWFLOATINGTENDERDECLARATION],[ALLOWMULTIPLELOGINS],[ALLOWMULTIPLESHIFTLOGON],[ALLOWOPENDRAWERONLY],[ALLOWPASSWORDCHANGE],[ALLOWPRICEOVERRIDE],[ALLOWRESETPASSWORD],[ALLOWRETRIEVEORDER],[ALLOWSALESTAXCHANGE],[ALLOWTENDERDECLARATION],[ALLOWTRANSACTIONSUSPENSION],[ALLOWTRANSACTIONVOIDING],[ALLOWXREPORTPRINTING],[ALLOWZREPORTPRINTING],[MANAGERPRIVILEGES],[MAXIMUMDISCOUNTPCT],[MAXLINEDISCOUNTAMOUNT],[MAXLINERETURNAMOUNT],[MAXTOTALDISCOUNTAMOUNT],[MAXTOTALDISCOUNTPCT],[MAXTOTALRETURNAMOUNT],[NAME],[POSITION],[POSPERMISSIONGROUP],[RECID],[USEHANDHELD] INTO [#dbo_RETAILPOSITIONPOSPERMISSION_6a5067cd-ba66-41c4-bf8f-da7dc918b25e] FROM [dbo].[RETAILPOSITIONPOSPERMISSION];
 ---> System.Data.SqlClient.SqlException: Invalid column name 'ALLOWPASSWORDCHANGE'.



Another feature is the “Keep Packages Files”. It keeps the files in the working folder for later review. Again, this will leave you with a lot of data in the directory.

With the Keep Package Files set you get a couple of files in the work folder with the .tmp extension. One that ends with an I and one that ends with an R. The I file is the definition of the data model and the R file is the actual data. As is they are close to unreadable. So to get the result we can use the Pack Viewer tool. It is started from the Start menu next to the Service Settings.


Select the file you want to convert. The target folder is automatically filled in. You can change it without any problems. Mark the Open Folder to open the target folder when done and click the Convert button.

The I file gives you one file that looks like this:


Converting the R file you get a multiple files depending on the number of tables in the package:


They are named with the table name for easy access. The SCTargetRequestHeader file is a content and action overview. The data files are easy(-ish) read XML files with the complete data set to be transferred.


Remember to disable the keep package flag when done and restart the service.


This is not the full and complete troubleshooting guide but a quick intro to a couple of entry points when struggling with an AX 2012 R2 Retail.

Troubleshooting AX/SSRS

The purpose of this document is to list a troubleshoot path to follow when reports cannot be printed from AX 2012.

The contents are not fully covering all options available but points out a toolbox for handling often seen issues.


Is it all reports not printing?

Try printing one of the most simple reports available. I usually use the Departments report found in “Organization administration / Reports / Base data / Departments”. If that one prints successfully it is probably not the SSRS causing the problem.

Is SSRS set up correct within AX?

AX has a very flexible setup regarding SSRS. Each AOS has – and must have – its own relation to an SSRS. All AOS’s can point towards the same SSRS but it is also possible to address the reports from each AOS to its own SSRS instance. One AOS can on top this have multiple relations to different SSRS instances. However, only one relation can be default and active.
So how do we make sure all this works?
1. Make sure that all AOS servers have a relation (with default mark set) to an SSRS instance in the SSRS list (Appendix 1 – Locating the SSRS names)
2. Validate the relations using the “Validate settings” button.
3. Verify that the specified URLs are valid.

Is SSRS set up correct regarding connection to AX?

With AX pointing towards the right SSRS instance we need to make sure that the SSRS instance points towards a valid AOS. With only one SSRS instance on the server it – by default – looks up the default client configuration on the server to access AX. Having multiple SSRS instances on one server requires each instance to have an configuration file with the name Microsoft.Dynamics.AX.ReportConfiguration.axc. Make sure that this configuration file is valid. For instance by opening a client with it if possible. Also make sure that the WCF part of the file is fully updated. To rebuild the WCF part follow the description in the section Rebuild the WCF part of the AX configuration for the SSRS.
Another way to test that multiple instances points towards the correct instances is to create eg. a department called “Development” in a development environment and one called “Test” in the test environment and then verify that these are shown when printing from the relevant AX environments or the SSRS report manger site (see description of how to print from outside the AX client).

Does it print from outside the AX client?

SSRS offers a web frontend allowing us to test – at least some – reports from outside AX pretty easily. To do so you need to find the URL address to the report manager site. This is listed in the Report server list found within AX. To find this list please read the description in Appendix 1 – locating the SSRS names.
From here navigate to the URL specified in the field Report Manager URL.
If this does not open up succesfully go directly to restarting the SSRS service.
aIf it opens up successfully click on the DynamicsAX folder and use the Search field in the upper right corner to locate the report design HcmDepartmentReport.DepartmentDesign

Printing reports from the SSRS Report Manager

Printing reports from the SSRS Report Manager

Click on the report to show it. If a report is shown the report server and the connection works.
If not printed successfully you might be presented with an error description pointing you in a useful direction.
Rebuild the WCF part of the AX configuration for the SSRS
The WCF part of the AX configuration describes the service ports available. It can be usefull to rebuild these in some circumstances eventhough you do not think they have been altered. To update this open the Microsoft Dynamics AX Client Configuration on the server running the SSRS. Click Manage and “Open a configuration file…”. Navigate to C:\Program Files\Microsoft SQL Server\MSRS11.<Name of the relevant instance>\Reporting Services\ReportServer\bin and select the file Microsoft.Dynamics.AX.ReportConfiguration.axc.

Rebuild the WCF part of the configuration file

Rebuild the WCF part of the configuration file

On the Connection tab click the Refresh Configuration button and wait …

Waiting for the WCF to be rebuild.

Waiting for the WCF to be rebuild.

When completed click Apply and “Manage / Save configuration file”.
After saving the file restart the SSRS-service.

Appendix 1

Locating the SSRS names

The name of the server can be found from within AX by looking up the reporting server(s) listed in “System administration / Setup / Business intelligence / Report servers”.
Notice, that the list can contain multiple SSRS instances and not all of them are related to the environment you are trying to fix.

Restart the SSRS-service

This is a fairly quick service when it comes to restarting so you will not be troubling users for that many seconds.
Log on to the server running SSRS. From here locate the service “SQL Server Reporting Services (<Name of the relevant instance>)” and restart it.