Azure & Co: SharePoint2010

Showing posts with label SharePoint2010. Show all posts

Saturday, June 12, 2010

CSS Registration and Rendering for SharePoint 2010 (including themes)

Updated 2011 december 20th

Topic :

In my previous post on the ms-rteStyle, the ms-rteElement CSS classes and their role in the generation of the Styles and the Markup Styles menus items within the SharePoint 2010 Ribbon, I promised a real world example of the Wiki Page branding. I will provide it soon, but first of all I had to deeply explore how all was implemented in the new SharePoint 2010 version so this post will be a very technical review of the involved blocks. That way, I will be able to refer to the technical explanations of this post when I publish a real example of branding.

Technical review of the CSSLink , and CssRegistration WebControls in SharePoint 2010 and their use for the SharePoint 2010 themes

To start from the beginning, I simply looked at the html source of a SharePoint 2010 wiki page created in a standard team site, and noticed this three link references:

Then, I decided to understand how they was generated by the product.

1 -The <SharePoint:CSSLink /> control - How does it work?

If you look in the v4.matser code you will find the control within the Head tag

<SharePoint:CssLink runat="server" Version="4"/>

First, let us just examine the OnLoad method

method OnLoad

method SetDefaults
Check if it is the version 4 and choose between core.css corev4.css

method MakeCssUrl - Make the default CSS Url (primaryCssUrl)
If the variable cssFile is already affected, return it
else,
Check if there is customized CSS and return the url if yes.
If no NormalizeThemableCssFile (add themable in front of cssFile name if it is the corev4.css)
then MakeLayoutCSSUrl
At this time there is only two options (if you use native templates)
-->/_layouts/lcid/style/core.css
or
-->/_layouts/lcid/styles/Themable/corev4.css

Check if there is alternate CSS and if yes
cancel the default values
flag there is alternate css and register the value.

method SetupDialogCSS --> add dynamically CSS class to dialog and add a link to dlgframe.css

Conclusion, after the OnLoad method, the control will render only the link to

either /_layouts/lcid/sytles/themable/corev4.css if you use v4.master and a site based on a native SharePoint 2010 site definition.
or /_layouts/lcid/styles/core.css if you omit the Version property
or /_styles/something if you use customized css (ie stored in the database)
or /_layouts/lcid/styles/customFolder/customStyles.css if you use alternate CCS
or maybe the corev4.css of the theme if a theme is applied but I could not checked that...

Plus a link to dlgframe if you have open a SharePoint 2010 dialog.

Notice that this is a very bad idea to remove this control from a master page because
it sets programmatically the styles for the SharePoint 2010 dialogs.
it manages the version of the core.css file
it finds the customized styles if there is some
it switches to the alternate css if needed

Notice also that even if you use an alternate CSS and display a team site wiki page, the OOTB corev4.css will be loaded ANYWAY.
So, regarding the team site wiki pages the term alternate is WRONG...
For further information regarding this point you can read 2.8 - Second limitation of the team site wiki page in SharePoint 2010: it is very difficult to remove the OOTB RTE style

And much more as we are going to see with the new SharePoint 2010 themes. But before, let us finish with the two other links generated by the control:
So where does come the wki.css and the search.css references from?
They are rendered by the control in the Render method, based on the enumeration of the CssRegistrationCollection filled by at least a SharePoint.CssRegistration Web Control used in a declarative or imperative way.

2 - The <SharePoint:CssRegistration> control and the Microsoft.SharePoint.WebControls.CssRegistration.Register method

This control and this method are both linked to the <SharePoint:CSSLink> control, because they are adding links to a collection at the level of the site (CssRegistrationRecord) and the CSSLink control will enumerate this collection during the Render method to render all the links to css files that are registered within this collection.

- The two link toward Themable/wiki.css and Themable/search.css are rendered by the CSSLink control using this way:

The Themable/wiki.css is registered at the wiki page template level in the wkpstd.aspx file located at 14/TEMPLATE/DocumentTemplates/wkpstd.aspx
You will find the instruction in the PlaceHolderAdditionalPageHead:

<SharePoint:CssRegistration runat="server" Name="wiki.css" />

- For the Themable/search.css reference it is much more tricky to find and explain:

If you examine the v4.master you will find a delegate control

<SharePoint:DelegateControl runat="server" ControlId="SmallSearchInputBox" Version="4" />

This delegate gives us the choice to call different kind of search box at the top of the page.
The link to the Themable/search.css is registered at the level of the web control called by the delegate control

There are three possible controls that can to be called by the delegate, they are registered in these three features:

ContentLightup
OSearchBasicFeature
OSearchEnhancedFeature

This the ContentLightup feature has the 12.0.0.0 version ans the scope Farm

and references the Microsoft.SharePoint.WebControls.SearchArea web control located in the Microsoft SharePoint dll

the OSearchBasicFeature feature has the 12.0.0.0 version and the scope WebApplication

and references the Microssoft.SharePoint.Portal.WebControls.SearchBoxEx located in the Microsoft.Office.Server.Search dll

the OSearchEnhancedFeature has the version 14.0.0.0 and the scope WebApplication

and also references the the Microssoft.SharePoint.Portal.WebControls.SearchBoxEx located in the Microsoft.Office.Server.Search dll, but its sequence number is lower and the properties of the feature element (SearchArea.xml) are different.

This is in this component (Microssoft.SharePoint.Portal.WebControls.SearchBoxEx) that the css link to the search.css is registered, in the OnPreRender method:

if (SPContext.Current.Web.UIVersion == 4)
{
CssRegistration.Register("Themable/search.css");
}

But how to know which control is actually called by the DelegateControl?

As you have noticed for these three features, one has the scope Farm and the two other the scope WebApplication.
I have deployed and Entreprise version of SharePoint Server 2010 and the THREE features are actually activated in my configuration:
I could checked it thanks to a providential application page coded by Slinger...

As the lowest sequence number delegate control wins, we have the Microssoft.SharePoint.Portal.WebControls.SearchBoxEx installed by the OSearchEnhancedFeature.

Now, we have to explain the difference between the standard styles and the themable styles because you have noticed that:

in 14/TEMPLATE/LAYOUTS/1033/styles directory there is a folder called Themable where you can find files that are already present in the styles folder
the CSSLink control by default, references the corev4.css file that is located in the Themable folder
the Microsoft developer that has coded the SearchBoxEx web control has choosen to reference the search.css in the Themable folder
although the wiki.css in not registered with the Themable instruction, the rendered link references the wiki.css file located in the Themable folder

What all that does mean?
All this is linked to the new implementation of themes in SharePoint 2010. So, let us check the difference between the standard styles and the themable styles

3 - Specifying the themable styles

I have already talked a bit about SharePoint 2010 new themes in my previous post on the Managing the CSS styles for the SharePoint 2010 wiki pages and since the RTM delivery, things have been changed since the automatically generated themes files are now stored in another location than in the SharePoint 2010 Beta version.

When applying a theme in SharePoint 2010 the product takes the THEMABLE css files and generates automatically the new css files required for the theme and store them bellow the
_catalog/theme/Themed/ virtual directory within the content database.

What is important to know is that you CAN specify which css file will be involved when applying a specific theme and which will be not, ie what file is themable and what is not.

In SharePoint 2010, the CSSRegistration web control has now a new method CssRegistration.EnableCssTheming Property

Important: There is also a property called EnableTheming, so do not mistake EnableTheming that is inherited from System.Web.UI.Control for EnableCssTheming that is a new feature of SharePoint 2010 corresponding to the new SharePoint 2010 themes implementation.

that can be used with the declarative way:

<SharePoint:CssRegistration runat="server" Name="customStyles.css" EnableCssTheming="true" />

"Fantastic!" you might think, but wait a minute, and keep focusing because its use and understanding is less than simple...

For instance, assume you allow yourself to perform quick tests of this control by customizing the template of the wiki pages (wkpstd.aspx) that is (I don't need to tell) not a thing to do in the real life.

So add a customStyle.css file in the lcid/Styles folder AND in the lcid/Styles/Themable folder
Then, place the previous declaration without the EnableCssTheming property within the template above the wiki.css registration and you will have this:

<SharePoint:CssRegistration runat="server" Name="customStyles.css" />

<SharePoint:CssRegistration runat="server" Name="wiki.css" />

now check the source html of the wiki page and surprise...

The exact same configuration and operation for the two files gives TWO different results. Why?

Especially, why, in the case of the wiki.css, although the EnableCssTheming is not set to true in the wkpstd.aspx template, the rendered link has the /themable/ path?
It is because we used the name of the file instead a path beginning by a '/'. The rule is the following:

If you pass a name of the following files as a parameter of the name property of the new SharePoint.CssRegistration web control, the generated link will ALWAYS reference the themable file:

blog.cs
calendarv4.css
corev4.css
datepickerv4.css
discthread.css
forms.css
groupboard.css
help.css
layouts.css
mblrte.css
menu.css
minimalv4.css
mws.css
owsnocr.css
survey.css
themev4.css
wiki.css
wpeditmodev4.css

These files references are neither in a CAML file nor in the Database, but hardcoded in the NormalizeThemableCssFile method within the CSSLink web control.

So if you want one of THESE native css files present in the themable folder NOT to be themable you must give the COMPLETE reference to the same file that is not in the themable folder:

<SharePoint:CssRegistration runat="server" Name="/_layouts/1033/styles/wiki.css" />

this DOES NOT work

<SharePoint:CssRegistration runat="server" Name="wiki.css" EnableCssTheming="false" />

Your file will remain themable anyway because it is one of the default themable css files!

On the other hand if you want either, one of the custom css files present in the themable folder, or one of the native files that are not in the default themable files list to be themable you must ,

either specify it explicitely

<SharePoint:CssRegistration runat="server" Name="custom.css" EnableCssTheming="true" />

or give a reference using a relative path starting from the Themable folder

<SharePoint:CssRegistration runat="server" Name="Themable/custom.css" />

or give a reference using a relative path starting fome the server

<SharePoint:CssRegistration runat="server" Name="/_layouts/1033/styles/Themable/custom.css" />

notice that if you don't give to the Name property a complete path but just the file name, and there is no corresponding file in the Themable folder, as SharePoint 2010 will check in the folder for this file, you will have an Exception.

Notice that you will have also an exception if the path is not just the file name but a real path and it does not start by a '/' (Except if the first word is Themable).

And finally if the path is well formed but is not good, you will not have any raised exception, but the page will not find your CSS file and you will not see your styles appear at the page displaying.

Now, we are going to examine the imperative side, it is no more simple...

If we look at the Microsoft documentation of the Microsoft.SharePoint.WebControls.CssRegsitration.Register method, we notice that we have the following overload

Registers the specified cascading style sheet (CSS) in master pages, content pages, or .ascx code pages, and specifies whether to reference the themed version of this CSS file if a theme is applied.

And we can see it with the Visual Studio intellisense

Important: this method has been completely rewritten for SharePoint 2010, and there is now an overload for EnableCssTheming. The parameter enableTheming that you can see on the screenshot showing Visual Studio Intellisense is corresponding to the EnableCssTheming property of the control that is a new feature of SharePoint 2010 for the SharePoint 2010 themes implementation. Do not mistake this parameter (EnableTheming) with the EnableTheming property of CssRegistration that is inherited from System.Web.UI.Control

I know it is difficult to understand and I was puzzled myself so to conclude :

Forget CssRegistration.EnableTheming, you don't need it, it is for the ASP .Net themes
CssRegistration.EnableCssTheming and the boolean parameter enableTheming of the method CssRegistration.Register(String,Boolean) are the same exactly although the names are different.

So, our previous Microsoft developer when implementing the Microssoft.SharePoint.Portal.WebControls.SearchBoxEx, had to specify the themable folder because the search.css is not themable by default (Although it is one of the native SharePoint 2010 css files present in the themable folder), but he (she) could have also written:

if (SPContext.Current.Web.UIVersion == 4)
{
CssRegistration.Register("search.css",true);
}

if (SPContext.Current.Web.UIVersion == 4)
{
CssRegistration.Register("search.css",true,"4");
}

For ending,

If you want to register a themable css file programmatically, consider overriding the OnInit method.

To obtain themable references (You will notice that I have omited the Themable/ path for the wiki.css on purpose because here also, we can omit the path for the ccs files that are themable by default.)

That can be used when applying a SharePoint 2010 theme.

Conclusion

If you want your custom CSS to be a part of a SharePoint 2010 theme, you must use the CssRegistration web control.
Never, ever remove the CSSLink control from a SharePoint 2010 master page.
One fantastic thing : If you add a themable css file reference programmatically to a site, you have not to re apply the theme. The css is automatically included within the theme references when refreshing the page.

This is some of my other posts on the topic:

--> Use a delegate control to reference a CSS at the wiki page level: Managing the CSS styles for the SharePoint 2010 wiki pages

--> To se the dynamic loading of the styles by debugging the SharePoint 2010 Ribbon and think about changing the CSS for the wiki pages: Customizing and branding the SharePoint 2010 wiki pages

Monday, June 7, 2010

Migrating to SharePoint 2010

Introduction

This post will show 2 possible scenarios to migrate from MOSS 2007 to SharePoint 2010. In order to demonstrate one of the worse case, we will start from a farm running MOSS 2007 SP1 on 32-bit Windows 2003 server OS. I have chosen two hybrid scenarios among those exposed in the Microsof documentation Determine upgrade approach (SharePoint Server 2010) because their are safer since for each scenario we will upgrade on a copy of the farm:

1: Database attach with read-only databases
Lets you continue to provide read-only access to content in your MOSS 2007 web sites during the upgrade process. For this approach, you set the MOSS 2007 databases to read-only while the upgrade is in progress on another farm where SharePoint 2010 is deployed. This method reduces perceived downtime for your users.

2: In-place upgrade with detached databases on a separate Farm
Lets you take advantage of an in-place upgrade's ability to upgrade content and settings, while adding the speed of a database attach upgrade. For this approach, you use an in-place upgrade to upgrade the farm and settings on a separate farm that is a copy of the farm, and to detach and upgrade multiple databases in parallel on this separate farm.

Before detailing the steps required for these scenarios I would like to draw up the list of the benefits and drawbacks of these hybrid scenarios comparatively to the two basic approaches (in-place and database attach):

Pros:

Safer : you upgrade the content for the environment on a separate farm so you keep your old MOSS 2007 Farm intact.
More service availibility: Although the sites of your old MOSS 2007 Farm that are involved in the migration process are in read only mode, they still can display content to the users during the migration process. The sites that are not involved can be used as usual. This method reduces perceived downtime for your users.
Faster upgrade time: You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade.
More flexibility: You can use a database attach upgrade to combine multiple farms into one farm that allows you to take advantage of the migration to reorganize your architectures.
Cleaner: as you have to replicate all the environment configurations and customizations on the new farm, you will take advantage of this work to move only the nece ssary files and perform only the necessary configuration operations.

Cons:

More expensive : Except if you are using virtualization, you will have to plan until twice more machines than for In Place upgrade.
More work : You will have to replicate all your old Farm cutomizations on the new SharePoint 2010 Farm

And here are the pros and cons of these two hybrid scenarii:

1 - Database attach with read-only databases
Pros
If you’re running MOSS, each Shared Service Provider (SSP) and its settings will be upgraded and converted into new service applications. Source: Migrating to SharePoint 2010
Cons
You will have to mount a MOSS 2007 farm on 64-bit, then use an In Place uprade on the new farm for the settings, finally use an attach database upgrade for the content.

2 - In-place upgrade with detached databases on a separate Farm
Pros
You have not to upgrade your MOSS 2007 farm to 64-bit, then to upgrade it to SharePoint 2010, you save one step
Cons
For those running MOSS 2007, you should know that a database-attach upgrade won't fully upgrade your SSP into new service applications. When you attach an SSP database, only your user profile store is upgraded. Search settings, Excel Service settings, Business Data Catalog (BDC) application definitions, and other settings must be recreated from scratch. Source: Migrating to SharePoint 2010

Conclusion : if you have a lot of SSP settings like advanced search settings, wide use of Excel Services,etc. consider to use the scenario 2 otherwise, scenario 1 is quicker.

Steps of the migration

1 - ugrading the SharePoint Farm with MOSS 2007 SP2
2 - upgrading the SharePoint Farm with MOSS 2007 October 2009 Cummulative Updates
3 - running the pre-upgrade tool: pre-upgrade checker
4 - Scenario 1: performing database attach upgrade with read-only databases
4.1 - Building a SharePoint 2010 Farm
4.2 - Determining how to handle customizations
4.3 - Moving the customization to the SharePoint 2010 Farm
4.4 - Moving and Upgrading the Content to the SharePoint 2010 Farm
4.5 - Restoring and Upgrading the Content on the SharePoint 2010 Farm

5 - Scenario 2: In-place upgrade with detached databases on a separate Farm
5.1 - Copying the MOSS 2007 farm to upgrade to 64-bit
5.2 - Performing an in-place upgrade to upgrade the farm and settings
5.3 - Moving the Content to the SharePoint 2010 Farm
5.4 - Restoring and Upgrading the Content on the SharePoint 2010 Farm
5.5 - Fixing the customizations.

1 - Ugrading the SharePoint Farm with MOSS 2007 SP2

1.1 The different operations list

One of the prerequisites before migrating to SharePoint 2010 is to patch your SharePoint farm to at least MOSS 2007 SP2. This requires several operations:
Running the SP2 fo WSS
Running the WSS SP2 for each Langauge Pack
Running the SP2 for MOSS 2007
Running the MOSS 2007 SP2 for each Langauge Pack
Doing all that for each server of the Farm

1.2 A sequence sample

For each hotfix the sequence will be the same.

First you will have to run the installation of binaries.

After the hotfix binaries installation, the SharePoint Products and technologies wizard will be launched,

There will be a first warning informing the system administrator that IIS, SharePoint Administration Service, SharePoint Timer Service may have to be started or reset.
But, more important there will be another message that will inform that the same upgrade operation has to be done on every Server of the Farm.

Then the wizard will perform the configuration steps.

It will inform the system administrator that the configuration was successfull

With this windows for WSS 3.0

and this one for MOSS 2007

Finally, when closing the wizard, the SharePoint Central Administration web site will be lauched.

1.3 Validating the Upgrade

First of all let us check the version of our SharePoint Farm. You can check the version number on the settings page of any SharePoint site of the Farm, or in the Central Administration on the "Servers in Farm" Page.

You notice that SharePoint 2007 SP1 correspondig to this version number : 12.0.0.6219

What you have to check after having applied the WSS 3.0 SP2 upgrade, is obtaining this new version number : 12.0.0.6421

What you have to check after having applied the WSS 3.0 Language packs SP2 upgrade, is obtaining the updates information for the language packs in the "Add and Remove Programs" pannel:

What you have to check after having applied the MOSS 2007 SP2 upgrade, is obtaining the update information for MOSS 2007 in the "Add and Remove Programs" pannel:

It seems that there is no way to check the complete installation for MOSS 2007 language pack SP2, in my case, the "Add and Remove Programs" pannel did not show the update information as you can notice on the above picture.

Now is the time to navigate through SharePoint Portals of the upgraded farm in order to check they still run perfectly well.

2 - Ugrading the SharePoint Farm with MOSS 2007 October 2009 Cummulative Updates

While it is enough to upgrade a MOSS 2007 Farm with SP2 to be allowed to migrate to SharePoint 2010, and that is the minimal step to get the SharePoint 2010 pre udate checker installed, it is worth to uprade the Farm with October 2009 Cummulative Updates in order to have the best version of the tool.

Download the MOSS 2007 October 2009 Cummulative Updates

You will have to register to obtain them. The link to them will be sent to you by e-mail with the password to unzip them.
Then you will run them and the sequence will be the same than for the SP2.

Here is the screen shots of the the "Add and Remove Programs" pannel after the upgrade:

And you have to obtain this new version number after having run the update: 12.0.0.6520

3 - Running the pre-upgrade tool: pre-upgrade checker

Now that we have the best version of the SharePoint 2010 pre udate checker installed, because we performed an update with October 2009 Cummulative Updates, we can now run the tool.

Open an command prompt and if the STSADM.exe path is registered in the environment variable of the machine, type the following command:

stsadm -o preupgradecheck

The tool runs and traces the Potential Upgrade Blocking Issues for a migration to SharePoint 2010.

It is also generated a more complete report in html format:

If we refer to the found blocking issues, they are totally normal since, the machine OS is in 32-bit and is not a Windows 2008 version, and SQL Server 2008 is in 32-bit and was not updated. I have also several SharePoint artifacts references in the content databases but the referenced files are no more present in the file system of the server. I should have to clean them although they are no more used by any site.
So what all does this mean ? It means that we are not allowed to perform an upgrade on THIS machine (ie an In Place Upgrade), but there is good chances that a database attach upgrade works...

4 - Scenario 1: performing a database attach upgrade with read only databases

In our case, an attach database upgrade requires two conditions:

Having a SharePoint 2010 ready to use Farm to receive our machine databases
Determine how to handle customizations

4.1 - Building a SharePoint 2010 Farm

In order to train for building such an environement, you can use my previous post: Installing SharePoint 2010 on Windows 2008 Server R2 that is an example of how to mount this kind of environment using only free and trial versions of the involved products for a development machine. If you want to mount a real production environment I have also provided links to the corresponding documentation.

Do not forget to install the same language packs as in your SharePoint 2007 source farm.

4.2 - Determining how to handle customizations

First, this is the Microsoft recommendations: Determine how to handle customizations

- the case of the compiled code.

Although customizations for SharePoint come in many forms (Site templates , Site definition, Feature, Workflows and server controls, Event handler, Web Parts, Master pages and CSS files, etc.) I would like to focus now on the compiled code.
There were many questions I have read on Forums and Blogs about "Do we have to recompile or rewrite the code for a migration to SharePoint 2010 ?".
I have found several answers and the good news is that in many cases neither rewriting the code nor even recompile it won't be necessary.

but I would like to display two excerpts of the Microsoft documentation that illustrates what you have to deal with :

Excerpt 1
[...
Existing applications

You must recompile existing 32-bit applications and custom assemblies (for example, Web Parts and event receivers) to run on the 64-bit architecture because the 64-bit edition of SharePoint cannot load a 32-bit assembly. Before you recompile existing applications or custom assemblies, verify that they are compiled to run on both architectures. If this is the case, do not compile them for a single architecture. (In Microsoft Visual Studio this build option is Any CPU.)

If the existing applications are third-party applications, check with the third-party vendor regarding 64-bit versions and compatibility. In the case of custom contracted solutions for which you do not have the source, verify the solutions in a test 64-bit environment to ensure compatibility.
..]

In Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)

Excerpt 2
[...
Obsolete Classes and Namespaces

Because the changes to the API in the upgrades are backward compatible, you should not have to make any changes to your Windows SharePoint Services 3.0 or Office SharePoint Server 2007 custom solutions before you redeploy them in either SharePoint Foundation 2010 or SharePoint Server 2010. Some classes and namespaces are obsolete, but they will continue to work as expected. If you want to start upgrading your applications so that they use the most current classes and methods, recompile your code. The compiler warnings will tell you which elements of the object model are obsolete, and which newer alternatives you should use. Figure 3 shows an example compiler warning and the corresponding mouse-over warning in Visual Studio 2010.
..]

in Redeploying Customizations and Solutions in SharePoint Foundation 2010 and SharePoint Server 2010

So the philosophy is the following:
you can deploy a dll compiled for MOSS 2007 using the "Any CPU" or x64 build option on a SharePoint 2010 server and it will work using the 64-bit process, but if you want an optimized code you should recompile it with the new SharePoint 2010 object model. So in many case it won't be necessary to recompile but it is recommended to do it to optimize your code and to learn the new SharePoint 2010 object model.

I have published a first post on the topic: Migrating custom assemblies to SharePoint 2010 that explains some important concepts to take into account and gives an example for a Web Part , and am planning to detail some more operations for at least Event handler.

- other customization

I have not performed advanced searches on topic until now, but am planning to do it, and will certainly publish some posts on specific operations like I did for custom assemblies. Looking to the table listing the diffrent kinds of customizations and the migration impact on it, presents in the Microsoft documentation (Determine how to handle customizations ), I see 4 main important areas to review:

Information architecture - sites provisionning
Site definition and site templates
Managed paths (inclusions/exclusions)
Look and Feel - UI Experience
Themes
Toolbar actions
Master pages and CSS files
Custom code
Workflows and server controls
Event handler
Web Parts
Services
Authentication providers
Search provider or security trimmer
JavaScript
Features

4.3 - Move Customizations to the SharePoint 2010 Farm

Depending on the decision you took about handling your customization, you can either move it on the SharePoint 2010 target platform and test it or rewrite it for SharePoint 2010 to take advantage of the new product benefits.
For the current tests, I have deployed SharePoint solutions (.wsp), installed features that was not packaged in .wsp, using the stsadm tool and typing exactly the same command lines than in SharePoint 2007 and during my content database upgrade, all the deployed files were retrieved by the upgrade process.

4.4 - Move Content to the SharePoint 2010 Farm

Once your customizations are properly handled for SharePoint 2010, it is the time to move the content. Here are the operations for an attach database upgrade.

First this is the Home page of one of the Web Application of the MOSS 2007 farm I am going to migrate. As you may notice, I took a standard site definition : the Collaboration Portal, with a few custom Web Parts and features as customizations.

Open SQL Server management studio and locate the Database you want to migrate and display its properties pane.

Set the Database Read Only to true

You will notice that the database icon will turn to gray

And that all the corresponding SharePoint site are now in read only mode.

Then perform a back up of the Database, and move this back up on your SharePoint 2010 Data Base Server.

4.5 - Restoring and upgrading the Content on the SharePoint 2010 Farm

First copy the back up of your SharePoint 2007 content darabase in the right folder to prepare to restore this backup.

Then, create a new Web Application on your SharePoint 2010 farm to host the content dabase to be restored.

Then, open the SQL Server Management Studio of your SharePoint 2010 farm Database Server

Detach the content database...

to drop the existing connections

then, re attach the same database

You can now restore the database coming from the SharePoint 2007 farm

Do not forget to check the option: overwrite the existing database

Very important : grant the db_owner permissions to the Set-up account the wich you will be logged-in with when you will perform the upgrade for the new database, otherwise the upgrade will definitively fail!

and you will have this error in the log file

[STSADM] [SPUpgradeSession] [ERROR] [5/31/2010 11:56:27 PM]: Exception: Cannot open database "WSS_Content_WebApp81" requested by the login. The login failed.
Login failed for user 'VMDEV-012\Administrator'.

Finally, open a command prompt on a SharePoint 2010 server that hosts the SharePoint 2010 central Administration and type the following command:

stsadm -o addcontentdb -url yourWebApplicationUrl -databasename yourDatabasename -databaseserver yourdatabaseServerName

While the upgrade is being processed you will be informed of the percentage of data upgraded...

But more interesting, a page especially dedicated to upgrade status is available in the Central Administration Web site in SharePoint 2010 and is refreshing automatically giving you the number of warnings and errors encountered during the upgrade process, and informing you about the site that is involved by the upgrade process.

Finally, the upgrade process has been completed and you can review the upgrade log.

While there are some errors the Status will be "Failed", but it does not mean that your SharePoint site will not be available. For example, assume you have provisionned some files or a list by using a feature and that someone has removed the files or the list from the SharePoint site and removed the feature from the file system of the source farm without uninstalling it.
Your upgrade will be sucessful since the pages provisionned are no more required, but the reference of the feature is still in the SharePoint content database, and while the upgrade process does not find the feature in your SharePoint 2010 file system you will have an error and the upgrade will be set to "Failed", but you will be able to perfectly use all the functionnalities of your upgraded Sharepoint 2010 site.

and have a content database perfectly restored

In my case for a native Collaboration Portal of Moss 2007 I obtained several errors on missing features, because either they were missing in the MOSS 2007 farm file system anyway, or because I forgot to copy them in my new SharePoint 2010 server. But one was because it seems that the SharePoint 2010 release is missing a MOSS 2007 feature.

Warning : It seems that since the feature DocLibLanguageFiltering is missing on the Sharepoint 2010 release, while performing an upgrade of a site based on the document center site definition, you will always have this two errors:

[STSADM] [SPContentDatabaseSequence] [ERROR] [6/7/2010 1:01:32 AM]: Found a missing feature Id = [00bfea71-e717-4e80-aa17-d0c71b360102]
[STSADM] [SPContentDatabaseSequence] [ERROR] [6/7/2010 1:01:32 AM]: The feature with Id 00bfea71-e717-4e80-aa17-d0c71b360102 is referenced in the database [WSS_Content_WebApp-81], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.

To fix this issue, take the feature on the MOSS 2007 farm, and install it on the SharePoint 2010 farm.

So, if you want a perfect upgrade without one single error, you will have to review the upgrade error log file, fix the error, then
remove the content db
Close its connection by detach re attach it in SQL Server
Restore again the source fram content db backup
Set up the Administrator permissions
Perform an upgrade

Untill you obtain that screen!

You have to change the permissions for the Site Collection administrator(s)

Then, check all the functionnalities of the upgraded portal are available.

4.5 - Perform a Visual Upgrade

Now, if you really want to have a complete upgrade that allows you to take advantage of the new SharePoint 2010 user experiece, you have to perform a Visual Upgrade, so locate the menu

Choose a preview or a definitive visual upgrade

Anyway, start enjoying the new UI of SharePoint 2010 by editing the home page and changing a label...

Well done !

5 - Scenario 2: performing an "In-place upgrade"

5.1 - Building a SharePoint Farm running MOSS 2007 64-bit on Windows server 2008 R2

will be published soon...

5.2 - Moving Customizations on SharePoint Farm running MOSS 2007 64-bit on Windows server 2008 R2

will be published soon...

5.3 - Performing In Place Upgrade

will be published soon...

5.1 - Moving and Upgrading Content on SharePoint Farm running MOSS 2007 64-bit on Windows server 2008 R2

will be published soon...

6 - Aknowledgements and useful links

Thanks to Randy Williams for his post : Migrating to SharePoint 2010

First, the link on the topic in the SharePoint 2010 site ressource center: Upgrade and Migration for SharePoint Server 2010

A good article in Technet magazine: Get Ready for SharePoint 2010

One of the post of Joel Oleson What NOT to Migrate into SharePoint 2010 that has, by the way, published a book on the topic.

Azure & Co

Saturday, June 12, 2010

CSS Registration and Rendering for SharePoint 2010 (including themes)

Monday, June 7, 2010

Migrating to SharePoint 2010

About Me

Followers

Blog Archive