Tag: Implementation

Review – Pro SharePoint 2010 Branding and User Interface Design

I was recently given a chance to review this book thanks to one of the books author’s John Ross.  While my main focus is not on branding and user interfaces it is a critical component of the SharePoint solutions my team delivers and also one of the important things that can separate successful from failed implementations.

This book does a great job of providing an overview of the branding options with SharePoint 2010 (Foundation and Server).  It also does a really good job of showing how things have changed which is an important thing to understand since the there are so many new controls and features (ribbon) and the previous use of nested tables has been all but abolished. 

There are some valuable tips for “simple branding” which would is great information for Site Owners to have as they manage their local department or project site.  There is also great information on more advanced branding that can cover your overall marketing and communication standards.

One of the really nice things about this book is that it highlights some of the landmines that can pop up during your project.  Understanding where in an inheritance chain to style or not to remove the !Important commented items can save you hours of grief.  The Content Placeholder reference for MasterPages is also incredibly valuable.

From my perspective one of the most important chapters is on deployment.  Since user experience guys are not always coders they are not always familiar with how to properly deploy their brilliant work.  SharePoint Designer is a valuable tool, but it should not be used to maintain the branding and user interface changes for your environment (with very few exceptions).

All told this book provides a great overview of all of the areas and depth to important topics designers need to know.  This book should be a good fit for SharePoint Developers or Administrators needing to do simple branding, Site Owners looking to apply some customizations, or for Designers looking to create robust user interfaces on the SharePoint 2010 platform.

Professional SharePoint 2010 Branding and User Interface Design

SharePoint Governance and Continuous Improvement

There are a number of reasons why I have seen SharePoint Governance stall in many environments, but one of the most common reasons and the one I would like to address today, is the problem of trying to take or address too much scope at once.  There are a lot of topics that roll into SharePoint Governance; the SharePoint Governance Framework we use at my company identifies over 50 distinct topics.  In most cases it is not practical to take the full list of topics and work through a governance plan in one pass.  Instead, I advocate for an iterative approach starting with a selection of core topics and finding a pace that matches your organizations cadence to continue solidifying the process.

Continuous Improvement

Continuous Improvement (CI) is a concept that relates to Lean, Kaizen or TQM practices and is intended to use small, incremental changes to bring big results instead of trying change everything at once.  There are many advantages to this approach but the one that resonate most with me is that the incremental investments could be very small, but you start to see gains quickly.  I believe this relates very well to the process and concepts of SharePoint governance.  As you start to gain momentum you are much more likely to get stakeholder involvement which is critical to any governance effort.

Selecting Topics

The selection of topics is important.  There are some topics that lay the foundation for everything else.  I typically start with the core topics that are needed to define the service and system to be implemented (or that has been implemented).  I then move to the most critical items that are needed for managing the system such as touching on the core Information Architecture, Site Topologies, Site Creation Process (who/how/where) and Permission Management.  Over time, and definitely in more mature organizations, you can start to tackle some of the more subtle topics.

Depth for Topics

When reviewing a topical area, it is important to iterate there as well.  For example, when starting an implementation stakeholders may have a decent idea what the service definitions and SLAs might look like, but this will certainly change after it is in use for a while and perhaps became mission critical for core business processes.  As these requirements and needs evolve, additional iterations are required.  This fits very well with the CI concepts mentioned above.  These iterations continue to deliver more value to the stakeholders in small increments.

Finding a Pace

Finding the pace for the governance work can be difficult.  I think the pace for change in any organization is heavily tied to the organization’s maturity.  Anyone that has been IS/IT or IS/IT management for while should be familiar with the Capability Maturity Model.  In Level 1 organizations things are completely chaotic, with ad-hoc efforts which means you are constantly chasing a moving target.  As you progress up the maturity model though, there should be more discipline and an ability to stay focused.  In these organizations it is possible to iterate more frequently and potentially to tackle more topics in parallel.  There is no doubt that more mature organizations work more efficiently.

Other Considerations

Governance should be an ongoing process and the document should be a living document that continues to see change over time as the organization and it’s needs evolve.

It is also important to note that groups should not take a shortcut and try to minimize the stakeholder involvement to simplify the process or to quicken the pace.  Stakeholder involvement, specifically non-IT, is critical to these efforts and it could be argued that you really do not have any governance without this involvement.


Governance is a key aspect to success with SharePoint and by taking the right approach, and one that is in sync with your organization’s capabilities will greatly increase the likelihood that your governance effort will be successful.

Keys to Long Term SharePoint Stability and Success

Recently I have been called into a few environments where the customers were having some serious performance problems or had features that were no longer working.  It really nailed home the point that Capacity Planning should really be Capacity Management as Microsoft now refers to it in their Capacity Management and Sizing Overview guidance for SharePoint 2010.  These environments also tend to have some other issues with patching and large un-used content databases.

The Keys below will help establish long term success for your SharePoint environment.

Initial Design and Planning

The planning and design work that typically goes on prior to an implementation is based heavily on assumptions and the understanding of current requirements.  In any environment where an application like SharePoint takes off, those assumptions change quickly, the needs of the business evolves, and therefore all of those requirements change.  In many cases though, the SharePoint farm topology is not changed and can no longer meet the needs.  With the current state of IT many resources are stretched and do not have time to make major changes to the system, but in many cases a few proactive changes would remove some of the ongoing system support and troubleshooting efforts.

Continued Monitoring

Every system needs regular monitoring.  The frequency and depth of the reviews depends on how complicated the implementation is, but below I have listed out some generic topics that can be reviewed.

Quarterly Review

  • Memory and CPU Utilization
  • Patches – Review new patches and install if appropriate

Semi-Annual Review

  • Review Content Databases – Number of Site Collections per Content DB and the size of each Content Database
  • Search Index Health – Number of items in the index, length of the crawls
  • Average and Peak Usage Stats – Review the average and peak user stats and add hardware if needed.

In addition, in some cases new features are enabled or leveraged months after the initial implementation.  If for example you are going to use SharePoint to host your BI solutions additional capacity may be needed.  If the system was initially designed for a pretty basic Intranet and the BI capabilities are added then the system may not be able to keep up.


Patch management also contributes to keeping your SharePoint installation stable and high performing over time.  Installing Service Packs or the bi-monthly Cumulative Updates can be difficult in some environments where maintenance windows are tight, but these patches will also help keep services running smoothly and bugs at bay.  I worked in one environment where at least three major issues were all resolved with previously released patches.  Unfortunately a lot of time was spent troubleshooting needlessly.

Prune the Hedges

Most information stores get bloated over time, SharePoint is not immune to this.  IT groups have been fighting this for years with shared drives and mail servers.  It is important to have some good retention policies in place to make sure you are keeping the right content, but also getting rid of the stale content.  At the very least you can implement an archiving solution that can move the content to cheaper storage, while keeping it accessible.


Following these recommendations will greatly increase your chances for maintaining a highly capable, well performing environment.

Keys to Planning For SharePoint Search

Of the core planning areas in SharePoint, Search seems to get very little attention.  I find this surprising since one of the most common complaints from SharePoint implementations (or any Enterprise Information System) is that users cannot find “anything” in the system.  Most of the environments I go into have Search configured in only a very basic sense; a search site was created and crawling is scheduled.  To really get value out of the search features, and to greatly enhance the end user experience, additional planning and configuration is required.  Like many of the high level planning topics, the goals and plan should be reviewed at least once a year to ensure that the current goals and expectations are aligned.

Evaluate the Content

Not all content is equal.  The format of the content (File Type, Lists, Web Sites), the freshness of the content, and the purpose of the content can vary dramatically and may need to be handled differently.  Evaluate the types of content in the system currently along with any new types of content expected to be added in the short term.

Three examples of the different types of content could include:  Enterprise Content Management, Help Desk, and Project content.

Enterprise Content Management – Large ECM data stores primarily include structured data used throughout the organization.  Examples could include things like Sales Orders, Purchase Orders, or anything that is used by multiple departments throughout the organization.  Search tends to be very important to large data stores like this since the content is not easy to browse.

Help Desk Content – In most medium to large organizations there is content used to support the Help Desk functions spread through multiple sites, and perhaps multiple systems.  Some content might be document based, some might be in SharePoint lists for things like FAQs, or other formats.  While a regular keyword search may bring back relevant content, this is a great example of a case where a custom Search Scope could be created to narrow down the content locations or types that are queried against.

Project Data – For organizations that manage a large number of projects through SharePoint, it is possible to identify a unique type of content that is stored throughout all of the sites, and create Search Scopes that can return that specific type of project content.

Determine Search Goals

The next step is to interview the stakeholders including a number of the end users to determine what their expectations are as well as how they think they would approach search with the system.

Identify the Content They Search For – Try to determine the content they most frequently work with as well as the types of content they most frequently have to search for.  Typically users know where their frequently accessed content is located.  Unless there are thousands are items they may not need search for that content.  For other content, in other areas they are likely less familiar with the structure and rely on search.

Identify Search Types – Try to identify the types of searches they do (standard, or advanced with keywords), and how likely they would be to match a search against a specific search scope.

Identify Level of Patience – While it would be great if you only ever received a single search item in the result set, and it was the perfect match, that is not realistic.  Try to have the users express what their expectations are and what their true level of patience is.  While they ever look at the second page of results?  Will they quickly just do a different search?  Will they use any of the search refinements?

Identify Location of the Search – In addition, try to have them identify WHERE they initiate a search from.  To they navigate to the general area of the sites, do they try and search directly from the front page, do they navigate to different search centers depending on what they are looking for?  Depending on the results, the end users may be even be able to take advantage of the advanced configuration without training.

Develop a Search Design Plan

The next step is to develop your Search Design Plan.  It is important to review all of the different types of content along with the stakeholder’s goals and expectations to ensure that they are addressed.

Define Content Sources – Start the design by identifying all of the content sources you want to include in the index.

Identify Search Scopes – Next, try and identify Search Scopes that represent the logical boundaries for your content.  This more than anything can lead to highest level of relevancy because you are limiting the areas of the index that are being searched against.

Keywords and Best Bets – For the common search terms or critical company specific terms, it is important to try and identify the Keywords, Best Bets and Synonyms to help surface the content.

Custom Search or Result Pages – Try to identify any areas where a custom search or results page would be beneficial.  Both the search and results pages can be fully customized.  There are a number situations where simple modifications can provide a big payback.

Enterprise Search

With proper planning these features can be extended to provide a powerful Enterprise Search experience.  To make that transition the planning needs to extend beyond just your SharePoint content, but to content also stored in other systems, file shares, web sites, and email systems.  As the scope of search increases, so does the number of items in the index and therefore the amount of planning and configuration that needs to happen to deliver relevant results.

This is also where typically the topic of Federated Search comes up, since it is often valuable to provide results from other search systems, but in a separate result set instead of adding it to the local index and return it as part of the main results.

Review Search Metrics and Reports

Both MOSS and Server 2010 come equipped with Search metrics and reports that make it possible to analyze the current usage and effectiveness of search.  If you have not reviewed these before, there are bound to be some surprises both with the number of searches executed as well as what people are searching for.  The information can help you understand what people frequently search for as well as which results they are clicking through versus executing another search.  This information can be used to tune the search results for those keywords, and Best Bets can be configured for key content.  I have always relied on this information when reviewing end user needs for an existing environment.


The keys to planning for SharePoint Search include Evaluating the Content, Determining the organization’s Search Goals, Developing a Plan, and Reviewing Search Reports.  Following through on these steps will greatly increase the likelihood that the system will deliver reliable and relevant content back to the end users.  Enhancing the search experience will have tremendous payback for any organization with mission critical content in the system and can be the critical point that makes the difference between a successful and an unsuccessful enterprise information system.

SharePoint 2010 Migration versus Upgrade

No doubt there are hundreds of companies currently reviewing or planning the move to SharePoint 2010 from previous versions.  The excitement and business interest around the technology is very encouraging.  Before picking an “upgrade” path though, I would encourage teams to compare the Migration paths in addition to the normal Upgrade paths. 

Migration Path

Taking a Migration path means you are going to build a new farm or environment and then move content to it.  There are many advantages to this approach, here are some to consider. 

Restructure Information Architecture and Design – The migration path gives you the ability to learn from past mistakes or to make changes to better suit the current set of requirements.  This opportunity does not come up often, so if changes need to be made, this is a good time to enact those changes.  Changes may include restructuring the web application and site collection topology as well as Taxonomies.

Incremental Move – Since you are moving from one farm to another it does not have to be completed at all once, you have the option of breaking the content down into smaller units that can be moved one at a time.  This is especially valuable in cases where custom applications might have been built that cannot be upgraded without rework. 

Take Advantage of New Features – There are some situations where after an upgrade it may be difficult or at least require more work in order to take advantage of all of the new features.  One great example of this is the new Claims Based Authentication model.  In the past though, I have seen other issues which were traced back to compatibility issues with site definitions.  Given the fundamental changes to the Publishing features in 2010, I expect there to be issues when people take an Upgrade path. 

