Tag: Planning

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.

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. 


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

SharePoint Dev and Customization Paths

Microsoft’s technology stack has traditionally offered a lot of good options leaving the developer or architects to choose the best path.  Even still there there have been people camping out on one side or the other.  In the early days when VB first came out the hardcore devs didn’t take it seriously, and I remember hearing a lot of negative comments from traditional C++ developers.  VB devs didn’t have to understand concepts like threading and memory allocation and the VB code was bloated leading to “poor performance.”  While those statements are true, not every deliverable has the same grade requirements and in many cases businesses were more than happy with the code that was delivered faster and for less money than what C++ developers could provide.  I think this is a very good analogy to the current SharePoint development and customization paths.  Microsoft has worked hard to position SharePoint as a tool that can be leveraged and customized by power users as well as developers.  I think this is both a strength and a weakness; a strength because there are options, but a weakness because many of the people doing the work do not understand the implications of their decisions.

Understand the Scope of the Solution

The first thing I think about when I get a request is the scope of the solution.  I think through the questions below and choose a direction that makes sense in order to meet the requirements in a cost effective manner. 

Who is the audience? – The larger the scope of the audience, the more robust the solution should be.  A solution created for a work group is probably very different than one used enterprise wide.

How many users will need to use it? – Similar to the previous question, but a little more concrete.  Do you expect 10 concurrent users, 100 or 1000?  Company or enterprise wide means different things in different environments.

Where will the solution be used? – Deploying the solution on a single Project or Team Site is very different than deploying it to 100 sites, which is very different than deploying to the front page of a company’s Intranet.  If it is for a single use the Light Dev and Customization path can make sense.  If it is meant to be reusable, then it warrants more time and attention to make sure that it is the best it can be.  If it is use on a top level or heavily used page or site then performance is even more critical meaning a more robust solution should be developed.

How long is it expected to be in use? – Try to have some understanding of how long the solution is intended to live.  Assumptions may change, but make an informed decision based on the information you have at the time.  If a newly acquired third party tool will be providing that functionality in the next 10-12 months there is no need to overbuild the solution.  Likewise, don’t take short cuts on a critical project that can undermine peoples’ understanding of the capabilities of the platform.

Who will maintain the solution? – This is a tricky one.  Not every company has a large staff of qualified developers waiting in the wings.  There is normally a large backlog of work waiting for them.  If you are a consultant then you might look at whether you are handing over the support to the internal team or if your group will continue to maintain it.  The group isn’t capable of maintaining a solution and doesn’t have the tools and environment in place to do the work then full scale development may be a bad idea.

Are there performance requirements? – If there are performance requirements then those should be planned for from the start.  Stats like page load times, and an agreement on what constitutes the end of a page load are important.  In most cases I have not seen this requirement.

Light Development and Customization

Light development and customization includes features and solutions dealing with SharePoint Designer, DataViews, Content Query Web Part and the Content Editor Web. 

More than anything I see this being for the benefit of Power Users and site owners who can apply customizations within the scope of a site collection.  While there are many that want to outlaw SharePoint Designer and these solutions in their environment, I think they risk eroding the value and impact of their SharePoint platform.  I see SharePoint as a tool that enables content/site owners without needing to rely on a central IT group.

I tend focus on this part of the stack when dealing with solutions targeted to small teams or with small requests that do not need a full blown application.  There are definitely lots of opportunities for simple, high impact, one off solutions. 

This however is probably not the appropriate set of tools for org wide workflows, complicated forms, or even displays on heavily trafficked pages.  The Content Query Web Part (CQWP) for example is not the most efficient way to aggregate content so pulling something like project status information from 50+ project sub-sites is likely to end in frustration.

Robust Development

Robust development includes features and solutions dealing with Visual Studio built applications packaged and deployed via the solution framework in SharePoint. 

This really should be the starting point when reviewing any project of real significance.  The developer has a lot more flexibility and control in what can be implemented and it is much easier to centrally track and manage what is deployed to the server. 

I think that it is important to note that poorly developed VS solutions are at least as dangerous as anything that can be done using the Light Development and Customization technologies and techniques.  Failing to dispose of objects or inappropriate CAML queries can bring down a server or cause all kinds of havoc.

Mixing Approaches

There will be times when it is necessary to blend the two approaches.  Within a given project there are features that are core to the solution and some that are in more of a supporting role.  Admin or reporting features are a good example of that, where using a DataView may be easier to maintain than a custom Web Part to display content.

The Business Does Not Always Understand

Customers, project stakeholders, and other decision makers do not always know what is best.  I’ve seen many cases where even sophisticated development shops do not fully understand SharePoint development paths and fully leave the decision up to the developer.  Like any project using any technology, risks should be identified and discussed before things get too far.  It is irresponsible to deliver a solution that you know cannot be supported or maintained after you sneak out the back door at the end of the engagement. 

Administrator’s Perspective

From an administration perspective, I do not want to manage more solutions than I need to.  There is a balance between wanting to know what is deployed to the environment and wanting to touch everything that is installed.  If there is a fairly ridged change control process in place it can be time consuming to submit and deploy minor updates to small, narrowly scoped solutions.  Again, my approach comes back to the scope of the solution preferring to focus on widely scoped, high impact solutions.

Related Posts

The SharePoint in the Cloud – SharePoint as a Service

The cloud debate continues to rage in the offices of many business and IT executives.  They look for it as a way to control or reduce costs and to better focus on their core business functions instead of managing complex IT systems.  As a technologist though I see the cost benefit not just in dollars but in opportunity and the potential for the system to enable the organization to innovate and collaborate in ways they were not able to in the past.

I see plenty of value in SaaS for commodity systems, with email being a great example of that.  Email systems both large and small can be expensive to run and there can be very little difference in the service if it is run in house or in the cloud.  Is SharePoint a commodity system though?  Certainly some organizations are doing their best to not customize it.  Last year’s AIIM survey results reported many organizations underestimating the cost and effort to customization and integration which I’m sure will scare executives of any new implementations.  As a developer and integrator I have seen tremendous valued gained from implementations that are extended to work with other enterprise tools whether it is an ERP, HRIS, CRM, ECM or 3rd party BPM/Workflow systems.  The level of effort to implement and maintain those environments does need to be included in the decision process.  The cost is significantly higher than a vanilla SharePoint implementation so the value derived should also be measurably higher. 

If it is a plain vanilla environment then it is a great candidate for SaaS including MS Online.  The new “Sandbox” feature of SharePoint 2010 may help to provide a mechanism for minor customizations and an “App Store” that could benefit users of a hosted SharePoint environment.  This should definitely simplify the process for making some customizations possible. 

It will be interesting to see how the SaaS and hosted solutions evolve over the next few years and how they are perceived by organizations.  It will also be interesting to see if the Sandbox feature is made available to those services and what kinds of solutions are made available through that interface.

%d bloggers like this: