Microsoft Dynamics CRM 2016 On-Premise Deployment on Azure VM – Part 2 – Internet-Facing Deployment Configuration

Objectives

This article in 2 parts, explains step by step how to set up a Microsoft Dynamics CRM 2016 development server on an Azure Virtual Machine and to open it to the Internet via the CRM Internet-Facing Deployment.

These steps are not intended to be followed for a Production server as they rely on a single Virtual Machine for all the infra-structure including:

  • Windows Server 2012 R2 Operating System
  • Active Directory Domain Services role,
  • Web Server (IIS) Role
  • Active Directory Federation Service (ADFS) V3.0 role,
  • SQL Server Enterprise 2014 SP1,
  • and of course Dynamics CRM 2016 with all roles on the same server.

This is clearly not a configuration recommended and supported by Microsoft but it’s very didactic as it touches to a good range of Microsoft server technologies and concepts.

This deployment adds a bit of complexity regarding some required work-arounds to make it run properly, but also remove some complexity in overall (less servers to deploy and configure, lower administration). Some straight lines and assumptions are taken, for example regarding the Windows accounts that again is not suitable for a Production environment.

Part1 covers the core infrastructure installation with MS Dynamics CRM 2016 configured for a simple AD Authentication, restricted to internal users. The schema below highlights the process:

You can complete Part 1 of this article and stop there with a fully functional Dynamics CRM 2016 server accessible only from the internal network.

Part 2 covers the Internet-Facing Deployment configuration of Dynamics CRM 2016 to have it support Claim-Based authentication for internal and external access thanks to the MS Active Directory Federation Service. The schema below highlights the process:

Requirements

For this deployment you need:

  • A SSL wildcard certificate provided by a well know Certificate Authority,
  • Admin access to a domain provided by an Internet Domain Name Registration Provider or by your company (access to the DNS),
  • Full Administration access on the infrastructure of your servers,
  • If you are building a development environment hosted on Azure, then the Part 1 of this article is assumed to be covered.

SSL Certificate Application

Our development instance of Dynamics CRM will be accessed via the URL https://crm2016.mydomain.com:444 (In this article mydomain.com is a fake domain to be replaced by your domain of choice).

We need to purchase a standard SSL wildcard certificate to be applied to our IIS Server. If you intend to stop this deployment to Dynamics CRM only, then you could eventually consider to use a free self-signed certificate for testing/dev purpose, but be aware that some integrations with other systems, following this article, may not work.

As a SSL Certificate Provider, we’ll use the services of https://www.namecheap.com that is one of the cheaper provider of the market with pretty good tracking records.

On your Windows Server, open IIS Manager:

  • Click the Server Name of the left panel
  • On the central panel, double click the ‘Server Certificates’ icon
  • On the right panel, click ‘Create Certificate Request’

Fill-up the ‘Distinguished Name Properties’ pop-up fields with alphanumeric symbols (no special ones such as ‘&’, ‘/’,’@’, etc. allowed):

  • Common Name – The name through which the certificate will be accessed (example *.mydomain.com for a wildcard certificate)
  • Organization – The legally registered name of your organization/company
  • Organizational unit – The name of your department within the organization
  • City/locality – The city in which your organization is located
  • State/province – The state in which your organization is located
  • Country/region – two-digit country code

The next screen ‘Cryptographic Service Provider Properties’ offers to choose 2 parameters. Check with your Certificate Provider in order to be sure what values to fill there. The most common values today are:

  • Provider = ‘Microsoft RSA SChannel Cryptographic Provider’
  • Bit length = 2048

Next select a place where to store the Certificate Request text file, any place and any file will work.

Now on the SSL Certificate Provider web site, activate your newly purchased certificate and paste the content from the previously generated file to the Certificate Signing Request (CSR) field. Select IIS as a web server if this choice is available.

Your SSL Certificate provider will require to go through a Domain Control Validation (DCV) process for security purpose.

We opted for the Email method to complete the DCV (Other possible alternative: HTTP-based validation or DNS-based validation). The validation can take a few hours to a couple of days.

Once the SSL Certificate delivered, download it and select the Action “Complete Certificate Request” in IIS Manager and upload your certificate.

Our SSL Certificate Provider delivered the certificate under different formats, we selected the one with the extension p7b (.cer, .p7s, .p7b should be equally accepted by IIS).

Web Sites Binding with SSL Certificate

Default Site

On your Windows Server, open IIS Manager:

  • Click the Server Name of the left panel
  • Expand the Sites and select the Default Web Site
  • On the right Action panel, click “Bindings”
  • Click the button “Add” in the Site Bindings” pop-up

  • Select Type = ‘https’
  • Leave IP address to ‘All Unassigned’
  • Set Port = 443
  • Select your wildcard SSL Certificate by its friendly name
  • Click OK

Dynamics CRM Site

in IIS Manager:

  • Click the Server Name of the left panel
  • Expand the Sites and select the Microsoft Dynamics CRM Web Site
  • On the right Action panel, click “Bindings”
  • Click the button “Add” in the Site Bindings” pop-up

  • Select Type = ‘https’
  • Leave IP address to ‘All Unassigned’
  • Set Port = 444 (must be different from the port used for the default web site)
  • Select your wildcard SSL Certificate by its friendly name
  • Click OK

DNS Configuration

Our DNS requirements are the following:

  • To set up Claims-based authentication for our Dynamics CRM server:
    • internalcrm.mydomain.com – URL accessed by internal network users à Internal access
    • sts.mydomain.com – URL pointing to the security token service (ADFS) à Internal and external access
  • To set up IFD:
    • crm2016.mydomain.com – URL accessed by external network users à External access

      Important: this name has to match the name of your Dynamics CRM Organization

    • dev.mydomain.com – Discovery service URL à External access
    • auth.mydomain.com – external IFD URL à External access

We need the services of an Internet Domain Name Registration Provider to create an external domain. Typically, providers such as Namecheap (http://www.namecheap.com) or GoDaddy (http://godaddy.com) can provide this for a reasonable cost.

For External accesses, we create the following A Records pointing to our public IP (See Part 1 of this article to find out how did we get this IP from Azure) From the user interface of the Domain Provider.

For internal accesses, we can set up A Records via our local DNS Manager…

… or add the following entries within the host.file. This file is located on your loca server: C:\Windows\System32\drivers\etc. This is acceptable for a development server.

(replace holes by your domain and 10.0.0.4 by your private IP adress)

Test all the DNS names, from your server and from the internet.

Notes:

  • You may not be able to ping those names because Azure may block those request
  • In case of local name resolution problems, you can try to clean up the DNS cache

Open your Server to the Internet

The following steps are specific to the Dynamics CRM server deployed on an Azure VM (Part 1 of this article). If your server is hosted by a different Cloud platform provider, then you’ll need to refer to their documentation. In any cases, the second step about configuring the Firewall stay valid.

Inbound Security Rules on Azure

Create Inbound Security Rules on your Network Security Group to allow inbound access from the outside world.

On the Azure Portal:

  • Select your Virtual Machine
  • Select your current Network Interface associated with your Static IP
  • Select the Network Security Group
  • Click on the “Inbound Security Rules”
  • Create the following rules depending on your need
    • Open Port 80 (only if access to default web site on HTTP is required)
      • Source:any / protocol:TCP / Source port range:* / Destination:any / Destination port range: 80 / Action: Allow
    • Open Port 443 (required for our Dynamics CRM IFD set up where port 443 is bound to the default web site for ADFS)
      • Source:any / protocol:TCP / Source port range:* / Destination:any / Destination port range: 443 / Action: Allow
    • Open Port 444 (required for our Dynamics CRM IFD set up where port 444 is bound to the Dynamics CRM web site)
      • Source:any / protocol:TCP / Source port range:* / Destination:any / Destination port range: 444 / Action: Allow

Firewall configuration

On the Windows Server, launch the “Windows Firewall with Advanced Security” Tool from the Server Manager and create the following Inbound Rules reflecting the rules you have defined via your Azure Network – Security Group:

  • Open port 443 on TCP
  • Open port 444 on TCP
  • Optionally if you want to leave access to your default web site in HTTP, open port 80 on TCP

The firewall could eventually cause problems for the remaining steps of this deployment if not configured properly, we recommend to temporarily turn it off until you can verify the IFD is working properly with Dynamics CRM and then turn it back on again later.

Declare your Domain’s Web sites in Internet Explorer

Include all your web sites in the local intranet zone in order to avoid some security blockages with Internet Explorer later.

Within IE, click on the “Tools” Icon and select “Internet Options”.

Pick the tab “Security”, select “Local Intranet” and click the “Sites” button, and then click the “Advanced” button on the pop-up.

Finally, add all the web sites of your domain, e.g. add the entry “*.mydomain.com”.

Claim-Based Authentication Configuration for Internal Access

Active Directory Federation Services Installation and Configuration

We need to install ADFS 3.0 that will act as the Security Token Service (STS) for our Claim-based authentication. It will be using our default IIS web site.

On your Server, open the Server Manager:

  • Click “Add Roles and Features”
  • In the wizard, select “Server Roles”
  • Check the role “Active Directory Federation Services”

  • In the wizard, select “ADFS” and read the content
  • In the wizard, select “Confirmation” and tick the box “Restart the destination server automatically if required”
  • Click “Install”

Once the installation is complete, click “Configure the federation service on this server”.

On the Configuration wizard, leave the choice “Create the first federation server farm” and click “Next”.

Next screen, select an account with AD domain admin permissions, your account should be fine in the context of this development installation.

On the “Specify Service Properties” screen:

  • Select the SSL certificate we created at the beginning of this article (do not click Import)
  • Set the Federation Service Name (e.g. sts.mydomain.com)
  • Choose a relevant FS Display Name as the users will see it at sign in (something like “MS Dynamics CRM”

If you click Next, you’ll see the following error:

Open Windows PowerShell and execute the following command:

  • Add-KdsRootKey -EffectiveTime(Get-Date).AddHours(-10)

Now you can click “Previous” and then click “Next” on the wizard if you see a Guid provided as an answer.

You can go for the creation of a Group Managed Service Account since you are on a development environment. It would be recommended to use a defined account in Production.

On the next screen we create a database on the server using Windows Internal Database, but you can choose to leverage the existing SQL Server on your Windows Server.

Click “Next” and review your selections and then go to the Pre-requisite Checks.

You can safely ignore the 1st warning, as long as All prerequisite checks passed successfully. Click “Configure”.

Finally, if everything goes well, you should obtain the success confirmation screen.

Let’s check the URL of the ADFS metadata in Internet Explorer to verify the ADFS is working properly; you’ll need this URL later.

It should look like the URL below:

https://sts.mydomain.com/federationmetadata/2007-06/federationmetadata.xml

  • Replace “sts” eventually by another DNS name of your choice dedicated to ADFS (done in step “DNS Configuration”)
  • Replace “mydomain.com” by your own domain
  • If Internet Explorer doesn’t display the XML file, make sure you have done the steps described in section “Declare your Domain’s Web sites in Internet Explorer”
  • Another important thing to check is that no error appears on the browser regarding your SSL certificate (click on the locker icon close to the URL for more info about it)

Configure MS Dynamics CRM Server for Claims-Based Authentication

Open the CRM Deployment Manager and follow these steps:

  • Select “Properties” in the Action menu
  • Go to the “Web Address” tab

  • Change Binding Type from HTTP to HTTPS
  • Replace all occurrence of the server name by the URL accessed by internal network users internalcrm.mydomain.com (see step “DNS Configuration”)
  • Change all occurrences of the port 5555 to 444

  • Click the “Apply” button and close the pop-up
  • Back to the Microsoft Dynamics CRM Deployment Manager, right click on the top of the tree “Microsoft Dynamics CRM” and select in the menu “Configure Claims-Based Authentication”

  • Click Next on the welcome page of the wizard
  • On the “Specify the security token service”, enter the Federation metadata URL we tested in the previous steps, setting up ADFS

  • Click “Next” and pick your SSL Certificate declared previously with a friendly name

  • Click “Next” and review the System Checks, you should have 2 successes à this stage

  • Click “Next” and then click “Apply”
  • On the last screen, click “View the log file”

  • Click “Finish” on the wizard
  • Test that the Internal Federation Metadata URL is working (You may have to do the next step prior to test successfully this URL)

Next we need to grant to the account NETWORK SERVICE the access to the encryption certificate because it’s the account that has been associated by default to the CRMAppPool in IIS. You can double check it on the Application Pools in IIS.

  • From the Windows Start button, right click and select “Run”
  • Type the command “mmc” to launch the Microsoft Management Console

  • Select “Add/Remove Snap-in” from the “File” menu

  • Select the “Certificates” snap-in and click “Add”

  • Select “Computer Account” and click “Next”
  • Make sure “Local computer” is selected and click “Finish” and “OK”

  • Select “Console Root” à “Certificates” à “Personal” à “Certificates”
  • Right click on your SSL Certificate we declared for the CRM and select “All Tasks” à “Manage Private Keys”

  • Click the “Add” button
  • Click the “Advanced” button
  • Type a search string like “network service” and click “Find Now” button
  • Pick the account “NETWORK SERVICE” and click “OK”

  • Ensure the NETWORK SERVICE has got Read access

  • Apply and close MMC.

Create and configure Claims Provider Trusts and Relying Party Trusts in ADFS

Start AD FS Management from the Server Management’s Tools and follow these steps:

  • Select “ADFS” à “Trust Relationships” à “Claims Provider Trusts” on the side panel
  • Right click on “Active Directory” and select “Edit Claim Rules…” on the menu

  • In the Claim Rules editor click the button “Add Rule”

  • Select “Send LDAP Attributes as Claims” for the Claim rule template and click “Next”

  • In the Claim Rule configuration screen, create the following rule:
    • Claim rule name: UPN Claim Rule
    • Attribute store: Active Directory
    • LDAP Attribute: User Principal Name
    • Outgoing Claim Type: UPN

  • Click “Finish” and “OK” to leave the Claim Rules editor

Now it is time to configure the CRM as a relying party to consume claims from ADFS.

Stay in the ADFS Management and follow these steps:

  • Select “ADFS” à “Trust Relationships” à “Relying Party Trusts” on the side panel
  • Click “Add Relying Party Trust” in the right Actions panel

  • Click “Next” and specify a display name in the following screen like “CRM Claims Relying Party”

  • Click “Next” and do not configure the “Configure Multi-factor Authentication”, so click “Next” again
  • On the step “Choose Issuance Authorization Rules”, leave the option “Permit all users to access this relying party” checked

  • Click “Next” and leave the step “Ready to Add Trust” as it is by clicking again “Next”

  • On the “Finish” step, make sure to check the tick box “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” and push the “Close” button

  • On the Claim Rule Editor, click the button “Add Rule”
  • Select the Claim rule template “Pass Through or Filter an Incoming Claim” and click “Next”

  • Create the Rule n°1:
    • Claim rule name: Pass Through UPN
    • Incoming claim type: UPN
    • Check “Pass through all claim values”
  • Click “Finish”

  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Pass Through or Filter an Incoming Claim” and click “Next”
  • Create the Rule n°2:
    • Claim rule name: Pass Through Primary SID
    • Incoming claim type: Primary SID
    • Check “Pass through all claim values”
  • Click “Finish”
  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Transform an Incoming Claim” and click “Next”
  • Create the Rule n°3:
    • Claim rule name: Transform Windows Account Name to Name
    • Incoming claim type: Windows account name
    • Outgoing claim type: Name
    • Check “Pass through all claim values”

  • Click “Finish”
  • Back to the Claim Rules editor, check you have your 3 rules and click “Apply” and “OK”

We need now to enable Forms authentication for internal access which is off by default.

Stay in the ADFS Management and follow these steps:

  • Select “ADFS” à “Authentication Policies” on the side panel
  • Click “Edit” on section “Primary Authentication” – “Global Settings” – “Authentication Methods”

Check the box “Forms Authentication” in the Intranet section.

Apply and close the ADFS Management console.

Open Internet Explorer and open the Internet Options.

Open the tab “Advanced” and make sure the option “Enable Integrated Windows Authentication” is checked.

This should be done for every PC accessing the internal access points so that ADFS and CRM can pass the Kerberos tickets without being prompted for credentials.

Finally, we need to register the ADFS Service Principal Names (SPN) on the user running the ADFS Service:

  • Open PowerShell or CMD
  • Enter the following command:
  • setspn -a HTTP/sts.mydomain.com mydomain\Administrator
  • setspn -a HOST/sts.mydomain.com mydomain\Administrator

(adjust those parameters with your domain and the user you choose to run the ADFS Service)


  • Reset IIS with the command
  • iisreset

Before to move to the IFD configuration, you can test the internal access to Dynamics CRM by typing the URL https://internalcrm.myserver.com:444.

If it doesn’t work at this stage, you need to troubleshoot it before to move on to the next stage. The SPN config. is critical, make sure it’s done correctly.


Internet-Facing Deployment Configuration for External Access

Configure MS Dynamics CRM Server for Internet-Facing Deployment

Open the Dynamics CRM Deployment Manager:

  • Right Click on “Microsoft Dynamics CRM” and pick “Configure Internet-Facing Deployment” in the contextual menu

  • Click “Next” on the 1st screen
  • On the next screen, enter the URLs with the port 444 for
    • the Web Application server domain (it’s a domain, not a server)
    • the Organization Web Service domain (identical to web application since we are installing all CRM roles on the same server)
    • The Discovery Web Service Domain (here we need a resolvable host name, we defined “dev.mydomain.com” for the Discovery Service in the DNS setup phase)

  • Click “Next”
  • Leave the default for the Internet Facing Server location (“auth.mydomain.com” has been also defined in the DNS setup phase)

The system checks should come with 2 successes.

  • Click the “Apply” button on the summary screen and you reach the Finish screen

Create and configure Relying Party Trusts in ADFS for the IFD Endpoint

Start AD FS Management from the Server Management’s Tools and follow these steps:

  • Right click on “ADFS”
  • Select “Add Relying Party Trust…” on the contextual menu

  • This open the “Add Relying Party Trust Wizard”, click “Start”
  • On the “Select Data Source” page, click the choice “Import data about the relying party published online or on a local network”
  • Type the Federation Metadata URL to locate the federationmetadata.xml file for IFD (should start with the prefix URL you specified in the IFD setup, https and port 444 and then the suffix is the same as for the Internal Federation Metadata URL: https://auth.mydomain.com:444/federationmetadata/2007-06/federationmetadata.xml

  • Click “Next” and on the “Specify Display Name” page, set the Display name as “CRM IFD Relying Party” for example

  • Pass the “Configure Multi-factor Authentication” with a “I do not want to configure …”
  • On the “Choose Issuance Authorization Rules” page, keep “Permit all users to access this relying party” and click “Next”
  • Confirm the page “Ready to Add Trust” by clicking “Next”

  • On the Finish page, leave the tick box “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” and close the wizard
  • If you missed the previous step, you can right click on the relying party that you created, and click “Edit Claim Rules”
  • On the Claim Rules editor popup, click “Add Rule” and select the rule template “Pass Through or Filter an Incoming Claim”

  • Create the Rule n°1:
    • Claim rule name: Pass Through UPN
    • Incoming claim type: UPN
    • Check “Pass through all claim values”
  • Click “Finish”

  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Pass Through or Filter an Incoming Claim” and click “Next”
  • Create the Rule n°2:
    • Claim rule name: Pass Through Primary SID
    • Incoming claim type: Primary SID
    • Check “Pass through all claim values”
  • Click “Finish”
  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Transform an Incoming Claim” and click “Next”
  • Create the Rule n°3:
    • Claim rule name: Transform Windows Account Name to Name
    • Incoming claim type: Windows account name
    • Outgoing claim type: Name
    • Check “Pass through all claim values”

  • Click “Finish”
  • Back to the Claim Rules editor, check you have your 3 rules and click “Apply” and “OK”

  • You should have 3 Relying Party Trusts in the ADFS Trust Relationships

Change the Port of ADFS with the command line and restart the ADFS Service (adfssrv):

  • Set-adfsProperties -nettcpport 809

Restart IIS with the command line:

  • iisreset

For information, you can browse the following URL and get the ADFS Web Service WSDL:

https://sts.mydomain.com/adfs/services/trust/mex (replace with your adfs name and your domain).

Internet-Facing Deployment Test

Access to Dynamics CRM 2016 from the internet (not from the server you did the install) and use the following URL:

https://{crmOrg}.{mydomain.com}:444

e.g.: https://crm2016.mydomain.com:444

that should lead your browser to this authentication screen:

Login with the following format: domain\username

Congratulation !!! you made it through the IFD for Dynamics CRM 2016.

In case of issue, there are ways to help you troubleshoot it. Your favourite search engine is your best friend. Check out also the links below that helped a lot to complete this installation.

Mobile App (Optional)

Once you got MS Dynamics CRM working with the IFD, you can access it from the Dynamics CRM mobile app.

You can download this app on multiple phones and tablets OS:

CRM for phones app



CRM for tablets app



Once the mobile app started, just enter your external CRM URL, e.g. https://crm2016.mydomain.com:444.

And that’s it, after a short time loading some modules, you should be able to use your CRM from your phone or tablet.

Useful Links

Here is a list of great links that really guided me very well through this installation:

Here are some official documentation links:

Finally, some useful links that helped me for troubleshooting some issues during the installation:

Microsoft Dynamics CRM 2016 On-Premise Deployment on Azure VM – Part 1 – Core Infrastructure and CRM Installation

Objectives

This article in 2 parts, explains step by step how to set up a Microsoft Dynamics CRM 2016 development server on an Azure Virtual Machine and to open it to the Internet via the CRM Internet-Facing Deployment.

These steps are not intended to be followed for a Production server as they rely on a single Virtual Machine for all the infra-structure including:

  • Windows Server 2012 R2 Operating System
  • Active Directory Domain Services role,
  • Web Server (IIS) Role
  • Active Directory Federation Service (ADFS) V3.0 role,
  • SQL Server Enterprise 2014 SP1,
  • and of course Dynamics CRM 2016 with all roles on the same server.

This is clearly not a configuration recommended and supported by Microsoft but it’s very didactic as it touches to a good range of Microsoft server technologies and concepts.

This deployment adds a bit of complexity regarding some required work-arounds to make it run properly, but also remove some complexity in overall (less servers to deploy and configure, lower administration). Some straight lines and assumptions are taken, for example regarding the Windows accounts that again is not suitable for a Production environment.

Part1 covers the core infrastructure installation with MS Dynamics CRM 2016 configured for a simple AD Authentication, restricted to internal users. The schema below highlights the process:

You can complete Part 1 of this article and stop there with a fully functional Dynamics CRM 2016 server accessible only from the server itself.

Part 2 covers the Internet-Facing Deployment configuration of Dynamics CRM 2016 to have it support Claim-Based authentication for internal and external access thanks to the MS Active Directory Federation Service. The schema below highlights the process:

Requirements

For this deployment you need:

  • An Azure account: https://azure.microsoft.com with some credit available,
  • A Dynamics CRM 2016 On-premise license key (ideally through a MSDN subscription like Visual Studio Ultimate or you can use a trial key).

Virtual Machine Provisioning on Azure (new Portal)

2 alternative options are presented here:

  • Option 1 relies on an Azure Virtual Machine provided with both Windows Server 2012 R2 and SQL Server Enterprise 2014 SP1. This option is interesting if you do not have a license of SQL Server but would cost more since it will come with a mandatory storage disk, especially if you go for the premium SSD version
  • Option 2 relies on an Azure Virtual Machine provided with only Windows Server 2012 R2. You’ll have to install your own SQL Server, but it is possible to make it use the VM disk space instead of an independent storage disk, which is fine for a development box.

Option 1: VM with Windows Server 2012 R2 + SQL Server Enterprise 2014 SP1

You need, first of all, a Resource group on the new Azure Portal:

  • You can create it by clicking “New” à “Resource group”:
  • Give it a name, select your Azure subscription and then pick a location that is closest to you

You can now create a new Virtual Machine from the new Azure Portal:

  • Pick the “Database Servers” group and select the “SQL Server 2014 SP1 Enterprise on Windows Server 2012 R2”
  • SQL Server Enterprise is recommended (64 bits), SQL Server Compact or Express are not supported for Dynamics CRM (see Requirements in the links provided on the second article, Part 2)

  • Name your Virtual Machine
  • Define your admin account that will be used for the rest of this article
  • Select your Azure subscription
  • Select your Resource Group

On the next page you need to size your Virtual Machine:

  • Be careful with your choice, this is going to impact your burn rate and overall cost
  • We pick the DS2 Standard with 2 Cores, 7 GB of RAM, a disk of 14 GB that seems comfortable for a development environment

  • On the next page we would recommend the Standard disk type for a development box (the premium one adds a lot to the Azure burn rate)
  • We take the opportunity to create a Storage account, a Virtual Network with a public IP (static), Network Security Group from this interface
  • The Availability Set is not required for this dev. Environment

  • On the next page we define the SQL Server settings:
    • SQL connectivity: Private
    • Port: 1433 by default
    • Optionally Enable SQL Authentication and create a login and password for the SQL authentication (Windows Authentication only is fine)

Once the VM provisioning is complete, select “Connect to open a remote desktop session” and access your VM from your remote PC or Mac with Microsoft Remote Desktop. This software can be installed for free on Windows or iOS.

  • Use your VM username and password to access your Virtual Machine
  • By default, the Remote Desktop access port 3389 is enabled on your VM but be aware that this is the only open port to start with
  • Don’t try to ping your VM with your public IP, Azure doesn’t seem to let it going thru

Option 2: VM with Windows Server 2012 R2 only

Make sure you have a Resource group on the new Azure Portal (see Option 1).

You can now create a new Virtual Machine from the new Azure Portal:

  • Pick the “Windows Server 2012 R2 Datacenter”

  • Follow the same steps as Option 1, but you will not encounter the SQL Server settings.

Now we are going to install our own database software.

Transfer across your VM an installer of Microsoft SQL Server 2014 SP1 Enterprise (or another MS SQL Server version supported by Dynamics CRM 2016) and launch the installer.

  • Select ‘New SQL Server stand-alone installation’

  • Accept the software license terms on the next screen
  • On the Install Rules screen, you can ignore the warnings about the Computer Domain Controller and Windows Firewall, since we are building a development environment

  • On the Setup Roles screen, select ‘SQL Server Feature Installation’ and click ‘Next’
  • On the Feature Selection screen make sure to check the following features:
    • Database Engine Services
    • Full-Text and Semantic Extractions for Search
    • Reporting Services – Native
    • Management Tools – Basic
    • Management Tools – Complete
  • Leave the default installation paths proposed by the wizard

  • On the next screen, you maybe signaled some missing features like the .NET Framework 3.5 Feature. You’ll need to go and add those features via the Server Manager (Manage à Add Roles and Features). You can proceed with the installer afterward if no reboot is required.

  • If no missing features, you’ll reach the Instance Configuration screen
  • Leave the Default instance with its default Instance ID

  • On the Server Configuration screen, associate the following Account Names:
    • SQL Server Agent: NT AUTHORITY\SYSTEM
    • SQL Server Database Engine: NT AUTHORITY\SYSTEM
  • Leave the other accounts as default

  • On the Database Engine Configuration, you can keep the Windows authentication mode or optionally use the mixed mode
    • In that second case, provide a password for the ‘sa’ account
  • Click the button ‘Add Current User’ to add your current admin account as the SQL Server administrator. You can also add later other users such as your CRM Admin user.

  • On the next screen, confirm ‘Install and Configure’
  • And finally, you’ll be ready to install … click ‘Install’

  • Check the Windows services, and make sure the SQL Server Agent is running. If not, you’ll have to change the Log On user in the service properties and use an admin user declared in the Active Directory (like your current user).

Active Directory Domain Services Installation and Configuration

Access your VM via Microsoft Remote Desktop, open the Server Manager:

  • Click “Add Roles and Features”
  • Leave the choice “Role-based or feature-based installation”

  • Select your server from the server pool

  • Add the Server Role “Active Directory Domain Services”
  • Accept to add all the required features for Active Directory Domain Services

  • Make sure to also include these features:
    • Windows Identity Foundation 3.5
    • Windows Search Service

  • Click “Next” button

  • Click “Next” button and accept the Wizard to automatically restart the server if needed

  • Click “Install” and wait the end of the process
  • Click “Promote this server to a domain controller”

  • Check “Add a new forest”
  • Define your Root domain name: e.g. mydomain.com
    • It will be matching the domain we will register with a public internet Domain provider later, so select it carefully and check if this domain is available

  • Click “Next”
  • On the next page, fill up the following fields:
    • Forest functional level: Windows Server 2012 R2
    • Domain functional level: Windows Server 2012 R2
    • Check the box “Domain Name System (DNS) server”
    • Choose a password for the Directory Services Restore Mode (DSRM) and note it somewhere safe

  • Click “Next” to reach the DNS Options
  • Ignore the popup message notifying you that “a delegation for this DNS server cannot be created…” as this is irrelevant for a developer server

  • Click “Next” and verify the NetBIOS domain name assigned to the domain

  • Click “Next”
  • Accept all the default locations for the AD DS database, log files and SYSVOL

  • Click “Next” and make sure the Prerequisites Check is passed

  • You can safely ignore the warnings from the Prerequisites Check
  • Click “Install”
  • The server reboots at the end of the promotion operation, this is fine, you’ll be able to connect again in a few minutes
    • You’ll use your domain credentials instead of your local server account, e.g. mydomain\login

IIS Web Server and Application Server Installation

Open again the Server Manager:

  • Add more server roles:
    • Application Server
    • Web Server (IIS)

  • Click “Next”
  • Leave the selected features

  • Click “Next”
  • On the “Role Services” page for the Application Server, check the following services and add all related features:
    • .Net framework 4.5
    • Web Server (IIS) Support
    • HTTP Activation

  • Click “Next”
  • Select the following Management Tools on the “Role Services” for the Web Server (IIS):
    • IIS Management Console
    • IIS Management Scripts and Tools
    • Management Service

  • Click “Next” and “Install’ then wait the installation process to complete
  • All the new server roles will now appear in the Server Manager

Organizational Unit and CRM Users creation in Active Directory

Now we are going to add in the domain an Organizational Unit and some users for the CRM:

  • From the Server Manager, click the “Tools” menu and select “Active Directory Administrative Center”

  • Create some CRM users, e.g.
    • CRM Administrator: mydomain\crmadmin
    • Better check Account never expired for dev users

  • Add the administrator account into the performance Log Users (it is required if you use this account for the Dynamics CRM set up)

  • Don’t forget to add a password for your users
  • Click “OK” for each user

  • Next, create a new “Organizational Unit”

  • On the Organizational Unit page:
    • Name=CRM2016
    • The CRM setup will add its specific AD security groups in this OU

  • Click “OK” and leave the wizard

Reporting Services Configuration

Reporting Services are already installed on the VM with SQL Server Enterprise 2014 SP1. We just need to perform a few configuration steps:

  • Open the Reporting Services Configuration Manager and connect it to your server
  • Select Report Server Service Account as “Use built-in account” and pick “Local System”
    • Note that the Report Server local account is not supported by Dynamics CRM

à If you went for the option 2 and installed SQL Server yourself, then you can ignore the following steps about the Reporting Services.

  • Click “Apply” and move on to the “Web Service URL” page
  • Just click the “Apply” button to create the IIS directory with default settings on the default web site

  • Click “Apply” and move on the “Database” page
  • Click the “Change Database” button
  • On the popup wizard, select “Create a new report server database” and click “Next”

  • We are done with the SQL Server Reporting Services (SSRS) configuration

Microsoft Dynamics CRM 2016 Installation

Now it’s time to install Microsoft Dynamics CRM 2016 Server. Launch the Setup:

  • Click the link “Install Microsoft Dynamics CRM Server”

  • Get the updates for Dynamics CRM if any
  • Click “Next”

  • Install all the listed required components

  • Click “Next” if all components were installed successfully

  • Choose a path for the installation files, the default is fine
  • Click “Next”

  • Specify the Server Roles
    • We are building a development environment where all Server Roles are deployed on the same server, so check all tick boxes
    • In Production, we would probably dispatch the different roles on multiple servers with some redundancy servers in play
  • Click “Next”

  • On the Deployment Options, select “Create a new deployment”
  • Select the name of the computer that is running SQL Server, the same as the one where you’re installing Dynamics CRM
  • Click “Next”

  • Browse and select the Active Directory Organizational Unit (OU) created earlier
  • Click “Next”

  • On the Service Accounts specification page, we should normally define one specific account per service, but that would be for a Production environment
  • In our case, we’ll keep the default “Network Service” for all services
    • You could use a specific account like the “CRM Admin” you created earlier, but we decided to leave this account to be effectively the CRM Administrator later
  • Click “Next”

  • On the Website page, it is very important in our case to create a new website dedicated to Dynamics CRM
    • The default Web site is reserved for ADFS and in our typical scenario is not recommended to use (even if our version of ADFS doesn’t really rely on IIS, there are still some binding magic going on)
    • Create a new Website with Port Number = 5555
  • Click “Next”

  • We do not plan to deploy the Email Router now (this can be done later)
  • Leave the box blank and click “Next”

  • On the Organization Settings screen, fill up:
    • Display Name: CRM2016 (same as Organizational Unit)
    • Unique Database Name: CRM2016 (same as Organizational Unit)
    • Select your currency
    • Leave SQL Collation by default
  • The selected Organization Name “CRM2016” will be reused in the subdomain of the external URL so choose it carefully
  • It is possible to add other Dynamics CRM Organizations in top of this one later
  • Click “Next”

  • Check that the default Report Server URL is correct (see in Reporting Services configuration)
  • Click “Next”

  • This is time for a full system checks
  • Don’t worry too much about the security warning, there are normal because we are deploying a development environment
  • Click “Next”

  • You should reach out the final screen when the Dynamics CRM Server installation is completed
  • Tick the box “Launch Reporting Extensions for SSRS Setup” so the next wizard can start
  • Click “Finish”

  • IIS should now have the Microsoft Dynamics CRM web site in top of the Default Web Site, you can do this quick check

Reporting Extensions Installation

In order to start the CRM Reporting Extensions setup wizard, you could have ticked the dedicated box on the previous wizard or launch it manually from the Dynamics CRM setup:

  • Check “Get updates for MS Dynamics CRM”
  • Click “Next”

  • Select the Database Server, in our case it is deployed on the same server
  • Click “Next”

  • Select the SSRS Instance name by default
  • Click “Next”

  • Leave the default Installation directory
  • Click “Next”

  • Time for the system checks
  • Again, in the case of our Development server, we are not too worried about the security warnings
  • Click “Next” and start the installation

  • This is the completion screen you see when the installation is done successfully

Dynamics CRM 2016 Testing and Post Admin

Accessing Dynamics CRM 2016 for the first time

You can access to Dynamics CRM 2016 with the url: http://{your_server_name}:5555

  • Do a quick test drive and make sure everything works all right

Sample CRM Data Addition (Optional)

For a Development environment, it’s always a good idea to add some test data. Good news, Dynamics CRM has got a few in store for you:

  • Pick the “Settings” in the main menu
  • Click on “System”à“Data Management”

  • On the next page, select the icon “Sample Data”

  • Go and install the Sample Data

Extra CRM Users Creation (Optional)

  • Click on the main menu “Settings” and pick “Security”

  • Click on “Users” and click the button “+ New”

  • Enter a user name of someone that is already in your Active Directory
    • E.g our CRM Administrator created earlier with user name = crmadmin
    • Data will be autocompleted from AD
  • Click “Save”

  • Once the user is saved, click button “Manage Roles”

  • Typically for our CRM Administrator we select the roles:
    • “Activity Feeds”
    • “Salesperson”
    • “System Administrator”