Note: This document is based on the original spoken WebCast transcript. It has been edited for clarity.

John Morello: Today's topic is "Hosting Web sites on Microsoft Small Business Server 2000." Just to briefly cover what our agenda today (slide 2) is going to be, the first thing that we're going to look at is using host headers and destination sets to host multiple Web sites. Then, we'll cover how ISA packet filters help protect network security, and also how to configure ISA to publish protected network services.

So the flow of the talk today is going to be as follows. We'll first talk about configuring and verifying our DNS configurations, then we'll talk about the necessary components for IIS and ISA to be running on the same server. Throughout the discussion, we'll be referring to these components of Small Business Server, IIS and ISA, by their short names, just to make it a little bit quicker for us. IIS stands for Internet Information Services, which is the Web server component of Small Business Server and also of Microsoft^® Windows^® 2000. ISA, or ISA Server, is Internet Security and Acceleration Server, which is a firewall and Web-caching product that ships with Small Business Server 2000.

After we talk about installing the components, we'll look at how we configure IIS and ISA to work together on the same server. Next, we'll go over a brief review of how logical Web requests are going to flow through, all the way from an Internet client through ISA Server to IIS and then back to that client, just to give you a brief overview of how the entire process works. Finally, we'll finish up with how to maintain your site. In other words, how to increase the performance of your Web site and also how to maintain it in its proper security state.

The first thing that we need to look at is the hosting requirements (slide 3). Any Web host must have a static IP address that will be assigned by the organization's ISP. Many types of Internet connections are available today, including DSL, ADSL, cable, T1, and ISDN. Keep in mind that the important feature for the Web host is the upstream capacity. So ensure that in an asynchronous connection environment, which is common with DSL service, that the upstream bandwidth is what your Internet customers will be utilizing. The bandwidth sizing requirements for an SBS 2000 server will depend heavily on factors such as concurrent users and content type and sizes, as well as the number of sites hosted on the server. Tuning your Web site and bandwidth is an ongoing process. It's important to make sure that your sites are able to respond normally, even during periods of heavy use.

So if we look at our hosting requirements slide, one of the things that we see here is that you need to have a server that meets the SBS 2000 recommended requirements, rather than the minimum requirements. Our recommended requirements are a 500-MHz Pentium III with at least 256 MB of RAM. Obviously, if you need to increase performance, or if you're going to have a larger Web site, you want to increase those requirements accordingly. Also, see that the upstream Internet connection is at least 128 Kbps. Usually, ISDN will at least have that kind of bandwidth. You may be interested in getting something like a fractional T1, or even a full T1, though, depending on the amount of traffic you anticipate having on your site.

The next thing we'll look at is why hosting a Web is different on SBS, as opposed to Windows 2000 with IIS (slide 4). In most scenarios, the firewall and the Web hosts are on physically separate servers, which allows the firewall service to publish the Web host from a protected network. Because SBS is an integrated suite, both Internet Security Acceleration Server and Internet Information Services run on the same physical server. Because of that, ISA and IIS require specialized configuration to work together properly and efficiently.

Now, we'll take an example environment to refer to throughout the WebCast to help us demonstrate the principles that we're going to be talking about today (slide 5). In our baseline hosting configuration, we have a multihomed Small Business Server 2000 computer with one interface attached to the Internet and the other attached to the private LAN. This configuration can vary greatly, and it may include single-homed servers behind a hardware router or multihomed servers where the external interface is attached to an upstream router. In cases where a hardware device, such as a DSL modem, router, or ISDN adapter, is the device with direct Internet connection, that hardware must be configured to map to the appropriate ports or IP addresses to the SBS 2000 server.

So if we're looking at our diagram here, we see that the Internet cloud represents any kind of connection that you may have to the Internet. The connection is a neutral-connection environment. In other words, it doesn't matter. We don't care if you're using DSL, have fractional T1, a full T1, cable modem, or any other kind of technology. As long as you have a normal IP connection to the Internet, you'll be able to host here, without any problems.

In our test scenario, we'll be working with the Northwind Trading Company. We'll assume that Northwind Trading has made the move to Small Business Server 2000. Because Northwind Trading wants to develop a more full-featured Web site, the company has decided to host their Web site locally on their SBS 2000 server. Northwind Trading has followed the Windows 2000 domain-naming scheme we recommend and named their Windows 2000 domain nwtraders.local. Their ISP has installed a T1 line in their office, and has given them a static IP address of 200.2.2.2. As with most SBS 2000 hosting scenarios, the ISP will continue to hold the SOA record for the domain nwtraders.com. Their ISP has already created an A record called www within the nwtraders.com zone, and has associated the A record with the 200.2.2.2 IP address. If you're unfamiliar with these DNS concepts at this point, don't worry. We'll be addressing them in more detail very soon.

Next, we'll look at installing the necessary components (slide 6) on your SBS 2000 server to make sure that you're able to host the Web sites and also protect the Web sites properly with the ISA Firewall service. The first step is going to be to use the Microsoft Small Business Server 2000 Setup Wizard to install the components that we need. Small Business Server setup will, by default, include both ISA 2000 and IIS 5.0. Note that IIS is under the group called Windows 2000 Optional Components. When any SBS 2000 component is installed, it's recommended that you use the SBS 2000 integrated setup wizard to ensure that all the components are tuned to work together properly and efficiently. That setup wizard can be found in two places: either by running Setup directly off the first CD in the SBS set, or by running Setup from Add/Remove Programs in Control Panel.

