Exchange Server

Boris · Guest

Hi,
I am working on a plan to kill our current mail system and implement a
decent Exchange 2003 Server environment. I find it very hard, however, to
come by any useful information when it comes to hardware requirements. The
standard Microsoft requirements don't really cut it, especially not in our
environment.
We currently have approx. 250 users using PST files on a server location (I
know, it's a nightmare). These PST files take up a total amount of about 300
GB (PSTs between 1 and 2 GB are no exception), and we probably want to import
the existing mail into the new Exchange database.
Can anyone tell me how Exchange will perform with mailboxes that big, and
what kind of hardware would be required to provide my company with a very
stable solution?
Regards,

Al Mulnick · Guest

At that size db's, you'll want to be sure that you have a fast disk
subsystem. You'll also want to keep the store db's to as small a size as
you can manage (12.5 - 25 GB each in your environment?) If you use third
party software, you'll want to take that overhead into account.

You would likely want to max the memory (about 5GB on W2K3 servers to allow
for overhead past what Exchange can use.) You'll also likely want to
separate the I/O to maintain decent performance.

I highly suggest that you find a way to control the legacy mail retention.
Any longer, this is something that regulatory compliance just about requires
to some degree.

Al

"Boris" <Boris@discussions.microsoft.com> wrote in message
news:D4FB7B23-79F1-46D6-94ED-94DF854A6598@microsoft.com...

Boris · Guest

Hi Al,

thanks for the advice! I'm not very knowledgeable about Exchange 2003, but
what I gather from your reply is that it is possible to create multiple
databases? How does that work then? Does Exchange handle this as one
environment (for global address list, public folders, etc.)? How many of
these stores can Exchange handle, and should I put each on different disks,
or can they reside on the same? And, you are right, I am seriously
considering limiting the mail retention, as the current situation is
pratically impossible to handle.

"Al Mulnick" wrote:

Al Mulnick · Guest

Drop a note if you need anything or if it raises any additional questions.
I highly applaud the learn-it-yourself method you are pursuing and I will do
what I can to help you do that.
Best of luck,

Al

"Boris" <Boris@discussions.microsoft.com> wrote in message
news:C870A250-5553-49C8-A8FD-85F5A319251A@microsoft.com...

Boris · Guest

Hi Al,

ah, hiring a consultant! It might very well turn out that we do, but I've
seen many consultants leaving a system behind that is completely
undocumented, and ofcourse my own team would like to gain the experience
themselves, we'll see...

As for your information: It's been very helpful, I will start digging in the
Exchange library, thanks a lot!

Regards,
Boris

Al Mulnick · Guest

I highly suggest reading some of the docs at
http://www.microsoft.com/exchange/library to get a bit more up to speed on
the details.

Exchange handles multiple instances of the data stores as a single server.
In older technology, there was one mail store per server. In SQL and
Exchange 200x they introduced multiple stores per server. In 200x, you can
have up to 20 of them [1] max. They are all seen as a single server and they
all share the same GAL, PF hierarchy, F/B time, etc. Whether or not you put
them on different disks depends on your needs and configuration. It's I/O
type is random R/W typically with a 3:1 r:w signature (disk perspective)
after it normalizes. Because each company is different and because the
signature changes as you grow data sizes, it's hard to predict based on the
situation you're in but that would be the mix to plan for initially. A goal
if you will.

That said, separating out the I/O types typically done based on priority.
The priority is often set based on ROI of performance vs. cost. What I've
typically seen goes something along this order:

1) Log files: best ROI if you separate the log files (per SG) to their own
spindles. Highly write intensive (~95% write wouldn't be surprising if not
a little conservative)
2) MTA/SMTP Queue files (I'm showing my age with this stuff, because SMTP
Queues are the recent version ;) Typically very write intensive because
Exchange will spool each message to the disk before processing further. Some
variation occurs, but you can expect 1:7 r:w I/O types
3) tmp files. Exchange uses these when it needs some scratch space.
Separating this out can be useful for added performance
4) Store DB's (EDB and STM files together) can and often should be separate.
Tends to be random r/w so putting all 20 on the same set of physical disks
can be workable. As the db's grow, it might be best to group them based on
storage group or even to take it to the next level and separate them out if
the stores are really large and highly utilized.

There's some good docs about troubleshooting performance that would be
worthwhile for you to read along with the deploying and design docs at that
link. Else you would hire a consultant to help out (that's folks like me
;)

Don't forget to take your AD GC's into account as well as your back/restore
requirements. You'll want those in the planning process up front vs. as an
afterthought to save time and money.

Does that help?

Al

[1] active on a server at a time. I'm not talking about RS DB's. There's
more information in the docs at that link.

"Boris" <Boris@discussions.microsoft.com> wrote in message
news:D635CC11-5E12-4549-A24F-A7AD2DA79E1F@microsoft.com...

Leonid S. Knyshov · Guest

"Boris" <Boris@discussions.microsoft.com> wrote in message
news:D4FB7B23-79F1-46D6-94ED-94DF854A6598@microsoft.com...

	Exchange Server Forum Index -> Design	All times are GMT
Page 1 of 1