MDS website won't load after install: configuration errors and how to fix them

The MDS install runs in two steps: first the website is deployed to IIS, then the database is configured. If you reached the website and got an error instead of the login screen, one of these two steps is incomplete or misconfigured. The error message "no Master Data Services instance section exists" means the website is looking for configuration that should have been written to the database during setup, and it is not finding it.

Start here: can you reach the web server at all, and if so, what are you seeing? That tells you whether this is a network problem, a permission problem, or a configuration problem.

Step 1: Verify the website is running

Open IIS Manager on the web server and look for the MDS website. It should be listed under Sites.

• If the site is there and shows a green play icon: The website is running. Try navigating to it in a browser. If you still see an error, move to Step 2.
• If the site is there but appears stopped (red circle): Right-click it, select "Start", and try again. If it stops immediately after starting, check the event log.
• If the site is not there at all: The install did not complete. Rerun the Master Data Services Configuration Manager and walk through the website setup step again.

To find the MDS Configuration Manager: on the SQL Server instance that has MDS installed, go to Start → Master Data Services Configuration Manager.

Step 2: Check the database connection

The website connects to the MDS database using a connection string stored in the IIS application web.config file. If this connection fails, the website cannot start.

First, verify that the MDS database exists and is in a healthy state:

-- On the SQL Server instance:
SELECT name, state_desc, is_broker_enabled FROM sys.databases WHERE name LIKE 'MDS%';

You should see the MDS database with state_desc = ONLINE and is_broker_enabled = 1. If the state is OFFLINE or RESTORING, the database is not ready. If the broker is disabled, enable it:

ALTER DATABASE MDS SET ENABLE_BROKER;

Next, check the connection string in the web server's web.config file. Navigate to the MDS website folder (usually C:\Program Files\Microsoft SQL Server\[instance]\Master Data Services\Web) and open web.config in a text editor. Look for a <connectionStrings> section:

<connectionStrings>
  <add name="MDS" connectionString="Server=SQLSERVER01;Database=MDS;Integrated Security=true;" />
</connectionStrings>

Verify that:

• Server name is correct: Does it match your SQL Server instance? If your instance is on a different machine, use the full name: Server=10.0.0.100\SQLEXPRESS or Server=sqlserver.domain.local
• Database name matches: If you renamed the MDS database during install, update it here too.
• Integrated Security is enabled: Unless you specifically chose SQL authentication, it should be true.

Test the connection from the web server using sqlcmd:

-- From a command prompt on the web server:
sqlcmd -S SQLSERVER01 -d MDS -E -Q "SELECT @@VERSION"

Step 3: Verify the app pool identity has permission

In IIS, the MDS website runs under an "app pool," which is a Windows user account. That account must have a login in SQL Server and must be a member of the mds_exec database role.

Check which account the app pool is using:

• Open IIS Manager → Application Pools
• Right-click the MDS app pool → Advanced Settings
• Look for "Identity" (often near the bottom) — it typically shows ApplicationPoolIdentity (a built-in account) or a domain account

If it is running as ApplicationPoolIdentity (built-in), the SQL Server login is IIS APPPOOL\MDS (where "MDS" is your app pool name). If it is running as a domain account like DOMAIN\AppPoolUser, that domain account needs a login.

Check the logins on the SQL Server:

-- On the SQL Server:
USE master;
SELECT name FROM sys.server_principals WHERE type IN ('U', 'G') AND name LIKE '%AppPool%' OR name LIKE '%MDS%';
GO

If the login is not there, create it:

-- For a domain account:
CREATE LOGIN [DOMAIN\AppPoolUser] FROM WINDOWS;

-- For the built-in ApplicationPoolIdentity:
CREATE LOGIN [IIS APPPOOL\MDS] FROM WINDOWS;

-- Add the login to the mds_exec role:
USE MDS;
EXEC sp_addrolemember [mds_exec], [DOMAIN\AppPoolUser];
GO

After adding the login and role membership, restart the app pool in IIS (right-click it in Application Pools → Recycle).

Step 4: Folder permissions and physical path

The IIS website must point to the correct physical folder, and that folder must have the right permissions.

In IIS Manager, click the MDS website and look for the "Physical path" shown in the middle pane. The typical path is C:\Program Files\Microsoft SQL Server\[version]\Master Data Services\Web. Verify that folder exists on disk.

Next, check folder permissions. The app pool identity needs Read and Execute permissions on this folder. Right-click the folder → Properties → Security → Edit:

• Click "Add" and type the app pool identity: either IIS APPPOOL\MDS or your domain account
• Select it and check "Read" and "Read & Execute"
• Click "Apply" and close the dialog

Restart the app pool and try the website again.

Step 5: Reconfigure the website using MDS Configuration Manager

If the above steps do not fix it, the safest next step is to delete and recreate the website through the MDS Configuration Manager.

• Open Master Data Services Configuration Manager on the SQL Server
• Click "Web Configuration" on the left
• Select the website from the dropdown and click "Delete"
• Click "Create" to recreate it, and walk through the setup wizard again

This often fixes configuration issues that are hard to diagnose. The Configuration Manager will rewrite the web.config, re-add the database connection, and ensure all the plumbing is in place.

Special case: MDS database on a different server

If the MDS database is on a different SQL Server instance (either on a different machine or a different Azure SQL Database), three extra things must be true:

• TCP/IP must be enabled on SQL Server. Check SQL Server Configuration Manager on the SQL Server machine → SQL Server Network Configuration → Protocols for [instance name] → TCP/IP should be "Enabled".
• Port 1433 (or your custom port) must be open. From the web server, run telnet [sql-server] 1433 and verify it connects. If you get "connection refused" or no response, the port is blocked.
• The app pool identity must have a SQL Server login with network permissions. If the app pool is running as ApplicationPoolIdentity and SQL Server is remote, you must change the app pool to run as a domain account first. Built-in accounts cannot authenticate over the network to SQL Server.

For Azure SQL Database, add the database to a Virtual Network or allow public endpoint access from the web server's IP address via the Azure Firewall rules.

Common questions