With the release of Microsoft SQL Server 2012, came a lot of great new features. Microsoft really listened to its client base, on many fronts for this major version refresh. Now that SQL Server 2012 is here, and we are a few months beyond it's release-to-manufacturing, its time we talk about all the great features it brings to Microsoft Dynamics AX 2012 today!. One of the topics that I think deserves a lot of focus, is the new AlwaysOn technology for SQL Server 2012. You can find out more general information about this topic from MSDN, from the following resource pages.: Introducing SQL Server AlwaysOnDeploying a new Availability GroupConfiguring Application Failover Using a Virtual NameHaving an understanding of the purpose for this new technology, lets look at how this can be used to benefit those customers who have decided to use Microsoft Dynamics AX 2012. The focus for value, in what AlwaysOn for SQL Server 2012, brings to AX 2012 is around High Avalability. In the past, customers when wanting to speak in terms of High Availability, typically focused around active / passive SQL Cluster. This is still a valid solution, even with SQL Server 2012. However, now it's not the only option, thanks to AlwaysOn technology with SQL Server 2012. This brings us new options around the concept and setup of Database Availability groups. Now we can have two SQL Server 2012 instances, helping us run, both active, the total solution for a Microsoft Dynamics AX 2012 customer. This means, instead of having a full powerhouse server, just waiting for it's active cousin to crash - both can be used, and each being the target of AlwaysOn failover for specific database. As the above image suggest, part of the design is deciding which databases will reside on which production SQL Server instance. Both having be the target of AlwaysOn fail overs for each other's availability groups. This is a high value point in terms of SQL Server usage, and something that Microsoft really did right with this release. This means that, as the example shows, Microsoft Dynamics AX Databases can be loaded on one target production instance of SQL Server 2012, while the rest of the production databases can be loaded on another. Both being equal boxes, per resources, and both having each other as their target fail over. Having this now as a design option for a customer's total solution, means taking full advantage - and deriving the most value - from having chose Microsoft Dynamics AX and the Microsoft stack it resides on. That's all for today's post, I will do a follow up post to this one, shortly, speaking to the exact experience for having this concept in action. I will end with there is so much going on in the Ecosystem right now, including the upcoming Spring Decisions 2012. I will be attending, are you? Till Next Time! Follow Me @: "Visit the Dynamics AX Community Page today!"