After you've installed the necessary components using the SBS setup wizard, we'll need to next run the Internet Connection Wizard to ensure that the Internet connection is properly configured to work with all the associated services, such as Exchange, ISA, and IIS.

After the Internet Connection Wizard is run, we'll next go to the To Do list in the BackOffice® Server Manager of your Administrator Console and choose the option to Configure IIS. Configuring Internet Information Services does two things for us. First of all, it binds the Web to the default internal IP address on the server, which is going to be important, as you'll see later on. Second, it disables socket pooling for IIS, which will also be important, and which we'll discuss at a later time.

The next thing that we're going to look at is a basic DNS configuration overview (slide 7). After the components are installed, the next thing that we need to check to make sure of is that the DNS configuration is set up properly. In verifying DNS addressing, first determine which server has the Start of Authority (SOA) record for the target domain. Then, attach that server and determine what IP address is associated with the A record for the target host.

So, in our scenario, we first determined that the SOA record for nwtraders.com is hosted by their ISP. Then, we query the ISP's DNS server for information about the A record for www.nwtraders.com. After we verify that the A record correctly points to the external IP address of our server, we'll be able to continue configuring our own server in confidence, knowing that DNS, externally, is configured properly.

A common problem in any hosting scenario is incorrectly configured DNS records. So the first and the most important step is to verify that these address records have been correctly configured. To verify which servers have SOA for a particular domain, and also that the A records are configured properly, we'll use the Nslookup utility included with Windows 2000.

This next slide (slide 8) is what we'll actually be doing at the command prompt while we're using Nslookup. If you want to, you can also refer to Q200525, titled "Using Nslookup" (http://support.microsoft.com/support/misc/kblookup.asp?id=Q200525) for further information on how to use this utility. In our example, we'll see that the server at 200.1.1.1 owns the Start of Authority record for the nwtraders.com domain.

To use Nslookup, the first thing we'll do is drop to the basic command prompt. At that command prompt, we'll type in the command line, nslookup. You'll see the first thing that happens is the default servers return. The default server should be configured to be the internal DNS server on your SBS 2000 system. It will return both the DNS name, server.nwtraders.local, in our case, and its associated IP address.

Because this server does not have the Start of Authority record for the domain that we're looking for, we need to change the server to be a server that does host that Start of Authority record. So we can choose the server by typing in the server variable, space, then the name of the server that we want to attach it to. So in our example, we'll say, server <space> dns1.isp.net. In your case, you could substitute the dns1 part for whatever your ISP's DNS server is. After you do that, you'll see that it returns the default DNS server address of that server, as well as that server's IP address.

After we've done that, the next thing that we'll do is change the type to Start of Authority, which is what SOA stands for. So you'll see here, we'll say, set type=soa.

After that, the next query that we'll issue is to find out what server holds the Start of Authority records for the domain that we'll specify. At this point, all we need to do is to type in the name of the domain we want to query on. In this case, it's going to be nwtraders.com. So we'll just type in nwtraders.com, and you'll notice, after you press Enter, it will determine what server has the actual Start of Authority record. In this case, the same server we were originally attached to is the server that hosts Start of Authority. So, as soon as we typed nwtraders.com, we'll see the server is equal to dns1.isp.net, and it lists the address of that server as well.

Another thing to keep in mind here is that we need to keep the two namespaces separate. In other words, the namespace that's used for our internal Windows 2000 domain, we need to call that domain.local (that's how we recommend it). Also, the domain that's going to be used on the Internet is obviously going to be domain.tld. So in your situation, let's say that your company was just called Company. Well, you would call your company's internal Windows 2000 domain name company.local, and its Internet domain name would be something like company.tld.

Next, we'll use Nslookup to verify that your Web host is correctly pointed to the actual IP address on the external interface of your server (slide 9). After the server that has SOA for a domain has been determined, the next step is to attach to that server and verify that the A record for the Web host is pointed to the correct IP address. If any discrepancies are found between the expected record information and what's actually provided by DNS, that A record needs to be updated on the server listed as the Start of Authority server, which is what we determined in our previous step.

So, in our example, we can see that

www.nwtraders.com resolves to 200.2.2.2, which is the IP address assigned to our fictitious server's external adapter. So again, to go through the command prompt, you'll see that we're going to type in nslookup again, and we're attached to our same local, internal server, which is server.nwtraders.local.

The next thing that we'll do is change the server to the server that we determined in our previous step that actually has Start of Authority records for the domain. So, here we'll say server SPACE dns1.isp.net. After that, we're going to query just for the regular host name, which is going to be www.nwtraders.com. We'll see, in this case, that the server response at www.nwtraders.com has the address of 200.2.2.2, which is the address that was assigned to the external address on the card.

