Sunday, January 25, 2009

Case Study - ECM for Enterprise wide Sharepoint Intranet Collaboration Portal

We recently completed development of my company's Collaboration Intranet Portal, here is a small case-study of MOSS features we have used and customizations we have done during the development phase:

1. Use of default Publishing features: We created a site collection using Collaboration Publishing Portal site template, in that way we got what we wanted for ECM including Page Publishing with Approval mechanism.

2. Site Structure and Architecture: We had a single site collection with various internal departments as Sites under One site collection like : we had Home as the top level site and then HR, Finance, Administration, Business Units etc as our sub-sites within the site collection. We had a single server farm, one dedicated search server and one SSP configured.

We had separate Virtual machines configured for Development, Content Management and Production environment respectively with WSS SP 1 and MOSS SP 1. We had identified a few Content Managers from within the respective units, who would maintain their respective sites for managing/uploading content in lists/libraries.

3. Capacity Planning: We had a Cord Core processor with sufficient hard-disk and 4 GB RAM, our capacity planning was based on the fact that we had a target audience of 3000 users within the organization.

4. Use of custom Master page, custom Page Layouts and custom styles: We actually created a copy of default.master, a copy of Page Layout from Blank Web Part page and a copy of Core.css from Style Library using SharePoint Designer, after creating copies of each of them we restructured the entire master page and added some new styles in our custom style sheet, we had to hide certain Content Placeholders from Master page(you should not delete these placeholders, instead place them all in an control with visibility as hidden to avoid errors), we then added a new Left Web part Zone to our Custom Page Layout, all using SharePoint Designer

But doing all the above mentioned customizations using SPD was not a viable option as all the pages would then become un-ghosted (customized) and everything would be then stored into SharePoint Content Databases, instead we copied all the three files we developed with SPD into the file system and deployed it as a feature using WSP builder, so we could get both the benefit of Visual design using SPD and Ghosting (un-customization). So we now have our custom master page, custom page layout and custom style sheet on the file system, making it more scalable across farms, as all of them have been deployed as features, we also have them under our source control now.

5. Use of .NET User Controls: We used a lot of pure .NET user controls within the custom master page, for e.g. the organization wanted to display names of its employees having their birthdays on that day, in a dynamic ticker which would change each day, the birthday data was exported from excel to SharePoint list using the Excel Add-In for MOSS 2007, click on the link to download,

We then used a calculated field to determine employee birthdays as on Today. Similarly, we also had a rolling ticker for News, Events and Announcements from SharePoint lists across all the sites in the site collection; we had to use impersonation due to some security concerns in accessing lists across subsites.

Similarly, we had to roll thumbnails of pictures from the Site Collection Image Gallery on the top-level site, when clicked the enlarged images would appear as a lite box pop-up. We could have used J-Query too, may be next time.

The beauty of using User Controls in master page is that we could maintain them without having to customize the master page, the hassle of upgrading the WSP file, redeploying the feature is no longer required, in case any of the user control file changes.
We deployed .ascx files in the Control Templates folder of the 12 hive structure, then deployed the DLL in inetpub\wwwroot\\bin, we also had to register the DLL in GAC

To create User Controls with MOSS, read this excellent post:

6. List Items as Pop-ups: We also made a .aspx page which will accept List Item Id to be displayed, List Name and Column Name as query string parameters, this was deployed in the LAYOUTS folder of the 12 hive structure, it meant that it will now be accessible to any site within the site collection due to the virtual directory _layouts which is mapped to the physical folder LAYOUTS, so if I have to call the .aspx page from the HR sub-site, I would call it in the following way: /HR/_layouts/ShowListDescription.aspx?ItemId=1&ListName=NewsEvents&ColumnName=NewsDescription
We used to link the .aspx page as a Read More… pop-up in the List View web part, so that it could show the description/details of that particular list item in a pop-up window.

7. Daily Back Up and Restore: Since, we had a separate Content Managers Environment for uploading data into lists/libraries, we would actually perform back-up and restore drills each day to move updated content from Content manager’s environment to Production environment. We created back-up and restore batch scripts, it would have to be run manually each day by a dedicated Administrator as he had to copy .bak files and move it across the server and then restore. Later on we found that this could have been achieved without manual intervention using Content Deployment Jobs, to download this white paper, visit:

8. Third party web parts: We used various free third-party web parts like the Quick
a. Surveys web part for Surveys & Polls (
b. Zone Tabs web part to show web parts in a tabbed manner (
c. RSS Feed Reader web part from CodePlex:
We also customized the existing Content Query Web part to include URL’s from Link List, here is an excellent article:–-link-lists-and-the-content-query-web-part.aspx

9. Use of Visual Studio workflows: We had to pick up email addresses from a master list based on the site context and send an Email alert to the appropriate contact, whenever a Suggestion/Feedback is entered from the portal; we used Visual Studio Workflows and deployed it as a SharePoint feature.

10. Search Scopes: We created context based Search Scopes like HR, Finance, Admin, Purchase using Central Administration and then added them to our Site Collection using Search Scopes setting at the top level site collection.

11. Stress Testing Tool: We used Microsoft Stress Testing tool in order to load test concurrent users, we created 100 dummy users and test scripts for all the pages, load tested our application for about 12 hours, we found RPS rate was good and the application didn't even crashed once, when the concurrent stress testing was going on.

All throughout i was reading Andrew Connel's book on Web Content Management for Sharepoint, (Go to Andrew Connels bookshelf) Heather Solomon’s blog for Custom master pages ( During my development phase, i got some help from John Holliday in relation to Disposing Sharepoint objects while using Sharepoint API. Liam Cleary's wonderful posts also help me profoundly.