Error when installing Reporting Extensions for AX2012 R3 on SQL 2014 SSRS

Hi

I could not really find any posts on this out there, so I decided to just share this here.

You may experience installation errors when you try to install Reporting Extensions for AX2012 R3 on SQL 2014. The setup crashes internally, rolls back the installation and fails.
In the installation log you will see the error "Version string portion was too short or too long".

The solution is available on LCS as a downloadable hotfix KB3216898 (released 10th of January 2017) here:
https://fix.lcs.dynamics.com/Issue/Resolved?kb=3216898&bugId=3800976

Unpack the content of the hotfix and slipstream it as part of your AX2012 R3 installation and run the installation again. Now it will work.

Just to make this sure people find this post if they search for the errors, I'll add the full call stack below:

An error occurred during setup of Reporting Services extensions.
Reason: Version string portion was too short or too long.
System.ArgumentException: Version string portion was too short or too long.
  at System.Version..ctor(String version)
  at Microsoft.Dynamics.AX.Framework.Reporting.Shared.SrsWmi.get_ReportManagerUrl()
  at Microsoft.Dynamics.Setup.ReportsServerInstaller.GetOrCreateServerConfiguration(String instanceName, String sharePointServiceApplicationSite, Boolean& createdConfiguration)
  at Microsoft.Dynamics.Setup.Components.ReportingServicesExtensions.InstallConfigurationFiles(String instanceName, String sharePointServiceApplicationSite, Boolean& createdConfiguration)
  at Microsoft.Dynamics.Setup.Components.ReportingServicesExtensions.RunReportingSetupManagerDeploy()

Using PowerShell to list the 10 most recent KBs installed in AX2012 R3

I was asked to get an overview of the most recent KBs installed on an AX2012 R3 environment.
One way to do this is using PowerShell.
We know each KB is deployed as a single model, and we know each model installed will have a unique ID. This ID is incremented automatically by the system, so why not just sort on it, in a descending fashion.

Look at the following PowerShell command:

axmodel | 
where {$_.Name -match 'KB'} | 
sort modelid -Descending | 
select modelid, displayname, version, description, details -first 10 | 
out-gridview

I assume the default environment picked up by the command "axmodel" (alias for Get-AXModel) is the one we want to query. You can put in a "-Verbose" after the command if you'd like to see some verbose information about what ModelStore database the command operates on.

I then add a filter on the list, making sure I only get models having a match on "KB" in the Name property. I could also have looked for the word "hotfix" in the Description property. The string is not case sensitive.

I then pipe the result to a sorting where I want the list sorted descending on the ModelId.

I select out only some of the columns, and I also pick out the first 10 of the result.

Finally I send the result to the GridView Window, just because I like to see the result in a nice window (which allow for resizing, column resizing, filtering, etc).

Notice also that I can have this entire command on multiple lines, and the trick is that PowerShell will allow this when you use Pipe (|) like I am doing above. Otherwise, a line-break is interpreted as execution of a command, so be aware of that when running a "multi-line" PowerShell command.

You can also use the example above to do other things, like looking for specific KBs and check if they are already installed.

Enjoy!

Compiler warnings when using AXBUILD

When you run AXBUILD with AX2012 R3 you might notice there are some classes that throws warnings, even though you know they are not customized. Why is that?

Here is an example running CU10 and the following classes are flagged for investigation.

*** Bad element: \\Classes\AssetBookBonusMethod_IN
*** Bad element: \\Classes\PCImportModel
*** Bad element: \\Classes\VendInvoicePostBatchCleanup

The reason these classes throws warnings is the SysObsoleteAttribute where you can force compiler warnings with the second parameter.

There are system classes marked as obsolete and while you could argue they should be removed, there may be dependencies to them - out there somewhere -still.

Error during install of Microsoft Report Viewer 2012

When installing the client for AX2012 R3 CU8 or later, one of the requirements is installing Report Viewer 2012. The prerequisite Validation step will inform you the component is missing, and it will provide the download link.

However, depending on your scenario you might need to download and install Microsoft System CLR Types for SQL Server 2012.

The error is "Setup is missing an installation prerequisite".

You can download the necessary components from Microsoft SQL Server 2012 Feature Pack.

Or you can download it directly using the following links:
32bit http://go.microsoft.com/fwlink/?LinkID=239643&clcid=0x409
64b http://go.microsoft.com/fwlink/?LinkID=239644&clcid=0x409

Fixing firstDayOfWeek and firstWeekOfYear in AX2012

I was asked to have a look at why the date picker in AX still chose Sunday while the user expected Monday. I remember fixing this back in AX2009, so I was curious to see how this was solved in AX2012. The Global class and the methods firstDayOfWeek and firstWeekOfYear caught my attention. One of them used the current users language as key to find the best possible calendar setting, while the other picked the default system setting. Well, let us rewrite this and make it work a bit better, and since sharing is caring - here is how I solved it.

Global::firstWeekOfYear served as an inspiration, but I want it to differentiate between whatever languages my environment is serving. I can live with one cached result for each language, and the performance penalty is low and acceptable.

static int firstWeekOfYear()
{
    #WinAPI
    SysGlobalCache  cache   = classfactory.globalCache();
    int             clientFirstWeekOfYear;
    anytype         calendarWeekRuleValue;
    // Axdata.Skaue ->
    /*
    str             language;
    */
    str             language = currentUserLanguage();
    // Axdata.Skaue <-
    System.Globalization.CultureInfo        userCulture;
    System.Globalization.CalendarWeekRule   calendarWeekRule;
    System.Globalization.DateTimeFormatInfo userDateTimeFormat;

    // Axdata.Skaue ->
    /*
    if (cache.isSet(classStr(Global), funcName()))
    */
    if (cache.isSet(classStr(Global), funcName() + language))
    // Axdata.Skaue <-
    {
        // Axdata.Skaue ->
        /*
        clientFirstWeekOfYear = cache.get(classStr(Global), funcName());
        */
        clientFirstWeekOfYear = cache.get(classStr(Global), funcName() + language);
        // Axdata.Skaue <-
    }
    else
    {
        // Axdata.Skaue ->
        /*
        language = currentUserLanguage();
        */
        // Axdata.Skaue <-
        userCulture = new System.Globalization.CultureInfo(language);
        userDateTimeFormat = userCulture.get_DateTimeFormat();
        calendarWeekRule    = userDateTimeFormat.get_CalendarWeekRule();
        calendarWeekRuleValue = CLRInterop::getAnyTypeForObject(calendarWeekRule);

        switch(calendarWeekRuleValue)
        {
            case CLRInterop::getAnyTypeForObject(System.Globalization.CalendarWeekRule::FirstDay) :
                clientFirstWeekOfYear = 0;
                break;
            case CLRInterop::getAnyTypeForObject(System.Globalization.CalendarWeekRule::FirstFullWeek) :
                clientFirstWeekOfYear = 1;
                break;
            case CLRInterop::getAnyTypeForObject(System.Globalization.CalendarWeekRule::FirstFourDayWeek) :
                clientFirstWeekOfYear = 2;
                break;
        }

        // Axdata.Skaue ->
        /*
        cache.set(classStr(Global), funcName(),clientFirstWeekOfYear);
        */
        cache.set(classStr(Global), funcName() + language,clientFirstWeekOfYear);
        // Axdata.Skaue <-        
    }

    return clientFirstWeekOfYear;
}

Using the same ideas, I changed Global::firstDayOfWeek. Again, I allowed for one cached result for each language.

static int firstDayOfWeek()
{
    // Axdata.Skaue ->
    /*
    System.Globalization.DateTimeFormatInfo fi;
    */
    int dow;
    str             language = currentUserLanguage();
    System.Globalization.CultureInfo        userCulture;
    System.Globalization.DateTimeFormatInfo userDateTimeFormat;
    // Axdata.Skaue <-

    SysGlobalCache  cache   = classfactory.globalCache();
    int             clientFirstDayOfWeek;

    // Axdata.Skaue ->
    /* 
    if (cache.isSet(classStr(Global), funcName()))
    */
    if (cache.isSet(classStr(Global), funcName() + language))
    // Axdata.Skaue <-
    {
        // Axdata.Skaue ->
        /* 
        clientFirstDayOfWeek = cache.get(classStr(Global), funcName());
        */
        clientFirstDayOfWeek = cache.get(classStr(Global), funcName() + language);
        
    }
    else
    {
        // Axdata.Skaue ->
        userCulture         = new System.Globalization.CultureInfo(language);
        userDateTimeFormat  = userCulture.get_DateTimeFormat();
        dow                 = userDateTimeFormat.get_FirstDayOfWeek();        
        /* Removed
        fi = new System.Globalization.DateTimeFormatInfo();
        dow = fi.get_FirstDayOfWeek();
        */
        // Axdata.Skaue <-
        
        // The .NET API returns 0 for sunday, but we expect sunday to
        // be represented as 6, (monday is 0).
        clientFirstDayOfWeek = (dow + 6) mod 7;

        // Axdata.Skaue ->
        /*
        cache.set(classStr(Global), funcName(),clientFirstDayOfWeek);
        */
        cache.set(classStr(Global), funcName() + language,clientFirstDayOfWeek);
        // Axdata.Skaue <-
    }

    return clientFirstDayOfWeek;
}

So, for those of you who have an environment supporting potential multiple calendar setups, I recommend applying the fix above, or write your own fix. If you know a more efficient and better way, please comment below.

Supporting multiple Enterprise Portals for AX2012

With AX2012 you can setup the SharePoint sites named "Enterprise Portal". These sites run perfectly well on the free SharePoint Foundation version, and it also runs on SharePoint Foundation 2013 if you have the necessary updates. In this post I will discuss some considerations for supporting multiple environments, which might be needed if you want to support some development and testing scenarios in addition to a production environment.

Installing and configuring SharePoint is in many aspects a separate skill set, so I totally get why IT Pros prefer to leave that to dedicated SharePoint consultants. Having said that, if you just need to setup Enterprise Portal for the purpose of supporting Role Centers and giving your AX2012 install a nice looking Home page, then your SharePoint install doesn't have to be too complicated.

I will use Foundation as example, but SharePoint Server 2013 (Standard or Enterprise) obviously works with AX2012 as well. Foundation is free, but does have the necessary features for supporting Dynamics AX Enterprise Portal with it's role centers. If you plan for utilizing Power BI, OData or any of the more advanced features, you should know that upgrading Foundation to Standard or Enterprise is not supported.

Assuming you're starting with a blank server, you can download SharePoint Foundation 2013 with SP1 and begin installing the prerequisites. If any of the prerequisites doesn't install successfully, you can browse through the log file and look for the download URL and try install the failed component manually. I've experienced having to install prerequisites manually before. Eventually, you should have the necessary binaries installed and you are ready for installing SharePoint binaries.

I recommend you do not run the Configuration Wizard just yet. Rather continue with installing the updates for SharePoint. Head over to the overview of updates and download the most recent cumulative update and install it. With the latest updates installed, you are ready to initialize your SharePoint Foundation 2013 Farm.

A couple of points here:

• Consider the account you are using to install the SharePoint farm. Typically this account is referred to the SharePoint Setup and Farm account, and you use it again to configure the farm and potentially install more SharePoint servers into the same Farm. You may need to share the credentials of this account with other IT Pros, so avoid using your own personal account.
• Normally you want a dedicated service account for SharePoint. This is an unattended account that has broad permissions on SharePoint. The administration web application will run under this account. 
• It is also normal to have a dedicated service accounts for several of the various services you can setup in SharePoint, but that is out of scope for this article. 

After having run the Configuration Wizard, you have the option to run the wizard that creates your first SharePoint Site. I recommend skipping this wizard, and instead create the necessary web applications manually.

Before installing the very first Enterprise Portal, I recommend the following:

• Install AX2012 Client and Management Utilities. Point the configuration to the environment you want to install the first SharePoint site. Both the local configuration and the business connector configuration should be pointing correctly and have working WCF configurations.  
• From the SharePoint Administration Site, you need to manually create a new "Managed Account". From the Home page, under Security and General Security, you will find "Configure managed accounts" and from there you can register the business connector account as a new managed account. The SharePoint sites running Enterprise Portal needs to run under this managed account. 
• From the SharePoint Administration Site you also need to start the Claims to Windows Token Service (aka C2WTS). From Home, under System Settings and Servers you will find "Manage Services on Server". Locate the C2WTS and start it from here. If you start this from Services under Windows Administrative Tools (Control Panel) and not from SharePoint itself, the service will be in a faulty state and you'll get in trouble when installing Enterprise Portal. Trust me, I've been there.

Now you should be ready first install of Enterprise Portal on this SharePoint Farm. The following steps can be repeated for each environment you want to support, let it be multiple DEVs or TESTs. Obviously, this limits itself performance wise if your box can't handle the load. So lets begin:

1. Make sure Dynamics AX local configuration and business connector configuration points to right AOS, and do not forget to refresh and save the WCF configuration to this config.
2. Create a new Web Application. Each Portal needs to run on its own Web Application and isolated application pool. Give it a good name, both the site and the application pool. Also give the Content Database a correlating and good name. The managed account must be the one you created earlier using the business connector account. I like to put these sites on ports like 81, 82, 83, etc.
3. When the application is created, you are ready to install Enterprise Portal using AX2012 Setup. On the step where you select Web Application you choose the one you created in step 2. Give the site a good name, like "DynamicsAXDev" or something that makes it easy to understand what environment this site will support. Imagine looking at the URL in the browser and you can easily see from the address what environment you're currently at.
4. Assuming the installation at step 3 went through successfully,  your next step is to make sure the new site always connects to the right environment. Copy a working AX Configuration file (AXC-file) locally to the server. Make sure it has an updated and correct WCF-configuration in it. I tend to put the file under c:\inetpub\wwwroot\. Give it a good name (like DEV.axc). I know the official documentation says the file can be on a UNC-share, but I never got that to work, so a local file seems to work ok. Finally, you need to put a reference to this file inside the web.config for this particular Web Application. The file is normally located under C:\inetpub\wwwroot\wss\VirtualDirectories\81 (given this application runs on port 81). Open the file in some notepad or text editor and put in a new XML section:
   
   
   
   Now you can be sure the Web Application points to the right environment independently of whatever is changed in the business connector configuration settings on this server. I put the section after the System.Web section.
5. Finally, I recommend loading the site itself and edit the Site Permissions. You probably want to make sure either Domain Users or some dedicated AD User Group has at least Read permissions. 

You can repeat these five steps for each environment you want to support. How cool is that? 

Now, what if you need to copy the AX2012 data between the environments? Well, that can be a problem, because when you install Enterprise Portal, setup connects to the AOS and adds data to the database. These data include the URL and the unique ID of the site you installed. If you start copying data around, you might end up with multiple environments pointing at the same Enterprise Portal, and this Portal points to just one of the AOSes, and that isn't very helpful. 

We need to fix that! :-)

Use this PowerShell command to identify the unique ID (GUID) for each site:

Get-SPSite http://fancysharepointserver:81/sites/dynamicsaxtest | 
Select -ExpandProperty AllWebs | 
where {$_.Url -notmatch "dynamicsaxtest/"} | ft -a ID, Url

This will reveal the ID, and you can copy it over to the following SQL command:

DECLARE 
    @EPURL                  AS VARCHAR(255),
    @EPGUID                 AS VARCHAR(255)

SELECT 
    @EPGUID                 = 'e3b7b289-cb17-4c38-8e98-858181af88a5'        ,
    @EPURL                  = 'http://fancysharepointserver:81/sites/dynamicsaxtest'

UPDATE EPGLOBALPARAMETERS
SET    HOMEPAGESITEID    = @EPGUID,
       DEVELOPMENTSITEID = @EPGUID
WHERE  KEY_ = 0

UPDATE EPWEBSITEPARAMETERS
SET    INTERNALURL = @EPURL,
       EXTERNALURL = @EPURL,
       SITEID      = @EPGUID
WHERE  COMPANYID = 'DAT'

The URL and GUID above is just examples, and will obviously differ from your environment, but you get the idea. 

Now save the SQL Command and make sure to include it in your routines when copying data from one environment to another. 

With all of this, you should be good to go and able to have multiple SharePoint applications running Enterprise Portals for different environments, all on the same server. 

Setting up multiple instances of Report Server for AX2013 R3

The documentation for setting up multiple SSRS instances covers the steps I will illustrate in this post. I did this on AX2012 R3, and in this version it is made a bit easier due to the new PowerShell command for setting up the SSRS configuration files. If you're using a version prior to AX2012 R2 CU7, I highly recommend using the freely available PowerShell scripts from this codeplex project.

Let's begin!

So I prepared by installing three named instances of SSRS, running SQL Server Setup for each instance.

Furthermore I completed the initialization of each of them by making sure they all run under business connector proxy account and had the databases and sites ready.

Next I ran AX2012 R3 Setup and installed the Reporting Extensions, which would make my first SSRS instance prepared for reporting. I opted for having the reports deployed as well.

However, the remaining instances remain without a complete configuration, so let us go ahead and prepare them as well.

Using the PowerShell command introduced after AX2012 R2 CU7 makes this easy. Simply open the Dynamics AX 2012 Management Shell and run this command:

Install-AXReportInstanceExtensions –ReportServerInstanceName AX2012_DEV -Credential contoso\daxbc

Notice that after running this command, the configuration files will be modified and they will have the necessary changes to support Dynamics AX reporting.

Run the command for all the additional instances you're setting up.

So how will each instance know what AOS they bound to? We will drop an AX configuration file into the bin-folder for each Reporting Server. The guide tells us the file needs to have a specific name, Microsoft.Dynamics.AX.ReportConfiguration.axc, so all you need to do is to either create a configuration file or pick one you've already made earlier.

I always create configuration files for all environments, so I just copied the appropriate file for each environment to the bin-folder and renamed it according to the instructions. If you have to create new configuration files using the Dynamics AX Configuration from Administrative Tools, just make sure to leave it pointing at the first original configuration when you're done. If you remember, it was pointing to the same AOS as your first SSRS instance was, and you want to keep it that way. :-)

Notice the filesize. Typically if I see a configuration file that is less than 5kB, it tells me that file does not have an updated WCF-configuration. You know the huge chunk of XML that holds the WCF-configuration inside the AX-configuration file. You really want to make sure your configuration file has a proper WCF-configuration before you continue.

Finally restart the Report Server instances and they should be good to go.

Before deploying reports, you should prepare the settings inside AX. Open a client to each of the environments still missing reporting. Head over to System Administration, Setup, Business Intelligence, Report Services, Report servers. Either create a new configuration or change the one already there. My extra environments where copies from other environments, so I simply changed the existing one. Make sure it points to the right SSRS instance, has the right URLs and is associated with the right AOS (at the bottom of that dialog - so scroll down). If the settings are correct, you should be able to press the "Create report folder"-button and observe the folder be created successfully. That is a good sign! You're ready to deploy reports now.

Deploying reports is just a matter of running another PowerShell command. The whole process may take a while, so spend the time documenting your work and feel good about your achievement.

Publish-AXReport -ServicesAOSName MYAOSSERVER -ServicesAOSWSDLPort 8103 -ReportName *

Notice the name of the server running the AOS is used, along with the WSDL-service port. You'll find the correct WSDL from the Dynamics AX Server Configuration under Administrative Tools on the AOS server.

Finally, you can test the reporting by opening a client, and try run any of the reports under System Administration, like the "Database Log". Don't worry about the report not having any data, as long as it loads.

If you encounter any issues or problems, feel free to comment on this post, or head over the community site and post your concerns on the forum.

Synchronization error when setting up AX2012 R3

This will be a quick post on an error I had when setting up a fresh AX2012 R3 installation. I was getting a bit ahead of myself and got stuck with an error when synchronizing the database.

And to help search engines find this post, the error in clear text:

Cannot create a record in Inheritance relation (SysInheritanceRelations). MainTableId: 12345.
The record already exists. 

The error is due to the fact that I didn't restart the AOS after compiling the application. Lesson is; don't rush and do it the right way the first time.
Furthermore, if you DO get stuck, try do a quick search on Life Cycle Services for a solution:
https://fix.lcs.dynamics.com/Issue/Results?q=SysInheritanceRelations

Restarted the AOS and continued the installation.

Start and Stop your AX2012 R3 Azure Demos using PowerShell

There are tons of blog posts covering how to use PowerShell to control your Azure components, services, machines, etc. Once you download and install PowerShell for Azure and try it yourself, you see how easy you can manage Azure by running some simple commands. This post is here to help you AX'ers who have already started playing with Life Cycle Services and Cloud hosted AX2012 R3 Demos. You should be aware that each demo you create will cost money while it is running, so here is a post on how you can easily start and stop them using simple scripts instead of doing it through the Azure management portal.

I am going to assume your user is admin or co-admin on Azure, or you at least have credentials for such a user. I'm also going to assume you've downloaded PowerShell for Azure and installed it.

Start by opening PowerShell for Azure.

Run this command to authenticate for the next 12 hours:

Add-AzureAccount

You will be prompted for credentials, and you need to provide the same credentials you would be using if you were authenticating against Azure.

Use this command to Start demos:

Get-AzureService | Where-Object {$_.Label -match "AX2012R3"} | `
Foreach-Object { Start-AzureVM -ServiceName $_.ServiceName -Name "*" –Verbose }

If you change the filter part ("AX2012R3"), you could control a subset of your services based on some naming pattern or convention.

Use this command to Stop the demos:

Get-AzureService | Where-Object {$_.Label -match "AX2012R3"} | `
Foreach-Object { Stop-AzureVM -ServiceName $_.ServiceName -Name "*" –Force –Verbose }

Isn't that cool?

Now for the bonus part. When you create these demos, you access them through RDP-files. Here is a PowerShell command to download the RDP-files and save them to disk:

Get-AzureService | Where-Object {$_.Label -match "AX2012R3"} | `
Get-AzureRole -InstanceDetails | Where-Object {$_.RoleName -Match "DEMO" } | `
Foreach-Object { Get-AzureRemoteDesktopFile -ServiceName $_.ServiceName -Name $_.InstanceName `
-LocalPath (Join-Path "C:\Temp" ($_.InstanceName + ".rdp")) }

Pretty neat, ey? :-)

Upgrading AX2012 R2 to AX2012 R3

Dynamics AX2012 R3 is just a few days away, so I am thrilled to share some information around the upgrade story from AX2012 R2 to AX2012 R3. I realize most people will probably upgrade from RTM or pre-AX2012, but there might be a few of you who plan to upgrade from R2.

The upgrade story from AX2012 RTM (R0/R1) will be more or less the same as when upgrading to R2. The significant part was the fact the entire Dynamics AX Database was split in two, one database for business data and one for the application (aka Modelstore).

What is interesting with the R2 to R3 upgrade is that we now have two databases to begin with. Microsoft has solved this by doing the following:

1) Create a R3 Upgrade Baseline named YOURDB_UpgradeR3Baseline
2) Export the R2 Modelstore to disk
3) Import the R2 Modelstore to the R3 Upgrade Baseline
4) Replace all the Microsoft models in the actual modelstore with new shiny fresh R3 models!

From there you have more or less the same upgrade story as you would have when upgradring RTM to R2 or R3. The story is divided in two stages:

1) Code upgrade
2) Data upgrade

If you've done R2 upgrades, you will remember that code upgrade is recommended to do this in a isolated environment. It doesn't have to be on a dedicated server, as long as you know how to keep the environments separated. The code upgrade should be done on a copy of the newly configured R3 Modelstore, and the whole idea is to make sure you end up with an upgraded R3 modelstore that keeps the element IDs. Otherwise, you'll end up with having to start over.

The key thing to understand here is that setup will install and replace the Microsoft models in SYS and SYP (plus some other MS layers if applicable). You will need to have R3 compatible ISV models before you start. Your job will be handling the rest of the layers.

The code upgrade is done in a cyclic manner, and the upgrade guide explains it beautifully;

1) Import modelstore
2) Delete top most layers
3) Upgrade current layer
4) Export current layer models
5) Back to step 1 and start working on next layer.

You will do this from the VAR-layer, through CUS and finally USR.

One of the new features in R3 is the improved Code Automerge feature, and for this you will need to install the Team Explorer for Visual Studio 2012. It is not part of the prerequisites as of this writing.

Just to give you an idea on what you can expect when installing R3 during an in-place upgrade, I will provide some screenshots.

I will assume you've duplicated your R2 databases and you've prepared a new server. Obviously you won't be able to mix 6.2 dlls with 6.3 dlls, so you need a new server in order to do the in-place upgrade.

First you choose a Database upgrade:

You then choose to Configure an existing database:

You point to your prepared, but yet not upgraded R2 database. Do not fill in Baseline, because Setup will make one for you.

You will need to provide a location for where the exported modelstore from R2 will be saved.

When this part is completed, you will install the AOS, a Client, Debugger and Management Utilities - all tools necessary for compiling. The debugger will be used for the code upgrade part. Remember I chose to do both the code and the data upgrade on the same server.

Now, I did select the newly created R3Baseline for the first AOS installed, but only to show you the naming convention Microsoft used for the database. The baseline database comes to play when you are in the code upgrade phase. So I did eventually reconfigure my second AOS to use the baseline when I upgraded my layers to R3.

Finally, you define the Instance and ports.

The upgrade for AX2012 is pretty intense, and a lot of steps and details to remember. Lucky for us, the current upgrade guide is very well written and guides you through the process. I expect Microsoft to publish a comprehensive whitepaper for the R3 upgrade story, covering both source to target upgrades, but also RTM and R2 to R3 upgrades. Take the time to read it and understand it. And if you have questions, don't be afraid to ask on the community site.

Finally, I just want to add there a many neat new things in R3 from the technical perspective, so get excited. :-)