The concept of My Sites in SharePoint is often ignored in deployments due to the lack of understanding of the value that My Sites add when an organisation is considering a SharePoint deployment. One of the compelling reasons that I see for organisations for allowing My Sites to be enabled in a deployment is that it allows your users to explore and also learn on their own without being restricted to a "corporate rule". Recently Michael posted 10 tips of establishing "your" profile with My sites, which I must say is along more than enough reason that you should seriously consider opening My sites in your SharePoint deployment since it provides an instant findability and contactability solution for connecting with people in a large organisation.
From an IT and architecture point of view My Sites can be resource intensive and you need to plan accordingly before you open up My Sites to thousands of users. The reason My Sites are resource intensive is because each person's profile is invoked at the time when a user clicks the "My Site" link. I.e: The site provisioning code namely the UserProfile object and profile.CreatePersonalSite() is run in the background which results in a site collection being created. Also a when a user browses to a My Site profile page a series of web parts query the user profiles database to retrieve profile property information related to each user. This is typically via a URL such as "http://mysites/Person.aspx?accountname=MOSS\chandimak" or a URL with a GUID such as http://mysites/Person.aspx?guid=A151E8C0-6F59-42B7-AE2C-C9E06E5059CE . The "Person.aspx" contains a number of web parts that retrieve information from various sources. This page is also the page users visit when using the "People Search" functionality in SharePoint. That is to say when someone performs a Search by selecting the "People" tab the results are links to the matched My Site profiles.
The information is usually retrieved from your Active Directory or the profile properties can also be manually imported or inputted by users by selecting "Edit details" in their own profile page. One thing you should know is that these properties are not limited to what is configured by default. User profile information is used by index and search services to provide better search results, and is used in targeting content to audiences. You can import user profile information directly from AD directory services or enter it manually. You also have the ability to customise the properties of the user profile according to the needs of your organisation or to map to existing AD properties.
While browsing a persons private view of a page (that is me browsing my own My Site) a few web parts query and retrieve information. One of these web parts is the Colleague Tracker.
The Colleague Tracker actively informs me of changes to people's profiles. As a user you can also change what is being tracked.
The cumulative result of all of these web parts providing information from various sources (mainly from the Profile database via the SSP) is reasonably resource intensive. In fact the majority of the information is from the single profiles database.
Whilst you can provision all "My Site" content to be stored in a dedicated database or spread across several databases by applying this as a planned deployment stage the profile database is part of your Shared services. Note that the correct way to implement My sites is to host these on it's own web application and apply the personal sites quota template.
Via command line:
stsadm.exe -o extendvs
-url <url>
-ownerlogin <domain\name>
-owneremail <someone@example.com>
[-exclusivelyusentlm]
[-ownername <display name>]
[-databaseuser <database user>]
[-databaseserver <database server>]
[-databasename <database name>]
[-databasepassword <database user password>]
[-lcid <language>]
[-sitetemplate <site template>]
[-donotcreatesite]
[-description <iis web site name>]
[-sethostheader]
[-apidname <app pool name>]
[-apidtype <configurableid/NetworkService>]
[-apidlogin <DOMAIN\name>]
[-apidpwd <app pool password>]
[-allowanonymous]
Example:
stsadm.exe -o extendvs -url http://mysite -ownerlogin moss\administrator -owneremail demo@kcue.net -exclusivelyusentlm -ownername "Administrator" -databaseserver MOSS-SQL -databasename WSS_Content_MySites -sitetemplate spsmsitehost -description "My Site Host" -sethostheader -apidname MySiteAppPool -apidtype configurableid -apidlogin moss\mysiteapp
Will create a My Sites web application named http://mysite in a database named "WSS_Content_MySites" and apply the "spsmsitehost" template.
Once the application has been created you will need to enable self service site creation via Central Administration and ensure that Personalisation Services are set appropriately. By default the "NT AUTHORITY\Authenticated Users" have full rights. You should remove this group and add a specific AD group or create a pilot My Site Permission group with some specific users that you can manage specifically for the purpose of using My Sites.
These decisions require to be thought out and decided with business requirements in mind since My Sites are primarily meant to encourage collaboration within individual team members. The site collection boundary effectively isolates My Sites from being less structured and allows free thinking and the ability for your users to get familiar with concepts of specific SharePoint functionality. From an IT governance point of view My Sites can be managed and monitored by using the following controls.
- Quota Templates - Quota templates are applied at web application level. My Sites by default can be set with the Personal Site quota template (100MB)
- Recycle Bin - Site Level and Server Level should be set accordingly
- Blog API - On or Off (Link to create personal blog under My Site)
- Site use confirmation and deletion - Automate sites to be removed if not used for a XX number of days (Alerts site owners before deletion)
These are just some of the administrative controls that IT teams can use to ensure that My Sites are used effectively within organisations.
Resources: