Multiple Web Sites on One Machine

Installing the Internet Information Services (IIS) gets you a Default Web Site. This is a fully functional web server. It can be accessed from the same machine using the URL http://localhost and from all machines on the intranet using http://computername. With a DNS server or just a HOSTS file, you can expose the Default Web Site across your intranet under any domain names that you care to invent. You can even expose it to the actual Internet.

IIS allows for more than just the Default Web Site. Of course, each additional web site (also called a virtual web server) must have a unique identity on the network. Short of getting multiple IP addresses for the one machine or of expecting users to include a port number in the URL, this means that each different web site has its own host header name.

In Windows Server 2003 and Windows 2000 Server, creating additional web sites is important enough to warrant user-interface support in the Internet Information Services (IIS) Manager:

New Web Site Menu in Windows Server 2003

The selected menu invokes a Web Site Creation Wizard which takes you through a series of property sheet pages:

It really couldn’t be much easier, but for those who don’t already know what to do, the Help Topics for the IIS Manager have several relevant pages, including a section that is titled Hosting Multiple Web Sites on a Single Server.


This user-interface support is not present in Windows XP and Windows 2000 Professional. The context menu for the Web Sites folder has nothing for creating a new web site. Indeed, it has no submenu for making a New anything:

No New Menu in Windows XP

The product documentation, which is found in these versions by browsing the Default Web Site (specifically in a virtual directory named IISHelp), says not exactly unambiguously that the product is limited to one web site. For instance, under Frequently Asked Questions, the whole answer to “How do I create multiple Web sites?” is:

Windows XP Professional with IIS can host one Web site and one FTP site on a single computer. If you would like to host multiple Web sites or FTP sites on a single computer, consider upgrading to a Windows server product.

Yet many pages in the product documentation are written as if multiple web sites can exist, e.g., because grammar suggests that the reader may have a choice of web sites to operate on. One page of the product documentation even presents the syntax of an administration script, named MKW3SITE.VBS, for creating a web site.


In fact, the Windows client products such as Windows XP and Windows 2000 Professional are not constrained to having just the one web site. The only constraint is that at most one web site may be running at any one time. If you know how, you can create as many web sites as you want. What you can’t do is use them simultaneously.

This article addresses both issues. The means of creating a web site are obscured, but the user-interface support is actually present in the executables and can be restored. Being unable to start a second web site without stopping the first can also be patched away.

Creating a Web Site

That IIS allows creation of multiple web sites on the client products is really no secret. That the documentation has a page for the MKW3SITE script may look like an editing oversight for Windows XP, given that no such script is supplied with the product, but it’s no oversight for Windows 2000 Professional. The MKW3SITE script is included with Windows 2000 Professional and it works. For Windows XP, with no MKW3SITE script, you can get the same effect from several executions of the more general ADSUTIL, first to create the web site and then to set its properties.

For most users, these scripts would probably be enough facility. It’s more cumbersome than you might like, but you take what you can get. Microsoft apparently does not want its customers hosting multiple servers without upgrading to a server product, and Microsoft certainly has removed all plain-language encouragement, but at least the feature remains and at least it’s not buried in anything more obscure than a script. If you want the details, read the script.

The interest here is instead with the realisation that all the resources that are needed for the user-interface support, i.e., for the New Web Site menu and for the property sheets of the Web Site Creation Wizard, are present in the client versions of INETMGR.DLL and so too is all the code that supports this user interface. It just doesn’t run, but perhaps it can be made to. Then, the context menu for the Web Sites folder would have a submenu named New, from which you could create a new web site easily and naturally:

New Web Site Menu in Windows XP

It turns out that Microsoft has defined a set of what are apparently called server capabilities. These are determined by INFOCOMM.DLL, running in the INETINFO.EXE process, and are set into the IIS metabase as an undocumented entry (specifically, with the identifier 1103). The value is a dword of bit flags. INFOCOMM has hard-coded values for different combinations of platform and product type:

platform is NT and product type is either domain controller or server 0x00013BBF
other product type on NT platform 0x00013162
anything else 0x00000062

Only one variation to this hard-coded initialisation is known: the 0x0400 bit is added if the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\FrontPage\3.0 can be opened for read access.

The capabilities bit that permits INETMGR to show the New menu for Web Sites and FTP Sites is 0x80. Restoring the New Web Site menu is therefore a matter of either:

Both work. Patching INETMGR was what I did for my own purposes in January 2007 (when building a new website from the contents of another), but I think on reflection that patching INFOCOMM is better.

Patching INFOCOMM for the New Web Site Menu

In all the INFOCOMM versions listed below, the hard-coded value that must change is 0x00013162 and the instance that is wanted is in an instruction that has either of the following forms:

Opcode Bytes Instruction
C7 45 xx 62 31 01 00 
mov     dword ptr [ebp-d8],00013162h 
C7 85 xx xx xx xx 62 31 01 00 
mov     dword ptr [ebp-d32],00013162h 

Whether the instruction has an 8-bit or 32-bit displacement, only the one byte of immediate data has to change, from 0x62 to 0xE2:

INFOCOMM.DLL Version Package File Offset
5.0.2185.1 Windows 2000 0x0001C0D0
5.0.2195.1600 Windows 2000 SP1 0x00015BCB
5.0.2195.4430 Windows 2000 SP2 0x00017E5E
5.0.2195.5437 Windows 2000 SP3 0x00018123
5.0.2195.6709 Windows 2000 SP4 0x00017B99
6.0.2600.1 Windows XP 0x00014AC6
6.0.2600.1106 Windows XP SP1 0x00014B24
6.0.2600.2180 Windows XP SP2 0x00015D88
6.0.2600.5512 Windows XP SP3 0x00015D28
6.0.3790.0 Windows Server 2003 0x000141DD
6.0.3790.1830 Windows Server 2003 SP1 0x00014E29
6.0.3790.3959 Windows Server 2003 SP2 0x00014A4D

Of course, the patch is of no value if you are running a server edition of Windows, but I include locations for Windows Server 2003 because Windows XP and Windows Server 2003 have the same major and minor version numbers for INFOCOMM and it does not seem impossible to me that an INFOCOMM intended for Windows Server 2003 will end up running on at least some installations of Windows XP.

If you are not completely certain how to interpret file offsets, to check the bytes and to edit them, then do not try to patch the file. Even if you think you know what you are doing, please take care to work on a copy. Use some command such as fc /b to compare your patched copy with the original, and verify that you have changed only the expected bytes.

Windows File Protection

Recent versions of Windows ordinarily protect sensitve executables from corruption, so that they are automatically restored from a cache (or from your installation media, which you may be asked to insert). You can disable this feature and copy your patched INFOCOMM.DLL to both the INETSRV directory and the cache, but I recommend strongly that you do not.

The best way to install a patched executable that is otherwise subject to Windows File Protection is to copy it into place using another operating system. If you do not already have another Windows installation in a multi-boot configuration, then boot the Recovery Console. This is available on your Windows installation media, but you might do well to install the Recovery Console onto your hard disk, as a multi-boot option. If you do not know how to work the Recovery Console and cannot make sense of Microsoft’s directions, e.g., in Windows Help and Support, then do not try using it.

Running Multiple Web Sites Simultaneously

As noted above, when Microsoft says that Windows client products such as Windows XP can host only one web site, the actual behaviour is that additional web sites are creatable but no more than one may be running at any one time. INFOCOMM.DLL has a class that represents any IIS service and this class has a member function that counts the running instances of that service. This function may fairly be represented in C++ as:

