As part of a recent engagement, one of companies I work with made the decision to move from CRM Online to a CRM 2016 deployment in Azure. That includes full development and production environment virtual machines in Azure, and to take it even a step further, we need all of it to be internet facing (IFD) and connected to multiple Adxstudio portals. Sounds complicated enough? I thought I would share the main steps we went through, the reference (articles, resources) we used and some of the challenges we faced as well as the resolutions.
This post will be broken into 2 parts. The first one, this one, focuses on how we set up the infrastructure. In part 2, I will describe the steps required to configure IFD for CRM in Azure. Time permitting, I write about how we tied in our Portals in the equation.
Overall infrastructure architecture
In order to make this simple, I’ll discuss only our development environment. From an infrastructure standpoint, it is very standard. We planned to have two domain controllers (DCs), always good as a best practice in case one of the two isn’t available. We also planned to have a separate ADFS server, one CRM Server with all roles, and one SQL Server.
That all sounds simple enough. However, since we are working in Azure, there are a few things that are done a little bit differently than when you work within an on-premise environment.
Setting up your Virtual Network, Virtual Machines and Domain
For starters, we need to create a Virtual Network that all of our machines will belong to. Once we have that in place, we need to create the required virtual machines, an active directory domain, and join all our machines to that domain. To achieve this, you can follow the steps in the following articles:
- How to install a new Active Directory forest on an Azure virtual network (the article)
- A step by step video of the process here.
These resources are key to get you started. A few key important steps here are worth mentioning.
First, in the process of setting up your DC, you will need to make sure you update the DNS server of your Azure Virtual Network to the domain controller. In doing so, you will lose internet access from your VMs because there is no public DNS server available. That can become a problem very quickly. To solve the issue, you need to add a couple of additional DNS servers to your Virtual Network configuration. These DNS Servers are are Microsoft’s public DNS servers: 184.108.40.206 and 220.127.116.11:
Second, after the machines have all been created, we noticed there was no name resolution even through all the VMs were part of the same Virtual Network. We were able to ping using the IP address but not the machine names (short or FQDN, no difference). So we ended up taking a couple of steps to solve that problem.
- We made our CRM Application Server and SQL Server IP addresses static. There are two ways to do this. If you are familiar with PowerShell, start by installing Azure PowerShell, then in a PowerShell console, connect to your Azure subscription by following the instructions in the installation link, and use the Set-AzureStaticVNetIP command to assign a static IP address to your virtual machine. The other way of achieving this is to use the new Azure Portal. If you navigate to your VM’s IP addresses settings, you can set the Private IP address to be Dynamic or Static as shown below. Select the Static option (see screenshot below)
- We manually added DNS entries for both our SQL and CRM VMs in our DNS Server. If you are not familiar with doing this, check out this well written article.
Third, we initially had only one Domain controller for various reasons. We realized there was often long delays for AD related actions to be available throughout the network (e.g. add a user to an AD group). We created another server, joined it to our domain, added the AD DS role and made it another DC in our domain. Our issues seem to go away after we added an second DC.
That’s it for now. Feel free to post questions if you have any!