Your SlideShare is downloading. ×
Deploying customizations across microsoft dynamics ax 2012 environments ax2012
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Deploying customizations across microsoft dynamics ax 2012 environments ax2012

6,881
views

Published on

Deploying Customisations

Deploying Customisations

Published in: Technology

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,881
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Microsoft Dynamics AX 2012 ®Deploying customizationsacross Microsoft DynamicsAX environmentsWhite PaperThis white paper discusses best practices for deployingcustomizations from one Microsoft Dynamics AX 2012environment to another as part of the overall applicationlifecycle management process.http://microsoft.com/dynamics/axDate: July 2011Author: Dan Cromer, Program Manager for SetupContributors:Robert Badawy, TesterLiwu Hao, TesterRich Lazar, Test LeadRoy Leung, Test LeadKlaus Madsen, TesterIgor Menchoutkine, Test LeadNitin Sharma, Program Manager for AIF and ServicesSend suggestions and comments about this document toadocs@microsoft.com. Please include the title with yourfeedback.
  • 2. Table of ContentsIntroduction .......................................................................................................................... 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 ................................................................................................ 7Ensure 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 ....................................................................................................................... 10Export from the source environment .................................................................................. 10 Export metadata .......................................................................................................................................................... 10 Exporting workflows from source environment ................................................................................................................ 11 Exporting integration port data from source environment ................................................................................................. 11Prepare 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 ......................................................................................................................... 14Import 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 .............................................................................. 18Finalize the deployment ...................................................................................................... 18 Cleanup the old metadata schema ................................................................................................................................. 18 Set the AOS instance to reaccept clients ......................................................................................................................... 18Appendix A: Deploying data ................................................................................................ 19Appendix B: Starting the AOS in "Single-user" mode ......................................................... 20 Method 1: Create a maintenance configuration ................................................................................................................ 20 Method 2: Disable client configurations for your enterprise ............................................................................................... 20Appendix C: Automating workflow export and import ......................................................... 21Appendix D: Automating data import .................................................................................. 232DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 3. IntroductionAs part of the Microsoft Dynamics® AX 2012 application life cycle, every implementation shouldinclude several separate environments to reliably control what code ends up running on thecustomer’s production system. This white paper describes best practices for moving MicrosoftDynamics AX 2012 customizations into the production environment while minimizing downtime.This paper assumes that customers and partners are running a system that has the followingcharacteristics:  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 testenvironment, 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 asmaster 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 atthe same time. There are advantages and disadvantages to each approach. The following tablesummarizes 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 NoIn environments where compile and Common Intermediate Language (CIL) generation time do notmatter, it is fine to do metadata deployment by using XPO files or models. However, in environmentsin which minimizing downtime is critical, like a production system, we recommend deploying the entiremodel store at the same time, because this approach eliminates the need to compile and generate CILon 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
  • 4. TerminologyThe following table explains Microsoft Dynamics AX 2012 terms.Term DefinitionMetadata 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 theLanguage (CIL) Common Language Infrastructure from Microsoft and is more widely known as .NET. An older name for CIL was Microsoft intermediate language (MSIL).4DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 5. Overview of the deployment processThe following diagram illustrates the deployment process that will be described in thispaper.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 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 6. Overview of initializing the target systemBecause the recommended deployment approach involves exporting the entire model store, conflictscan arise if the target system is not initialized properly. In this section, we will describe commonmistakes, and then describe how to initialize a target system correctly.Common mistake: Initializing a target system by importing a single modelTo 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. Source Database Target Database Data ID1 Model Store Model Store Object1 AXID1 .axmodel Object1 AXID2 3. Then, someone runs the system and adds some data, which creates transactional records that reference the AXID. Source Database Target Database Data ID1 Data ID2 Model Store Model Store Object1 AXID1 .axmodel Object1 AXID26DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 7. 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. Source Database Target Database Data ID1 Data ID2 Model Store Model Store Object1 AXID1 .axmodelstore Conflict! Object1 AXID2Unfortunately, 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 MaintainingInstallation-Specific Element IDs.Initializing a target system by exporting the model storeTo 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. Source Database Target Database Data ID1 Model Store Model Store Object1 AXID1 2. Then, we initialize the model store by importing the model store from the source environment. Source Database Target Database Data ID1 Model Store Model Store Object1 AXID1 .axmodelstore Object1 AXID13 It is also possible to create the database manually and then specify this database during Setup, but for thepurposes of this example it does not matter how the database was created. For more information, see the MicrosoftDynamics AX 2012 Installation Guide. 7 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 8. 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. Source Database Target Database Data ID1 Data ID1 Model Store Model Store 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. Source Database Target Database Data ID1 Data ID1 Model Store Model Store Object1 AXID1 .axmodelstore Object1 AXID1This time, the export is successful, because the IDs are guaranteed to match.Ensure that the source system is ready for exportTo ensure that the export from the source system will be successful, it is important to follow the stepsin this section.The procedures in this section require that you use the either the AXUtil command line utility, orWindows PowerShell®. To have access to these utilities, you must install the Management Utilitiescomponent by using Setup.Grant necessary permissions to the deployment accountWe recommend that you create a dedicated account for performing deployments, because deploymentaccounts require significantly elevated privileges.The Windows account that you use to perform the deployment must be able to perform the followingactions 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.8DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 9.  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-AXModelStoreTo run AXUtil grant against a database, the deployment account must be a member of the followingSQL Server roles on the Microsoft Dynamics AX database server: Server role securityadmin Database role accessadminTo grant these SQL Server privileges, you must be a member of the SysAdmin server role on thedatabase instance.You can have a SQL Server system administrator grant you the privileges. If you are a member of theSysAdmin server role, use SQL Server Management Studio or the following commands to grant therights to the account:osql -S %SQLAdministrator% -E -Q "EXEC sp_addsrvrolemember @loginame = N%DeploymentAccount%,@rolename = Nsecurityadmin" -d masterosql -S %SQLAdministrator% -E -Q "EXEC sp_addrolemember Ndb_accessadmin,N%DeploymentAccount%" -d %DatabaseName%After the account has the correct privileges, you can execute AXUtil grant or Windows PowerShellGrant-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 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 10. 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 toTo get help on Windows PowerShell cmdletsExecute the following cmdlet: Get-Help <CmdletName> -fullRe-import all web content into the AOTWeb content in Enterprise Portal may have been modified through Microsoft SharePoint® Server. Toensure that any changes are deployed to the target environment, import the web content back intothe 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 CILTo avoid having to recompile the application in the target environment after the metadata has beendeployed, 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 environmentAfter the source environment is ready for export, the metadata, workflows, integration ports, and anyother necessary data can be exported from the source system.Export metadataTo 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 theneed to recompile and regenerate CIL on the target environment.AXUtil: AXUtil exportstore -file:%AxModelStoreFile% -s:"%SourceDataBaseServer%" - db:"%SourceDataBaseName%" –verboseWindows PowerShell: Export-AXModelStore -file “$AxModelStoreFile" -Server "$SourceDataBaseServer" –Database "$SourceDataBaseName" -Details -verbose10DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 11. Exporting workflows from source environmentWorkflows must be exported and imported by using the workflow editor. By using this method, userscan 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 isbeing deployed by using the AXUtil exportstore command, this will be the case; however, ifmetadata is deployed by using models or .xpo files, additional steps may be needed on the targetsystem 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 environmentBasic ports within Microsoft Dynamics AX 2012 are stored as metadata, and will be automaticallydeployed on the AOS. However, enhanced integration ports are stored as data, and need to beexported by using the data export/import utility. The first time a deployment is performed, you willneed to create definition groups for the inbound and outbound ports. These definition groups can bereused 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 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 12. 8. Clear the tables ExtCodeTable and BarcodeSetup.12DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 13. 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 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 14. 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 deploymentFollow the steps in this section to make sure that the target environment is ready for deployment.Grant necessary permissions to the deployment accountThe Windows account performing the deployment needs the exact same set of permissions on thetarget environment as the ones described for the source environment earlier in this document.Drain active users and reject new clients1. 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 usersIt is important to note that ending the sessions for active users will cause them to lose data. Be surethat 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.2. Open the Online users form: Administration > Online users.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 environmentUse the Service Control Manager to stop each service manually. Alternatively, run the followingcommand from a command prompt:sc %AOSServer% stop %AOSInstance%14DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 15. Import to the target systemWhen the target system is ready for import, the deployment can begin.Copy all deployment artifacts to the target environmentEnsure that you have read access to the location.Importing metadata to the target environmentImport the exported metadata into the destination environment by using AXUtil or WindowsPowerShell. To further reduce downtime, we recommend that you import the metadata into a newschema next to the old one, and then switch to the active schema.4AXUtil: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% /verboseWindows PowerShell:1. Run the schema command to create a new schema. Initialize-AXModelStore -SchemaName "$NewSchema" -Database "$TargetDatabase" –Details2. Import the model store into the temporary schema. Import-AXModelStore -File "$AxModelStoreFile" –SchemaName "$NewSchema" -Database "$TargetDatabase" –Details3. When all users are out of the system, stop the AOS instance. Set-Service -computername $AOSServer -name $AOSInstance -status stopped4. Apply the changes to the model store to move from the temporary schema to the dbo schema. Import-AXModelStore -Apply "$NewSchema" -Database "$TargetDatabase" –DetailsBoth AXUtil and the Windows PowerShell cmdlets have a flag to create a backup of the old schemawhile 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 beapplied. The steps for importing the new schema can be done before users are drained. 15 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 16. Start Microsoft Dynamics AX 2012 for maintenanceAfter the import has completed successfully, a single AOS should be started. Either log on to thecomputer and start the service by using the Service Control Manager, or run one of the followingcommands.Command prompt:sc %AOSServer% start %AOSInstance%Windows PowerShell:Set-Service -computername $AOSServer -name $AOSInstance -status runningNext, start the Microsoft Dynamics AX client. Because the imported model store is already compiledand contains the generated IL, no compile or CIL generation steps are necessary.Synchronize the database, if it is necessaryIf the imported customizations have changed the data dictionary, you must synchronize the database.Create Role Centers from the AOTAlthough Role Centers were moved to the source environment as metadata, they must be created asdata in Microsoft Dynamics AX 2012.1. Open the Microsoft Dynamics AX 2012 client.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 contentWeb content can either be deployed from the AOT or programmatically by using theAxUpdatePortal.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%16DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 17. Import workflows into the production environmentWorkflows are imported by using the workflow editor in the Microsoft Dynamics AX 2012 client.1. Open 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 theworkflows 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 environmentImport integration ports from exported .dat files by going to System administration > Common >Data export/import > Import.Deploy cubes1. 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 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 18. Deploy reportsOn 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 reportsby using Windows PowerShell cmdlets or scripts.Deploy reports by using Publish-AxReportRun 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 reportto deploy.To deploy all reports, substitute * for ReportName.Deploy reports by running the AxDeploy Windows PowerShell scriptThe AxDeploy.ps1 script can be used to deploy all reports from the AOT to the reporting servers. Torun 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> specifiesthe location where the logs should be stored.Finalize the deploymentAfter the customizations are verified as working in the target environment, a few steps should betaken to finalize the deployment.Cleanup the old metadata schemaIf you used the BackupSchema parameter when you imported the model store, you created abackup of the initial model store. When you are satisfied with the new model store, you should deletethe backup schema.AXUtil: AXUtil schema /drop:%OldSchema% /db:%TargetDatabase%Windows PowerShell: Initialize-AXModelStore -Drop "$OldSchema" -Database "$TargetDatabase"Set the AOS instance to reaccept clientsAfter the AOS has restarted, set the AOS instance to accept new client connections.1. Open the Online users form: Administration > Online users.2. On the Server Instances tab, select the AOS instance.3. Click Accept New clients.18DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 19. Appendix A: Deploying dataAt the time of publication, the best practice for deploying data is by using the Microsoft Dynamics AXexport and import functionality. For more information, see Use Microsoft Dynamics AX to transfer(export and import) data and Maintaining installation-specific element IDs. 19 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 20. Appendix B: Starting the AOS in "Single-user" modeAlthough the AOS in Microsoft Dynamics AX 2012 can be set to reject new incoming clientsessions, this setting is reset when the AOS restarts. During maintenance, it is important toprevent other users from connecting to the system. You can use AOS and clientconfigurations to prevent other users from connecting.Method 1: Create a maintenance configurationYou can create a separate AOS and client configuration for use by the deploymentadministrator.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 enterpriseIf you have configured the client across your enterprise to launch by using configurationfiles that are stored on a central file share, you can revoke read access to these files foreveryone except the deployment administrator to prevent users from launching theMicrosoft Dynamics AX 2012 client.20DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 21. Appendix C: Automating workflow export and importThe 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 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 22. #public class WorkflowImportUtil #{ #} ENDSOURCE SOURCE #ImportWorkflow #// Import a workflow XML #public void ImportWorkflow(str workflowFile, boolean isNewWorkflow = true) #{ # Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowExportDefinitionworkflowExportDefinition; # Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowModel importedWorkflowModel; # # if (WinAPI::fileExists(workflowFile)) # { # workflowExportDefinition =Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowModel::LoadExportedWorkflowFromDisk(workflowFile); # 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: END22DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS
  • 23. Appendix D: Automating data importYou can import data into Microsoft Dynamics AX 2012 from the command line. Note that, bydefault, 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 DEPLOYING CUSTOMIZATIONS ACROSS MICROSOFT DYNAMICS AX ENVIRONMENTS
  • 24. Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and yourpeople to make business decisions with greater confidence. Microsoft Dynamics works like and with familiarMicrosoft software, automating and streamlining financial, customer relationship and supply chain processes in away that helps you drive business success.U.S. and Canada Toll Free 1-888-477-7989Worldwide +1-701-281-6500www.microsoft.com/dynamicsThis document is provided “as-is.” Information and views expressed in this document, including URL and otherInternet 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 orconnection is intended or should be inferred.This document does not provide you with any legal rights to any intellectual property in any Microsoft product. Youmay copy and use this document for your internal, reference purposes. You may modify this document for yourinternal, reference purposes.© 2011 Microsoft Corporation. All rights reserved.Microsoft, Microsoft Dynamics, the Microsoft Dynamics logo, Microsoft SQL Server, Windows Server, and WindowsPowerShell are trademarks of the Microsoft group of companies.All other trademarks are property of their respective owners.24DEPLOYING CUSTOMIZATIONS ACROSS DYNAMICS AX 2012 ENVIRONMENTS