Aimless Ramblings from a Blithering Lunatic . . .

Just another Microsoft MVPs site

Month: September 2006

A companyweb by any other name . . .

So, one question that I get asked regularly is if you can use a different name to access your companyweb.  For whatever reason, it appears SBSers have their own ideas of what URL / name they want for their individual intranets [;)]   The good news is that this is very simple to do . . .

1)   Pick a name you want to use –  for the purposes of this post, let's say we want to use http://intranet (yeah, real original, I know . . . )

2)   Add and entry to your DNS.  First and foremost, we have to make sure that intranet resolves correctly to your server's IP. 
     a)  So open your DNS snap-in, expand <servername> | Forward Lookup Zones | <domain name>. 
     b)  Right-click on <domain name> in the left hand pane, and select 'New Alias (CNAME)'.
     c)  Enter 'intranet' for the Alias name.
     d)  Enter the FQDN of your SBS in the target host field (e.g.  sbs.company.local)
     e)  Click OK  and close the DNS snap-in

3)  Edit the host-headers for your companyweb site.  Now we have to make sure that IIS knows how to route traffic properly.  You see, when IIS receives a normal http web request, it looks at the header of the request to get the URL that the user entered (in this case,  http://intranet).  IIS then looks at the websites to see if there is one that wants this traffic (has a host header present that matches the request URL).  If it can't find a site with a matching host header, then it sends the request to the default web site.  Since we want these requests to go to the companyweb site instead of the default web site, we need to add host headers to the companyweb site.
     a)  Open IIS Administrator snap-in
     b)  Expand <servername> | Web Sites
     c)  Right-click on companyweb and select Properties
     d)  On the web site tab, click the Advanced button
     e)  Click the 'Add' button on the top half of the page.
     f)  Change the IP address from (All Unassigned) to the internal IP of your SBS.
     g)  Set the TCP Port to 80
     h)  Set the host header value to intranet  (or whatever name you want to use)
     i)  Click OK
     j)  Repeat steps e thru i, only this time use the FQDN value in step h (e.g. intranet.company.local)
     k)  Click OK  |   Click OK  |  Close IIS Admin snap-in

4)  Re-extend Windows Sharepoint Services to the web site.  Just like IIS needs host headers to know where to route requests, Sharepoint central config keeps track of the sharepoint sites in its database.  Therefore, we need to re-extend WSS to the site in order to update the config database so it knows that we're using an alternate name to access the site.
     a)  Open Sharepoint Central Administration
     b)  Click 'Configure Virtual Server Settings'
     c)  Click 'companyweb'
     d)  Click 'Remove Windows Sharepoint Services from Virtual Server'
     e)  Verify 'Remove without deleting content databases' is selected, and click OK
          (when this finishes, you will return to the Sharepoint Central Administration main page)
     f)  Click 'Extend or upgrade virtual server'
     g)  Click 'companyweb'
     h)  Click 'Extend and map to another virtual server'
     i)  In the Server Mapping field, select  'companyweb'
     j)  Select to 'Use and existing application pool'
     k)  Select 'DefaultAppPool (NTAUTHORITY \ NETWORK SERVICE)' for the app pool to use.
     l)  Click OK
     m)  Close Sharepoint Central Administration.

Now, open IE and browse to http://intranet (or whatever name you used) and verify that it opens up your companyweb.  Note that after following these steps, you will still be able to access the site by browsing to http://companyweb.  This is because the native SBS functionality relies on the Sharepoint site answering to http://companyweb.  As a result, you can have your users use the new name you specified, but all of the SBS functionality (including the wizards in the SBS Admin Console and the companyweb links in RWW, etc.) will work just as before . . .  

Publishing websites on Windows Server

It seems like we're dealing with more and more web applications in our business, and I find that I'm getting more and more questions about publishing these applications to the outside world – whether we're talking about a public-facing Sharepoint site, business site, or even a web application like Level Platforms' Managed Workplace Service Center.  As a result, I decided to take the time to put up a beginner's guide to publishing web sites with Windows Server 2003.  For all the SBSers, I'll include some SBS-specific content (most notably regarding ISA) – but otherwise the process is basically the same whether we're dealing with vanilla Windows Server or SBS.

1)  Understanding Your Toplogy:

The first thing to understand is your network layout – specifically, what is between the website you want to publish and the internet?  Do you have a dual-nic SBS box connected directly to your cable modem so that the SBS has a public IP?  Do you have a single-nic server behind a hardware firewall?  Or maybe you have a single-nic web server behind a tri-homed SBS premium that is behind a basic NAT router . . .    Obviously everyone here, it will be pretty simple for you to determine what path inbound web traffic needs to take to get to the server where your website lives.

2)  Taking Stock of Your Sites:

This is often an important step that I see many SBSers miss . . .  they fail to properly define the scope of their project . . .   after all, we very rarely want to publish a single web site – but in fact want to publish all of the sites on our web server(s).  When you take stock of your sites, you want to know what URLs visitors will be using to access each site, which protocols (just HTTP, or HTTPS as well?), and which ports each sites uses

3)  Understanding how Web Traffic gets Routed

There are two little gems of information that are really the key to successfully publishing multiple websites on a Windows Server.  First:

Host Headers:  Simply put, host headers allow you to tell IIS what URLs (either private or public) are associated with a given web site in IIS.  Host headers allow us to publish multiple websites all with a single public IP address.

SSL / HTTPS:  When it comes to sites that are going to be encrypting traffic, we lose the benefit of host headers.  As a result, each site that requires SSL needs a unique combination of public IP and port.

For right now, we're going to focus on sites that do not require SSL, and we'll come back to publishing encrypted sites later.  So let's start with the simplest scenario we have:  all of our sites on a single-nic Windows Server (either Std or SBS) behind a NAT'ing hardware router / firewall.  I am going to assume that you have already created the websites you want to publish.  The main point we need to address in the site configuration is the host header value(s).  So,