Deploying customizations across microsoft dynamics ax 2012 environments ax2012

Microsoft Dynamics AX 2012
®

Deploying customizations
across Microsoft Dynamics
AX environments
White Paper

This white paper discusses best practices for deploying
customizations from one Microsoft Dynamics AX 2012
environment to another as part of the overall application
lifecycle management process.

http://microsoft.com/dynamics/ax

Date: July 2011

Author: Dan Cromer, Program Manager for Setup

Contributors:
Robert Badawy, Tester
Liwu Hao, Tester
Rich Lazar, Test Lead
Roy Leung, Test Lead
Klaus Madsen, Tester
Igor Menchoutkine, Test Lead
Nitin Sharma, Program Manager for AIF and Services

Send suggestions and comments about this document to
adocs@microsoft.com. Please include the title with your
feedback.

Table of Contents
Introduction .......................................................................................................................... 3
Terminology .................................................................................................................................................................. 4
Overview of the deployment process ................................................................................................................................ 5
Overview of initializing the target system ......................................................................................................................... 6
Common mistake: Initializing a target system by importing a single model ....................................................................... 6
Initializing a target system by exporting the model store ................................................................................................ 7

Ensure that the source system is ready for export ................................................................ 8
Grant necessary permissions to the deployment account .................................................................................................... 8
Run AXUtil grant or Windows PowerShell Grant-AXModelStore......................................................................................... 9
Re-import all web content into the AOT .......................................................................................................................... 10
Compile the application and generate CIL ....................................................................................................................... 10

Export from the source environment .................................................................................. 10
Export metadata .......................................................................................................................................................... 10
Exporting workflows from source environment ................................................................................................................ 11
Exporting integration port data from source environment ................................................................................................. 11

Prepare the target environment for deployment ................................................................. 14
Grant necessary permissions to the deployment account .................................................................................................. 14
Drain active users and reject new clients ........................................................................................................................ 14
Remove any active users .............................................................................................................................................. 14
Stop all AOSs in the target environment ......................................................................................................................... 14

Import to the target system ................................................................................................ 15
Copy all deployment artifacts to the target environment ................................................................................................... 15
Importing metadata to the target environment ................................................................................................................ 15
Start Microsoft Dynamics AX 2012 for maintenance ......................................................................................................... 16
Synchronize the database, if it is necessary .................................................................................................................... 16
Create Role Centers from the AOT ................................................................................................................................. 16
Deploy web content ..................................................................................................................................................... 16
Import workflows into the production environment .......................................................................................................... 17
Correct workflows (if you are using XPOs or models) ........................................................................................................ 17
Import integration ports into production environment ...................................................................................................... 17
Deploy cubes .............................................................................................................................................................. 17
Deploy reports ............................................................................................................................................................ 18
Deploy reports by using Publish-AxReport ................................................................................................................... 18
Deploy reports by running the AxDeploy Windows PowerShell script .............................................................................. 18

Finalize the deployment ...................................................................................................... 18
Cleanup the old metadata schema ................................................................................................................................. 18
Set the AOS instance to reaccept clients ......................................................................................................................... 18

Appendix A: Deploying data ................................................................................................ 19

Appendix B: Starting the AOS in "Single-user" mode ......................................................... 20
Method 1: Create a maintenance configuration ................................................................................................................ 20
Method 2: Disable client configurations for your enterprise ............................................................................................... 20

Appendix C: Automating workflow export and import ......................................................... 21

Appendix D: Automating data import .................................................................................. 23

2

DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS

Introduction
As part of the Microsoft Dynamics® AX 2012 application life cycle, every implementation should
include several separate environments to reliably control what code ends up running on the
customer’s production system. This white paper describes best practices for moving Microsoft
Dynamics AX 2012 customizations into the production environment while minimizing downtime.
This paper assumes that customers and partners are running a system that has the following
characteristics:
 Test or pre-production environments are built based on the production environment.
 Modifications are applied first to test or pre-production environments, and then tested.
 Modifications are then deployed to the production environment.
