Why does IIS say "Address in Use" when I run Direct Web Service Mode?
Why does IIS say "Address in Use" when I run Direct Web Service Mode?
Question:
Windows NT Server versions 3.51, 4.0, 2000
I have set up Web Crossing to run in Direct Web Service Mode. It is properly set to bind to it's own IP number and Port (80), however all (some) of the web sites served by IIS are stopped. When I try to start them the error returned is "Address Already In Use". Event log messages may state something like "The service could not bind instance 1. The data is the error code."
Why does Web Crossing do this?
Actually this is a problem with IIS and not Web Crossing. When IIS starts up, in some case it apparently first tries to bind ALL available IPs, and then gets to actually listening only on the specific IP #s assigned to the various web sites as assigned in the ISM. If any of the machine's IPs are already bound, IIS halts.
Example, assuming a normal web port of 80:
You can see this by performing a "netstat -an" from the command prompt while web crossing is running, but IIS is down. You will note that Web Crossing is in fact binding only the IP:port assigned to it (there is no entry of 0.0.0.0:80 [exception would be if a web site did manage to start up first before Web Crossing], where any 0.0.0.0 listing means "all IPs", there is only the assigned IP:80...example: 10.0.0.8:80). If you shut down Web Crossing then start IIS and perform the same command, you see that IIS actually is listening on all IPs (this is evident by the entry 0.0.0.0:80).
So to sum up, IIS is incorrectly listening to all IP#s when it starts, and because of the way Windows loads services, Web Crossing generally gets loaded before IIS does. When Web Crossing binds its IP, IIS isn't happy about
Answer:
Delay the start of the Web Crossing Service by making it Depend on the World Wide Web Publishing Service being up first.
The following solution requires editing the registry. Web Crossing Inc. takes no responsibility for problems introduced by editing the registry. This information is from the following Microsoft Knowledge base article Q1933888. Microsoft frequently moves their site's links around, so you may need to specifically search for this article on their site should the above link be out of date.
It is your responsibility to read the above referenced article and fully understand what you are doing.
Start your registry editor (regedt32)
Locate the following registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Service name>, where <Service name> is the name of your Web Crossing Service (default is webx).
To create a new dependency, select the subkey representing the Web Crossing service you want to delay, click Edit, and then click Add Value. Create a new value name "DependOnService" (without the quotation marks) with a data type of REG_MULTI_SZ, and then click OK. When the Data dialog box appears, type the name of the World Wide Web Publishing Service ("W3SVC") then click OK.
Locate your Web Crossing root directory. Edit "webx.set" and make sure the "webPort=xxxxx:PP" says your IP:port (ex: webPort=12.34.56.78:80).
Reboot. You must reboot! When the computer starts, it uses this entry to verify that the W3SVC service is started before attempting to start the dependent (webx) service.
Note (for early builds of 4.0, and versions prior to 4.0) : if Web Crossing appears to not respond, it's usually because of some combination of the presence of a webPort *file* in your Web Crossing directory and/or incorrect webPort= entry in webx.set. Delete the webport file if it exists. Verify webx.set. Do not start/stop with the Configuration Panel (earlier versions of Web Crossing's Configuration Panel incorrectly wrote a webport file which was required for eariler web crossing versions. Sometimes this causes an interference. If everything is running a-OK, and this file exists, it is OK to leave it there). Reboot. If Web Crossing still does not respond, verify the HTTP Server Tab settings in the Configuration Panel. In most cases on "80" for the port and BLANK for the IP is sufficient. If you change these settings to reflect this, you may need to redo the webx.set file and reboot again. This can be frustrating, but fiddling with webx.set and webPort and the Configuration Panel will eventually get the correct combo and sequence of events to get over this IIS hump.