The other day I was laying out the framework, wire-frame if you will, of a few SharePoint Site Collections. During the planning process I was doing my god-like role of determining which divisions would have their own Site Collection and which divisions would share a Site Collection. As part of the exercise, I had to define my Managed Paths. Well, I don't know about you, but I have a tendency to always forget the difference between Managed Paths: Explicit Inclusion versus Wildcard Inclusion.
Why use Managed Paths?
As a SharePoint administrator you need to define which URL's SharePoint will maintain and which URL's can be used for Self Service Site Creation. OK, so what does that mean? I could pretend to be all-knowing and present you a re-hash of someone else's words, but, I'd rather just provide you a great description that Ben Curry wrote in his book Microsoft SharePoint Products and Technologies Administrator's Pocket Consultant (read the whole thing through; the last paragraph quoted will bring the entire definition into focus):
If you have a medium-scale or larger implementation, give serious consideration to extending the default set of managed paths. A managed path is defined as the path in the URI that is managed by SharePoint products. As an example, sites is the managed path in http://<site>/sites/madison. Managed paths cannot be limited for use by specific security groups, nor can they be targeted directly with audiences. They are simply a way to organize a large quantity of site collections.
When using managed paths, you can have two site collections with same name [i.e., 'Meetings']. For Example, http://<site>HR/Meetings and http://<site>Sales/Meetings [have the same site collection name of 'Meetings'].
When adding a new path, you have the option either to include only that path (explicit inclusion) or to specify that path and all subordinate paths (wildcard inclusion). If the path http:/<site>/sites was specified as an explicit inclusion, content could still be served from the WFE file system at http://<site>/sites/path. When creating an explicit inclusion managed path, you can then create a single site collection in the root of that path. If http://<site>/sites was specified as a wildcard inclusion, multiple named site collections could be created under that path.
If that didn't clear things up, then let's take it one step further.
Explicit Inclusion versus Wildcard Inclusion
Bob Fox has done a great job in creating several SharePoint screen casts; one of them is dedicated to Managed Paths. In his Managed Paths Demo, he provides us with yet another great set of definitions for Explicit Inclusion and Wildcard Inclusion:
Includes only the specific path you set. Use explicit inclusions, for example, if you want Windows SharePoint Services to manage a specific path, such as /portal, but not any possible sites below it, such as /portal/webapp.
Includes any sites below the path you set, so you don't have to add them individually. This is the type of inclusion to use for Self-Service Site Creation, when you want users to be able to create top-level Web sites underneath a specific path, such as /sites.
For example, using an explicit inclusion, you are saying that http://<site>/team/ is a site collection without the possibility of any site collections below it; however, wildcard exclusion allows you to create site collections under http://<site>/team/
Having a solid understanding of Managed Paths is a definite must for any SharePoint administrator. Though, I'm sure I'll have to refer to my own blog post the next time I need to configure Managed Paths.