Full CRM Deployment in Azure – Part II – Expose CRM to the Internet

In my previous post, I shared some of the chanllenges we faced as part of the deployment of a full CRM Infrastructure in Azure. In this post, I will focus on how we exposed the CRM application on the internet to meet our business requirements.

Context

Before I talk about the options and our decision making process, it is important to talk about some of the key requirements that we have for our application.

  • Dynamics CRM is the heart of the platform, containing client, membership info as well as open requests (you can think of these as cases)
  • Customer information is used/displayed through multiple portals (Adxstudio and custom portals)
  • Customer information is also used/displayed in custom mobile applications (not the Dynamics CRM apps), available in the Apple Store and in Google’s Play Store.
  • Internal support agents need to have access to CRM from anywhere in the world at all times (they have accounts in CRM)

One of the design decision that was made is to have a web service that the mobile applications can communicate with. That way, all our mobile applications use the same Data Access Layer to get to and manipulate Dynamics CRM data. The following diagram shows a simplified version of our architecture.

image

WIth that in mind, our portals and mobile applications have to be able to communicate with Dynamics CRM. To make that happen, we considered two options.

Internet Facing Deployment

That was our initial idea. We wanted to go with the classic IFD deployment for our Azure hosted Dynamics CRM installation. That would include the usual Claim-based authentication, ADFS configuration and a bit of advaned network configuration in the cloud service. In Azure, such a deployment isn’t very different from what we do for on premise-type installations. The main difference resides in how and where some of the configuration is done (certificates registration, DNS configuration done through Azure config using new portal or PowerShell commands).

Internet Facing Web-Sites hosted in Azure VMs 

The other option here, is to simply use the Azure VM End Points and Load Balanced Sets features to expose the CRM application on the web (internal or public). The big picture consists of having the CRM front-end role installed on multiple servers in our cloud service, create a load balanced set that exposes the CRM Web sites through an accessible URL (can be public or internal depending on your setup and requirements). The challenges here are authentication and possibly security (and they are not discussed in detail here, but happy to elaborate questsions are posted!).

image

What we did, how we did it and what we learnt

Now we are getting to the cool part. We decided to go with the second option, mainly because of expertise, ease of support and ease of deployment. It is much easier to find people who have basic knowledge of endpoints, load-balanced web site, than people who know CRM and IFD.

Untimately in our context, we needed to have a CRM that is accesible for our CRM users from anywhere in the world to our users. It also needed to be accesible from our Portals and custom web services all hosted in Azure.

Important to keep in mind that if you want to use the Dynamics CRM Mobile applications, ADFS is the required authentication mecanism so that factor into your decision making process.

Here are the main steps to getting to our goal.

  1. VMs are created, the Dynamics CRM Front-End Role is installed our two servers
  2. Validate CRM is accessible from both VMs independently using their local URLs (e.g. http://crmapp1/orgname and http://crmapp2/orgname 
  3. If all of that works, then it’s time to configure your VM end points and load balanced set

image

Looking at the Load Balanced Set above, we have created a web application available at “DNS Name” + Public Port. When the website at that URL is requested, it will be redirected to one of the CRM Virtual Machines on the port 80 which is the configuration you see with the VMs that are members of this Load Balanced Set.

image

When you reach your CRM, you will be prompted by the browser for user credentials (AD). There are multiple ways to enable single sign on but not discussed here. 

One resource that has been key for us in the process of making this happen is the Cloud Ranger blog and videos!

It’s been a fun experience. We love Azure more and more! To get more information and details on how you can build a full CRM infrastructure in Azure, or any information about your CRM needs and implementations, reach out to us!

Advertisements

Full CRM Deployment in Azure – Part 1 – Infrastructure

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.

image

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:

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: 169.62.167.9 and 168.63.129.16:

image

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)

image

  • 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!

CRM 2013 Deployment Certification Tips

I just passed Microsoft Dynamics CRM 2013 Deployment certification exam today with fairly little preparation (i.e. no course, no question studies, and no book). In my defense, I had a second shot voucher so I was thinking I could go back in a week if I didn’t pass it :).

I thought I would share the “study material” that I used to prepare for it.

YouTube Videos

Other Resource

That’s all I used, plus obviously a few years of experience with the product.

Recommendation

Spend some time on

  • CRM Outlook Client material (upgrade path from 2011, Online/Offline mode, having multiple organizations on the same outlook client etc.)
  • Email functionalities (router installation, configuration, server side synchronization, smart matching/tracking token).

Good luck!