The next thing that we'll look at is the basic TCP/IP configuration of the internal adapter (slide 10). The IP address will be a non-routed address, and by default, SBS will use the 192.168.16.2 address. Other associated private ranges that could be used in an SBS environment include the 10.0.0 range, as well as 172.16 through 172.32, and 192.168. The gateway on the SBS internal adapter should always be left empty, and the DNS server should be pointed to the IP address of the adapter. In other words, if my adapter was the 192.168.16.2 that SBS provides by default, I would provide that same address as the DNS server's address.

Again, in our Northwind scenario, the internal IP will use the SBS default of the 192.168.16.2. The reason why we associate the internal DNS server at this point is that we want to pass our name resolution first through the internal server and then use forwarders to resolve names that the internal server does not have the Start of Authority for. We'll get to that process in a few moments.

Next, we'll look at basic TCP/IP configuration of the external adapter (slide 11). On the external adapter, the IP address, subnet mask and default gateway will be provided by our ISP. We'll use the IP of the internal adapter again as our DNS server. The external network adapter TCP/IP configuration will be mostly dictated by the ISP, which will provide the correct IP to subnet to gateway addresses for the adapter. An important concept on the external adapter is to not enter the ISP's DNS server in the DNS server address options for the adapter. Rather, the external adapter, like the internal one as well, should be pointed to the server's internal DNS server for name resolution. If the Internet Connection Wizard has already been run and has completed properly, this chore should already be done for you. Otherwise, the ISP's DNS servers will then need to be manually added to the Forwarders list for the local DNS server. We'll look at how that's done in just a few moments.

The next thing that we'll need to do is to remove any unnecessary services and protocols that we have bound to the external adapter. Those include things like NetBIOS, if you have file and print sharing bound to it, Services for Macintosh, anything like that, which doesn't need to be accessible over the Internet, needs to be removed from that external adapter. This does a couple of things for you. First of all, disabling NetBIOS can help you avoid some potential name resolution issues with down-level Windows 98 or Windows 95 clients. Also, disabling NetBIOS will help you protect against some of your local network security issues.

Next, you'd want to disable DNS registration on the external adapter to avoid sending information about your internal network to the ISP. That information will be discarded by the ISP's DNS servers, but there's really no reason to send that on. Both of those changes will be made in the Advanced tab on your TCP/IP properties. First, we'd want to disable NetBIOS over TCP/IP and also disable DNS registration.

Now, we're going to look at configuring DNS forwarders (slide 12). Again, if the Internet Connection Wizard has already been run, DNS forwarders should be configured properly, assuming you do not have a dial-up connection. If you do have a dial-up connection, you probably should not be hosting a Web site.

Forwarders are what we use to allow for name resolution for internal clients to resolve external addresses that aren't hosted by the actual SBS server. Because both network adapters are looking to the internal DNS server for address resolution, we must provide a way for the internal DNS service to resolve names and zones it is not authoritative for. This is accomplished by adding the ISP's DNS servers to the Forwarders list for the internal DNS server.

This will be done by opening the DNS Management console and making the changes in there. The DNS Management console can be found under the Administrative Tools on your Start menu. Open up the DNS Management console, under Administrative Tools. Right-click the computer name and go to Properties. In Properties, go to the Forwarders tab (slide 13). Select the Enable forwarders box, click the Add button, and add the addresses specified by the ISP's DNS servers. In this case, because we already knew that the ISP's DNS server was 200.1.1.1, we would simply select Enable forwarders, click Add, and add that address in there. At that point, there's very little left that you need to do with the DNS forwarders configuration. You can click OK and restart the DNS service.

Now, at this point, we already have DNS configured properly. We've also verified that DNS has been configured properly by using the Nslookup utility. In other words, at this point, we know that the URL for our Web site actually does point to the IP address of our external adapter. So any further configuration that we need to do will be solely within the ISA or IIS side of things, and not so much with DNS or with the ISP.

What we're going to look at now is how to determine what kind of hosting scenario you'll be using (slide 14). In other words, do you plan to host multiple Web sites on the same server? If you are, will you be using host headers or unique IP addressing for those Web sites? Finally, we'll briefly touch on the different ways that you can update content on an SBS Server.

Keep in mind that IIS differentiates between multiple Web sites running on the same server by examining three properties for each Web site: the IP address, the host header, and the TCP port that the Web site uses. Each Web site on the server must be unique from all others by at least one of these three properties.

Most commonly, host headers are used to distinguish between multiple, virtual Web sites, because they cut down on costs associated with multiple IP addresses and also help simplify IP management on the server. When using host headers, you need to go through the same verification process we covered earlier, though, to ensure that the DNS configuration for each host header also correctly points to your external IP address.

As far as content updating methods, you have several choices. You can use something like FrontPage^®, SMB, or just normal Windows file copy from your internal network. The appropriate packet filters and permissions will need to be added for whatever decision you choose to make for content update methods. But for our discussion, we'll just leave it that SBS supports all common update methods, such as just regular SMB updates from the internal network, WebDAV, FrontPage, or FTP.

The next thing that we'll look at is assigning new internal IP addresses to the internal adapter on the SBS server (slide 15). This is necessary if you're hosting multiple Web sites on the same server. When we do this, to avoid a conflict between the Web Proxy service and the hosted Web sites, normally a separate internal IP address will be bound for each Web site hosted, as well as one for Outlook^® Web Access, which runs under the context of the default Web site. These IP addresses should be within the same network as the internal network, and they must be removed from the available DHCP scope to avoid possible addressing conflicts.

For our Northwind Traders scenario, we'll create a new IP of 192.168.16.200. Again, we'll need to make sure that the IP has been removed from the DHCP scope, and we'll apply that IP to the internal adapter. The way that this is done is to go to the Advanced TCP/IP Settings for whatever adapter we're going to add this to. Again, it's going to be the internal adapter in our ISP environment. We'll go the advanced properties, and under IP address we'll add the correct IP address, and then under that the Subnet mask associated with it, and we'll click on Add.

After the IP addresses have been bound properly, we'll create the Web sites within IIS. For each separate site being hosted, we'll need to create a new Web site, using the Internet Services Manager, which is also found under Administrative Tools on the Start menu. For Northwind Traders, we'll create a new Web called Northwind. So, we'll open the Internet Services Manager, again from Administrative Tools in your Start menu. We'll expand the computer name node — the computer name will be whatever the name of your server is. We'll right-click that name, select New, and then select Web site.

A wizard will launch. The wizard is shown in this screen shot (slide 16), saying, "Welcome to the Web Site Creation Wizard." It's going to gather some information, such as whether or not you're going to use a host header, what IP address it's going to be bound to, what TCP port it's going to use, and the file paths for the actual content for the site. After you've filled in all this information, click Finish.

At that point, the Web is created, and it's left in a stop state. In other words, it's not accessible right now within IIS, but we are able to configure it.

Next, we'll look at binding the Web site to the appropriate IP address (slide 17). Again, we'll still be using the Internet Services Manager, and we'll set what Web site is going to be using what IP address. So we'll right-click the Web site, and we'll select Properties.

In our example, we'll go to the properties of the Northwind Web site, and under the Web Site identification tab, we'll look in the drop-down box for IP Address and choose the 192.168.16.200 address that we just recently bound to the internal adapter. This is helping us avoid a race condition between the Web Proxy service and any IIS Web sites that may be running on the server.

The next thing that we'll be looking at is how we're going to reconfigure the incoming Web request listeners (slide 18) within ISA to properly intercept the Web requests coming into the server, and then pass those Web requests off to IIS. The next thing that we'll do is look at the Incoming Web Requests listeners tab within the Internet Security and Acceleration Server Manager. Incoming Web request listeners need to be added for each IP address used to host the Web site. If multiple host headers or destination sets are used to run more than one Web site on the same IP address, that IP will only need to be added once in the Incoming Web Request tab.

Within the ISA Management console, we'll go the properties of the server and go to the Incoming Web Request listeners tab. In our Northwind scenario, we'll set it so that ISA only listens for requests on the external IP of 200.2.2.2.

The next thing that we're going to look at is how we're going to create destination sets within ISA (slide 19). Within the ISA server management console, create a destination set for each Web site hosted. The destination set allows ISA to funnel incoming Web requests to the appropriate filter. In our scenario, we'll call the destination set the same thing as the Web site, Northwind. Keep in mind that the destination set provides the means for ISA to determine which Web Publishing rule will be applied to an incoming Web request. Again, we'll be using the ISA management console to create this. We'll right-click in the Destination Sets area and choose New Destination Set.

The next thing that we'll look at is creating Web Publishing rules (slide 20). After the destination set has been created, we must next create a Web Publishing rule to publish those sites requested via the destination set. When creating the rule, choose the appropriate destination set, and then choose the option to redirect this request to the internal Web server. We'll specify the internal IP address the site is bound to and choose the option to send the original host header. Also, these rules should apply to any incoming requests.

In our Northwind scenario, we'll choose the Northwind destination set and redirect the request to the internal IP we created and bound to the Northwind Web site. Again, that Northwind Web site is running at the 198.168.16.200 IP address that's bound to our internal adapter.

The Web Publishing rule is at the very heart of hosting our Web on SBS. Because it's ISA, through the incoming Web request listener that first receives the HTTP request coming from the Web, the Web Publishing rule itself must be able to correctly identify what Web site the request needs to be funneled to. That's how the Web Publishing rule works. It's going to first look and see what destination set is being used — in other words, what destination set is specified within the Web Publishing rule — and based upon that destination set, it will funnel the request to the appropriate Web site.

In our Northwind example, we created a destination set called www.nwtraders.com. What this means is that the incoming Web request listener will sit there and listen for any Web requests coming into the server. When it receives one of those requests, it's going to forward that on to the Web Publishing rules. The Web Publishing rule is then going to see if it applies to this request. It's going to compare the incoming Web request's host header — in other words, what site it's trying to request — with the destination set that is associated with that rule. If those two match — in other words, if the Web Publishing rule is looking for the www.nwtraders.com and the request is also looking for the same thing — then that Web Publishing rule is what's going to apply. Then the Web Publishing rule will funnel the request to IIS and the appropriate Web site there. IIS will then respond directly to the client.

We'll talk briefly here about packet filters (slide 21). Small Business Server 2000 comes with a number of packet filters predefined after you've run the Internet Connection Wizard. Among these predefined filters is a BackOffice HTTP server packet filter, which allows access to port 80 from internal clients. Keep in mind that the incoming Web request listener will dynamically create filters, so this isn't a necessary thing to have, but it's also created by the Internet Connection Wizard. So it's going to be there by default.

As long as DNS records for the domains are hosted externally, there should be no need to create additional packet filters on the server. If DNS is hosted locally, a packet filter will need to be added for DNS resolution. DNS services run on port 53, and it's important to ensure that the packet filter allows for bidirectional access to the port. Because Northwind's ISP still hosts the DNS records for the domain, nwtraders.com, we won't need to create any additional filters for our test scenario.

At this point, our configuration of ISA and IIS is pretty much complete. For our changes to take place, however, we'll need to restart the ISA services (slide 22). This should be restarted in one of two ways. The easiest way is to open up the computer management console, which is found under the Administrative Tools group on your Start menu, choose the Microsoft ISA Server Control service, right-click it, and choose Restart. You'll then be prompted as to whether or not you want to restart the associated ISA services, such as the Web Proxy service and the Firewall service. At that point, choose Yes. ISA will then stop all of those services and restart the services. At that point, all the changes that we've made within ISA will take full effect.

Alternatively, you can script this out through the command line by using the net stop or net start commands and the name of the service, which is ISACTRL — in other words, ISA Server control. One caveat when doing it from the command line, though, is you do not have the restart option. If you stop the ISA Server Control service from the command line, it will not automatically start the services back up if you type net start ISACTRL. So in that situation, you need to manually start each one of those services on your own.

Now, after we have everything configured, we're going to look at a high-level overview (slide 23) of exactly what's happening with the logical flow of a Web request, all the way from the Internet client, through the DNS hierarchy, to the ISA server, through the ISA server to IIS, and then back to the Internet client. Basically, this is designed to give you a good overview of exactly what's going on when a client requests a page on your SBS server. This is a very good situation to determine what's going wrong if you're having a problem, and you're trying to troubleshoot an issue. You can trace this logical flow back and determine at what point things are failing, and then isolate that issue and address that issue at that point.

So, if we look at the diagram here, in step 1 the client is dialed into a local ISP, and they'll point Internet Explorer to www.nwtraders.com. It can be dialed into any local ISP, anywhere in the world. All that ISP needs to have is a DNS server that's properly configured for the world-wide DNS hierarchy.

In step 2, the client's computer will send a DNS query for www.nwtraders.com to the default DNS server at its ISP. Because the local user's ISP does not have the Start of Authority record for nwtraders.com (step 3), and assuming that the address is not already cached at that DNS server, the ISP's name server must use DNS to find which server holds Start of Authority records for nwtraders.com.

Without getting into all the DNS specifics, that request will be forwarded (step 4) through the DNS hierarchy until the DNS hierarchy determines what server actually does host the Start of Authority records for nwtraders.com. Again, we've determined that to be the ISP for Northwind Traders, which is 200.1.1.1.

So the dns1.isp.net will then check its name table (step 5) and determine that www.nwtraders.com is at 200.2.2.2. That name and IP are then forwarded back through the Internet (step 6) to the client's local ISP DNS server, where it's cached and then returned to the Internet client.

At that point, the Internet client will respond directly to and request directly from www.nwtraders.com (step 7), which is at 200.2.2.2. In other words, if you're certain that the Internet client is able to correctly resolve www.company.com to your actual external IP address, you can be fairly confident that your DNS configuration at your ISP is configured properly.

The next thing that we'll do is look at the logical flow of the Web request after it hits ISA (slide 24). For this, we're going to see that the first thing that happens is the HTTP request will hit the external NIC of the server (step 1). The ISA incoming Web request listener has already dynamically opened the HTTP packet filter (step 2), so the request will be allowed to continue through the firewall. Then, the ISA incoming Web request listener will grab that request and forward it to the Web Publishing rules (step 3). The Web Publishing rules will grab that request, and based on the destination sets it's associated with, forward the request on to the appropriate internal Web server (step 4).

Again, this is where our destination set comes into play here. For example, we created the destination set www.nwtraders.com. After that Web Publishing rule takes a request, it's first going to compare the request to what that destination set is specified for. If those two match, then it will forward it on to whatever IP address is associated with it.

So here, the Web Publishing rule is going to grab the request for www.nwtraders, compare it to the destination set, see that those two match, then forward the request on to the appropriate internal Web server, which is the Web server running on our internal interface of 198.168.16.200. IIS, at that point, will then respond directly back to the Internet client (step 5).

At this point, we pretty much have a fully functional SBS server. Your server should be accessible over the Internet. People should be able to browse pages. Your content should be fully available on the Web; however, your job is not really going to stop here. The important things that you're going to need to do when maintaining your Web site are, number one, watch out for your performance, and number two, to maintain and ensure security in its most secure state.

In your supplemental reading on the Web site, I've included some links for documentation for security and also for some security tools that you can use to help you out in that. This slide (slide 25) gives you an idea of where you can go for the IIS home page. The home page will point to downloads, support, and white papers dealing with IIS, how to configure it, and how to have it do what you want, basically. The first one is the Windows 2000 Web and Application Services home page (http://microsoft.com/windows2000/technologies/web/default.asp); that's the IIS home page.

The next one here is "The Art and Science of Web Server Tuning with Internet Information Services 5.0" (http://microsoft.com/windows2000/techinfo/administration/web/tuning.asp). This is a white paper that describes tuning a Web server when running Internet Information Services 5.0 on Windows 2000 Server. It discusses the importance of monitoring and testing, as well as potential hardware, software, and tools issues that may arise when doing that. So if you configured your Web site, and you're concerned with or just interested in how you can get it to perform better, perform faster, or maybe configure it to do one more specific task, this is a good place to start off, where you can find that information.

The next thing that we'll look at here is basic IIS security (slide 26). One thing that we get a lot of questions about in support is how to secure your Web site. There's a common misperception that you'll secure your Web site the first time, leave it alone, and it will be secure forever. You need to keep in mind that security is an ongoing process, and that the only way that your site's going to be secure is if you can constantly maintain that security by staying up to date with the latest patches and security bulletins.

We're going to test some basic IIS security concepts. These concepts are covered in more detail within the supplemental reading that I've provided on the IIS security home page. One important concept to keep in mind is that IIS operates as an extension of Windows 2000. In other words, IIS uses normal Windows users and groups for user management, normal NTFS access control lists for security, and normal policies for security management.

Anonymous Internet users are represented by the IUSR_<servername> account. Whatever access that account has to a particular file or directory will be granted to anonymous Internet users. It's important that you keep in mind that it's never appropriate to fix access control problems by randomly granting everyone full control over a directory. When you do that, regular HTTP POST requests can be used to change content, update content, and remove content from that directory. You always need to be very granular when setting permissions on a Web site. Give Internet users as much permission as they need to do their job or to view your content, no more and no less.

The next thing that we're going to look at is how you maintain your security with patches and hotfixes (slide 27). This is important, because as any operating system or Web server is going to be going through its life span, there are going to be a number of issues identified that need to be patched or need to be resolved, or maybe there are just performance issues that could be resolved by downloading and installing the patch.

So I've included two links that are very good resources for any Web host using Internet Information Services 5.0. The first one is the "Secure Internet Information Services 5.0 Checklist," (http://microsoft.com/technet/security/iis5chk.asp) which, if you're concerned about IIS security, is the best place to start. It will take you from the very basics of how you configure IIS 5.0 in a secure environment, through all sorts of different configuration options that you can use, depending on what levels of security your environment demands.

Also, keep in mind that the same security principles and best practices associated with any Windows 2000 IIS 5.0 Web server will apply equally to the Small Business Server platform. Small Business Server in the 2000 iteration, much like the Small Business Server 4.5 iteration, is basically just a suite of products. It's not a specialized suite of products, or one for which you can't install the regular patches or the regular hotfixes that are associated with something like IIS or Windows 2000 or ISA. Any patch that comes out for each one of those products, unless for some reason it specifically tells you not to use it with SBS, should have no problem installing on Small Business Server 2000.

Also, remember that the relative security of any particular operating system or Web server is going to be directly proportional to the management of that system. If you invest the time and the resources to keep that system secure, you should have no problems with any kind of malicious actions to that machine.

Also, be sure to check out the links that I've included in the supplemental reading section that deal with topics such as IIS security, how to subscribe to the Product Security Notification bulletins (http://microsoft.com/technet/security/notify.asp), and the Hotfix Checking tool for IIS 5.0, which is also listed on the slide (http://microsoft.com/Downloads/Release.asp?ReleaseID=24168).

The HFCheck tool allows IIS 5.0 administrators to ensure that their servers are up to date on all security patches. The tool can be run continuously or periodically against a local machine or a remote machine, using either a database in the Microsoft Web site or a locally hosted copy. When the tool finds a patch that hasn't been installed, it can display a dialog or write a warning to the event log.

So for those of you who are deploying SBS 2000 out to multiple clients, this is a really great way to ensure that all of your IIS installations are up to date and have all the latest security fixes on there. You can get one single machine to go out and scan the IIS servers at each individual location and return to you a list of hotfixes that may need to be applied to those servers. You can then use something like Terminal Services in Remote Administration mode to apply those patches remotely to the server, without ever having to go on site.

So, in summarization, when you're hosting a Web site on SBS 2000, the first thing that you want to do is verify your hardware and your network connectivity. Verify that they meet the SBS 2000 recommended requirements, and also that the hardware is capable of handling whatever Web site load is going to be placed on it.

Next, configure and verify your DNS addressing. This will be done by using the Nslookup utility found within Windows 2000. You'll first want to verify that the Start of Authority record is correct for the domain, and then that the A record for www is pointed to the external IP address of your server.

Then, you'll go on to run the Internet Connection Wizard to configure the packet filters and also to correctly bind the IP addresses of the server. Then, you'll want to run the Configure Internet Information Services Wizard from your To Do list within the BackOffice Server Manager. Again, this disables socket pooling within IIS and binds the default Web site to the internal IP address of the server.

Next, you're going to want to make sure that the Web sites are bound to the appropriate internal IP addresses. If they're not, or if for some reason the Configure Internet Information Services tool has not done it properly, you'll need to do that manually.

Then, you'll need to create destination sets and Web Publishing rules within ISA to intercept the Web requests coming in, and then publish them to the correct Web site within IIS.

Finally, remember that maintaining a Web server is an ongoing tuning process. Stay up to date with patches for both security and performance. You should be up to date and running a solid Web server on Small Business Server 2000.

Thank you for joining the WebCast, and thank you for choosing Small Business Server 2000. I'll hand it back to Jim for the Q&A session.

Jim Coll: Thank you so much for that presentation, John. I have just a couple of quick notes before we move on to the Q&A portion of this Support WebCast.

To access information on all upcoming Support WebCasts, and the archived content from all past WebCasts, an easy-to-remember URL is http://support.microsoft.com/webcasts/.

The Q&A portion of this Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of these Support WebCasts. So if you need technical assistance, please submit an incident on the Web or call Microsoft Product Support Services and speak to a Support professional.

Joining us today for the Q&A, we have Joel Schaeffer, who is a tech lead with the BackOffice Solutions Group. Thank you for joining us, Joel.

Our first question today is: I installed SBS with Ddsi.ws, which is the actual name space. What problems will I have to overcome now?

John: Okay. I need to get a little bit of clarification on that question. First of all, you said that you installed it with Ddis.com, is that what you're referring to, at this point?

Jim: Ddsi.ws is what they have written.

John: Okay. What I'm assuming is that if it has been installed, that would be the DNS host name. If that's your Internet DNS host name, it's not like there's any kind of major disaster for you here. What you're looking to do is to host the Web site on your own server. So if you're hosting that as your DNS host name, what you're going to need to do is have a www record associated with that host name on your local server. That will allow for internal clients to be able to correctly resolve the www.host.ws address for internal name resolution.

Second, you'll need to contact your ISP and ensure that the www host is associated with the external address on the server. You should not have to do anything to address your Windows 2000 domain name. You just added a couple of levels of complexity to it.

So again, in summarization, the first thing you need to do is to add a www host — an A record — within your local DNS server, which will allow your internal clients to resolve that server. Then, contact your ISP and ensure that the www address is correctly associated with the external IP on the server.

Jim: Okay, thank you, John. Our next question is: How much of the configuration of the network cards is performed by ICW?

John: Well, if you're talking about how much configuration is performed by the ICW, it really depends on what options you choose with the ICW. By default, running the Internet Connection Wizard will give you two things. First of all, it's going to bind the Web site to the appropriate internal IP address. It's also going to set up the packet filters that are necessary within ISA for things like Exchange, SQL Server™, or depending on what you choose to work through ISA. Running the Internet Connection Wizard itself is not usually sufficient to configure things. It's important to follow-up and run that Configure Internet Information Services tool from the To Do list in your BackOffice Server Manager, because that will take the internal IP address and bind the default Web site to that. It will also disable socket pooling within IIS, which is necessary for ISA to work properly in an IIS environment.

Jim: Okay. The next question is: Isn't it also necessary to make sure that the new internal IP address is defined with the ISA LAT?

John: The new internal IP address doesn't necessarily have to be assigned within the LAT. The reason for that is that IP address will never actually be going out. It never will be making a request through ISA. You can associate it and put it within the LAT. It's not something that really necessarily needs to be done, though.

Jim: Our next question is: Can the local client box on the LAN be Windows 2000 Server with IIS 5.0? That is, to host nwtraders.com at 192.168.16.200 there, and use SBS 2000 for some other services, such as Exchange, SQL, DNS, and ISA?

John: Absolutely. That should work fine for you. In that situation, though, you're going to be deviating a little bit from what we discussed today. What we discussed today was having IIS and ISA on the same physical box. What you're doing in that situation is having a secondary server sitting behind the Firewall service. So the only thing that really changes is rather than having to go through the configuration of disabling socket pooling on the SBS server, all you'll need to do is use the Web Publishing rule to publish to the IP address of that internal Windows 2000 Server. If you do that, you should be solid. Basically, you're just going to need to create that Web Publishing rule, associate it with the destination set, and then publish the internal server out through ISA.

Jim: Okay, excellent. At this point, I'd like to ask everybody who's listening to submit some feedback to us. We're looking for suggestions for topics for future WebCasts, or any comments you have about today's WebCast or any WebCasts you've heard in the past. You can send those comments to us using the e-mail alias feedback@microsoft.com, and please include "Support WebCast" in the subject line.

Our next question is: We would like to use SBS Windows 2000–Integrated DNS as the primary Start of Authority DNS for hosting, and then BIND on Linux as a secondary DNS. Are there any issues there, such as replication, or should I use Linux and BIND as the primary SOA to replicate to SBS DNS?

Joel Schaeffer: This is Joel. I'll answer that question. Depending on the configuration of DNS on the SBS box, everything should work fine. The only issue would be regarding replication from the SBS server to the Linux box.

For a moment, let's assume that the Small Business Server would be the primary zone holder, and the Linux box would be the secondary. Because we're registering SRV records in the DNS server on the Small Business Server, we need to be able to have a BIND version that is compliant with SRV records. Otherwise, when our zone transfer takes place, BIND isn't going to know how to deal with an SRV record, and that zone transfer will fail.

Go to the Berkeley Internet Name Daemon at http://www.berkeley.edu/, and they'll list the latest versions of BIND. There is a version of BIND that is compliant with SRV records — BIND 9.0. So if you were to install that on the Linux box, we should be able to successfully do a zone transfer from the Small Business Server to the Linux box.

The other thing that's involved is that, depending on how the forward lookup zone in SBS is configured, if it's an Active Directory™-integrated zone, they're only going to be able to replicate those zones that are Active Directory integrated with other domain controllers within the domain. Obviously, in an SBS environment, we can have a peer DC to a Small Business Server 2000 server. So in that case, as long as the zone is Active Directory integrated, both servers in this environment are domain controllers, and that replication can take place just fine. But in the situation where we have a server that is not a Windows 2000 domain controller, the forward lookup zone on the Small Business Server could not be Active Directory integrated. It would have to be a primary zone. And after it is a primary zone, a secondary can be established to it.

Jim: Thank you, Joel. The next question is: What is the commitment to SBS 2000 with the advent of Windows XP?

John: If you're referring to it from a client perspective, the Windows XP client will be fully supported with SBS 2000. I'm not sure what you're asking, as far as the support in regard to Windows XP, but if you're going to be using Windows XP Professional in an SBS 2000 environment, you should have no problems doing that. In fact, we tested that here, and we haven't had any issues.

Jim: Why do you use an internal private address space for a hosted site?

John: The main reason that we're doing that is this: you have to keep in mind that when you're running a firewall and the Web server on the same box, it's actually the Firewall service that intercepts the incoming Web request. That Firewall service will then publish that request to an internal server. The internal server will then respond to the client.

The reason that we use an internal address is, rather than associating an additional public address with that external network card, it's easy and simple for us, and free also, to just create a new internal IP address associated with the internal network card, and then use ISA to publish those incoming requests to the internal addresses of the server. Again, what that lets us do is avoid having to have an additional address bound to the external NIC, and also, that's really the only way that you're going to be able to get both the firewall and the actual Web server running on the same system, and have the Web server be protected by the firewall.

Keep in mind that the firewall has to be able to have some kind of delineation between the external side of the network and the internal side of the network. By having the firewall listen on the external side of the network, and then publishing the protected resource on the internal side of the network, you're able to make the Web site accessible on the Web, while still having ISA protect that Web site through packet filters and Web publishing and things like that.

Jim: Our next question is: What is disabling socket pooling?

Joel: Okay. I guess I should define what socket pooling is before we talk about disabling. The socket pooling is a concept within Internet Information Services. Within the code base of IIS, it allows us to listen on all interfaces, on all IP addresses, on a specified port. Again, basically, it's the way that IIS can intercept an incoming Web request, dynamically bind that to an IP address, and then service the request back to the client.

By disabling socket pooling, it gives us the ability to truly bind one specific IP address to one specific Web site. Having the ability for IIS to be able to pseudo-listen on all interfaces can cause race conditions, like John was talking about, to where the incoming Web listener will compete for an IP address and a port combination, versus the Web site that may be bound to that same IP address/port combination. So disabling socket pooling will alleviate that possible race condition.

Jim: Okay. Our next question is: Will there be any upgrades to SBS 2000?

John: I'm not sure if you're referring to a product upgrade. There is going to be a subsequent release of Small Business Server in the future. If you're referring to SBS-specific product updates, like an SBS-specific service pack, there will not be. Those were addressed as normal Windows 2000 or normal ISA or normal Exchange service packs.

So if you're looking to resolve a particular issue, say for example, you were looking to have one of the fixes that was included in the Windows 2000 service pack on your SBS server, by all means, go ahead and just deploy the Windows 2000 service pack on your SBS environment. You should have no problems deploying either an upcoming Exchange service pack, an ISA service pack, if it comes out in the future, or any Windows 2000 service packs that come out in the future, on your SBS 2000 server.

Jim: Our next question is: I have been told that only one IP address should be bound to an adapter, or a performance hit takes place. Is this true?

Joel: I guess to answer that question, in the days when hardware was a bit slower, the subsystems were slower, network throughput was slower, yes, you could have seen a performance hit, because each IP address that's bound to the specific adapter would take up a small bit of RAM. With the stringent hardware requirements of Small Business Server, binding multiple internal IP addresses on the internal card and using the Web Publishing rule to forward back to that IP address, the performance hit is negligible. You shouldn't notice it all. So if you were to measure it, yes, there is a small performance hit, because it is utilizing resources, but not one that your users would notice — as long as those minimum hardware requirements are met.

Jim: Okay. We have answered all the questions that were submitted today, so that is going to wrap up our session. I want to thank all of you for joining us. I hope this information was useful to you.

Once again, we are very interested in your feedback regarding the WebCast program. You can send us your comments and suggestions using the e-mail alias feedback@microsoft.com. If you use that alias, please be sure to include "Support WebCast" in the subject line.