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!

Exchange System Attendant Errors

I have recently been setting up a virtual network to get more experience in upgrading the applications listed below in the same environment. I am utilizing the following Microsoft products:

Windows Server 2008 domain controller (version: Server Core)
Windows Server 2003 application servers (possible upgrade to Server 2008 in the future)
Exchange (version: 2003 upgrading to 2007)
Live Communications Server (version: 2003 upgrading to OCS 2007)
Windows SharePoint Services (version: 2.0 upgrading to 3.0)
SharePoint Portal Server (version: 2003 upgrading to MOSS 2007)
SQL (version: 2005 upgrading to 2008)

The DC has two NICs, one is Local only and the second has external access. The first Application server has one NIC, local only.

Right now I am at the point where I have my DC setup and I have finished installing Exchange 2003 on the first Application server that will host LCS 2003 as well. However, after I rebooted, I encountered the following errors within the Windows Application Log:

Event ID: 1005
Source: MSExchangeSA
Type: Error
Body: Unexpected error The logon attempt failed ID no: 8009030c Microsoft Exchange System Attendant occurred.

Event ID: 1004
Source: MSExchangeSA
Type: Error
Body: Microsoft Exchange System Attendant failed to start

Event ID: 1005
Source: MSExchangeSA
Type: Error
Body: Unexpected error The clocks on the client and server machines are skewed. ID no: 80090324 Microsoft Exchange System Attendant occurred

Also there is a Kerberos (Event ID: 5) error in the Windows System log.

My first thought was that due to the 1005 errors, the Application server wasn’t getting its time from the DC. Since it was a Server Core implementation, I did miss something (oops!): I did not start the w32time service. So, I entered the following commands:
>net start w32time
>sc config w32time start= auto

Now that the service was started, I did a reboot of the Application server just to make sure everything was working well. Same errors.

Since the error stated the times were “skewed”, I checked the time on the DC (by just typing “time” at the cmd prompt) and Application server….they were the same. What now?
I tried a manual time sync on the Application server using the w32tm command. This told me that the time between the server and the DC (its time authority) was exactly 2 hours off. That raised a flag! Timezone!

I checked the timezone for the Application server and it was correct. I went to the DC and at the prompt I typed >control timedate.cpl and one of the only remaining GUIs in Server Core gave me my answer….the DC was using the wrong timezone.

I updated the timezone, rebooted the Application server, and the System Attendant started without any problems.

Now on to installing LCS.