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!
hi,
ReplyDelete1.What about client access via terminal services / remote desktop? Is it recomended? In what scenario it will be beneficial? in what scenario it will be a risk?
2. is there a sizing tool for AX 2009 to determine cpu / memory / storage ?
thanks
Hi there!
ReplyDeleteYes, it is a common scenario today to access Microsoft Dynamics AX through terminal services and to be honest with you, I don't see it any other way.
Check the following post to get a detailed step-by-step guide on how to do it with Terminal Services
http://axwonders.blogspot.com/2011/05/deploy-ax-2009-from-terminal-services.html
To answer your second question, please see the following post about Intelligent Data Management Framework (IDMF), which will support what you are looking for:
http://axwonders.blogspot.com/2011/12/intelligent-data-management-framework.html
Let me know if you need any more info.
Thanks for checking my blog.
Thanks for your reply.
ReplyDelete1.Are there any performance issues with regards to terminal services?
2. Does the IDMF analyze CPU and Memory needs or just storage? Does it work with AX2009?