The Microsoft Dynamics AX 2009 Client has successfully completed the Certified for Windows Vista testing conducted by VeriTest.

Products that are certified to run on Windows Vista have passed an extensive set of tests conducted by an independent testing authority. These tests cover areas such as Security, Compatibility, Install /Un-Install and Reliability. The logo assures customers that Dynamics AX 2009 is among the elite applications that provide the best Vista experience.

The Certified for Windows Vista logo the more prestigious of the two Windows Vista Logo programs, the other being Works with Windows Vista which is given to an application that offers baseline compatibility.

Today Microsoft Dynamics AX 2009 is RTM. This means DVDs are now being mass produced, and the product is available for download at Partner Source.

My favorite features in DAX2009:

• Brand new UI: List pages, role centers, crumb-bar, activity centers and ribbons.
• Improved performance. Especially I like the near-instantly startup of the clients.
• Workflow support.
• Improved reporting and BI facilties; powered by SSRS.
• Enhanced developer experienced: TFS integration, XML documentation, ER diagrams, CLR interop and much more.
• New suite of tools for code upgrade.

I'm proud to have been a part of the extraordinary team building this extraordinary product, executing on a 2 year plan and delivering on time. Since you are reading my blog, I feel confident this product will have a postive impact on your professional life. Starting today!

We've had feedback from many sources (comments in this blog, emails, in-person meetings, partner advisory board, etc.) that we should fix the element ID problem in AX - the sooner the better. Thank you very much for this feedback. This post is intended to give a bit of background on this subject.

The element ID problem in AX causes pain on two fronts:

1. Uniqueness. Element IDs must be unique on any given installation. We have a suite of tools to help generating unique IDs, detect uniqueness conflicts, etc. Learning and using these tools are painful, resolving ID problems is even more painful, especially on live systems. Further the uniqueness issue makes it hard to combine solutions from different source in one installation.
   
2. Upper limit. Each layer has a finite number of IDs. This means there is an upper limit to how many model elements you can create. Microsoft's core development team knows exactly how this pain feels.

At any rate; this is a problem we need to address - and my team has been given the task. While many solutions spring to mind (use GUIDs or drop IDs completely) this is a case of Devil in the Details.

Business Data: IDs are persisted in the business data base. Any change to IDs would require upgrade scripts. To make matters even worse, IDs are also stored in unstructured blobs; making identification and migration even harder.

Business Logic: Business logic uses IDs. Both Microsoft's business logic; but certainly also the business logic in solutions authored by partners around the world. Changes to IDs would impact all this business logic.

Kernel: The implementation of the kernel used IDs heavily. Changing data type or dropping IDs totally would require rewrite of large portions of the kernel. The kernel provides the API for converting IDs to names and back again.

Application model: IDs (and Names) are stored in the Application Model. IDs are used as references between model elements and IDs bind customizations to the original element. Whatever changes we make, we cannot break the references in the model.

Getting challenges like this is what I love about my job.