Manage My Site host locations
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2007-09-04
A My Site host location is created automatically when a Shared Services Provider (SSP) is created. The host location is created in its own site collection on the default Web application, and all personal sites are stored in that location. In most scenarios, this is the only My Site host location for the entire deployment of Microsoft Office SharePoint Server 2007. Users can view My Sites if the SSP for the My Site host location imports their user profile information from directory services, and only if they have the Create personal site permission enabled. Individual personal sites are created when individual users click the My Site link on the top link bar of the site.
The My Site host location for an SSP can be changed for reasons such as performance, storage capacity, or security. Previously created personal sites remain in the original host location until they are migrated to the new location. However, new personal sites will be created in the new host location. The previous host location will be inaccessible unless an administrator adds the host location to the list of trusted My Site host locations and targets the host location link to specific users or groups.
In scenarios with multiple SSPs, each SSP has a different My Site host location. Most users will only have access to one SSP. In this case, they will only see My Sites if their user profiles have been imported to that SSP and they have the Create personal site permission enabled. Some users, however, might have access to My Sites in host locations on two or more SSPs. Those users see a different My Site for each SSP unless an administrator configures trusted My Site host locations to use the same host location across all SSPs.
Settings for My Sites are configured for each host location.
In this article:
Changing the My Site Host Location
Managing multiple My Site host locations over multiple SSPs
Changing the My Site host location
For reasons such as performance, storage capacity, or security, it is sometimes necessary to change the host location for My Sites. The migration scenarios for My Site host locations are:
Moving My Sites across SSPs. This is the common scenario when an organization's structure changes, such as when groups of users from separate divisions merge into a single new division, or separate organizations or divisions are created from a single organization. My Sites for at least some users will change host locations based on the need for sharing personalized information.
Moving to a different host location in the same SSP. This is the common scenario to improve performance or storage capacity by moving to a new server.
To create a new My Site host location, the farm administrator performs the following steps:
Create a new Web application for the new My Site host location. In most cases, you can accept the default settings for a new Web application.
Create a site collection for My Sites, selecting the My Site Host site template and the Personal Site quota template.
Browse to the site collection and click the option to set the site collection as the My Site host location.
Because each SSP creates a single My Site host location when it is created, a new Web application and site collection does not need to be created or set as the My Site host when migrating across SSPs.
Whether My Sites are being moved across SSPs or to a different location in the same SSP, trusted My Site host locations are used during the period of migration to ensure that personalized content is displayed correctly. At the end of the migration period, access can be limited on a user-specific basis to the new My Site host location. If the old location is no longer being used, those sites and the links to those sites can be deleted.
Managing multiple My Site host locations over multiple SSPs
In some cases, users can be members of two or more sites that use different SSPs and different My Site host locations. In that case, by default, the user can see the My Sites in the host location used for the SSP of the current site. My Sites in other host locations cannot be seen, and the personalization features of those sites cannot be used. This configuration results in an unpredictable My Site experience. Each user's My Site changes depending upon the site, and the My Sites of other users are not reliably available on each site.
To avoid this situation, it is usually a good practice to limit each user to one SSP. However, in certain scenarios, this is not possible. These scenarios include:
Geographically distributed deployments. Users work in different regions, each of which uses a different SSP. Some users have to collaborate across regions, and must have access to multiple SSPs. This is particularly common if an employee in a global deployment moves between geographic locations.
Multiple forest scenarios. A company might use multiple forests with groups of users isolated on each forest, with some users needing to work across forests. It is possible to configure a single SSP to import user data across forests, but during the transition to a single SSP, some users will have to work on multiple SSPs. In other multiple forest scenarios, the same considerations for service isolation or service autonomy that contributed to the decision to use multiple forests will also suggest multiple SSPs, even though these decisions are made separately and for different reasons.
Hosted scenarios: Multiple SSPs are often used in hosted scenarios, with each hosted deployment using a different SSP. In these scenarios, isolation is often complete and no users will have access to multiple SSPs. However, in some internal hosting scenarios, a subset of users might need access across SSPs. For example, members of an IT department hosting internal deployments for various divisions might need to view and collaborate with users in each hosted deployment.
In these scenarios, it is a good idea to think through the reasons for multiple SSPs and then create a predictable experience for My Sites and personalized content.
To enable users to view My Sites and use personal features on multiple host locations, each host location must enable support for global deployments on the My Site Settings page. This makes personalized content on each host location available across SSPs, but only if the host location is trusted by an SSP. Each SSP has a list of trusted My Site host locations links. Each link can be targeted so that only users in selected audiences can view My Sites in a particular host location. Profile information for all targeted users is replicated to each SSP, and is available to all sites on the SSP. My Site host locations are used by each SSP in the order of the trusted My Site host locations list. If a user is a member of an audience targeted by one host location link, then that My Site host location is used for that SSP and the later host locations are ignored. This results in one set of personalized content for each user being made available to all targeted users in each SSP. Trusted My Site host location links can then be used to rank My Sites in a consistent order across SSPs for a consistent experience across SSPs, or in a different order to maintain different personalization experiences for some users on different SSPs. This enables administrators to accommodate the following scenario:
An administrator can add a trusted My Site host locations link targeted to an audience that includes groups or individual users moving from one SSP to another. During the transition, groups or users can continue to view their existing My Sites, their My Sites on the new SSP, the My Sites for other users in their old group when viewing sites that use the old SSP, and the My Sites of the users in the new group when viewing sites that use the new SSP. The administrator can then change the order of trusted My Site host locations on the new site so that each user has access to both My Sites for a period of transition, enabling them to move information from one My Site to the next.
When the transition is over, the order of trusted My Site host locations on the old site can be changed so users always see the My Site for the new host location even when they are viewing sites that use the old SSP. They will continue to be able to see the personal sites of other users on both My Site host locations until they are removed from the audiences in the trusted My Site host locations list, or until the trusted My Site host locations link itself is deleted.
Consider the following example:
A company has three SSPs for three geographical divisions, and five groups of users. Group A is in SSP 1, serving the Asia locale. Group B is in SSP 2, serving the European locale. Group C is in SSP 3, serving the North American locale. Groups D and E include users that are being moved to North America from Asia and Europe, respectively.
The user profiles manager, who has the responsibility of managing My Site host locations for user profiles across SSPs, configures three audiences:
"North America" includes people who are already in North America or are in the process of being migrated to North America from another locale. This audience includes groups C, D, and E.
"Asia" includes people who are in the Asia locale or are in the process of being migrated to another locale. This audience includes groups A and D.
"Europe" includes people who are in the European locale or are in the process of being migrated to another locale. This audience includes groups B and E.
The trusted My Site host locations links list for SSP 1 (Asia) is:
Host location 1 (Asia), targeted to audience "Asia"
Host location 2 (Europe), targeted to audience "Europe"
Host location 3 (North America), targeted to audience "North America"
Groups A and D are targeted by the first link, so users in those groups have My Sites in the Asia SSP, and can view personalized information for all users in those groups. All current and migrating members of the Asia locale share information using the Asia SSP.
Groups B and E are targeted by the second link, so users in those groups use My Sites in the European SSP and can view personalized information for all users in those groups. All current and migrating members in Europe share information using the Asia SSP.
The third link is targeted to groups C, D, and E. However, groups C and D have already been included in the previous audiences. Only users in group E use My Sites in the North American SSP.
The trusted My Site host locations links list for SSP 2 (Europe) is:
Host location 2 (Europe), targeted to audience "Europe"
Host location 1 (Asia), targeted to audience "Asia"
Host location 3 (North America), targeted to audience "North America"
This results in the current and migrating groups in Europe and Asia using the My Sites in those host locations, and the North American group using My Sites in the North American host location.
Note
The same groups use the same set of My Sites as they did in the first SSP. This consistent experience across SSPs required changing the order of the first two host locations in the trusted My Site host locations list.
The trusted My Site host locations links list for SSP 3 (North America) is:
Host location 3 (North America), targeted to audience "North America"
Host location 1 (Asia), targeted to audience "Asia"
Host location 2 (Europe), targeted to audience "Europe"
Because the "North America" audience includes both current groups and users and migrating groups and users, this results in groups C, D, and E using My Sites in North America and viewing personalization information for all users in these groups when viewing sites that use the North American SSP.
Group A, which consists of users in Asia who are not migrating, uses My Sites in the Asia SSP and can only see personalized information for other users in that group. Similarly, group B uses My Sites in the European SSP and can only see personalized information for users in that group.
During the period of migration, users in groups D and E will use different My Site host locations depending upon which SSP is viewed (but will never be able to see personalized information from the third locale, which is Europe for group D and Asia for group E). After migration to North America is complete, these groups can be removed from the "Asia" and "Europe" audiences for the other SSPs, as they are no longer members of those locales. Alternatively, those host locations can be removed from the list, if no future migrations are planned or expected. In either case, users in those groups will always use the North American My Site host location regardless of which SSP they use when accessing My Sites.
This scenario is the most common use of trusted My Site host locations, but it is not the only one. Duplicate or broken My Sites can occur in any scenario with multiple SSPs. When this happens, you can add or delete trusted My Site host location links, change the order they are ranked in each SSP, or edit the audiences that are targeted by each link to fix the problem.
Task Requirements
The following are required to perform the procedures for this task:
Administrators must have access to the Shared Services Provider (SSP) administration site, and must have the Use personal features permission enabled.
Administrators must know the locations of other trusted My Site host locations.
To manage trusted My Site host locations, you can perform one or more of the following procedures: