This project is read-only.

Organize your SharePoint 2010 Team Sites and improve putability and hence findability by centrally controlling how content is automatically tagged (incl. SiteCollection provisioning tool)

Chances are you found this project because you are about to change from a SharePoint environment with just a few site collections to one with many; and that for good reason.

  • IT Governance: Business requires you to be able to restore a site collection within reasonable time i.e. your site collection should not be any larger than 100 GB
  • Scalability: So far you used a single, meaningful managed path e.g. "/marketing/" so you ended up with one site collection per department and now you're looking in a more scalable approach e.g. because the number of sites within a site collection is rapidly growing
  • Security: Too many SharePoint groups were created and the day somebody will make an error and allow the wrong people to see the wrong content is not far away anymore e.g. for each of the 400 sites in the site collection you've created three SharePoints (Owner, Member, Visitor), adding up to 1.200 groups right no
  • Navigation: The current solution you offer your end users to quickly switch between all the (team and project) sites they are subscribed to needs urgent improvement e.g. users don't appreciate the long list of favorites they saved in Internet Explorer, especially since naming conventions between sites seem to differ, which adds to the confusion
If you're impatient and want to skip immediately to a more detailed product description then have a look at the user manual.
A solution can be found when we start approaching the whole thing top-down instead of bottom-up. The latter approach often leads to a "fewer site collections / many sites" environment that sooner or later will run into a brick wall. That it will run into a brick wall is not a risk as chances of it happening are 100%. Users will start using SharePoint and hence data volume will grow and hence SharePoint's site collection capacity limits ( are never far away. It's bottom up because it looks at the problem of allocating SharePoint sites to end-users from an IT perspective. The top-down approach would be to try and be as flexible as possible and simply offer each (project) team its own site collection whilst making sure its name nor its location is in anyway meaningful e.g. "/sites/0001" instead of "/marketing/print-media-team/project-site-2012/meeting-workspace". For all that information can be "stamped" onto the content using metadata.
The power of metadata has been recognized over and over again. Often in combination with the increased findability of your (enterprise) content but on other occasions also with record management, compliance and information life cycle management. Whilst some metadata is auto-generated and managed by SharePoint, some isn't. If you think of metdata like "Author: John Doe" or "Last modified date: 01.01.2011" then it's obvious that SharePoint can manage such fields without your help. But other metadata probably has to be applied manually to content by people the moment they save it.

The challenge of the "AS-IS" situation today as described in the preceding paragraph is in the eight-letter word manually. An interesting observation is that people tend to have no problem whatsoever with searching for the right location to save a piece content. However, such a location, often being a deeply nested folder on a shared network drive, comes with a number of challenges:

  • There is the the risk it's not found by others
  • It's one-dimensional i.e. "Product ABC" or "Project XYZ" but sometimes it's about "Product ABC" in the context of "Project XYZ"
  • Its structure is often very local to a department, project, team etc. instead of centrally managed

The solution for this challenge most probably is a composite one. Some metadata probably is very team specific and can be managed at that level. For example by using SharePoint's location based metadata settings for folders in a document library. However, other metadata is considered to be relevant for all and may be distributed in the form of content types by SharePoint's content type hub. Still, this solution is yet not 100% waterproof and neither is it satisfying. Clearly with collaborative sites you need an approach where you combine the act of provisioning a new SharePoint site or site collection with "enforcing" a minimal set of metadata. But automated inheritance of SharePoint's managed metadata from a site collection to a site to library or list down to list items isn't possible out of the box. Finally, with the Location-based Auto-tagging Extension for SharePoint 2010 you can now do exactly just that. Let's briefly sum up the most important and tangible benefits of the Location-based Auto-Tagging extension for SharePoint 2010: Location-based

  • Users rather save a document in a meaningful location than tag it properly using a centrally managed taxonomy. Now with the Location-based Auto-tagging Extension for SharePoint 2010 you can take (part of) that burden off your users shoulders. You can ensure that (part of) your company's centrally managed taxonomy is automatically passed on to site collections, sites and libraries and lists as soon as they're being provisioned. So if you create a site collection for Project XYZ you can now rest assured that all content items in that site collection are being tagged as "Project: Project XYZ". And if "Project XYZ" is executed as a project for Customer ABC you add additional location-based metadata fields e.g. "Customer: ABC" and "Project Type: Customer Project".


  • Auto-tagging means that the Location-based Auto-tagging Extension for SharePoint 2010 automatically adds pre-defined metadata i.e. SharePoint Taxonomy Fields with pre-set values to your content items. Properly tagged content can now be found much easier as you can leverage existing SharePoint 2010 Server functionality e.g. Metadata based Search Refinement.

Cross-Site Collection Data Aggregation

  • Now finally with content that is properly tagged with metadata that is centrally managed you can start aggregating data across site collections. For example, you can roll-up content by using an optimized search results web part that searches for Announcements in alle project workspaces for customer projects. Not only would that be a really convincing enhancement to your intranet portal. It could also be the basis for creating rich dashboard applications.

  An example of a webpart that does just this will be added begin 2013 to the wiki-page of this project 

Central site collection navigation and provisioning

  • At the heart of the Location-based Auto-tagging Extension for SharePoint 2010 you'll find a administration list that allows you to centrally provision (and manage) workspaces i.e. site collections. It's here where you define metadata for the workspace that is then inherited by all its sites and subsequent libraries and lists. You can easily query this list (remotely) to provide a custom global workspace directory. Again, this would be a great enhance for your intranet portal e.g. All Marketing Workspaces.

The software comes as a single Windows SharePoint Solution Package (.WSP) together with a simple PowerShell Script to install it. As it is a Farm-Solution it is important that installation is conducted by your SharePoint Farm Administator. Since a SharePoint environment can be highly sensitive, proper testing is essential. Please also take notice of the following statements:

  • This software doesn't not include any third party software
  • Neither does it include any propietary software
  • Upon removal of the software you can continue using the workspaces created with it

A user manual is available online here: user manual.

If you want to show your appreciation and support future development then you can donate here:

Last edited Dec 22, 2012 at 6:07 PM by mvwieren, version 7