Stacking Managed Paths

Most SharePoint administrators are likely familiar with the Managed Paths feature that allows certain paths to be designated to hold site collections. The “sites” entry is added by default. Not everyone knows that those paths can be stacked to provide the same functionality at different levels.

Flat versus Deep
As part of any Taxonomy plan the team should always consider the appropriate depth to the site collections. Some might argue having a flat taxonomy with lots of siblings, while others will push for a traditional hierarchy.

Using single level Manage Paths help to provide fairly flat site collection taxonomy. That would give you a top-level site, and then site collections organized one level down. In most of the systems I have worked with there are more than one entry, typically separated by a general purpose (i.e. Projects, Team Sites, Applications, ECM Sites).

In some medium complex organizations that may not be enough. Perhaps there are multiple business units, and the sites could benefit from some BU level landing pages with the site collections below that. Stacking the managed paths will provide this.

For example:

Regular managed paths: http://myserver/units/

Stacked managed paths: http://myserver/units/euro/sites/

Note: In very large organizations it is likely that these sites would be in separate web applications or even separate farms. This technique may still offer value.

Landing Pages/Sites
To establish a landing area Site Collection above each of the managed path entries you will need to define a single level managed path and create the site collection as usually. Using the example above /units would be used for the managed paths and the site collection would be setup at http://myserver/units/euro. This would serve as the landing page for European Operations. The site collections underneath would be organized in the sites path.

When establishing the managed paths, the system does not check to see if a site exists at the path you supplied. If you were to setup a site collection at http://myserver/units and then establish /units as a managed path the site would no longer be accessible.

Site Collections versus Sub-Sites
There are a number of reasons why you might choose the isolation of Site Collections versus creating sub-sites. One big reason to require Site Collections would be for Quota Management which may be needed to support a chargeback system. Since quotas are set at the site collection level you will need isolation in order to manage that effectively and provide accurate notification and reporting.

Server 2008 and User Account Control

Recently while working with a Windows Server 2008 I found myself unable to run any STSADM commands. No matter who I was logged in as I kept receiving an “Access Denied” error which seemed awfully strange.

I proceeded to search the web for this issue and I found multiple sources identifying the issue as part of the User Account Control functionality. All of those sources recommended disabling the feature, which requires a reboot. The feature has value so I wasn’t too keen on disabling it, and having to reboot a production system during business hours is never fun. I proceeded with disabling the feature, but decided to follow up with it afterward.

I have since learned that getting past this block is quite easy. It simply requires that the user right click on the Cmd prompt and select “Run as administrator” in order to have the command complete.

MS Support has published a good overview explaining the User Account Control feature: http://support.microsoft.com/kb/922708

Hope this helps fellow administrators bringing up systems on Server 2008.

Search versus Information Architecture

At a recent Triangle SP User Group meeting an interesting debate broke out regarding the use of search to find information inside of a SharePoint system. One person went as far as to say that “search is a last resort” while another said “if a user has to search, you have failed.” Those are some pretty strong positions to say the least. I believe that Information Architecture and Taxonomy are incredibly important, but Search is as well and should not be a last resort. If proper planning is not done in both areas people are going to have trouble finding what they are looking for.

Preferred Method Depends on Context
First I think this debate requires context since the type and the amount of content to look through can range dramatically. Browsing a Wiki with 20 pages is not the same as browsing a Document Library filled with 100,000 invoices. For the former it would seem crazy to need to rely on search, but with the latter it is absolutely essential to most end users.

Users Think Differently
I have had the chance to do usability studies for large SharePoint implementations in a few organizations now. Early on I was amazed at some of the feedback I received with regards to organization and taxonomy. All users do not process thoughts the same way, so while you can work hard to cover all your bases some will still be left out. Put as much time into planning the Taxonomy as possible, and review it on a regular basis as the content and purpose evolves.

Search Needs Tuning
The search service with MOSS can be pretty powerful, but it isn’t something you just turn on and expect targeted search results to be delivered. Time should be spent planning the search system to take advantage of its powerful features including authoritative levels, keywords, best bets, scopes, etc.

As part of this planning effort you should try to identify which sections or sites could most benefit from custom search interaction. If the nature of the data is such that searching is likely to be needed, configure tools to make it as easy as possible to pull that specific set of data. In Mike Gannotti’s presentation, one of the things he suggested was creating a sub-site for each feature or type of list. The advantage of this is that when users search at the “This Site” scope, only data from that level will be returned. With the exception of Wiki configuration, this is not something I have typically done.

Learned Behavior – Browsing versus Searching
After the meeting I reflected on the topic quite a bit, and then a day or two later something occurred to me while working on my Vista machine. When I sent to go open a program I found myself using the desktop search feature to find the programs that were not pinned to the Start Menu. In the past, on previous computers, I had spent an insane amount of time building a system to help organize my program menu. Since I had too many things installed and the menu would wrap, I created a taxonomy with high level categories that led to the program folders (i.e. Dev Tools, Sys Tools, Office). Everyone agrees that browsing to something when you know its exact location is very quick. However, it is quicker still to type in a name and then double click the result returned. Reaching the Event Viewer for example has never been so easy. Without realizing it, my behavior in this OS has changed. While I am not a typical end-user, I believe that I am not unique in being able to adapt to new ways of finding information.

End User Ownership and Evolving Content
Some of the biggest Information Architecture challenges I have seen come from the fact that in most organizations many of the site collections are owned and managed by business units. You can try to educate them on proper planning and maintenance, but in most cases it is far from their top priority even as people complain about usability.

In many cases the purpose of the system changes leaving it out of sync with the taxonomy or navigation design. This is a sure fire thing that pushes users to rely on search.

Best Way Forward
I think the best way to tackle all of these challenges starts with proper planning and site owner education up front followed by periodic reviews of existing sites after the fact. If you can schedule reviews either quarterly or semi-annually as part of the overall service offering it will help you limit some of the issues of End user Ownership and Evolving Content. By keeping the system tuned, users will be more productive, and therefore more interested in using the system which increases end user buy in.

Where Do You Stand?
Where do you stand on the debate? Do you have anything to contribute to the discussion? Is Search a last resort? Is developing a maintainable taxonomy even possible?

Launch of the New Triangle SP User Group

The Triangle SharePoint User Group was recently relaunched with a new website and a monthly meeting schedule. The group will meet the first Tuesday of every month.

The first meeting featured a fantastic presentation by Mike Gannotti on Implementing Knowledge Portals in the Enterprise which offered great insight into his experiences delivering simple solutions that can deliver high value to the organization.

If you are in the area I would encourage you to watch the event calendar and attend any meetings you can.

If you are interested in presenting contact Josh Carlisle or Michael Lotter for schedule availability.

Enterprise Communication Paths

The communication options and paths within the enterprise has changed dramatically over the last 15-20 years.  More recently though there are some new options on the scene including Micro Blogging tools like Twitter and Yammer.  I think it is a good time to evaluate how your organization communicates in order to better enable them to meet business objectives and enhance collaboration.

Email

Email used to be great, but now it tends to frustrate me.  My guess is probably 80% of the messages I receive have no long term value.  I am a bit of a packrat and have a hard time determining what to keep and what to delete.  The time spent organizing, deleting, or archiving those messages is not a value added activity.  On top of that many organizations strictly limit mailbox size and many of those sizes are decreasing despite the Google Mail’s of the world offering increased storage space.  Storage and backup times are one reason, but with others there are Records Management implications involving compliance and legal discovery.

    Pros

  • Everyone is comfortable with and understands email
  • You do not need to know or care if the person is currently online, in the office, or on vacation
  • Easy to save and flag for further action if needed
  • Many software applications can send notifications and alerts via email

    Cons

  • High percentage of the emails have no long term value and have a short shelf life
  • Require effort for quota management and organization
  • Overhead to store, maintain, and backup messages centrally

Instant Messaging

Shortly after email use started Instant Messaging came along to distract people.  In the early days people mostly did this for personal conversations so it was looked at negatively by many organizations.  Slowly but surely it is getting a second look within the enterprise as major enterprise vendors have started to push their Enterprise Messaging wares.  I believe strongly that it does have a place within the Enterprise, but it is not the only tool or solution.

    Pros

  • Most people are comfortable with and understand IM
  • You know before sending the message if the person is online, and most provide some additional status indicators
  • Some IM tools support discussions between multiple people at once for ad-hoc group chats
  • Lowers the load on the email system and storage
  • Requires little to no message maintenance

    Cons

  • Company policy may be against it’s use
  • Adoption is not widespread in most organizations
  • It is another client based application the organization would have to support
  • Not all IM programs can interact, so program selection is important
  • Some of the internally hosted Enterprise tools do not work so well for distributed users or field users

Micro-Blogging

Micro-Blogging is a form of communication involving brief text based messages.  What started as a personal, consumer based, social activity, now has implications to the organization.  Tools like Twitter or Yammer fall into this category.  Most organizations are still struggling to understand what it is and how it can fit into the communication paths, but I think it offers a real opportunity to revolutionize Enterprise communication.

    Pros

  • Dynamic and able to adapt to the social fabric of an organization
  • Messages are brief
  • Reduce the clutter and storage needs of the email system
  • Messages have a short shelf life
  • People can tune in or tune out, supporting a Pull model instead of a traditional Push messaging model
  • Can lead to better collaboration and interaction within teams
  • Can lead to new connections and collaborations between teams with commonalities

    Cons

  • Not well understood by most organizations
  • Not well understood by many users
  • Most applications and networks are currently external, which may not be able to handle secure internal communication

Communication Soup

Technology leaders need to work with their business units to help figure out which tools to use, and for which purpose.  Without business buy-in and high enough adoption rates to reach critical mass people will slip back into the traditional way of doing things.

A good place to start is to do some analysis to figure out why types of communications are being currently taking place.

General Activity Info, location info to group
One on One Conversation when Online
One on One Conversations when offline
System Status Notifications
Exchange with external contacts
Exchange with attachments or RM needs
Group conversation when Online
Workflow notifications
Task Notifications

Then Take a look at what might be the best tool or communication path for that specific type of communication.

For example, system alerts and task notifications are currently sent via email.  I think it would be more convenient to have those sent to the MB message stream. 

Sending most messages to your team could also benefit from the MB path.  If you are seeking real-time collaboration between multiple people then email is inefficient and IM isn’t as flexible.

Fifteen years ago I never would have predicted that online communication and transactions would have replaced the postal system so quickly.  I feel confident in saying that in ten years from now email will not be the primary written communication path for either personal or business communications.  The sooner your organization starts the transition, the better prepared they will be to capitalize on it and use it as a competitive advantage.

%d bloggers like this: