Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsWindows Server 2003Windows 2000Windows NTSmall Business ServerVirtual ServerExchange ServerIISHost Integration ServerISA ServerSMSWSUSMOMWindows Media ServerSecurityCertification
Related Topics
SQL ServerMS WindowsMS OfficePC HardwareMore Topics ...

Windows Server Forum / Exchange Server / Design / October 2006

Tip: Looking for answers? Try searching our database.

Planning for a new 2003 setup

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Paul Kelly - 25 Oct 2006 13:49 GMT
We are a relatively small site: 350ish users, single NT4 domain, 1 PDC, 1
BDC, Single Exchange 5.5/NT4 server currently banging up against the 16Gb
store limit.

"Ordinary" users are configured with max 100Mb mailbox, about "Managers"
(bless them) have 200Mb each but over 50% users actually utilise more than
50% of their 100Mb capacity (usual story of a small number of users
constantly filling whatever you give to them whilst the majority read &
delete everything they receive).

Throughput is also relatively low in that we rarely exceed 75 inbound & 75
outbound SMTP emails an hour even at peak times. I don't (yet) have a handle
on internal email frequencies but again I expect them to be very low in
comparison to the sort of thing E2003 is capable of, even on a single
server.

BC requirements are generally really low (some bright spark seems to think
they can live without mailservers for 48hrs - can't see that getting through
to conception once the managers see it!) but I want room to manouvre in the
not too distant future. Clustering has been mentioned by a "consultant" at
one stage but I feel it's way overkill for their requirements (I already
manage a couple of clusters here so am well aware of the costs etc. of
them).

I'm looking to plan for an AD/Exchange migration and trying to understand
the options with FE/BE setups.

Initial requirement is to get over the mail store limits, so that means get
migrated/upgraded to AD and get an Exchange 2003 infrastructure in place.
However, I *know* that there *will* be a requirement for external (and
possibly internal) OWA and PDA access.

Current reading also indicates that, to be able to do anything more than
read Public Folders via OWA requires a FE server.

Other advantages I see are, if you have a FE/BE config, you can "seemlessly"
move users between BE servers (and presumably introduce new BE servers)
without any knowledge of the users (obviously except during the physical
move of a mailbox perhaps) as clients only ever access the FE server.

However, if a FE was hosted in the DMZ (we don't yet use reverse-proxying
although that might be investigated in future) would that be the same FE
server that we get clients to access internally, or would it be advised to
have a seperate internal FE server for internal clients?

How realistic, given the stated usage patterns, would it be to utilise the
likes of VMWare for FE & OWA servers/services, whilst utilising physical
servers for the BE/Mailbox servers?

We also need to look into the options re: Enterprise/Standard. 75Gb is
probably plenty, but I'm not keen on everything in one such large store due
to single point of failure for ALL malboxes, plus restore times for such a
large store. I'd probably prefer to use enterprise and split into multiple
25Gb stores or similar (possibly even smaller).

I've skimmed through a wad of MS documentation relating to FE/BE but all of
them imply either a single FE server or a DMZ-based proxy filtering back to
a single internal-based FE server, which I guess kind of gives a good
overall solution, but requires purchasing an ISA server /  software (we also
use SurfControl SMTP at the moment to pre-filter mails so that'd need to be
built in somewhere too.

Actually, for just this sort of use (no more than 20-30 simultaneous
external users peak load accessing email) would it be realistic to run ISA
on a decent VMWare host?

Any thoughts would be appreciated.

Paul
Simon Walsh - 25 Oct 2006 19:33 GMT
Some comments inline

/Simon

> We are a relatively small site: 350ish users, single NT4 domain, 1 PDC, 1
> BDC, Single Exchange 5.5/NT4 server currently banging up against the 16Gb
[quoted text clipped - 19 lines]
> requirements (I already manage a couple of clusters here so am well aware
> of the costs etc. of them).

Cluster definitely sounds like an overkill in this environment.

> I'm looking to plan for an AD/Exchange migration and trying to understand
> the options with FE/BE setups.
[quoted text clipped - 6 lines]
> Current reading also indicates that, to be able to do anything more than
> read Public Folders via OWA requires a FE server.

This is not true. A one server soultion can provide a fully functional
OWA/OMA and EAS experience.
(You may have some troubles with RPC/HTTP if you ever choose to use it in
the future.)

> Other advantages I see are, if you have a FE/BE config, you can
> "seemlessly" move users between BE servers (and presumably introduce new
> BE servers) without any knowledge of the users (obviously except during
> the physical move of a mailbox perhaps) as clients only ever access the FE
> server.

Quite right

> However, if a FE was hosted in the DMZ (we don't yet use reverse-proxying
> although that might be investigated in future) would that be the same FE
> server that we get clients to access internally, or would it be advised to
> have a seperate internal FE server for internal clients?

For the amount of traffic you are talking about it might be worth trying to
do it with the same serevr.

> How realistic, given the stated usage patterns, would it be to utilise the
> likes of VMWare for FE & OWA servers/services, whilst utilising physical
> servers for the BE/Mailbox servers?

We have lots of customers running FE servers as virtual machines. It works
just fine but it is a bit of a support grey zone from MS. Back Ends should
absolutely not be virtual machines.

> We also need to look into the options re: Enterprise/Standard. 75Gb is
> probably plenty, but I'm not keen on everything in one such large store
[quoted text clipped - 12 lines]
> external users peak load accessing email) would it be realistic to run ISA
> on a decent VMWare host?

That is also a possiblity but to be honest you might be just as well using a
single back end server. Then use FW NAT to open up port 443 to the BE server
for OWA.

> Any thoughts would be appreciated.
>
> Paul
Paul - 26 Oct 2006 12:13 GMT
> Some comments inline
>
[quoted text clipped - 41 lines]
> (You may have some troubles with RPC/HTTP if you ever choose to use it in
> the future.)

Interesting. I thought this was the case, but I'm basing my comment on the
following from
http://www.microsoft.com/technet/prodtechnol/exchange/Guides/E2k3FrontBack/3beec
46b-188a-4067-9f1e-c9fe17e1cb9f.mspx?mfr=true


------------------------------------------------
Improved Public Folder Access and Features
A front-end Exchange server increases the robustness of accessing public
folders, as it knows the state of back-end servers and can use multiple
referrals to access public folder data. This includes system data such as
calendar free/busy information. In addition, in Exchange Server 2003, a
front-end Exchange server enables your users using Outlook Web Access to
reply or forward to posts in public folders. Without a front-end server,
public folder posts can be only read.
------------------------------------------------

(This was from the section titled "Front-End and Back-End TOpology
Advantages")

This is obviously referring to some other kind of scenario. Anyone know what
that might be?

>> Other advantages I see are, if you have a FE/BE config, you can
>> "seemlessly" move users between BE servers (and presumably introduce new
[quoted text clipped - 44 lines]
>>
>> Paul
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.