Short version - Check to see if you have URLScan installed on your SharePoint server and, if so, uninstall it using Add/Remove Programs from the Control Panel.
At work we have a Windows SharePoint Services 3.0 setup that usually runs pretty well without any issues. However, seemingly out of nowhere, a user discovered that the "Open in Windows Explorer" option on every list had stopped working. We hadn't done any updates recently, no changes to the server were made, but since our site isn't used that frequently (especially that functionality), there was no way I could narrow down exactly when this functionality stopped working. Here is a rundown of what we encountered with this problem -
- Windows SharePoint Services (WSS) v3.0 (SP2)
- Windows Server 2003 running IIS 6.0
- "Open in Windows Explorer" does not work. On a client machine, you would experience either 3 authentication challenges, never-ending challenges or, on the server itself, just nothing would happen - no explorer window would open, no challenges, nothing.
- Account used to attempt logins was a Domain Admin with basically full access to every network resource.
- No actual error messages displayed.
So, there wasn't much to go on. I tried a whole bunch of troubleshooting steps that I found while searching Google and nothing worked. However, I started to understand that the entire process revolves around WebDAV - something that I really didn't have too much firsthand experience troubleshooting. After a very, very long time and having to manage all of our SharePoint sites manually, I finally caved and called Microsoft support.
For about a week, a few hours per day, the tech walked me through a lot of the same steps I had already tried. We tried disabling WebDAV in IIS since that could potentially interfere with the "Open in Windows Explorer" functionality. We looked at setting some registry keys controlling authentication and we tried changing settings through the Central Administration site and the Alternate Access Mappings there. None of these troubleshooting steps worked.
At this point, I was required to run NetMon 3.4 on both the server and a workstation and acquire a network capture on both machines. This was the key to unlocking what the cause of my problems were. After looking at the captures, it was evident that something was blocking the WebDAV requests resulting in HTTP 404 errors. At this point, the Microsoft tech asked me if we had Microsoft URLScan Filter installed. I honestly had no recollection of installing it and no documentation stating as much, but low and behold there was a shortcut on my server's desktop to a URL Scan folder containing logs starting over three years ago!.
So, the solution was easy - Just uninstall URLScan from your SharePoint server! It seems that, in some instances at least, that URLScan blocks certain WebDAV communication. Hopefully, uninstalling URLScan fixes your SharePoint WebDAV Windows Explorer issues as well!
PS - Of course, once I knew the solution, I was able to find this post that basically outlines the fix posted over 7 months ago. Sigh.
SharePoint 2007 / WSS 3.0 - Fixing the "Unable to Add Selected Web Part" ... "The File is Currently Checked Out" Error
Yesterday, I had to post a YouTube video to our SharePoint WSS 3.0 intranet site. If you're not familiar with embedding a YouTube post into a SharePoint page, your best bet is to use the Content Editor Web Part. However, when I went to add the CEWP today, I was receiving the following error -
Huh? Before that, I also noticed that when I was trying to add the CEWP web part to our home page, I was able to see the content, yet no other user was able to see the same content.
If you're struggling with this error, you'r in luck because the fix is simple. Just open up SharePoint Designer, navigate to the page that is giving you the error, right click on the page and select "Undo Check Out". That's it - once you do that, try to add the CEWP and it should work. Hope this helps!
Recently, seemingly at random, our company's SharePoint sites all experienced a serious error when trying to utilize the "Export to Spreadsheet" list functionality. When users would click on "Export to Spreadsheet" everything would seem normal - users would get a prompt asking them to either Open or Save an .iqy file, (assuming you choose Open) Excel would launch, depending on the user's security they would get the macros warning and then ... error. The error reads -
"Excel cannot connect to SharePoint list."
That's pretty much it - no details, no stack trace, no real logging, no event log notification - nothing. With pretty much no information to go on and nothing in our Change Management Log for our SharePoint server farm, I started troubleshooting this issue mainly in the dark. Turning to the search engines, I definitely didn't find much information on this error and even less when taking into account we were running Windows SharePoint Services (WSS) v3. I tried a few of the fixes I found online with no success. At this point I opened up a case using my MSDN incidents and started working with Microsoft. The MSFT tech had me check some of the basic issues such as what authentication type my site was using (Kerberos vs. NTLM), some user permissions, SQL security, etc. However, he finally found the issue when we opened up the web.config file located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI. In this web.config file, there was the following entry -
.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35" priority="1" group="0" />
According to the MSFT tech, this entry is due to the fact that at some point Web Services Enhancements (WSE) 2.0 was installed on the server (although, I really have no recollection of this ever occurring - maybe this was done through a patch?). By removing this line from the web.config specified above and performing an iisreset /noforce, I then tried exporting to Excel and the functionality was restored. Hopefully, if you are encountering this article, I can save you a support call to Microsoft.
Recently, a client wondered how they could add an external document to a document library that existed on their Intranet. The problem with just saving their document and uploading it to the Intranet is a matter of document "freshness" as changes are made by the document owner. Therefore, creating an external link to that document is a much better solution. However, adding a link to a document library would seem difficult on its face.
To get around this issue, I took the following steps -
1. Create a TXT file.
2. Open the TXT file and add the following HTML -
3. Save the file as a HTML file.
4. Upload to your Document Library.
While extremely unrecommended, sometimes you just want to fix a problem quickly and without jumping through a ton of hoops using the SharePoint SDK and writing a small C# program. I recently encountered this when I needed to delete a Folder from a whole bunch of Document Libraries across hundreds of sites. Making sure that I checked to see if the folder was there first, calling the right Web, calling the right List, getting the right Folder GUID, etc. all seemed like a lot of work for a simple SQL statement so I cheated.
Folders all stored in the AllUserData table with a tp_ContentType = 'Folder'. I was able to write a simple UPDATE statement like the following to delete the unwanted folder across the sites I wanted -
SET tp_DeleteTransactionID = 0x00000010
WHERE tp_ContentType = 'Folder' and ...
Quick and very dirty. Not recommended, kids don't try this at home.
Just a FYI to the 3 of you reading this site (Hi Mom and Dad!), I made an update to the Recreating the SharePoint Quick Launch story I posted back in February. I made some code fixes that were mainly introduced with the release of the 40 Free WSS Application Templates made by Microsoft.
Hope the bug fixes help!
When working with SharePoint v3 list data, it's important to understand the data structure used to store list items. List data is stored in the AllUserData table and the name should be your first indication that you might run into a problem if trying to pull or manipulate data stored in this table. Why? Well, "all" user data is stored in that table including deleted data and you will need to know how to filter out deleted items and that is where the tp_DeleteTransactionID column comes into focus.
The tp_DeleteTransactionID column is a varbinary field so you cannot readily read the contents of that column in SQL Server Enterprise Manager. This coulmn acts as a "deleted flag" and you will need to be able to know what items you have removed from your list, but you forgot to remove from your Recycle Bin. List items that you delete from your list, but that remain in your Recycle Bin will have the value of the tp_DeleteTransactionID column updated from the default value of 0x. Once you remove the items from your Recycle Bin, the item's corresponding rows will be deleted from the AllUserData, but until you do so those item's rows will remain in the AllUserData table.
So, if you want to filter out deleted content for the purpose of data manipulation or transformation, but you don't want to have to worry that the user has remembered to empty the Recycle Bin, add the following WHERE clause to your SQL statements -
Notice, that the value 0x is not surrounded by value defining apostrophes since the value is not a true string, numeric, date, etc. value, but a hex representation for the varbinary field.
SharePoint v3: Exception of type Microsoft.Sharepoint.WebPartPages.WebPartUserException was thrown Error
Today, I encountered an error that I wasn't immediately sure how to fix while creating a new web part. After uploading the .DWP file to the web part gallery, I attempted to add the web part to a recently created web part page. Even though I had a Try/Catch/Finally wrapper around my code, I received a browser alert that had the following error:
After a very quick search for that error on Google's main search index and Google Groups, I found zero results. Then, I remembered that I didn't make the necessary corrections to the .DWP file - in particular, I left the Assembly field blank. After adding the correct assembly name, I saved the file, deleted the previously uploaded DWP file, re-uploaded the new DWP file and was able to successfuly add the web part. Success!
Anyone who has worked with SharePoint extensively knows that when troubleshooting SharePoint errors you will be confornted with some of the most meaningless, generic error messages of any major application around. However, thanks to articles like this (which is where I first read this tip), SharePoint developers and administrators can turn on more descriptive, "friendly" error messages by making two changes to your web applications web.config file -
- Set customErrors=off
- Set CallStack="true"
Making these two changes in your development environment will really help your SharePoint developers and admins troubleshoot technical issues.
UPDATE: 2009 June 17th - Please see the comment by David in the comments section. His fix is the best fix I have seen for this problem.
If you see any improvements that I can make, let me know by leaving me a comment. Hope this helps someone.
- Version 1.2 - (2009 June 17) - Much better solution posted in comments by user David.
- Version 1.1 - (2007 May 2) - Bug fixes which include:
- Applying Quick Launch logic that is used in the SharePoint WSS 40 Free Application templates.
- Wrapping data retreived from the database and other sources in System.Web.HttpUtility.UrlPathEncode() to prepare for URL formation and usage.
- Colorized the comments (I'm looking for a Drupal module to automatically do this for me)
- Version 1.0 - (2007 Feb 7) - Original Article on recreating the SharePoint v3 Quick Launch through a Web Part