Re: 2003 store requirements on specialized servers
- From: "Rich Matheisen [MVP]" <richnews@xxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 14 May 2005 13:20:12 -0400
Ex Gomer <gomer@xxxxxxxxxxx> wrote:
>I have seen bits and pieces of best practices as it relates to the
>usage of mailbox and public folder stores but wanted to ask here to
>get more advice.
>
>I have a server that will hold only public folders, a server that will
>act as a bridgehead and internet connector, and a number of mailbox
>only servers.
>
>My questions are:
>
>1. Should I delete the publc folder stores from all but the primary
>and secondary specialized servers? What is the impact to free/busy
>etc. As long as the public folder server is specified for each
>mailbox store is there any reason to hold local copies of the public
>folder store?
I wouldn't recommend that unless you understand the way Exchange
routes mail for PF's and provides clients with the PF hierarchy.
By removing the public folder store from a mailbox server you have no
other source of the public folder hierarchy than the server you
nominated on each mailbox database. With only one public folder server
that may not have much of an effect if you nominated the PF server as
the hierarchy server for all the mailbox stores, but that means that
all the client will refer to this one server for the hierachy and that
may cause problems if the clients are "remote" to the PF server. OTOH,
if you had two PF servers, and you nominated one of them as the
hierarchy server, then taking that server offline would mean that
nobody could accees PF's even though you have replicas on another
server.
Removing the PF store from you "internet connector" can produce some
very odd message routing situations if you have PF's that receive mail
from the Internet and you DON'T remove the PF stores from the other
mailbox servers. Without a local PF store the connector server will
send the message to the PF store at the top of the
msExchOwningPFTreeBL property of the "Public Folders" object in the
configuration container. That server is usually the last server you
installed. So, for example, if your public folder server's in London,
and you leave a PF store on a server in Sao Paulo, Brazil, and your
connector server is in Sydney, then messages may be sent from
Australia to Brazil and then to London. While the locations are
exagerations, it's easier to comprehend than "network distance", which
is really the issue).
>2. On the bridgehead and public folder servers, should I delete the
>mailbox stores? (same general idea)
No. Without a mailbox store you won't be able to generate NDRs. And PF
replication uses mail to move the data between servers.
>I want to eliminate unnecessary stores for many reasons, some being
>efficiency, general "best practices", keep users from creating users
>or folders on the wrong servers etc.
Users don't control where public folders are created -- you, as the
admin, get to do that. The folder will be created on a local PF store
and then replicated to the servers in the replicas list. When that's
done, the "local" replica will be deleted. If you on't want local
folders then don't put replicas on the non-PF servers.
The only thing you'll be saving by removing the local PF stores is the
hierarchy replication traffic. That, most likely, will be so small as
to be unnoticable when compared to the other message traffic. You can
even reduce the number of messages by increasing the size of the
replication messages to 1MB (or more).
--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
.
- Follow-Ups:
- Re: 2003 store requirements on specialized servers
- From: Ex Gomer
- Re: 2003 store requirements on specialized servers
- References:
- 2003 store requirements on specialized servers
- From: Ex Gomer
- 2003 store requirements on specialized servers
- Prev by Date: Re: Envelope Journaling
- Next by Date: Re: Message size limits extended but not in effect EX 2003
- Previous by thread: RE: 2003 store requirements on specialized servers
- Next by thread: Re: 2003 store requirements on specialized servers
- Index(es):
Relevant Pages
|
