Saturday, November 16, 2013

Error during installation of Enterprise Portal for AX2012 R2 on SharePoint 2013

I want to just quickly share this with the community. I have not yet narrowed down why this failed, but I have a feeling this might be something I won't encounter too many times when installing Enterprise Portal.

I wanted to setup and install Enterprise Portal for AX2012 R2 (CU6) on SharePoint 2013 and I had already ensured that SharePoint was upgraded with latest upgrades. This SharePoint server was setup by a third party and prepared as just a regular SharePoint Server. I had to prepare the Business Connector as Managed Account. I also created a new Web Application designated for Enterprise Portal. Just to be safe I also created a root Site Collection and tested it ok.

Unfortunately, when I tried to install Enterprise Portal I constantly hit this error:
"Microsoft SharePoint 2010 is not installed or running. Please run the prerequisite utility for more information. Operation is not valid due to the current state of the object."

Now, obviously SharePoint 2010 is not installed, but SharePoint 2013. I believe the last part of the error is the important part. I did decompile the code to see if I could understand why it failed, but didn't find anything obvious.

Instead I found the necessary clue in the setup log. You know everytime you run setup a log is written to disk, normally under "C:\Program Files\Microsoft Dynamics AX\60\Setup Logs\". The log for this run showed me that when it was iterating over the Web Sites, probably for the presentation of them into the drop down list, it failed and threw the error. The last site it was traversing in the log was the default one, "SharePoint - 80".

So I head back to IIS and stopped the Web Site causing Setup to fail and reran setup again. Sure enough, the error was gone and I could successfully select the Enterprise Portal Web Application and continue setup.

Maybe this was just bad luck, or perhaps this will help someone.

Saturday, November 9, 2013

You got to love AXBuild Compiler Tool

Initial testing of AXBuild 

I finally got around to play with the new compiler tool for Dynamics AX 2012 R2 and it really is a game changer. My first attempt of compiling a fresh install of AX2012 R2 with CU7 took a little less than one hour. This was tested on a virtual server with enough RAM and just two logical (virtual) 3.6Ghz processors. Not the result I expected, so I went back to the host system and changed Power Options from Balanced to High and added one more logical processor. The tool will take number of processors, multiply by 3 and divide by 2 to give a count of "workers". Max number of workers are 32, in case you try to run this on a system with more than 21 processors. Lol.

Second attempt now took half an hour, which is good, but not quick enough. Apparently I wasn't completely alone on the system, so after kicking out other variables (aka. colleagues) I was down to around 16 minutes for a full compile. Now this is having the databases hosted on another virtual server, so there are some speed lost in chit-chat, but I am thrilled.

Testing backward compatibility

The next thing I wanted to check was whether or not I could actually (ab)use this new compiler methodology to compile older R2 modelstores, like CU6. Surely a bit far-fetched, and perhaps not really supported, but why not give it a go.

I ran the command line utility and threw in a parameter pointing to a CU6 modelstore. The tool started compiling, but it compiled against the CU7 modelstore and not the one I pointed at. So the tool will take the AOS configuration and compile against the modelstore database defined on the AOS configuration. Not really what I aimed for.

I then tested compiling a CU6 modelstore with a CU7 AOS and I got the same result as described here.
I already had a CU6 AOS prepared for testing if I could start this AOS against a CU7 compiled modelstore, but it fails with the following error:

Object Server 01:  Fatal SQL condition during login. Error message: "The internal time zone version number stored in the database is higher than the version supported by the kernel (5/4). Use a newer Microsoft Dynamics AX kernel."

Upgrade kernels!

I mean, the kernel should be backwards compatible, so having CU7 kernel for client and service running against an older application version of R2 is supported, so the lesson learned is to upgrade kernel binaries to CU7 and enjoy a new and improved compiler tool!

If you run axupdate.exe you have the option to only upgrade the services and client components:

Well served by Microsoft on this one!

Friday, November 1, 2013

About your elements Origin, ID and Handle

This post will be about the elements Origin, their ID and finally the Handle. These are important to grasp as AX developer when creating elements in the Application Object Tree (AOT) and copying them around between environments. I hope it will help both new and old AX developers.

The Origin is made up of a Global Unique ID (GUID), and it will follow the element created throughout its lifetime, from the very first brilliant idea, through all sorts of versions and bug fixes and until is is one day obsoleted; from cradle to grave. This Origin will be the same for this element in all installations, environments, versions and variations. It is unique and special, and it so for a purpose.

Take this table as an example:

The Origin of this table will follow this table from my development environment and into any other installation. If I copy this table using XPO, Model or ModelStore, this is the Origin it will carry everywhere. This also means that if I create "MyTable" in my AX, and you create your "MyTable" in your AX, you can be certain they will have different Origin, and essentially not be the same table.

Take a look at how the Origin is part of the element description when I export it to a XPO.

The same is true if I make an axmodel-file having this table.

So why is this so important? Well, most seasoned Dynamics AX developers have at some point gotten their hands burned on element ID conflict, element cache become invalid, change of element ID causing loss of data and so on. AX 2012 attempts to solve this by letting us forget about element ID altogether and instead focus on Origin. The goal is for us developers only to worry about Origin as identification of Elements.

Great, but what is "Element ID"? Element ID is a unique number identifying elements in the AOT. This ID is used a lot in AX for historical and good reasons. It is a way for the system to quickly identify any element for things like indexing, cache, relations, usage, etc. It works like charm, and is a lot more efficient than using the actual name, path or some other non-numeric reference to the element. Surely a GUID is not a very efficient way to index and organize a long list of elements - just think about it.

Element ID comes into play as soon as en element is created in the AOT, but an important difference compared to the Origin is the fact that the Element ID may perfectly well be different between environments. Element ID is strongly tied to the business data, so if the Element ID is changed or made invalid, you risk loss of data. There are however ways around this, but they are not discussed in this post.

Let us have a look at how Origin works when Elements get their ID in AX during import of a XPO or installation of a Model (axmodel). Details can be found in this Technet Article.

The system will automatically try to reuse Element ID based on Origin, or it will create a new Element ID if necessary. There is also this LegacyID, which is a way to make some IDs backward compatible with previous versions of AX, if really necessary.

As an example, take a look at good old CustTable, number 77. :-)

Also take notice of the Origin and compare it to the Origin in your AX environment. Is it the same? It sure is!

Ok, so what is then Element Handle? It is unique ID identifying every single element in the AOT that is meant to be uniquely identified. It is also the ID being used as key and foreign key in the tables containing the information about the AOT elements (ModelElement, ModelElementData, etc). The system assigns Element Handles just as it does RecIds.

Does that mean Origin and Element ID doesn't cover all possible elements in identifying them? The answer is NO! Take table methods as an example. It does not have an Origin, nor does it have en Element ID. It does have en Element Handle.

Try run the SQL underneath in your AX environment and see what handles you have for CustTable and a custom table.


You may want to replace "MyTable" with a custom table of your own. Notice how my ElementHandle of CustTable differs from yours.

So let's wrap this up with some highlights:
  • Origin is your cradle to grave ID for your new Elements. It is the only ID you really need to worry about.
  • Element ID works pretty much like before, except you no longer keep it between environments. System creates this ID uniquely for you.
  • Element Handles uniquely identifies every single identifiable element in the AOT and is provided by the system.
  • Not all elements have Origin or Element ID, but all elements have a Handle.
  • Finally - Business data is tied to Element ID and not Origin. Don't ever get tempted to mix one modelstores business data with another modelstores business data.
If you ever wonder what elements have ElementHandle but no Origin or ElementID (AxID), you could try run these queries on your modelstore database:

-- Get all element types having Origin but no Element ID
 WHERE AXID IN (0) AND ORIGIN NOT IN ('00000000-0000-0000-0000-000000000000') 
-- Get all element types having no Origin 
 WHERE ORIGIN IN ('00000000-0000-0000-0000-000000000000') 

Thank you for reading!