Blob Cache for SharePoint 2010

On a SharePoint Web Front End you can turn on the BLOB cache which allows the webserver to cache certain file types on the front end without having to go back to the SQL server.

The setting for doing this is in the web.config file of the web application. For example to activate it on the cp Portal I used the following configuration:

<BlobCache location="C:\BlobCache\14" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="true" />

 

The line was already in the web.config file but I had to change enabled to “true” and also create the folder c:\BlobCache

The users also have to be changed a la: http://technet.microsoft.com/en-us/library/ff758656.aspx

SharePoint 2010 not crawling some sites

I recently came across an issue where SharePoint was not indexing some Site Collections and the crawl logs were showing the following with reference to the problematic Site Collection:

"The SharePoint item being crawled returned an error when attempting to download the item"

It turns out the start page of the root site contained a search result webpart which was causing the crawler to abort the rest of the crawl.

This issue has since been fixed in a hotfix. Install the latest CU to solve the issue.

Central Management of Content Types with SharePoint 2010

A new feature of SharePoint 2010 allows you to publish your content types from one central hub to Site Collections that choose to subscribe to them.

The first thing you need to do is to to define the location of your hub. You will find this in the properties of the managed metadata service at the bottom:

Then in the properties of the managed metadata service connection you need to tell it to “consume content types from the content type gallery”:

The site collections that are then supposed to use the content type hub will need to activate the site collection feature “Content Type Syndication Hub”.

In order for content types to be published you need to change the setting under “Manage Publishing for this Content Type”

Add Traffic Light indicators to a Yes/No column in a custom SharePoint list

I needed to create a list which would show a Yes/No column as traffic lights. Since SharePoint already has the necessary images from KPI lists I decided to use them.

Unfortunately, this isn’t an option OOTB so I decided to generate the URL to the KPI gifs using a calculated column. The name of the Yes/No column was “Approved” so I created the following calculated column:

="<div><img src='/_layouts/images/KPIDefault-"&IF([Approved]=TRUE,0,2)&".gif'/></div>"

For those of you using various regional versions of SharePoint, be careful with the commas after “TRUE”. You might need to change them to semi-colons.

 

The problem with the result from the above calculated column is that it is simply displayed as text. While trying to get it to display as an image, I stumbled across this site, and in particular a script which does exactly that. The script can be downloaded from here. I have added it below for the sake of simplicity.

This script needs to be added to the bottom of the page using the Content Editor WebPart (add it by using the source editor not the Rich Text editor).

 

<script type="text/javascript">
/*
Text to HTML Lite - version 2.1.1
Questions and comments: Christophe@PathToSharePoint.com
*/

function TextToHTML(NodeSet, HTMLregexp) {
var CellContent = "";
var i=0;
while (i < NodeSet.length){
try {
CellContent = NodeSet[i].innerText || NodeSet[i].textContent;
if (HTMLregexp.test(CellContent)) {NodeSet[i].innerHTML = CellContent;}
}
catch(err){}
i=i+1;
}
}

// Calendar views
var regexpA = new RegExp("\\s*<([a-zA-Z]*)(.|\\s)*/\\1?>\\s*");
TextToHTML(document.getElementsByTagName("a"),regexpA);

// List views
var regexpTD = new RegExp("^\\s*<([a-zA-Z]*)(.|\\s)*/\\1?>\\s*$");
TextToHTML(document.getElementsByTagName("TD"),regexpTD);

</script>

Showing active SharePoint connections

It can be very useful to see how many active connections you have on your SharePoint server. This can be easily done using PowerShell to look at the IIS performance counters.

As is mostly the case with scripting, somebody has already done a much better job than I ever could. Here is a script which creates a PowerShell function Get-WebServiceConnections.

I created a PowerShell script called CurrentConnections.ps1 with the following content and can now run it whenever needed:

function Get-WebServiceConnections()
{
  $results = @{}
  $perfmon = new-object System.Diagnostics.PerformanceCounter
  $perfmon.CategoryName = "Web Service"
  $perfmon.CounterName = "Current Connections"

  $cat = new-object System.Diagnostics.PerformanceCounterCategory("Web Service")
  $instances = $cat.GetInstanceNames()

  foreach ($instance in $instances)
  {
    $perfmon.InstanceName = $instance
    $results.Add($instance, $perfmon.NextValue())
  }
  write-output $results
}

Get-WebServiceConnections

Displaying the Quick Launch in Web Part Pages

If you create a web part page in MOSS 2007 it won’t show the Quick Launch on the left side of the page.

To work around this open the page in SPD and remove the following code:

<asp:Content ContentPlaceHolderId="PlaceHolderLeftNavBar" runat="server"></asp:Content>

 

Unfortunately, the Quick Launch won’t be the correct width so in order for that to be displayed correctly you need to remove these additional lines of code:

<asp:Content ContentPlaceHolderId="PlaceHolderPageImage" runat="server"></asp:Content>
<asp:Content ContentPlaceHolderId="PlaceHolderNavSpacer" runat="server"></asp:Content>

“Access is denied” error when crawling content with SharePoint or browsing local server

When crawling your local SharePoint site you may receive the following error message:

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)

This can happen even if the account has the necessary permissions to crawl the site. This error is caused by what is know as the “loopback check”. The loopback check is basically a security “feature” which won’t allow a local IIS website to be accessed using a FQDN. This prevents an attack from pretending to be local thus bypassing certain restrictions.

Unfortunately, it also prevents your crawler from accessing local sites if they are using a FQDN.

Microsoft offers two workarounds here. You can either turn off this behaviour completely (not recommended) or you can exclude your site from this check. Here is method 2 from the above link:

1. Set the DisableStrictNameChecking registry entry to 1.
• Locate and click the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

• On the Edit menu, click Add Value, and then add the following registry value:

  Value name: DisableStrictNameChecking
  Data type: REG_DWORD
  Radix: Decimal
  Value: 1

2. In Registry Editor, locate and then click the following registry key:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. Type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
7. Quit Registry Editor, and then restart the IISAdmin service.

Windows Explorer Problems with Office SharePoint Server 2007 on Windows Server 2008 R2

I was installing MOSS 2007 on Windows 2008 R2 recently and the installation went very smoothly. You basically create a slipstreamed installation source of MOSS with SP2 and run it like you would any other install – Google it – there are plenty of how-to's out there.

Everything was running fine until I tried to open a document library in Windows Explorer using “Actions”-“Open with Windows Explorer”. The browser just didn’t react, neither did Windows Explorer.

It turns out I had installed the WebDAV that comes with IIS and the WebDAV that comes with SharePoint didn’t like that one bit. Using the Server Manager I removed WebDAV from the IIS features, bounced the server and all was well.

SharePoint 2007 SP2 Problems

Like with most service packs, I like to run tests before installing. If the service pack is for a mission critical application such as Exchange or SharePoint I make it a point to clone my environment and run the tests on a copy of my production system.

The SP2 service packs for SharePoint 2007 came out several weeks ago so it was time to test everything. I basically recreated my domain, the web front end and the SQL DBs for my main SharePoint installation – it’s always good disaster recovery practice, in any case :). The environment was (thankfully) 100% virtual so I could work with snapshots.

I started with the WSS update which during step 8 of 9 in the configuration wizard died on me with a link to the log. In the log I found the error:

“The B2B upgrader timer job failed”

There was lots of info on Google but nothing which helped. Since it was 100% virtual I could return to the original state after every failed attempt and try something different. I tried every suggestion I could find but no amount of stopping services, removing content DBs or disabling solutions helped.

Of course, the answer ended up being a lot less complicated than I had thought. I had an old web application which I had used for testing something a long time ago and, naturally, I hadn’t reproduced the content DBs when I was building my test environment. I deleted the old web application, retried the update and it ran like a dream.

Happy days!

Forefront “Exceedingly compressed size” error

When uploading a compressed file to SharePoint or sending it via email (Exchange), users were getting the error “Exceedingly compressed size”.

It seems that Forefront will block any compressed file that has a file larger than 20MB. Unfortunately, this setting can only be changed in the registry. I found the following newsgroup entry on the subject:

The Exceedingly compressed size can be controlled by a registry key called MaxCompressedArchivedFileSize.
If any one object within the zip file has a COMPRESSED size of over the MaxCompressedArchivedFileSize (which is a default of approx
20MB) then Forefront will delete this file. The reason this was done was to prevent a denial of service attack where Antigen would be scanning an infinitely large file. The incident that you will see for this would be an "Exceedingly compressed size virus”.
If this is the reason why a message is getting caught you can do the following:

• In the registry go to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\SharePoint or (Exchange) Server
• Add a DWORD Key of:  MaxCompressedArchivedFileSize (equaling 40,000,000)
• Restart FSCController service

This is about 40 MB. This will allow the zip file itself to be about 40 MB before Forefront will take action on it.

Uploading larger files to SharePoint (part 2)

After making the changes explained here I was able to upload larger files due to the IIS connection timing out. However, I ran into a similar problem a few days ago when trying to upload a 30 MB file to a Document Library and the previous solution didn’t seem to help.

My research eventually brought me to this Knowledge Base article. It seems that IIS 7 on Windows Server 2008 has a file size limit of 28 MB.

I’m sure Microsoft had a really good reason for adding these limits to their newest web server but I have been unable to find one. Would it be too much to ask for the SharePoint configuration tools to make these changes when it is creating the new site in the first place?

So I added the following to the web.config file in the virtual server folder and all was well:

<system.webServer>
    <security>
        <requestFiltering>
            <requestLimits maxAllowedContentLength="52428800"/>
        </requestFiltering>
    </security>
</system.webServer>

I had to add it to the end of the file (just before the </configuration> tag). Adding it to the beginning of the file caused an “Internal Server Error”.

Taking ownership of a SharePoint site

The farm admins no longer automatically have access to all SharePoint sites. If you don't have access you can take ownership or take a role of "Secondary site administrator" by using this command:

 

stsadm -o siteowner -url http://sharepoint.test.com/sites/[sitename] -ownerlogin [DOMAIN\netID]

use the -secondarylogin switch to take ownership of the “Secondary site administrator” role.

Problems uploading larger files to SharePoint

Clients were getting an "unknown error" message when trying to upload larger files (> 10MB) remotely. It seems that IIS was timing out after a couple of minutes.

Making the changes to web.config detailed here solved the problem

Manually starting a crawl in WSS

In MOSS it is possible to manually start a crawl by going to the settings of the content source in the SSP and choosing a full or incremental crawl in the drop down menu.

There is no equivalent in WSS when using the GUI. To start a crawl in WSS run the following command:

Stsadm -o spsearch -action fullcrawlstart