Microsoft Dynamics AX 2012 relies on Microsoft SQL Reporting Services to provide reporting capabilities to AX users.
Here are a couple of tricks and tips that I have learned over the years and for which I could not find any reference online. Maybe there is some documentation out there, what it was hard for me to find it when I needed it.
TIP #1. - Make sure you have all the permissions you need
Besides the required permissions in AX to deploy reports, the AX user’s domain account must have the appropriate permissions defined in SSRS. The domain user account must be able to access the SSRS Report Manager website and at least be assigned the Content Manager role in the Dynamics AX reports folder.
To test that my user has all the permissions I need to deploy reports, I usually open an Internet Explorer browser and go to the SSRS Report Manager website. Then I try to open the Dynamics AX folder. If that works then I temporarily create a subfolder within the Dynamics AX subfolder. If I am successful, it usually means that I have what I need to publish reports.
Maybe this is not the proper way to do it, but it has worked for me every time.
Note: Don’t forget to delete the created temporary folder.
TIP #2. - Pointing in the right direction
As many of you know, one Dynamics AX client can point to different AX instances installed on different servers. As an example of this, you can have a Terminal Services server with the AX client installed and then have that AX client point to a DEV instance, a TEST instance, and even a Production AX instance.
To have your AX client point to an instance you have two options:
- Set your domain user session’s AX active configuration by using the Microsoft Dynamics AX Configuration Utility, click Apply or OK, and then click on the standard out-of-the-box “Microsoft Dynamics AX 2012” shortcut. This will use the active configuration to connect to the AX AOS server.
- The other option is to export an AX configuration to a file. This will create a “.axc” file that you can double-click on and will launch AX and point it to the AX AOS server specified for that configuration. Very convenient to avoid the extra steps in option #1.
Now here is the tip.
When deploying reports, Visual Studio and AX will use the session’s active configuration to determine the target AOS and SSRS servers. (Hard-to-find information)
If for some reason you used a shortcut that points to DEV and the active configuration points to TEST, the reports will be published in the TEST environment, even though your AX client points to DEV.
You will notice something is wrong only after you have tried to deploy your report 1, 2, or maybe 20 times and your changes don’t show up when printing the report.
Not only that, this also affects the layers where you are making your changes. If your AX client points to the VAR layer and the active configuration points to the USR layer, you’ll have some of your changes in the VAR layer and some of them in the USR layer.
So the tip is to make sure your active configuration matches the environment and layer that the AX client is pointing to.
I have learned to not create AX shortcuts anymore as it creates a lot of confusion.
This article was written by Eduardo Sicouret, Dynamics Technical Consultant for Tridea Partners. Tridea is a leading Microsoft Dynamics provider.