Sunday, November 18, 2007

Branding Intranets with SharePoint (MOSS) 2007

Now let’s cover how we subsequently rebranded our intranet and increased employee self service to drive user adoption.


The strategic goals (from a company perspective) of the MOSS branding project were as follows:
1. Brand intranet.
2. Role/Persona approach versus functional. We developed a persona based approach to content delivery. Identified roles in the company and organized content so that these roles would have most of their daily needs served in one place. (We conducted a company-wide survey in which we asked people to organize information into buckets based on their roles and factored those results into our solution).
3. Minimize clicks / navigation to critical information. This is aligned with the above goal. We wanted to allow colleagues to get to information as fast as possible.
4. Page based delivery. We wanted to surface information in terms of pages which colleagues could easily read instead of abstract documents in a document library where a guess was usually required to find the needed information.


We identified two distinct project tasks in line with the above goals:
1. Develop the company brand.
2. Create the content to support the strategic goals. This was an important step because the content had been created in terms of documents in libraries. We had to pull out this information into user-friendly pages to enable employee self service.


The distinct pieces are explained below:

Develop the company brand
We engaged a design company to create the brand for us. Here is what the original provided design looked like:








We modified the design slightly to make the best use of SharePoint features. We then signed off on the design and got to work on implementing it.


User Interface
The various elements of the user interface are master pages, page layouts, site definitions, Web Parts, navigation controls and xsl transforms for placement of content.


Master pages
There are three ways we could have chosen to build the custom master pages.
1. From scratch - not recommended as SharePoint 2007 needs a few placeholders to be present in the master page or else the pages will not work.
2. From minimal.master - not recommended for a collaboration intranet, serves a .com site much better. The reason is that in a collaborative environment, you want to use OOB features and controls that SharePoint provides and a lot of these are declared in default.master.
3. From default.master - recommended as this allows you to use most of the collaborative controls already present on the master page. This master page does have a learning curve though.

We chose #3 and developed the master page for global branding. We took out what we did not need but retained a lot of the collaboration functionality declared in default.master. The master pages were developed using SharePoint Designer along with the style sheets that are discussed below.

These master pages were deployed as features to the target server. A note worthy of mention is that Microsoft recommends that we do not change application.master so we left it as is. That did cause a little confusion but we covered it pretty well in training. Only the site admins and the content authors saw this difference anyway, the majority of users did not.


Page Layouts
We worked with the design company to come up with page layouts that would enable us to serve content in line with the corporate strategy. This meant modifying the 9 predefined page templates to provide the desired content layouts. This was done for both the SMARTPGS templates as well as the BLANKPGS template.

We used SharePoint designer to modify the page templates. We took off the override for the left navigation placeholder to allow the site left navigation to show up from the master page. We also changed the percentage widths of the table columns to better suit our business requirements. This provided all our pages with consistent branding so as to reduce user confusion.


Site Definitions
The business requirement was that when new sites are created, a predefined set of Web Parts should appear on the default page for ease to the content author as well as from a governance perspective. The other requirement was that the brand should be applied to the site upon creation.

We developed 5 new site definitions that would serve 95% of the typical needs. We modified these site definitions and created/modified the WEBTEMP.xxx.xml and the ONET.xml files to place the selected web parts on the page. The recommendation here is to copy from the existing sts site definition and then rename and modify that to create a new site definition. We also wrote a custom provisioning provider that would intercept the site creation request and assign the correct site template and master page to it to meet the business requirement.


Navigation
We needed consistent global navigation across many site collections to ensure consistency and enforce the brand. We also needed current navigation that could be maintained at a site level. After some investigation we decided to develop list based custom navigation providers that would meet the needs of global and current navigation. This was also a very user friendly solution in that it allowed the appropriate users to set up and easily change global and current navigation in a custom list, with no IT involvement. To improve performance, we cached the global navigation tree so it would not need to be assembled for every site.

This is a view of the global navigation shared across all site collections. It includes one level of dropdowns.





Here is a view of the current navigation which is specific to every site:







We created custom site columns, custom content types and then a custom list that used these content types to allow users to easily build hierarchies that the navigation provider could read and deduce the navigation levels. Here is an example of the custom list for the top navigation content. The actual URLs below in the Url Link column have erased, but this should get the point across.







Building custom navigation providers means that we did not have to build special navigation user controls, we made minimal changes to the master page to switch to our navigation provider for navigation content. One tip here is to start debugging your provider early and often. For folks developing custom providers for the first time, it would be prudent to develop them in ASP.NET first to get a good understanding of how they work, only then proceed to build them in SharePoint. We used Visual Studio 2005 to develop and debug the custom navigation providers.

We would like to point out that not only did we reuse SharePoint to hold the data, but we are also using the SharePoint security permissions to secure who is able to get access to and change the data in the list, and ultimately the navigation.

CSS
We used CSS styles to achieve our design goals. Core.css defines most of the standard SharePoint CSS classes. Every site and application page is linked to core.css. We left core.css intact (as is recommended by Microsoft) but 1) changed the direct references to core in default.master to point to a custom style sheet and 2) overrode some of the other indirectly referenced core styles by defining a few styles in the master page itself. We also developed secondary style sheets that would enable us to change the color theme on sub sites easily and used the AlternateCSS setting to attach the secondary style sheets. The effect is shown below.






Web Parts
We purchased a few third party Web Parts that served the business needs really well. These included a stock ticker Web Part, weather Web Part and an image rotator Web Part that gave us quick bang for the buck. We also used XSL transforms to place information in a desirable manner using the Content By Query Web Part.


The final design looked like this:





Content Creation
As discussed earlier, most of the content was previously stored as documents in libraries. From a company strategic perspective, we decided that in order for the more relevant content to be of greatest use to colleagues, it would need to be pulled out from documents and surfaced on pages along with action items that users might consider after reading the information. In our mind, this strategy would go a long way in driving user adoption and employee self service. We assembled a content creation team that encompassed content authors from all departments who would then be responsible for the relevant content for that department.

This strategy did indeed pay off and user adoption increased many fold.

This entire branding project was fast paced and was completed in 6-7 weeks from the inception date. The newly branded site went live on October 1, 2007 with only 4 support calls the entire first week. There have also been no issues reported since that time, so the project team is proud of the work we have done.

Update on Persona based approach: Persona based approach basically means (to us) as understanding the user types (personas) that will be visiting the intranet. Once we divided people into categories (such as general workers, managers, executives) we went ahead and developed persona based sites so that these classes of people could get all or most of their day to day needs served in one place (as opposed to trying to find this information and wasting time). Examples of day to day needs include employee benefits information, travel guides, travel expense forms, career center, information for new colleagues to get started, rewards information, recognition information, performance mangement tools for managers, learning center links, ethics and compliance links. This simplifies the dissemination of information, updates, as well as keeps the single source of information intact.


Here is a snapshot of the Departments and Teams page. This is just a listing of where to find more information, most of our departments were in different site collections.

Friday, November 16, 2007

Migrating SharePoint 2003 to SharePoint (MOSS) 2007

Overview
Approximately 3 years ago, we successfully completed a project to migrate the corporate intranet to SharePoint 2003. The project was primarily driven by IT, wherein we analyzed and selected a product which would meet the needs of the business; hence the business would thank us for finding a great product and adopt it. We selected the right people to be site admins and delivered training to these individuals with the mandate that they would drive adoption in their respective business units. However this did not turn out to be the case. We noticed that initially the user adoption increased but then started tapering off as users started finding little quirks in the product. Some of the notables were that search did not always get the most relevant results, it was cumbersome to navigate from one site to another or to get a feel for where you are in the site hierarchy, navigation links were not security trimmed leading to frustration etc. to name a few. We only branded the main areas of SharePoint 2003 but not the sites which led to an inconsistent look and feel. Finally, there was no governance committee to oversee the intranet and hence company colleagues were free to do what they liked. This amounted to information being stored in the form of documents in document libraries, which was hard to find without explicit instructions.

Below is an example image of how the SPS 2003 intranet looked earlier this year.














The MOSS 2007 opportunity
MOSS 2007 provided an enhanced feature functionality set. We performed an initial assessment against the pain points and determined that the MOSS enhancements/OOB features met IHS strategic goals. We went over the features and placed them into two buckets based on priority, ones that we need now vs. others that could wait. This helped us decide the licensing model for MOSS. We devised the hardware architecture and evaluated the different migration approaches/risks. At the end of this phase, we decided to go with the Content DB migration option. The reasons for this are follows:
1. IT initiative to consolidate to a single hosting center with leading practice hosting services and monitoring. Our intranet was hosted on 32 bit architecture and we preferred to move to 64 bit to utilize the performance benefits that it offers. Another motivator was that the cost difference between the two was minimal.
2. We had over 100 GB of data, but the majority of data was stored in WSS site collections, not in SPS areas. We only had a few areas and we were willing to lose those, as they did not contain any required information, they were just hooks into the appropriate WSS sites. We also had a few custom site definitions - but we were only interested in upgrading a couple of them.
3. We tried a couple of trial runs of the migration using the content database approach - and things migrated over pretty well for the most part.
4. Microsoft does not recommend the in-place upgrade because if something went wrong during the migration, it’s difficult to restore.
5. We did not want to go with the gradual migration approach as well because there was risk in our mind. This included installing both MOSS and SharePoint 2003 on one production server, performance issues this may have caused, disk space issues we may have run into given that we were running out of disk space on that server.
6. We also evaluated four 3rd party tools that we felt could assist us in the migration but turned them down because they did not meet our needs completely, or that significant post migration cleanup would be involved.

Finally, the intranet goals for IHS were:
1. Strategy / Governance
Define intranet as critical component to corporate communication strategy
Solidify our intranet strategy, usage and measures
Form an internal governance council and supporting processes
2. Content Migration / Foundation Upgrade
Coordinate migration with business to minimize user impact/downtime
Support customizations and integration points
3. Branding & Content Re-organization
Take a role/persona approach versus functional
Minimize user clicks / navigation to critical information
Implement a page based delivery
After finalizing the migration approach (which was our single biggest X factor), we went back to planning the migration and worked on the documenting the four phases that any SharePoint migration consists of: Planning, Preparation, Migration and Clean Up. A big misconception in people's minds is that the planning and preparation phases are very small and the actual migration and clean up phase is what matters. Nothing could be further from the truth. To the contrary, the planning and preparation phases are critical to the migration and should be allotted ample time. To underscore how important the planning phase is, here are some of the tasks we completed in the planning phase: understanding the big picture and defining future state, understanding the current deployment and usage, assessing SharePoint 2007 features, licensing, planning and validating architecture, getting buy in from all business units and executive sponsorship, choosing a migration option and running test migrations, planning customizations, creating a networking and domain name plan, creating a communication plan, creating a testing plan and training users on moss etc.


IHS Project Approach
Here we will provide a high level overview of the approach we took with the SPS 2003 to MOSS 2007 migration.
1. We used standard software lifecycle methodology (Design, Develop/Test, Deploy).
2. Solicited executive sponsorship and created a governance team. We also formed a collaborative project team (IT & Business). This gave us a big boost as the corporate communications and key business stakeholders "owned" the intranet migration and therefore took it upon themselves to push for governance and adoption. IT was no longer a driver, but a facilitator.
3. Gathered necessary requirements for design.
4. Defined scope – business approval. We effectively split the project into 2 phases: the as-is content migration to MOSS and then subsequent creation of the company brand. We separated these goals into 2 different projects to tackle each one individually and ensure nothing fell through the cracks juggling two sets of tasks.
5. Used content DB migration. The reasons for this decision are explained above.
6. Did not upgrade 2 out of 4 custom site definitions as we felt that MOSS would address these needs OOB. We wrote custom site definition and upgrade files so that the remaining site definitions would upgrade successfully.
7. Did not migrate MySites as the user adoption was very low and we discovered through communication that the users would not mind losing their SPS 2003 MySites.
8. Did not migrate any 3rd party Web Parts as these had to do with navigation. MOSS 2007 provided this functionality OOB.
9. Did 4 trial migrations to ensure that content migrated and the development team was comfortable with the result. This also allowed us to tweak our steps in the migration phases.
10. Established Training and Communication plans for end users and delivered worldwide training.
11. Created a testing plan and performed testing to ensure that the hardware would be able to serve our users and that there would be no performance concerns after go-live.
12. “Froze” SPS 2003 for 3 days as we moved the 100 GB database over and completed the migration, clean up and final testing for MOSS. This means that SPS 2003 was in a read-only state.
13. The DNS change was transparent as we just changed the entries to point to the new servers. The users entered the same URL and they were taken to the MOSS 2007 intranet instead. We still maintained the old intranet as a different URL if users wanted to compare or felt they had missed something. Fortunately the number of such requests was less than 5.
14. Performed migration in off hours and over the weekend. This limited the downtime as a small minority of users use our intranet over the weekend.
15. Re-architecting SharePoint content in terms of pages. As mentioned previously, without active governance our SPS 2003 had become more of a document repository than we were comfortable with. So the governance team took it upon themselves to engage colleagues from various business units who would build informational pages and links to next steps. This is an ongoing operation and will be discussed in part 2 of this series.


Here are the high level upgrade experiences
1. The upgrade took 4 hours. We migrated 800 sites and 100 GB of data.
2. All the WSS site content migrated with the same structure as SPS 2003.
3. Search scopes, keywords, best bets, audiences were recreated as these did not migrate.
4. We needed 2 days of post migration cleanup and tasks – links, web parts that were not migrated, scripts, integrations with other applications.
5. Communication had to be repeated as some users did not read that the intranet would be read-only.

To learn other migration Do's/Don’t's and if you need further information about the tasks we completed in each migration phase, please see the slides (from my September blog post) from a recent presentation at the Rocky Mountain SharePoint user group where we spoke about our migration experience.
After the migration, here is what our SharePoint intranet looked like. We added the Under Construction image to indicate that this was a temporary look before the final branding.




In part 2 of this series, I will talk about how we branded SharePoint 2007 for our intranet.

Thursday, November 8, 2007

How to Change SharePoint Site URL

Sometimes you will have a requirement to rebrand your site with a new domain name for various business reasons. We had a business case a little over a month ago wherein we had to change the brand for our intranet. The requirement was that users visiting the old site would get redirected to the new site automatically. History: We had migrated our SharePoint 2003 intranet to MOSS 2007 and we now wanted to give it a new brand to drive excitement and adoption.



Here is a slick way that I devised to achieve this switch easily. This worked like a charm so if you have a similar business case, test this to decide if this will meet your needs. The URLs and Website names are made up, but they serve to demonstrate how this is done.



We had 2 Web applications for the intranet (one for the main portal and one for MySites). The DNS names were oldintranet.ihs.com and mysite.oldintranet.ihs.com, as an example.



The new DNS names we decided to go with were newintranet.ihs.com and mysite.newintranet.ihs.com.



Here are the steps:

1) On the target server, assign 2 new IP addresses. This is because you can only have one SSL Website enabled on one IP. Create 2 new Web applications (a collaboration portal for newintranet.ihs.com and a MySite for mysite.newintranet.ihs.com) on these 2 new IPs.

2) Procure and attach the appropriate certificates to these Web applications (if using SSL). Create the relevant site collections for these Web applications. Make sure that the new web applications work correctly when you browse to them.

3) Make sure to save the certificates as text files on the C: or D: drive for all the 4 Web applications involved.



--- So now we have a total of 4 IIS Websites. Lets assume these are called MOSS_IHS_Intranet_Old and MOSS_IHS_Intranet_Old_Mysite and MOSS_IHS_Intranet_New and MOSS_IHS_Intranet_New_Mysite. ---

--- Here is where you will have a few minutes of downtime, so do this during a maintenance window ---



4) Go to central administration and change alternate access mappings for newintranet.ihs.com to newintranet2.ihs.com. Similarly change alternate access mappings for mysite.newintranet.ihs.com to mysite.newintranet2.ihs.com. (We change these to arbitrary names so that some other Web application can claim the names that we are changing).



5) Now change alternate access mappings for oldintranet.ihs.com to newintranet.ihs.com and mysite.oldintranet.ihs.com to mysite.newintranet.ihs.com. (Now we change the old headers to the new ones so that the new headers serve content for the old Web application - which is where the content lives anyway. MOSS will do the heavy lifting of changing all the links served on pages to the new URLs we just applied. An exception to this is hard coded links in the Content Query and/or the Links Web Parts).



6) Similarly, now change alternate access mappings for newintranet2.ihs.com to oldintranet.ihs.com and mysite.newintranet2.ihs.com to mysite.oldintranet.ihs.com. (Now we claim those old headers for the new sites so that the old url effectively points to the new Web applications - which have little to no content. We will use these old host headers to merely redirect users to the new URLs).



-- So far we have only done half the work --



7) Go to IIS, right click on the old Website MOSS_IHS_Intranet_Old, click on the Web Site tab and click on Advanced. Here change the host header value from oldintranet.ihs.com to newintranet.ihs.com. This is to match in IIS what we did with alternate access mappings so everything is in sync. Do this for all 4 IIS Websites in question.



8) Change the certificates in IIS. As the host headers were mismatched, so are the certificates. Right click on Website, click Properties and browse to the Directory Security tab. Click on Server Certificate --> click next --> Remove the current certificate. Then attach the certificate that matches the newly changed host header from your hard drive (these were saved in step 3). Do this for all 4 IIS Websites.



9) Swap IPs between the corresponding Web applications. In IIS, right click on Website --> Properties --> Web Site tab --> Advanced --> change IP for both the "Multiple identities for this Web site" as well as "Multiple SSL identities for this Web site". For example, swap IPs between MOSS_IHS_Intranet_Old and MOSS_IHS_Intranet_New as well as between the MOSS_IHS_Intranet_Old_Mysite and MOSS_IHS_Intranet_New_Mysite. This is done to preserve the original IP mappings that we had after step 2. This also helps in keeping the same IP address for the old site and the new site. The new DNS names could then be pre-advertised so that after you are done with this step the old content is being surfaced using the new host header. No funny DNS entry changes required at the last minute.


Now you are done.
10) Now finally add a redirection to the old host headers (newly created Websites) so that they exist merely to redirect all requests to the new host headers (attached to the old Websites where the old content will be surfaced). Go to IIS --> right click on newly created Websites --> Properties --> Web Site tab --> "The content for this resource should come from: --> Select "A redirection to a URL" and specify the URL to be the corresponding new host header. (Do this for both the new Websites.)



You are done. This method may sound complicated, but its not - if you understand what is going on. What we have effectively done is switched which host headers are responding to which content. So now when you browse to the old url, you are automatically redirected to the new url which is serving the old content - the links are automatically changed.

This also helps in house keeping. Once the new url has been sufficiently advertised, you are free to delete the Web applications that are serving the old url, because they point to the new content - which is meaningless for your purpose anyway.

Realize that there are other methods of achieving this goal, but this works pretty well and has the advantages listed above.

Missing In Action

So I haven't been able to blog for the past month and a half coz I have been busy travelling to a lot of places. I visited Bombay, Dubai and London for vacation and it was pretty awesome to say the least. I'll post some interesting pictures of the trip on here soon.