Migrating to a Load Balanced IIS 6 Environment Page 2


There are a few subtle issues involving SMTP and FTP services, such as the absence of CDONTS. Your e-mail form may choke if you don't take one simple measure: copy cdonts.dll from a Win2k machine (located in system32) and copy to the system32 directory. Or, if you're feeling a bit more daring, you can convert all the CDONTS calls to CDO, which is a good option depending on the amount of calls used. I would caution against the second method if you're in a hosting situation where your clients expect CDONTS functionality.

For SMTP management,  consider replacing references to the system partition (usually c:inetpubmailroot) and place on your data drive. Do this by opening up the metabase file and do a search/replace. You will want to copy the directory structure as well.

FTP services aren't much different than in IIS 5 except for the new feature for isolated FTP sites. Be certain you use the option "Do not isolate users". Otherwise you'll generate a "Home directory inaccessible" error message when logging into the site.

IIS 5 to IIS 6 Migration

Physically moving Web sites from server to server can vary greatly between organizations. Consequently, it's difficult to detail every step. Most migrations involve three main areas: IIS settings, data, and intangibles. The first two areas are straightforward while the last deals with any specialized setting/service that may also need to run on the new servers. This could encompass anything from COM components to custom Windows services.

Depending on the number of Web sites and their inherent application setting complexities, you will have to decide on moving IIS settings manually or in an automated fashion. "Manually" is characterized simply by recreating the Web site(s) in IIS manager with the possibility of referencing a metabase dump (check out absutil.vbs). The automated route involves using a tool like the IIS 6 Migration tool (download here). You may even take it a step further and write a batch utility to move all the Web sites at once. An automated, single Web site migration is detailed as follows.

The IIS 6 migration tool (IISMT) allows you to migrate a Web site from an IIS 5 server to IIS 6. This command-line tool runs off the destination IIS 6 machine. If you take a peek at documentation associated with the download, you'll notice a number of options. Most significant are the options for:

  • "Web site/W3SVC" - Name of site identifier of old source Web site
  • server_binding - String containing new IP address, port, host header (e.g. )
  • site_id - Usually a random 9 or 10 digit number (can use http://www.winguides.com/security/password.php to generate ID). If created in IIS, the site ID is fashioned after the name of the Web site (IIS 6 no longer uses auto identifiers as a security precaution)
  • configonly - Moves only IIS settings, not Web site data

Running IISMT while moving data is the default behavior, but it also moves ACL's. Although this may be desirable, local groups are moved, which can result in broken SID's on the destination machine. If this applies to you, opt to move data by a simple xcopy:

xcopy \targete$inetpubsitesdomain.com e:inetpubsitesdomain.com /E /H /Y

Alternatively, the Microsoft SubInAcl command-line tool can work to replace/delete SID's. Or even a more power utility SetACL (available at http://setacl.sourceforge.net). This tool is superior to CACLS/XCACLS and doesn't suffer from the inheritance bug (http://support.microsoft.com/?id=834721)

Putting It All Together

Now that I've described some of the concepts and tools required of a load balanced environment, let's expound on the earlier example of hosting five Web sites. Imagine they currently reside on a single, shared IIS 5 server and must be moved. The following table lists the fake source Web site information:

Domain W3SVC # IP Address Document Root
www.domain1.com 1 e:inetpubsiteswww.domain1.comwwwroot
www.domain2.com 2 e:inetpubsiteswww.domain2.comwwwroot
www.domain3.com 3 e:inetpubsiteswww.domain3.comwwwroot
www.domain4.com 4 e:inetpubsiteswww.domain4.comwwwroot
www.domain5.com 5 e:inetpubsiteswww.domain5.comwwwroot
OLDIIS - Host info

With this information in hand, it's time to start moving IIS settings and data! Start by logging into the primary IIS 6 server (PRODIIS1 in this example). Now follow these steps for each site, substituting the correct source and destination info (www.domain1.com used below)

  1. iismt OLDIIS w3svc/1 /path "e:inetpubsitesdomain1.comwwwroot" /serverbindings /siteid 842798180 /overwrite /configonly

    * Make sure /siteid value is unique for each Web site. To generate ID use link provided earlier

  2. Copy data off target server like so:

    xcopy \OLDIISe$inetpubsitesdomain1.com e:inetpubsitesdomain1.com /E /H /Y

  3. Run IIS sync batch command from PRODIIS1

  4. Set any ACL's if need be on all servers in the Web farm. I recommend creating another batch file to ACL common routines such as setting basic authentication. I've provided such a sample in the article download.


Some tips for load balancing and IIS 6:

  • Use standard internal IP naming conventions
  • Increase upload limit for ASP application by setting the property AspMaxRequestEntityAllowed in the IIS metabase. Default value is a measly 200k
  • In IIS manager under the configuration button, enable parent paths so your SSI calls work with relative pathing
  • If you use a local IUSR account for anonymous users, rename it so that it isn't machine specific (e.g. IUSR_PRODUCTION instead of IUSR_PRODIIS1). Same goes for the IWAM account
  • Ensure that your machine.config files on each server match
  • Create a static machineKey element in the machine.config file. Refer to KB article (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312906) to create validation and decryption keys
  • If you encounter an ASP.net error saying something like "Access denied to 'E:inetpubsitesdomain1.comwwwrootadminweb.config'. Failed to start monitoring file changes". Add the "NT AUTHORITYNETWORK SERVICE" account to the directory in question
  • Files that are writable by an application should be placed in separate directory so that permissions can be granted on the directory rather than individual files. Otherwise the data synchronization service will wipe out ACL information
  • Create separate application pools for Web sites with direct FTP access or those have they extensive programming. Logically name these pools too (e.g. app.domain1.com)

About the Author

Gregg Faus, MCAD.Net, is a Senior Web Software Engineer for Company 39 / Parsons Brinckerhoff. He works with a breadth of technologies including ASP.Net, C#, SQL Server, Flash, and Content Management Systems using Interwoven.

This article was originally published on 15 Seconds.

This article was originally published on Mar 30, 2006
Page 2 of 2

Thanks for your registration, follow us on our social networks to keep up-to-date