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...
Posts
