Microsoft Dynamics AX 2009 Administration

By Marco Carvalho
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. System Planning and Hardware Sizing

About this book

Microsoft Dynamics AX 2009 is an advanced Enterprise Resource Planning system, essentially a comprehensive business management solution, designed for midsize and large organizations. Dynamics AX provides a centralized source for business data and enables you to consolidate and standardize your business processes, helping to improve productivity and provide visibility across your organization, for a variety of business needs.

This book will enable you to successfully set up and configure Dynamics AX 2009 in your business with clear, practical, step-by-step demonstrations. You will learn how to plan and implement Dynamics AX 2009 efficiently, how to manage the Enterprise Portal, Role Centers, Kerberos Authentication, Workflow, Application Integration Framework (AIF), and much more!

Each chapter of the book explores the different aspects of administring and configuring Dynamics AX 2009 to fit any company's needs.

The book begins by introducing you to the important process of planning and implementing Dynamics AX 2009, providing the basic components to get you started with your Dynamics AX environment.

It then dives deep into the installation of the multi component server of Dynamics AX and how to get it up and running efficiently, specifically the Base Server Components, Enterprise Portal, Role Centers, Kerberos Authentication, Workflow, and the Application Integration Framework (AIF).

Other content includes the process of importing data into your Dynamics AX 2009 instance, common user administration functions, and Alerts and Notifications.

Finally, the book considers how to enhance your Dynamics AX environment after it has been installed and it is being utilized, from tuning your system to work more efficiently to backing up and maintaining Dynamics AX to make sure you are prepared for worst-case scenarios, enabling you to keep Dynamics AX 2009 functioning at its best.

By following the clear and practical steps found in the book, you will successfully master how to administer and configure Dynamics AX 2009 into your company.

Publication date:
January 2011


Chapter 1. System Planning and Hardware Sizing

Before you plan your Dynamics AX implementation, it is vital that you understand the current hardware, network, and software infrastructure in which you will be implementing Microsoft Dynamics AX. It is also equally important to gather information about a company's business requirements, functions, and departments that will be utilizing Dynamics AX 2009. At times, there may be a need to implement new hardware, network, or software resources to fulfill the needs and requirements of Dynamics AX. Therefore, gathering as much information as possible on hardware, network, and software is essential to the success of the functionality and performance of Dynamics AX.

In this chapter, we will cover:

  • Typical phases of a Dynamics AX implementation

  • How to create a robust environment in which Dynamics AX 2009 can be installed and utilized

  • How to size hardware, networking, and software resources that will support the Dynamics AX 2009 system


Phases of a Dynamics AX implementation

In order for Dynamics AX to function at its best, hardware and network infrastructure has a large effect on the level of performance a company will experience. Luckily, there are requirements to ensure that Dynamics AX will function at its best. You can also expand on these requirements to provide even better performance. For example, you can certainly expand and implement a better infrastructure (scaling out) that supports more network bandwidth or implement more data capacity or processing power as well (scaling up).

The requirements of the network and hardware are determined by the number of concurrent users and transactions as well as the other services whose demands will take up network resources alongside Dynamics AX.

Since Dynamics AX is a modular server system, requirements are also based on which of these systems will need to be utilized and to what degree. For example, for the Enterprise Portal, you will need to decide if it will be accessible using an Intranet on a Local Area Network (LAN) or using the Internet on a Wide Area Network (WAN).

In this case, your hardware, software, and even network requirements will have to compensate to handle the bandwidth, security, and load. Another example may be that your implementation may be running many batch jobs in which they handle large sums of data. For that reason, you may consider implementing extra Application Object Servers (AOS) to compensate for the batch loads and demands.

You may also want to be prepared for emergency scenarios or for compensating additional demands that occur from company expansions.

Microsoft Dynamics Sure Step implementation methodology ( is an excellent collection of guidelines for successful implementations, especially for Dynamics AX. The following table is adapted from the Sure Step methodology and provides an overview of processes during an implementation:

Modeling phase


Tasks during phase


  • Evaluate a customer's business processes and infrastructure

  • Prepare a proposal


  • Analyze the current business model

  • Produce a gap/fit analysis

  • Create the requirements documentation


  • Create documents:

    • Feature design

    • Data migration design

    • Test criteria

    • Technical design

Development, testing, and training


Tasks during phase


  • Set up the production environment

  • Configure the system

  • Migrate data

  • Test the system

  • Train the end-users

  • Bring the system live

Production (Go live)


Tasks during phase

Deployment and Operation

  • Resolve pending issues

  • Finalize the user documentation and knowledge transfer

  • Conduct a post-mortem of the project

  • Provide on-going support

These are on-going activities that continue after the project is closed and throughout any future involvement with the client

Planning phase


Tasks during phase


  • Analyze the system to determine how it can be optimized for best performance based on the customer's needs

  • Perform the optimization

  • Carry out testing

The purpose of this phase is to help the customer optimize the benefit they get from the business solution.


  • Review the customer's business processes

  • Align the business processes with new functionality

  • Put the systems in place to support the upgrade

Delegation phase

Before beginning a Dynamics AX implementation, it is important that roles are determined and delegated. This ensures a steady process throughout the implementation and lessens the possibility of any bottlenecks occurring. The following table shows a theoretical sequence of the initial phase of an implementation:

Sequence or Priority

Responsible party (Company, Implementer, or Both)

Action item




Choose required features that a company will need to perform business functions.

Specific licenses will need to be purchased to enable certain functions in Dynamics AX to be useable. Also, third party modules may need to be utilized.



Gather current network, hardware, and software capabilities.

Review installed software such as operating systems, hardware such as processing speed, available RAM and HDD space. Also review current bandwidth capacity and current network load.



Gather user, usage, and topology requirements. Estimate projected growth rate.

Number of total users in the company, number of concurrent users, and number of transactions per minute. Topology requirements, such as Intranet or Extranet (VPN).



Install any new hardware, software and/or configure the network to fit the previously mentioned requirements.

Examples of modifications at this phase are to set up the Windows Domain Controller to support Kerberos authentication.



Set up user accounts.

Create users that will need to have specific privileges from the implementation company to perform installation, setup, and the configuration of Microsoft Dynamics AX 2009.



Create implementation directories.

Specific directories for Dynamics AX configuration files, user documentation, installation and utilities, or any other miscellaneous yet relevant files for the implementation.



Install required software for Dynamics AX 2009.

Install required software that the Dynamics AX 2009 installation program needs in order to install and run base and server components. For example, Internet Information Services (IIS) and Windows SharePoint Services will need to be installed and set up for the Enterprise Portal to be installed.



Create and set up development environment.

In conjunction with the previous step, there should be a server dedicated to development. The development environment will contain everything that the production environment has; however, the base and server components can run on the same system. Sometimes, the test environment can also reside on the development server.



Create and set up test and staging environment.

Similar to the previously mentioned; however, these environments will resemble the production more so. Typically, the staging environment is practically identical to the production environment.



Create and set up production environment.

The production environment should be considered an "island" from the other environments and should be treated as sacred.



Import users.

Import company users into required environments.

A well-coordinated team with specific tasks is an integral part of a successful implementation. Without such a team, unforeseen failures and setbacks may occur. Each role is required due to the responsibilities incurred during an implementation lifecycle. The following roles will need to be occupied by qualified professionals:

  • A Project Manager is a person who will oversee the implementation process. Such an individual may encompass some skill sets of each preceding role. Ultimately, the job of the project manager is to orchestrate each individual during the process of an implementation and also communicate with the business to create functional and technical requirements.

  • An Architecture specialist is one who can determine methods to balance performance and scalability with manageability, interoperability, security, and maintainability.

  • A Developer is responsible for tailoring Dynamics AX 2009 to a company's specific needs by providing custom development and integration.

  • A Tester is an individual with functional knowledge of developed modifications and functionality of Dynamics AX.

  • The role of a Trainer can be fulfilled by a Tester who will be in charge of specifically training individuals on how to use the systems for business functions.

  • A System Administrator would typically already be working at a position in the company that requires familiarity with network topology and server hardware. The primary goal of this individual, especially during the implementation phase, would be to monitor and ensure that all resources are operating sufficiently, enabling them to provide optimal performance and meet service level agreements.


At times, responsibilities fluctuate, consolidate, and deviate from the initial roles. The previously mentioned list provides mere guidelines to understand the typical responsibilities required for an implementation. Keep in mind, the larger the implementation, the greater the responsibilities, as the number of roles required will increase proportionally.

Setting up an environment for Dynamics AX 2009 follows similar guidelines to other Microsoft infrastructure methodologies. A list of possible implementation methodologies are as follows:

  • Infrastructure Planning and Design (IPD)

  • Windows Server System Reference Architecture (WSSRA)

  • Infrastructure Optimization Model

  • Microsoft Operations Framework


Hardware planning

Having hardware performing at its best is crucial for the performance of Dynamics AX 2009. Therefore, planning hardware setup and infrastructure is essential to the overall implementation and post implementation of Dynamics AX. There is a level of performance that is proportional to the level of utilization. The goals of achieving performance requirements are to minimize response time, maximize throughput, and balance resource utilization and workload. This is also a function of capacity management, which is the process of planning, analyzing, sizing, and optimizing capacity to fulfill demands in the least timely and lowest cost approach. The following table is a list of items that need to be collected and quantified in order to create an optimal Dynamics AX 2009 environment:



Number of companies

Some implementations may contain one or more companies.

Number of users

Maximum number of concurrent users as well as company size. Keep in mind that the number of concurrent users will increase as a company grows.

Number of departments

It is important to know the number of departments present within a company. In Dynamics AX, departments can be partitioned into a company account. It is also important to determine the following:

  • Department requirements

  • Department business processes

  • Number of department personnel

  • Permission requirements and restrictions

Number of transactions

Determine the number of transactions that are occurring during on and off peak hours. Resources need to be leveraged to handle the loads. Keep in mind that different times during the year may also put variable strain on the system.

  • Note: One purchase order with 50 line items is considered as 50 plus the order itself, number of transactions.

Required features

Will EDI, business analysis, web, or mobile access be required? These are just a few examples of features you must consider.

Consider that, when users access role centers, behind the scenes, they will be accessing SQL Server Analysis Services. Depending on your data and role centers, these can be intensive calculations and may require extra processing power to compensate.

Another scenario would be an EDI scenario. If part of your information is being received from an outside vendor and orders are also being created to another outside vendor, consider that there may be a need for a specialized setup to efficiently work with the two endpoints.

External user access

Determine whether users will be accessing Dynamics AX using the Internet or extranet. What features, permissions, and resources do these users require? What are the peak and off-peak hours for users, as well as the number of transactions within those periods?

Internal user access

Similar to External user access, however for the intranet.

Estimated growth rate

To determine this, take the current growth rate in the last two to five years and distribute it over the next several years. The following mathematical formula can be used to calculate the rate:

For example, if "Carvalho Company" had 50 employees five years ago and now has 200, the calculation would be as follows:

(200-50)/50 = 3 * 100 = 300%

Therefore, one should determine the potential of another 300 percent growth rate since the company had grown 300 percent in the past five years. Besides, with all the money the company would be saving by implementing Dynamics AX, they could focus more on strategy and hire more employees!

Availability (uptime)

Although the availability of an ERP system should be 100 percent throughout the day and year, you must determine the appropriate uptime requirements. For example, there are times for regular maintenance and upgrades where systems must be brought offline.

Number of sites

Many companies have various locations. Although Dynamics AX does not need to be implemented in each location, it is certainly the goal.

Based on the information here, you should now have a better idea about completing a company's requirements. For example, depending on the number of users, clustering or load balancing may be necessary for the AOS.


Microsoft Dynamics AX can function in a virtualized environment and does not require any specific setup since virtual environments, by nature, simulate a physical environment. Therefore, in many cases, your company will benefit greatly by deploying Dynamics AX 2009 on a virtualized infrastructure. There are many added benefits if you choose to follow this route such as cost, speed of client deployment, and modifying resources in real-time, to name a few. There are many vendors that provide virtualization solutions, including Microsoft. Price, features, and ease of use all play a role in deciding which solution is better. Consult the virtual solution vendor for more detailed information on server virtualization products.


When choosing a virtualization solution, consider the impact on the Dynamics AX 2009 support agreement.

Database sizing

Database sizing is potentially the most critical step in performance for a Dynamics AX 2009 implementation. Each database server has its own specifications for hardware. However, the general ideas are the same. We will primarily be focusing on Microsoft SQL Server. The following table contains resources that are useful references when setting up a database for Dynamics AX:



Microsoft SQL Server TechNet site

Microsoft SQL Server 2008 and Microsoft SQL Server 2008 R2 Books Online

SQL Server 2008:

SQL Server 2008 R2:

Microsoft SQL Server Storage Top 10 Best Practices

Data Warehousing Best Practices in SQL Server

Scaling Up Your Data Warehouse with SQL Server

SQL Server Database requirements

Microsoft Dynamics AX Performance Team Blog

Microsoft Dynamics AX 2009 Planning Database Configuration

As with any company, the level of database space, redundancy, and efficiency is dependent on the number of transactions that the database will have to handle. Therefore, the larger the business, the more is the need for a robust and redundant data store. These constraints will also be important when determining the best database configuration.

As far as the hardware configuration for a database goes, there are many robust options available such as RAID and SAN storage. The database server may contain all the business data and SharePoint content data as well as run SQL Analysis Services for business intelligence. If using RAID, the configuration should be RAID 0+1 (01) or RAID 1+0 (10), in case of the unlikely event of data loss or corruption.

It is certainly possible to have all the databases for the development and test environments on such a server. However, the production environment should have its own database server. For example, a multiple processor core system with 8 GB to 16 GB of RAM per database with at least 2 TB of storage. Additionally, backups should occur as needed, otherwise, they should occur daily during off-peak hours.

For minimum database server requirements, please refer to the following table:


CPU speed (GHz)

Single Core CPUs

Dual Core CPUs



Network (GB)

Windows Server 2008/2008 R2 Enterprise Edition (x64)




8-16 or more

500 or more on RAID configuration



These are manual requirements. Since computer hardware evolves exponentially, these recommendations may not be the best approach for hardware setup as time goes by.

Additionally, the larger the enterprise, the greater the need to have a SAN storage system. The following table outlines a possible hardware setup scenario:

Storage solution


Number of disks for SQL Server and Tempdb

Number of disks for SQL Server log

Total number of disks

Direct Attached Storage (DAS)


12-16 (RAID-10)

2 (RAID-1)


Storage Area Network (SAN)


12-16 (RAID-10)

2 (RAID-1)


Storage Area Network (SAN)


12-16 (RAID-10)

2 (RAID-1)


Storage Area Network (SAN)


16-20 (RAID-10)

2 (RAID-1)


Storage Area Network (SAN)


16-20 (RAID-10)

2 (RAID-1)



SAN setup and configuration may be different among vendors. Therefore, please consult your SAN vendor for more detailed information.

Application Object Server requirements

The Application Object Server (AOS) is essentially the "heart" of Dynamics AX. This is where all the business logic, application objects, and operations are handled. Due to this, it is no surprise how important it is to make sure that the AOS operates as best as it can. Performance resources allocated to one or more AOSs must be done as follows: depending on the number of concurrent users, you may be required to implement multiple AOSs.

In order to successfully determine how many AOSs are required, the basic rule of thumb is that there should be one AOS for every 60 concurrent users (based on the recommended configuration). Therefore, if your company has 120 concurrent users, you would need to implement two AOSs and load balance them both. You can load balance either using hardware or software. Dynamics AX already includes the feature of clustering multiple AOSs. Clustering may be a more cost-effective approach to load balancing, yet may not be as powerful as hardware-based solutions. A company will need to leverage the two based on performance and cost.

Application file server requirements

The Application file server will hold all the application files, which contain all the application code, modules, and customizations for Dynamics AX. The server should have sufficient space to hold this information. Typically, for one environment, the application file folder with base modules takes about 7 GB of space. However, for backups and additional possible maintenance tasks, 100 GB is recommended. Network bandwidth, disk performance, and fault tolerance (RAID configuration) are the emphasis for this server. The server will not be performing any business calculations; however, it will be serving the AOS server application data. In a clustered or load balanced environment, the application file folder, for an environment, will be a network share. However, the shared folder cannot be set up as a Distributed File System (DFS). Although it's not required to backup the application files unless the codebase is modified, backups of the application file folder should occur daily during off-peak hours to ensure an easy restore plan.

The following table describes a recommended configuration for a typical Application file server:


CPU speed (GHz)

Single Core CPUs

Dual Core CPUs



Network (GB)

Windows Server 2008/2008 R2 Enterprise Edition (x64)




4-6 (without SQL Server)

Two 100 GB HDD with RAID configuration


Web server requirements

A web server will serve Enterprise Portal content, Reporting Services reports, Application Integration Framework (AIF) web services, or Workflow. Depending on the number of concurrent users or available resources, a single web server can contain more than one Dynamics AX extended server component or a dedicated web server may be required for each extended server component. It is important to assess the requirements for accessing such services. Available network bandwidth, security, response time, and processor speed are the emphasis for a web server. This server will connect to the AOS server and serve as a frontend access to Dynamics AX instead of using the rich client. The following table describes the minimal requirements for a typical web server used for Dynamics AX extended server components:


CPU speed (GHz)

Single Core CPUs

Dual Core CPUs



Network (GB)

Windows Server 2008/2008R2 Enterprise Edition (x64)





100 GB



Network planning

There is a minimum requirement in order for Dynamics AX 2009 to function. That is, a data rate of no less than 100 Megabits per second (Mbps) between the client to the AOS and the AOS to the database. There must also be latency of no more than 5 milliseconds between the client to the AOS and the AOS to the database, as shown in the following table:


Client to AOS

AOS to database


100 Mbps

100 Mbps


5 ms

5 ms

The information here should fit the current majority of megabit Ethernet network infrastructure; however, it is recommended to have a more current gigabit Ethernet infrastructure.

Domain Controller setup

Dynamics AX will integrate seamlessly with Active Directory. However, in order for this to work properly, appropriate steps must be completed. You will need to consider the following domain requirements when installing Dynamics AX:

  • Computers running Microsoft Dynamics AX components must have access to other computers in the same Active Directory domain, with Active Directory configured in native mode.

  • In the recommended production configuration, since Microsoft Dynamics AX extended server components, such as the Enterprise Portal, Role Centers, and Reporting Extensions are installed on separate servers, Kerberos authentication is the required method of authentication. Otherwise, the Role Center web parts will fail to load.

  • More information on setting up Kerberos authentication will be detailed in Chapter 5, Setting Up Kerberos Authentication.

  • It is recommended that current users in an organization are partitioned into logical groups. This will be very helpful when importing users into Dynamics AX, and assigning group permissions and setting up alerts.


Software planning

Dynamics AX is a flexible ERP system, so there are certain features and modules that a company may need while others may not. It is important to determine what functions a company will require prior to performing any hardware or network sizing. One cannot possibly make an accurate estimate as to determine what will be required. For example, a company may require the usage of the Dynamics AX .NET Business Connector to integrate with other systems; therefore, a license will have to be acquired for the business connector. Having said that, the first steps will be to determine which functions and features a company will require. Afterwards, it will be easier to determine the server, hardware, and network resources to support the modules. Currently, there are three editions of pre-selected Dynamics AX 2009 licensing options:

  1. 1. Business Essentials

  2. 2. Advanced Management

  3. 3. Advanced Management Enterprise

A Microsoft Certified Partner would be able to assist you in choosing the appropriate software license.

Dynamics AX components will only work in a Windows environment. You can run Dynamics AX server components on either Windows Server 2003 with Service Pack 2, Windows Server 2008, or Windows Server 2008 R2. Both 32-bit and 64-bit versions are supported; however, we will be using a 64-bit version because 64-bit computing provides greater processing and memory addressing gains. Simply put, you can access and process larger sets of data in equal or greater speed than a 32-bit system.

The .NET Business Connector can be installed on either a 32-bit or 64-bit system. The Dynamics AX client, which is a 32-bit application, can be installed on Windows XP Service Pack 2, all Windows Vista versions with Service Pack 1, all Windows 7 versions, and Windows Server 2003 or 2008 systems.


Microsoft Dynamics AX 2009 does not support the Itanium platform.

Database software

Dynamics AX 2009 can use either Microsoft SQL Server 2005 with Service Pack 2 (Standard or Enterprise editions), Microsoft SQL Server 2008 (Standard or Enterprise edition), or Oracle Database Server 10g R2 (Enterprise or Standard Windows versions only) for a database. Online Analytical Processing (OLAP) is not supported by the Oracle Database Server. Each database server provides its own strengths and weaknesses. For example, your organization may decide to opt for SQL Server 2005 because of its maturity level or opt for SQL Server 2008 for many new and unique features. For the purpose of this book, we will cover the setup and configuration on SQL Server 2008 and 2008 R2.

Software integration

It may be part of an implementation to integrate Dynamics AX with other systems such as Microsoft Project Server, BizTalk, Web service, or any other application or service. It should be noted that specific requirements will need to be established. Depending on the implementation of these integration points, you may have to include the load and usage into determining the level of usage of Dynamics AX.

Single server topology

A single server topology is when all Dynamics AX extended and base server components are installed on a single server. This can also be considered as a development or demo environment. A single server topology consists of all the server base and extended components on the same system. This topology should never be used for a production environment.

Small-scale topology

A small-scale server topology is when related components are on a single server because they share the same resources. For example, Dynamics AX extended server components that use Internet Information Services (IIS), such as the Enterprise Portal, Reporting Extensions, Workflow, or the AIF. In such a configuration, Kerberos authentication is not required. Although a small-scale topology may be quicker and easier to implement, it lacks scalability, availability, or the best possible performance. For an example diagram of a small-scale topology implementation, refer to:,AX.50).gif.

Large-scale topology

In a large-scale topology implementation, base server components, such as the AOS, database, and Application file server exist in their own server. The AOS and database can be clustered to increase scalability, resources, and availability. However, the Enterprise Portal can exist in an IIS cluster along with Workflow, AIF, and Reporting Extensions. A large-scale topology is based on a small-scale topology except it is far more scalable, reliable, and provides a greater performance capacity. This would require more time to implement and Kerberos authentication is required. However, the benefits include the best possible availability and scalability, as well as failover precautions and load balancing for optimal user and transaction performance. For an example diagram of a large-scale topology implementation refer to:,AX.50).gif.

Large-scale distribution topology

In a large-scale distributed topology implementation, each base and extended server component has its own dedicated server, which may or may not be clustered. A large-scale distributed topology is almost identical to the large-scale topology. However, this topology configuration provides scalability, availability, greater performance capacity, and fault tolerance. For an example diagram of a large-scale topology implementation, refer to:,AX.50).gif.

Intranet and extranet topologies

Typically, most companies only access their ERP system using an intranet configuration. However, it may be required that Dynamics AX will need to be accessible outside of a company's intranet using an extranet connection. Such an example is connecting to a company's network through a remote Virtual Private Network (VPN) connection. This shows a possible scenario where users may want to connect to Dynamics AX resources remotely. Extra considerations will need to be made to incorporate mobile devices since, these devices are usually provided by third party vendors. Typically, mobile devices can access Dynamics AX resources in both topologies.

