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).
and Microsoft Public License (Ms-PL).
IMPORTANT NOTE 3: Make sure you have working backups of all databases involved.
For moving SSP-s across farms, use the procedure described at http://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.
- 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:
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
2: Download, compile Moss Profile Replicate from Codeplex
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)
It will move (export/import): Content Sources Crawled properties Managed Properties, Search Scopes
Moving the data (Audiences)
1 .Download Audience migration from codeplex http://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)
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.
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:
portal url : http://portal
Administration site host for the ssp http://portal/ssp/admin
mysites host http://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
backup the site at http://portal/ssp/admin
stsadm –o backup –url http://portal/ssp/admin –filename c:\sspadmin
ii. create a managed path (explicit inclusion) in the new site to point to /ssp/admin
restore the backup you just created at this location
stsadm –o restore –url http://newsite:10000/ssp/admin –filename c:\sspadmin –overwrite
stsadm –o editssp –title “your old ssp name” –sspadminsite “http://newsite:10000/ssp/admin”
Now you can change the portal association between the SSPs
(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 http://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)
<Site Url=http://portal/personal/username Owner=”Domain\username” SecondaryOwner=”Domain\administrator” ContentDatabase=”ContentDBName” StorageUsedMB=”0.4″ StorageWarningMB=”80″ StorageMaxMB=”100″ />
will become (in 3 bat files):
stsadm -o backup -url http://portal/personal/username -filename c:\backup\username.dat
stsadm -o restore -url http://mysite/personal/username -filename c:\backup\username.dat –overwrite
same for the rest of my sites