SharePoint 2010 Updates and 503 Error

Today I updated a SharePoint Server 2010 test virtual machine with service pack 1 (SP1; Foundation and Server) and the August 2011 cumulative updates for SharePoint Foundation and SharePoint Server. I ran the SharePoint configuration wizard after installing all the updates.

When I rebooted the server (suggested when encountering the User Profile sync problem after applying the patches) and tried to open one of the team sites, I received a 503 Service Unavailable error (as shown in the picture below).

Service Unavailable – HTTP Error 503. The service is unavailable.ServiceUnavailable503

Once I got over the “what did I do??!?” moment, I of course recognized this as an IIS error, not a SharePoint error. I opened the Internet Information Services (IIS) Manager MMC and noticed that none of the SharePoint Application Pools were running. After starting all the needed Application Pools, everything is back to normal.

Renaming a document – ”The Specified name is already in use”

A SharePoint document library in some ways acts similar to a folder when storing documents on your local computer. For example, you can’t have two documents with the same name within a document library (or folder, if you are using folders). If you try to rename a document and give it the same name as another document in the library, you will be given this wonderful error (in SharePoint 2007):
[Server Error in ‘/’ Application. The specified name is already in use. A document cannot have the same name as another document or folder in this library or folder. Click your browser’s Back button, and type a new name.]

This makes perfect sense, unless the “existing file” really isn’t there. I recently ran into an issue where a user tried multiple times to upload a document (PEBKAC) and finally, they received the error that they couldn’t add the document with the current name because it already existed. Somehow, the document they were uploading and checking-in was removed from the database, but SharePoint thought it was still there. So, they couldn’t upload a document or rename a document with that same name.
When I tried to upload a document to the library, I received the error below that says the document (which wasn’t really there) was checked-out to the user that was uploading the document from before.

[Error. The {filename} is checked out or locked for editing by {username}]
Again, since the document really wasn’t there, it was a bit frustrating, but this last error did give me insight into how to resolve the issue. The fix in this case was simple enough. After opening the document library’s settings, I opened the Manage checked out files page (selected from the Permissions and Management column).


Since SharePoint did believe the document was still there, I am given the wonderful opportunity to “Take Ownership” of the checked-out document.


After selecting the checkbox next to the document and clicking the Take Ownership of Selection button, the document was then checked-out to me. I then was able to upload a document with the same name (the library had versioning turned on, so I selected for it to add another version).

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!

SharePoint Datasheet View and Office 2010 64-bit

If you have installed the 64-bit new version of Microsoft Office, Office 2010, then you will most likely see the following message when trying to edit a SharePoint list using the Edit in datasheet function:

The list cannot be displayed in Datasheet view for one or more of the following reasons:

– A datasheet component compatible with Windows SharePoint Services is not installed.

– Your Web browser does not support ActiveX controls

– Support for AxtiveX controls is disabled


The issue revolves around the fact that 64-bit versions of Office 2010 do not ship with the 32-bit Activex control that would make the datasheet option work with Internet Explorer.
There are ways to make this work, and the usual suggestion is to find a copy of an Office 2007 product and either install it (such as SharePoint Designer 2007) or just choose to install the Windows SharePoint Services components of the product. This works, but I don’t really want to go to that much trouble.
Another solution, and the one that I employed, is to install the 2007 Office System Driver: Data Connectivity Components. After installing the Components, go back to the menu and the datasheet option will work great.

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.

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.

Access Denied Message When Trying to Edit Properties of a List or Library Item

I created a new Office SharePoint Server 2007 Web Application a few months back and moved our existing sites around to create a new structure in the new Web Application. I did this to move all the project sites under one ‘roof’ and get things more organized. At the time, we were a little behind the curve on patching SharePoint. We were on version, which is SP1 plus the August 2008 Cumulative update.

When new sites were created though, users were unable to edit the properties of anything they added to the site, whether a document or list item. As the SharePoint farm administrator, I received the Access Denied message as well when trying to edit the properties. The Access Denied message was also received when attempts were made to edit the properties of items within newly created Lists or Libraries on existing sites. Items could be added and deleted, but not edited.

While doing some research (see Technet Forums and Odole blog), I ran across several sites saying this was a known issue that is fixed in the February 2009 Cumulative update (for MOSS and WSS 3.0). I was told by Microsoft support after contacting them (see below) that the root cause is ACL corruption when the sites are moved.

After installing Service Pack 2 (for MOSS and WSS 3.0), and the latest Cumulative update (February 2010), the issue was not resolved for existing sites; but I expected this behavior. I contacted Microsoft support to obtain an executable (not publically available) that would fix the existing sites. After running the executable, the existing sites were all fixed and when I created a new site, it did not have the issue.

A screenshot of the fix program in action: