SSRS Report label shown as @SYSxxxx in AX2012

Here in this blog I will share two scenarios when this happening and basic troubleshooting steps when facing this issue.


When you are rendering SSRS report, the data will load correctly, but all AX labels are not resolved:

Two known causes of this:

  1. SQL Server Reporting service version does not meet AX requirement.

    You can always check for latest system requirement for AX 2012 HERE. For reporting service, the minimum version is SQL 2008 R2 SP1

  2. Exception occurred during report definition processing.

Troubleshooting steps:

There is no one shoot solution for this, but general troubleshooting steps could help to identify the cause, here is a demo for one of my scenario.

  1. AOS is using meta data service to provide the interface to resolve label, which is hosted on WCF service. Ideally we will trace to verify if the label resolve step is happening or not.

    To do that, we can enable WCF trace on AOS and capture the WCF requests. Sample of the trace file as below (highlighted in yellow are where the changes were made):

    <startup useLegacyV2RuntimeActivationPolicy=”true”>

    <supportedRuntime version=”v4.0.30319″ />

    <requiredRuntime version=”v4.0.30319″ safemode=”true” />



    <source name=”System.ServiceModel.MessageLogging”>
    <add name=”messages”
    initializeData=”c:\logs\messages.svclog” />






    <binding name=”QueryServiceBinding” sendTimeout=”00:10:00″ transferMode=”StreamedResponse” maxBufferSize=”65536″ maxReceivedMessageSize=”104857600″ listenBacklog=”200″ maxConnections=”200″>

    <readerQuotas maxStringContentLength=”104857600″ />


    This will create a messages.svclog file under C:\logs. You may put it to somewhere else. We need to merge this xml content to Ax32Serv.exe.config and restart AOS to apply the change.

    Restart AOS and reproduce the issue again, then check the meesages.svclog to find label resolve step:

  2. As we can see AOS has already processed the label resolve request, and all results has been sent via response. Which means something wrong on reporting service side. Next we will need to use ProcDump to capture first chance exceptions to find clues from reporting service side. Attach to reporting service with ProcDump with command as below:

    ProcDump.exe -e 1 -f “” ReportingServicesService.exe

    Now we process the report again and able to see an exception message interest as below:

    Invalid enum value ‘GMTMINUS0300SANTIAGO’ cannot be deserialized into type ‘Microsoft.Dynamics.AX.Framework.Services.Metadata.Enums.TimeZone’. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

    That this exception interrupted the report processing.

  3. A quick check about this Enum ‘GMTMINUS0300SANTIAGO’, which was added by a code change:

    Timezone rules for Dynamics AX need to be updated to the latest windows patch – 10/2015

    KB3110276 released 11/10/2015

  4. Check the ax extension version against the reporting service, the extension dll was RTM version. Which is introducing current issue.

    Image path: c:\windows\assembly\gac_msil\microsoft.dynamics.framework.reportsextensions\\microsoft.dynamics.framework.reportsextensions.dll

    Image name: microsoft.dynamics.framework.reportsextensions.dll

    File version:

    Product version:


Upgrade the AX report extension on reporting service machine to resolve this issue.