Upgrading From WSS 3.0 to Search Server Express

About a year ago, I wrote a couple of articles (here and here) that discuss the merits of using Search Server Express 2010 instead of SharePoint Foundation. It really boils down to the fact that you get more stuff, and it’s still free. As opportunities for Foundation arise, we have been installing SSE and our customers are quite pleased with the result.

I recently had the opportunity to perform an in place upgrade of a WSS 3.0 site that we had built a few years ago to Foundation, and I of course decided to use SSE instead. As it turns out, the upgrade wasn’t quite as straightforward as I had hoped.

Normally, when you perform an in place upgrade from WSS to Foundation, you first install the bits, and then run the Products and Technologies Configuration Wizard, which in turn detects the pre-existing WSS installation and offers to upgrade it. Unfortunately, this doesn’t happen with SSE. The Wizard only prompted for a new or existing Farm. 

The next step was to uninstall SSE, and to Install Foundation, once this was done, the Wizard did detect the existing installation, and properly upgraded the entire farm. Once this was done, I thought “why wait?” and I went ahead and laid down the bits for Search Server Express and then for Office Web Applications.

Everything seemed alright, but when I tried to start the services on the server, they simply weren’t there. It also wasn’t possible to create the corresponding Service Applications for either SSE or for the Office Web Applications. After much head pounding, I decided to uninstall everything, OWA, SSE, and Foundation (CAREFULLY as outlined here..), and then Install SSE alone, joining it to the Pre-existing farm.

Once that was done, everything showed up properly, and I was able to properly start the appropriate search services, and OWA services, and to create the appropriate service applications.

So as it turns out, order of operations is pretty important in this scenario. If you want to upgrade from WSS 3.0 to Search Server Express 2010 (using the in place upgrade approach), you’ll want to follow these steps:

  1. Install SharePoint Foundation 2010 on your server
  2. Run the Products Configuration Wizard, and perform the upgrade
  3. Uninstall SharePoint Foundation from the server, removing it from the farm
  4. Install Search Server Express 2010 on the Server
  5. Run the Products Configuration Wizard, and re-join the existing farm
  6. Test the site to ensure that it’s functional
  7. (optional) Install any appropriate Service Packs and/or hot fixes for SSE
  8. (optional) Run the Products Configuration Wizard to update the databases (if step 7 was performed)
  9. (optional) If desired, Install Office Web Applications, and any appropriate Service Packs for OWA
  10. Run the Products Configuration Wizard to complete the OWA installation
  11. Start all necessary services, create the necessary service applications (search is a big one….)
  12. Create a basic Search Center and configure your site collection to use it.

Hopefully this helps any other folks in the same situation.

Access Denied When Accessing Search Service Application With Search Server Express 2010

Search Server Express is an excellent alternative to straight up SharePoint Foundation. It’s also free, but it gives you the fundamental underpinnings of the full SharePoint search infrastructure, plus a few other goodies. I’ve written about this previously here and here.

If you follow best practices for SharePoint deployment, and use a separate account for installing the bits and for the Farm account, you may run into a very odd little error. After everything is set up and you try to access the search administration application, you receive an access denied error. This happens even though the account that you’re logged in as is a Farm administrator, and a site collection administrator for the Central Administration site collection. If you log in as the farm account, all is well, but the actual administrator account is denied access.

To the best of my knowledge, this happens because of some oddness related to claims authentication. SharePoint properly applies the rights of the farm account, but not the setup account.

The fix for this is to properly add the NTLM authentication account for the required user into the User Policy for the Central Administration application. Unfortunately, unlike all other applications, you cannot change the User Policy for the Central Administration application through Central Administration itself.

You can, as with many other things however, do this through PowerShell.

I have shamelessly lifted the PowerShell script below from Tore Kristiansen at the Code Project.

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

$site = new-Object Microsoft.SharePoint.SPSite("http://SitesCBA.domain.no")

$wa = $site.WebApplication

$user = "domainuser"

$policy = $wa.Policies.Add($user, $user)

$policy.PolicyRoleBindings.Add($wa.PolicyRoles.GetSpecialRole(
[Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl))

$wa.Update()

$site.Dispose()

 

In the above script, replace “SitesCBA.domain.no” with the URL of your Central Administration site, and “domainuser” with your setup user account (or any other). After using this script, your service applications should become available.

Adding PDF Icon or Creating a Site From Template triggers Prompt for Download In SharePoint 2010

In a previous article, I wrote about the fact that with Microsoft SharePoint 2010, the default behaviour for handling PDF files is to prompt for download instead of opening them directly in the browser. In it, I mentioned how to change this behaviour, both at the application level, and where necessary at the library level.

I recently ran into a case where neither approach fixed the problem. SharePoint continued to prompt for download even though the BrowserFileHandling property was set to permissive at both the application and at the library level. I registered a support call with Microsoft and was told that they’ve seen this, and were working on it, and there was no expected date for an answer.

I decided to do some further experimenting, and found that I was actually running into two different things that caused this. The environment had both, so it made troubleshooting a real treat.

1. Adding the PDF icon to the front end server causes prompting for download

It’s been standard procedure since SharePoint 2007 to manually add in the PDF icon to display PDF documents, as described here. Every time that I do so, SharePoint starts prompting for download instead of opening in the browser. I as yet have no idea why,but it’s repeatable. UPDATE – This has been solved – see below.

2. Creating a site from a custom site template causes prompting for download

With the PDF icon uninstalled,the browser behaviour is correct on all sites in the site collection. If you then create a site template from an existing site with a library, and then use that template to create a new site, you will experience the prompting behaviour on any documents saved to that library. This is NOT true for any new libraries created in the site. You can also run the PowerShell script that I previously posted to reset the properties of the libraries, and they will behave properly.

For the record, the environment that I was working on this problem with was Search Server Express 2010, which is essentially the same as SharePoint Foundation plus the Search features from SharePoint Server.

Both of these problems are quite annoying, and I suspect I’ll be updating this post as I learn more, or as I hear back from Microsoft.

UPDATE

I’ve put together a solution that can be installed on a farm and activated at the site collection level. It’s essentially an event receiver that fires whenever a new web (subsite) is created and it sets all of the lists to Permissive. It works fine for me, and for at least one customer, and I provide it to you here with no warranties express or implied…. If anyone is interested in the code, let me know, but it’s only about 5 lines.

UPDATE – OCT 15 2010

The pdf icon problem has been solved. I’ve been back and forth with Microsoft on this and we wound up exchanging DOCICON.XML files. They sent me back one that worked, and the suggestion was that I change the icon file name to pdf16.gif to accommodate it. However, I noticed that there was an additional attribute in their file, OpenControl=””. I added that to the Mapping tag for my PDF extension, did an IISReset, and the problem was solved. For the record, the complete tag will look like:

<Mapping Key=”pdf” Value=”pdf16.gif” OpenControl=””/>

With pdf16.gif being whatever the name of your pdf icon file is.

Microsoft also confirmed the problem with the custom site templates that I created the solution for above. It’ll have to do until a fix is available.

UPDATE – JAN 3 2011

Reader Christoffer von Sabsay has notified me that this bug has been fixed in the December 2010 Cumulative Update Pack for SharePoint Foundation. For a list of the fixes in this CU, and to request them, go to http://support.microsoft.com/kb/2459108. My event receiver workaround should NOT be required after applying this and you should remove it upon doing so.

Secure Store Service is Included With Search Server Express 2010

I did my first Search Server Express (SSE) 2010 installation the other day. I expected to see a new Service Application for search available, but what I did not expect to see were a few other services, in particular, the Secure Store Service.

Why do I care about this? Well, as I wrote about previously, the BCS relies on this very heavily when running in a multi server environment without Kerberos. (As an aside, Kerberos, or Cerberus is the three headed dog that guards the gates of Hades. Aptly named I think.). SharePoint Foundation 2010 does not come with this service, which pretty severely limits the value of BCS for these environments.

SSE is a free add-on to SharePoint Foundation 2010, and therefore, suddenly, there is hope! Foundation users CAN use BCS,they just need to install SSE first,and as a nice bonus, they’ll get a much stronger search engine.

How to Index PDF Files with SharePoint Foundation 2010

SharePoint uses iFilters to index its files. Filters for most common file types are included out of the box with most versions of SharePoint. The big notable exception is an iFilter for PDF files. This is because Adobe won’t let Microsoft redistribute any of their code. It’s so bad that Microsoft can’t even include a PDF icon with SharePoint, you have to go out, download it, and set it up yourself. This has been true since the early days of SharePoint.

One of the things that you must do when you configure SharePoint to index PDF files is that you must tell the indexer that PDF is a valid file type. That’s easy enough to do from within the Shared Service Provider (for 2007) or the Search Service Application (for 2010), but the free versions of SharePoint, WSS and SharePoint Foundation don’t come with these tools.

It has always been possible to do this with WSS with a little bit of registry editing (and it’s supported by Microsoft), but that’s no longer true with SharePoint Foundation. That hack just doesn’t work with it. So what’s the answer? Well, as it turns out, the solution isn’t just adequate, it’s quite a bit better. The solution is to Install Search Server Express 2010.

Search Server Express is pretty simply a (only slightly) scaled back version of the Search Service applications that you get when you install SharePoint Server 2010. They are virtually the same architecturally and you get many of the features that you get with Server 2010. You also get a few other SharePoint Service applications, most notably, the Secure Store Service. And if you’re a Foundation user,it aligns up with your licensing agreement because it’s free.

So essentially,you get a much better search engine, with more capability for free. I can’t see a down side here. You don’t already need Foundation installed to install SSE, so in the future, whenever called upon to install SharePoint Foundation, I’ll be going straight to Search Server Express.