|
|
|
date: Mon, 19 Nov 2007 13:32:45 -0800,
group: microsoft.public.exchange.design
back
Re: RPC over HTTPs for *all* clients?
On Mon, 19 Nov 2007 13:32:45 -0800, "Stephen"
wrote:
>Hello,
>
>We have an Exchange 2003 Front-end/Back-end configuration. We want to
>enforce a requirement that all clients communicate using an encrypted
>protocol.
>
>On Exchange 2003 I don't think there is a way to 'enforce' this without
>installing ISA in front, and we don't want to do that. The current idea is
>to use RPC over HTTPs to connect to port 443 on our front-end server and not
>allow clients to connect directly to the stores.
>
>Pros:
>1) Encryption is enforced
>2) Backend stores have no direct client exposure
>3) Easy to implement, no significant change in topology/configuration
>
>Cons:
>1) Double the resource use
>2) difficult to debug as all traffic to store comes from same server
>3) Since front-end is publicly exposed on 443 all our clients could lose
>connectivity during a DoS attack.
>4) Double the dependencies (harder to patch, two points of failure)
>5) Loss of clustered backend fault tolerence (we don't do NLB on front-end)
>
>Beyond that, are there any technical reasons that we shouldn't do this? Can
>it scale to several thousand active connections, or is there a critical
>limit where everything might bog down and die?
>
>TIA
Using an FE/BE is the recommended solution anyway. The chance of an FE
going wrong is pretty low since it doesn't do a great deal. Sure,
you've got hardware dependencies but these days?? Nah, it'll be fine.
Heck, virtualise the FE if you want - it's even supported in certain
circumstances. The rest of your cons are pretty tenuous, if not bogus.
The FE is the right way, go for it.
date: Mon, 19 Nov 2007 18:03:19 -0500
author: Mark Arnold [MVP]
|
|
