AX 2012, SQL Server 2012 & AlwaysOn - Issue with AOS Install

I wanted to spend a little time today talking about a specific setup issue I recently encountered with a client in setting up Microsoft Dynamics AX 2012 with SQL Server 2012 AlwaysOn technology. The focus around SQL Server 2012, AlwaysOn technology is around enabling an active-active high availability options for AX customers. You can find out more about this, here.: AX 2012 - New High Availability Options with SQL Server 2012



This is a very interesting issue actually, one that does not have much public coverage yet it would seem. Actually not sure what the combination of setup & settings that causes such a state, however this is an issue directly related to setting up an AOS that points to the Virtual Name of a Synchronous SQL Server 2012 - AlwaysOn Active-Active node.



What we run into is, the AOS reports as if the install took place. However in looking at the setup log, you will see something similar to the following.:

"Granting AOS account access to database [DatabaseName] on server [Virtual SQL Server Name.]

*******************************

Component installation task stopped due to an error.

*******************************

The network path was not found.

*******************************

System.IO.IOException: The network path was not found.

S260FinishedInfo"

Now, the above is not the full error message at all, but it is the keywords that most people would search on, to reach this post - and therefore reach the solution!. When faced with this scenario, it would seem the issue is the installation program running into an issue with the resolution of the Virtual SQL Server 2012 name, to the current primary node of the AlwaysOn Group for the Dynamics AX 2012 Database.

The path around this issue, at least at the time of this writing is to target the node name of the primary SQL Server 2012 instance, for the AX 2012 database. This targeting should be as part of the install process when selecting which SQL Server, and corresponding database in which the AOS should connect to. In doing this, you can then have a successful install of your new AOS.

After having a successful run at installing your new Microsoft Dynamics AX 2012 AOS, you can now use the server configuration utility, specify the virtual SQL Server 2012 name, restart the AOS and everything should be working correctly.

There is a community post about a similar issue to this, in error reported from the installation process. You can find that here.: AOS installation issue (Remote Registry service). As the name states, this was directly related to the Remote Registry Service of the targeted SQL Server box not running. This could be the issue your facing, if your not trying to use AlwaysOn for SQL Server 2012, and get the above type errors.

Finally, let me add a recently updated Microsoft TechNet article on supported SQL Server topology for AX 2012.: (TechNet) SQL Server topology [AX 2012]. Here we can see the supported scenario's, in which the Synchronous for SQL Server 2012 is one of those. I do also welcome any further feedback, and specific details if anyone has anything else to add to this topic. At the very least you can use the above to be able to easily get past such installation woes, but still use the desired SQL Server 2012 topology.

Well that's all I have for this post, check back soon as a whole lot more to come, including more focuses around Putting your data to work for you while driving towards Creating Systems of Engagement with Microsoft Dynamics AX 2012! Till Next Time!


Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.


Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - Server Configuration Performance Options Review

I wanted to take a little time this fine Friday, and review some of the new options that exists when it comes to the AOS Server Configuration in AX 2012. There are a few new things to point out, really a decent amount of things, and it's important to understand them.



As you can see from the screen shot above, to get started with this review we need to look at the System Administration > Setup > System > Server Configuration. In doing so, a form like the one shown in the following screen shot should appear.



You maybe familiar with this form, basically it list all the AOS instances that make up the current Microsoft Dynamics AX instance your connected to. Further you have some of the more standard configuration options on the right, per select AOS. These include the ability to set Batch schedule times, max batch threads and even if an AOS is meant to be considered as a batch server.

What you may not be familiar with is a little hidden part of this server configuration form. To get to this, as shown in the following screen shot, you must scroll with the right far side scroll bar, as highlighted so you can see Performance Options smart tab.



In doing this, when you expand the performance options, you will notice that there are two main groups. A group, related to such performance settings for 'Settings for All AOS Instances' as well as 'Cache limits for this AOS instance.'

You will notice that when looking at this, and comparing these two main groups, that only the cache limits can has a specific AOS override. Other settings like Error on invalid field access or Maximum number of Tables in a Join are specific to the entire instance of Microsoft Dynamics AX 2012. This means those such settings applies across all AOS(es).



I've highlighted a few options in the above screen shot. You can see that the first highlighted option is the maximum number of Tables in a Join. This limit exists, because with all the great new data models changes in AX 2012, there can be some performance issues. Specifically related to creating queries, calls and the like which could cause a massive amount of joins. The out-of-the-box is 27, and this is one settings that is something I've personally had to change for a few clients already. Be careful with it, it's there to limit for a reason.

Further highlighted we have some of the caches, like the amount of objects in the Global Object Cache. This is the size of the objects keep in RAM, for a Specific AOS. This is also now known as the SysGlobalCache. What's interesting to point out, and very important to understand with these cache point of views, is that these caches are always contained within an AOS. This means there are no cache sharing taking place between AOS(es) that you might have in your instance of AX.

Just because you have the option of overriding the cache values for a specific AOS, and you instead use the global setting, should not imply that the cache's are shared among the AOS(es).

I think, for now this is a good introduction to the Server Configuration within AX 2012, specifically the Performance Options for AOS(es). The key take away's are understanding how to get to these values, how caches act within the context of an AOS, and specific instance wide global settings, like Maximum tables in a join.

That's all for this week, I hope everyone has a great weekend, and make sure to check back soon. There is a lot more coming, including the build up to #CONV12. Till Next Time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 Issue: Cannot execute a data definition language command on Dimension set balance temporary data

So, I ran into something new today with AX 2012. The following error message starting showing up, within an instance that has two AOS(es). It showed up anytime any process needed to post to the General Ledger area.

"Cannot execute a data definition language command on Dimension set balance temporary data (DimensionFocusBalanceTmp). Financial dimension set: 0, 0.
The SQL database has issued an error."

After this, there was a trail of SQL related errors that both AOS(es) trapped and bubbled up to the UI. This happened on both AOS(es) not just one. I tried, to run the following.: DimensionCache::clearAllScopes(); in a job. This had zero affect.

To get past this fast, a restart of both AOS instances was completed, that resulted in the resolution of this issue. I would like to hope that maybe there is a Cache call that could take place that would fix this issue, without having to restart the AOS. However, for now, if you see this, the fastest resolution is a restart of *ALL* AOS(es) within a given instance of AX.

If I get an update on this, for what fixes this, if a hotfix comes out, or if there is a piece of X++ cache clearing code that can be executed, I will make sure and update this post as such.

Hopefully this will help someone out.

"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012 - System Architecture Overview

As we draw closer and closer to the release of Microsoft Dynamics AX 2012, I plan to continue and dive deeper and deeper into all area's of the new release.

With that in mind, lets take a look at what resources we have on Microsoft TechNet.: Microsoft Dynamics AX 2012 - System Architecture



As we can see there is quite a bit of new roles, and also new ways old roles will interact, function, and what they run on.

Starting at the bottom of the diagram, we see that SQL Server of course, plays a major role in a given Microsoft Dynamics AX 2012 solution. To this database point, SQL Server, when AX 2012 is released, will be the only Database Software that Microsoft Dynamics AX will run on. Bye-Bye Oracle option!

You will noticed that we have similar databases here before, like SSRS, SharePoint and SSAS. What's important to understand is that the Dynamics AX database, will take and have both the Transactional Data, as well as the model store for which all Dynamics AX Objects live in.

This is where the AOT moved from the file system, and into the database, and reason why there is a new utility for moving .axmodel files, from one instance of AX into another.

Moving up the stack, we have the AOS and .Net, and within that .Net 4.0 applications, AX Services like the Metadata Service, Query Service and more. Here a lot of changes has taking place, and really openning up Microsoft Dynamics AX 2012, as was laid out in the past post I did some years back with Lachlan Cash.: WCF: The Enterprise Service Bus for Dynamics AX and the rest of the Microsoft Stack

All of these new blocks you see, mixed in, and being hosted by old one's like the AOS, help enable this vision laid out throughout the series of post, including the one mentioned above, that helped describe what the future of AX held. That future is becoming today, with the release of Microsoft Dynamics AX 2012 soon.

There is also a lot more to cover with this, and I recommend taking the time and reviewing each section of the system Architecture. Take a deep dive into the TechNet pages that already exist for Microsoft Dynamics AX 2012.

How we plan installs, how we do modifications, how we extend AX, all is going to change is some degree or another with this release, and it's important to understand the impact of these changes, and how much they enable for a business that will be making use of them.

That's all for now, I will continue this dive next week, with looking into comparing AX 2009 and AX 2012 in this area, and talking about some of the benefits, from this move being made.

Check back soon, as more to come!

"Visit the Dynamics AX Community Page today!"

The Perfect Storm - a Case for the Good Ship SourceSafe

It's Friday, everything was going along fine, and the AOS crashes. Ok, go check the event logs, note an error with an AOT object, and restart. Bang, seconds later it crashes again.

Start the AOS service, and go open the AOT to try and get to that object, which happens to be a view, AOS crashes.

There is a corrupt object in the AOT, and you can't get access to it, via the AOT to remove it.

This is what happened to me last Friday. I call it the "Perfect Storm", and the reason why will be evident as you read on from here.



So there I was, AOS crashing, and you can't get to the object that is causing the issue. You also can't import over it, as that causes it to crash as well. It's a corrupt object in the AOT.

So there is a posted blog entry out there, that talks about removing the corrupted AOT object from the instance with code. That blog entry can be found here: Deleting a Corrupt AOT Object via code.

So I took and was lucky enough that a job would come up in a private project. So I created a new job, and changed the code from the above post, to fit my needs. When it made it to the util.delete(); call, the AOS crashes.

Bang! Another wave crashing down.

So moving on, the plan was to try and take and just restore from last night's backup of the /Appl files. But wait, another storm from the other side was coming in. As the last good backup for the /Appl files is 10 days old.

This was because of an issue with the backup solution, shutting down the AOS at night, and stopping the batch job processes and nightly jobs. The backups were scheduled to start back later that night. Not good, waves crashing in even higher, as 10 days worth of work seemed to be possible it could be lost to the sea of no return.

So in a last ditch effort, a plan was hacthed, to take and try to export all the layer objects, but that single one causing the crash. The code was wrote up, based on the following:

"TreeNode treeNode = infolog.projectRootNode(); ProjectNode projectNode; UtilElements utilElements; ;

treeNode = treeNode.AOTfirstChild();
treeNode.AOTadd('VarLayerChanges');

projectNode = treeNode.AOTfindChild('VarLayerChanges');
projectNode = projectNode.getRunNode();

while select utilElements WHERE utilElements.utilLevel == UtilEntryLevel::var {
ProjectNode.addUtilNode(utilElements.recordType, utilElements.name); }

ProjectNode.AOTsave();
"

The above was just changed to not include the object that was causing the crash. However when ran, this too crashed the AOS. Arrgh! Nothing that we do works.

Another wave came crashing down. It was bleak looking at this point, we were all hanging on by a thread. And just then, over the last crashing wave, a small light could be seen. Another ship? Another way out? yes! yes!

It was good the ship SourceSafe, Visual SourceSafe to be exact. So quickly we restored to the 10 days back .aod file, after making plenty of backups for the /appl files and database. Then moved on to start everything back up. After that we brought in every object from SourceSafe that had been touched since 11 days back... and the storm calmed, and the sun shown again.

We were save by that good old ship, SourceSafe.

So the moral of this story, making use of SourceSafe is a good idea. Even though it may be a pain at times to setup, and cause some extra steps for making sure things stayed sync on a weekly basis, it's worth it's weight in man hours, as it came in and saved the day!

Check back soon, as I fully recover from the perfect storm last week, and being sick yesterday, and hopefully I can get back to posting what I had planned. See you then!

Update:
I wanted to make sure and update this post, letting everyone know that the typical removing of the .aoi file from the /Appl folder location, and even removing of the object in the SQL DB did not have any affect or offer any help.

That is a typical thing to try and do, to get AX to to 'fix' it's meta data about all the objects it manages at the different layers they exists. I did not post that I tried that first, in this perfect storm.




"Visit the Dynamics AX Community Page today!"