Permission requirements

Each component for Dynamics AX requires specific permissions. Most of these permissions are administrator level permissions. However, to make sure you audit your permissions carefully, the following table gives a list of the components and required installation rights:


Permissions required to install

Application Object Server (AOS)

Member of the securityadmin role on Microsoft SQL Server database.

Microsoft SQL Server database

Member of the dbcreator role on SQL Server database.

(Specific permissions will need to be set for Oracle.)

Application files




Role Centers and Enterprise Portal framework



Member of the Administrators group in Microsoft Dynamics AX.

Analysis extensions


Reporting extensions


Reporting tools


Enterprise Portal developer tools


Synchronization service


Synchronization proxy

Member of the dbowner database role on the SQL Server database for Microsoft Project server, and an administrator on the computer that is running Office Project Server.

AIF Web services


BizTalk adapter


.NET Business Connector


Developer installation

Member of the dbcreator role on the SQL Server database.


During an implementation of Dynamics AX, remote access to the network will be required for outside development and testing tasks. For security reasons, it is recommended that you use a secured VPN to provide remote access to an internal company network.


Miscellaneous implementation tasks

During an implementation, there will be specific documents, configuration files, applications, and other miscellaneous files that will be required for a Dynamics AX 2009 implementation. This file store should be in an easily accessible location for people involved in an implementation. Such files can be stored on a SharePoint site or on a network drive. The following screenshot contains a sample file structure:

