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