Tag: Implementation

Site Topology Planning and Taxonomies

In the previous article SharePoint Site Topology Planning I discussed some of the technical implications of organizing the the sites within one or more applications, site collections, and sub-sites.  The article started to get pretty long so I decided to save the taxonomy part of the discussion for a separate article.

Organizing Sites

In the previous article I addressed different types of content and using that to help segment the sites across applications and site collections.  Within a given application it is possible to provide some meaningful segmentation by configuring managed paths. 

For example, you may segment collaboration sites with the following url structure:

  • http://collaborate.company.com – Collaboration Application
    • /Communities – Communities of Practice Managed Path
      • /Proposals – Proposal Community of Practice Site Collection
      • /Procurement -  Procurement Community of Practice Site Collection
    • /Projects – Projects Managed Path
      • /Alpha – Alpha Project Site Collection
      • /Omega – Omega Project Site Collection

Organizational Hierarchies

Most people understand hierarchies, and most businesses (at least in the west) have been organized in hierarchies for many years.  It is natural for people to think of their organization in this manner, but this may not be the best way to plan for the topology of your sites.

Traditional Intranets tend to go from the largest organizational unit down to the smallest.  There may be multiple divisions, with multiple business units, with multiple departments, with multiple teams, with people that actually do the work.  Sites or portals that go 5 or more levels deep can become very difficult to manage and even harder to use.  Modern businesses need to remain agile with teams always being redefined, combined and split up.  In  most situations it is a good idea to fight the hierarchy tendencies and strive for a flatter structure. 

From a SharePoint perspective a flatter structure with more site collections will make it easier to reorganize sites and structure versus a single site collection with 5+ sub-site layers deep.  As previously discussed Site Collections can be backed up and restored with a high level of fidelity (completeness) compared to a sub-site’s export and import options.  The key to usability and manageability is to find the right amount of segmentation and site collection structure.

Finding Sites and Content in a Flat World

An alternative to a rigid hierarchy is adopting flexible taxonomies with tagging.  Tagging provides a flexible and dynamic method of describing the content and sites that can evolve over time.  A great example of this is a site like StackOverflow compared with the rigid structure of the MSDN/TechNet Forums. The flat structure decreases the chance of duplication and provides new opportunities to view the data in new and unique ways. 

The SharePoint 2010 system full supports tagging without the need for custom or third party add-on components.  I fully expect that these will be a popular feature within the new version. 

Summary

Following the guidance between the two articles you should be able to properly plan your site topology.  Assumptions and business decisions do change, but if you establish the right level of granularity with applications and site collections you will be able to migrate and relocate things as needed.

Related Posts

SharePoint Site Topology Planning

This is the next in a series of articles addressing core SharePoint implementation topics.  I hope that this is valuable to both groups looking to implement SharePoint for the first time as well as groups planning planning for an upgrade or migration to SharePoint 2010.

A Series of Containers

I tend to think about SharePoint from a container perspective.  Each of the containers has a set of settings and features that can be configured and administered for all of the containers within.  It is important to understand the boundaries of each level so that you can create a site topology that meets all of your objectives.  I’ll cover a sub-set of these I typically consider while planning the site topology.  The containers I’m going to address include:

Farm – In the context of this article, all of the Applications, Site Collections, and Sites hosted by one or more connected SharePoint servers.  I say “connected” because it is possible, and fairly likely that most organizations will have more than one Farm (Dev, Staging, Production for things like Intranet, Extranet, Internet, etc).  A farm has one or more content Applications plus additional applications for things like Central Administration.

Application – An application would be the top level address which maps to an application in IIS.  For example http://sharepoint.  An application has one or more Site Collections.  The application level is also the level where you have the opportunity to identify one or more content databases for storing the content on the SQL server.

Site Collection – A site collection has one or more Sites also referred to as Webs or Sub-Sites.

Sub-Sites or Webs – This is the smallest container which resides under and can be managed by the Site Collection.

Types of Content

The first step is identify what types of content or site(s) you expect to host.

  • Internet
  • Extranet
  • Intranet
  • MySites
  • Company or Divisional Portal(s)
  • Web Content Management (Publishing)
  • Electronic Content Management (Document Management)
  • Business Intelligence
  • Project Management
  • Team Collaboration
  • Application Hosting

Not all of those types of content apply to every organization, but it should be pretty clear that the content, the update frequency and the manner in which it is used and managed can vary quite a bit from type to type. 

Considerations of Multiple Applications

Very small companies or workgroups may be able to get by with all of the types of content hosted in a single Application, but for anything larger there should be plans to segment it to multiple Applications in the farm.

Here are some considerations when using multiple Applications:

Authentication Model – What type of authorization model will be used?  Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA).  Since an Application can only support a single authorization mode, that can dictate additional applications.

Edit:    Anders Rask was kind enough to point out some changes to the authorization model in 2010 that make the previous statements incorrect.

In 2007:  Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA).  Since an Application can only support a single authorization mode, that can dictate additional applications.

In 2010: There are two high level options; Classic which supports Windows Authentication only and Claims Based which supports one or more different providers.  Additional information can be found on TechNet’s article Plan Authentication Methods.

Sessions – When a user visits an application a session is created.  It is important to understand that their session is for a specific IIS Application so if they visit the main company portal and then click to see the MySite they may be asked to authenticate again.  With Anonymous this should not be an issue.  With Windows Integrated this should not be an issue if 1) users are using Internet Explorer 2) they access the site(s) with the same account they use to access their computer and 3) their browser is properly configured to pass logged on user information. 

Application Scoped Solutions – Solutions can be scoped to specific Applications which can provide some flexibility in deploying new features.  In a large environment it is important to only show features to the areas where they apply.

Considerations for Site Collections

The site collection has some important boundaries to consider when deciding to use one versus multiple site collections.  They include:

Amount of Data – It is important to keep your site collections at a maintainable level.  There is no hard limit, but as Site Collections grow over 40GB they can get more difficult to maintain and will take longer to restore.  SQL Server tuning becomes more critical with larger databases.  It is a good idea to segment your content across multiple site collections (and across multiple content databases) in a manner that makes sense.

SharePoint Groups – SharePoint Groups can be a good way to organize users, especially when they do not map to functional areas or groups otherwise managed in Active Directory.  These groups are defined and contained within a given Site Collection which means if you want to use them in multiple site collections they have to be duplicated and maintained separately which can be problematic.

Site Collection Administrator – A site collection administrator has great power and control within the site collection container.  A Site Collection administrator can choose themes, manage all security within the site collection, manage activated solutions and potentially deploy other customizations if policy permits.  Enabling content owners should be a top priority, and the Site Collection provides a good container for that.

Quota Management – Quotas are set at the Site Collection level so if granular quota management is required for billing or charge back purposes it may have some impact on how site collections are segmented. 

Navigation – The default SharePoint navigation provider does not span site collections (and therefore applications) which can make a standardized or unified navigation scheme difficult to maintain.  This tends to work fine for team collaboration sites, but can be cumbersome when you need to link many site collections.

Content Types – I think Content Types were one of the most important changes introduced with WSS 3.0 and MOSS.  An entire overview of content types is outside the scope of this article, but keep in mind that within the current release Content Types are created and maintained within a Site Collection.  If a Content Type applies to multiple site collections then it needs to be duplicated.  SharePoint 2010 will support farm level content types which will remove the need to duplicate them.

Profiles (WSS Only) – If you are using WSS it is important to understand that the profiles are stored at the Site Collection level.  If you add custom attributes they will need to be added to all site collections they apply to.

Implications on Backup and Recovery

There are a few different methods to backup and recover SharePoint content.  Within the context of this article it is important to understand the difference between the commands that stsadm provides. 

Site Collection Backup and Restore – Considering the boundaries previously discussed, there is a lot of extra content stored in the top level site of a site collection.  Doing an stsadm backup will provide a high fidelity snapshot of the content, configuration, workflows, and other customizations.  It is important to note that if you are moving the site collection between applications or farms that you will need to install any solutions or dependencies referenced in the current location.

Sub-Site or Web Export and Import – The Export process offered for Sub-Sites is great for archiving, but it does not provide the fidelity needed to move sites around.  It will not save workflow, features, solutions or alerts.  I’ve also had inconsistent results with DataViews on sites being migrated in this manner.

If you think you will need to migrate the content or want flexibility, it would be in your best interest to consider using more Site Collections rather than deeply nested Sub-Sites.

Upgrade and Migration Considerations

The purpose and content within a site collection or site can evolve over time.  Some sites that started very narrow in purpose may change and now warrant their own Site Collection or Application.  When preparing for a migration or upgrade it is a good time to run through this exercise again to validate the assumptions and decisions that were previously made or overlooked.  While it may make the move more difficult the changes will pay dividends over the coming years offering a system better tuned to the user’s needs and more maintainable by the site owners and farm administrators.

Related Posts

Overcoming Obstacles in SharePoint and Ent 2.0

One of my favorite general IT blogs is Michael Krigsman’s IT Project Failures blog.  Michael provides a balanced view with great insights into the failures of many organizations.  These are lessons that every implementer, integrator, or system stakeholder should pay attention to.

In a recent post titled Resistance to change:  The real Enterprise 2.0 barrier Michael discusses some of the challenges to implementing Ent 2.0 systems.  As always it is a great and relevant read, but I think it matches much of my experience with implementing SharePoint in the Enterprise.  The top obstacle listed was Resistance to change.  The capabilities of the tools are not the biggest limiting factor, user adoption is.  Some of the reasons discussed include fear of change, the power of information holders and lack of interest.

Fear of Change – This is a natural human response.  Much has been written about how to drive change in an organization, but I think the most critical technique is end user involvement.  When people are involved they are much more likely to have a positive view of the change and you are more likely to value insight into how things are actually done in practice. 

This also provides a good opportunity to fine tune your feedback collection techniques so that all stakeholders continue to have a voice after go live. 

Information Power – In some organizations there is a culture in place where people feel like they have to be a gateway to information.  With the recent economical downturn people are all the more desperate to be seen as irreplaceable.  Organizations need to work towards transparency and openness.  A positive side effect of this is better use of the subject matter or domain experts who are normally over worked in closed organizations and frequently have to answer the same questions repeatedly.

Lack of interest – Lack of interest can definitely have an impact on the life of a system.  Some users still do not understand or have any interest in Ent 2.0 systems.  I think easiest way to get passed this is to show sustained value.  It is easy to establish and maintain interest with small groups, but it gets exponentially harder as the size of the group increases.  Keep the tools current, and show incremental advances to keep stakeholder interest.

I’ve also seen turnover in key positions or management impact a groups use of these tools.  It is important to work with the new stakeholders to review what is there and what can be done to align it with any changes to the group’s direction.

Closing

I’m always interested in hearing feedback.  Do you agree, disagree?  Have any other tips to decrease the resistance to change?

Related Posts

Site Requests, Provisioning, and Governance

Yesterday I posted a link to Michael Sampson’s survey on Site Creation Rights which is intended to collect information on the process and governance around who can request new sites and how they are provisioned or “actioned.”  This is an important topic, so I’m looking forward to seeing the results.

This is a topic I have had to put a lot of thought around recently in my current organization.  Like all things Governance, there is no one-size-fits-all solution.  Instead there are topics that needs to be discussed in the context of the organization to determine an appropriate path.

 

Some items to consider:

Who can create a site; Anyone, Project Manager, Manager and above?

True collaboration doesn’t always happen based on a mandate from above.  Whenever possible, it is good to encourage and accommodate requests from anyone that will use the service.  Some of the most innovative sites I’ve seen were lead directly by information workers sometimes even without the knowledge of their supervisors.  If there is a charge to the site, this may not be possible.

Does a site request require approval?

Does a site request require approval from a manager of the requestor’s group or from IS/IT?  If so is it for financial reasons, or does the scope and purpose of the site need to be validated?

What types of sites can be created?

Are there only certain types of sites supported like Division, Department / Functional Area or Project?  What if somebody wants to setup a site to organize the Bowling League or discuss Social Media’s place in the organization?

Where are the sites placed and how are they organized?

Are all sites placed into the generic “Sites” path or are they logically grouped in containers that represent the org structure or purpose?  This can definitely have an impact on the process if sites are automatically provisioned. 

If they are logically organized, you need to make sure you have a plan on how to move the sites and content if the purpose of the site or the organization changes.  These sites need to be dynamic and adapt to change.

Does the site need to be logged somewhere like a Site Directory?

If one or more Site Directories are used, the provisioning process should include steps to list the new sites. 

Does anyone need to review the site’s Design, Structure or Security?

This question is pretty central to the Governance process.  If you establish standards or guidelines you want to ensure people follow them, but it is also a good idea to have some form of a review available so that advice and best practices can be exchanged to help maximize the value the group derives from the site and system.

The scope of this review can run the gamut, I’ll save that as a topic for another day.  I will however say that it is important to the overall success of the platform unless the capabilities and understanding of the site owners/administrators are very high.

 

Site Requests and Provisioning in the Small Organization

In small organizations it is pretty easy to handle things manually.  Site provisioning really doesn’t take that long so it is easy to help the site owners/administrators along and get things organized correctly so that it meets the group’s information architecture objectives and is easy to use.

If the process is automated in a small organization it is likely to be a pretty simple process.

Site Requests and Provisioning in a Large Organization

In larger organizations it quickly becomes apparent that manual processes cannot scale and at least portions of the process need to be automated.  Depending on some of the topics above relating to charges, approvals, and topology the process can vary quite a bit from organization to organization. 

If the Governance model is properly though through it should be easy for people to request sites, and they should be provisioned in a way that offers additional value. 

 

End Notes

Thoughts, feedback, critiques?  I’m always eager to hear other people’s thoughts on this topic and eagerly await the results of the survey.

