Using related entities in PowerApps with MSDYN365 as a data source

Getting related records to work in PowerApps and MSDYN365

PowerApps is a relatively new feature to the Office365 portfolio which allows advanced users to create their own apps which can be used on mobile (and desktop) platforms to perform daily tasks. It is a great tool for creating those small functions you usually have to book a developer for a few hours/days, and is ready for authentication, authorization, and distribution right out of the box.

PowerApps comes with the ability to connect to a wide array of sources to collect and manipulate data, and today I'm going to demonstrate how to connect with MSDYN365:CRM and how to use connect with related records.

Connecting to MSDYN365:CRM

Now this is the easiest part. To connect with MSDYN365 in your powerapp simply go to the 'Content' tab and select Data Sources, and you'll be presented with the option to add new connections and data sources. Here it will probably show you something like this (I have a completely new trial organization with only O365 E3 and MSDYN365 Plan1:

What I'm doing is connecting to the MSDYN365 suggestion, and I'm going to add 3 tables (entities) to my data source list; Accounts, Contacts and Users (systemusers).
Once that's done I'm going to add a new screen with the browse template. This will give me the option to search and display records from the chosen data source.
Now, from the right hand side, choose the advanced tab and select your Gallery component from the dropdown list. Next through the Home tab on the top toolbar select "Items" from the property dropdown box. We're going to do some drastic changes to the formula used to collect data, but first a little insight.

When a function is run/validated in powerapps it returns the result set to the parent function (or context, whatever you'd like to call it). This means that we can build an advanced data source or query by nesting functions inside each other, and end up with a pretty good set of data to play with.

So to get the data I want in my gallery browser I'm going to use the following formula:
SortByColumns(Search(AddColumns(Accounts, "User", LookUp(Users, systemuserid = _ownerid_value), "Contact", LookUp(Contacts, contactid = _primarycontactid_value)), TextSearchBox1.Text, "accountnumber", "name"), "name", If(SortDescending1, Descending, Ascending))

Now this might seem a little frightening at first, but I'll go through it step by step and you'll see how I thought through it. Remember the part about nesting functions that I mentioned above? Well that's how I start building a function, by nesting backwards.

1. I want a collection of accounts, but I also want to add the primary contact and the account owner (I'm not checking for teams, I'm just assuming that all accounts are owned by users. This is just a quick demo). That means I'll have to use a function to join those sources. A quick search online says that I can use AddColumns to do joins in a PowerApp formula, and thanks to the built in intellisense it's easy to create the formula required.
   AddColumns(<data source>, <table alias>, LookUp(<data source>, <condition>))
   This will nest the related table underneath the table alias (or namespace if you will), and you can add additional tables by just specifying new column aliases and lookup expressions. To get the ones I needed I filled in the following:
   AddColumns(Accounts, "User", LookUp(Users, systemuserid = _ownerid_value), "Contact", LookUp(Contacts, contactid = _primarycontactid_value))
   This means that I've nested the Users entity underneath the "User" column alias, and the Contacts entity underneath the "Contact" column alias.
2. I need to be able to search for these records, I don't simply want all the accounts listed at all times. Search is a function designed for this, but I could also use Filter if it was a set query I wanted to use. Now I know that the AddColumns(...) functon I used will return the result set of that function, so I could potentially search through the related records as well. I'm going to do it a lot simpler so I'll want to search through the account number and name field on account. The syntax is :
   Search(<data source>, <Search text>, <Column to search in>, <Column2 to search in>, ...)
   The data source in our case will be our previous AddColumns formula. The search text we'll get from the default search box, TextSearchBox1.Text, and the columns we want are "accountnumber" and "name", which makes the formula look like this:
   Search(AddColumns(.....), TextSearchBox1.Text, "accountnumber", "name")
3. Lastly I'd like to sort the result, so I'm going to add a SortByColumns function just to get a predictive list instead of a random one. This starts just the same as our previous function, the result of everything we've done so far has been returned, and we can order by the columns we want. The syntax looks like this:
   SortByColumns(<data source>, <column name>, If(<logical test>, <true value>, <false value>))
   We want to use the data source we've built so far, and we want to use the "name" column of the account. The logical test will be the default sorting button, with true as Descending and false as Ascending (false is the default value). We end up with the following formula:
   SortByColumns(Search(...), "name", If(SortDescending1, Descending, Ascending))

Now we've got a search gallery were we can search for accounts and get the related primary contact and the owning user data values. We can use that to further style our result list so it will look something like this:

Customizing the details form

So now that we have a decent-ish looking gallery we want to do some modifications to our details and edit forms. There isn't really any magic to this, you simply add and remove the data fields that you want. There are however two things I would like to point out so that you don't walk into the sweet honey traps.

First of all, we want to set a data source and item that PowerApps has a relation to and can work with. If we choose the same data source as we used in the gallery then we can certainly we the data and place it on the form, but updating the record or creating a new one could prove a bigger challenge. So what we do here is that for the data source, we set the "Accounts" entity table. The Items property is a bit more special though, and here we have two options (I'm going for option 2):

1. We use the item from the gallery, ie. BrowseGallery1.Selected. This will work perfectly fine as long as you don't try to update any other fields than the main account fields. However, you will get an error in the PowerApp user interface because the data source chosen for the details form is not the same data source as you have in your gallery. The upside is that you don't have to do a new query to get the account data, but on the downside you will have to live with a warning sign that comes with not following the best practices.
2. We use the accountid from the gallery to look up the specific account from the account data source, ie we use the following formula:
   LookUp(Accounts, accountid = BrowseGallery1.Selected.accountid)
   The positive thing about this is that we're now 100% compliant with the best practices, but we now don't have direct access to the sub-components, and we're doing an additional query to CRM for a lookup. Luckily, this lookup is very cheap because we're getting 1 entity based on the Guid, and I'll be picking this one just so we can demonstrate how to do a lookup inside a field.

So now that we've got the data available we can start adding the fields to the forms. If we want to have some fields from related records we can simply use the LookUp function to get them. For example, if I want the full name of the primary contact I can use this formula in a data form:

LookUp(Contacts, contactid = _primarycontactid_value).fullname

So now that I've done a very small amount of customization my detail form looks like this.

Customizing the details form and changing the primary contact

So now we're ready to do some customization to the edit form. I've gone ahead and added the same data source and item as we did on the detail form, and I've added the address fields just so we have something to play with. The results so far looks like this:

Now, as a power user I would love to be able to edit the primary contact of the customer without having to specify a Guid, I want a search window so that I can find the right one and add it to the account I'm looking at. The first thing I'll do is to add a new browse gallery screen, and then I add a new button on the edit form which navigates to the new screen:

Now, on the contactselector screen I want to show all active contacts. I'll start off by creating the same kind of formula as we did in the beginning of this blog post, but this time I'm just searching through the Contacts data source. My formula now looks like this:

SortByColumns(Search(Filter(Contacts, statecode = 0), TextSearchBox2.Text, "fullname"), "fullname", If(SortDescending1, SortOrder.Descending, SortOrder.Ascending))

Now the right arrow on each result will usually try to navigate to a details window, but we don't have that window here and we don't want to see the details either, we just want to add this contact as the primary contact to the account. So what we're going to do is to use the "patch" function in PowerApps. The Patch option allows you to edit items on an existing record, while the update function replaces an old record with a new one. Since we just want to update the contact I'm going ahead with the patch method. The syntax for the patch function is like this:

Patch(<data source>, LookUp(...), { field1: value1, field2: value2})

So we want to update the account we have selected in previous windows. In additon, we want to update the primary contact Id for that account. That means we have to do a formula like so:

Patch(Accounts, LookUp(Accounts, accountid = BrowseGallery1.Selected.accountid), { _primarycontactid_value: ThisItem.contactid})

This is starting to look pretty nice, but we also want to navigate away from this form after updating. To do that we simply add a semicolon after the Patch function, then call the Back() function to go to the previous window. What we end up with is a window that looks something like this:

So now we have a complete app that can search for Accounts, display related record information, and finally edit the fields and set a new primary contact. This should work just as well for all related records, but now you have a pretty good example to start out with.

Wrap-up

So as we've seen not everything in PowerApps is just point-and-click, but you don't have to be an advanced developer to find out this stuff on your own. The documentation for powerapps is decent, so you'll find plenty of examples you can experiment with on your own.

What I find very exciting is that not only can I create these simple apps very fast, I can also distribute them to other users in my organization so that it will be available from the https://home.dynamics.com menu.

I've added a copy of the powerapp to to my public google drive so you can download it and use it as you want (TestAccounts.msapp). 

All you have to do is to go to the "Content" tab and add the data sources, you'll need "Accounts", "Contacts" and "Users", and then you're ready to go.

Handling CRM 2016 organizations (and a tuning tip)

Handling organizations in MSCRM 2016

This post is about handling organizations in Dynamics CRM 2016 using the Deployment Manager tool and SQL Server Management studio. Just a heads up, this will be along one, but there's lots of pictures too.

What is an organization?

An organization is... well, an organization! You can think of it as an instance in your CRM deployment. Multiple organizations can exist in the same deployment of CRM services, but they are completely separated from each other. The benefit of having multiple organizations is mainly for enterprise size companies, who have large organizations with almost completely different needs in regard to customization and work methologies. When this is the case you can create multiple organizations with it's own set of customizations and web parts.

In addition, if you have multiple developer teams working on different things in your CRM environment then each team can get their own organization to deploy their changes in, and it doesn't require multiple servers with CRM and SQL Server, dozens of AD groups, etc.

An organization is actually just a SQL Server database, as we will see later in this post, and that is part of the reason why you are required to have unique organization names.

Organization overview and deployment administrators

To get an overview of your organizations you can simply open up the Deployment Manager from a CRM Server with the "Deployment Server" roles installed. One caveat is that you'll have to be added as a deployment administrator first, and you need login permissions on the SQL Server where the organization and configuration database is stored, and permissions to the MSCRM_CONFIG database. If you try to open the deployment manager without these permissions first then you'll get the following error message

To add new deployment administrators, log on with the user account used to install MSCRM, and open up the deployment manager tool. Navigate to "Deployment Administrators" and click on the "Add Deployment Administrator" link on the right hand side. Type in the name of the user you want to add, and click OK.


Now, to find your organizations simply navigate to "Organizations" on the left hand menu, and you'll get a list of all the connected organizations in your environment, both active and disabled (but not deleted, more on that in a little while). The overview lets you see the name (this is the unique name), display name, status, version and update availability of all your organizations.


You can also right click the organization to open up the properties for it

Adding organizations

Next let's step through the process of adding a new organization. From the organization overview simply hit the "New organization" link on the right hand side. This will give you the "New Organization Wizard", which collects the basic information needed to create a new organization.

Now, here are a few steps to complete, starting with display name and unique database name. Remember _MSCRM is appended to the unique database name, so it will look like this in SQL Server: myorganization_MSCRM. The display name is the name visible in the navigation bar beneath your name on the right hand side (depending on your screen resolution).

Next choose the base currency. Remember! None of the settings below "Unique Database Name" can be changed after the organization has been created. 

If you click the browse button and find your country from the list it will automatically fill in the currency code, name, symbol and precision.

Now, here's a pro tip: If you install additional language packs on the server then you're able to deploy multiple organization with different base languages. There are a lot of people who think that once the base language is chosen you have to uninstall to change it, but you really just have to deploy a new organization (which suddenly becomes a problem if you've already added tons of data to the old one, but lets hope you spot the mistake early on).

OK, last one out, the SQL Collation. Make sure you choose the same collation as the default one in your SQL Server. If you don't know which collation it has, ask your DBA. But just to be nice, here's how you do that yourself using tsql:

SELECT CONVERT (varchar, SERVERPROPERTY('collation'));

Next, select the SQL Server you want to store that databases on (it automatically fills in the same server as the MSCRM_CONFIG database is stored on), and the reporting URL. The slightly negative thing about the reporting URL is that it won't check which URLs the other environments use, it will just pick the SQL Server name and add HTTP:// to the front and /ReportServer at the back. So if you want to be sure you're using the correct SSRS server then you can copy that from the details about one of your other organizations (see the part about organization overview).
Please note that adding a new organization and importing existing organizations requires the SRS Data Connector to be installed beforehand. See my previous blog post for more information on installing this component.

Now, rock on through to the summary screen, and hopefully it will be one warning accompanied/succeeded by two green flags. The warning is for data encryption which will be activated, and that you should backup you encryption key.

Just a heads up, it is not unusual for the creation to take a long time during the "Microsoft.Crm.Tools.Admin.ImportDefaultDataAction" and similar screens. I've seen these take well over 30 minutes before so just get yourself a decent cup of coffee and come back later (or stare at it intensively, that's always fun)

When the creation is complete the new organization will be visible in the Organizations overview in the Deployment Manager

Deleting an organization

In this section we'll go through how to delete an organization. I'll show you some related topics along the way like editing the organization settings and the overview in SQL Server.

First off, to delete an organization you need to start with disabling it. Simply right click the organization from the overview in the Deployment Manager, and click disable. After you've done this, right click it again to delete it from the deployment. Please be aware that this does NOT delete the database, it simply removes it from the "organizations" table in the MSCRM_CONFIG, the database is still present and online in SQL Server. One thing you might notice when you've disabled the organization is that a new option is available; edit organization. This allows you to specify new values for an existing organization.

Importing an organization

This chapter explains how to import an organization. This typically happens when you want to clone your production environment into test or migrate from one server environment to another.
Start in the "Organizations" overview in Deployment Manager, and click the "Import organization" link on the right hand side.
This will bring up the "Import Organization Wizard", which automatically lists the organizations available for import on the SQL Server specified. Organizations that already exists in the deployment will not be listed.


Next you'll be able to edit both the display name and the unique database name. Editing the unique organization name does not actually edit the database name, it only edits the unique name stored in the database tables, which is appended to Internet Facing Deployment URLs.

Next specify the SSRS server URL you'll be using for this organization, and proceed to the next screen. Now, the installation will ask you for user mappings. This is for mapping the users in the organization to AD user accounts, and you can either choose automatic mappings or manual mappings. Automatic mapping is best when you're importing into the same active directory domain as it previously was. Manual mapping allows you to to specify all users manually, or create an import schema which you can edit in Excel.


I'll stick to automatic, because there's only one user in the organization.
To proceed with the import you have to map the current logged in user to a system administrator in the organization. If you try to continue without mapping this user you will be presented with the following error message

When this is done you'll be ready to import the organization, and you'll be presented with the familiar CRM process bar. Please note that if you've imported an older database, for example CRM 2015 or a previous update rollup, the database schema will be updated during import


And you're done! Organization imported and everything is (hopefully) nice and dandy. If you go into SQL Server you should be able to see that the databases are present, and the name of your organization has not been edited

Bonus round

Parallelism in SQL Server

A good tip I can't give often enough is the Max Degree of Parallelism (MAXDOP) setting in SQL Server. Some years ago in the "Best practices" documentation for CRM 2011 it was adviced to set MAXDOP to 1, meaning only one thread per SQL statement. This can cause horrible performance problems in CRM, because almost all queries rely on joins and filtering based on those joins, and that requires a lot of work if you can't execute it in parallel. Subsequently, this recommendation was removed, but the practice has continued with many consultants and IT Pros (this could also be because MAXDOP 1 is an actual best practice for Microsoft SharePoint).

So my tip: set MAXDOP to 0, and set threshold for parallelism to 4 or 1/4 of the number of processor cores on your SQL Server (whichever is higher). This is a generic recommendation, so do keep in mind that YMMV.

Developer resources in CRM

One of my favorite new things in the new CRM navigation is the improvements to the Developer Resources, available from Settings -> Customization

This new page gives you a lot of great information, starting with useful links for devlopers, the new WEP API available per instance, the organization id and the unique name, as well as the new discovery web api (and the old SOAP api, but SOAP is like, totally so 2009).

That's it for today, I hope you found this post useful.

Tomorrow I'll do a post on how to create an Office365 tenant and activate the CRM feature.

With the Deploying Microsoft Dynamics CRM Online exam it is increasingly important to know your way around the Office365 instance.

Until then, happy CRM-ing!

Basic post installation tasks for CRM 2016

Post installation tasks for Microsoft Dynamics CRM 2016

This post will be all about post installation tasks for Dynamics CRM 2016. It's a collection of tips and tricks I've learned and used over the years. I'm assuming that you've already installed CRM 2016 on your servers, but in case you haven't and need some tips check out my previous post.

Prerequisites

As mentioned, I'm assuming you already installed MSCRM 2016 on your servers, in addition I assume you have some basic understanding of the related technologies. Because I've been a newbie and know how frustrating it can be to look up related information I've included links to good resources for learning the technologies as we bump into them.

I also assume that you will be actually reading this post, because you won't necessarily understand the context and ramifications if you cherry pick answers from inside the document.

Software

SQL Server Reporting Services data connector

In yesterday's post I went through the installation of a single server CRM 2016 deployment, and finished off on installing the actual CRM Server application. The first part today will be to install the SRS Connector for Dynamics CRM 2016.
To install this package you need to locate your installation media and copy the folder named "SrsDataConnector" over to the server running SQL Server Reporting Services (SSRS).


Run the SetupSrsDataConnector.exe file to start the installation, and head through the steps:

1. I recommend getting the updates for the Dynamics CRM installation. If there's any bugs in the installation then you might get updated installation files that fixes these. 
2. Read throught the important license requirements and rock on through. The first selection is which SQL Server is used to store the MSCRM_CONFIG database, if you can't find it on the list then it's either because SQL Server Browser isn't running or some port exclustions.
3. On the next screen you choose which SSRS Instance you want to use. Remember that SRS Data Connector can only be installed ONCE on each Windows Server, so even if you have multiple SSRS instances on one server you can only install the connector for one deployment.
4. You arrive at the system check screen, which is all greens (if not, check the next step). Hit next and install that connector.
   
5. If you receive the following error it means that SSRS isn't running in the context of a service account. Perform the steps described in this article (technet) and retry the installation.
   

CRM Trace viewer (PFE CRM Trace Tool)

Now this isn't strictly required or needed, but if you have to enable tracing in the future then I strongly advice using a good tool to read the trace logs. Trace logs are typically large and include a long call stack. Even the most seasoned developer can miss vital clues in large text files, so having a reader which allows you to filter and sort information can shorten an arduous debugging session by hours, or even days.

Head over to codeplex and get this viewer, used by Microsoft's MVPs when they're out on a mission.

Internet Information Services (IIS)

By default, MSCRM only installs the bare minimum services needed to run. If this is a development/test environment then you'll probably want to add some additional features to the webserver. Head over to server management and hit the Add Roles button to get the "Add Roles and Features Wizard". Rock on through until you get to the Server Roles window, and add the features you want to add. Heres a collection of features I like to add in addition to the default ones:

• Web Server (IIS)
• Web Server
• Health and Diagnostics
• HTTP Logging (great for debugging infrastructure-related issues, slow loading modules, etc
• Logging tools
• Request Monitor (do not use this in production without checking if you have consent. Monitoring user activity might infringe on privacy laws)
• Tracing (great for getting deep-down into the specific requests and performance related issues)
• Management Tools
• IIS Management Scripts and Tools (I love to do stuff in powershell, it allows me to save those little snippets and reuse them later. Also, more and more documentations and how-to guides gives you powershell commands to fix issues, so you might want to have IIS snappin available)

Configuration changes

Now over to the good stuff, configuration changes that I have found to help out quite a bit. I'll go into the simple configuration tips I've learned and give some details into what you should read up on if you're unsure about the settings and tools used. Performance tuning is reserved for another post, because that a whole chapter in itself.

Internet Information Services (IIS)

Didn't we just do this one? Well yes, but that was only additional features to the web server role, now we're gonna look at specific configuration options in IIS. Open up the IIS admin console (either from Start or run "inetmgr.exe").

1. First out, we're gonna go check the recycling settings. Navigate to the application pools on your server, find the one called CRMAppPool and select it. Click on the "recycling" link on the right hand side to bring up the recycling settings.
   
2. In the recycling settings, uncheck the box marked with "regular time intervals (in minutes)". This is the default IIS setting, which means the application pool will recycle every 29 hours. You probably don't want the application pool to recycle in the middle of the work day, and that will eventually happen with an odd-numbered time interval. I prefer to set it at night, maybe 2 or 3 AM. Just make sure you're not gonna have any integrations depending on the CRM Web Services running at the same time. Rock on through and complete the wizard.
   
3. Next up, click the "advanced settings..." link found just beneath the recycling setting in step #1. Locate the settings for "Idle Time-out (minutes)". This setting specifies how long the worker process, that is the process CRM is running in, can be idle before it gets terminated. The CRM installation has set this to 1500 minutes, or 25 hours. That means the worker process will be terminated if there are no activity in the specified timespan. You can leave it at this value, but I would recommend you set it to 0 (never) and rather restart the application pool manually if need be (recycling and restarting an application pool is not the same thing by the way).
   
4. If you want to you can repeat these steps for the deployment application pool as well, but you probably won't be using that service that much so it's fine to leave it with the defaults, unless you need to integrate with these services regularly (for example if your developers use it alot or if you intend to integrate with FIM)
5. Head over to "Sites" when you're done, and look at the list of sites available. For each of the sites (you might just have the one), navigate into it and locate the "Bindings..." link on the right hand side.
   
6. Open up the bindings and look for any TCP port 808 bindings. If you have any of those: delete them. The CRM services depend on this port number to work as expected, especially if you have sandbox plugins. If there are specific applications which need to have this port number, they should not be hosted on your CRM servers (or vice versa)
   

Antivirus settings

To make sure that CRM performs at it's best, you should exclude some directories from the antivirus scanning/monitoring. I won't be going into details for each possible antivirus application how to do this, I can only advice you to google (or bing) "<your antivirus application> add exclusions"

There's an excellent blog post from crminthefield on msdn regarding antivirus exclusions for Dynamics CRM found here (msdn).

The article is somewhat dated, but the information is still valid.

If you plan to/suspect you have to enable tracing in the future, you should also exclude the trace folders (configurable from powershell, but that's for another session called debugging).

The wrap-up

This started to get kind of lengthy, so I stopped at the simple configurations you can do to make your CRM environment run smoothly. The CRM installation has grown a lot since 2011 was introduced (first edition on IIS7+), and you no longer need to enable "authpersistnonntlm" og stuff like that. There's still a few options that can be done to tune the system, but you're pretty much done right now.

I'll be writing another, lengthy blog post on optimization/tuning in the future, so be sure to come back and check it out.

Tomorrow I'll be doing a blog post on backup/restore of your CRM environment, and for all you cowboys out there; it's more than just backing up a database.

Installing Dynamics CRM 2016

Installing Microsoft Dynamics CRM 2016

How to install MSCRM 2016 on a Windows Server 2012R2 with SQL 2014

MSCRM 2016 is here, and it's time to take a look at the installation to see what, if any, parameters and configurations have changed.
Spoiler: Nothing's changed, if you know how to install CRM 2013 or CRM 2015 then you know how to install all three. One thing to notice is that the setup has become more intelligent over the years, and now it will give the vss writer service account the correct permissions, and it will add the SPNs needed automatically (gived that you have the necessary permissions).
It does not, however, fix the performance log access the async and application service account needs, so you still have to add those manually.

Environment

I've set up a Hyper-V host with Windows Server 2012R2 with Active Directory and SQL Server 2014. Since it's all in one box I might have to cheat a bit, but I'll make sure to highlight it if it's relevant.

I've created an organizational unit in the root of my forest named "CRM" to use for the different groups.

Some tips:

• If you're just setting up a dev box then these are the only roles needed for SQL Server:
• Database Engine Services
• Full-Text and Semantic Extrations for Search
• Reporting Services - Native
• If you want to create the service accounts using powershell, add the ad ds command line tools from Roles and Features
• CRM will give you an error message if SQL Server Reporting Services isn't running with a domain user credentials, so if you've installed with local users I advice to switch accounts before CRM installs. Here's how (technet)
• Add the Asynchronous Processing service account and the Application service account to the performance log users before installation, just to save yourself the red ring of death that is the summary error!

Service accounts

I've pre-created the service accounts needed to install. I just use a short powershell command to generate accounts with the same password:

("svc-crmapp", "svc-crmdeploy", "svc-crmasync", "svc-crmvss", "svc-crmmon", "svc-crmsandbox") | foreach {New-ADUser -Name $_ -Confirm -AccountPassword (ConvertTo-SecureString -Force -AsPlainText "Secret123") -CannotChangePassword $true -ChangePasswordAtLogon $false -PasswordNeverExpires $true -Path "OU=ServiceAccounts,DC=test,DC=local" -Enabled $true }

Installation time!

1. It starts out like usual, asking to download updates for the installation only. I recommend that you do, because the installation could have bugs that have been fixed in newer updates.
2. License key: you know what to do (but in case you don't, here's the trial license key: WCPQN-33442-VH2RQ-M4RKF-GXYH4)
3. Read carefully through the lengthy terms, then proceed and hit install to download and install the necessary prerequisites (I'll add a future blog post on how and where to download these prerequisites manually, to enable installing on systems that are not connected to the internet)
   
4. If you see the following screen that means you'll have to restart (manually) and retry the setup. Geez Microsoft, it's been 5+ years since 2011 came out, can't you add a "restart now" button </lazy>
   
5. We're back! And it's time to decide on the installation path and which roles to add. In my case I'll be using defaults, and I'll add all roles. I'll be adding a future bloggpost with guidelines for multi-server deployments, be sure to check it out!
   
6. Next specify the SQL Server you want to use. If you're using SQL Server HA then you'll have to go through some ardous steps to configure CRM to use this post-installation. I hoped it would be easier in 2016, but they still haven't fixed native, UI support for HA listeners yet. Want to know how? Well here's how (technet)
7. Select the OU where you want to create the CRM groups. CRM 2016 (and the previous three versions) create 4 groups used for various purposes. If you want to create them manually you'll have to specify them in a config-file used for installation. I'll add some words of wisdom regarding unattended installation in a future blogpost, including what to do with those pesky encryption keys. In the meantime, here's the doc for the xml config (technet)
   
8. Next, specify the service accounts used for CRM, domain\username followed by passwords. Still the same 6 service accounts as in CRM 2013 and 2015
   
9. Next select which website you will use. I personally prefer to use a new website, and just edit the bindings in IIS later. The reason for this is that the MSCRM setup didn't use to remove the IIS default settings for the default website, so you got a lot of port bindings that you didn't need or want (like :808 which causes problems with the sandbox service and fetch based reports). More info on port numbers found here (technet). I'll be using the default this time, it's just for demoing anyway.
10. Specify the server used for the email router if you already know which one that is. Hopefully you'll be using the server-side-synchronization for emails, in which case just leave this field blank.
11. Now it's time to specify the defaults for your first organization. If you're using a multi-server deployment with only a few roles you won't get this screen. Remember! You can't change these settings later, so make sure you know which settings you want. The display name is the display name of the organization (metadata is important too!). The unique name is used in combination with a pre-defined text to create a database name (also, IFD uses this name appended to your URL to create public facing URLs). example_mscrm will be my organization.
    Also, make sure that you use the same collation as the SQL Server instance you're using, to prevent unnecessary translations in the db engine.
    
12. Specify the reporting services URL, this is the normal user accessible URL to your reporting services server, not the admin URL. By default the installation will suggest the same address as to your SQL Server, which isn't necessarily the case.
13. Next, you choose whether you want to be part of the customer experience program. I would check no, unless it's OK to send anonymous data to Microsoft about how you use the CRM application.
14. Finally, you're at the system verification check. If you're lucky you've done everything right, and it's all green (except for the data encryption, which you should fix post installation. See my future post for more information regarding encryption keys)
    
15. If you receive this screen you have to give the service accounts for the application role and asynchronous processing service permissions to the performance log. Use the following command to add each of them
    net localgroup "Performance Log Users" /add test\svc-crmasync
    
16. YOU'RE DONE! Let the installation run to completion and you're ready to start on the post installation tasks.

Wrap-up

As you can see, installing CRM 2016 is simple, simple as pie. Just follow these steps and you'll be done in no-time.

Tomorrow I'll go through the post-installation steps, be sure to check in!