Microsoft Dynamics AX 2012: Tech Domain New Features

Module 5: Moving Between EnvironmentsREVIEW V1.1Moving between Microsoft Dynamics AX 2012 EnvironmentsREVIEW V1.1

Microsoft Dynamics AX 2012: Tech Domain New FeaturesModule 5: Moving Between Environments

REVIEW V1.1Released: June 8, 2011

Conditions and Terms of UseMicrosoft Confidential - For Internal Use OnlyThis training package content is proprietary and confidential, and is intended only for users described in the training materials. This content and information is provided to you under a Non-Disclosure Agreement and cannot be distributed. Copying or disclosing all or any portion of the content and/or information included in this package is strictly prohibited.The contents of this package are for informational and training purposes only and are provided "as is" without warranty of any kind, whether express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, and non-infringement.Training package content, including URL and other Internet Web site references, is subject to change without notice. Because Microsoft must respond to changing market conditions, the content should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.Copyright and Trademarks 2011 Microsoft Corporation. All rights reserved.Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. For more information, see Use of Microsoft Copyrighted Content at http://www.microsoft.com/about/legal/permissions/.Microsoft, Internet Explorer, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Microsoft products mentioned herein may be either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.

About the Authors

Author: Larry Reski

Bio:

Larry is a Senior Technical Lead specializing in Microsoft Dynamics AX technical domain support. He has been working for Microsoft for the past 10 years with a focus on workflow, database, AOS, and Enterprise Portal as well and the other Dynamics AX technologies.

Table of ContentsMoving between Microsoft Dynamics AX 2012 Environments1SUMMARY1Restore the database and set proper SQL permissions3Verify the Kernel and Application versions in the Database3Setting Database Permissions for the AOS service account3Provide Microsoft Dynamics AX user credentials5Changing the Microsoft Dynamics AX users account to new Domain Account information5Configure Base System functionality7Changing theSystem Service Accounts7AOS Services9Install or configure additional components12Non-interactive Business Connector Configuration12Workflow13BI Components14OLAP database14List of Connection strings that reference server and database names14Help Server15Enterprise Portal and Role Centers16Enterprise Search18Project Server Integration19Web Service on IIS19Customized Business Connector integrations20Appendix21Unique GUID per Microsoft Dynamics AX environment21

Moving between Microsoft Dynamics AX 2012 EnvironmentsSUMMARYIt is common practice to restore a Microsoft Dynamics AX database from one environment into another environment for testing and development purposes. In most cases, this is not a problem but there are circumstances that need to be considered to get the restored database functioning. The scope of this document covers settings such as server names, domain names, user accounts, and URLs that may need to be changed in the new environment. In Microsoft Dynamics AX 2012 RTM (6.0), the application code files are stored in the same database as the transactional business data and in Microsoft Dynamics AX 2012 R2 (6.2) there is a separate _model database. Both database implementations require further planning to move environments.

There are special circumstances where there are AOT based metadata and matching SQL database records that need to be moved together, such as customized security or workflow objects. The topic of moving code will not be covered here, but you can refer to Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments.

Consider the following scenarios where users may need to restore a Microsoft Dynamics AX database to a different environment:1. Testing a Microsoft Dynamics AX service pack, rollup, or full version upgrade.2. Bringing Microsoft Dynamics AX 2012 data in house for testing or development.3. Restoring a copy of the production database into a test or development environment to work with the most recent changes.4. Moving a production database from one Active Directory domain to different production Active Directory domain environment.In most scenarios, users should have the base Microsoft Dynamics AX 2012 software installed in the new environment and running at the same service pack and rollup version as the environment where the database was backed up. This would not apply to scenarios where users are testing a service pack, rollup or full version upgrade.At a high level, the process for moving the database from one environment to another will follow these steps:1. Restore the database and set proper SQL permissions.2. Provide correct Microsoft Dynamics AX user credentials to allow users to connect and login with a client.3. Configure the base system functionality for those setting which may have changed.4. Install or configure additional components such as Business Intelligence and Enterprise Portal.The specific requirements of a user's particular scenario may include additional steps or steps in a different order. This document is designed outline common considerations. Having a good understanding of the installation process and all the integrations and touch points will aid users in adapting the process to their needs.Restore the database and set proper SQL permissions Each scenario will begin by making a full SQL server backup, which will be restored to the new environment. This step assumes users are working with a qualified DBA to perform the backup and restore of the SQL database. This section begins with describing the Microsoft Dynamics AX specific steps. Verify the Kernel and Application versions in the DatabaseBefore users install any Microsoft Dynamics AX software in the new environment or determine if they need to update, check the Microsoft Dynamics AX Kernel and Application versions installed with the restored database.select * from SYSSETUPLOG where DESCRIPTION = 'finished' order by CREATEDDATETIME descThe record returned at the top of the list indicates the last time the setup or upgrade checklist was run, note the APPBUILD and KERNELBUILD versions. This may not always give you the most recent build depending if you are working with a database that is not fully upgraded and you can use this query to get the highest build used in this environment by running the following.select distinct(KERNELBUILD) from SYSSETUPLOG In the new environment, you will install the same version of Microsoft Dynamics AX kernel to match these builds. If you setup the new environment with the correct kernel and application build versions, the Upgrade Checklist does not appear when opening a client using an AOS instance connected to the restored database.In Microsoft Dynamics AX 2012, the application layer files are stored in the Microsoft Dynamics AX database instead of on an application file share in previous versions. Implications will be discussed later in this section, when users consider coding related scenarios.Setting Database Permissions for the AOS service accountIf users do not already have an AOS instance installed, they can install a new instance of the AOS and point to the restored database. It will grant the correct SQL permissions and file and folder rights to the AOS account specified during the install. Make sure the AOS instance is running at the correct service pack and rollup before starting the AOS. If there is an existing AOS instance, users will need to grant SQL right to the AOS service account Refer to the Microsoft Dynamics AX 2012 Installation Guide in the section on Create a SQL Server database manually or see the MSDN topic AOS Security. Make sure the database name has been set correctly in the Microsoft Dynamics AX 2012 Server Configuration tool on the Database connection tab

For both Dynamics AX 2012 RTM and Dynamics AX 2012 R2 only one database name is specified in the configuration tool, but for Dynamics AX 2012 R2 where there is the additional model database the naming convention is used of adding the suffix of _model to the database that is used here. So in this example for Dynamics AX 2012 R2 the AXDB is the business database and the model database will need to be called AXDB_model, to match the naming convention.Next, start the Microsoft Dynamics AX Object Server in the Services management tool. If the AOS fails to start, check the application event log for the specific errors and take appropriate corrective actions.Whenever an AOS starts against a database environment a record will be added or updated in the sysserversessions table. In addition, the AOS service account name is also in the AOSaccount field.Table NameColumn in Table

sysServerSessionsAOSAccount

Since the existing records in this table may not be valid in the new environment, these records may need to be removed or updated. The recommended approach would be to remove all records from the sysserversessions table, while all AOS instances are stopped and have the record recreated as the new AOS service starts against the database.

Provide Microsoft Dynamics AX user credentials Changing the Microsoft Dynamics AX users account to new Domain Account informationIn order for the user's Microsoft Dynamics AX account to log into the restored database environment, their domain account must be a user in the system. Microsoft Dynamics AX 2012 is integrated with Active Directory. The account information in the database must match the user and or domain in the new environment. If the user is simply restoring the database to a different server in the same Active Directory domain, and the user account is already in the Microsoft Dynamics AX sysadmin role in the restored database, then the following steps would not be required.1. The following information about the new user and or domain environment is needed: the active directory Security identifier (SID), Network domain name, and user account Network alias. If this information is already in another Microsoft Dynamics database the user can run the following SQL script to get the information they will use with the newly restore database:select SID, Networkdomain, networkalias from userinfo where networkalias = ''The placeholder represents the actual alias of the Microsoft Dynamics AX user account that you want to make the Microsoft Dynamics AX administrator in the restored environment. The script returns the values for the following user information: Security identifier (SID) Network domain name Network alias Users can obtain the SID using other tools such as Active Directory users, and computers management console or PowerShell scripts. If you are logged into, a machine and you want to make your own the Dynamics AX admin you can open a command prompt and run:Whoami /user To get the SID in the current environment.2. Once you have all the values, you can run a script on the new instance of Microsoft Dynamics AX 2012 database that was restored. update userinfo set SID='', Networkdomain = '', networkalias = '' where id = 'admin'Replace the , , placeholders with the actual SID, network domain name, and network alias that the script returned in step 1For Microsoft Dynamics AX 2012 RTM there is normally only one record updated, but for Microsoft Dynamics AX 2012 R2, there may be, multiple records for the admin account each having a different partition column value.At this point, the AOS is started against the newly restored database; ensure the Microsoft Dynamics AX 2012 Configuration tool is set correctly to connect to that new AOS instance. Then start the Microsoft Dynamics AX 2012 client and login as the Microsoft Dynamics AX administrator account you just updated.Configure Base System functionalityOnce logged into the system, users can change other machine or domain information through the user interface. There are settings that affect the system as a whole such as AOS batch setup and service account stored to the database. Users will want to get the base system functionality working before moving on to working with other components that are dependent on the base systems. Changing theSystem Service AccountsChange the System service accounts held in the Microsoft Dynamics AX database with the correct domain accounts as needed. The Business Connector Proxy account is used for any .NET Business Connector integrations. For web applications, the Business Connector Proxy account will need to match the identity account of the IIS application pool. The Workflow execution account is used to process workflows on behalf of the user who submitted it and needs to be a valid domain account in the new environment. The Microsoft Project Server Synchronization account is used to process projects on behalf of the user who submitted it and needs to be a valid domain account in the new environment. The Bing map account is used to access online maps, which does not contain domain specific information, and most likely would not need to change.To setup System Service Accounts, click System Administration, click Setup, click System, and then click System Service Accounts. Once the account is entered, it will check against the domain controller to validate the account.Users may not require SSRS reporting, workflow, or Enterprise Portal in the new environment, if they are just testing X++ code. If a user corrects the system, service accounts either through the client or by creating SQL server update scripts.The following table lists the form name from the AOT and the SQL table names and columns.Form NameTable NameColumns in Table

System Service Accounts (sysBCAlias)SysBCProxyUserAccountSID, NetworkAlias, NetworkDomain

System Service Accounts (sysBCAlias)SysWorkflowParametersSiteURL, ExecutionUserID, workitememailid

Use the table above to help you develop SQL update scripts.

AOS Load Balancing and Batch ProcessingIn Microsoft Dynamics AX 2012, server side batch scheduling is processed by the AOS instead of the client. With this change in mind, there are several Microsoft Dynamics AX forms and tables that need to be updated when users restore a database to a new environment. If these changes are not made, server side batch jobs will not execute which can also affect workflow and upgrade testing.AOS load balancing has moved from the AOS configuration in Microsoft Dynamics AX 4.0 to the client. Click System Administration, click Setup, and then click System in Microsoft Dynamics AX 2012.

Open the Server Configuration and Cluster Configuration forms to review the settings. All the old AOS instance names are still referenced in the forms, and the new AOS instance is listed. When a new AOS is attached to the database, it will be recognized by the system but it will not be setup as part of load balancing or for batch processing. It is not necessary, but less confusing if the user deletes the old AOS instance name from these forms. Make sure to mark at least one valid AOS instance as batch server and setup and required load balancing if needed.Validate the batch setup, Click System Administration, click Inquiries, click Batch Jobs, and then click Batch Jobs. Once the form opens click View tasks. When the Batch tasks form opens, click the General tab and make any required changes to the batch groups if any new ones were setup. The batch table has the AOS account stored in the database, which needs to be updated in SQL or through table browser in the AOT.Refer to the table below for the objects affected and create SQL scripts as needed:Form NameTable NameColumns in Table

Server ConfigurationSysServerConfig, BatchServerConfigServerID

Cluster ConfigurationSysClusterConfigClusterName

Batch GroupsBatchServerGroupServerID

BatchServerID

The following SQL scripts are examples of how users can change the records to use the new AOS instance in the restored environment without making the changes through the client.update batch set SERVERID = '' where serverid = ''update sysserverconfig set enablebatch = 1 where serverid = ''update BATCHSERVERCONFIG set SERVERID = '' where serverid = ''

Make sure to change the and placeholders with the actual AOS instance name. Depending on user testing requirements, they may need to make other changes to the AOS cluster setup for specific load balancing scenarios. The steps related to batch jobs and workflow may be different. Refer to workflow section of this document to learn the importance of running the workflow wizard.After the changes are made, restart the AOS instances, in case they are caching any of the settings.

AOS ServicesAOS services are used by the client and the installer and should be verified and working in the new environment before users install other Microsoft Dynamics AX components such as Enterprise Portal. Open the Microsoft Dynamics AX 2012 client, click System Administration, click Setup, click Services and Application Integration Framework, and then click Inbound ports. Users should see several WCF services with a category of basic that are installed with the AOS. Make sure they all have a green checkbox next to them. If they do not, users can delete the service and then click Register basic ports to have them regenerated on this server. If you still get errors, try to activate the port and troubleshoot any errors written to the info log.Figure 1: Inbound portsResolve all the errors, close the client, and restart the AOS. If users have registered other services besides the basic ports, they will need to handle any domain or server machine name parameters.

Email ParametersEmail Parameters are used for email alerts and sending server side email using an SMTP server. This requires some server specific values that may change when users install Microsoft Dynamics AX in the new environment. Check with the user's network and IT department on security specific setup required to send SMTP email in the user's organization. There is no Microsoft Dynamics AX installation required, but it may be necessary to change these parameters for SMTP email to function after restoring the database in a new environment. To open SMTP email, click System Administration, click Setup, click System, and then click email parameters.The following table lists the form name, tables and columns involved in email setup related to environment specific settings.Form NameTable NameColumns in Table

SysEmailParametersSYSEMAILPARAMETERSAttachmentPath, SMTPRelayServerName, SMTPPortNumber, SMTPServerIPAddress, SMTPUserName, DNSServerName

SYSEMAILSMTPPASSWORDAOSID, Password, InstanceName

Depending if users need email functioning for all users, update the email address in the SYSUSERINFO table.

Document ManagementDocument management can store information to the database or to the file system. For those deployments that use the file system, this can be changed by navigating to System Administration| Setup | System Parameters once the form opens choose File store and browse to the correct path.The following table lists the form name, tables and columns involved in Document Handling setup.Form NameTable NameColumns in Table

SystemParametersSysFileStoreParametersFilePath

Install or configure additional components Microsoft Dynamics AX 2012 holds parameters related to Web Site URLs for Enterprise Portal, SSRS website, Workflow, and AIF web services. In addition, machine server names for the OLAP and SSRS servers are held in the database. Some testing environments may require these additional components be functional while others may not.Microsoft Dynamics AX system components are functioning based on steps prior to this section. Now, it is time to begin to think about the additional components that are needed in the user's test and development environment. Two different processes and scenarios need to be considered when users work with the additional components of the restored database in the new environment. The first scenario is where the additional components are not already installed in the new environment. In those cases as a general rule, users would install the component in the new environment against the restored database. Under most circumstances this will be all that is needed to get that component functioning. If there are exceptions to this rule or additional considerations, they will be outlined when discussing that particular component. The second scenario is when the component is already installed in the test or development environment and users want to refresh that environment with new data or code by restoring a new SQL backup. In those cases, the process would be different and would normally involve changing the values of the domain, server machines, and URLs stored in the database to the new values, either by changing them in the client forms or by using SQL update statements.Which method is used will depend on the user's specific needs and requirements of their testing and development. It may include a combination of the two scenarios, even if users have an existing deployment of some Microsoft Dynamics AX components. This manual will try to outline the most common methods. Keep in mind that the exact steps may vary depending on the user's specific needs.

Non-interactive Business Connector ConfigurationFor all connections using the business connector, the Client Configuration under the Configuration Target drop down list, controls the connection to the AOS and subsequently to the database. For the business connector configuration choose the target of Business Connector (non-interactive use only) check the Connection tab and verify the Server Name and Port you are using is correct in the new environment.For Microsoft Dynamics AX components that use web applications such as Enterprise Portal, the Help Server, and Web Services for IIS: the Business Connector Proxy account needs to be the same account that runs IIS application pool.In the new environment, if users are setting up the SSRS, SSAS and Enterprise Portal for the first time, doing the BI Components and Enterprise Portal and Role Center installation will set the correct values in the database. If users restore the Microsoft Dynamics AX database to an environment where they have already installed and deployed BI Components and Enterprise Portal, then they can change the server names and URL references in the database. They can do this by using the client forms or running SQL update statements. The following section discusses the database forms and tables involved with the different Microsoft Dynamics AX components.

WorkflowFor a new workflow deployment, the AOS installation will cover the workflow code that Microsoft Dynamics AX 2012 runs under the AOS process. Setting the System service accounts discussed about will set the Workflow Execution account, and the AOS server and batch setup already discussed handles the batch jobs that are used with workflow. The additional step that will need to be completed is to run the workflow infrastructure configuration. 1. Click System Administration, click Setup, click Workflow, and then click Workflow infrastructure configuration. To enable workflow in an existing environment with a restored database for a different environment, open the Batch Job form. Click System administration, click Inquiries, click Batch Jobs, and then click Batch Jobs.2. The workflow batch jobs could be actively running. First, change the status to withhold by highlighting the Workflow message processing job and from the top of the form click Functions, click Change status, and then click Withhold. Do the same steps for the Workflow due date expirations and Workflow line item notifications batch jobs. 3. Once all three workflow batch jobs are in a Withhold status, highlight the Workflow message processing job and from the top of the form, click Functions, and then click Delete, which will bring up a query window. Remove all columns except one, and choose a field of Job Description. 4. In the Criteria, type *Workflow*. Due to the fact that there are no other jobs with workflow in the job description, and click OK to delete the records. 5. Now that the workflow batch jobs are removed along with the records from the related tables, correct all the AOS and batch group settings discussed above and run the Workflow infrastructure configuration again. This will create the workflow batch jobs with the correct settings for this environment. 6. Since this problem is likely to happen again the next time users restore the production database to the test environment, create SQL update scripts to correct the problem in the database directly. 7. Open SQL manager and run select statements on the following tables:select * from BATCHJOB where CAPTION like 'workflow%'select * from BATCH where CAPTION like 'workflow%' 8. By looking at the columns in each table, users find that the SERVERID is available in the Batch table and would be the column to update in the environment when the database is restored. An example of the update statement would look like the following:

update BATCH set SERVERID = '' where SERVERID = ''

9. Make sure to change the placeholders for the actual AOS instance name and update both the batch and batchjob tables.

BI ComponentsOLAP databaseIf needed, restore the OLAP database, which should already contain reduced cubes to match the customer license keys and configuration. Dynamics Database for OLTP connection string, is held in the OLAP database by using SQL management tools and connect to Analysis Services. Under the Dynamics AX database choose the Data Sources folder and adjust the properties on the Dynamics Database data source. It is recommended to redeploy new ODC files after the above forms have been updated to the test or development Enterprise Portal. Redeploy SSRS reports to re-populate the SSRS web site reports. Redeploy any Enterprise Portal changes that exist in the AOT to the test EP website. List of Connection strings that reference server and database namesODC FilesDynamics AX (4.0 Perspectives)SharedLibrary.DynamicsAXOLAPDynamics Database (for OLTP)

SharePoint Document LibraryReports Web siteReports Web siteSQL Manager (Analysis Services)

Depending on the method, users should ensure all connections strings have correct server names and databases. The list above outlines the connections strings. In the SSRS reports manager site edit the SharedLibrary.DynamicsAXOLAP datasource.To change this setup in the client click System Administration, click Setup, click Business Intelligence, click Analysis Services, and then click Analysis Servers. To change this setup in the client click System Administration, click Setup, click Business Intelligence, click Reporting Services, and then click Reporting Servers.The following table lists the form name, tables and columns involved in OLAP and SSRS setup related to environment specific settings.Form NameTable NameColumns in Table

BIOlapAdministrationBIANALYSISSERVERSERVERNAME, DEFAULTDATABASENAME

BICONFIGURATIONPROJECTPATH, DATASOURCENAME, CONNECTIONSTRING, LOGFILEPATH, PROJECTFILENAME

SRSServersFormSRSSERVERSSERVERID, SERVERURL, AXAPTAREPORTFOLDER, REPORTMANAGERURL, SERVERINSTANCE, AOSID, CONFIGURATIONID

Help ServerThe Help Server may not be required in most testing and development environments, unless users are doing Help Server specific customizations or want to provide help in a separate training environment. For a new deployment of the Help Server, refer to the Installation Guide. Once the Help Server is installed, it will update the existing value in the restored database. If the Help Server is already deployed in the development or test environment, the Help Server URL can be changed through the client or in SQL server. 1. To change this setup in the client click System Administration, click Setup, click System, and then click Help system parameters.2. For the SQL server tables refer to the table below:Form NameTable NameColumns in Table

SysHelpSystemParametersSYSGLOBALCONFIGURATION Value

3. To retrieve the existing URL run the following SQL statement:select VALUE from SYSGLOBALCONFIGURATION where NAME = 'HelpServerLocation'4. To change the value, users would create a SQL update statement with the same where clause. After making the changes to the help sever URL a client and possibly AOS, restart is required depending on cache settings. See the Help topics are not displayed in the help viewer section of the installation Guide if you need to setup the search server to be indexed again in the new environment. 5. All clients deployed in the Development or test environment would need to access the Help Server URL.

Enterprise Portal and Role CentersFor a new installation of Enterprise Portal in a development or test environment with a restored database, have either SharePoint 2010 Server or SharePoint 2010 Foundation installed and in a working state with access to SharePoint Central Administration. Users will need to ensure the business connector proxy account is set correctly, in the database. These steps are described above in the System Service accounts. Since some SSRS and SSAS components are displayed in Enterprise Portal, users may want to get those working first with the restore database in the test or development environment.Refer to Installation Guide for the Enterprise Portal and role center installation. If users are using NLB, SSL, or a SharePoint Web Farm see the Installation Guide for the special instructions with those types of deployments. For an existing installation of Enterprise Portal in a development or test environment with a restored database have either SharePoint 2010 Server or SharePoint 2010 Foundation in a working state with access to SharePoint Central Administration. Method 1: Create a new SharePoint Web Application and install Enterprise Portal against that new web application. Even though the Enterprise Portal files are already on the server, the checkbox during the installation for Configure for Windows SharePoint Services needs to be marked to update the Web.config files with the Microsoft Dynamics AX references. If users want to limit the overhead on the test and development site, only enable the BDC and search services when the new web application is created in SharePoint.Method 2: Use an existing SharePoint Web Application and create a new SharePoint site collection manually. Method 3: Change the values in the database and use AXUpdatePortal to deploy any code changes stored in the database to an existing EP web site.1. To change Enterprise Portal parameters in the client click System Administration, click Setup, click Enterprise Portal, and then click Enterprise Portal parameters. Change the Search server URL, the default URL is: http:///_vti_bin/search.asmx, 2. The is the IIS server name. Users can also validate the URL by checking for the search.asmx page in IIS manager and browsing the file to ensure it is functioning.3. To change this web site URL in the client click System Administration, click Setup, click Enterprise Portal, and then click Web Sites.4. In the web sites form, delete the old or incorrect web site URL from the other environment. Click Register site and enter the Internal URL and the External URL of Enterprise Portal in the new environment. This will use a web service to get the SiteID GUID from the WSS databases and update the values in the Microsoft Dynamics AX database.5. If users get errors or want to use SQL update statements, use the following steps to update the URLs manually. Users can get the correct SiteID GUID from the WSS database to update the EPWEBSITEPARAMETERS and EPGLOBALPARAMETERS tables with by using the same Web Service call that Enterprise Portal calls. Before making any changes, ensure that the user has a working Enterprise Portal Web site in the new environment.6. To do get the SiteID GUID, open Internet Explorer from the IIS server and go to the website URL for the Enterprise Portal web site and use the following relative path: /_layouts/ep/WSSAdmin.asmx. 7. By default the full URL would be http://localhost/_layouts/ep/WSSAdmin.asmx. Users can also replace localhost in the URL with the machine name of the IIS server. Once the web page opens, users will click the GetEPWebInfo link.

Figure 2: WSSAdmin8. A new web page will open, enter the siteURL of the Enterprise Portal web site and click Invoke.9. This will return the GUID id of the Enterprise Portal web site to be used with method 3 above to create SQL update statements.10. The following table lists the form name, tables and columns involved in Enterprise Portal setup related to environment specific settings.Form NameTable NameColumns in Table

EPParametersEPGLOBALPARAMETERS HOMEPAGESITEID, DEVELOPMENTSITEID, SEARCHSERVERURL

EPUpdate

EPWebSiteParametersEPWEBSITEPARAMETERSINTERNALURL, SITEID, EXTERNALURL

CollabSiteParametersCOLLABSITEPARAMETERSROOTURL

Enterprise SearchEnterprise Search uses SharePoint 2010 and may not be required in most testing and development environments, unless users are doing Enterprise Search specific customizations. Enterprise Search integrates SharePoint 2010 Central Administration and the configuration of the Business Data Connectivity and Search Application services.The approach to take for deployment in a new environment is to have either SharePoint 2010 Server or SharePoint 2010 Foundation installed and the services configured in SharePoint Central Administration. Next, install Enterprise Search from the Microsoft Dynamics AX 2012 installation media. See the installation Guide for details. Once the Business Data Connectivity and Search Application services are installed and running in the new environment, click System Administration, click Setup, click Search, and then click Search Configuration in the Microsoft Dynamics AX client.The Search Configuration will connect to the service applications configured in SharePoint Central Administration. Users will select them from the dropdown list and mark the checkbox to crawl the content, create the index, tables and columns you define.In an existing deployment, where the Enterprise Search was working with a previous database users could take three different approaches. The first method is to bring over the new Microsoft Dynamics AX database along with SharePoint database and restore all of them in the new environment. This would require the user to follow the recommended methods of moving the SharePoint database and best practices outlined for that product. The second method would be to create a new Business Data Connectivity, Search Application services and databases and have the newly restored Microsoft Dynamics AX database content indexed. The third method and possibly the easiest would be to use the existing Business Data Connectivity and Search Application services and re build the indexes with the newly restored Dynamics AX database content.Project Server IntegrationTo change this setup in the client click System Administration, click Setup, click Microsoft Project Server synchronization, and then click Synchronization service parameters.Form NameTable NameColumns in Table

SyncParametersSYNCPARAMETERS

Web Service on IISWeb Services for IIS are only used if users need to expose services externally. If users require this component in their new environment, get all the base system functionality working in Microsoft Dynamics AX before installing this component and then follow the Installation Guide to install the Web Services on IIS.If the Web Services on IIS are already deployed to a server in the test or development environment, users will need to ensure the business connector proxy account is set correctly in the database and the existing IIS application pool matches the business connector proxy account. The Non interactive Business Connector Configuration must be set to connect to the correct AOS instance.To change Web Services on IIS click System Administration, click Setup, click Services and Application Integration Framework, and then click Web Sites.Form NameTable NameColumns in Table

AifWebsitesAIFWEBSITESVirtualDirectoryShare, URL

If there is more than one record in the form and the other reference is no longer valid in this environment, delete the record from the other environment to eliminate the confusion. If the AOS instance is on a separate server or does not have rights to the Web site where the user installed Web Services on IIS, they will need to grant the rights manually. For both new and existing installations of Web Services on IIS see the section in the Installation Guide After you install the web services on IIS for the steps to create an enhanced port. Users may be required to delete the existing inbound port and create a new one with the restored database.

Customized Business Connector integrationsFor external Business Connector integrations where users have developed any custom integrations to Microsoft Dynamics AX using the .NET Business Connector, update the business Connector proxy account in System Service accounts as described earlier. Review the logon or logon as methods used to make the connection to the AOS in the custom code for any domain account names or server specific information such as server names and port numbers. For IIS web application, check the account running the IIS application pool or WCF or Windows service accounts being used in the customizations. Review the web.config file or any configuration utilities, as users may have made changes to specific environmental variable settings.

AppendixUnique GUID per Microsoft Dynamics AX environmentIf users experience incorrect caching information or strange form behavior, they may be using the same Client Cache file when switching between database environments. In order to ensure that a unique AUC file is created per instance for the Microsoft Dynamics AX client to use, and to ensure that the Microsoft Dynamics AX instances have a unique Global GUID, update the GlobalGUID in the SysSQMSettings table with an empty GUID (00000000-0000-0000-0000-000000000000). After making this change, restart the AOS service and it will then generate a new GUID that allows a new AUC file to be created for the Microsoft Dynamics AX client to use.

PURPOSE:Deploy the enterprise portal and each individual component of SharePoint site.

USAGE: AxUpdatePortal -listvirtualservers AxUpdatePortal -redeploy [-updatewebsites] [-iisreset] AxUpdatePortal -deploy [-createsite] -websiteurl AxUpdatePortal -createsite -websiteurl AxUpdatePortal -updateall -websiteurl AxUpdatePortal -proxies -websiteurl AxUpdatePortal -images -websiteurl AxUpdatePortal -updatewebcomponent -treenodepath -websiteurl

AXUpdatePortal COMMAND PARAMETERS: Listvirtualservers: List of all virtual servers, SharePoint Web applications and IIS Web sites, on this computer. Redeploy: Recreate a virtual server, SharePoint web application, on this computer. Enterprise portal must already be installed on this machine by running setup.exe. Note that this first deletes the existing virtual server then deploys a new one. Deploy: Deploy a new virtual server, SharePoint web application, to an IIS web server, which already has Enterprise Portal installed on it. If the createsite parameter is omitted then only the virtual server is created and the user will need to later create the web site. Users can run this from any computer. Connects to IIS via a web service. Createsite: Create an Enterprise Portal web site within an existing Enterprise Portal virtual server. Users can run this from any computer. Connects to IIS via a web service. Updateall: Update all web components on an Enterprise Portal web site, SharePoint site collection. Users can run this from any computer. Connects to IIS via a web service. Proxies: Update all proxies on an Enterprise Portal web site, SharePoint site collection. Users can run this from any computer. Connects to IIS via a web service. Images: Update all images on an Enterprise Portal web site, SharePoint site collection. Users can run this from any computer. Connects to IIS via a web service. Updatewebcomponent: Update a web component on an Enterprise Portal web site, SharePoint site collection.

ADDITIONAL PARAMETERS: virtualserver Virtual server name, (SharePoint web application). Example: ServerName virtualserverurl Virtual server URL, (SharePoint Web application). Example: http://ServerName[:port]. websiteurl Web site url (SharePoint Site Collection). Example: http://SeverName[:port]/Sites/DynamicsAx. treenodepath Deploy web component tree node path. Example: /web/Web Files/Page Definitions/ActivityEdit UpdatewebsitesUpdate all enterprise portal web sites during the redeploy. You can run this from any computer. Connects to IIS via a web service. IisresetStop and restart the IIS web server after completing the deploy operation. Verbose

Log the exception and error message handling to the console. Applies only to this command: -redeploy

16 2011 Microsoft Corporation. All rights reserved.Global Technical ReadinessMicrosoft Confidential - For Internal Use Only17