Warning: This is allegedly fixed in SQL 2016 RTM CU1. While I haven't tested that I can confirm that post-patch you'll get an MDS error requiring the service account be granted permission on an additional temp directory. I haven't documented that step below.
When setting up the web application for MDS you must specify an Active Directory service account to use for the application pool. What's hilarious about this is that this will break your MDS installation unless you also add that user as a local Administrator (!) or otherwise jump through hoops to identify what else is required (which I'm going to do below).
Here's a clean SQL Server 2016 database engine and MDS install on a Windows Server 2012 R2 box. I've created a basic Active Directory account on the Domain Controller with no explicit permissions.
And on your first access to the web site it will generate this unfathomable error:
Which is actually code for "the tool Microsoft wrote explicitly to set up their web application doesn't work properly."
Add the domain account as a local Administrator. It's not listed in documentation anywhere. It's just expected you're willing to open a massive security hole in a customer-facing web application.
Check the service account is added to the local MDS_ServiceAccounts group (for example using lusrmgr.msc). This is important because sometimes the configuration tool doesn't do this!
Grant (only) Read permission on
C:\Program Files\Microsoft SQL Server\130\Master Data Services\WebApplication\web.configto the local MDS_ServiceAccounts group.
This generates a new error, though to see it you must modify web.config to have a line for
<customErrors mode="RemoteOnly" >
It looks fatal but this is just a bug masking the real issue. We'll come back to that in a minute.
Create a folder
C:\Program Files\Microsoft SQL Server\130\Master Data Services\WebApplication\Logsand grant (only) Write permission to the local MDS_ServiceAccounts group.
Success! It works. So much for that required registry access.
If you open up the logs however you'll see that registry access recorded as a (non-fatal) error at the beginning whenever the application starts. That's what was being reported before.
To fix this, open Registry Editor and grant Full Control on
HLKM\SOFTWARE\Microsoft\Microsoft SQL Server\130to the local MDS_ServiceAccounts group. Unfortunately any lower privileges will not get rid of the error.
What registry keys is it trying to read there anyway? Well, of course, it's the mandatory Microsoft spyware experience improvement program… I mean… Customer Experience Improvement Program. This registry access does not appear to be occur on older versions of MDS.
Notes: I had a very similar issue in late 2015 on the SQL Server 2016 CTP 3 which I reported on the Microsoft forums. They seemed to be aware of an issue that required MDS service accounts to have local Administrator access but didn't fix it for RTM.
John Eisbrener independently came to a similar conclusion a month ago, though I hadn't seen it until now. Thanks John. It's good to have confirmation that I'm not just going crazy and that all of these contortions really are necessary to get MDS running.