This issue is a permissions issue somewhere. At this point, we need to determine if its an issue with the user accessing the report. You can do the below troubleshooting steps. This was the order I did it in but you don't have to do it in this order.
- SSRS server (server permissions)
- SSRS reports (SSRS permission restrictions)
- AX security issue (probably not but good to check)
- An issue with all users or just them
- An issue with local cache or something screwy with current windows session
To help the users identify this issue, I usually ask them to do the following on the server where they are receiving this error:
- Click on the Start menu in Windows
- Type 'cmd' in the 'Search programs and files' search line in the start menu
- In the command prompt, type 'ping CDBRS-MAX01'
- Take a screenshot of the command responses and send back the results.
- The results should come back with the standard ping response of 'Reply from XX.XX.X.XXX: bytes=32...''.
Having established they can access the report server, have the user access the report through the SSRS server. Have them do the following in the server where the AX client is erroring and if necessary, the SSRS report server itself:
- Go to internet explorer and access the SSRS report server (commonly 'http://[SSRSSERVERNAMEHERE]/reports'
- Once here, go to 'Dynamics AX' folder
- click on the report that is erroring
- Run the report and see if it runs. Just make sure required fields are populated.
Have the user run the report from a server other than the one where the user was encountering the error. I logged into the AOS on their machine under my name and did the hold shift+right click on the .axc file, enter their credentials so we were running AX as that user in my server instance, and try running the report.
Have other users attempt to run that report as well as others. Determine if its an issue with just that user. If no one is able to run the report or others, the reports may need to be deployed or the SSRS server settings need to be checked.
This actually resolved the issue. Something went wrong with the user's Windows server session. I wasn't exactly sure what the issue was but having the user log out and log back in to the server resolved.
In this test, do the following:
- go to the person's terminal and watch them try to run the report
- hold shift+right click on the .axc file they were using to run the report and run as a different user. Use your own user
- In AX under your user in their terminal session, try to run the troubled report.
- If it passes (it did in my instance), hold shift+right click on the .axc file and run as a different user, only this time use the person's credentials. For us, the user was able to run the report this way but not when just clicking on the .axc in the normal fashion