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.

[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:


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.

[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:

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.


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).


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

Select Port for the type of rule you want to create, click Next, and then type in 1433 in the port field.
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.


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!

Cannot Connect to the Meeting: Live Meeting

Today I experienced some issues with Office Communicator 2007 R2 and Live Meeting 2007. First, Communicator was complaining about not being able to update the address book. Then, when I tried to start a meeting using Live Meeting (via the Meet Now function), I received the following error:

When I looked to find some hints to the “Live Meeting cannot connect to the meeting.” message online, all the posts were pointing to issues with trying to connect to an external meeting. I was trying to connect to my internal Office Communications Server.

I next tried to do a nslookup on the FQDN for the server and I received a reply message that it was a non-existing domain! Well, there’s your problem!

I took a look in DNS and the SIP entries for the service were all in tact, but the A record for the server in the Forward Lookup Zone was missing! I do not know why/how it was removed, but I quickly added it back and now all is well with OCS.

Office Communications Server 2007 R2 and NIC Teaming

I have been trying to install Office Communications Server (OCS) 2007 R2 Standard Edition for a few days now without success.

During the server install process (after the schema has been extended), a warning shows up in the activation logs of every role (Standard Edition Server, Web Components Server, Web Conferencing Server, Audio/Video Conferencing Server, Application Sharing Server, and Application Host).

The warning on the main Deployment Log states:

[0x03EC796D] Wizard was successful, but one or more warnings occurred during execution of the wizard. Please check the log file for more information.

The warning within each activation log states:

[0x03EC78E4] More than one DNS records are found for the pool FQDN. Please validate the pool’s DNS registration.

A note about the DNS Record Count: 3 is also in the log.

After trying for many hours to get this to work, the solution is simple, but it isn’t ‘nice’.
Office Communications Server 2007 does not support network interface controller (NIC) teaming. Sounds crazy, right? Good luck finding this little tidbit documented anywhere.

[UPDATE] I have been told (by a Microsoft rep) that Microsoft does support NIC teaming, but I haven’t found any documentation that points to the correct answer.