Tag Archives: SharePoint

Migrating from 32bit SharePoint Services

Server Support,

This is my definitive guide on migrating from 32 bit Windows SharePoint Services 3 to SharePoint Foundation 2010 (64 bit only, oof!).  It’s not quite as definitive as I would like as I barely had time to work this through once, let alone multiple times:

  1. I changed the user account that runs WSS3 from ‘NETWORK SERVICE’ to a domain account (though I’m unsure if this step is required).  I originally did this when trying to restore the 32bit WSS3 onto the 64bit box and then using 64bit WSS3 to try and upgrade it.  Don’t do that by the way.  Anyway it made working with the database easier on the whole anyway.
  2. Backed up the SharePoint content database, called STS_servername_1 in my case. (This server used the ‘Windows Internal Database’, an extra crippled version of the already crippled SQL express.  I had installed the SQL 2005 tools on there for a different project so I used the ‘SQL Server Configuration Manager’ to change the service argument to add “;-T7806” and I then used the SQL management studio to do the backup).
  3. Installed 64bit Sql Server 2008 express on the new 64 bit server (I named the main instance the same as the instance on the 32bit box, not sure if that matters)
  4. Installed SharePoint Foundation on the new 64 bit server (it automatically set itself up in the SQL instance I installed).
  5. Restored the content database to the new server (again, using the management studio; I know that it can be done through the command prompt but I like the visual feedback).
  6. Within the Central Administration site on the new server I went to ‘Manage Content Databases’, clicked on the preinstalled content database and removed it in the subsequent interface.  This step removes the content linked to ‘/’ so that the restored database can go there.
  7. Added the restored database to the farm using stsadm. (in our case: stsadm -o addcontentdb -databasename STS_servername_1 -databaseserver newserver-url http://newserver/)
  8. Upgraded the content database using the ‘upgrade-spcontentdatabase’ command within the Sharepoint PowerShell.
  9. The content should now show up when you pull up http://newserver/ , but to complete the upgrade (and keep the content database from showing as ‘mostly upgraded’ or something along those lines) I had to upgrade the view under ‘Site Settings’ within the Sharepoint site and then going to (I believe) ‘Visual Upgrade’.

Obviously our setup is fairly simple with one server driving the whole ‘stack’.  Our content is also fairly static (it didn’t matter that the database backup that I was working with was a day old).  Your results, of course, may vary (but will probably do a sight better than trying to put something together from the amalgamation of websites that only convey one piece of the puzzle!).

SharePoint upgrade with a side of Metabase

Server Support,

After upgrading from SharePoint 2 to 3 our content came up, but no changes could be made and when trying to sign on (via the “Sign In” link) I was getting an error of “Server Application Unavailable” and an event 1062 on the server with the text:

It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process.

What was aggravating on this count was that everything looked to be ASP ‘2’ (2.0.50727), but while digging I discovered that the ‘images’ and ‘inc’ virtual directories under ‘_layouts’ were set to ‘1.1’ (v1.1.4322).  The ‘inc’ path didn’t even exist and after creating it, it stuck to the ASP.net setting of 2.  The ‘images’ virtual directory was a different story as it kept reverting back to 1.1.  I finally recalled from a certification test that if nothing else the metabase.xml file for IIS contains all the settings for the web server and it can be edited by hand.  After looking into the file I discovered that the ‘images’ virtual directory had two entries, one with 2 and one with 1.1.  I deleted the 1.1 and the settings stuck to 2 when IIS was cycled; but unfortunately the error persisted.

It turned out that, even though it couldn’t be changed in the GUI, the ‘_layouts’ directory was set to 1.1.  I manually changed it in the metabase.xml file by copying the settings over from the ‘inc’ section and after cycling IIS the sign-in function worked and the error was gone!

Now to fix all the permissions on our custom web parts that got copied by the upgrade process and were set to the default folder permissions.