SharePoint 2007 MySite Customizations and Architecture


Before we get started, keep in mind SharePoint 2010 is on the horizon. As such, I’ll start distinguishing between the two versions in my future post titles as I move forward. As I learn more concerning features publically announced for SP 2010 I’ll begin discussing them in more detail.

So here is yet another MySite customization post, this is intended to both “get to the point” rather quickly but also to provide a good explanation of MySite’s high level architecture as it relates to SharePoint 2007. The motivation for this post originates from a recent client request for a short presentation on the topic. I decided to first write this up as a blog post to help organize my thoughts.  I’ll spell out the important facts up front.

When we talk about MySites we’re really talking about two distinct site collections, not one. One site collection is for your personal use, the other is shared by all users for displaying your profile information. Now, this can be confusing when first attempting to customize these sites. So let’s next designate the names for each site collection as “My Home” and “My Profile” which also happen to be the titles used in the navigational tabs. Keep a sharp eye out for things easily tripped over like path names being similar menu names. 

An out of the box, single server, install of SharePoint 2007 places these site collections in two different logical (managed) paths using the installation defaults.

clip_image001  image

For my single server OTB install the following is true,

“My Home” is located on the logical path http://win-4w3peoo2hal/personal/{username}

“My Profile” is located on the logical path http://win-4w3peoo2hal/MySite

These site collections are located within the same “web application” at port 80 and share the same content DB, at least for the default installation. In a production environment these site collections would be located in their own web application altogether. 

The logical path for each of these site collections are maintained within the “Shared Services Administration” site and accessed by clicking the “My Site Settings” on the SSP default page. See the next image.


The “My Site Settings” configuration is as follows


You can see the “Personal Site Services” and “Personal Site Location” settings. These entries represent the two paths for each site collection (“My Home” and “My Profile”). To confirm this assertion just navigate to the “Define Manage Paths” within “Central Administration”.


Although Microsoft intends (and succeeds) in presenting a seemingly unified “My Site”, you now understand its really two separate site collections containing a copy of  common navigational elements displayed the same way within each site collection. Of course, each site collection serves different purposes. Obviously, “My Home” is your OWN site collection. Modifications using the browser interface or SharePoint Designer can be made, saved, but only seen by you. Changes made to the “My Profile” site collection will be seen by everybody.  

I’ll now point out potential areas of confusion.

The “My Profile” site collection (in this OTB example) lives at http://win-4w3peoo2hal/MySite but IS NOT a child site of http://win-4w3peoo2hal although it appears that way. This is reconfirmed by noting (again) that its defined as a managed path (see above image). In fact, true child sites (not site collections) created from the parent site will use precisely the same logical path syntax without the need to be designated on a managed path. Remember, managed paths designate the logical path only for one or more “site collections”, not sites.   

Another potentially confusing point are the naming conventions themselves. That is, the “My Profile” site collection happens to live on an OTB managed path called “mysite”, as already noted. Conversely, the “My Home” site collection lives on a managed path called “personal”. These seem a little odd to me? Why not just use “myhome” and “myprofile”? Ultimately, of course, these are configurable properties and not such a big problem. 

A few more details worth mentioning – the “My Home” site collection is located here on the managed path /personal with a designated “type” of “Wildcard Inclusion”, this essentially means multiple “site collections” can be added to the same logical path as long as the site collection path names are unique. As a consequence, several “My Home” site collections can exist by username. For example, /personal/user1, /personal/user2, etc. The “My Profile” site collection is located on a managed path with “type” marked as “Explicit inclusion”, this means only one site collection can exist on that path – in this case – the public profiles.

Mark Arend, from Microsoft at goes into these topics in more detail aided by a wonderful diagram. My goal here was to highlight those items you really ought to understand prior to performing any kind of MySite customization.

Methods of Customizing “My Home” and “My Profile” 

MySites should not generally be configured using the full set of tools typically exploited in a standard site design. For example, creating an alternate site definitions for the “My Home” site collection is actively discouraged by Microsoft, although use cases have been identified. MySites hold a special significants – at least with regard to how they are configured and customized within SharePoint. So lets hit the basics first – 

The site page templates and related files for “My Profile” is located at 12TemplatesSiteTemplatesSPSMSITEHOST. The “My Profile” site definition (onet.xml file) is located at 12TemplatesSiteTemplatesSPSMSITEHOSTXML

The site page templates and related files for “My Home” is located at 12TemplatesSiteTemplatesSPSMSITE. The “My Home” site definition (onet.xml file) is located at 12TemplatesSiteTemplatesSPSMSITEXML

What is common between these site definitions is that pages within the site collections can be modified using SharePoint Designer. Why? Because they are "site pages” located within a site collection, not application pages. Here are further considerations with  regard to SharePoint Designer:

SharePoint Designer

  1. For “My Home” SharePoint Designer will only change individual (and currently existing) sites on a user by user basis. Any new MySite provisioning will always assume its original site definition. So this method of customization is not able to create new corporate “My Home” (personal) site definitions (as you well know anyways by now).
  2. For “My Profile” SharePoint Designer can change the look of the person.aspx page for everyone because “My Profile” is a shared site collection (and page).
  3. SharePoint designer will place any page into a customized mode (where the page differences are stored in the content database). For individual personal sites this would not have a significant impact on performance. For “My Profile”, a page often hit, this could impact performance depending on how many MySites have been created and overall site activity.
  4. SharePoint Designer does not play well as a source control mechanism. Often, changes will be made to a production environment without appropriate safeguards and controls. It is up to the user to manage any changes made in their site. To the extent that prior file versions can be managed using SharePoint Designer, it unfortunately sets up a parallel source control process that increases administrative burden.

Overall, SharePoint Designer is most appropriate for one-off changes a user wants to make for their “My Home” site collection. Usage beyond that point can lead to chaos, or at the very least performance problems. Although you need to decide for yourself. The next section covers changes made directly to the 12 hive files

Directly customizing the 12 hive site definitions (paths shown above).

  1. Directly customizing MySite definitions is not supported my Microsoft. Generally speaking, if the correct approach is used its rarely necessary to change 12 hive files in the first place. Arguments can be made and use cases constructed for making “unsupported” changes directly to 12 hive files but carefully weigh the benefits / risk.
  2. The impact of changing the My Home site definition directly (assuming no bugs) will be that any newly provisioned personal (My Home) sites will assume the look and feel defined by the new site definition, master page, and templates. However, already provisioned “My Home” site collections will not assume the new look and feel  – and most likely existing sites could not be re-provisioned for the new look and feel without considerable work, if at all.
  3. The “My Profile” site collection will not assume the new look and feel because the site collection was already provisioned. Additional steps need to be taken (such as re-provisioning the site collection, for example) to have new changes picked up.  Although its a much simpler task because we are only talking about a single “shared” site collection.

One take away from the points just made is that you need to take into account both existing sites and newly provisioned sites in formulating your approach.

Customizing the “My Home” and “My Profile” site collection using standards and best practices.       

The correct way to customize MySites is to use best practices – which really just mean deploying customizations using solution packages. However, for the “My Home” site collection, for example, a single solution package containing some customized site definition is not a complete answer. Why? Because typically companies want personal sites to use some corporate standard but often only AFTER many MySites have already been provisioned (using older branding). So a site definition is insufficient. Also, Microsoft discourages any alteration of the onet.xml definition anyways. Ok, so what do we do?

For “My Home”, the accepted approach (which eliminates the need for site definition changes altogether) is outlined as follows:

  1. Create a new master page for “My Home”
  2. Add a server control to the new master page that makes any site changes programmatically. The control is deployed as a separate solution.
  3. Create a Feature that provisions a new master page for “My Home” (programmatically activate this feature for all existing personal sites)
  4. Create a Feature stapler that activates the new master page when provisioning a new personal site.
  5. Bring these elements together as a solution file and deploy

When an older (existing site) pulls up the new master page the newly added server control can detect if changes still need to be made. If so, the code executes and does its work. If the older site has already made those changes then the site page just comes up in the new look. The sites property bag object holds a flag that’s used to determine the appropriate action.

The actual steps (in detail) can be found here –

One word of advice, the solution to the problem resolved by Steve Peschka (in the above link) is more generalized. His approach is to read in a configuration file (in the form of xml) that directs the new server control (on the new master page) with what changes to make programmatically. When I prototyped this approach myself I found it was much less code just to make the specific changes I needed, although your mileage may vary.

Ok, what about “My Profile”? Three approaches can be taken for customizing the “My Profile” site collection, depending on the complexity of the changes required. The first, as already outlined, is to use SharePoint Designer. The tradeoffs of this approach have been discussed. The second approach is to copy the site definition (and associated files from the 12 hive), make the required changes and deploy that as part of a solution. You may now be asking, “should I change the site definition or page template?” The short answer is to try and NOT change the site definition. Of course, the third is programmatic as discussed for the My Home site collection.

The solution presented for the “My Home” site collection needed to consider both new and already existing MySites. A programmatic solution was required in that case. However, for the “My Profile” solution this could be “programmatic overkill” – but I suppose some exceptions could be justified for using the programmatic approach. SharePoint Designer is never a great option in an enterprise environment.

So not changing the OTB site definition but rather the person.aspx for the “My Profile” site collection really appears to have the most practical set of tradeoffs (as long as you make these changes via solution deployment). The steps are as follows

Addendum: corrected this section to reflect recommendations for NOT changing the OTB site definition for “My Profile”

  1. Copy the SPSMSITEHOST site definition, make alterations as required to the person.aspx page 
  2. Package as a solution, deploy, and re-provision the “My Profile” site collection.

The site definition and/or page templates are deployed within a solution in keeping with standard practices – rather than directly changing the 12 hive files. The decision for making these changes programmatically versus changing the OTB definitions (or person.aspx) really comes down to your specific requirements and your willingness to support the solution.  

One last word of caution – changing any OTB site definition could impact the amount of work required upgrading to SP 2010. At the very least understand that upgrading any custom site definition will immediately be added work. Finally, if upgrading to SP 2010 is a real concern then a programmatic approach my be helpful (although its much to early to know how programmatic changes compares to site definition changes).

Finally, the approach outlined here can be found at this link –

I hope this was helpful – Cheers!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s