We have a large deploy with a customer this week which is a very bad time for AXBuild to stop working… really bad time. And ofcourse that is what happened (screw you Murphy). There are of course other ways to to a compile in AX byt doing it from within AX is really slow so AXBuild is much nicer and faster.
The problem was that when I launched AXBuild the process kept crashing with this error:
I also got the following events in Event viewer:
Error 14.11.2016 17:49:05 Dynamics Server 01 110 None
Object Server 01:
Can not create default Keyset. Error code -2146893809.
Error 14.11.2016 17:49:05 Dynamics Server 01 110 None
Object Server 01:
The license information can not be decoded.
Error 14.11.2016 17:49:06 .NET Runtime 1026 None
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception
Exception Info: System.Runtime.InteropServices.SEHException
When doing research we found that this is most likely a permissions issue and I got somen hints on what to check:
- Are you running elevated: Check
- Are you local admin on the AOS computer: Check
- Is the AOS user local admin on the AOS computer: Check
- Check AOS user permissions on the AX database and modelstore: Check
I was not able to find the solution so I resorted to Microsoft Support and they sait the same thing… it is a permission issue. So finally I fired up ProcessMonitor (which I don’t do often enough) and the it was after some looking around and filtering. I filtered out everything except the Ax32Serv.exe process and I also removed the SUCCESS lines.
The issue was that my user (the one doing the the compiling) got access denied on a file in the folder:
I changed the permission on the file and Presto! (or as one of my colleugues said – I am going to get a Cappuchino with cinnamon)
The compile is running and things are good
This morning we had an incident with a customer who during the night had failed over their SQL cluster during the night and then failed it back again and now AX had stopped working. The error was this:
The problem is that when SQL is restarted the permission on tempdb is reset. AX solves this is a “special” way. When AX is installed the install created a stored procedure in master on the SQL server which it calls to set the permissions in case they get lost.
These was unfortunately missing on one of the nodes so I used Management Studio to script them out and the create them on the node where they were missing
Today I did an inplace upgrade of AX 2012 CU 8 to CU 10 and found myself having a strange issue. As part of the upgrade you need to complete a checklist including such things as Compile application and detect conflicts… and there is also a couple of times where you need to restart the AOS. When I did this the checklist disapeared and I could not find it. Turns out you can restart it by going to System administration > Setup > Checklists > Software Update Checklist
That all for today folks…
This is a follow up to the last post regarding Reports in AX.
When I tried the report I published I got an other error: The DefaultValue expression for the report parameter ‘AX_CompanyName’ contains an error: Request for the permission of type ‘System.Security.Permissions.EnvironmentPermission
When I tried the report again it worked… Weird!
Apparently it has to do with the configuration of SSRS. If you open the SSRS configuration file called rssrvpolicy.config in
C:\Program Files\Microsoft SQL Server\MSRS12.MSSQLSERVER\Reporting Services\ReportServer
Find the line PermissionSetName=’Execution’ and change it to PermissionSetName=”FullTrust” (remember to make a backup of the file before you change it)
So this one involves Reporting Services and AX. One of my customers had an issue printing a report today and the error he got was that the report did not exist.
I checked the SSRS web UI and sure enough I could see it… The problem was that it was not correctly published from AX. To fix this I went into the UAT (Ctrl?D), found the report, right-clicked it and clicked Deploy Element.
I tried it and everything looked fine and dandy… or so I thought
When I went into the SSRS Web I found that the reports I just published ended up in a new subfolder and not in the standard DynamicsAX folder
Turned out there was an error in the AX Reporting Server Setup
So I changed it and everything worked fine. Remember to delete the extra folder that was created by mistake in SSRS Web.
So the problem was actually in my case not an issue with a published report… it was an error with the path containing reports…
That’s all for today
Today we look at a tiny issue… Permissions in problems. I got an email from a user containing the following error message:
This is quite a simple problem… with (in this case) a little twist. The customer is not using the default SRSS instance which meant that when I first tried to fix the problem I did it in the wrong instance .
To fix this, you first go to the AX client – System administration – Business Intelligence – Report Servers. Copy the information from the field called Report Manager URL, this should normally look like http://ReportServer/Reports but in my case it was http://ReportServer/Reports_AX_PROD_SSRS.
Start your browser and go to the URL you copied before. You should see something like this
Click the down arrow and select Security. Click New Role Assignment
Enter Domain users and check DynamicsAXBrowser… Since AX is normally handling the security of which data is displayed in the report it is not a problem to add Domain Users… I the user is not an AX user no data will be displayed
That’s all folks
If you use Dynamics AX 2012 R3, Management Reporter is included from the beginning. It is simply a feature you add from the install application. Prior to AX 2012 R2 you will need to download the install from Microsoft and install it. This is a short description on how to install Management Reporter and integrate it into AX 2012 R2.
My server Environment consists of one SQL server called SQL1, one AOS server called AOS1, one Management Reporter Server called MR1
I start by installing SQL locally on the MR1. The features installed are:
Then next thing is to install Management Reporter. This is a simple Next, Next, Finish install and when it is done you start the Configuration Console to do the actual work. The first thing to do is to select the AX 2012 Data Mart integration.
Now start the hard stuff… I will try to explaing the values as good as possible and also where it is easy to go wrong
- This is a Service account used to run Management Reporter. It needs to be a user in the AOS instance you want to connect to and it needs the role System Administrator
- This is the database server where Management Reporter keeps its own databases. In this case it is locally on the MR server.
- To create the databases on the MR server we use Windows authentication which is the account you are currently logged in as
- The name of the Management Reporter database
- This is an encryption key Management Reporter uses to encrypt information stored in its database
- This user is added to the Management Reporter as an admin
- This is the port which Management Reporter Client will use to connect to the Management Reporter Server
- This is the port used to connect to the AOS server instance. Note that if you have more than one instance on the same server this will be different for all instances. You can find port information for each instance in Microsoft Dynamics Ax Server Configuration Utility (Image below). In my case this is the third instance and the ports are 8203 and 2714.
- This is the AOS server (Note: NOT the instance name)
- See 8
- This is the database server where the AX database is located.
- This is the AX database name. Note that the service account will need atleast db_reader access to both the AX database and to the AX model database
- This is the database where the AX Data mart is stored. In my case this is located in the MR Server