AX 2012 - Run Reports without hitting the Production DB

Hi there!

My fellow Sunriser, Brandon George,  has written an amazing article about running reports without hitting the Production Database.

Form the article:

"Since the default .Net Business Connector configuration for SSRS is pointing back to the same AX instance, when the SSRS instance is executing the reporting and firing the Data Extensions to get to the correct Query object and therefore data, then in this standard approach, we are hitting the production database for your instance of AX..."

"The critical keys that enable this concept are, (1) having the production instance of your AOS and Reporting Server setup, pointing to your SSRS server role within AX. (2) Changing what AOS the SSRS server hits for processing data, by deploying a custom configuration file. (3) Log Shipping is enabled at on the AX Production database, so that the AX Reporting Database is kept up to date with live data."

"...That is code promotion, or change management. Why does this matter? Well simply put, it's because the model store that represents the application now lives as a part of the production database. This then gets replicated when any changes take place."

Brandon George is a Senior Technical Architect at Sunrise Technologies and I personally believe he is one of the few people in the world that has truly master AX. I strongly suggest to follow his blog as it contains valuable, innovative, and critical information about AX.

You can access his blog (and the article) from here.

Take care!

Plan a Succesful AX 2009 System Topology

Hi,

Today I would like to talk about a topic that, when followed with professionalism, can differentiate a good consultant from a bad one.

If you think about it, Microsoft Dynamics AX has become the way to help companies become more efficient, and to also help them save money. However, is also true that AX (in general) has become a big boom where some (low quality) partners and developers are not following up certain guidelines to make an implementation a successful one.

The result ... Customer dissatisfaction and a bad taste for AX.

In this article I would like to discuss the basics to plan a good system topology. In other words, what do we need to have in mind when faced with this task. What kind of question should we be asking the customer.

For example,  A large business with multiple locations might experience different challenges compared to a smaller business with one location and only a few users.

So, a good tip would be to start the implementation process by (1) creating an inventory of the customer's current hardware and software, and (2) determining the deployment scenario that best meets the business’ current needs and future growth.

 So, before the actual installation occurs, we must collect information about the customer's requirements to help prepare the correct topology.

1- Define and document these items with the customer:

• Number of transactions
• Number of users
• Uses of system (modules and features to be implemented)
• External user access required
• Web access required
• Required availability
• Projected growth rate
• Number of sites

2- Evaluate and document the existing infrastructure:

• Existing hardware
• Bandwidth
• Operating system
• Databases present
• Applications to integrate

3- After collecting this information, determine how to structure the system. Key decisions are as follows:

• If there are any computer roles that can be combined on a single computer? If computer roles can be combined, consider which ones to combine.
• Determine whether there are any network load-balanced clusters to host the AOS.
• Select a backup system for the Microsoft Dynamics AX environment.

Topologies

If the customer's requirements are focused on not allowing users outside the domain, then use the following topologies:


Minimal Base Topology

Clustered Base Topology (You can install the application file server on a AOS server as you will have more than one AOS server)

Enterprise Portal Topology

There are two (1) Intranet (Simple and Large-Scale), and (2) Internet-Facing

Intranet

Intranet Large-Scale

Internet-Facing Enterprise Portal

Standard Perimeter Network

With a standard perimeter network the Active Directory domain contains:

• All internal users to be added to Microsoft Dynamics AX 2009.
• Special users required for Microsoft Dynamics AX functionality.
• An organizational unit that contains any users from outside the organization that require Enterprise Portal access. These users’ rights must be restricted in that the users cannot:

                      Log on locally

                      Access network

Traditional Perimeter Network

Basically, the traditional perimeter network contains two Active Directory domains: the internal domain and the external domain. The internal domain contains:

• All internal users to be added to Microsoft Dynamics AX 2009.
• Special users required for Microsoft Dynamics AX functionality.
• Group required for application integration server functionality.

[From Microsoft Training Material]

The perimeter network contains a second domain controller with a one-way trust relationship to the first domain controller. The second domain controller contains any users from outside the organization that require Enterprise Portal access.

These users cannot have any rights in the internal domain, and their rights must be restricted in the perimeter network domain so that the users cannot:

• Log on locally
• Access network

 Report Server Topology (This is installed on IIS and is not Internet-Facing)

Application Integration Server Topology (This is also installed in IIS and is not Internet-Facing)

Let's be consistent in the work that we do. Let's provide a great customer satisfaction so Microsoft Dynamics AX can keep growing and helping businesses succeed. By following the above suggestions, we can make a huge difference in how new businesses experience AX implementations.

Take care!

Reporting & BI in AX: An Overview

The following link contains an amazing post about Reporting and BI in AX by Arijit Basu. I just felt obligated to share this great overview.

http://daxguy.blogspot.com/2008/01/reporting-bi-in-ax-overview-level-100.html