In-Depth

An Intrinsic Problem

How not to communicate with a Web server.

• By Raymond Garvey
• 10/01/2003

One of the servers being upgraded was the last in a line of six servers making a COM call that originated on the Web server. The Web server’s COM object would make a call to a COM proxy on itself, which would point it through a firewall to the first application server in the chain. That server would, in turn, call a proxy on itself that would point to another server and so on, until the last server was reached and the call would fail.

I could see that the object was being activated on the last server, but the application Event Log showed an error that the COM object could not be instantiated. I was pretty sure that the problem was permission related and that it was somewhere between the fifth and sixth servers.

After checking that permissions were in order, I wrote a simple Visual Basic program that would just make a call to verify communications between the two servers. I packaged it in a COM object and ran a test. I quietly hoped that it would fail, thus verifying that the problem was between servers five and six. But the test was successful, and I got more confused and hungry.

So, while eating my cold vending machine meatball sandwich (the mic- rowave was broken and only had the ability to make warm water if you had 15 minutes to spare), I came up with a strategy: First, I’d set up identical local users on each box, then configure roles in COM+ on each server to ascertain if I was having domain-related permissions problems. My efforts were in vain, though, as that test was also unsuccessful.

Now, five hours had passed. I was considering backing out of the upgrade and taking an antacid. (That meatball sandwich had hit me pretty hard.) I decided to take one more shot at it and telephoned the networking chap on call that night. The chap turned out to be a woman, and she wasn’t amused by my “If-I’m-up-everyone-should-be-up” crack.

After allowing several minutes for her to wake up, I asked if she’d take a look at the switches and check for communication errors. A half-hour later she called back. She couldn’t see any errors on the switches, but there was an error logged on the inside firewall indicating that server No. 6 was trying to communicate with a Web server.

Now I was both completely bewildered and nauseous (continuing effects of the cold meatball sandwich). The only opening in the firewall was between the Web server and the first application server, because they were the only ones that communicated directly. After some serious (and demoralizing) begging on my part, I convinced her to open a second hole in the firewall for server No. 6. I tested the application again and was completely blown away when the COM call went through with no problem. I completed the upgrade and went home to get some much-needed sleep, still extremely perplexed about the resolution.

The next morning, I called Microsoft for an explanation. Once I was referred to the right department, a helpful technician informed me that, indeed, the sixth server did need to converse with the Web server. He explained that IIS intrinsics were set to On (which they are by default), and that was causing the last server in a chain of COM calls to verify the existence of the call’s originator—in this case, the Web server. When I asked how I could disable this pesky setting, he e-mailed a VBS script that allows you to shut off intrinsics for all components, or just certain ones. Since that happened, I’ve always insisted that the firewalls in Quality Assurance be configured with the same settings as production, lest I spend another sleepless night debugging an obscure Microsoft feature and eating foul meatball sandwiches.