Problems with CheckOut in SharePoint 2007

Last week I installed WSS 2007 on a server for a client and ran into an odd issue with checkouts under certain circumstances. Kudos to my coworker for ultimately figuring it out. I was on the right track, but not quite there yet. I wanted to document it since the GoogleOracle didn’t find any results that quite met my criteria. It seems safe to assume that under these conditions, the resolution would have worked for both MOSS and WSS.

The conditions & behavior:

  • When accessing the portal from IE on the server directly, everything worked fine.
  • When accessing the portal from IE on my computer connected over the client’s VPN, I’m unable to checkout files, or even cancel checkouts. I would receive the error:
    Object reference not set o an instance of an object.
  • Oddly enough, when accessing the portal from IE on my computer and checkout is set to be required, I’m unable to perform actions like “Edit in Microsoft Word”. I would receive the error:
    The document could not be opened for editing. A Windows SharePoint Services compatible application could not be found to edit the document.
  • Creating new Doc Libraries & testing there made no difference – even if created within a different site on the same portal.
  • Requiring checkout or not made no difference on checkout behavior.
  • Filetype made no difference. Tested with MS Project, MS Word, PDF, and generic text files.
  • If I checked out a file in IE on the server itself, I could checkin the file from my local IE – but not cancel the checkout..

Search results gave me quite a few options to choose from, but nothing that directly solved my problem. The potential issues ranged from permissions, to no local drafts folder, to something to do with Office 2007 SP2 installed on your local machine, DNS, configuration of ISA Server in conjunction with AAM…

The fix:
Ultimately the issue stemmed from another service on port 80. This service was the primary reason for the server in the first place, and the port # could not be changed. This service was not managed by IIS, and since there was no SSL cert for SharePoint to use the SharePoint web app just needed to be configured on an alternate port in order to work.

The url was configured as http://servername:81 during the install and everything appeared to be working just fine initially. Apparently the AAM needed this custom port number specified or it would result in this odd behavior.

Most Alternate Access Mappings howtos and troubleshooting resources don’t comment about custom port numbers – so hopefully this will be of use to someone out there.

No Responses

There are no comments.

Comments are closed.

For questions and feedback on this entry, send me an email.