What's in a SharePoint Managed Path?

What's in a SharePoint Managed Path?

I often hear and sense confusion about SharePoint managed paths. Managed paths are essentially 'mount points' for site collections.There are two types of managed paths - Explicit and Wildcard.

What's the difference between an explicit managed path and a Wildcard managed path?

By default, the root ‘/’ managed path is explicit, meaning only one site collection can be in it and it assumes the identity of the managed path. That's how you browse to http://webapp.fqdn.msft and get a Web page. A Web application without a site collection in the root managed path will return a 404 error when browsing to the root. You could always create another explicit managed path for multiple portal support in a Web application, i.e. http://webapp.fqdn.msft/HR. HR is a peer to '/'. Now, you can no longer have an HR sub-site in the root - you will get a security validation error because the URL space is already taken.

A Wildcard managed path is basically 180 degrees in the opposite direction. A Wildcard managed path can support hundreds or thousands of site collections, but they are appended to the managed path, like http://webapp.fqdn.msft/sites/team, with sites being the Wildcard managed path. It will always return a 404 error when browsing directly to a Wildcard managed path. But, you can create many Wildcard MPs like teams or projects.  Wildcard managed paths are like a sorting mechanism for site collections.

I hope this helps your Web application structure and design.

Share Point Designer

Share Point Designer – A definite Maybe

SharePoint Designer does have some great qualities that at first glance get you really excited about using it. I could make some analogy here likening SharePoint Designer to an attractive girl you meet at a bar and before you know it you wake up in a bathtub full of ice missing a kidney, but I’ll refrain. So, what’s good about

Don’t have to develop on a the server

Probably the most awesome thing about SharePoint Designer is that you don’t have to develop on the freaking server! This is phenomenal for those developers who have to get SOMETHING done and they don’t have access to the necessary development tools. This was my ONLY option for development for the first 6 months that we were using and learning about SharePoint. You do however need to be a site owner on the site in question.

Modifying ASPX files, Master Pages, and CSS

SharePoint Designer is great for modifying and maintaining your ASPX pages, Master Pages, and Cascading Style Sheets. It especially is useful in browsing through and learning SharePoint’s massive CSS files. SharePoint Designer has a pretty good WYSIWYG editor (What You See Is What You Get) as well which can really help when designing and creating themes.

Prototyping

SharePoint Designer is great for throwing together a quick Prototype on your development servers and getting it in front of people to build some excitement about SharePoint and show what SharePoint is capable of.

SharePoint Designer Workflows

The second best thing about SharePoint Designer are the SharePoint Designer Workflows. SharePoint Designer comes with quite a few workflows that can be connected to a SharePoint List and can be set up to be executed manually, when an item is created, or when an item is changed. Some of things you can easily do with these workflows are:

• Send emails, including emails to individuals who created a list item or executed the workflow
• Do simple business calculations and store those values in your lists
• Create lists
• Update lists