(Todd, sorry about the late response--I missed your
post to the list and happened to see it in the
archive.)
Congratulations! Glad myself and others could be of
some help in your success!
I've been wondering why Imail is the ONLY app flummoxed
by certain high-end NICS, and then only on Win2000
machines. I haven't done any serious coding in 20
years, so I will have to leave it to people far wiser
than myself to figure out if these observations relate
at all:
1. If I understand correctly, W2K's I/O Manager
apparently handles integrated systemboard devices
during startup differently than the devices found on
the PCI bus. Perhaps this is why I had to disable the
NIC in the BIOS to completely fix the issue. Not sure
exactly why mind you, but it may be a starting point
for further investigation.
2. Windows 2000 made significant revisions and
enhancements in I/O processing and thread handling.
Perhaps the way W2K now handles certain Imail calls
"behind the scenes" brings out a nascent timing issue
in some poorly-written Imail code--and then only in the
presence of a very fast bus/processor/NIC.
3. The above assumes that Imail code is not taking any
"shortcuts" in the way it handles I/O. This is
speculation, but I now suspect that the programming
team is being forced to patch an ageing core codebase
that has deep structural flaws dating back to the
original 1996 release. Evidence? Try Imail's continuing
inability to associate a socket to a specific local IP
address--and this in a $1000 program marketed in 2003!
This "let's bind to all IP's" silliness is simply
intolerable--especially on busy multi-site webservers
and dual-homed boxes. For users, it contributes to
WebMail often being slow and glitchy while the iwebmsg
server inanely responds on the wrong local interface.
So if it's not some gawd-knows-what structural
limitation leftover from Imail's programming roots, why
doesn't Ipswitch simply use SOCKADDR data with BIND and
fix this serious issue once and for all? After years of
deafening silence on the subject, the only conclusion
we're left with is that they CAN'T--without rewriting
most of the code. I sincerely hope Ipswitch can and
will prove me wrong on this point, but I doubt it.
All that being said, I'm still eagerly looking forward
to whatever incremental improvements and fixes are
slated for 7.14. (And hopefully a COMPLETE rewrite for
8.0--including native IPv6 support.) But if Ipswitch
doesn't address some of these absurdly longstanding
issues SOON, I'm done recommending Imail--and any
non-Exchange mail servers I build for clients in the
future will likely be Linux-based.
Todd, congrats again on successfully making Imail
behave in a fast W2K environment--and for sparking
several VERY interesting threads!
Best Regards,
Dev
--------------
Dev Anand MCSE,CCNA,A+
Network Manager
Biomorphic VLSI, Inc.
Westlake Village, CA 91362
dev_at_biomorphic_dot_com
pcpro_at_vcnet_dot_com
Thursday, December 19, 2002, 5:06:52 AM, you wrote:
TR> Folks,
TR> I have successfully gotten my mail upgraded to Windows 2000. I followed
TR> Dev's suggestions and everything is working fine now. I am not 100% sure
TR> that I would have had the problem after the upgrade, however. Originally
TR> when I encountered this problem, I move IMail from an NT4 BDC (Dell
TR> Poweredge 1400 866Mhz, Intel Pro100s) to a Windows 2000 DC (Dell PowerEdge
TR> 2550 1Ghz, Intel Pro100s, BroadComm Gig) as a temporary step while I rebuilt
TR> the original mail server as Win2000. But I never got that far because it
TR> ran like crap on the 2550. That's when this whole thread started.
TR> Because of installing IMail, removing IMail, enabling NICs, disabling NICs,
TR> adding different NICs, and a few other domain related issues, I had serious
TR> AD replication problems that took a lengthy phone call (5.5 hours) to
TR> Microsoft to clean up. So I decided that I will NOT experiment on my live
TR> 2000 domain to get IMail working.
TR> Soooo...what I finally did was to build a second NT BDC and temporarily move
TR> mail to it. Then I wiped the original mail server, put in a 3C905C,
TR> disabled the onboard Intel NIC in the bios, built it as 2000 (member
TR> server), installed IMail and tested. Seemed to run OK. Waited a few days
TR> to see how it ran. Once I was satisfied, I promoted it to a DC and again
TR> watched for problems. Still OK. This morning I moved the mail to it and
TR> downed the old NT4 box. So far so good. IMail is once again screaming but
TR> this time on 2000. No more NT! Yippee!!
TR> It kinda bothers me that I won't really know what fixed the problem since I
TR> am not running IMail on the same machine I where I originally had problems.
TR> But I don't want to jeopardize my domain by testing on that machine. But
TR> it's now working and I am pretty confident that disabling the Intel NIC in
TR> hardware and installing the 3c905c is what made it work. And that probably
TR> would have worked on the 2550 as well.
TR> Many thanks to Dev and everyone else who invested significant amounts of
TR> time and brainpower on this one. I would still like to hear from others who
TR> had the same problem and if these steps took care of it.
TR> Thanks everyone! This group of folks is an incredible resource!
TR> --Todd.
TR> ----- Original Message -----
TR> From: "Dev" <[EMAIL PROTECTED]>
TR> To: <[EMAIL PROTECTED]>
TR> Sent: Wednesday, December 11, 2002 1:32 PM
TR> Subject: [IMail Forum] FIXED! Imail SLOW When Running On Fast W2K Hardware
>>
>> Hopefully the following may be of some help to others.
>>
>> I had a similar problem as Todd. Here is a part of his
>> thread:
>>
>> http://www.mail-archive.com/[email protected]/msg59929.html
>>
>> In my case, an existing NT4 Imail installation was
>> moved to a new, very fast (P4-2.4GHz/512MB) Dell
>> PowerEdge running W2K, hardware RAID, Imail 7.13, and
>> KWM 3.0.
>>
>> The result? We had inexplicably slow logins, flaky mail
>> downloads, GLACIAL webmail, and random SMTP/POP
>> hangs--and all with CPU utilization near ZERO. Oh yeah,
>> and a lot of ticked-off users!!
>>
>> Anyway, after a week of debugging, hardware swapping,
>> cloned testbeds, performance logging, and analyzing
>> over 200 MB of packet captures, I now have it humming
>> along quite nicely, thank you.
>>
>> The usual caveat here: The following fixes worked for
>> me, your mileage may vary. :)
>>
>>
>> 1. My dual-homed Dell server was equipped with an Intel
>> Gigabit ethernet integrated into the motherboard, along
>> with an Intel Pro100/S NIC. I noticed in a post that
>> Todd extracted from Ipswitch TechSupp the stunning
>> admission that Imail is incompetent at reliably
>> communicating with two popular server adapters:
>>
>> http://www.mail-archive.com/[email protected]/msg59332.html
>>
>> Guess what? Tech support is right. My tests showed that
>> Imail would randomly just stop communicating for
>> varying periods of time over these two adapters. This
>> particular "going into limbo" issue was resolved by
>> replacing them with two 3C905C's.
>>
>> Note that to fully eliminate this issue, it was
>> necessary to completely DISABLE the onboard Gigabit
>> Ethernet adapter in the server's CMOS setup. The second
>> Intel Pro adapter card was also physically removed from
>> the box.
>>
>> ISSUE SUMMARY: No fast, server-quality NICs are allowed
>> within sight of an Imail box. Ipswitch apparently wants
>> us to continue running the latest 1998-era hardware. :)
>>
>>
>> 2. Packet captures indicated that Imail did not like
>> operating over a NIC with more than one IP address
>> assigned to it. This may be somehow related to the
>> Imail programming blunder of binding to all IP address.
>> Inexplicably, the speed of the machine may also play a
>> role, since an identical multiple IP setup cloned to a
>> P2/266 had no such Alzheimer's issues. And yes, the
>> Imail address WAS the primary IP. The fact is that
>> removing the second IP on this P4 made a HUGE
>> difference in Webmail stability and speed. It doesn't
>> make sense, but as I said, YMMV.
>>
>> ISSUE SUMMARY: Only one IP address per NIC on a Pentium
>> 4 box running Imail.
>>
>>
>> 3. Once the above was sorted out (users--especially
>> WebMail--noticed a HUGE difference in performance and
>> reliability with the two fixes above), there was still
>> a mysterious 1.5 - 6 second delay on some incoming SMTP
>> and POP sessions.
>>
>> The cause? In this case, it was NetBIOS name lookups
>> timing out.
>>
>> To verify the problem, look for this unanswered NBT
>> query request string in your packet
>> captures: "*<00...(15)>"
>>
>> Without getting too involved in the machinations of
>> NetBIOS or of our internal network and firewall layout,
>> basically Windows 2000 (or perhaps a 'getHostAddress()'
>> call by Imail) was insisting on performing an
>> unnecessary reverse lookup (computer name from IP
>> address) on the incoming connection. It was sending a
>> node status request directly to the perceived
>> source--my NAT Public IP address (the equivalent of a
>> "nbtstat -A <ip_address>").
>>
>> The irony? After NetBIOS repeatedly times out and
>> finally gives up trying to resolve the name, W2K then
>> simply ignores the timeout and successfully proceeds
>> with the SMTP/POP connection! Sheeesh!
>>
>> The solution? If the NetBIOS query can't be resolved
>> with properly configured WINS/DNS, go into the HOSTS
>> file (systemroot\winnt\system32\drivers\etc\) on your
>> Imail box and give the IP address query that is timing
>> out a name to satisfy the lookup. In my case (failing
>> to resolve the NAT Public IP), this is what it looks
>> like:
>>
>>
>> 127.0.0.1 localhost #existing entry
>> ... ... #more existing entries
>> 207.178.203.99 anyname.mydomainname.com #BINGO!
>>
>>
>> Note that the NetBIOS timeout issue was not present on
>> an otherwise identically configured NT4 box.
>>
>> ISSUE SUMMARY: Look for unexplained response delays of
>> multiples of 1.5 seconds. If you have them, sniff the
>> wire (make sure to check ALL interfaces on multi-homed
>> boxes!) for unresolved NetBIOS queries. If necessary,
>> simply create a suitable Hosts file entry to make
>> Windows happy!
>>
>> By the way, the Hosts file is checked every time name
>> resolution is attempted. Changes in it take effect
>> immediately and do NOT require a reboot!
>>
>> As I said, the box absolutely rocks now. I don't claim
>> to know why some of these fixes worked, just that they
>> did. Perhaps this will provide a helpful starting point
>> to others facing similar inexplicable slowdowns.
>>
>> Cheers,
>>
>> Dev
>>
>> --------------
>> Dev Anand, MCSE,CCNA,A+
>> Network Manager
>> Biomorphic VLSI, Inc.
>> Westlake Village, CA 91362
>> dev_at_biomorphic_dot_com
>> pcpro_at_vcnet_dot_com
>>
>>
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