Supporting Multiple Active Directory Domains

In many environments there is more than one Active Directory forest with users that need access to the SharePoint farm. Setting up support for users on multiple domains is pretty easy and can provide new collaborative features for users throughout the extended organization.

Trust Relationship
The only prerequisite is that there has to be a trust relationship between the forests. Users from the other domain(s) will need to be able to authenticate and access resources on the host domain.

If that trust is not in place, here is a good resource: Support for Cross-forest deployments

Setting up the Import
The Profile import settings are in the Shared Service Provider’s User Profile section. Setting up the primary domain, the domain the server is on, is pretty straight forward and the default settings should be fine.

To setup an import for additional domains click on the “View import connections” link from the main User Profiles and Properties page followed by the Add Connection item in the toolbar. Fill in the domain information and click the Auto Fill Root Search Base button. If the SharePoint Administration account does not have access to read from the target domain you will need to supply an account to read the directory.

People Picker Control
If there is a one way trust, or there are duplicate accounts (display names) on different domains it may be a good idea to set some additional properties. In the article Select user from multiple forest domains it provides a path to specify which forests to search, and allows the passing of credentials if the SharePoint Administration account does not have the required privileges.

Summary
The platform does a good job of supporting cross domain collaboration, and it is a lot easier to setup than many enterprise systems. In one environment I had to support over thirty domains so the information included above really came in handy.

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.

Managing SharePoint Solutions and Extensions

One of the great things about SharePoint today is the incredible traction that the platform has gained. The depth and range of solutions now offered by vendors along with open source solutions offered by the community really is amazing. It was a different place when I first installed SharePoint Portal Server 2001 back in early 2002.

Browsing the CodePlex I often feel like a kid in a candy store. So many great solutions, I cannot wait to install them all! Well not so fast, it might be a good idea to take a step back and consider the consequences.

Deciding What to Install
One key to maintaining a well run environment is to have a process in place to review, approve, and manage customizations. This should be part of your formal governance plan, but if you do not have one do not let that stop you from looking at this particular topic and working out some plans.

Special care should be given to non-commercial solutions. They should always be tested in a non-production environment before being deployed to your production environment. When downloading community code, be sure to take notice of who is contributing it and what the official release is. CodePlex for example does a great job of showing build info and release notes. If an item is marked as Alpha or Beta it probably has not been put through rigorous testing yet. If you want to use it then make sure you are comfortable with the risks and test it in your environment.

Testing Environment
Your test environment should be as similar to your production environment as possible. You do not necessarily have to put it on the same quality of hardware, but the configuration should be similar. It is critical that the patch levels are the same. On this note, you should be testing any KB Patches, MS Cumulative Updates, or Service Packs anyway.

Make sure that the test environment also includes the full catalog of Solutions, Web Parts, and other customizations. This is important because it is possible that one might conflict with another. Unit Testing is not enough, you will want to see how it will react and interact with your environment.

Potential Problems or Conflicts
Depending on what functionality the solution provides, the problems or conflicts can range quite a bit. Knowing what is installed is a good start.

While there is a chance that something could break independently, most of the issues I have seen came from trying to migrate, patch, or upgrade a site.

Site Migration – When migrating a site from one environment to another, it can be a pain to find out half way through that you need to install additional site templates or web parts on the target server.

Patch – When completing the installation of a Patch, Cumulative Update, or Service Pack you normally have to finish the upgrade by running either the Configuration Wizard or the PSConfig command line app. This can be a pretty stressful exercise, and no fun comes from seeing it fail along the way. I have had customizations cause problems here, particularly when changes were made directly to the web.config file as some solutions require. Having your documentation on hand will help you get through the mess and cut down on the time it takes to complete the upgrade.

Future Versions – You also need to consider the likelihood that the solution will be maintained going forward. When I made the jump from WSS 2.0 and SPS 2003 to the current version WSS 3.0 and MOSS many of the solutions I had been using did not make the jump. Some of it was because of the code base changing from .NET version 1.1 to 2.0 and some of it was because Microsoft added parts of the functionality to the platform so vendor no longer wanted to support the products. End users are not necessarily going to care why they do what they used to do, they will only care that they cannot do it. Mitigate the risk by communicating to the stakeholders the potential problems.

It has already been noted that Service Pack 2 will include an upgrade readiness check to help identify any potential problems upgrade to the next version. I would recommend taking the time to go through this check after SP2 is installed, and then checking it again after you install any new solutions before making the jump to the new release.

Summary
By putting together a plan to review, test, and approve add-on solutions you will decrease the likelihood of problems in your environment and decrease the time it will take to respond to issues when they do come up.

%d bloggers like this: