Ran into an issue today with trying to import an Excel 2003 spreadsheet into a SharePoint list.  SharePoint would load Excel, then you select the cells in Excel that you want to import, you click Import and Excel responds with "Cannot connect to the server at this time."  After a long while searching for a solution, I came across the following link:

WSS FAQ - I cannot import from Excel 2003 to WSS. What’s…

Basically the solution was 2 workarounds:

a.) Import the spreadsheet into a root site, then create a list template and use that to create the list within a subsite.

or

b.) Use Excel’s List Publishing feature to publish directly to the subsite.

I tested both options and they each worked equally well, I ultimately went with option B as it seemed a cleaner solution.

I recently ran into an issue where editing content within a Content Editor web part would cause the following message to appear in the Publishing Toolbar:

The page you are attempting to save has been modified by another user since you began editing

At that point you would have to select “Save and Overwrite Changes” in order to proceed. This would happen any time that you edited a page, provided that you first selected “Edit Page” from the Site Actions menu. If you simply clicked the drop-down for the web part and selected “Modify Shared Web Part”, this problem would not appear.

After spending a significant amount of time troubleshooting the issue it was narrowed down to one of the customizations that was made to the master page. The Site Actions menu had been relocated to under the Quick Links menu.

I went back to the default.master page that ships stock with MOSS to try to reproduce the issue. Sure enough, if I put the Site Actions menu after the Publishing Console, I would receive the “page has been modified” error. If I put that Site Actions menu prior to the Publishing Console, everything would work fine.

After a little more than 5 hours troubleshooting the issue, it was determined that simply relocating the Site Actions menu to the top of the page was the simplest solution, however I would like to understand why it cannot follow the Publishing Console, or what needs to be done so it can.

Ran into an issue today with installing the October 9th SharePoint Security Patch. During the content database upgrade I received several errors that certain sites and webs were missing. This is due to the staging content database being migrated from a development content database, and there are slight differences in the configuration databases between the two environments. In any event, I found the following posting from Cory Burns that took care of the issue:

How to Clean Orphans from your environment.

(Be smart have backups prior whenever you are performing maintenance on your farm, use suggestions at your own risk.)

Configuration Orphans: These are the orphans that reside in your configuration database but have no child counterpart (contentDB entry). Cleaning these are the easiest of all the orphans. Simply detach the content database from your farm that was included in the result set and reattach it. This will refresh the sitelist that is tied to that content database and will remove the stale entry.

Sharepoint Tips and Tricks : Sharepoint Orphans Explained

Follow along:

1. Create a new site template from SharePoint Designer.  Doesn’t really matter what the site template is for or what options you choose (based on my experience).
2. Go into SharePoint and create a new site based on the new custom Site Template.
3. Note that your top navigation bar (the global navigation) should now have a “Home” tab, and an “Error” tab.
4. Click refresh.
5. Your top navigation bar now appears as normal!

I’ll chalk this one up as a “feature”.

One of our SharePoint servers at work was updated with the most recent round of security patches the other day.  Unfortunately, the result of this update was the inability to login to the SharePoint Portal from the server, and the search crawler not being able to access the site.

After some significant research on the matter I came across http://support.microsoft.com/kb/896861 which indicates that an IIS website that is using Integrated Windows Authentication and the URL is different from the computer name, will result in a 401.1 error.  The fix is to add the other names of the computer into a registry key and restart IIS.  After following the instructions in the knowledge base article I was able to login to the site from the server, and the search crawler was once again able to crawl the content.