Lifecycle Services (LCS) is a project management site specifically designed to simplify Dynamics AX implementations, including the deployment of DEMO, DEV/TEST and production environments. LCS is available free of charge to any customer with an active AX license. Any account registered in Customer Source will have access, though once a project is created, non-customer source accounts can be invited in.
The integration of LCS and Azure does require an active Azure subscription, which is where the environments will be stood up. In order to allow this to happen, a simple certificate upload needs to happen.
LCS can be found at https://lcs.dynamics.com. To start a project, click the + under recent projects, and fill out the Project blade. (NOTE: Make sure that you have at least a general idea of what you want because there is currently no way to delete a project.)
Opening the project will show a number of blades that can be used to track your progress. For now, we just want to scroll over to the Environments, which will be blank. Before creating a new environment, the Azure connection needs to be established by clicking on the Microsoft Azure settings link.
That link will pop up a connector window that will allow you to either add or modify Azure connections. If there is more than one connector, because there are multiple Azure subscriptions in use, you can set one as the default.
Name the connector, enter your subscription number, and then click next. This will allow you download a management certificate that will be uploaded in Azure to allow LCS deployment rights.
Once the certificate has been downloaded, open the Classic Azure Portal (https://manage.windowsazure.com). Currently LCS cannot connect to the ARM portal because the deployment is still dependent on Cloud services, which do not exist in ARM.
Go to Settings -> Management certificates, and click the upload link at the bottom of the page.
With the certificate uploaded, we return to LCS and add an environment by clicking the + under Environments. This will launch a new environment workflow that will collect all of the information required to create the environment. Note that if the intent is to create a production environment, the sizing estimator will need to be run first.
Before the wizard is run there are a few things to consider. AX requires Active Directory, so either a Contoso domain controller will need to be installed or the desired AD will have to be replicated into Azure. This can be either through an AD VM (IaaS) or by using Azure Active Directory. If Office 365 is being used then Azure AD may already be available. The second consideration is whether premium storage will be used or not. There is a significant performance difference between standard and premium storage, so premium should always be used for production, however a cost vs performance analysis should be done for dev/test.
The first step in creating an environment is selecting what it is for. A DEMO environment will be a single VM configured as a Contoso domain controller and pre-populated with the Contoso demo data. This is a great playground environment to see what AX does “out of the box”. DEV/TEST is just that and a High availability environment will be configured using SQL HA AlwaysOn.
Selecting DEVTEST will show a list of the default deployment settings.
The domain controller in this instance will be a Contoso one, so if you already have AD configured, change the instances to 0 for the Domain server. Once the instances are selected and deployment has begun, it is not possible to go back and add or remove instances through LCS. A new environment would need to be created, and even then it would create a new database. Once the deployment is done, any changes would need to be done at the VM level through the Azure portal.
Simply continuing with this setup will have Azure create all new resources for this environment, like a new virtual network, new storage group, etc. To join this environment to existing resources, click on the Advanced settings link. This will provide options for Active Directory, Storage type and existing Azure resource reuse.
The actual deployment can take a few hours, depending on the number of VMs in your environment. The deployment status will show up in the environment details.
Once the deployment is complete, the machine details, along with the connection link for RDS and the admin usernames and passwords will all be available in the environment detail window.
From here, users can actually start and stop the environment, so there is no need to provide them Azure portal access. Also note that the RDP link will only show up if the environment is running. A stopped environment will release its public IPs, so it may be necessary to download the links if they are configured to use IPs. Using DNS is the default and better way to go.
If the environment is no longer needed, the Deallocate link will mark all of the VMs associated with the project for deletion. This can also take some time and when it is done, the link will change to Delete. This is the only way to remove the environment from the list of environments.
With the new environment in place, a simple database replication will bring the environment in sync if needed. Azure does not simplify or speed up this step, and may even complicate it if PROD is on premise and DEV\TEST is in Azure. There are a number of things that can be put in place to mitigate this.
Azure site recovery or SQL AlwaysOn can be put in place, which would allow for real time replication of production into Azure making a database readily available for replication. This does incur some charges, but it also provides a viable BDR solution, so it does offer more benefit than simplifying environment replication.
There are also a number of companies that offer database virtualization. This is a completely different topic, however if there is a significant demand for rapid replication or the number of DEV/TEST environments is very fluid, DB virtualization can provide replication in minutes, if not seconds and there is a significant reduction in storage requirements.
Although Azure does not simplify every AX environment management process, having the ability to spin up new environments that will be available for use in a matter of hours is a huge step forward. AX configurations (report servers, etc.) and database management will still need to be updated using traditional methods, however there are ways those tasks can be automated as well. The cost savings of being able to shut down the environments when not is use can also be significant, especially if testing sprints don’t happen every week. Setting up the number of environments required ahead of time and then simply leaving them turned off until needed coupled with granting business users the ability to start and stop their environments through LCS can offload a significant amount of burden from IT resources.