With several implementations underway, I’ve been on the lookout to provide the best experience for our development team and also curb costs. The new Dynamics AX (we can still call it new right?) has excellent tooling for developers in Visual Studio as most are aware, and there are a few options to deploy development environments:
1- LCS can deploy developer topology on Azure. This requires an Azure subscription, and will provision the classicCompute ( legacy, v1 ) Virtual Machine. This is an all-in-one configuration, or OneBox, that contains SQL Server 2016, IIS, Visual Studio, and the AOS is configured to use the local system for blob storage emulation. The user who deploys the environment is automatically provisioned as the default System Administrator. LCS will configure the AOS with the public URL that was created and updates the application to use your Azure Active Directory tenant for identity and authentication.
2- You can download a VHD from Microsoft which has the same OneBox configuration to your local machine. The VHD is not exactly identical to the cloud version it has no idea who is about to use it. Therefore the AAD tenant is set initially to Contoso, and the system is “hard coded” with a dummy URL via DNS and IIS bindings which only work inside the VM itself ( can’t get to it on the public internet ).
I have preferred the LCS deployments thus far, simply because they are fast and get you a public website which is great for customer demos, modeling, and the like. However, it does run up a bill. To that end we have created flexible Azure Automation powershell scripts which power up and down the VMs on varying schedules per resource group so that the Developer environments are online for a limited amount of time per day. This does get things out of sync though with LCS, as it shows the environments are still running when in fact they are offline.
Because I don’t have a super robust laptop, and frankly I’ve become accustomed to the 56GB of RAM provided by the D13 VM :) I want to demonstrate just how easy it is to get the VHD uploaded back to Azure to manage the developer environments yourself!
DevTest labs are still in preview, and they have a fantastic price of FREE. Well, the lab itself is free, but of course any VMs that you spin up will start to cost. Let’s get started:
Create a new DevTest Lab, I’ll call mine Implementation1:
I highly recommend the premium storage. It really makes a difference in the speed of the machine, but does add extra cost. However, I have found the additional cost is marginal compared to the boost in performance. This is a setting for the entire lab at this point, so all VMs you deploy will use either Standard or Premium.
Next let’s add a Custom Image to the lab. This is where we configure the name of the image for the AX RTW VHD that we have downloaded previously from LCS. The lab conveniently gives you the powershell needed to upload the VHD directly to the lab.
Next lets set the allowed VM sizes for the lab as well as the maximum number of VMs per user:
Optionally you can set the auto shutdown and startup times for your lab.
The hard part is over! Now we just need to deploy the VM. Select your base image that you uploaded earlier:
Then set the rest of the options as you wish. Keep in mind that you cannot use administrator as a username in Azure for security reasons, but this will pose problematic with the VHD as it comes with an account pre-established.
The VM will take some time to spin up, perhaps 15 minutes. Time for a coffee break. When you get back, you’ll likely see the VM deployment has failed:
This is likely due to the account issue above, or a failure in part of the SysPrep done by the team who created the VHD. In any case, the VM is operational! Click on it to get to the Virtual Machine tab where you can download the RDP file:
And we are in!
The big advantage to using Azure is that we have on-demand resources at our disposal. No more waiting for infrastructure, it can be provisioned and directly managed by your team. Also being in the cloud we can access this environment from anywhere…right? Well unfortunately we did use the VHD which is associated to a *.cloud.dynamics.com address which we don’t control. Let’s get that fixed.
First, go to your Azure Active Directory in the classic portal and add a new web application:
For the URLs, set both to the same address that is used in your RDP file, prepending https:// :
On the Configuration tab of your app in Azure, add permissions to any other cloud applications AX will need to interface with, such as PowerBI. Be sure to include Microsoft Dynamics AX permissions as well as “Sign in and read user profile” from the Windows Azure Active Directory delegated permissions:
I found that I could log in to the environment just fine but that other users in our organization could not because they were not admins on the Azure subscription. To resolve, I made sure that none of the permissions in the above screenshot had Application permissions and that the delegated permissions were those that don’t require tenant admin approval. That resolved the issue and all users could then login to the environment.
Finally, we just need to update the configuration files for the AOS to match these settings. Add the URL you used as the signin address for the app in IIS:
I used the above SSL certificate and it seems to work, of course it is a self-signed cert so the browser will give a warning. If you want to buy an SSL certificate for this you sure can!
Next, locate your AOS website application directory and there are three config files we need to update:
In the web.config, locate the Aad.Realm property and update the spn ( which is short for Service Principal ) from the default Microsoft value to your clientID from Azure Active Directory. Also replace all instances of usnconeboxax1aos.cloud.onebox.dynamics.com with your new URL. Keep the slashes when they are present! You may also need to replace instances of IP settings, 127.0.0.1 obviously only works on the virtual machine but not on the network.
In the wif.config file, replace the spn as above. In wif.services, replace the spn as well as set the replyURL to match exactly the replyURL you set in the application in Azure Active Directory.
And with that, you now have a public-facing DevTest Lab AX RTW instance that you can fully manage internally. Enjoy!