Tag: Security

SharePoint Install – Cannot connect to database master

This morning I encountered an error I hadn’t seen in a while, so I thought I would share the resolution with everyone (and keep a record for myself the next time it happens).

When configuring SharePoint using PowerShell after the initial install, you may encounter the error shown below.

image
[New-SPConfigurationDatabase: Cannot connect to database master at SQL server at ServerName. The database might not exist, or the current user does not have permission to connect to it.]

The error is misleading, as it implies that either there is no Master database on the SQL server or the current user doesn’t have the correct permissions. I did check the user’s permissions in SQL:

image

The required permissions, dbcreator and securityadmin, for the SharePoint installed account were configured correctly. So my next step was to confirm the SharePoint server could actually connect to the SQL server. Windows Firewall is running on the SQL server, but there wasn’t a rule allowing SQL communication (ms-sql-m).

After configuring the firewall to allow ms-sql-m traffic, the SharePoint configuration proceeded without issue.

image
[Windows Firewall – Allow ms-sql-m traffic (port 1433 and 1434)]

Error Connecting to Database Server

I recently setup yet another SharePoint farm (this time using virtual machines) and ran into a problem that happens all too often.

The scenario is this: I setup MS SQL server in preparation for getting SharePoint installed on a separate server. After setting up your service accounts in Active Directory and installing MS SQL on Server1, I set off installing SharePoint on Server2. When I got to the screen in the Specify Configuration Database Settings within the SharePoint configuration wizard, I received the following error:

1
Cannot connect to database master at SQL server at ServerName. The database might not exist, or the current user does not have permission to connect to it.

Knowing the database ‘master’ did exist, I setout to solve the “current user does not have permission” issue. I opened the SQL Management Studio and checked to make sure my account had permission to connect.

2

I checked the permissions for the service account and everything looked good. So, what’s going on?!?

Since I don’t follow a setup script anymore (I have done this hundreds of times, so I know what I am doing, right?), I had forgotten one step. MS SQL listens for incoming traffic on port 1433. When setting up your SQL server, you have to make sure you create a firewall rule to allow that incoming port. This is elementary and I should have remembered this step, but no one is perfect, right?

So, I opened Windows Firewall (if you are using a different firewall product, the steps should be similar).

3

I selected Inbound Rules in the left window and then chose New Rule… from the Actions menu on the right.

4
Select Port for the type of rule you want to create, click Next, and then type in 1433 in the port field.
5
Click Next and then select to Allow the connection. Go through the rest of the wizard by clicking Next and filling in the appropriate content.

6

Again, this is not rocket science, but I hope this information can be helpful to the next person who forgets the important step of allowing inbound connections to their SQL server!

Intermittent forbidden errors (403)

After applying a new master page and related theme components, we have been receiving reports that users were being presented with 403 ‘forbidden’ errors when trying to load our intranet site. After refreshing the screen four (4) times, the page would finally load.

I checked the web server’s Application log and found that every time a user received a 403 error, there was an “Information” Web Event message logged with a source of ASP.NET and an ID of ID 1314. The body of the event included, among other information:

Event code: 4011
Event message: An unhandled access exception has occurred.


After doing research and knowing this was most likely a security issue, I came around to fixing permissions on the Bin and _app_bin folders for the IIS virtual server that was hosting my SharePoint Web Application. I added the server’s local group “users” (which includes the domain group users) to both folders with READ permissions.

After an application pool restart, there have been no more reports of 403 errors and not a single 1314 report has been shown in the Application log.