Call the file anything you want.

I meant by copy, as in cut and paste, or copy and paste into a txt file with
a .reg extension.

Then double click the file to have it ipmort into the WS.

And the key works on 9X or NT (It hasn't been tested for Outlook 2000 tho).

Mike

> -----Original Message-----
> From: John Hovell [SMTP:[EMAIL PROTECTED]]
> Sent: � ������ 31 2000 10:05
> To:   Mike Glassman - Admin
> Subject:      Re: [FW1] MS Exchange 5.5 to work with Checkpoint 2000
> 
> Mike --
> 
> You are a genius... Does that work with Win 9x kernels as well?
> 
> By "copying into a .reg file"... is there a particular one I should copy
> this into, or use regedit to do it?
> 
> Thanks!
> 
> Cheers,
> John
> 
> 
> ----- Original Message -----
> From: "Mike Glassman - Admin" <[EMAIL PROTECTED]>
> To: "'fw-1 listserv'" <[EMAIL PROTECTED]>
> Sent: Thursday, August 31, 2000 1:54 AM
> Subject: RE: [FW1] MS Exchange 5.5 to work with Checkpoint 2000
> 
> 
> >
> >
> > 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
> >
> ==========================================================================
> ==
> ====
> >


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================

Reply via email to