Design My Sites architecture
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: 2016-11-14
In this article:
My Sites design recommendations
Host My Sites in a dedicated Web application
Coordinate My Sites across your organization
Plan Web application general settings
Design content database settings for My Sites
Automatically delete sites that are not used
Plan for permissions of My Sites
If you plan to offer My Sites as part of your deployment, you should include My Sites in the initial architecture design, regardless of when you plan to roll out My Sites to users. This article provides logical architecture design recommendations for deploying My Sites within a server-farm.
For more information about the My Sites feature, see Plan My Sites.
My Sites design recommendations
Compared to team sites or published intranet portal sites, My Sites typically are a larger number of sites that are smaller in size.
Design goals for My Sites include:
Optimizing performance of the overall server farm.
Creating logical divisions of databases for My Sites for ongoing maintenance (backup, restore, and upgrade).
Enabling you to apply appropriate policies and settings for My Sites without affecting other types of sites within your intranet.
Design guidance for My Sites includes the following recommendations:
Host My Sites in a dedicated Web application.
Coordinate multiple My Site applications across your organization
Apply Web application general settings to manage growth of My Sites and to keep content current.
Automatically delete sites that are not used.
Design content database settings for appropriate storage and scale.
Plan for appropriate policies and permissions.
Host My Sites in a dedicated Web application
You can configure many settings at the Web application level that contribute to performance and assist with manageability. Therefore, we recommend that you host My Sites in a dedicated Web application.
Performance
Deploying My Sites in a dedicated Web application results in one or more content databases that host only personal site collections. Databases that host My Site content have the following characteristics:
A large number of tables in the database because of the large number of personal sites.
Size of tables are small because individual sites are small.
If you dedicate content databases to host sites with similar data characteristics, Microsoft SQL Server database software operates more efficiently. SQL Server chooses a query plan based on the characteristics of a database. If a database combines sites with vastly different data characteristics, the query plan that SQL Server uses might not be the most efficient method for all content in the database. For example, if a database hosts My Sites (that is, a large number of small sites) and portal sites (that is, a small number of very large sites with many requests), the chosen query plan will be inefficient for one of the types of sites. By placing content for My Sites in a dedicated database, you can optimize performance for SQL Server, which results in better performance for the overall server farm.
Manageability
Deploying My Sites in a dedicated Web application enables you to separately manage the following items:
Database settings
Quota templates
Recycle Bin settings
Automated actions for unused sites
Authentication
Policies
By managing My Sites separately from other types of sites, you can more effectively manage the growth of My Sites.
By placing My Sites in a separate Web application, you also create the opportunity to negotiate a specific service-level agreement. For example, a service-level agreement for My Site content might allow more time to restore sites in the event of a failure. A larger time allowance for restoring content databases creates the opportunity to increase the size of content databases, resulting in fewer databases to create and manage.
Choosing an application pool
In a corporate environment, My Sites can share an application pool with Web applications that have similar collaboration and isolation requirements. For example, a My Sites application can share an application pool with collaborative team sites.
In a hosting environment in which content for multiple organizations is hosted on a single server farm, we recommend that you host all content for a single organization in the same application pool.
Deploying My Sites to a dedicated Web application
When you create a Shared Services Provider (SSP) you specify a Web application for My Sites. The following figure shows a Web application that is dedicated to My Sites.
.jpg "Logical network architecture for My Sites")
In the diagram, the first top-level site collection that is created uses the My Site Host template. A wildcard inclusion, /personal, is automatically appended to the URL. When you create the SSP, you can specify a different inclusion, such as /sites. All sites below the wildcard inclusion are independent site collections that inherit the My Site Host template. The user name is appended to the URL: http://my/personal/username.
Coordinate My Sites across your organization
In organizations where multiple server farms are deployed or where multiple SSPs are configured, it is possible for users to create multiple My Sites. For example, in a geographic deployment with a central farm in Europe and a regional farm in Africa, a user can click the My Sites link when browsing content hosted by either farm. Consequently, the user can create a My Site on the Europe farm and a My Site on the Africa farm.
If your organization includes multiple farms or multiple SSPs that host My Sites, you can prevent users from creating multiple My Sites by using the Trusted My Site Host Locations feature. This feature enables you to specify trusted My Site locations. When trusted My Site locations are specified, users are redirected to the My Site that is intended for their user accounts, regardless of where they are browsing when they click the link to create a My Site. This feature ensures that each user creates only one My Site in the organization.
You can further increase usability across multiple My Sites applications by selecting Enable My Site to support global deployments on the My Sites Settings page. However, this option relies on a profile replication solution to share profile data across multiple SSPs in an organization. When these are in place, users can incorporate content or profiles from other SSPs into their My Site:
When users add links to their personal site to content that is hosted by other SSPs, trusted SSPs create the link from the context of the user's SSP, rather than the SSP the user is currently browsing.
When users add colleagues, they are added from the context of the colleague's SSP.
To configure trusted My Site host locations, perform the following steps.
Specify trusted My Site host locations
On the Shared Services Administration site, in the User Profiles and My Sites section, click Trusted My Site host locations.
On the Trusted My Site Host Locations page, click New.
On the Trusted My Site Host Locations: New Item page, in the URL section, type the URL of the Web application.
In the Target Audiences section, list the user accounts or group accounts that you want to use this trusted My Site host location.
Repeat the preceding steps for each SSP that hosts My Sites.
The items on the Trusted My Site Host Locations list are evaluated and applied in the order that they are listed, and the first item that matches a user is applied to the user. Therefore, list specific target audiences before you list general target audiences.
The following table lists URLs and target audiences for Fabrikam, Inc. In this example, Fabrikam is located in Europe with a remote site in Africa. Fabrikam includes a Europe domain and an Africa domain.
| URL | Target Audiences (domain\securitygroup) |
|---|---|
http://DivisionA/mysite |
Europe\DivisionAEmployees |
http://my |
Europe\all |
http://MyAfrica |
Africa\all |
When employees of Fabrikam click the My Site link, their accounts are evaluated based on membership in one of the security groups in the Trusted My Site Host Locations list. If an employee is a member of Division A, the My Site is created in the My Site application for Division A. If they are not an employee of Division A but their account is in the Europe domain, then their My Site is created in the My Site application for the Europe domain. If they are a member of the Africa domain, their account is created in the My Site application that is hosted by the Africa server farm.
For a more secure environment, ensure that the Trusted My Site Hosts Locations lists are uniformly managed across all SSPs.
Plan Web application general settings
There are several settings on the Web Application General Settings page that can assist in managing the growth of data and how current content is in a My Sites application. These settings are applied to all sites within a Web application. At a minimum, plan to implement the following settings:
Apply a quota template to limit the maximum size of personal sites.
Establish a maximum upload size to control the overall size of files and sites. Choose a generous size based on business requirements so users are not prevented from collaborating.
Turn on the Recycle Bin.
In addition to these settings, evaluate all settings on the Web Application General Settings page to ensure that the features are appropriate for My Sites in your organization. By default the following features are enabled:
Person name smart tag and online status (online presence information is displayed)
Alerts (users can create a maximum of 500 alerts, by default)
Really Simple Syndication (RSS) feeds
Blog application programming interface (API) (link to create a blog)
Default quota template
The default quota template for My Sites is the Personal Sites template. This template includes the following default settings:
Automated e-mail is sent to users when the size of their site reaches 80 megabytes (MB).
Users are prevented from uploading additional documents when the size of their site reaches 100 MB.
Although these default settings work well for most organizations, evaluate the size and number of documents that you expect users to store on their My Sites and adjust these settings as appropriate to ensure that My Sites are used as intended in your organization.
For example, if your organization includes knowledge or research workers who produce a large volume of academic work or intellectual property, consider increasing quota limits (for example, increase the site limit to 500 MB). In these scenarios, hosting the content on My Sites ensures that personal work is backed up regularly and that the work remains available if a user leaves the organization.
On the other hand, if your organization includes users who do not produce a significant amount of academic work or intellectual property, consider using the default quota limits or decreasing these limits. This encourages employees to use their My Sites to store only business-appropriate items, which can help to control the size of the sites.
If some users in your organization have a business need to store a greater volume of content on their My Sites, you can adjust the quota limits for an individual site collection. To adjust quota limits, on the Site Collection Quotas and Locks page, select the site collection that corresponds to the users. Change the current quota template to Individual Quota, and then specify the limits that are appropriate.
When planning for quota templates, choose limits that work for most of your users. To maintain a manageable application, only adjust quotas on a per-user basis when it is necessary to meet a business need.
Maximum upload size
The default maximum upload size is 50 MB. If users in your organization need to store larger files on their My Sites, consider adjusting this setting. 50 MB is considered to be a generous limit that gives users the flexibility of uploading many types and sizes of documents without negatively affecting performance.
Recycle Bin
Turning on the Recycle Bin is a simple way to enhance manageability of My Sites. The Recycle Bin enables users to retrieve items that they have deleted without requiring administrative intervention (that is, restoring from backup tapes).
The default settings for the Recycle Bin include the following:
Recycle Bin Status: On.
Delete items in the Recycle Bin: After 30 days.
Second-stage Recycle Bin: Add 50 percent of live site quota for second stage deleted items.
These default settings work well for most organizations.
The second-stage Recycle Bin stores items that users have deleted from their Recycle Bins. Only farm administrators can restore items from the second-stage Recycle Bin. The size that is specified for the second-stage Recycle Bin increases the total size of the My Site. For example, if users are limited to 100 MB for their personal site and the second-stage Recycle Bin is set to 50 percent, the total amount of space that can be used by the site is 150 MB.
Just as with the Recycle Bin, items in the second-stage Recycle Bin are automatically deleted when the time period for deleted items is reached (30 days, by default). However, when the size limit of the second-stage Recycle Bin is reached, items are automatically deleted from the second-stage Recycle Bin starting with the oldest items. Administrators can also manually empty the second-stage Recycle Bin.
Key considerations when using the Recycle Bin feature are whether to use the second-stage Recycle Bin and how much space to allocate. Consider allocating at least a small amount of space (such as 10%) to the second-stage Recycle Bin for cases where a user hastily deletes important documents in an effort to create enough space to upload time-critical documents, such as a presentation.
Design content database settings for My Sites
After determining the size limit to apply to My Sites and establishing the Recycle Bin settings, determine the maximum size for any one database and the maximum number of sites that can be created in each database.
In a managed environment, database size limits are often determined by the following two factors:
The time required to back up a database. Beyond a certain database size, backup operations become inefficient, require more time than is practical, and become subject to other disruptions.
The service window (that is, the amount of time) allowed for restoring content, as determined by the service-level agreement. For example, if the service window for restoring content is four hours, the size of the database is limited to a volume that can be restored within this amount of time.
By deploying My Sites in a dedicated Web application, you create the opportunity to negotiate a different service-level agreement for My Sites than you use for sites in your organization in which restoring content might be more time-sensitive.
To determine the maximum manageable database size for My Sites, determine the values listed in the following table.
| Item | Factor | Value |
|---|---|---|
A |
Service window for restoring My Sites content |
hr |
B |
Volume of content that can be restored within the service window, given the chosen restore method and tools |
gigabytes (GB) |
C |
Target time window for backing up databases |
hr |
D |
Volume of content that can be backed up within the target window, given the chosen backup method and tools |
GB |
Given the two values for volume of content (B and D), the maximum manageable database size for your organization is the lesser of the two values.
After you determine the target size for content databases, you can calculate the number of sites that can be supported in each database. The following table shows the number of sites per database based on database size and site size limits. Site size limits include the space allocated to the second-stage Recycle Bin.
| Database size | 100 MB site size limit | 150 MB site size limit | 300 MB site size limit | 500 MB site size limit | 750 MB site size limit | 1 GB site size limit |
|---|---|---|---|---|---|---|
25 GB |
250 |
166 |
83 |
50 |
33 |
25 |
50 GB |
500 |
333 |
166 |
100 |
66 |
50 |
100 GB |
1,000 |
666 |
333 |
200 |
133 |
100 |
200 GB |
2,000 |
1,333 |
666 |
400 |
266 |
200 |
500 GB |
5,000 |
2,666 |
1,333 |
800 |
533 |
500 |
1 Terabyte |
10,000 |
5,333 |
2,666 |
1,600 |
1,066 |
1,000 |
When you create the Web application for My Sites, modify the settings for the first content database with the maximum number of sites that corresponds to your database size target and site size limits (Maximum Number of Sites). Also specify the threshold (that is, the number of sites) that trigger a warning (Site Level Warning). When the site level warning is reached, create a new database with the same settings. When the maximum number of sites is reached, no new sites are created within the database. If another database has not been created, site creation fails.
Automatically delete sites that are not used
You can increase the currency of content in My Sites by automatically deleting sites that are not used. This can also help you to control the overall growth of My Sites.
Because My Sites are hosted in a separate Web application, you can more aggressively manage unused personal sites (compared to team sites). By default, settings for automatically deleting sites are not enabled. To manage site deletion settings, on the Application Management page, in the SharePoint Site Management section, click Site use confirmation and deletion.
If you enable this feature, default settings include the following:
E-mail notifications are sent to owners of site collections 90 days after site collection creation, or use is confirmed. In other words, if a site has not been confirmed as being in use for 90 days, the site owner receives a notification.
The system checks for unused site collections and sends notices daily at midnight.
The option to automatically delete the site collection if use is not confirmed is not selected. If this setting is selected, sites are automatically deleted after sending 28 notices. Alternatively, you can specify the number of notices.
Given the default settings, a site that has not been used for 90 days is deleted after 28 notices, or 118 days after the last use of the site. Determine the duration settings that are appropriate for your organization.
When employees leave your organization, we recommend that you:
Assign the associated My Site to the employee's manager.
Send the employee's manager e-mail to alert them to retrieve business-related content before the site is deleted.
Plan for permissions of My Sites
The permissions and policies that you apply to My Sites determine:
Who can create My Sites.
Who can view and contribute to My Sites.
Who is prevented from accessing My Sites content.
We recommend that you use security groups to manage permissions. The following table provides guidance for configuring permissions and indicates where permissions are configured.
| Permission | Guidance | Configuration |
|---|---|---|
Create personal site |
By default, all authenticated users can create a My Site. Ensure that you want the default setting to apply to your organization. Alternatively, you can grant the Personal Site permission to a subset of people in your organization by using one or more security groups. |
On the Shared Services Administration site, in the User Profiles and My Sites section, click Personalization services permissions. Users and groups with the Create personal site permission can create a My Site. |
View and contribute to My Sites |
Even if an employee is prevented from creating a My Site, they can still view and contribute to documents on other My Sites, based on the permissions that site owners apply. We recommend that you allow site owners to manage permissions to content on their sites, rather than globally preventing users from participating in this type of collaboration. By default, all authenticated users are allowed to view and contribute to My Sites. |
On the My Site Settings page, add or delete members who belong to the Default Reader Site Group. |
Cannot access My Site content |
You can block users in your organization from accessing My Site content altogether by creating a policy for the Web application. Use this option cautiously because this prevents all collaboration on personal sites with the users who are blocked. A policy on the Web application overrides any other permissions that are configured within the application. |
On the Application Management page, in the Application Security section, click Policy for Web application. On the Policy for Web Application page, select the users whom you want to block, click Edit Permissions of Selected Users, and then on the Edit Users page, in the Permission Policy Levels section, select Deny All. |
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.