For example, an implementation might contain several development environments, a test
environment, a pre-production environment, and a production environment serving the end users.
A successful deployment involves moving application metadata as well as any necessary data (such as
master data).
In Microsoft Dynamics AX 2012, metadata can be moved by using export/import files (XPOs), models
(a new concept introduced in Microsoft Dynamics AX 2012), or by moving the entire model store at
the same time. There are advantages and disadvantages to each approach. The following table
summarizes the differences between XPO files, model files, and model store files.

XPO files Model files Model store files
Imported/exported by using… MorphX AXUtil.exe or Windows AXUtil.exe or Windows
PowerShell cmdlets PowerShell cmdlets

Can be uninstalled? No Yes No1

Can be signed? No Yes No

Microsoft Dynamics AX Object No No2 Yes
IDs from source environment
preserved?

Compile required? Yes Yes No

IL Generation required? Yes Yes No

In environments where compile and Common Intermediate Language (CIL) generation time do not
matter, it is fine to do metadata deployment by using XPO files or models. However, in environments
in which minimizing downtime is critical, like a production system, we recommend deploying the entire
model store at the same time, because this approach eliminates the need to compile and generate CIL
on the target environment.
The recommended process for deploying customizations is:
 Ensure that the source system is ready for export.
 Export from the source environment.
 Prepare the target environment for deployment.
 Import to the target system.
 Finalize the deployment.

1
A model store can be backed up before it is updated, and then restored in the future, if needed.
2
If a model containing new objects is imported, it may not have the same IDs as another environment. However,
if those objects already exist in the target environment (due to layering) then the IDs will not be changed.

3

DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS

Terminology
The following table explains Microsoft Dynamics AX 2012 terms.

Term Definition
Metadata Information about the properties or structure of data in the Application Object Tree
(AOT) that is not part of the data values. Everything in the AOT is metadata.

Application layer A single layer of the Microsoft Dynamics AX 2012 application within a model store.
Elements in higher layers override elements in lower layers.

Model A named set of elements in a given application layer. Each layer consists of one or
more models, of which one is a system-generated layer model.

Model element A single piece of metadata. For instance, a table definition is a model element. Any
one element in a layer belongs to exactly one model; that is, no element can belong to
two different models nor can it belong to any model.

Model file (.axmodel) A model that has been exported from a model store. This file is the chief vehicle of
metadata deployment in Microsoft Dynamics AX 2012.

Model store file A complete model store that has been exported from the database. The file includes all
(.axmodelstore) metadata, compiled artifacts, CIL code, and security artifacts. The file is used for
moving consistent metadata between environments with minimum downtime.

Model store A collection of tables in the Microsoft Dynamics AX 2012 database that house the
application metadata. The model store is analogous to the AOD file share in Microsoft
Dynamics AX 2009.

Generated data Data that is generated by Microsoft Dynamics AX during development.

Transactional data Data that describes business transactions and the state of the business.

Configuration data Data concerning how Microsoft Dynamics AX 2012 is configured. This data includes the
following subcategories:
Environment: Computer-environment–specific data. An example of environment data
is the list of servers running Microsoft SQL Server® Reporting Services that Microsoft
Dynamics AX 2012 is configured to use. If this data is moved, it needs to be corrected
to account for new server locations.
System: Parameter settings for the Application Object Server (AOS) such as which
database to connect to, or for Enterprise Portal forms.
Application: Number sequences, invoicing profiles, or other data that relates directly
to the application.

Reference data Data that is characterized by shared read operations and infrequent changes.
Examples of reference data include flight schedules and product catalogs. Windows
Server® AppFabric offers the local cache feature for storing this type of data.

Master data The critical data of a business, such as customer, product, location, employee, and
asset. Master data falls generally into four groupings: people, things, places, and
concepts. It also can be further categorized. For example, within people, there are
customer, employee, and salesperson categories. Within things, there are product,
part, store, and asset categories. Within concepts, there are categories like contract,
warrantee, and licenses. Finally, within places, there are office location and geographic
division categories.

Definition group A collection of tables that defines what will be exported by using the data export
feature.

Common Intermediate The Common Intermediate Language instruction set is part of the specification of the
Language (CIL) Common Language Infrastructure from Microsoft and is more widely known as .NET.
An older name for CIL was Microsoft intermediate language (MSIL).

4


Overview of the deployment process
The following diagram illustrates the deployment process that will be described in this
paper.

Deployment Process

Prepare Source for Deployment

Must be performed manually
Start
Metadata Automatable through Ax32.exe
Source Environment

Automatable through utility
Models or
Model Compile, Export
Model Store Automatable through Windows PowerShell
Generate CIL metadata
Store?

Models

Export
Models

Prepare Target for Deployment

Drain users,
Stop all AOS Close active
reject new
instances sessions
clients

Prepare Target for Deployment Publish to Servers Hydrate System

Models or
Model
Models Model Start all AOS
Target Environment

Store Publish cubes End
Store? instances

Import Import
Metadata metadata* Create Role
Centers from
AOT
Allow multi-
user on AOS
Compile and Start single Publish
generate CIL AOS Enterprise
Portal
content
Clean up old
Synchronize model
database Publish schema (if
reports applicable)

5


Overview of initializing the target system
Because the recommended deployment approach involves exporting the entire model store, conflicts
can arise if the target system is not initialized properly. In this section, we will describe common
mistakes, and then describe how to initialize a target system correctly.

Common mistake: Initializing a target system by importing a single model
To avoid element ID conflicts later on, it is essential that the target database (especially in production)
is initialized from an exported source database—not individual model files.
The following example illustrates how conflicts can arise:
1. First, we start with a customization that we want to move into the target environment.

Source Database Target Database

Data ID1

Model Store Model Store

Object1 AXID1

2. We import the model that contains our customizations. Because this is a new object that
does not already exist in the target system, Microsoft Dynamics AX may give the object an
ID that is different from the ID in the source system.


Data ID1


Object1 AXID1 .axmodel Object1 AXID2

3. Then, someone runs the system and adds some data, which creates transactional records
that reference the AXID.


Data ID1 Data ID2


Object1 AXID1 .axmodel Object1 AXID2

6


4. Now, we have made another customization and want to deploy the entire model store for
minimal downtime. To do this, we export the entire model store, which includes the IDs.


Data ID1 Data ID2


Object1' AXID1 .axmodelstore Conflict! Object1 AXID2

Unfortunately, we will run into conflicts, because the IDs in the two systems are different.
For more information about why element ID conflicts arise in these situations, see Maintaining
Installation-Specific Element IDs.

Initializing a target system by exporting the model store
To properly initialize the source system, follow the following process:
1. We start with a blank database created by using Setup3. It will contain, at a minimum,
the Foundation SYS model, but none of the customizations that should be deployed.


Data ID1


Object1 AXID1

2. Then, we initialize the model store by importing the model store from the source
environment.


Data ID1


Object1 AXID1 .axmodelstore Object1 AXID1

3
It is also possible to create the database manually and then specify this database during Setup, but for the
purposes of this example it does not matter how the database was created. For more information, see the Microsoft
Dynamics AX 2012 Installation Guide.

7


3. At this point, we can safely start adding data to the target system. At the same time,
customizations are made to the source system.


Data ID1 Data ID1


Object1' AXID1 Object1 AXID1

4. When it is time to re-deploy the customizations, the entire model store is once again
exported to minimize system downtime.


Data ID1 Data ID1


Object1' AXID1 .axmodelstore Object1 AXID1

This time, the export is successful, because the IDs are guaranteed to match.

Ensure that the source system is ready for export
To ensure that the export from the source system will be successful, it is important to follow the steps
in this section.
The procedures in this section require that you use the either the AXUtil command line utility, or
Windows PowerShell®. To have access to these utilities, you must install the Management Utilities
component by using Setup.

Grant necessary permissions to the deployment account
We recommend that you create a dedicated account for performing deployments, because deployment
accounts require significantly elevated privileges.
The Windows account that you use to perform the deployment must be able to perform the following
actions in order to export customizations from the source environment:
 It must be able to start and run the Microsoft Dynamics AX client.
 It must have permissions to start and stop every AOS service in the source environment.

The account must therefore have the following rights and privileges:
 It must be able to execute AXUtil.exe or the AXUtilLib.PowerShell cmdlet module – this requires
that it have read and execute access to the folder <Microsoft Dynamics AX installation
folder>ManagementUtilities.

8


 It must have write access to a local location in which the .axmodelstore file can be saved to export
metadata.
 It must have administrative permissions on the local computer.
 It must be a member of the Microsoft Dynamics AX role System administrator.
 If you are working with Enterprise Portal for Microsoft Dynamics AX, the account must be able to
run on the server that runs Enterprise Portal. The account must have the following rights:
 Microsoft SharePoint Server farm administrator
 Membership in the local Administrators group on the server that runs Enterprise Portal
 If you are working with Microsoft SQL Server Reporting Services, the account must have the
following rights on the server that runs Reporting Services:
 System Administrator rights in Reporting Services
 Membership in the local Administrators group on the server that runs Reporting Services
 It must have privileges in the Microsoft Dynamics AX database given by running the AXUtil grant
command or the Windows PowerShell Grant-AXModelStore cmdlet.
Note: The grant command is used by default on the AOS Service account, but we recommend that
you use a different account for deploying customizations, and run the grant command for it.

Run AXUtil grant or Windows PowerShell Grant-AXModelStore
To run AXUtil grant against a database, the deployment account must be a member of the following
SQL Server roles on the Microsoft Dynamics AX database server:
 Server role securityadmin
 Database role accessadmin

To grant these SQL Server privileges, you must be a member of the SysAdmin server role on the
database instance.
You can have a SQL Server system administrator grant you the privileges. If you are a member of the
SysAdmin server role, use SQL Server Management Studio or the following commands to grant the
rights to the account:
osql -S %SQLAdministrator% -E -Q "EXEC sp_addsrvrolemember @loginame = N'%DeploymentAccount%',
@rolename = N'securityadmin'" -d master
osql -S %SQLAdministrator% -E -Q "EXEC sp_addrolemember N'db_accessadmin',
N'%DeploymentAccount%'" -d %DatabaseName%

After the account has the correct privileges, you can execute AXUtil grant or Windows PowerShell
Grant-AXModelStore.
To run AXUtil grant:
1. Open a command prompt, and navigate to the <Microsoft Dynamics AX installation
folder>ManagementUtilities folder.
2. Execute the following command:
AXUtil grant -aosaccount::%account" -s:"%SourceDataBaseServer%" -db:"%SourceDataBaseName%
Where %account is the account that you are granting privileges to. The –s and –db parameters
are included in the command to clearly specify which database and server you are granting access
to.
To get help on AXUtil commands:
AXUtil.exe /?

9


To run the Windows PowerShell Grant-AXModelStore cmdlet:
1. On the Start menu, point to Administrative Tools, and then click Microsoft Dynamics AX
2012 Management Shell.
2. Execute the following cmdlet:
Grant-AXModelStore -aosaccount "$account" -Server "$SourceDataBaseServer" -
Database:"$SourceDataBaseName"
Where $account is the account that you are granting privileges to. The –Server and –Database
parameters are included in the command to clearly specify which database and server you are
granting access to

To get help on Windows PowerShell cmdlets
Execute the following cmdlet:
Get-Help <CmdletName> -full

Re-import all web content into the AOT
Web content in Enterprise Portal may have been modified through Microsoft SharePoint® Server. To
ensure that any changes are deployed to the target environment, import the web content back into
the AOT before deploying the metadata.

1. Open the AOT in the source environment.
2. Expand the Web > Web Menu Items > URLs node in the AOT.
3. For each URL that has been modified, right-click the item and click Import Page.

Compile the application and generate CIL
To avoid having to recompile the application in the target environment after the metadata has been
deployed, compile the application and generate CIL in the source environment. For more information,
see Code Compiler and X++ Compiled to .NET CIL.

Export from the source environment
After the source environment is ready for export, the metadata, workflows, integration ports, and any
other necessary data can be exported from the source system.

Export metadata
To export the metadata, use the AXUtil exportstore command or the Windows PowerShell Export-
AXModelStore cmdlet to migrate the entire metadata store at the same time. This will eliminate the
need to recompile and regenerate CIL on the target environment.
AXUtil:
AXUtil exportstore -file:%AxModelStoreFile% -s:"%SourceDataBaseServer%" -
db:"%SourceDataBaseName%" –verbose

Windows PowerShell:
Export-AXModelStore -file “$AxModelStoreFile" -Server "$SourceDataBaseServer" –Database
"$SourceDataBaseName" -Details -verbose

10


Exporting workflows from source environment
Workflows must be exported and imported by using the workflow editor. By using this method, users
can select workflows from within the workflow list page and export them to XML files.
Note: We assume that the object IDs of the workflows match between environments. If metadata is
being deployed by using the AXUtil exportstore command, this will be the case; however, if
metadata is deployed by using models or .xpo files, additional steps may be needed on the target
system to correct the object IDs, depending on the complexity of the workflows.
1. Open the Microsoft Dynamics AX client in the source environment.
2. Open the workflow list page for the workflow you want to export (for example, click Travel and
expense > Setup > Travel and expense workflows).
3. Select the workflow that you want to export and click Versions.
4. In Workflow version dialog box, select a version of the workflow and click Export on the
toolbar.
5. In the Export to dialog box, type the filename and click OK.
6. Repeat Steps 1-5 for each workflow that you need to export.

Exporting integration port data from source environment
Basic ports within Microsoft Dynamics AX 2012 are stored as metadata, and will be automatically
deployed on the AOS. However, enhanced integration ports are stored as data, and need to be
exported by using the data export/import utility. The first time a deployment is performed, you will
need to create definition groups for the inbound and outbound ports. These definition groups can be
reused for future deployments.
1. Click System administration > Common > Data export/import > Definition groups. Click
New.
2. Enter a name and description for the definition group.
3. Click Clear to clear all values on the Options and Include table groups tabs.
4. On the Options tab, select Include system tables and Include shared tables, and then click
OK.
5. Click Select tables. In the Name of table list, click AifInboundPort.
6. Select Apply criteria and Specify related tables to make the Export criteria and Select
related tables buttons available.
7. Click Select related tables. In the Select related tables form, set the value of Relationship
levels to 2.

11


8. Clear the tables ExtCodeTable and BarcodeSetup.

12


9. Click Select all remaining levels, and then click Close.

10. Click Export criteria. In the Criteria field, select the name property AifInboundPort, and then
click OK.

13


11. Repeat steps 1-10 to create a second definition group for outbound ports. Repeat the same
process using AifOutboundPort as the root table. Set the export criteria to filter on the name
AifOutboundPort.
12. To export the data, click System administration > Common > Data export/import > Export
to.
13. On the General tab, select the definition group that you want to use for the export.
14. Enter the name and location of the file that you want to export the data to on a local or network
share, and click OK.

Prepare the target environment for deployment
Follow the steps in this section to make sure that the target environment is ready for deployment.

Grant necessary permissions to the deployment account
The Windows account performing the deployment needs the exact same set of permissions on the
target environment as the ones described for the source environment earlier in this document.

Drain active users and reject new clients
1. Set all AOS instances to reject incoming client connections.
1. Open the Online users form: Administration > Online users.
2. On the Server Instances tab, select the AOS instance.
3. Click Reject New clients.
2. Stop load balancers, if applicable – This will prevent new service clients from connecting.
3. Restart all Reporting Services servers – This will force the Reporting Services server to recycle its
idle connections.
4. Open a page on the Enterprise Portal site – This will force SharePoint Server to recycle its idle
connections.

Remove any active users
It is important to note that ending the sessions for active users will cause them to lose data. Be sure
that you have followed the steps above before you decide to stop any active client sessions.
To end active client sessions for each AOS, use the Online users form.
1. Open the Microsoft Dynamics AX 2012 client.
3. On the Client instances tab, select the AOS instance.
4. Click End Sessions.
Be sure to also end the sessions for web users.

Stop all AOSs in the target environment
Use the Service Control Manager to stop each service manually. Alternatively, run the following
command from a command prompt:
sc %AOSServer% stop %AOSInstance%

14


Import to the target system
When the target system is ready for import, the deployment can begin.

Copy all deployment artifacts to the target environment
Ensure that you have read access to the location.

Importing metadata to the target environment
Import the exported metadata into the destination environment by using AXUtil or Windows
PowerShell. To further reduce downtime, we recommend that you import the metadata into a new
schema next to the old one, and then switch to the active schema.4
AXUtil:
1. Run the schema command to create a new schema.
AXUtil schema /schemaname:%NewSchema% /db:%TargetDatabase%
2. Import the model store into the temporary schema.
AXUtil importstore /file:%AxModelStoreFile% /schemaname:%NewSchema% /db:%TargetDatabase%
3. When all users are out of the system, stop the AOS instance.
sc %AOSServer% stop %AOSInstance%
4. Apply the changes to the model store to move from the temporary schema to the dbo schema.
AXUtil importstore /apply:%NewSchema% /db:%TargetDatabase% /verbose

Windows PowerShell:
1. Run the schema command to create a new schema.
Initialize-AXModelStore -SchemaName "$NewSchema" -Database "$TargetDatabase" –Details
2. Import the model store into the temporary schema.
Import-AXModelStore -File "$AxModelStoreFile" –SchemaName "$NewSchema" -Database
"$TargetDatabase" –Details
3. When all users are out of the system, stop the AOS instance.
Set-Service -computername $AOSServer -name $AOSInstance -status stopped
4. Apply the changes to the model store to move from the temporary schema to the dbo schema.
Import-AXModelStore -Apply "$NewSchema" -Database "$TargetDatabase" –Details

Both AXUtil and the Windows PowerShell cmdlets have a flag to create a backup of the old schema
while the new schema is applied. For more information, see the documentation on these commands,
available within the utilities.

4
It is possible for users to continue using the system until the AOS needs to be restarted so the schema can be
applied. The steps for importing the new schema can be done before users are drained.

15


Start Microsoft Dynamics AX 2012 for maintenance
After the import has completed successfully, a single AOS should be started. Either log on to the
computer and start the service by using the Service Control Manager, or run one of the following
commands.
Command prompt:
sc %AOSServer% start %AOSInstance%

Windows PowerShell:
Set-Service -computername $AOSServer -name $AOSInstance -status running

Next, start the Microsoft Dynamics AX client. Because the imported model store is already compiled
and contains the generated IL, no compile or CIL generation steps are necessary.

Synchronize the database, if it is necessary
If the imported customizations have changed the data dictionary, you must synchronize the database.

Create Role Centers from the AOT
Although Role Centers were moved to the source environment as metadata, they must be created as
data in Microsoft Dynamics AX 2012.
2. Go to the Role Center pane. In the Navigation window, select System Administration and click
User Profiles.
3. Click File > New to create a new role.
4. Enter a Profile ID and Description.
5. Select the Role Center from the drop-down menu.
6. Click Add User to Role Center.
7. Select the User ID to add and click OK.

Deploy web content
Web content can either be deployed from the AOT or programmatically by using the
AxUpdatePortal.exe command line utility, which is installed with the Management Utilities by Setup.
All web content can be updated at the same time by using the following command:
AxUpdatePortal.exe -updateall -websiteurl %SiteUrl%

Individual web content items can be deployed by specifying their location in the AOT:
AxUpdatePortal.exe -updatewebcomponent -treenodepath %TreeNodePath% -websiteurl %SiteUrl%

Additionally, proxies and DLLs can be deployed by using the following command:
AXUpdatePortal.exe -proxies -websiteurl %SiteUrl%

16


Import workflows into the production environment
Workflows are imported by using the workflow editor in the Microsoft Dynamics AX 2012 client.
2. Open the workflow list page (for example, click Travel and expense > Setup > Travel and
expense workflows).
3. Click Import.
4. In the Import dialog box, select the filename and click OK.
If you imported the metadata by using the AXUtil exportstore functionality described in this
document, you have finished.
5. Repeat for all workflows that you want to import.

Correct workflows (if you are using XPOs or models)
If you deployed the metadata by using models or XPOs, the Object IDs may have changed, and the
workflows may need to be corrected.
1. If you have a parent workflow that contains sub-workflows, you need to re-link the sub-workflow
with the parent workflow:
1. Open the parent workflow in the Workflow Editor.
2. Select the sub-workflow element.
3. In the Properties window, choose the appropriate sub-workflow and its field.
4. Save the parent workflow.
2. If you have a header workflow that contains line item workflows, you need to re-link line item
workflows with the header workflow:
1. Open the header workflow in the Workflow Editor.
2. Select the line-item workflow element.
3. In the Properties window, choose the appropriate line-item workflow.
4. Save the header workflow.
3. Repeat for all workflows that you want to import.

Import integration ports into production environment
Import integration ports from exported .dat files by going to System administration > Common >
Data export/import > Import.

Deploy cubes
1. Go to Tools > Business Analysis > Sql Server Analysis Wizard.
2. Click Next.
3. Click Deploy.
4. Select a project from the AOT drop-down menu. Click Next.
5. Click Deploy the Project. Click Create New Database. Click Next.
6. The deployment window opens, which may take a few minutes. Click Next.

17


Deploy reports
On the source system, reports are exported when you export the model store.
To deploy reports on the target system, you first import the model store, and then deploy the reports
by using Windows PowerShell cmdlets or scripts.

Deploy reports by using Publish-AxReport
Run the following cmdlet:
Publish-AxReport –Id $ConfigId –ReportName "ReportName"
Where $ConfigID is the ID of the AOS configuration to use, and ReportName is the name of the report
to deploy.
To deploy all reports, substitute * for ReportName.

Deploy reports by running the AxDeploy Windows PowerShell script
The AxDeploy.ps1 script can be used to deploy all reports from the AOT to the reporting servers. To
run the script, navigate to the <Microsoft Dynamics AX installation folder>ManagementUtilities folder,
open a command prompt, and enter the following:
AxDeployReports.ps1 <ConfigurationID> <LogFilePath>

Where <ConfigurationID> specifies the configuration of the AOS to use, and <LogFilePath> specifies
the location where the logs should be stored.

Finalize the deployment
After the customizations are verified as working in the target environment, a few steps should be
taken to finalize the deployment.

Cleanup the old metadata schema
If you used the BackupSchema parameter when you imported the model store, you created a
backup of the initial model store. When you are satisfied with the new model store, you should delete
the backup schema.
AXUtil:
AXUtil schema /drop:%OldSchema% /db:%TargetDatabase%

Windows PowerShell:
Initialize-AXModelStore -Drop "$OldSchema" -Database "$TargetDatabase"

Set the AOS instance to reaccept clients
After the AOS has restarted, set the AOS instance to accept new client connections.
2. On the Server Instances tab, select the AOS instance.
3. Click Accept New clients.

18


Appendix A: Deploying data
At the time of publication, the best practice for deploying data is by using the Microsoft Dynamics AX
export and import functionality. For more information, see Use Microsoft Dynamics AX to transfer
(export and import) data and Maintaining installation-specific element IDs.

19


Appendix B: Starting the AOS in "Single-user" mode
Although the AOS in Microsoft Dynamics AX 2012 can be set to reject new incoming client
sessions, this setting is reset when the AOS restarts. During maintenance, it is important to
prevent other users from connecting to the system. You can use AOS and client
configurations to prevent other users from connecting.

Method 1: Create a maintenance configuration
You can create a separate AOS and client configuration for use by the deployment
administrator.

1. Use the server configuration utility to create a copy of the active configuration.
2. Change the TCP/IP and WSDL ports to different values.
3. Use the client configuration utility to create a copy of the active client configuration.
4. Change the TCP/IP and WSDL ports to the values used for the server configuration.

During maintenance, change the AOS and maintenance client to use these configurations.
This will prevent users from connecting to the maintenance AOS.

Method 2: Disable client configurations for your enterprise
If you have configured the client across your enterprise to launch by using configuration
files that are stored on a central file share, you can revoke read access to these files for
everyone except the deployment administrator to prevent users from launching the
Microsoft Dynamics AX 2012 client.

20


Appendix C: Automating workflow export and import
The following example class can be used to automate workflow export and import.

***Element: CLS

; Microsoft Dynamics AX Class: WorkflowImportUtil unloaded
; --------------------------------------------------------------------------------
CLSVERSION 1

CLASS #WorkflowImportUtil
PROPERTIES
Name #WorkflowImportUtil
Origin #{187DA138-A34F-48F8-8C8D-769800EB35D2}
ENDPROPERTIES

METHODS
SOURCE #GetFullFileName
#private str GetFullFileName(str _filePath, str _fileName)
#{
# FileName filePathName;
# FileName fileName;
# FileName fileExtension;
# ;
#
# [filePathName,fileName,fileExtension] = fileNameSplit(_fileName);
# return _filePath + '' + fileName + fileExtension;
#}
ENDSOURCE
SOURCE #ImportWorkflows
#// Import all workflow XMLs from a specific folder
#public void ImportWorkflows(str workflowFilePath)
#{
# int workflowFileHandle;
# str workflowFileName;
#
# if (WinAPI::folderExists(workflowFilePath))
# {
# [workflowFileHandle, workflowFileName] = WinAPI::findFirstFile(
# this.GetFullFileName(workflowFilePath, "*.xml"));
#
# while (workflowFileName)
# {
# this.ImportWorkflow(this.GetFullFileName(workflowFilePath,
workflowFileName));
#
# workflowFileName = WinAPI::findNextFile(workflowFileHandle);
# }
# }
#}
ENDSOURCE
SOURCE #classDeclaration

21


#public class WorkflowImportUtil
#{
#}
ENDSOURCE
SOURCE #ImportWorkflow
#// Import a workflow XML
#public void ImportWorkflow(str workflowFile, boolean isNewWorkflow = true)
#{
# Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowExportDefinition
workflowExportDefinition;
# Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowModel importedWorkflowModel;
#
# if (WinAPI::fileExists(workflowFile))
# {
# workflowExportDefinition =
Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowModel::LoadExportedWorkflowFromDisk(workfl
owFile);
# importedWorkflowModel =
Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowModel::Import(
# workflowExportDefinition,
# isNewWorkflow, // true = Create a new workflow on version conflict; false =
skip the import on version conflict
# "Admin", // Current user id
# curext()); // Current company id
# }
#}
ENDSOURCE
ENDMETHODS
ENDCLASS

***Element: END

22


Appendix D: Automating data import
You can import data into Microsoft Dynamics AX 2012 from the command line. Note that, by
default, the import will delete ALL existing data in the target tables and company.

1. Prepare an XML file that describes the data that you want to import. A sample is given below:
<?xml version="1.0"?>
<AxaptaAutoRun version="4.0" logFile="C:ImportDataAutorun.log">
<DataImport file="C:YourData.dat" companyId="DAT" />
</AxaptaAutoRun>

Required XML parameters include the following:
Parameter Description
logFile The log for the import.
file The full file path for the data to be imported.
companyId The company to import the data into.

Optional XML parameters include the following:

Parameter Description
definitionGroupId The definition group used for import.
includeSystemTables Whether to include system tables in the list of tables
to import.
skipSharedTablesForSilentDeletion Sets shared tables not to be deleted during import.
skipSystemTablesForSilentDeletion Sets system tables not to be deleted during import.
skipAllTablesForSilentDeletion No tables are deleted during import.
updateRecord Sets the system to use update record during import.
Use this option to avoid deleting existing data.

2. From the command line, run the following:
AX32.exe -startupcmd=autorun_C:<location>Autorun.xml

23


Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your
people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar
Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a
way that helps you drive business success.

U.S. and Canada Toll Free 1-888-477-7989
Worldwide +1-701-281-6500
www.microsoft.com/dynamics

This document is provided “as-is.” Information and views expressed in this document, including URL and other
Internet Web site references, may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You
may copy and use this document for your internal, reference purposes. You may modify this document for your
internal, reference purposes.

© 2011 Microsoft Corporation. All rights reserved.

Microsoft, Microsoft Dynamics, the Microsoft Dynamics logo, Microsoft SQL Server, Windows Server, and Windows
PowerShell are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

24


Deploying customizations across microsoft dynamics ax 2012 environments ax2012

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Deploying customizations across microsoft dynamics ax 2012 environments ax2012

Similaire à Deploying customizations across microsoft dynamics ax 2012 environments ax2012 (20)

Dernier

Dernier (20)

Deploying customizations across microsoft dynamics ax 2012 environments ax2012