This is perhaps the most thorny and difficult part of any upgrade because of how the upgrade code is written to perform regarding SS. So we’ll be straightforward and tell you that, in most circumstances, we believe it is a best practice to create a new SSP in SharePoint Server 2007 and then reassociate your portals in 2003 with the new SSP. In order to understand our best practice recommendation, it’s important to first understand the differences and similarities in how SS is implemented between the two platforms and then understand how the product team was forced to write the upgrade code.
In SharePoint Portal Server 2003, SS was an optional configuration that could be implemented if the need was perceived to exist by the farm administrator. Multiple portals were not needed to implement SS, but multiple portals were often the case for making this choice so that users would experience the same index, My Sites, audiences, and user profiles across all the portals.
What made this choice optional in SharePoint Portal Server 2003 was that each portal had its own index, My Site location, audiences, and user profiles at the time the portal was created. So, in a single portal implementation, there was little motivation to implement SS, even if the existing portal was selected as the SS portal. Doing this was like deciding to eat at a local restaurant after you had already finished your meal there. It was a redundant decision that was often perceived as unnecessary.
As a result, many SharePoint Portal Server 2003 implementations created multiple portals without configured SS. In these environments, the portals each had their own index, My Sites, audiences, and user profiles. In most cases, this redundancy was designed into obscurity because users were instructed to consume these services from a single, designated portal. Other portals were implemented for different purposes, and the My Site link was removed and/or users were instructed only to perform certain actions within that portal. In many cases, it worked just fine.
Among several drawbacks to the SharePoint Portal Server 2003 SS topology was that you couldn’t have more than one SSP. Once you designated an SS portal, the other portals in the farm consumed those services from the SS portal. Any virtual servers that were not configured as portals did not participate in the SS either, leading to an inconsistent user experience. If you did need (what we would call today) multiple, disparate SS, you left SS turned off and then used different designated portals as your different SSP. Unfortunately, this randomization of SS across multiple portals was neither flexible nor scalable if you had a number of virtual servers that were configured with team sites. None of them had access to any of the portal SS, even if they were connected to one of the portals.
When SharePoint Server 2007 was developed, it was decided that, in order to obtain SS, the farm administrator would need to create a designated SSP. This SSP would then serve out the SS that the farm needed. But they also went one step further and allowed the farm to host multiple SSPs. When portals are created in SharePoint Server 2007, they have no capacity to act as their own SSP, unlike the portals in SharePoint Portal Server 2003. In other words, portals in SharePoint Server 2007 do not have a built-in index, My Site provider, audiences, or user profiles. These and other SharePoint Server 2007 SS must be provided by and consumed from a designated SSP. Consumption is by association at the Web application layer, leading the farm administrator to decide which Web applications will consume which SSP’s services.
By default, when a SharePoint Portal Server 2003 portal in a non-SS environment is upgraded to SharePoint Server 2007, the upgrade code realizes that this is not only a portal, but also, in a pragmatic sense, its own SSP. So the code creates an SSP for this portal in SharePoint Server 2007 and then embeds the SSP inside the portal in the http://<portal_name>/ssp/admin location (Figure 22-4). If you look at the upgraded portal’s association, you’ll find that the same Web application was created for both the portal and the SSP and the portal is associated with itself (Figure 22-5). Obviously, you can change the portal’s association to another SSP, but then you’ll need to move the My Sites as well to the SharePoint Server 2007 My Site location.
Figure 22-5. Shared Services Administration page showing that the portal is associated with itself for SS
Unfortunately, you will end up reconfiguring several Shared Service elements after an upgrade. For example, the scopes in SharePoint Portal Server 2003 are tied to the content sources; in SharePoint Server 2007, they are not. So even though the scopes will upgrade from SharePoint Portal Server 2003 to SharePoint Server 2007, the chances are good that you’ll end up deleting the upgraded SharePoint Portal Server 2003 scopes and creating a new set of SharePoint Server 2007 scopes.
Another example is the index. The index doesn’t upgrade and neither do the content sources. So after the upgrade of your SS portal, you’ll still be in the position of having to re-create and re-crawl your content sources.
Hence, in light of what doesn’t upgrade for an SS portal coupled with the extra work that you’ll have to perform on an upgraded SS portal, perhaps you can now understand why our best practice recommendation is to create a new SSP and associate your upgraded Web applications with that new SSP.
If you have a large number of audiences and/or user profiles, you can use the database migration approach to bring those profiles over to your new SSP in SharePoint Server 2007. After that, you’ll have to redo most of your SS customizations anyway, so performing them in a new SSP is our recommended best practice.