AX 2009 and edition of SQL Server Analysis Services

I recently came across an issue when trying to build a SSAS project containing modifications to the standard AX Cubes.

When building or rebuilding the project, I got 1 047 (!) errors with the description "Dimension [x] : Only dimension attributes and attribute relationships can have translations in Standard Edition."

The only solution to this is to (try to) modify the SSAS database in SQL Server Management Studio by some heavy scripting. Or of course upgrade SSAS to Enterprise Edition which I really don't know is legal without licensing Enterprise Edition (I'm trying to clarify this). Anyway it's a valid upgrade path regarding to the information given by Microsoft for SQL Server 2008 R2 (Version and Edition Upgrades) on MSDN.

The system requirements for AX 2009 doesn't contain any information saying SSAS Enterprise Edition is needed and neither does the general SQL Server reqiurements.Until further noticed and official information is given from Microsoft, it's worth having this in mind when deciding which edition of SQL Server to use together with AX 2009.

The only information from Microsoft I have found on this issue, is in a draft document titled "How to add financial dimension to Dynamics AX default cubes" (PDF) from the EMEA Dynamics Support blog on MSDN. On the bottom of page 3 and the beginning of page 4, the following information is given:

This is the only information from Microsoft I have found and despite this beeing a draft document, it clearly states that the system requirements should be updated alternatively that another soultion is provided. From this I understand that you have to backup the OLAP database and restore it to an instance of SQL Server 200x Developer Edition (equals Enterprise Edition in functionality), create a project in BIDS, build and deploy the changes to Developer Edition, and finish doing a final backup - restore sequence back to the production instance of SSAS.

In general, I think most customers will end up designing their own cubes and modifying the needed Role Centers accordingly, to avoid all the struggle with the default cubes.

Experience doing an AX 2009 Complete Install

A short update on my experience from doing a complete install of AX 2009 with dedicated servers for each server role.

First of all, the process went quite well and the only struggle was to get all the Service Principal Names (SPNs) correct including named instances and the SQL Server Browser service on the SSAS server.

Main take aways:

• Spend time on planning and account for some issues related to Kerberos authentication (hard to estimate)
• Follow the latest version of the AX Installation Guide
• Make sure you deploy the latest Cumulative Rollup package for AX (and other services)
• Bookmark the AX EMEA Support Team Blog (very valuable source of information)
• Make sure each component work as expected before you proceed the install and configuration sequence

After installing SharePoint 2010 for the first time, I also have a suggestion for Microsoft regarding AX setup - please have a look at the SharePoint 2010 Products Preparation Tool (shown below) and incorporate this idea into the next release of AX.

AX 2009 Rollup 6 and KB 2278963 (SharePoint 2010)

Finally I'm doing a complete install of Dynamics AX 2009 on a new plattform for a customer! While performing the installation of the core solution, my verified plan (verified by Microsoft) was to install in this sequence:

1. AX 2009 RTM patched with binaries from the KB
2. AX 2009 SP1
3. AX 2009 SP1 RU6
4. Initialize
5. Apply application fix for the KB

Everything went according to plan until step 5. This step failed with the following message:

This update is not applicable to your installation of Microsoft Dynamics AX because wrong version of application files is installed. This update is applicable to version 5.0.1000.52-5.0.1500.3560 of application files.

Setup could not complete the installation.

After checking my sources and discussing with Microsoft without any progress, I decided to install a second application in this sequence:

1. AX 2009 RTM
2. AX 2009 SP1
3. Initialize
4. KB 2278963
5. AX 2009 SP1 RU6

This time everything went according to plan and based on my experience, one of the following are true for this issue:

• KB2278963 application hotfix is forgotten with regards to RU6

or

• KB2278963 is included but not documented as part of RU6 (or RU5)

or

• Wrong version is used when the axupdate process verifies the application version (max is 5.0.1500.3760 - RU6 gives 3761)

The worst thing is that I had to spend extra time and effort doing a new install and 2 compilations in addition to installing a separate AOS and a Client to work on the same versionlevel.

AX 2009 64-bit AOS instance memory usage

I have seen some people asking if the 64-bit "edition" of the AOS kernel is capable of utilizing memory above 2 Gb (search microsoft.public.axapta which by the way is or is going to be retired). The snapshot below is taken from a customer site.

Working Set equal to 2 Gb and Peak Working Set equal to 4,1 Gb - say no more.

Question

A little challenge to my readers:

Can You tell me what I'm trying to illustrate in the graph below?

A couple of tips along the way

• it's closely related to Microsoft and Dynamics AX 2009 SP1...
• the average is almost 69...

Please leave your answer as a comment.

Follow Up on Event ID 110 and 117 (annoying database error)

I wrote about this a while ago and since this still is what I call an annoying database error (noice) and something very common to AX 4.0/AX 2009 solutions, I would like to call on my readers to vote for a change in the AOS kernels (x32/x64) to filter out this information to prevent bombing the event log with errors not beeing errors at all. The voting can be done at Microsoft Connect.

Finally I would like to quote a paragraph in Microsoft KB article 143339:

Applications need to code their error handling routines for SQL Server connections to call SQLError() until it returns SQL_NO_DATA_FOUND, and act on any messages other than the ones that return a pfNative code of 5701 or 5703.

Maybe it's impossible to change this behaviour, but as long as Microsoft don't state this in their feedback on Connect, it's still an issue that I find hard to accept...

AX 2009 - deadlocks

I recently conducted a system review at a customer site and discovered a message totally new to me beeing logged in on all AOS: "Object Server xx: Dialog issued for client-less session 1: Cannot edit a record in LastValue (SysLastValue). User ID: ,AdminUserSetup. Deadlock where one or more users have simultaneously locked the hole table or part of it."

The database at hand was not configured to use Read Committed Snapshot Isolation (RCSI) as recommended by the AX Performance Team. Enabling RCSI on the database solved the issue.