BOOL IIS_SERVICE :: RecordInstanceStart (VOID)
    LONG count = InterlockedIncrement (&m_Count);
    if (g_PlatformType != 2 && count > 1) {
        InterlockedDecrement (&m_Count);
        return FALSE;
    return TRUE;

in which 2 means that the platform is NT and the product type is domain controller or server. To allow that the count of running instances may exceed 1 is therefore a matter of defeating either of the tests. This is most easily done by changing the if block’s first jump from conditional to unconditional.

Patching INFOCOMM for Simultaneous Web Sites

In all but one of the known builds, the patch site is in the one occurrence of the following sequence:1

Opcode Bytes Instruction
83 3D xx xx xx xx 02 
74 xx 
83 F8 01 
7E xx 
cmp     dword ptr [variable],2 
je      @f 
cmp     eax,1 
jle     @f 

Only the one byte has to change: from 0x74 to 0xEB.

More generally, the patch site may be located easily since the RecordInstanceStart function is exported by name and is therefore readily found with a debugger or in a disassembly such as prepared by Microsoft’s DUMPBIN program. I recommend strongly that even for the builds in the following table, you should look for yourself to see that what you intend to patch actually is in the RecordInstanceStart function. If this is beyond your technical competence, then you ought perhaps not be patching executables.

INFOCOMM.DLL Version Package File Offset Remarks
5.0.2185.1 Windows 2000 0x00002F9B change 0F 85 to EB 04
5.0.2195.1600 Windows 2000 SP1 0x00015E72  
5.0.2195.4430 Windows 2000 SP2 0x00018105  
5.0.2195.5437 Windows 2000 SP3 0x000183CA  
5.0.2195.6709 Windows 2000 SP4 0x00017E40  
6.0.2600.1 Windows XP 0x00013E9A  
6.0.2600.1106 Windows XP SP1 0x00013EF8  
6.0.2600.2180 Windows XP SP2 0x0001509C  
6.0.2600.5512 Windows XP SP3 0x0001503C  
6.0.3790.0 Windows Server 2003 0x000135B8  
6.0.3790.1830 Windows Server 2003 SP1 0x00014168  
6.0.3790.3959 Windows Server 2003 SP2 0x00013D8C  


With two bytes changed in one executable, it becomes possible to create multiple web sites on Windows XP or Windows 2000 Professional and to have them all running simultaneously:

Multiple Web Sites on Windows XP All Running

But are you permitted, whether by a supposed agreement with Microsoft or by the law of the land, to edit Microsoft’s executables for such an effect? And am I permitted to tell you how?

At this website, there are a few other pages that direct you to patch an executable in order to fix a bug, especially a bug that Microsoft does not acknowledge or will fix for you only by the time-honoured abuse of leaving you to upgrade Windows (for a fee, of course). See for instance Missing Icons in Notification Area. On no such page do I mean to convey the slightest sense that the obstacles to fixing a fault by patching an executable are anything other than technical. I don’t begin to know what might guide a court, but I would find it incredibly perverse that a product can be sold with an enforceable prohibition on fixing its faults (or anything that the purchaser reasonably considers to be a fault).

The patching on this page is quite different. There is no bug to correct. Instead, means are found to enable a feature which Microsoft chose to disable in (but not remove from) some of Microsoft’s products. Not incidentally, the products in which the feature is disabled sell for (markedly) less than the products in which the feature is enabled. In uncovering the feature, there is an element of taking something that has not been paid for. Yet you don’t have to browse much of this site to realise that if there’s nothing here about cracking software it’s not because of technical incapacity. It’s because cracking software is not what I do. So, why do I make an exception now for what is, really, only a small feature?

Microsoft’s documentation is far from unambiguous that the feature is disabled in the affected versions. The terms of the so-called licence agreement do not explicitly limit the number of simultaneously running web sites. Some text in the IIS documentation says something about hosting only one web site, yet Microsoft itself supplies a script (or two, depending on the product version) that will create extra web sites. Where a search of product documentation, the MSDN Library or Microsoft’s website finds pages that talk of creating web sites but do not list Windows XP among the applicable products, how is any reader to know whether this is just another of Microsoft’s all-too-typical oversights. After all, some of these pages, presumably just from being old, don’t list Windows Server 2003 either. Some other pages that do list Windows XP as an applicable product talk as if the user may have a choice of web sites, such that it’s only inevitable that readers may then waste time wondering how to create more web sites. A sprinkling of asterisks for fine print along the lines of “not available on X, Y and Z models” is a familiar sight in manuals for washing machines, and even of much lowlier consumer goods, but is apparently too much trouble for Microsoft.

So, in case it’s not clear yet, let me stress: had Microsoft stated plainly, clearly and unambiguously that IIS in Windows XP is not licensed to host more than one website, then this article would not exist.

If you think it unethical to patch away a check for the product type or to patch in a different hard-coded default, then don’t apply the patch. I don’t mean to encourage you one way or the other, but I do mean to encourage you to think about the games that software manufacturers play with you—and to begin that thinking, you need to know what those games include.

[1] I am grateful to Alan Feldman for pointing out to me that the JE and JLE instructions had been given incorrectly as JNE and JL. What sort of editing mistake produced that, I can’t think, and I am now in fear that the reason many similar, or worse, mistakes are not discovered every other day is just that nobody cares enough to tell me.