How to move an SSP

Article
02/10/2009

IMPORTANT NOTE: This blog entry adresses the steps that need to be performed when moving SSP A to SSP B within the SAME farm as a recovery for a broken SSP scenario.

IMPORTANT NOTE 2: The tools provided as reference from codeplex.com are provided "AS IS" , are not supported by Microsoft and provided under the Microsoft Public License (Ms-PL).

Please review the Codeplex Terms of use :

https://www.codeplex.com/site/legal/Terms

and Microsoft Public License (Ms-PL).

https://msdn.microsoft.com/en-us/library/ff649456.aspx

IMPORTANT NOTE 3: Make sure you have working backups of all databases involved.

For moving SSP-s across farms, use the procedure described at https://technet.microsoft.com/en-us/library/cc896556.aspx

In the past few months , I have come across quite a big number of issues who’s only supported solution (other than rebuilding everything) was to create a new Shared Service Provider.
Easier said than done, an SSP change raises a very valid question:
What data can be transferred between SSPs and what data cannot be moved?

A short answer would be all the data that lies in the content database of each respective webapplication will move without problem and without manual interaction whereas all the data that stored in the SSP DB and SSP Search DB needs to be migrated.Some of it can be migrated (copied), for some of it we do not have tools yet (scopes), some of it doesn’t make sense to migrate because is internally bound to the SSP and would not make sense into the new SSP.

Here are the main components that need to be ported between SSPs

my sites
search settings.
Excel Services settings
Business Data Catalogs and applications.
audiences
other configurations.

Looking at the above list the most manual work would need the profiles (because, not everything is automatically imported from AD) and the search managed properties, crawled properties.

The rest of the configurations might need additional work but not that time consuming as the above. Here is my approach on the matter:

Basic steps:

Create a new web application that will host the administrative site host for the new SSP

Create a new web application that will serve as repository for the “my sites” (this may be deleted afterwards, see Note 1)

Create the new SSP

Moving the data (profiles)

1: Install administration toolkit on the server

(Microsoft SharePoint Administration Toolkit)

2: Download, compile Moss Profile Replicate from Codeplex

https://www.codeplex.com/MOSSProfileReplicate

3. Use MOSSProfileReplicate to export the properties from SSP A

4. Use MOSSProfileReplicate to import the properties into SSP B

5. Use Sharepoint Administration Toolkit Replication manager to instrument Full replication between servers.

Moving the data (managed properties, crawl properties and relevent categories)

1. Download, compile and run (export in A import in B)

SharePoint Shared Services Search Provider Property Creation

It will move (export/import): Content Sources Crawled properties Managed Properties, Search Scopes

Moving the data (Audiences)

1 .Download Audience migration from codeplex https://audiencemigration.codeplex.com/

2. Export the Audiences from source

3 Import at destination

The tool will perform a re-ID-ing of the audiences to match the destination therefore, take into account that it might take some time to complete.

----------------------------------------------------------------------

You will need to manually migrate the rest of the configurations in the SSP as no tools are (yet) available to do so.

Here’s what’s left:

Excel services ( do not forget to port the Kerberos related settings for delegation on this new ssp)

How to configure SharePoint Server 2007 and Excel Services for Kerberos authentication

BDC applications

Scopes (non - shared scopes, as the shared ones will be exported/imported by the above tool)

Final check of all the settings

Now that you successfully migrated all the SSP data from A to B, all that’s left to do is to associate the web applications from SSP A to SSP B and set this as default.

Notes:

1. If you do not want to change the web application hosting the my sites, before changing the association, edit my site setting for SSP B, set the my site to point to the old my sites URL and delete the temp my site web application, then perform the association

2. If you start from having just one web application that hosts all the sites (portal, ssp administration site host, my sites) here’s what you need to do to separate them:

Scenario :

portal url : https://portal

Administration site host for the ssp https://portal/ssp/admin

mysites host https://portal/personal……

Issue A: you cannot change the association for the administration site host of an ssp

i : create a new web application to host the administration site for the OLD SSP

https://newsite:10000

backup the site at https://portal/ssp/admin

stsadm –o backup –url https://portal/ssp/admin –filename c:\sspadmin

ii. create a managed path (explicit inclusion) in the new site to point to /ssp/admin

https://newsite:10000/ssp/admin

restore the backup you just created at this location

stsadm –o restore –url https://newsite:10000/ssp/admin –filename c:\sspadmin –overwrite

change the ssp administration site host from https://porta/ssp/admin to https://newsite:10000/ssp/admin

stsadm –o editssp –title “your old ssp name” –sspadminsite “https://newsite:10000/ssp/admin”

Now you can change the portal association between the SSPs

Issue B:

how to move the mysites from https://portal/personal to a new webapplication at https://mysite ?

(mysite web application was created either when creating the new SSP as the new mysite host or manually using My Site Host template, in which case you need to add an wildcard inclusion to /personal manged path)

backup and restore

enumerate all the mysites that were already created (output it to a file for easier work):

stsadm –o enumsites –url https://portal/personal/ > c:\mysites.txt

edit the txt file and create 3 batch files ot of it:

one for backing up the mysites, one for creating the destination mysites , one for restoring from backup at the destination:

for instance, the following line from the initial file resulted (mysites.txt)

will become (in 3 bat files):

stsadm -o backup -url https://portal/personal/username -filename c:\backup\username.dat

stsadm -o createsite -url https://mysite/personal/username -sitetemplate SPSPERS -owneremail username@domain.com -ownerlogin "Domain\username"

stsadm -o restore -url https://mysite/personal/username -filename c:\backup\username.dat –overwrite

same for the rest of my sites

HTH

Comments

Anonymous
January 01, 2003
I would look at account permissions for the sharepoint admin account, it needs to be a member of the WSS_ADMIN_WPG and local Administrator on the server
Anonymous
July 15, 2009
The comment has been removed

Share via