Upgrading Large Microsoft® Office SharePoint® Portal Server 2003

Intranet Portals to Microsoft Office SharePoint Portal Server 2007

Published: March 19, 2007

By Eric Charran
Microsoft Corporation
February 2007

Applies to:
Microsoft Office SharePoint Server 2007
Organizations that are upgrading large enterprise portals from Microsoft Office SharePoint Portal Server
2003 to Microsoft Office SharePoint Server 2007 require the ability to conduct the migration with minimal
impact to dependent business users while ensuring that portal content, taxonomy and design are all
maintained and optimized. After the migration, users will expect that their MySites (including all their
customizations, links, alerts, documents, etc.) will have been migrated as well. By understanding the
implementation details of SharePoint Portal Server (Office 2003 Version) and Office SharePoint Server,
organizations can more effectively meet the goals of upgrading large portal and MySite implementations.

1
The information contained in this document represents the current view of Microsoft Corporation on the
issues discussed as of the date of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot
guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights
under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these patents,
trademarks, copyrights, or other intellectual property.

 2007 Microsoft Corporation. All rights reserved.

Microsoft, Excel, InfoPath, SQL Server, and SharePoint are trademarks of the Microsoft group of
companies.

All other trademarks are property of their respective owners.

2
Introduction
Organizations with a large investment in SharePoint® Products and Technologies have been recipients of
significant innovations in enterprise collaboration and portal capabilities. These features include document
management, information sharing and Microsoft® Office integration. In many large organizations,
SharePoint Portal Server has experienced large enterprise implementation growth. In many cases, the
growth within a single organization is either controlled or uncontrolled. In organizations that have
consciously practiced a controlled growth model, administrators that are well-versed and trained in
SharePoint Portal Server design and architecture, as well as best practices, have been able to apply design
and usage guidelines to allow all areas of the organization to benefit from SharePoint. These organizations
often have carefully thought out SharePoint Portal Server farms, a well-defined taxonomy, and a mature
method of site requisition, management and deletion. In these instances, it is a rarity for stale sites and
portals to pollute the organization's SharePoint Portal Server structure.
Conversely, organizations that have not devoted the resources to tightly managing and planning the
SharePoint Portal Server infrastructure often must deal with multiple undesired management effects. These
include the uncontrolled propagation of sites and portals, inconsistent security models and access right
delegation (i.e., everyone is an administrator), stale or aging portals which are no longer used, and other
aspects of uncontrolled usage and growth. In addition, the job of administering the infrastructure of the
portal falls to an administrator whose primary responsibility often supersedes maintenance and
administration of SharePoint. These administrators often simply ensure that the boxes which host SharePoint
Portal Server are running. They are often reticent to delete or remove stale materials for fear that someone
might require it. They also have difficulty keeping up with the growth of the portal and the users and groups
within the company that are leveraging it.
Regardless of the growth model within the organization, the migration to Office SharePoint Server is one
that requires organizations to have a complete understanding of their SharePoint Portal Server environment.
This understanding is crucial to providing a foundation for the upgrade into Office SharePoint Server and
ensuring that the organization benefits from an Office SharePoint Server taxonomy and physical architecture
that supports current usage and controlled growth. While there are many similarities between the objects
found within SharePoint Portal Server and Office SharePoint Server, there are also significant architectural
differences between the two products. Office SharePoint Server provides a wealth of upgrade options and
flexibility that administrators and portal planners must understand to ensure an optimal structure that
accommodates current SharePoint Portal Server usage.

Procedural Upgrade Prerequisites

In order to move to Office SharePoint Server, there are certain envisioning tasks that organizations should
conduct to provide a solid foundation for the implementation. These are high-level conceptual prerequisites
that facilitated by a Microsoft Solutions Framework (MSF) or Microsoft Operations Framework (MOF) iterative
project cycle for software deployment. For more information on MSF and MOF project planning and
implementation, see the TechNet home for the Microsoft Solutions Framework as well as the TechNet home
for the Microsoft Operations Framework.
While the details of the organizational properties of these project frameworks and their industry equivalents
are beyond the scope of this documentation, project planners should ensure that the following concepts are
represented in the project plan. By understanding these concepts, even organizations that maintain an
uncontrolled growth model for SharePoint Portal Server administration, management and usage can
transition to a well-defined Office SharePoint Server implementation.

3
Understand the Existing SharePoint Portal Server Environment
For organizations that do not have a good audit trail or understanding of the SharePoint Portal Server
environment, it is important to become familiar with the depth and scope of its usage. Organization
implementers should identify portal users, study their own implementation and use that information to
develop a model of usage that would allow designers to map out the current taxonomy of SharePoint Portal
Server.
By understanding the current environment, developing a proper existing taxonomy and identifying usage for
sites, designers can identify points of synergy and overlap in the SharePoint Portal Server implementation.
Often, organizations can find that collapsing or combining sites into an organizational structure is beneficial
not only to portal management and physical implementation, but to users of the portals as well. Based on
the identified map of the existing SharePoint Portal Server environment, coupled with the business drivers
behind identified portal area content owners and users, implementers can obtain a good understanding
about site usage. Additionally, implementers will also understand how to organize the Office SharePoint
Server architecture using best practices.
Some critical elements to understand are as follows:
Upgrade Planning Information

Type of Analysis Measure Description

Logical Number and Type of By understanding the number and type of sites, organizations can
Implementation Existing Sites develop a manifest that can be used to interview owners,
determine usage and find key content business owners for
validation (whether or not the portal is current and is used)

Logical Audiences for Existing Understanding the audiences for existing sites will help determine
Implementation Sites how the Office SharePoint Server implementation will be
configured to support the security and access structure for these
sites post-migration and whether existing sites can be
consolidated

Logical Site Access Methods By understanding the method of access, both current and future
Implementation and Requirements desired state, planners and implementers for Office SharePoint
Server can design an Office SharePoint Server implementation
that satisfies the requirements (i.e., extranet or internet access
using Forms Based Authentication)

Logical Site Feature Usage Planners should obtain a list of utilized features to ensure that
Implementation and Requirements current site templates are appropriate in SharePoint Portal Server
as well as interview content owners to determine which Office
SharePoint Server features would be of interest to them

Physical Size of Existing Sites Once the number and type of existing sites are identified, a
Implementation Content Database primary input to the planning of migration and organization for
Organization Office SharePoint Server will be how the physical structure of
SharePoint Portal Server exists.

Physical Size and Placement of Both the physical layout of servers within the farm as well as the
Implementation Existing Server Farm physical implementation of sites within Virtual Servers inside
Infrastructure SharePoint Portal Server should be understood and cataloged such

4
Type of Analysis Measure Description

that planners can correlate SharePoint Portal Server Virtual

Servers to newly design Office SharePoint Server Web Applications

Understand the Basics of Office SharePoint Server

While there are many similarities between SharePoint Portal Server and Office SharePoint Server, there are
differences in the way Office SharePoint Server is implemented. In addition, there are some well-
documented best practices for the implementation of Office SharePoint Server Web applications and physical
architecture. Many of these best practices surround the management and performance aspects of
establishing Office SharePoint Server in the enterprise. The objects within Office SharePoint Server related
to sites and Web applications inherently facilitate the creation of a structured taxonomy. This taxonomy will
inherently support ease of management (including backup, restore and portability of sites, site collections
and content databases), performance of individual sites, as well as flexibility for fault tolerance and ease of
access from both internal and external users.
The two categories of Office SharePoint Server implementation that planning teams should focus on are
performance and manageability. By understanding and focusing on these elements and their associated best
practices, the implementation and design team can craft an upgrade strategy from SharePoint Portal Server.

Design an Office SharePoint Server Taxonomy for Site Structure

After understanding and documenting the existing SharePoint Portal Server architecture, the implementation
team should conduct design sessions that outline the taxonomy or structure of the implementation in terms
of Office SharePoint Server objects. Designers should focus on identifying the existing portal elements and
express them as Office SharePoint Server web applications, site collections and Office Server features.
Taxonomy refers to site structure and organization as it relates to portal architecture and is relevant to the
Office SharePoint Server design process. This design process helps ensure that each migrated site from
SharePoint Portal Server performs as desired and is individually manageable. Taxonomy definition also will
define elements (including navigation), that will determine how sites are placed within site collections and
web applications. The design team should involve an infrastructure and network architect to establish and
map DNS names to Office SharePoint Server web applications.
By establishing well-defined site taxonomy, supported by a documented Office SharePoint Server
infrastructure, the organization will have created an early foundation for site administration and governance.
The goal is to ensure that any new sites that are created or requested will fit within the taxonomy. For those
sites that may not fit within existing taxonomy, portal architects and designers can adjust and republish the
taxonomy so that the organization clearly understands the rules for site creation and location.

Design an Office SharePoint Server Physical Architecture

Adjacent to the activity of taxonomy design, the physical architecture of the Office SharePoint Server farm
must also be designed. By understanding existing site and feature usage, the designers can identify and
document a physical design that will service all required portal users, use cases and business scenarios. As
inputs to the design process, elements of access, security, required/desired features, workflows and
connectivity to internal systems should be addressed in the physical server farm design. While the specifics
of planning an Office SharePoint Server farm are beyond the scope of this documentation, the following list
of items will help farm designers understand how to design the physical server farm.
Office SharePoint Server Farm Design Requirements

Requirement Impact on Farm Design

Site Access and Office SharePoint Server provides organizations the ability to serve sites to internal

5
Requirement Impact on Farm Design

Availability to Users intranet, extranet and internet users as well as support out of the box (OOB) and
custom built authentication methods. The placement of the farm within the
organization's infrastructure (i.e., DMZ placement, firewall configuration and rules,
etc.) will depend primarily on the authentication and access requirements of the
users.

Required/Desired Features such as Office Integration, Excel® Server, InfoPath® Forms Server,
Features Workflow and Enterprise Search are all determinants into how the farm is created
and arranged to meet scalability and manageability demands

Integration with Existing Enterprise Application Integration (EAI) requirements for the portal will be driven
Applications/Systems by business requirements and force designers to consider Business Data Catalog
(BDC) configuration from a physical perspective which includes single-sign on,
network paths and protocols for system connectivity

Search Requirements While Enterprise Search can be considered a feature, it often requires more
planning and consideration especially when designing the physical server farm and
includes tasks such as identifying search sources, indexing requirements and
availability of search in the farm

Farm Availability Office SharePoint Server server farm topology should be configured such that the
Requirements physical design meets with the intersection of various user's requirements for
availability and uptime

Component Manageability As discussed below, component manageability

In addition to the above concepts, review of the Planning and architecture for Office SharePoint Server 2007,
which outlines the planning required for Office SharePoint Server farm implementation within an enterprise,
is recommended.

Understand the Office SharePoint Server Upgrade and Migration Approaches

Once the implementation and design team understand the existing SharePoint Portal Server infrastructure
and gain a complete understanding of how Office SharePoint Server needs to be deployed within the
organization, the team must build a strategy to get from the existing portal to an upgraded server farm. In
order to facilitate this, the team must become extremely knowledgeable about the upgrade methods that
Office SharePoint Server makes available. Understanding these upgrade approaches will affect how the
product is installed and eliminates repeat work when the end result is not the desired one.
Independent of understanding and selecting upgrade options, the implementation team must also determine
the physical method for the migration. This will vary depending on the method chosen and may include the
specification of an independent migration server to upgrade content and allow for testing before final
migration to the destination server farm.

6
Office SharePoint Server Implementation Design Guidelines for Large
Portal Upgrade
As mentioned above, a solid Office SharePoint Server architecture addresses several goals. Principle among
these goals is manageability and performance. They encapsulate a solid foundation of an Office SharePoint
Server implementation and provide a fundamental focus for ensuring that the organization maximizes the
use of the product. Within each of these categories, several immediate practices and techniques should be
used when planning and conducting an upgrade.

Management
From a management perspective, planners and implementers should consider not only the immediate
upgrade timeframe, but also a situation in which the Office SharePoint Server footprint within the enterprise
will experience growth. The goal is to avoid a situation where an organization experiences uncontrolled
growth of sites that become an administrative challenge for the support department. These situations can
threaten the performance and operating integrity of the product. Thus, Office SharePoint Server
management should be considered at multiple points during the planning exercise. For an upgrade planning
process, the concept of component management focuses on the physical architecture of the production farm
and its components. These include web applications, services in the farm, features on the server as well as
the locations and roles of farm servers. When designing the web application architecture, manageability of
web applications should play a role in how the SharePoint Portal Server sites, content databases and profile
information will be migrated into Office SharePoint Server.
The manageability of an Office SharePoint Server installation will increase if large monolithic sites are
migrated from SharePoint Portal Server to more modular web applications where activities, audiences and
site templates are more homogeneous. For example, considering the following diagram, the SPS 2003
implementation contains a significantly large site content database that contains a portal, team sites and
MySites. This meant that in SharePoint Portal Server the smallest unit of management was the virtual server
that was housed within this content database.

Figure 1. Typical SharePoint Portal Server (Office 2003 version) Large Intranet Portal Structure

7
As depicted above, a single content database houses a SharePoint Portal Server portal site, custom areas,
MySites and other additional team sites and subsites. While for a smaller enterprise, this configuration was
more than adequate, as the growth and usage increases, administrators will struggle to maintain
performance in this configuration. In addition, if a simple upgrade to Office SharePoint Server occurs, the
new web application will maintain a similar structure. Again, while this may be satisfactory for a smaller
enterprise, a larger company (for example an organization with a heavy investment in SharePoint Portal
Server with a MySite usage of around 2000 sites, or company with a single content database greater than
30 GB) will have a challenging time maintaining performance and scaling the site to meet new demand.
Additionally, challenges will arise when it comes time to move components of the architecture between
farms when scaling out in the future.

Performance
From a performance standpoint, Office SharePoint Server planning and architecture guidelines suggest that
content databases be segregated based on the primary site template that is defined for the site collection.
For example, combining a MySite Host with a Collaboration Portal site collection in a single web application
can cause performance issues as well as scalability and manageability challenges. Performance is a critical
factor in ensuring the usability of the portal. Best practices state that a physical separation across web
applications is warranted when the size of a site collection is large, or there is a significant amount of
differing operations that a single content database will have to perform at the SQL Server™ level.
By separating monolithic SharePoint Portal Server sites into separate content databases and web
applications, gains in performance and manageability increase the potential for controlled growth of Office
SharePoint Server within the enterprise.

Office SharePoint Server Strategies for Upgrade

Planning a Strategic Approach to Upgrade
When planning an upgrade strategy to Office SharePoint Server, the physical design of the new Office
SharePoint Server architecture (specifically web application and site collection design) should be the starting
point to determine how to conduct the migration. Larger portals based in SharePoint Portal Server that have
monolithic content databases will need to be addressed. Additionally, there are other scenarios, including
MySite host placement, Team Site placement and segregation of sites from the portal depending on size and
performance, which should be considered when formulating an upgrade strategy.
Foremost in the strategy formulation is the selection of an upgrade model. The upgrade models include
database migration, gradual upgrade and in-place upgrade. While each has their strengths, a single
approach lends itself to migrating large SharePoint Portal Server content databases. Review the Upgrading
to Office SharePoint Server 2007 documentation to understand how to plan and execute an upgrade and the
different options for choosing an upgrade model.

Upgrade versus Migration

Once the upgrade model is selected, the details of how the upgrade will take place should be worked out. A
goal in an upgrade situation should be to minimize the downtime in for users. Additionally, the organization
will require the ability to conduct user acceptance testing (UAT) and sign off on the upgrade prior to going
live. Because of these requirements, large organizations should begin to think of the move to 2007 as more
of a migration than an upgrade. This shift in thinking specifies a coexistence of SharePoint Portal Server and
Office SharePoint Server (much like the gradual upgrade on a single server) within the enterprise and
provides the flexibility for the organization to conduct through repetitive upgrades, low-level inspections of
upgraded site collections and content sign off by responsible parties. By changing the upgrade into a
migration, the organization has the ability to provide a platform for testing the SharePoint Portal Server

8
content on Office SharePoint Server prior to its implementation. The implementers can benefit from this
situation by allowing content owners and testers access to the upgraded platform in order to provide training
and quality assurance as well as a level of end-user exposure to Office SharePoint Server capabilities,
features and changes from SharePoint Portal Server.
The capabilities of virtualized hardware (virtual machines) can provide a virtual migration platform that will
allow implementers quickly test a migration, reset or rebuild the environment and retry migration strategies
much faster than on physical machines (thanks to undo disks and the ability to snapshot and backup images
of the migration environment). In a large corporate intranet migration, the following strategies allow for
maximum uptime from a user perspective and provide flexibility such that the organization can roll back to
the SharePoint Portal Server version.

Site Collection Migration Strategy

Because both the gradual upgrade and database migration approach do not allow the ability to split site
collections from a single content database to multiple Office SharePoint Server web applications,
consideration should be given to large monolithic SharePoint Portal Server databases. Since these databases
cannot be broken across separate Office SharePoint Server applications on upgrade, implementers can either
decide to break them up into smaller content databases prior to the upgrade, or conduct the upgrade first
and then import/export the site collections between Office SharePoint Server web applications. By breaking
the sites up prior to upgrade, each site collection can be assigned to a separate web application during
gradual upgrade or database migration. This is extremely pertinent when it comes to separating disparate
web application functionality within Office SharePoint Server (i.e., such as separating MySites from the
Intranet Portal)
Alternatively, organizations dealing with large site collections can choose to conduct the upgrade first and in
a separate project iteration, cascade over the site collections as upgraded and move them to separate
content databases or between web applications within Office SharePoint Server. This allows organizations to
go to production sooner and then to choose a controlled portion of the larger site collection to move to
different web applications.
For organizations' that do not require all sites in their SharePoint Portal Server installations, the gradual
upgrade approach will allow for the selection of a subset of sites to be upgraded. This saves time and effort
and allows administrators to only upgrade those sites that are to be moved into the production Office
SharePoint Server environment, while leaving behind any site collections that are no longer required.
Conversely, if the entire content of SharePoint Portal Server needs to be migrated, the database migration
approach will work better.

Physical Migration Strategy

For large upgrades, the ability to conduct a migration provides great flexibility and practice for
administrators and implementers, especially when faced with requirements that mandate an immediate
cutover to Office SharePoint Server from SharePoint Portal Server, rather than a simultaneous production
coexistence. In this scenario, in the time leading up to the cutover, implementers can leverage not only a
migration environment but the production environment. The following diagram outlines the individual
element of a large SharePoint Portal Server to Office SharePoint Server migration strategy that includes a
virtualized migration environment.

9
Figure 2. Large Portal Upgrade and Migration Strategy
The components of this environment include the source SharePoint Portal Server portal server. This source is
the current production intranet portal. The virtualized migration server is a migration-only sandbox. Using
this approach, administrators will restore a backup of the monolithic site content database from the
production SharePoint Portal Server into the migration environment. In many instances, the migration
environment will have a significantly smaller hardware profile since no volume Office SharePoint Server
service requests will be directed here. This migration environment is a container to allow the upgrade to
take place prior to shipping the upgraded contents to the production environment.
The Value of Virtualization
Virtualization is of significant value the migration model. Specifically, for organizations that do not have
existing hardware to facilitate a migration environment, virtual machines present an attractive alternative.
Additionally, by using the capabilities inherent in virtual machines, such as undo disks and the ability to back
up the virtual hard disks when the machines are at critical states, administrators can quickly and repetitively
rehears the migration process prior to cutover.
For example, administrators can back up the virtual hard disks for the migration environment after
SharePoint Portal Server is installed, after the production SharePoint Portal Server sites have been restored
and after Office SharePoint Server has been installed. This will allow administrators to roll back to a recovery
point in the process to quickly test migration steps.
The procedure to conduct the migration and upgrade using a migration environment is as follows.
Back up the existing SharePoint Portal Server content and profile database for all sites to be migrated to
•
Office SharePoint Server

• This can be accomplished by using the SharePoint Portal Server Backup and Restore utility or STSADM
Configure the Migration Environment
•
• Install SharePoint Portal Server with SP2
Restore the backup of the production sites from the production SharePoint Portal Server to the
•
migration server SharePoint Portal Server instance
Run prescan.exe in the migration environment to ensure site upgrade readiness
•
Reset any site templates to the out-of-the-box (OOB) definitions, or alternatively use the SharePoint
•
Accelerator to create upgrade mapping definition files so the upgrade can map and represent the
SharePoint Portal Server custom site template

10
 Install Office SharePoint Server 2007 in the Migration Environment
•
The method by which Office SharePoint Server is installed in the migration environment will depend on
•
whether or not the approach being taken is a gradual upgrade, or a database migration
If conducting a gradual upgrade, Office SharePoint Server will detect the existence of SharePoint Portal
•
Server in the migration environment and present the in-place and gradual upgrade options
If upgrading a subset of sites, select the gradual upgrade option in the Office SharePoint Server
•
installer
• If conducting the database migration, select no upgrade option
Run the SharePoint Configuration Wizard and Upgrade to Office SharePoint Server
•
• If conducting a database migration, configure the farm by creating a new farm

• Create an empty web application which will hold the upgraded site on an empty port

• Start all required Office SharePoint Server services

• Use stsadm to add the restored SharePoint Portal Server content database to the new web application
Note that administrators can either backup and restore the SharePoint Portal Server content database
•
on the migration environment, or stop the IIS website allocated to SharePoint Portal Server and directly
add the content database to the web application
If conducting a gradual upgrade, configure the farm and then use Central Administration to choose sites
•
for the upgrade
Once the database migration completes (or alternatively, the gradual upgrade completes and the chosen
sites have been upgraded) the task of configuring Office SharePoint Server to connect and incorporate the
upgraded personal sites from SPS 2003 should be addressed. The following section outlines the strategy
with regard to MySite upgrades

MySites Migration Strategy

The MySite migration strategy should be formulated during the site collection migration strategy selection.
Many of the considerations that are given to splitting site collections apart apply specifically to MySites. As
per the Office SharePoint Server documentation, MySites should be housed on a separate web application.
The separation of the MySite site collection provides significant performance and manageability benefits. In
the case where the SharePoint Portal Server MySites can be split from their main content database where
they coexist with the portal prior to upgrade, adding the content database for the portal first and then the
MySites next during a database migration will provide the ability to select 2 separate web applications for
the upgrade. However, if the strategy chosen is to migrate a single monolithic content database and
subsequently split the MySites from the main site collection in a separate iteration after Office SharePoint
Server implementation, additional administration steps will need to be taken. Coupled with the migration of
MySites is the inclusion of user profiles.
Profiles and MySites
Planners and implementers can choose whether to migrate profile settings into Office SharePoint Server
from the SharePoint Portal Server instance, or to regenerate all profile information based on an Active
Directory import. There are specific trade-offs accompanying leaving behind profile information and it is
rarely done because of what is lost.
Discarding SharePoint Portal Server Profile Information for MySites
In a gradual upgrade, the root site collection upgrade process will automatically create a new SSP for the
site and migrate profile information. However, during a database migration upgrade, it is possible to migrate
just the user's private site collection and leave behind the profile information. The impact of leaving behind
profile information is that the users will have access to their personal site content, documents, lists, pages,
etc., but will no longer have access to their My Links or Alerts features. The choice to leave behind the PROF
database means that a new SSP for the farm will need to be created and that an Active Directory import will

11
have to commence before the sites are "matched" to their accounts. Additionally, administrators will
manually have to create a MySite host template in the root site collection and specify managed paths so that
MySite functionality in Office SharePoint Server will be linked to this new site collection Note that this is true
only if upgrading from a monolithic database with intermixed portal and personal site site collections in
SharePoint Portal Server.
While discarding profile information is possible, it is not recommended and most likely will seldom be
practiced based on the losses associated with the profile information
Maintaining Profile Information When Upgrading MySites
To maintain profile information including My Links and Alert settings from SharePoint Portal Server during
the upgrade, the PROF database must be restored as the SSP. Using the STSADM tool (with the restoressp
operation), a new Office SharePoint Server SSP will be created and associated with the upgraded web
application where the personal sites were migrated.
Note The Central Administration Restore SSP UI cannot restore an SSP from SharePoint Portal Server
because the database must be upgraded first (which the restoressp operation does intrinsically).
When the users visit their own MySite, the traditional provisioning process will not occur. Instead, the user is
redirected to their upgraded personal site collection. Coupled with the profile information retrieved for the
user from the SSP, the user should have full access to their pre-upgraded content and documents as well as
the ability to see their links under the MyLinks menu in Office SharePoint Server.
Profiles and MySites must be migrated together to ensure that the complete SharePoint Portal Server user
experience surrounding MySites are migrated into Office SharePoint Server. While MySites can be moved
without profiles, users will not have access to their My Links or Alerts. All this information is stored within
the PROF SharePoint Portal Server database.
Understanding MySite Architecture
Prior to conducting the migration for MySites, administrators can benefit from understanding the
architecture of MySites in SharePoint Portal Server and Office SharePoint Server. The following diagram is a
comparative depiction of the similarities and differences in MySite structures between the two versions of
SharePoint

12
Figure 3. SharePoint Portal Server (Office 2003 version) MySite Structure

Figure 4. Office SharePoint Server MySite Structure

As depicted above, the primary differences between the SharePoint Portal Server models and the Office
SharePoint Server model is the method in which the public and private pages are displayed. In the
SharePoint Portal Server environment, the product relegates private and public views to a MySite path that
houses both a data-driven view of user information based on their profile and some data derived from the
user's personal site (for example shared links). The pages configured themselves based on the person
requesting them (in the case of a private page), or the visit by another user to an individual’s MySite (public

13
page). In SharePoint Portal Server, when an administrator made a change to any properties found on the
personal or public page, it applied to everyone. In the Office SharePoint Server environment, the
person.aspx page assumes a similar function to the SharePoint Portal Server public.aspx in that a single
page draws information from the user's profile to display organizational and publicly visible personnel
information. However, a change to the Office SharePoint Server environment is how personal sites are
designed. While both models continue to store profile information separately (SharePoint Portal Server in the
PROF database and Office SharePoint Server in the User Profile store and administered using the SSP), the
personal page has been moved into the users MySite personal site collection. This provides greater flexibility
and management of customizations to the private page.
Similarities between both include the fact that the /personal/username site collection continues to contain
subsites, document libraries, documents, pages and other elements. According to Office SharePoint Server
best practices, the ideal placement for MySites is on a separate web application that exists alongside the
portal. In advanced scenarios where IP addresses cannot be allocated for each site on the server for port 80,
host headers and DNS can be used to create a separate address space for navigating to the MySites on port
80. The following diagram depicts the best-practice configuration for site collection configuration for MySites
and portals (i.e., upgraded SharePoint Portal Server portal sites).

14
Figure 5. Recommended Office SharePoint Server MySite and Portal Structure
While this is the optimal structure, as mentioned previously, separation of the MySites from the primary
portal content database would have to occur before the migration or immediately afterwards. While this
might be best practice and conform to established performance guidelines, many organizations will not have
the timeline to accommodate for a protracted outage that is required this configuration. Thus, the following
diagram outlines how a monolithic database structure will look when upgraded and migrated into Office
SharePoint Server following the documented upgrade steps.

15
Figure 6. Monolithic Content Database MySite and Portal Structure
Thus, if the strategy chosen for the upgrade is to take a monolithic database and migrate it to Office
SharePoint Server from SharePoint Portal Server using the migration server approach (while keeping the
profile information), the following steps need to be performed. These steps assume that the aforementioned
database migration steps have been executed.
Conduct the restoressp operation following the database migration using the following syntax.

stsadm -o restoressp -title SSPName-url http://portal:PortNumber –

ssplogin DOMAIN\ServiceAccount -mysiteurl http://portal:PortNumber/mysite

-indexserver MIGRATIONSERVERNAME -indexlocation "C:\Program

Files\Microsoft Office Servers\12.0\Data\Office Server\Applications" –

keepindex -sspdatabaseserver SQLSERVERNAME -sspdatabasename SPS2003_PROF

-ssppassword ServiceAccountPassword

16
Once the SSP restore is complete, the upgraded site will be associated with the SSP. The SSP will have
automatically been made the farm default SSP. From this point, typical SSP configuration can continue, such
as search configuration, profile imports, BDC application definition, etc. The user should be able to select the
MySite link at the top of any Office SharePoint Server page they visit and have their full list of URL's
available to them as well as alerts.

Completing the Upgrade

Once the upgrade has been completed without errors and finalized, the goal is to conduct significant
regression testing of the site. In addition to ensuring that the site has been migrated successfully, the
principle task is to inspect how the upgrade process has arranged the SharePoint Portal Server portal now
that it is in Office SharePoint Server. Of significance is how Office SharePoint Server deals with portal areas.
Since the concept of areas does not translate into Office SharePoint Server, all SharePoint Portal Server
areas are now created as subsites. Careful attention should be paid to taxonomy, site design and naming.
Administrators may need to move sites and site collections around in order to conform to predetermined
taxonomy. Additionally, if the project timelines permit, the separation of MySites from their portal database
can occur at this stage as well. Administrators may also have to deploy and register any custom assemblies
(i.e., SharePoint solutions or MSIs containing web parts, custom list templates or site templates, etc.) and
test to ensure that the portal can render correctly. This step also can include the deployment of any custom
master pages, or other content-based artifacts developed in Microsoft SharePoint Designer 2007.
While the migration server is the best place to do this low level testing, full regression testing and
interoperation testing should occur within the production hardware. While the ongoing support of a testing
environment is recommended, the production hardware, on an initial migration, will not have any traffic or
exposure to end users. Thus, the next step for the implementation team is to backup and restore the
migrated SharePoint Portal Server content from the Office SharePoint Server migration server to the
production server (as depicted in the physical migration strategy diagram). The production farm (which can
be configured in parallel with the SharePoint Portal Server to Office SharePoint Server migration on the
migration server) will contain the final site taxonomy. When administrators migrate the site content to the
production server farm, they will restore the web application(s) (portal, SSP and optionally MySite web
application if separated in migration).
Ideally, content owners from the previous SharePoint Portal Server portal can conduct user acceptance
testing and end user training using the production hardware on an initial migration. During this time, the
existing SharePoint Portal Server portal can remain active and service the organization until a final migration
and cutover can be accomplished by repeating the upgrade migration steps.

17