This screenshot only represents an example sample file structure, but depending on your specific implementation, more directories may be required. However, the AX Config Files folder is very important as this will be the file to access Dynamics AX 2009.

Before creating your environments, you will need to determine what to name your environments. Your environment names should contain enough information to know the version and instance. The following table contains sample names for the Ingnomics example company:















In this chapter, we discussed the processes that you will need to follow in order to prepare your environment for implementing Dynamics AX 2009. Having a properly orchestrated preparation saves many unnecessary issues and potential setbacks that can be easily eliminated if the configuration and setup is done properly from the beginning.

In the next chapter, we will go through the setup and configuration of the Dynamics AX 2009 base server components and the running of the Dynamics AX AOS.

About the Author

  • Marco Carvalho

    Marco Carvalho has over ten years experience in the software development and IT industry. He started working with Axapta in 2003 and has since been working exclusively developing and implementing solutions for Dynamics AX. Amongst other things, Marco along with Microsoft and various ISVs, has pioneered the integration of Dynamics AX with proprietary and third-party systems. He has also developed unique solutions that integrate Dynamics AX with Mobile and .NET technologies. Additionally, Marco enjoys educating organizations and training developers on Dynamics AX. He has held senior and management-level positions but serves as the CTO of Ingnomics Solutions, LLC an upcoming Microsoft VAR.

    Browse publications by this author
Microsoft Dynamics AX 2009 Administration
Unlock this book and the full library for FREE
Start free trial