Cumulative updates packaging changed for SharePoint 2010

while browsing the updates page on Technet I found:

The packaging of cumulative updates changed as of August 31, 2011. The following packages are provided for cumulative updates:
• SharePoint Foundation 2010
• SharePoint Foundation 2010 + SharePoint Server 2010
• SharePoint Foundation 2010 + SharePoint Server 2010 + Project Server 2010
As a result of the new packaging, it is no longer necessary to install the SharePoint Foundation cumulative update and then install the SharePoint Server cumulative update.

Source: http://technet.microsoft.com/en-us/sharepoint/ff800847

SharePoint 2010 gradual upgrade approach using ISA server

Now first a little remark about this post: This post will not handle the actual upgrade from MOSS 2007 to SP2010. It will only provide a possible method to use when you are considering to gradually upgrade specific web applications, meaning that you actually want to have the same web application with the same hostheader available on MOSS 2007 and SP2010 and redirect your users to the correct farm depending on the site collection they target.

I have been doing some brainstorming with regards to an upcoming SharePoint 2007 to SharePoint 2010 migration for one of my customers. I have had my fair deal of upgrading from SharePoint 2003 to MOSS 2007 using the gradual upgrade approach that was built-in into MOSS 2007.  

In that scenario you were able to use the URL redirection feature of MOSS. In short you could alter your DNS settings for your web application to point to your MOSS farm and then MOSS would determine if the specific site collection the user was targeting had already been upgraded and if not MOSS would redirect the user to the old SharePoint 2003 site using an alternative URL. This scenario causes a lot of confusion with your users that are accessing sites that have not been upgraded because they would start seeing your alternative url. For example: your original url was teamsites.contoso.com. Once you activated the gradual upgrade of a that specific web application, all your users would start targeting the MOSS farm and then be redirected to the alternative url which could be something like old-teamsites.contoso.com or teamsites.contoso.com:8080

In SharePoint 2010 there is still a way to use this alterantive url redirection as described in the “Using AAM URL redirection as part of the upgrade process (SharePoint Server 2010) white paper”

Now my customer asked me for a way to do it without an alternative url and simply use the same url and depending on the targeted site collection be redirected to either MOSS 2007 or SP2010. This got me thinking that it would certainly not be feasible using only DNS. The alternative url redirection feature was not an option, so I needed something that can handle such logic. This brought me to my good friend ISA server (more specifically ISA 2006)

Let me explain using a small scenario:

MOSS 2007 Farm
- Web application: teamsites.contoso.com
- site collection: /sites/siteA

SP2010 Farm
- Web application: teamsites.contoso.com
- site collection: /sites/siteB

Now there is no way that you can have your users access teamsites.contoso.com/sites/siteA and teamsites.contoso.com/sites/siteB if you are just going to use a DNS entry. To which farm would you have it pointed? The user would only be able to access one of these two sites.

What if you have the DNS entry pointed to an ISA server? Could you configure ISA to analaze the incoming request and redirect the users to the correct farm? The answer is Yes !

In ISA 2006 you can create a publishing rule for publishing a SharePoint site. With a publishing rule you can accept incoming hostnames and redirect that to a specific computer or IP address. Now in addition to that you can specify the paths that a rule should respond to.

So for this solution to work you would create 2 Publishing rules :

- 1 publishing rule publishing the web application teamsites.contoso.com towards the SP2010 farm using the IP address of the SP2010 WFE or using load balancer Virtual IP address of the WFE Servers. On the Paths tab for the rule, remove the /* path and add the path /sites/siteB/* path

- 1 publishing rule publishing the web application teamsites.contoso.com towards the MOSS 2007 farm  using the IP address of the MOSS 2007 WFE or using load balancer Virtual IP address of the WFE Servers. On the Paths tab for the rule, remove the /* path and add the path /sites/siteA/* path

Apply the new rules and that should do it.

With this in place you can easily plan the upgrade of all the individual site collection one by one if you want and let your users work transparently throughout your migration period with the same url they are used too.

Now I have tested this scneario and it actually does work. I also must admit that I have not tested this scenario very thoughly yet and that there mey be some catches, but hey it’s the idea that I want to pass you on

 

Revert a SharePoint 2010 site to the WSS3.0/MOSS2007 Look after Visual Upgrade

This question came up in one of my comments recently and I wanted to find out if it was even possible to reveert the look back of a SharePoint 2010 site that has been upgraded from WSS 3.0 or MOSS2007

Thanks to Corey Roth and a comment on his post about I found out the following:

“In SharePoint 2010, there is the concept of a UI Version and it has a value of 3 or 4.  When you upgrade your existing site, it will leave you at Version 3 which looks just like WSS3.  However, you have the capability to upgrade to the new SharePoint 2010 visualizations which is version 4.  If the administrators have the options enabled, you can change your UI version using the UI itself.  It provides the capability to run on Version 3 but get a preview of 4 and then ultimately they can convert to version 4 completely.  However, you may want to do this programmatically or you may want to revert back to version 3 after you have turned off preview mode.  “

So there are already two possible ways of doing it:

1. Using Code: (thanks to Corey Roth)

using (SPSite siteCollection = new SPSite(“http://server/site“))
{
    SPWeb site = siteCollection.OpenWeb()
    {
        site.UIVersion = 3;
        site.UIVersionConfigurationEnabled = true;
        site.Update();
    }
}

2. Using Powershell: (thanks to Tobias Zimmergren)

$site = Get-SPSite(“http://portal“)
$web = $site.OpenWeb()
$web.UIVersion = 3
$web.Update()
$web.Dispose()
$site.Dispose()

My upgrade experience to SharePoint Foundation 2010

I thought I’d share with you guys what I had experienced during the upgrade from my WSS 3.0 server to SharePoint Foundation 2010 beta.

First of all, my WSS 3.0 is quite small. There’s only One site collection in there of any significance en some other site collections for testing purposes. So with this in mind I thought this would be a piece of cake.

After having made a stsadm backup of every site collection and a backup of all my SharePoint databases, I was ready to start. After having read though the deployment docs, I found out that if you are running SQL 2008, that it needs to be at least SP1. I was already running that build so I was good to go for that. I must admit that the prerequisite installer runs smoothly. It does detect your missing prerquisite software and goes out to the interent to download the missing bits. The installation of SharePoint Foundation went flawlessly. I was quickly able to start up the Products and Configuration wizard.

The upgrade wizard quickly failed, telling me that I need to install the Dutch Language Pack as it is also installed for WSS 3.0. A quick look on the web showed me that there isn’t one yet available. Hmm.. problem number 1. I had to uninstall the Dutch language Pack before I could continue. Since all my site collections are also created in Dutch, I needed to convert them to an Englich version, so I decided to do some unsupported stuff and change the  language of my site using the following SQL command on my content database:

UPDATE dbo.webs set language = 1033

Sure enough, my sites are now back in English. I ran the uninstall for the dutch WSS Language Pack and again I was good to go.

My next attempt for running teh upgrade failed as well, complaining about an incorrect SQL version. What the h***? Hadn’t I checked that already before? As it turns out you do not only need SQL 2008 SP1, but it also needs the Cumulative Update 2 for SP1 installed. So I got to download those bits, install them and voila, we are back in business.

The final attempt for the upgrade succeeded. The upgrade process ran successfully, giving no errors and I was soon presented  with the new Central Admin site.I quickly checked the look of my sites, which was as expected still the same, although if you go through to Site Settings, you immediately notice that something has changed. It isn’t quite the old version anymore.

 So all I needed to do is play aroud  with the Visual Upgrade Preview and fin out how my sites will look in their SharePoint 2010 version.

so that’s it for my first upgrade experience.

Well actually it isn’t, because after all my sites had been upgraded I decided to take a backup of my new site collections using stsadm and remove everything. I uninstalled SharePoint Foundation 2010, WSS 3.0, deleted all my SQL databases and started a clean install of SharePoint Foundation 2010. After that I restored the site collections and there I was again: up and running. I don’t like running some hybrid versions with both WSS and Foundation installed and prefer a clean install [:D]

 

Update a SharePoint farm with minimal site downtime

It was the time of the year again to do an upgrade of several SharePoint farms for my customer. This upgrade was for installing SP2 and the June cumulative update on an entire farm and the requirement was to avoid too many downtime by the installation. This post will cover the process that I used to upgrade the entire farm.

Farm setup:
- 1 hardware load balancer
- 2 Web Front End servers (I will call the WFE1 and WFE2)
- 1 index server
- 1 SQL cluster

What I needed for upgrading the farm smoothly was a way to put a maintenance page for all web applications to appear when the content is really down. I used the simple ASP .Net trick by creating a – in my case custom -  App_Offline.htm file which mentions that the site is down for maintenance. Copying this file into the root location of each IIS website used by SharePoint Web Applications will show this message instead of the SharePoint content.

Another thing I wanted to do is to detach the databases before running the Configuration Wizard. Why? To avoid the upgarde to fail on a single content database and shorten the upgrade time. Once the config wizard completes, I reattach the content databases one by one, causing them to be upgraded at that moment.

preparation tasks:
- create a custom App_Offline.htm file for showing a maintenance page
- create a batch file that conveniently copies the App_Offline.htm file to all Web Applications (make sure not to copy it to the Central Admin WebApp) 
- create a batch file that conveniently deletes the App_Offline.htm file from all Web Applications 
- create a batch file that detaches all content databases for all Web applications with the exception of the Central Admin and SSP Web Apps ( add stsadm -o preparetomove command before detach database if you are still running MOSS SP1 pre-Infrastructure Update) 
- create a batch file that attaches the content databases

Upgrade process:

1.  Make sure that the hardware load balancers stops the services for WFE1 and only uses WFE2 to service user requests. We have an internal procedure that allows for manipulation of the load balancer. Actually we simply need to stop a custom IIS web site on the WFE server which will cause the load balancer to failover to the second WFE automatically.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 2 minutes

2. Install the binaries for your SharePoint upgrade on WFE1. In my case WSS SP2 + MOSS SP2 +  all SP2 versions of the WSS and SharePoint Language Packs and finally installing the June Cumulative Update for WSS and MOSS. When installation completes, reboot the server.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 50 minutes

3. Simultaneously install the same binaries on the index server. When installation completes, reboot the server.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 40 minutes

OK So far so good. So basically, at this point, I have installed the binaries on 2 servers and I still have 1 to go, which is WFE2 that is still serving the SharePoint sites. I have two possibilities to continue:
- option1: install the binaries on WFE2 and reboot
- option2: run the configuration wizard on the upgraded WFE1 or the index server.

Option 1 will take all the sites down, because the installation of new binaries will stop IIS = Downtime and 404 errors. I cannot redirect my users to the upgraded WFE1, because the configuration Wizard has not run yet. So I am working with option 2

4. on WFE2 I launch my script that sets all my sites in maintenance mode (copies the App_Offline.htm file, that is)
   Availability Result: Users are not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
   Timing result: this operation took 1 minute

5. on WFE2 I launch my script for detaching all content databases
   – this script launches a stsadm -o preparetomove command for each content database (except Central Admin and SSP databases). This command is no longer required if you have at least SP1 with the Infrastructure Update installed.
   – this script launches a stsadm -o deletecontentdb command for each content database (except Central Admin and SSP databases)
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
   Timing result: this operation took 5 minutes ( I had 5 content databases)

6. on WFE1, run the SharePoint Products and Technologies Configuration Wizard.
If the upgrade process fails, investigate the log specified by the wizard, but also check 12-Hive\LOGS\Upgrade.log and the default SharePoint ULS logs. I have already seen that the SharePoint logs are written to the 12-Hive\LOGS folder instead of the location you specified in Central Admin during this upgrade process. After the upgrade your specified Logging location is used again.
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
   Timing result: this operation took 15 minutes

7. Now that the farm configuration databases have been upgraded, your WFE1 is ready to start serving users again as soon as the content databases have been reattached. So, on WFE1 I launch my script to reattach the content databases. If one the operations generate an error, you can find the specific error in the 12-Hive\LOGS\Upgrade.log file.
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
   Timing result: this operation took 10 minutes.

8. Make sure that the hardware load balancers starts the services for WFE1 and stops the services for WFE2 to service user requests.
   Availability Result: Users are again able to access SharePoint content through WFE1.
   Timing result: this operation took 2 minutes

My upgrade status is now complete with regards to the SharePoint content. My farm is servicing users again through a single Web Frontend Server for the moment, but it is servicing which is my main concern at this point. I no longer have downtime towards my users. If you add up all the minutes, then I have had a downtime towards my users of 33 minutes, which can be considered a small downtime. Now I continue with the rest of the upgrade process.

9. WFE2 is free now to do with whatever I want since it is no longer included in the load balancer pool.
- first, I launch my script to deactivate the site maintenance which simply deletes all App_Offline.htm files
- Next, I Install the binaries for the SharePoint upgrade on WFE2 + Reboot the server
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 50 minutes

10. While WFE2 is installing the new binaries, I can run the SharePoint Products and Configuration Wizard on the index server.
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 6 minutes

11. Run SharePoint Products and Configuration Wizard on WFE2
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 8 minutes

12. Final step: Add WFE2 back into the load balancer pool

Conclusion:
Although the entire operation took about 4 hours, there was a downtime of only 33 minutes for our users and furthermore our users did not hit any 404 pages, but received a nice site maintenance page telling them exactly what is going on. Needless to say, that my customer was satisifed with the result for the downtime

Hopefully this process is of any use to you guys.

 

Sample of my script files as requested by KbNk:

The maintenance mode script and the de-reattach scripts are simple batch files (*.bat).

Here is a sample for the scripts:

example data:

-> 1 Web Application with url http://webapp1.contoso.local
-> SQL server name: sqlserver01
-> content database name for the webapp: wss_content_webapp1
-> IIS Site directory location on file system: E:\IIS\mywebapp

- maintenance mode on script = simple copy command, no rocket science
   copy e:\App_Offline.htm E:\IIS\mywebapp\

- maintenance mode off script
   del e:\IIS\mywebapp\App_Offline.htm

- detach database batch file sample:
   stsadm -o preparetomove -contentdb sqlserver01:wss_content_webapp1 -Site http://webapp1.contoso.local  (Remove this line if you have SP1 wth Infrastructure Update or later installed)
   stsadm -o deletecontentdb -url http://webapp1.contoso.local -databaseserver sqlserver01 -databasename wss_content_webapp1

- attach database bacth file sample:
   stsadm -o addcontentdb -url http://webapp1.contoso.local -databaseserver sqlserver01 -databasename wss_content_webapp1

How to upgrade to SharePoint 2007 SP2 – Step by Step by Chris Givens

I was reading trhough my blogroll today and noticed a very complete blog post for deploying SP2 in a large MOSS environment. It describes optimized steps for installing SP2 with lesser downtime as you would have by just installing it. Chris Givens is a SharePoint trainer. His Advanced SharePoint 2007 Operations course looks very interesting. Just a pitty that you have to go all the way to Seattle for it…. For us European trash guys, it is hard to defend that to our manager, right? 

So please, read through this post as it may help you with your upgrade of your farm if you have large databases.

This is the original content of Chris’s Post that can be found at

http://blogs.architectingconnectedsystems.com/blogs/cjg/archive/2009/05/10/How-to-upgrade-to-SharePoint-2007-SP2-_2D00_-Step-by-Step.aspx

 built this lab for the latest update to my Advanced SharePoint Operations course.  But I felt like it would benefit the entire community…so here you go!  Good luck!

Module #25: Updating The Farm Lab #01

 

Course:                SharePoint 2007 Operations

Estimated Time to Complete:  45 minutes

Objectives:

·         Upgrade to SP2

Operating Notes:  

·         You will need sharepoint2007 and svr-sp2 images

·         Assumes that you are using SQL Server 2000/2005/2008 for your database server (Not Internal DB engine)


Deliverables:

·         None

 

Overview:         Learn the steps of preparing your farm for upgrade and then performing the upgrade.

Exercise 1 – Prep the Farm

Purpose:         There are a series of recommend steps that will speed up the upgrade of your SharePoint Farm.  Following these somewhat simple suggestions will get you through the process much faster!  Rebuilding indexes will ensure that the upgrade process will modify the database schemas and records as quick as possible.  Truncating the log files will ensure that your backup and restores will run quickly.  Detaching

Result:           
A farm ready for upgrade

Task 1 – Clean up the databases (rebuild indexes)

  1. Open SQL Server Management Studio
  2. Connect to your sharepoint database server
  3. Click “New Query”
  4. Run (press Atl-X) the following command on each SharePoint database (set the dropdown for each):
    • WSS_Content*
    • SharePoint_Config*


SELECT  object_id, index_id, avg_fragmentation_in_percent, page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL , NULL)
order by avg_fragmentation_in_percent desc

SET NOCOUNT ON
    DECLARE @objectid int
    DECLARE @indexid int
    DECLARE @command varchar(8000)
    DECLARE @baseCommand varchar(8000)
    DECLARE @schemaname sysname
    DECLARE @objectname sysname
    DECLARE @indexname sysname
    DECLARE @currentDdbId int

    SELECT @currentDdbId = DB_ID()

    PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Starting'

DECLARE indexesToDefrag CURSOR FOR

SELECT
        i.object_id,
        i.index_id,
        i.name
FROM
       sys.indexes AS i
INNER JOIN
        sys.objects AS o
ON
        i.object_id = o.object_id
WHERE
        i.index_id > 0 AND
        o.type = 'U'

    OPEN indexesToDefrag
    -- Loop through the partitions.

    FETCH NEXT
    FROM
        indexesToDefrag
    INTO
        @objectid,
        @indexid,
        @indexname
    WHILE @@FETCH_STATUS = 0
    BEGIN
        -- Lookup the name of the index
        SELECT
            @schemaname = s.name
        FROM
            sys.objects AS o
        JOIN
            sys.schemas AS s
        ON
            s.schema_id = o.schema_id
        WHERE
            o.object_id = @objectid

        PRINT CONVERT(nvarchar, GETDATE(), 126) + ': ' + @schemaname + '.' + @indexname + ' is now being rebuilt.'

        -- Fragmentation is bad enough that it will be more efficient to rebuild the index

        SELECT @baseCommand =
            ' ALTER INDEX ' +
                @indexname +
            ' ON ' +
                @schemaname + '.' + object_name(@objectid) +
            ' REBUILD WITH (FILLFACTOR = 80, ONLINE = '

        -- Use dynamic sql so this compiles in SQL 2000
        SELECT @command =
            ' BEGIN TRY ' +
               @baseCommand + 'ON) ' +
            ' END TRY ' +
            ' BEGIN CATCH ' +
               -- Indices with image-like columns can't be rebuild online, so go offline

               @baseCommand + 'OFF) ' +
            ' END CATCH '

        PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Rebuilding'
        EXEC (@command)
        PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Done'

        FETCH NEXT FROM indexesToDefrag INTO @objectid, @indexid, @indexname
    END

    CLOSE indexesToDefrag
    DEALLOCATE indexesToDefrag

SELECT  object_id, index_id, avg_fragmentation_in_percent, page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL , NULL)
order by avg_fragmentation_in_percent desc

GO

 

Task 2 – Check disk space on web and database servers

  1. On each web front end, open Explorer to “My Computer”, record your disk space.  Make sure you have at least 300MB free for install of files
  2. On each database server, open Explorer to “My Computer”, record your disk space.  Make sure that you have enough space to make a copy of your largest content database.
    • Example:  if you have three databases of size 10GB, 20GB and 30 GB.  Make sure you have at least 30GB of free space on your DB server.

Task 3 – Backup the databases (truncate and backup)

  1. Create a folder called “D:\Backups”, ensure that you have enough disk space to save all your backups to this location (add the size of each database to determine how much you will need)
  2. Run the following commands TWICE for each database (this will shrink, backup and truncate your database and log files):
    • WSS_Content*
    • WSS_Search*
    • SharePoint_Config
    • SharedServices*


use WSS_Content

dbcc shrinkfile ('WSS_Content')
dbcc shrinkfile ('WSS_Content_log')
go

backup database WSS_Content to disk = 'D:\backups\wss_content.bak'
go
backup log WSS_Content to disk = 'D:\backups\wss_content.bak'
go

dbcc shrinkfile ('WSS_Content')
dbcc shrinkfile ('WSS_Content_log')
go


Task 3 – Evaluate Database Size

  1. If you designed your farm wrong, it is possible that you have a single web application with a single content database that contains all your content.  This type of setup normally means you have a database that is going to get large very quickly and backup and restore operations, as well as future upgrades could take a considerable amount of time.  It is suggested that you create more content databases and partition your site collections across multiple databases.
  2. You have two options to do this:
    • Create another content database in the web application
    • Create another web application with a new content database
  3. Create a new site collection in your port 100 site
    • Open “Central Administration”
    • Click “Application management”
    • Click “Create Site collection”, ensure that you are on port 100 web application
    • For Title, type “SC2”
    • For URL, select “/sites/”, and type “SC2”
    • For owner, type “administrator”
    • Click “Ok”
  4. You will now have two site collections in your content database, you can use the following commands to backup a site collection, delete it and restore to a different web application (and hence a new content database):


stsadm -o backup -url http://sharepoint2007:100/sites/Sc2 -filename c:\backup.dat –overwrite

stsadm –o deletesite -url http://sharepoint2007:100/sites/Sc2

stsadm -o restore -url http://sharepoint2007:777/sites/sc2 -filename c:\backup.dat

  1. You can continue this process to load balance your site collections across multiple content databases and in essence distribute your database sizes so that upgrading will not be so painful.
    • NOTE: you can only use a url once in a web application

Task 4 – Detach the content databases

  1. Open the “Central Administration” site
  2. Click “Application Management”
  3. For each web application in your web application list (EXCEPT central administration), do the following steps. NOTE: Click “Web Application List” to see them all:

  1.  
    • Click “Content Databases”

  1.  
    • You will see a list of content databases for the web application
    • Click the database name

  1.  
    • Click the “Remove content database” check box
    • Click “Ok”
    • Click “Ok”

  1.  
    • Click “Ok”
    • You should now see that the web application has no content databases:

  1. Again, do this for every web application EXCEPT the Central administration web application!
    • NOTE: you may have several content databases…this may be a tedious task so you should likely follow step 5
  2. You can also create a command line utility to do this:
    • Open Visual Studio
    • Click “File->New Project”
    • Select “Console Application”
    • For name, type “ContentDetachAttachScript”
    • Copy the following into the program.cs file:


using System;
using System.IO;
using System.Collections.Generic;
using System.Text;

using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            TextWriter tw = File.CreateText("C:/detachall.bat");
            TextWriter tw2 = File.CreateText("C:/attachall.bat");

            SPFarm farm = SPFarm.Local;
            SPAlternateUrlCollectionManager mgr = farm.AlternateUrlCollections;                                             

            foreach (SPAlternateUrlCollection altColl in mgr )
            {
                foreach (SPAlternateUrl url in altColl)
                {
                    if (url.UrlZone == SPUrlZone.Default)
                    {
                        try
                        {
                            SPSite site = new SPSite(url.IncomingUrl);

 

                            SPWeb root = site.RootWeb;
                            if (root.WebTemplate != "CENTRALADMIN")
                            {
                                //get the web application for the site collection
                                SPWebApplication webApp = site.WebApplication;

                                foreach (SPContentDatabase cd in webApp.ContentDatabases)
                                {
                                    tw.WriteLine("stsadm -o deletecontentdb -url " + url.IncomingUrl + " -databasename " + cd.Name + " -databaseserver " + cd.Server);

                                    tw2.WriteLine("stsadm -o addcontentdb -url " + url.IncomingUrl + " -databasename " + cd.Name + " -databaseserver " + cd.Server);

                                    //Console.WriteLine("Content Database [" + cd.Name + "] was detached");

                                    //cd.Delete();

                                }
                            }
                        }
                        catch (Exception ex)
                        {
                            Console.WriteLine(ex.Message);
                        }                       
                    }
                }
            }

            tw.Close();
            tw2.Close();

            Console.WriteLine("Press enter to close");
            Console.ReadLine();

        }
    }
}

  1.  
    • Compile the program, press F6
    • Copy the executable to your SharePoint Farm
    • Run the executable
    • Open the C:\detachall.bat file , this file will contain all the stsadm commands that will detach all your content databases
    • Open the C:\attachall.bat file, this contains all the stsadm commands to reattach your databases (NOTE: you should attach one at a time in the later steps).


Task 5 – Backup important files

  1. If running in a virtual environment, backup your front end webservers main image file.  After doing this, you may skip the rest of these steps and head straight for upgrade!!!
  2. Web.config files for all web applications (located in WSS directory of wwwroot)
  3. Core Site definitions that were modified  ( located in 12 hive template/sitetemplates directory)
  4. Any customizations including:
    • Changes made to core.css
    • Changes made to javascript files
    • Pretty much anything you changed in the 12 hive…

Task 6 – Upgrade the servers (WSS)

  1. Stop IIS
    • Open a command prompt, run “iisreset /stop”
  2. Run “d:\lab files\25_Lab01\ wssv3sp2-kb953338-x86-fullfile-en-us.exe”
  3. Click “Click here to accept…” check box
  4. Click “Continue”
  5. The service pack should start…:

  1. When the WSS update finishes, the Configuration Wizard will start:

  1. Click “Next”

  1. Click “Yes”

  1. Click “Next”

  1. Click “Ok” at the information popup, the farm will start to configure itself.  This includes:
    • Updating DLLs (gac)
    • Creating/Updating registry keys
    • Creating/Updating 12 hive information
    • Updating web.config files
    • Installing new features
  2. The install should finish:

  1. Repeat the above steps for the svr-sp2 image

Task 7 – Upgrade the servers (MOSS)

  1. Stop IIS
    • Open a command prompt, run “iisreset /stop”
  2. Run “d:\lab files\25_Lab01\ officeserver2007sp2-kb953334-x86-fullfile-en-us.exe”

  1. Click “Click here to accept…” check box
  2. Click “Continue”
  3. The service pack should start…:

  1. When the MOSS update finishes, the Configuration Wizard will start:

  1. Click “Next”

  1. Click “Yes”

  1. Click “Next”

  1. Click “Ok” at the information popup, the farm will start to configure itself.  This includes:
    • Updating DLLs (gac)
    • Creating/Updating registry keys
    • Creating/Updating 12 hive information
    • Updating web.config files
    • Installing new features
  2. The install should finish:

  1. Repeat the above steps for the svr-sp2 image

Task 8 – Reattach the content databases

  1. Open the C:\attachall.bat file, run the attach command for each content database that you detached
  2. SharePoint will upgrade the database as it attaches it.

Task 9 – Verify Install

1.       Open the upgrade.log file (in 12 hive LOGS directory)

o    Look for “Finished upgrading SPFarm Name=<Name of Configuration Database>”

o    Look for “In-place upgrade session finishes. Root object = SPFarm=<Name of Configuration Database>, recursive = True. 0 errors and 0 warnings encountered.”

2.       If the above entries DO NOT exist, look for all instances of

o    “fail”

o    “error”

3.       Check version number on:

o    Owssvr.dll (in 12 hive isapi directory) should be “12.0.6421.1000”

 

 

o    Registry “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0”

 

o    Central administration

4.       Check version of the sharepoint databases:

o    Run the following sql command on each database:


select * from versions
order by timestamp desc

 

o    You should get “12.0.0.6421”

 

5.       On Central Administration, click “Operations”

o    Click “Servers In Farm”

o    The version for the farm and servers should be “12.0.0.6421”

 

Task 10 – Check for SharePoint 2010 readiness

1.       Run the following command:


stsadm –o preupgradecheck

 

2.       Review the PreUpgradeCheck-*.htm file in the 12 hive logs directory (it should open in a browser window

3.       You should watch out for the following items:

o    The above command should be run on all Web Front end servers to ensure they are identical

o    You should review the Site Definition information for any non “Internal” site definitions, these will need to have an upgrade definition file.  Your developers will need to build this file for SP 2010

o    If you have language packs installed, you will need to install the latest version when SP 2010 comes out

o    Look for any referenced and missing features.  Either install them or delete the references to them

o    Depending on the type of upgrade to SP 2010 you do, you many need to plan for URL changes in your sites

o    Review the Lists that have more than the recommends number of items.  These could slow the migration process to SP 2010.  Consider removing the list or deleting items to shrink the list size

o    Review any Custom Field types that have been added to your Farm.  CAML is not used in SP2010 and each of them will need to be re-developed with XSLT in mind.

o    If you are running on 32 bit OS and Server 2003, you will need to start planning for migration to a 64bit server 2008 environment to run SP 2010

lessons learned in my last sps to moss migration project using gradual approach

I have been doing a fun project for a customer, which asked to have his SharePoint Portal Server 2003 farms upgraded to MOSS 2007 using the gradual upgrade approach. I wanted to share some tips and things to consider when you are facing such a project.

1. remove unused and/or previous versions of webparts fom the SharePoint configuration.

There can still be web parts registered in SharePoint that have been physically or manually removed from the virtual server. Check stsam -o enumwppacks for any webpart packages installed that are no longer registered in the web.config files and so on. Know that when you start the upgrade of the web application, MOSS will try to upgrade all registered webpart packages and that if it cannot find it anymore, the process will fail and you zill not be able to upgrade the web application until you have fixed this. 

2. check if your IIS sites have not been renamed

Another one of those things to keep in mind is the fact that when the farm is created in SPS, it writes down the name of the IIS web site in the configuration database. The MOSS upgrade will use this information to find out which IIS site corresponds to the SPS sites. If these sites have been renamed in the meantime and you want to upgrade a SPS web application, then you can get a message indicating that there is nothing to upgrade or you will also not be able to find your SPS virtual servers in the MOSS upgrade pages in Central Administration v3. If for some reason you are in a farm scenario and your IIS site name has been changed on another front end server and not on the one you are performing the upgrade, then you will not get this warning, but the MOSS upgrade will not update the IIS site with the alternat url or port that you configure and you will therefore need to make the changes manually.

3. consider adding an additional frontend server to be used as the server that performs the upgrades

When you are ready to start upgrading sites, you need to do this on a server running the Central Administration role and the Web Application role. Do not think you can get away by using your index server to do your upgrades. The moss upgrade pages go through your IIS configuration to find the web applications that can be upgraded. If you are going through the upgrade pages on a central admin site hosted on your index server and net having the web application role, you will not find any web applications and/or site collections for which you can start the upgrade. Of course having installed MOSS on top of your existing front end servers, already bring an additional load to those systems and your users will probably start complaining with performance issues. That is why I would advise havin an additional frontend server installed in your SPS farm and use this one for performing the upgrades.

4. beware of the side effects of prescan

Another thing that surprised me in the project is prescan. This required tool suppoedly does not change anything to your sites. However it does. You know when you are viewing a list of all yous Document libraries and lists in your site, that it mentions next to each list when the last modification was done in that library or list (e.g. 6 days ago). Well running prescan will reset that information. So while it does not actually change any documents or lists, it does change the last modified date of the list or library itself. Knowing this may help you when you get your users on the phone complaining that all the document libraries have been changed all of a sudden (after you have run prescan)

5. there is no stsadm command to lock/unlock a site in SPS

damn, this is a bugger. Planning to script the upgrade of each site I found out that you cannot lock a site in SPS using the commandline stsadm tool. Apparently this was only introduced in MOSS. I found the solution in SPSiteManager (see my post about it)

6. Plan your content databases in MOSS

part of my project I was asked to have tha large databases in SPS, split up in multiple databases in MOSS. I did this by using the stsadm -o mergecontentdbs operation right after the site has been upgraded. Unfortunately you cannot choose wher the upgrade porcess needs to put the upgraded site collection. Part of the preparations to your upgrade is the fact that you need to configure a 1 to 1 relation of your existing SPS content databases to your MOSS databases, meaning that if a site is located in a specific content database, that its upgraded version will end up in the configured MOSS database and nowhere else (even if there is a parameter in the stsadm -o upgrade command that allows you to specify the targetdatabasename)

A piece of good advise: If you are planning to have more content databases in a specific web application in MOSS than you have in the corresponding virtual server in SPS, create additional empty databases in SPS to match the number of content databases in MOSS. It will save you a lot of trouble if you need to revert an upgraded site and reupgrade it again.

7. Check your upgrade.log file

Every action that MOSS does which regards upgrades of web applications, upgrades of site collections and even reverts of sites is logged in the upgrade.log file. If you have chnaged the default logging location in Central Administration v3 – Operations – Diagnostics Logging, then do not expect the upgrade.log file to be there as well. This log file does not leave the nest. You need to find it in the 12-hive Logs folder. A good practice would be to clear this file before starting the upgrade of any site.

8. Know how to rollback a failed upgrade of your SPS virtual server.

I had this issue that I was finally ready to start the upgrade of the web application and that during this upgrade process the well-known “unknown error occured” appeared. When I went back to the upgrade page, I was not able to rollback this operation or redo the upgrade. So what do you do next? the answer is very simple: delete the newly created web application in MOSS and every change made to the IIS sites (URL redirection) will automatically be undone as well.

I am sure that I can add some otherpoints to this list, but nothing comes to my mind on this sunny sunday afternoon. If something does come up I will gladly add it to this post and share it with you guys.

SPS2003 Add Link to Site not working

Why might this be relevant to a MOSS admin. Well, you might be busy upgarding a SharePoint Portal Server 2003 environment to MOSS using the gradual approach, like I am. Off course you would test thjis on a test farm and reproduce your production environment in a somewhat representative way. In my case a imported only a couple of production sites in my test environment, which could be considered as logical.

Now, the thing is that I tried crawling the SPS content with my new MOSS farm and the crawl uses the Site Directory on the SPS Portal to anmalyze which sub sites it needs to crawl. Clearly the Site Directory was not reflecting teh istes I had on my test environment. So I cleaned out the Site Directory and wanted to add Links to the actual sites on the SPS application.Guess what, I was unable to. Apparently this is due to SP2 for SharePoint Portal Server 2003.

Thanks to this blog post I found the solution:

1. Open this file in a text editor:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\[LCID]\SPSSITES\LISTS\SITESLST\NewForm.aspx
(Replace [LCID] with your locale identifier, 1033 for English)

2. Find this code fragment:

<SPSWC:InputFormButtonSection runat=”server”>
<SPSWC:InputFormButtonAtBottom ID=”ButtonOk” runat=”server”
TextLocId=”Page_OkButton_Text”/>
<SPSWC:InputFormButtonAtBottom ID=”ButtonCancel” runat=”server”
TextLocId=”Page_CancelButton_Text” visible=”false” />
</SPSWC:InputFormButtonSection>

3. Replace it with this code fragment:

<SPSWC:InputFormButtonSection runat=”server”>
<!– Workaround for WIN2003SP2 issue: http://support.microsoft.com/kb/934229
–>
<input type=”button” value=”         OK         ”
onclick=”document.forms[0].submit()” />
<!– <SPSWC:InputFormButtonAtBottom ID=”ButtonOk” runat=”server”
TextLocId=”Page_OkButton_Text”/> –>
<!– End workaround –>
<SPSWC:InputFormButtonAtBottom ID=”ButtonCancel” runat=”server”
TextLocId=”Page_CancelButton_Text” visible=”false” />
</SPSWC:InputFormButtonSection>

4. Thats it;-)

Step-by-Step – A REAL world upgrade of a SharePoint Portal Server 2003 (SPS) farm to Microsoft Office SharePoint Server 2007 (MOSS) by Cornelius J van Dyk

Looking for some more information about the gradual upgrade from SPS 2003 to MOSS 2007 I stumbled upon this monster step-by-step guide of Cornelius J van Dyk, a Microsoft MVP in SharePoint. If you are starting an upgrade project, then be sure to go through this document!


You can find the document and the post at http://www.cjvandyk.com/blog/Lists/Posts/Post.aspx?ID=107


And be sure to add Cornelius’ Blog to your favourite feeds!


And if for some weird reason you are reading this Cornelius, GREAT JOB on your blog! You just got an additional fan!