Explorer View versus the Large Document Library


Recently, I came across the error below when attempting to open a large document library in Explorer View :

Some/SharePoint/Folder is not accessible.  You might not have permission to use this network resource. Contact that administrator of this server to find out if you have access permissions

Folder is not accessible.  You might not have permission to use this network resource. Contact that administrator of this server to find out if you have access permissions

Seeing as I am the administrator of the server, the site collection, the web application and the entire farm itself, I think I pass the permissions test.  It turns out that the real culprit has absolutely nothing to do permissions in any way.

Click to read the full post

Bizarre Problem Using a Custom User Control as a Delegate


I was creating what I thought was a very simply custom user control to be deployed as a delegate in order to enable custom analytics on a SharePoint site.  Everything came together quickly and I deployed the solution via Visual Studio, reloaded the site but my custom control was nowhere to be found.

The custom control’s ASCX file is deployed to a subfolder of the CONTROLTEMPLATES folder as per best practices but no matter what I did the control would not load.  The ULS logs showed the theoretically simple “User control “~\_controltemplates\Analytics\FooterCalls.ascx” is not in safe control list.”.  I rechecked everything related to SafeControls, directories, features, activation and deployment but everything was as it should be.

It turned out that the problem had nothing to do with SafeControls but was actually in my Elements.xml file where I was activating the control as a delegate.  The line that was causing the issue was:

<control id="FormFooter" sequence="110" controlsrc="~\_controltemplates\Analytics\FooterCalls.ascx" />

This particular portion of SharePoint is apparently very sensitive to the direction of the slashes.  Changing them to forward slashes fixed the problem.

<control id="FormFooter" sequence="110" controlsrc="~/_controltemplates/Analytics/FooterCalls.ascx" />

Hopefully this will save someone the hours I spent tracking this less than obvious fix down.

SharePoint Updates and Service Pack links


I’ve been looking for official links to all SharePoint service pack and version history information for some time and have only been able to find various blogs out there, none of which are updated regularly.  Fortunately, Microsoft actually does have official pages for updates and service packs.  Here are the links (mostly so I don’t lose them again 😉 )

Official Microsoft Pages

There is also an RSS Feed for updates to all office products that includes all version of SharePoint, among other things.

Microsoft also has pages that show all of the specific version numbers for SharePoint by Product/Service Pack/Cumulative Update and, best of all, they are current as of this writing – including the August 2013 Cumulative Update.

Hopefully these will help more people than just me as these official pages were never near the top of my Google searches for any SharePoint topic and were hard to find if you weren’t searching on just the right keywords.

 

Update 09-Sep-2013 – Added links for SharePoint 2013 and revised text to reflect the changes

One More Reason to Love ULS Viewer


If you do any work with SharePoint then you probably already know about the incredibly wonderful tool that Microsoft gave us called ULS Viewer.  This tool allows you to watch and filter your SharePoint logs in real-time or after-the-fact so that you can find key events.

Apparently they added something else in there to be grateful for – ‘New Page By This Item’.  Simply right-click on one of the entries in the list, select that option and you are presented with a dialog like the one below. 

ulsfilters

Make your selection for your filter, click ok and now you have a new tab based on that selection.  If you are filtering on a past event, make sure to uncheck the ‘Restart filtering’ option so that it will pull from the current log instead of starting fresh.

Why is this so wonderful?  Well, if you are doing a lot of real-time monitoring of the logs, you know how much noise there is in there, making finding critical information difficult as things scroll by so fast.  So, you set up filters (usually a lot of them) to cut down on the noise.  Normally, when you filter for something, i.e. a Correlation ID, you have to scrap all of your live filters so that you can see all of the entries associated with the ID.  Using this method however, the tab that you are using for live monitoring continues normally but now you have a new tab that lists everything associated with just that ID.

Deleting Orphan Template Files from SharePoint 2007 for Upgrade to 2010


I’ve been working on knocking out some issues from the Pre-Upgrade Check Report in order to get ready for our upgrade to SharePoint 2010 and recently hit one heck of a snag where certain artifacts that were created way back in 2003 were somehow still being referenced but not actually used anywhere in 2007.  These items never existed in the 2007 file system and were certainly not visible in any way from the UI.

The items appeared under the “Missing server file or server configuration issues” section of the report under the specific title of “The following setup file(s) are referenced by the content, but they are not installed on the web server”.  They were part of old Site Templates that were fortunately all named starting with “STSFA”.  To find out where SharePoint thought these items were required diving into the content database (Sorry, but the additional data Microsoft provides for these errors is close to useless)  the SQL used is below but the fields of concern are DirName and LeafName:

select * from AllDocs with (nolock)
    where SetupPath like 'SiteTemplates\STSFA%' 
    order by DirName

In my case, I had the following URLs that were being kicked out – “/RealFolder/03folder/default.aspx”. RealFolder exists (obviously) but 03Folder does not, yet SharePoint claimed it did on the Pre-Upgrade report.

It turns out that these items were in a state where, depending on how you looked at them, they were either orphaned or were not orphaned.  Go ahead, put on your Kenobi robe on and wrap your brain around that, I’ll wait.  Back?  Ok, good.  Perhaps a better term for these types of items might be “disowned” rather than orphaned.

After some digging in the Object Model, it turned out that if you use certain methods to access the item, like GetFile() or GetFolder() that it could see the items but it only returns a subset of the data that SharePoint has about the object. The objects returned from these methods always had several properties, including ParentWeb listed as empty. When I attempted to call .Delete() on the item, it would throw the ever popular “Object or reference not set…” exception.

The PowerShell below is a summary of how I got past that issue and it includes the comments as to why the steps are there.  Yes, I could have written this as a C# console application as well, but I wanted to keep it in PowerShell so that the other Admins would know exactly what the script was doing.

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[Microsoft.SharePoint.SPSite]$site = [Microsoft.SharePoint.SPSite]("http://SiteUrlGoesHere/")
$fileUrl = "http://SiteUrlGoesHere/RealFolder/03Folder/default.aspx"

#get a handle to the web that thinks it contains the orphan
[Microsoft.SharePoint.SPWeb]$parentWeb = $site.OpenWeb($fileUrl, $false)

#Get a handle to the object itself.  
#for some reason, this call brings back way more information than GetFile(), 
#not the least of which is the Guid to the actual object $tempFile = $parentWeb.GetObject($fileUrl) #use the Guid to get the real object [Microsoft.SharePoint.SPFile]$oldFile = $parentWeb.GetFile($tempFile.UniqueId) #Now make all your dreams come true #oldFile.Delete() #but don't forget to clean house $parentWeb.Dispose()

I tried about 7 variations on the above method, including trying to open the items from the root of the site, using GetFile() directly, etc..  This was the only version I tested that actually deleted the items from the SharePoint database. 

The best part about this is that the update is done completely via the Object Model so it is a fully supported way to cleanup these types of orphaned files.