Sign In
 
 
Go Search
 
Zach Rosenfield's SharePoint Blog > Categories
SharePoint 101: What’s a Host Header Site Collection?

I often get asked to differentiate the different ways to configure URLs for site collections—most often how Host Header (HH) Site Collections fit into the mix—so I thought I’d try to disambiguate this for everyone.  In the simplest explanation, there are three types of Site Collections:

 

·    Load-Balanced URL web application:   A single root URL that is shared amongst all contained site collections.  For example, you could have http://sharepoint, http://my, or http://teams.  There is one root site collection (matches web application URL) and additional site collections can be created at Managed Paths under this URL (http://sharepoint/sites/zach).

·    Host header web applications: Similar to a load-balanced URL web application, except the URLs all use a single host header (e.g.: http://www.foo.com).

·    Host Header Site Collection: These are site collections that each have their own unique host header. For example, http://foo.com and http://bar.com.  These sites are by far the easiest to rename—use STSADM –o RenameSite to change a HH Site Collection host header.  These site collections must still be hosted in a web application—but the Web App URL or Host Header is ignored for these sites.

 

While host header site collections give the most flexibility for offering multiple unique FQDNs, there are some limitations:

 

·    Only 1 site collection can use a unique Host Header

·    Managed Paths do no work

·    AAMs are not used as part of site lookup for HH Site Collections, so URL re-writing will not work

·    SSL Termination at the load balancer will not work  (due to lack of AAM support)

 

It’s important to note that Host Header Site Collections can only be created from the command line—in the STSADM command createsite, provide the Host Header for the SPSite in the URL parameter and then provide the url of the web application that will host the HH Site Collection.   The good news is that for those of you familiar with previous versions of SharePoint, there is no longer a “Host Header Mode”; HH Site Collections can be created at anytime on existing web applications.

SharePoint 101: Full Width Rich Text Editor
It can be a little frustrating in SharePoint when the "Rich Text Editor" on the edit page of Wiki's, Blogs, or on certain lists is set to fixed column width.  I certainly find it easier to blog in a fullscreen-width editor!
 
Here's the CSS to make it happen (warning, this syntax applies to ALL rich text editors!).   The first does all normal forms and wikis:
 
#onetIDListForm, #onetIDListForm .ms-formbody, #onetIDListForm iframe[title="Rich Text Editor"]{
 width:100% !important;
}
 
And this does the same for Blogs!

.ms-formbody span span div iframe, .ms-formbody span span table.ms-long{
 width:100%; text-align:left;
}

Hope this helps.
SharePoint 101: Styling the Site Actions menu

This is a quick one... I wanted to share a "SharePoint 101" tip: Styling the Site Actions Menu.

Here's what i started with--you can tell that the site actions menu (with its Out-Of-The-Box style) wasn't going to work for me:

I wanted something simpler that matches the "welcome" screen! So for starters, i removed the background from the container div:

.ms-siteactionsmenu div div div{
     background:transparent !important;
}

Notice the "!important".  This is so that I can override the inline styles on the control (get ready for a few more of them).  Next I remove the border from this same div:

.ms-siteactionsmenu div div div{
                background:transparent
!important;
     border:1px solid transparent !important;

}

So--Getting Better!

Note that I leave the 1 pixel 'transparent' border so that when I show a border on hover I don't get a funky "resize" behavior.  So, on that note--let's add the "hover" behavior:

.ms-siteactionsmenu div div div.ms-siteactionsmenuhover{

     background: green !important;

     border:1px solid white !important;

}

 

On hover now looks like this:

 

 

Simple and clean! To finish it off, I similarly set the Welcome to the same hover style:

.ms-siteactionsmenu div div div.ms-siteactionsmenuhover, .ms-SpLinkButtonActive{

     background: green !important;

     border:1px solid white !important;

}

 

SharePoint 101: Managed Paths

I often get asked "What is a managed path?" and thought it would make for a good blog post. However, first I must disambiguate a couple common SharePoint terms. For the remainder of this post I will use Object Model (OM) terms for the following objects listed below. I've given a small explanation of these objects—but it is certainly not all inclusive.

  • SPWeb: These are referred to in SharePoint UI as a "Site". SPWeb's are a collection of user data (lists, library, docs, pages, etc.) in a database. An SPWeb belongs to one, and only one, SPSite.
  • SPSite: These are referred to in SharePoint UI as a "Site Collection". SPSites are a grouping of SPWebs that all share the same root URL. The SPWeb that lives at the root url of an SPSite is called the "Root Web". SPSites have settings, but do not contain user data.

SPSites have one very important feature—all SPWebs in an SPSite must be stored in the same Content Database. This is key to how we figure out what database user data is stored in.

Now, on to managed paths! When user types in a URL into their browser—the root domain is directed through DNS to a SharePoint Server (this is the easy part!). Once SharePoint gets a URL, how does it now what data to look up?! Let's take the following url: http://www.foo.com/sites/foo/bar/foobar. The first thing to note is that we know that the user's data (provided he typed a valid URL in) is in an SPWeb somewhere… But where? First we need to figure out the 'containing' SPSite so we know what database to look at—but which part of the URL gives us the address of the SPSite? /sites? /? /sites/foo/bar? This is where Managed Paths play their role.

SPSites are limited to being created only where a managed path is defined! For example, "(root)" is one of the default managed paths you see when creating a new web application in SharePoint (visit Central Administration -> Application Management -> Define Managed Paths). This means you can create one site collection at the root of the web app—in our example, this means you can have a site collection at http://foo.com. This is an explicit managed path as it means you can create only one site collection at the exact location specified.

Another default managed path you see is "sites"—which is a wildcard managed path. This allows for unlimited number of site collections to be created directly under the provided path (it is important to note that a site collection, and thus an SPWeb, cannot be created at this explicit url). This means I can create site collection (and only SPSites, not SPWebs) directly under this url (http://foo/sites/foo). This means that any additional path in the given URL is an spweb (created from the root web of this spsite). So in our example, we can split the incoming URL into four pieces to quickly look up the information:

"http://ww.foo.com" + "/Sites" + "/Foo" + "/bar/foobar"
(Web Application) + (managed path) + (SPSite) + (Web/SubWeb)

Whenever a URL is 'received' by SharePoint, the site collection is determined by looking at the list of managed paths for a given Web Application. This means SharePoint has to look at every managed path so try to limit the number of managed paths (<20 is highly recommended). SharePoint always matches the longest pattern possible—we'll look at a more complicated example to explain the reason. Using the following managed paths:

  • 10 (explicit)
  • 10/teams (wildcard)
  • 10/howto (explicit)
  • 10/howto/misc (wildcard)

How do we map out URLs? Site Collections (SPSites) urls are highlighted in Bold:

  • http://foo.com/10/teams/sites/bar
  • http://foo.com/10/myteam/sites/bar
  • http://foo.com/10/howto/team1/foo
  • http://foo.com/10/howto/misc/team1/foo/bar
  • http://foo.com/10/howto/misc/team2/foo

The key item to note is in the last three example URLs—notice that the longest managed path (10/howto/misc) takes precedence over the shorter (10/howto). Hopefully this clears up Managed Paths! I'll end by summarizing:

  • Managed Paths allow SharePoint to determine what portion of a given URL corresponds to the "site collection URL".
  • Managed Paths can be defined per web application (and cannot be defined for host header site collections)
  • Managed Paths can be "Explicit" or "Wildcard"
  • Explicit Managed Paths allow a single spsite to be created at exactly the given url
  • Wildcard Manage Paths allow unlimited spsites to be created under the given url – no spsite can be created at exactly that URL.
  • Limit your managed paths to <20 per web application
SharePoint 101: Alternate RSS Feed

This week, a quick SharePoint 101 session—changing the SharePoint RSS feed to use your favorite alternate. I just set up this blog to use FeedBurner—and wanted to make the RSS button in the browser point people to my FeedBurner URL:

Alternate RSS Feeds

To do this was quite simple! There are two easy steps. First, add the feed links to the <HEAD> tag of your Master Page:

<link rel="alternate" type="application/rss+xml" title="Zach Rosenfield's SharePoint Blog (RSS)" href="http://feeds.feedburner.com/ZachRosenfield" />
<link rel="alternate" type="application/atom+xml" title="Zach Rosenfield's SharePoint Blog (ATOM)" href="http://feeds.feedburner.com/ZachRosenfield" />

Each entry adds another option to the drop down (the first one defined will be the default option).

Next, we need to remove the default RSS feed link generated by SharePoint—it's a tag called <SharePoint:RssLink runat="server"/>. You'll find it in the 'default.aspx' page (and any other blog post viewing page) inside the "PlaceHolderAdditionalPageHead" content place holder. Remove the tag—but NOT the content placeholder! Repeat this to any page that views a blog post; I removed it from Default.aspx as well as the AllPosts.aspx and Posts.aspx pages under Lists > Posts.

*Side Note: be aware that by editing these pages you are customizing it (also called 'unghosting') to be unique—not relying on the underlying site definition (this is important as it will affect your page during upgrade).

SharePoint 101: Beginner Master Pages

Building a SharePoint master page is hard. Period. But with the right tools—even the most ambitious web site can be designed. It's just a different mentality than web designers are used to doing. It's more about mapping existing components than creating a new web site. I wanted to share some useful links and try to help out! Here's the must have elements of creating a new master page:

  1. Check out the Minimal Master Page on MSDN. In my opinion, it's actually a little too 'minimal' and takes some work to get started when all you're given is a blank slate.

    *NOTE: there is a required ContentPlaceHolder missing from the MSDN howto (atleast as of 1/1/2008)—make sure that there is a content place holder for the section "PlaceHolderBodyRightMargin". If not, add it to the 'invisible' panel of content placeholders to avoid issues in the future.

     

  2. Find a good "Master Page CSS Reference" chart for SharePoint. I have started to create a library (it's a work in progress, but I'm trying!) that's originally based off of Heather Solomon's CSS Reference Chart (Heather has some areas I have yet to reach). You can see my library here, or use the link on the left hand nav.

     

  3. Is your master page missing something? Look at the Content Place Holder list on MSDN to see if you have the necessary component. Just because it's not required for the page to render, doesn't mean you don't want to have it on the page. For example, the section "WSSDesignConsole" is not in the Minimal Master Page as it is not a required field – yet if you don't add this to your master page users will be unable to save any changes after pressing "Edit Page"! I am also adding these to my Master Page Cheat Sheet—available from the Master Page Elements View.

     

Hope this helps you all get started!

SharePoint 101: Enable Error Messages

While creating my custom master page for this blog I failed to include a required ContentPlaceHolder on my page—and was shown a very generic "Error" message. Since I was never going to figure out what I had done wrong, I needed to enable error messages for my web application to get the full description of the problem (which solved my issue instantaneously). Here's how to enable turn off friendly error messages:

  1. On the web server, navigate to the site directory (probably something like: C:\Inetpub\wwwroot\wss\VirtualDirectories\80 )
  2. Open the Web.Config file in Notepad
  3. Search for the safemode node with the word "CallStack" and change the CallStack status to true
    <SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
  4. Search for the CustomErrors node and set the mode to off
    <customErrors mode="Off" />
  5. Save and close.

Don't do this on a live farm—it's not good for your security! But this is definitely a common change for development farms that will be sure to simplify your work.

SharePoint 101
I've added a new category to my blog called SharePoint 101.  I don't mean to bog down my overall blog theme (SharePoint Administration), but as I run into complicated or interesting SharePoint topics I need a place to post them.
 
As always, if your interested in a specific area of SharePoint, please post your topics in the comments of a post and I'll try to look into it!
 
 
   
Real Time Web Analytics