Gartner Magic Quadrant

In a recently published research report (June 4), Gartner places Microsoft Dynamics AX as the leader in the Midmarket and Tier 2-Oriented ERP for Product-Centric Companies.

"Gartner concludes that only one offering qualifies as a leader in the
market at this time: Microsoft Dynamics AX."

This is good news for everyone involved in both using and delivering services around AX, especially if you are working with AX 2009. I have been blogging about some of the features and changes in AX 2009 for some time and I find my own oppinion to be aligned with what Garter expresses around the technological aspects.

After reading the report, I thought about my experiences with Axapta/AX and I found it worth summarizing my history with Axapta and AX to put the product envolvement in a subjective perspective (from Damgaard via Navision to Microsoft as software vendor):

I first looked at Axapta 2.1 in 2001 and back then, it was considered to be a product with quite rough edges (a very young product born around 1998). The company I worked for at this time, decided to wait until version 2.5 before doing the first implementations. We got a lot of experience from these implementations and discovered that the product still had some rough edges (for instance the returning issues around the famous axdat.udb file espesially in solutions with clustered Application Object Servers). Then we got Axapta 3.0 adding more functionality. Axapta was already branded as a true international solution, but the requirements for doing a central implementation supporting users in different time zones, was driving the requirement for the number of AOS licensed heavily and such solutions did'nt support access to the data stored in the AX database across time zones (it was at best Unicode enabled if you remembered to enable this before synchronizing the database for the first time). This was also in the same period where Microsoft bought Navision. After using more time on finding work arounds to technical issues compared to bringing value to the customers, I decided to do something else for the next 3 years (I was a little bit fed up to be honest). When the opportunity to return to what then was called AX (4) back in 2007, I first considered the architectural changes (eliminated the axdat.udb file and put the license/session handling into the database, replaced the AOCP protocol with RPC, buildt a new Web application based on SharePoint, a pure 3-tier architecture and a greater range for the very important RecId value) and found it very promising. Based on this, I decided to give AX a second try. My experience with AX 4, proved that AX 4x was a big step in the right direction with regards to architecture. Now we only lacked support for handling users accross different time zones on one (or several) AOS instances with scaling and redundancy beeing the drivers for the number of AOS licenses required. This was finally introduced in AX 2009 and for the first time, I considered AX to live up to the promise of beeing a true, international solution. Add even tighter integration to other Microsoft products and technologies, and a Web Application "bringing BI to everyone" through a role based Enterprise Portal, and AX 2009 was positioned to compete with the other 2 main rivals also in the Enterprise Market.

I don't regret returning to AX and I'm rest assured that AX 2009 and later releases, will move further up and to the right in the Magic Quadrant "cementing" it's position as the most agile and TCO effective ERP solution on the market. SAP Business One is of course a serious player and it will be interesting to see how the competition evolves the next years.

So what's my point here? Given the history of AX and the fact that Microsoft now has done the necessary and required changes with regards to the architecture (not a small task), the product enters a new era. Companies looking for a new ERP solution, should indeed evaluate AX 2009 in line with both SAP and Oracle. And existing AX customers running on a version prior to AX 4, should work through their exisiting solution either aiming at eliminating as many customizations as possible or in fact re implement AX 2009 with a clear strategy around utilizing standard functionality to lower TCO over time and keep in pace with new/added functionality. It's in my oppinion all about positioning for a very exiting product cycle where I expect a lot of new functionality to be introduced (both horizontal and vertical) and less architectural changes!

Some information about the next release of AX (6) is already available (AOD files moved from file system to the database, increased range for ObjectId etc.). Some will probably argue that this is architectural changes, but as I see it yet not ground ground breaking compared to the changes already implemented in AX 4 and AX 2009. If you have access to the Product Roadmap, you can read what Microsoft is planning for the future and my final word, is the fact that Gartner concludes that Microsoft is delivering on their vision and that this is one of the key reasons for Gartners conclusion!

Happy reading.

Approaching GO LIVE

For those of you that have read my prior posts regarding AX 2009 and AIF with the AX BizTalk adapter, we have been working with our first implementation since June 2008. Without going into the details, we are approaching GO LIVE and the latest configuration is done this week such as defining the final endpoints. We basically have a solution with a set of front line services (FTP) in the perimeter network and BizTalk Server 2006 R2 togheter with AX 2009 in the local network tied together with some middleware. Not revolutionary or innovative, but a simple, cost effective and robust solution based on proven technology.

The test results so far are good and we are ready to GO LIVE tying a lot of trading partners to the client. We will have sales ordres, purchase orders, packing slips and picking lists flowing, in addition to invoices in different shapes and flavors. First phase is roll out in one country and two additional roll out phases are planned for the next months. By roll out in this context, we talk about markets with a set of different trading partners for each market.

Stay tuned for general updates!

AX 2009 SP1

I recently got information telling that Service Pack 1 for AX 2009 is pretty close to RTM. I don't have any information about what it contains, but let's hope SSAS and SSRS for SQL Server 2008 is fully supported.

Maybe some more information will be published during the upcoming Convergence conference in Copenhagen (November 19 - 20).

In addition Microsoft has released at least one kernel hot fix for AX 2009 with reference to the "non existing" KB article 958328. It' still hard to find any information about this hot fix, but I know Microsoft is working on the KB article. As usual, hot fixes are provided directly from Premier Support (or other official Microsoft support channels), while the KB articles still are published on Partner and/or Customer Source. Kernel hot fixes are distributed as a set of MSP files which also is a good thing as I see it.

With this said, our experience so far has been pretty good and the quality of the RTM release seems to be better that 80/20 (we haven't yet experienced any big issues except for the technical issues described in an earlier post). So at this stage and after working with the release for almost 5 months, it looks as a big step in the right direction. We are still working with AIF and the BizTalk adapter, and except for some minor issues, we have been able to proceed as planned on our current project deliveries.

First Experiences

First of all; Dynamics AX 2009 is really exiting with regards to the tight integration with the Microsoft Technology Stack. The product is really starting to take shape in the technology area and it's starting to look as a Microsoft product (remember the history... Damgaard, Navision, Microsoft?). At the same time the complexity has increased and this of course both affects the time and skills needed to implement AX.

My journy so far is based on experiences from one customer installation (Core solution by now) running Windows Server 2003 R2 Standard x64 and from a single computer installation running on Windows Server 2008 Standard x32.

NetBIOS over TCP/IP: At a customer site I experienced problems connecting clients to the AOS instance ("A connection to the Axapta Object Server could not be established") - the initial startup of the AOS service for the instance, went fine. After trying some tweaks, I had to ask the hosting partner for a network trace. It turned out that the problem was that NetBIOS over TCP/IP was deactivated. After activating this (network card, Properties, Advanced, WINS, Enable NetBIOS over TCP/IP) on the AOS and servers with AX client installed, it all went smooth. After looking into the details, I think the reason is that AX from version 4 uses Remote Procedure Call (RPC) for communication between clients and AOS instances, and that RPC requires NetBIOS over TCP/IP. Perhaps Microsoft should put this into the system requirements for AX?

Installing the application component on 64-bits Windows Servers: I had a hard time trying to change the location for the application files from the installer. I almost always installs the application component to a different location than \program files\..\, but this turned out to be very hard on a 64-bit Windows plattform... I did'nt have the time to try out a silent install utilizing a parameter file and the solution could be to specify the location here. No matter what I changed, it defaulted to \program files\..\ and I could'nt change it because it was disabled for editing. I ended up doing the installation followed by copying the files to the correct location as separate application instances. By doing it this way, I have all the original setup information left as a master. This does'nt happen when installing on a 32-bit Windows plattform and here you can change the location freely.

SQL Server 2005/2008: If you only are going to implement AX CORE components (application, AOS instance and database) SQL Server 2008 is supported. If you on the other hand are going to use Reporting Extentions (the AX integration against SQL Server Reporting Services - SSRS) and/or Analysis Extentions (AX integration against SQL Server Analysis Services - SSAS), you have to use these components from SQL Server 2005. Also remember that both SSRS and SSAS are required if you want to use Enterprise Portal (the Web application module in AX) since the Role centres are composed of Web parts that shows SSRS reports (Report Viewer) and that the KPIs also are produced through SSRS reports utilizing SSAS. A former collegue has already an entry about this in his blog, but unfortenately I didn't read his post until after doing the exact same experience. But I totally agree with him that Microsoft should fix this compatibility issue as soon as possible, especially since SQL Server 2008 now are in RTM and supposed to fit very well with AX 2009. Another thing worth mentioning if you are going to install SQL Server 2005 on Windows Server 2008, is that you have to install the IIS6 compatibility components before installing SQL Server 2005.

.NET Framework 3.5: This is a general requirement, but I went away installing .NET Framework 3.5 SP1 as this is the latest release... After installing Enterprise Portal and doing the initial configuration, I ended up with an error message saying "Unhandled Exception" when browsing the site and an repeating error logged in the eventlog (application) saying "An unexpected error has occurred - A ProgressTemplate must be specified on UpdateProgress control with ID 'AxProgressControl'". As usual when encountering these kind of errors, I used Google to search for references. I found one link saying that the solution was to uninstall .NET 3.5 SP1 and reinstall .NET 3.5. All I can say is that it worked... This is also explained in the System Requirements page for Dynamics AX 2009 (says .net 3.5 and not .net 3.5 sp1), but at the same time Microsoft tells you to run Microsoft Update to get the latest security updates for your installation. I think many will be trapped by this one either when installing or later. Anyway I strongly advise you to inform your customers not to install .NET 3.5 SP1 (or any components like Visual Studio 2008 SP1 that updates .net) on the server hosting Enterprise Portal until this component is supported on .NET 3.5 SP1. If you arrive at the office one morning facing a non functional Enterprise Portal site, I would start by checking if .NET Framework 3.5 SP1 is installed...

Installation order: As explained by Microsoft in the AXInstallationGuide, you should always install and configure the Core solution first. Configuration is the same as running through the Installation Check List. After this, it all depends on the features or options required for the implementation. For a full implementation, it worked well for me by running the installation of each component in the following sequence: 1) Workflow 2) Reporting Extentions 3) Analysis Extentions and 4) Enterprise Portal. I installed each component individually and made the necessary configuration from the AX client both before and after the installation. One important part of the installation is to verify the setup logs to make shure everything was properly installed. Also read the documentation carefully to make shure all the pre requesites are met. I used Windows Sharepoint Services 3.0 SP1 (WSS) and installed this separately prior to installing Enterprise Portal (AX setup can do this for you). I ran the configuration, but did'nt create any applications or sites at this stage - just created the main service and the main database. My message is that you can end up with a lot of tricky errors if you install every option in one operation after installing and configuring the core solution. Also remember to fill in the information for the System Accounts before installing any options or additional components.

SSRS 2005 on Windows Server 2008: Remember the manual configuration required before installing Reporting Extentions. This is described in detail in the AXInstallationGuide. What you also should remember is to map the account for the AX SSRS application pool as a user in the SSRS databases.

Role centres: Some of the default Role centres still has errors with missing initial values for report parameters (I have'nt spent time trying to fix this yet). What I find a little bit more suprising is that a couple of the Role centres gives a "stack" of errors and messages saying that the dataset returned is larger that the default value. I don't have the details available right now, but I'll post on this later. The solution is rather simple - you have to increase the buffer size in the AOS instance configuration. I think it defaults to 24 Kb and by changing it to 25 Kb, I got rid of the errors and warnings. This is another area Microsoft should pay attention to and fix, since this is standard out-of-the box functionality that partners should'nt need to spend time on fixing.

This wraps up my first entry in this blog. Hopefully someone will find this information useful and please, don't leave a lot of "pingback" comments - it's impossible to have complete control over all the content out there. I promise to do my best to link to the source when this is applicable...