The Downsides – There are costs to taking this approach.  It may take more time than an in-place upgrade and it definitely takes more planning.  There may also be software costs for migration tools which can help automate a migration.

Upgrade Path

The upgrade paths may mean you are using the same hardware, or at the very least you are moving the Content Databases which keep the Applications and Site Collection topology intact.  The main advantages include:

Quicker and Easier – It should not take as much planning, nor take as long to complete. 

The Downsides – All of your existing Site Topology, Security, and general organization issues are moved to the new platform.  The system may be difficult to administer and maintain.

Choosing the Correct Path

Both paths have their pros and cons and offer unique opportunities.  The right path is the path that helps your team meet its objectives within the constraints given.  Most IT leaders push for the regular Upgrade path because it is less complicated within the scope of the short term project, but they do not have the full picture of what the opportunity cost is or what the long term impact will be.  It is implementation team’s responsibility to educate the decision makers as much as possible so that the best decision can be reached.

Related Posts

Unlocking The Potential of SharePoint With Remote Access

I have been putting a lot of work lately into some general 2010 presentations and one of the messages I’m really concentrating on is Connect anywhere, from any device, with any browser.  I think this is a critical ingredient in enabling SharePoint to be a great Unified Business Collaboration Platform.  It comes down to removing all of the unnecessary hurdles of accessing and working with the content in a secure manner.  While there are some technical changes that were made such as better support for mobile devices and true standards support allowing cross-browser consistency, the real change for me is philosophical.  Until recently I have been somewhat uncomfortable opening up internal portals and content to the internet.  My biggest fear has always been network security.  Gateways like ISA, now Forefront Threat Management Gateway (TMG), are not new but many IT groups have had difficulty implementing them or managing them effectively so I have not pushed for them in many of my implementations unless it was needed to fulfill a requirement.  With the Connect Anywhere, from any device, with any browser mantra in mind that will no longer be the case.  I will now advocate for secure access to be provided wherever possible without the requirement to connect via VPN or be on the local network.  This enhanced access will easy collaboration for remote workers and has the potential to speed up the collaboration process in addition to making it richer. 

If your organization is not sure how to implement or configure one of the gateway applications, seek out experts in the form of consultants or community members that are able to help.  You users will thank you for it!

MySite Provisioning Methods

A number of times over the past few years I have stumbled into discussions (in person or online) about how to automate the creation of MySites for all users in the organization.  Creating the sites programmatically is actually pretty simple, but the real question is “Why do you want to do that?”  There are advantages and disadvantages to automating the process, but for me it almost always comes down to two big things; Governance and Business Reason. 

MySite Governance

MySites present an interesting challenge with regards to governance.  While most of the topics are outside the scope of this article there are a few important topics that relate to the number of MySites within an organization.

Storage Considerations – Even with quotas in place it is easy to see exponential growth for the storage requirements.  In larger environments with 1,000s of users serious planning needs to take place to build out a SQL environment to support the site collections.  Planning should also be done to manage the number of sites per content database to ensure long term maintainability. 

When you provision all of the sites at once all of the planning has to be done up front, where conversely if you provision the sites slowly over time you spend a little time planning out the long term assumptions and then tweak the strategy over time as the sites and their usage evolves.  It is much easier to make corrections with the slow approach.

User Support and Training – A MySite is very different than an email account which is something nearly all computer users are familiar with at this point.  The average SharePoint user has never received any formal training and has little understanding of the capabilities of a site collection.  Without proper training it is unlikely that user will be able to take advantage of any of the real benefits of the MySite leaving them to just use it as a replacement for a personal network share (see Storage Considerations above). 

In my experience site owners or administrators for traditional collaboration or department sites are much more likely to have success and less likely to need extra support.  That narrower group of people is a much better starting point, and they are also sophisticated enough to initiate the automatic provisioning process themselves.

Business Reason

Each organization should develop a user story for what the purpose of a MySite is within their organization.  Like any site collection, it can be used for many different purposes such as; Landing Page, Dashboard, Personal Site, etc.  The user story may help establish how the MySite will be used, who is expected to use it, and ultimately if customization is needed to provide the functionality and content.  The answers to those questions should help guide the decision about how to provision the sites. 


While I tend to like the go slow and make adjustments path, there are valid reasons for needing to auto-provision sites for large groups of users.  Hopefully the guidance here will help to guide the team through proper planning so that the implementation can be successful.

Related Posts

%d bloggers like this: