Tag: Enterprise

White Paper – MS Office Compatibility with SharePoint

For those that have been involved with SharePoint for awhile the document title “Good, Better, Best” should ring some bells.  There was a document with that title published with the last few SharePoint versions that compared the various MS Office suites going back to Office 2000 and detailed how they interacted with SharePoint features.  An updated version has been published in the form of a 37 page white paper called Business Productivity at Its Best

This document is important because the hardware and software refresh cycles at most companies are much different than it is for servers.  I have worked with a few clients in the past few months that still have a significant number of users on Office 2003 for example.  When providing them SharePoint 2010 guidance the information needs to match what they can expect in their environment with the products they have.  This document will provide excellent information that may help justify accelerating the upgrade to Office 2010 or if not will help illustrate what features will not be available (ex. co-authoring).  The white paper also includes information on the mobile and offline capabilities which are also becoming much more important in deployment projects.

I highly recommend this document to anyone planning or engaged in a deployment or upgrade to SharePoint 2010. 

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

Finding the Sweet Spot with Process Improvement

Today while visiting a grocery (super-)store I witnessed a strange event in the parking lot where a couple of guys were “pushing” carts.  This is something I did in high school so it is a task I understand very well.  They had a 60’ plus train of carts along with a motorized device at the end that helped to push which is what grabbed my attention.  My assumption is that since they had the motorized device (technology innovation) they could take on more work (process efficiency).  What I witnessed was something completely different.  I watched them for well over five minutes.  In that time the train grew and grew and became very difficult to manage.  You can also imagine that a 60’ train of carts in a busy parking lot blocks quite a few cars, including my own.  From my time of pushing carts I knew what a manageable load was and that it was often more efficient to manage smaller subset of work.  In the time I watched them in this farce, the two individuals without the aid of any motorized cart should have been able to collect and return twice what they ended up collecting without unconvincing any of the customers by blocking them in.

This story is a great example of what happens when you overuse technology in an attempt to increase business efficiency.  It is important to look for the sweet spot, adding just enough value without overbuilding or you will see diminished returns. 

I’m sure everyone that has worked with workflow or Business Process Management (BPM) for any period of time will have lived through projects that went passed the sweet spot.  It is not always as clear as the shopping cart story above.  In my experience it typically comes from either trying to automate too much in a previously manual process or from trying to handle too many process exceptions.  One of my favorite things about process improvement is that it is not a one cycle process.  You go through iterations of improvement and continue to tighten up the process.  With this iterative approach it affords the team some time to automate the manual processes and helps the process mature a bit before you try and handle all of the potential exceptions. 

In one project where clearly things had been taken too far, the team had spent a pretty substantial amount of time working through all of the different types of process exceptions.  I think there were eight possible paths at one point.  After the process went live we ended up finding that a few of the paths were never followed, and a few others were followed fewer than 3% of the time.  Clearly mistakes had been made and the process was overbuilt.  Working in a few steps that were a bit more generic and only partially automated would have been a better alternative.  By planning smaller, more focused iterations you will show value quicker and make it a lot easier to plan the next improvement cycle. 

Keys to Establishing a Disaster Recovery Plan

Today I put the finishing touches on a SharePoint Disaster Recovery presentation I’ll be delivering at the Triangle SharePoint User Group meeting this week.  Part of the presentation goes into the regular technical aspects of backing up and restoring SharePoint, but the second half goes into how I approach a Disaster Recovery plan. 

Prioritize Your Content

Not all sites, nor all types of content are the same.  In environments where I have seen SharePoint been very successful, it was successful because it was used to manage or store business critical content.  When looking at any medium to large implementation, 100GB+ of content, it really pays to spend some time working with the business to prioritize the content so that a restore sequence can be established.  Getting the most critical content back online will likely buy you some time and ease the pressure while you work on the rest of the content.

When you practice your recovery, be sure to practice it based on your recovery sequence to validate that it can be executed in that order and that you are not overlooking any dependencies.

Track Customizations and Solutions

I’ve mentioned a few times in the past how important it is to keep a running list of all the customizations in place along with the actual solutions or install files.  If you have to rebuild the environment this is crucial to getting the system back in working order.  Review the list regularly and be sure to save it to separate media since keeping it on the SharePoint server may not help you much during a catastrophic failure.

Identify Multiple Recovery Paths

There are different types of failures, and the same path isn’t appropriate for each.  In addition, sometimes unknowns come up that either complicate or block the desired recovery path.  It is always a good idea to have a secondary recovery path.  When it comes to Disaster Recovery, redundancy is a very good thing.

Know Your Restore Rate

It is important to know who long it will take you to restore the systems.  Base the rate on actual tests, not on the stated rate of a given network or tape technology.  If the company has a DR agreement with a facility like Sun Guard it would be a good idea to also include both the expected rates for your home facility as well as the disaster facility.  Once the restore rate is established it can be used for ongoing planning as your contend databases grow.

It also pays to set a worst case scenario rate.  If the entire data center had to be restored or rebuilt and every tape machine is in overdrive and the network is saturated you are not going to see the same performance that you will when just recovering a single system. 

Ensure the Plan Meets the Business Objectives

All of this planning is to ensure that you can recover the system in a way that can get the business back up and running.  Be sure to get validation on the recovery plan and do not make assumptions.  If the business really does require quicker recovery times there may be justification for additional tools to help speed up the recovery process.  The cost of those tools is typically negligible when compared to the cost of business interruption.

%d bloggers like this: