We've been doing a fair bit of research lately on how better to deal with sessions on a forms-based authentication site.  By default SharePoint creates a fixed 10 hour session using a permanent cookie that persists beyond the browser session.  This means that even if you close all your browser windows and re-open it, you session is persisted and you are still logged in.  The only way to logout is to explicitly do so.

While session persistence has some benefits, particularly around single sign-on and Office integration (you don't need to re-athenticate as you launch Word, Excel, PowerPoint, etc. from SharePoint), it has some drawbacks from a security perspective.  If your Extranet is more about providing a secure web experience than Office integration, you probably don't want the persistent session.  Thankfully there is an easy solution to the session persistence, in the form of a number of PowerShell  commands we'll get to in a minute.

The other part of the problem is the 10 hour session.  Again this is convenient, but not neccessarily best practice for all secure Extranets.  You can shorten the session, but what we found was that it didn't slide.  What this means is if you shorten it to 10 minutes, at 10 minutes your session will expire and you'll be force to re-authenticate, even if you were constantly using the site throughout those 10 minutes.  What we wanted was for the session to expire after 10 minutes of inactivity.

I'm sure many people have already installed SP1, but I thouoght it would be a good idea to put the file locations and steps down in one place, if only for our staff and customers to be able to refer to.  Bear in mind that these steps are for simple installations, typically with just a single web front end and a separate SQL Server.

As with any update, this should be tested prior to applying to a production system.  These updates cannot be backed out, and they update not only the binaries on the disk, but also the structue and content of the content databases themselves.

Last night was a packed house at the TSPUG.  As promised I've uploaded TSPUG Presentation 2010-12-15.  I'd still like to add more to it, and may even repeat the session and record it, so check back for updates.

So we've had SP2010 Beta 2 installed for about a week now, and it's time to get our site upgrade into it again.  We've got a seminar on web content management (WCM) in SharePoint 2010 next week, and having an upgraded version of our site and the Heart and Stroke Foundation of Ontario (HSFO) done for the presentation is a big part of it.

So it was time to look back on my previous blog posts on upgrading to SP2010, and figure out how to do it again.  For those of you that read my SharePoint 2010 Upgrade post back in October, you'll know that I'm a big fan of the content database migration approach.

To start with, I needed to get access to the SQL 2008 Express installation on the standalone installation that we did for Beta 2.  Now I know that we should do a full farm installation, but to start with this seemed easier.  However there are no management tools for SQL installed with SQL Express, so I had some challenges.

I got the email from Microsoft that the Microsoft Office 2010 Beta is now available.  This is an early release for members of the Technical Preview (which we are), but I believe general availability will happen tomorrow (November 18th).

The download wasn't too bad.  A couple of hours and I had images for SharePoint Server 2010, SharePoint Foundation 2010, Office Professional, Project, Visio, SharePoint Designer, and the Office Web Applications.

There is no upgrade path from the Technical Preview to the public beta, so our first step was to get a new clean server setup.  I love HyperV for this kind of work.  We have a development server with quad quad-core procs, 64 Gb RAM and lots of disk.  We can spin up 25+ servers on the one box for development and testing work.  Mark Campbell from my team fired up a clean Windows Server 2008 SP2 image, got it all patched up for me, and I was set to go.

Everyone remember getting frustrated by SharePoint’s “An unexpected error has occurred” that gets displayed by default when something goes wrong in SharePoint?  Well it still happens in SP2010, but the good news is the same fix takes care of it.

For those of you that haven’t come across the fix for this, it requires an edit to the web.config for the web application you are getting the error on.  Typically we do this on development and QA servers.  If you’re doing it in a farm, remember that you need to do the change to all front-end servers, or guarantee that you are hitting a specific web front-end.

The web.config is found in the home directory for the web application.  This is typically c:\inetpub\wwwroot\wss\VirtualDirectories and then the folder for your web application.  To see the full errors make the following two changes.  Opening the web.config in Notepad and searching for the tags (there is only one for each) is the easiest way to do this.

• Set: CustomErrors="Off"
• Set: CallStack="true"

Once you’ve done this change, you’ll see the full .NET error details and call stack for the error that occurred.

Okay, so maybe charging ahead on Beta 1 isn`t always the best idea.  I got my blog site up at blog.petercarson.ca with very little difficulty.  I pasted up a few of my posts, and things were still looking good.  We registered the DNS name, setup the rules on our ISA Server to publish it out, and voila, my blog site was live on the web.

That’s where things went off the rails.  Our www2010.envisionit.com site is coming along nicely too, and that was published in the same way.  In both cases I wanted the sites to be available anonymously.  No sense in doing all this writing if no one can see it.  Well the www site was publishing fine, but the blog site wouldn’t stop requesting authentication.  It wasn’t the ISA Server, as the same thing was happening inside the network.