One of the ways we fixed this sort of issue was to change the registry key
pertaining to how the client talks to the Exchange server on each WS with a
registry file as follows :
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider]
"Rpc_Binding_Order"="ncacn_ip_tcp"
This ensures that the communication is IP based only.
Speeds things up very nicely.
Just copy that into a file with a .reg extension and it'll work.
Mike
> -----Original Message-----
> From: Ian Campbell [SMTP:[EMAIL PROTECTED]]
> Sent: � ������ 31 2000 8:03
> To: '[EMAIL PROTECTED]'
> Subject: RE: [FW1] MS Exchange 5.5 to work with Checkpoint 2000
>
>
> John,
>
>
>
> I'll comment briefly on what I see here. It sounds to me like your problem
> is name resolution:
>
> <<My clients are all Win9x and log onto the PDC (which is the exchange
> server) on
>
> a local RFC 1918 subnet (192.168.x.x). There is no DNS or WINS, but
> Exchange
>
> works fine in this environment (through SMB broadcasting I'm guessing?)>>
>
> This works because without WINS you're probably broadcasting for NetBIOS
> name resolution. Those broadcasts are dropped at the router before they
> ever
> hit your other subnet. Exchange will require NetBIOS name resolution to
> function. If you're running Exchange, you should be running WINS, so I'd
> setup a WINS in both your subnets, and have them replicate. Or (bad), you
> can simply point the machines in the subnet without a WINS to the WINS in
> the other net.
>
> <<Another complicating issue is that many of the VPN users (on the
> separate
>
> subnet) have their own WINS servers specified by DHCP. Does this render
>
> lmhosts.sam useless?>>
>
> Maybe; if the machines are configured for WINS, they'll probably be
> H-nodes,
> which will check a WINS before using hosts or lmhosts. For NetBIOS name
> resolution order in NT4 with H-node clients, just remember Cows With Big
> Lips Have Drool (CWBLHD):
>
> Cache (local)
>
> Wins
>
> Broadcast
>
> Lmhosts
>
> Hosts
>
> DNS
>
> Also, it should be noted that you must remove the .sam extension from the
> hosts of lmhosts file; the .sam just stands for 'sample'. ;-)
>
> <<The Exchange server is already kinda schizophrenic, because it is
> proxied
>
> to the outside world via FW-1's static NAT. Thus Exchange thinks it is
>
> mail.ourdomain.com (valid) while MS tcp/ip says its 192.168.a.b.>>
>
> This shouldn't be a problem; that's Checkpoint's job. A little risky to do
> this though. Should have a proper DMZ...
>
> <<Basically the question is,
>
> since the users are already logging onto one domain, with its own WINS
> servers,
>
> can they ever access this Exchange server, in another domain (with no WINS
>
> servers)? If I specify to log onto the Exchange server's domain in Win9x,
> will
>
> Windows ever know how to log onto it (since the PDC can only be looked up
> in
>
> lmhosts.sam and WINS is specified in DHCP)?>>
>
> If I understand correctly, your remote users are only connecting to the
> domain\subnet that has the WINS, which is connected by an FW1 encryption
> tunnel of some type to the 192.168.x.x net, and they can't resolve the
> NetBIOS name of the Exchange server on that net. The easy solution to this
> problem is to configure the DHCP server on the 192.168.x.x net to
> configure
> clients as H-node, and point their WINS server to the one you have (on the
> other subnet). This will work, but think hard about adding a WINS to the
> subnet without one; your Exchange server causes plenty of traffic, so for
> bandwidth and redundancy's sake, running a WINS there and replicating them
> is just a good thing to do in an MS network if it gets to any size. HTH,
>
>
>
> Ian
>
>
>
> ==========================================================================
> ======
> To unsubscribe from this mailing list, please see the instructions at
> http://www.checkpoint.com/services/mailing.html
> ==========================================================================
> ======
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
