Mail Flow:

Let’s begin
There are several components that are involved in the Mail delivery process.

Information Store (Store.exe)

The Microsoft Exchange Server Information Store (Store.exe) is the end point for e-mails
sent to users on this server. It is also the start point for e-mails which are sent by MAPI
clients, like Microsoft Outlook 2003, which directly connect to the MSExchangeIS.

Figure 1: MSExchangeIS

Exchange InterProcess Communication (EXIPC)

EXIPC is responsible for Data Transfer between Internet Information Server 6.0 (IIS) and
the Microsoft Exchange Server Information Store (MSExchangeIS). EXIPC provides a
layered service between both components to achieve the best possible performance
between IIS dependant components and the Exchange databases. As you might know, all
Internet Client Access Protocols like HTTP/S, SMTP, POP3 and IMAP4 are configured
and managed by IIS with some exceptions.
Figure 2: EXIPC Layer

This interaction allows Exchange to be in a FrontEnd, and BackEnd, Server scenario.

Through Virtual Servers, multiple configurations of the same protocol can exist on a
single Exchange Server.

Advanced Queuing Engine (AQE)

The Advanced Queuing Engine (AQE) is responsible for creating and managing message
queues for e-mail delivery. When AQE receives a Simple Mail Transfer Protocol (SMTP)
mailmsg object, this object will be forwarded to the Message Categorizer. The Advanced
Queuing Engine then queues the Mailmsg object for message delivery based on the
Routing information provided by the Routing Engine process of Exchange Server 2003.

The Message Categorizer is part of the Advanced Queuing Engine and is responsible for
address resolution on every Mailmsg object that flows through the AQE. The Message
Categorizer is implemented as an Event Sink. The Message Categorizer is also
responsible for splitting messages into RTF or MAPI.
Routing Engine

The Exchange Routing Engine uses Link State information for e-mail routing. The
Routing Engine will forward this information to the Advanced Queuing Engine.

Please note:
The SMTP Stack from Windows Server 2003 will be extended through the Exchange
Server installation process with several enhancements. One of these enhancements is the
implementation of the XLINKSTATE protocol.

The Routing Engine creates and maintains the Link State information for every Exchange
Server and is also responsible for routing the messages to inbound or outbound
destinations.

SMTP Service

The SMTP Service processes incoming traffic from any SMTP host. SMTP is also used
in most communications between Exchange Servers (except Exchange 5.x Servers which
use RPC for message transferring). SMTP is also responsible for some advanced
Exchange Server functions like Message Journaling. During the Exchange installation,
the built in SMTP Serivce from Windows Server 2003 will be extended with several new
functions. Some of the Enhancements are:

• Moving the Message Queue Directories to the Exchange installation Directory

• Providing support for the LSA (Link State Algorithm) in SMTP
• Moving SMTP Messaging from IIS to the Exchange System Manager

Message Flow
Because understanding the e-mail message flow is important, I will list some high level
steps in the message flow:

• MAPI client sends a message to a remote recipient

• Information Store (Store.exe) receives the message
• The created MailMsg object is forwarded to the Advanced Queue Engine (AQE)
• The Message Categorizer from the AQE processes the MailMsg object and splits
it into MIME or RTF as necessary
• The Message Categorizer expands groups and checks defined Message limits on
Exchange
• The MailMsg object is then transferred to the Remote Destination Domain within
the AQE
• The AQE passes the destination address to the Exchange Routing Engine
• SMTP initiates an SMTP session with the remote SMTP host
• After the SMTP session with the remote host has been established, the
information store retrieves the body of the message and converts the message as
necessary
 • SMTP sends the Message from the Queue to the Remote Host

The following Exchange Features require the use of SMTP:

• Intra Server Message Delivery

• Inter Server Message Delivery
• Message Delivery to the Internet
• Exchange of Routing Information

Intra Server Message Delivery

SMTP will be used for Intra Server Message Delivery for several components like
Message Journaling and Message categorization. Exchange Servers in the same Routing
Group use SMTP to communicate with each other.

Message delivery to the Internet

SMTP is often used to deliver e-mail to other exchange organizations or other messaging
systems. Exchange Server 2003 can use the Virtual SMTP Server to deliver messages, or
one or more Exchange SMTP Connectors or Routing Group Connectors.

Exchange of Routing Information

SMTP is also used to exchange Link State information between routing groups.

MX Record
A Mail Exchanger Record (MX Record) is a special DNS record specifying how e-mail
should be routed. When a message should be sent to that domain, a DNS lookup into the
destination DNS domain occurs and will look for an MX record and a responding A
Record. The E-Mail will then be sent to the specified Exchange FrontEnd or BackEnd
Server for message delivery.
Figure 3: MX Record in NSLOOKUP

Relaying
SMTP Relaying occurs when one SMTP host forwards e-mail to another SMTP host.
Open SMTP relaying occurs when the SMTP host accepts messages from recipients
outside the organization and forwards the messages to other recipients that are also
outside the organization.

Figure 4: Relaying
If the Exchange Server allows everyone without authentication to deliver messages, the
server is called an Open Relay. Open Relays can be used to send UCE (Unsolicited
Commercial E-Mail). By default Exchange Server 200x is not an open relay.

The following steps describe the process:

• The unauthorized user sends an e-mail message to the SMTP Server and
addresses multiple recipients in the message. The recipients in the e-mail are in
domains external to the Exchange Server's Messaging Organization.
• The Exchange Server accepts the Message.
• After Exchange has accepted the message, Exchange delivers this message to an
outside SMTP host because there is no match in the recipient policies in the
exchange organization.

Routing Groups
Exchange Server 2003 supports the concept of routing groups to control the message
flow between Exchange Servers. Routing groups are groups of servers running Exchange
Server 2003 that are connected over permanent highspeed network links. Within routing
groups, Exchange Server always transfers messages over SMTP.

There is one special Server called the Routing Group Master which is responsible for
tracking and maintaining the routing information which is necessary for determining the
best path for message delivery. The default Routing Group Master is the first server in the
routing group. If you wish to transfer the Routing Group Master role you must do so
manually in the Exchange System Manager.

Figure 5: Routing Groups

If your organization has more than one routing group, you must install a connector
between the two or more routing groups. The preferred connector is the Routing Group
Connector but you can also use a SMTP, or X.400, Connector.

By default, all exchange server organizations include only a single routing group called
First Routing Group. All servers in the organization are members of the First Routing
Group, unless routing membership is modified by you as an exchange server
administrator.

You should plan to implement multiple routing groups when one or more of the
following conditions occur:

• Network connections are slow or not permanent

• The network is unreliable or unstable
• Message transmission is complex and indirect, requiring multiple physical
network hops
• Message transmission must be scheduled between different locations
• The routing group structure is created to prevent users from accessing public
folder replicas

Link State Algorithm (LSA)

Exchange Server 2003 determines the route that an e-mail must take based on the status
and availability of connectors between different routing groups and to external messaging
systems through an SMTP connector or other connectors.

Every exchange server stores its status information in a Link State Table (LST). The Link
State Table is a small table which requires about 32 bytes per entry which is held in
the Exchange Servers' RAM.

All information will be collected by the Routing Group Master (RGM) of the routing
group. The Routing Group Master uses TCP Port 691 to talk with other exchange servers
in the routing group and is responsible for generating / updating the LST and for the
distribution of the LST to each exchange server in the routing group.

The updated LST is propagated to other routing groups through Bridgehead Servers. The
Routing Group Master (RGM) then sends the updated information to the Bridgehead
Server, and then the Bridgehead Server sends the information to Bridgehead Servers in
other Routing Groups over TCP Port 25.
Figure 6: Link State Table

The Link State Table lists all connectors, and their status, in an Exchange Server 2003
organization. The following information is included in the LST:

Link status

There are only two states for any given link: up or down. For this reason, connection
information, such as whether a link is active or in a retry state, is not propagated between
servers running Exchange Server 2003, and it is only available on the server involved in
the message transfer. Exchange Server 2003 only considers routing messages by using
connectors with a link status of up.

Link cost

The Link State Table stores costs for each connector. Exchange Server 2003 uses the cost
values stored in the link state table to select the least cost route for a message. Costs are
configured on each connector, and Exchange Server 2003 records them in the Link State
Table.

Conclusion
In this article I tried to show you how Exchange Server 2003 Message flow works. In the
second part of this article I will show you how to use Message Tracking, Message
Queues and some other tools such as Winroute to troubleshoot Exchange Message flow.
There are several places and tools which can help you find the reason for failed or
delayed message delivery. I will go through some basic steps to show you where you
should start troubleshooting from. After reading this article and playing with these tools
you should be able to troubleshoot e-mail message delivery.

Queues
If you are looking for e-mail messages which were not delivered to their recipients, one
of the first places to look to see where the Message has gone is the Queue Viewer. You
can find the Queue Viewer in the Exchange System Manager directly under the Server
Node.

There are several Queues of interest and you should have a look at the state of the Queues
and the number of messages in the Queue. If there are any messages in the Queue, you
can select the Queue and you will see more information about possible problems in the
info pane. If you right click the Queue you can force a connection if the problem is
only temporarily.

Explanation of Queue Types

Here is an explanation of Queue Types from Henrik Walther's article about Exchange
2003 Queue Viewer improvements.

DSN messages pending submission

This folder contains Delivery Status Notifications awaiting delivery. Its primarily used
for NDR’s – Non Delivery Reports.

Failed message retry queue

Contains outbound messages which couldn’t be delivered to their destination but will be
given another attempt.

Local delivery
Contains inbound messages for delivery to mailboxes on the Exchange server.

Messages awaiting directory lookup

Contains inbound messages awaiting recipient lookup in Active Directory.

Messages pending submission

Contains messages accepted by the SMTP virtual server, but haven’t yet been processed.

Messages queued for deferred delivery

Contains messages queued for deferred delivery (later time).
Messages waiting to be routed
Contains outbound SMTP/X400 messages still waiting to be routed to their destination
server, when it has been determined the message will be sent.

Figure 1: Queue Viewer

For Troubleshooting reasons it is also possible to Stop all Outbound Mail if you click the
Symbol in the Queue viewer. Please note that in the picture above Outgoing Mail has
already been stopped. Outbound e-mail delivery was stopped for the purposes of
this article so that some Messages in the Queues can be easily shown.

Message Tracking
One of the fundamental settings that every Exchange Server should have enabled is the
Message Tracking option. The Message Tracking option enables the logging of every e-
mail message and, if enabled, for the message subject. You should enable message
subject tracking only on low utilized Servers. Message subject logging can also be
problematic in Data Security, so please speak with your legal department
before implementing this feature.
Figure 2: Enabling Message Tracking

After the Message Tracking feature has been enabled, the Message Tracking Feature can
be used in the Exchange System Manager to find messages sent to recipients.

Figure 3: Message Tracking Center

If an e-mail message is selected, the message can be clicked in order to see the message
delivery status details.
Figure 4: Message History

As can be seen in the picture above, the message was Submitted from Store, delivered to
the AQE, submitted to the Categorizer, Queued for Routing and Queued for Remote
Delivery. For an explanation of these terms read the first article about Exchange message
flow.

SMTP Logging
With Exchange Server 2003 it is possible to use extended SMTP Logging for
troubleshooting purposes. If SMTP Logging is enabled, Exchange will write every
outgoing mail through SMTP in a special logfile located by default in
\Windows\System32\Logfiles\SMTPSVC1 where SVC1 is the first Virtual SMTP Server.

You must enable this feature in the Exchange System Manager under the potocol
container from the Exchange Server object.
Figure 5: SMTP Logging

After enabling this feature, the generated logfile can be opened and the detailed steps are
shown in the SMTP connection process.

For better viewing and analyzing, it is possible to export the logfile into Microsoft Excel.
With Microsoft Excel the logfile can be formatted so that it is easier to analyze its
content.

Figure 6: SMTP Logfile

Diagnostic Logging
One other troubleshooting helper is the Diagnostic Logging of Exchange Server 2003.
Diagnostic Logging sets the details that are logged in the Event Viewer for specific
Exchange components to a higher level, so more information will be logged in the Event
Viewer Application Log .

Diagnostic Logging should only be enabled when troubleshooting specific problems

because Diagnostic Logging quickly fills the Event Log. The Logging Level can be
set from None to Maximum in the GUI but there is also a Registry Key for setting the
Logging Level to Level 7 for SMTP Logging purposes.

Diagnostic Logging must be enabled in the Exchange System Manager under the
Exchange Server object.

After enabling the Diagnostic Logging feature the Event Viewer can be analyzed for
specific problems.

Figure 7: Diagnostic Logging

Telnet for SMTP

Telnet is a great tool for analyzing problems with the SMTP Service, especially for
Message delivery.

If a Telnet session is started with the Exchange Server's SMTP Port, every step that is
necessary to establish a communication with the SMTP Service on Exchange can be seen.

To start a Telnet session with the Exchange Server open a command prompt and enter:
Telnet Server.Domaene.TLD 25

The following picture shows the steps which are necessary to establish an SMTP
connection and to send an e-mail.

Figure 8: Telnet for SMTP Tests

For more information about Telnet and SMTP read my article.

SMTPDIAG
SMTPDIAG is a simple Tool for testing the SMTP Message flow from Exchange Servers
to outside SMTP or Exchange Servers.

SMTPDIAG can be downloaded from the Microsoft Exchange 2003 Tools Website.
After downloading and extracting the SMTPDIAG Tool, open a command prompt and
start SMTPDIAG.

SMTPDIAG has a very simple Syntax, as you can see in the picture below.

SMTPDIAG [email protected] [email protected] starts the

SMTPDIAG process. SMTPDIAG now checks DNS settings and initiates an SMTP
connection to the destination system without sending mail.

SMTPDIAG has only two options.

• /V = enables Verbose Mode and shows some more details which are hidden in
Standard Mode.
• [-d target DNS] = This parameter is optional. The IP address of the target DNS
server can be specified in order to look up remote MX records. This is often
configured as an external DNS server in Exchange. An external DNS can be
configured at the Exchange virtual server level but not for the Internet
Information Services SMTP service.
Figure 9: SMTPDIAG

For more information about SMTPADIAG read my article.

Conclusion
In this article I tried to show you some troubleshooting tips for problems you may
have with e-mail delivery in your Exchange Organization and to external recipients. The
first part of this article discussed the basics of Message Flow and Delivery within an
Exchange Organization.

Message Flow Architecture

The Hub Transport server role is essential for each Exchange Server 2007 to route
internal and external emails. The service running on these servers is the Exchange
Transport Service (MSExchangeTransport.exe).

Inbound Email

Inbound email is email that is delivered from outside Exchange Server 2007, for
example, from the Internet. We should have a gateway server implemented which can be
an Edge Transport server role or Hub Transport server role. This depends on what
internet connectivity and firewall structure is implemented. Best practice should be
installing an Exchange Server 2007 Edge Transport server role residing in the perimeter
network (also known as DMZ) without the need of Active Directory. This server then
routes incoming messages into your Exchange Server 2007 organization.

Outbound Email

Outbound email means messages that are being sent from internal mailbox users to
external recipients residing on the Internet. After a Hub Transport server has processed
the mail and identified it as outbound mail, the server routes it to the Internet, either
directly or again by passing a gateway server. This gateway server can be an Edge Server
Transport server.

Local Email

Local mail flow refers to messages that are processed by a Hub Transport server in an
Exchange Server 2007 organization and delivered to a mailbox on the same Active
Directory Site.

Remote Email

Remote Email flow refers to messages that are processed by a Hub Transport server in an
Exchange Server 2007 organization and delivered to a mailbox on a different Active
Directory site from the source mailbox.

SMTP Connectors
SMTP connectors are Exchange Server 2007 components that support one-way SMTP
connections. Due to this new restriction (based on earlier versions of Exchange Server)
we need two connectors:

• SMTP Receive Connectors

• SMTP Send Connectors

An SMTP Receive connector is required for an Exchange Server 2007 server system to
accept any SMTP connection. It is used to enable an Exchange Server Hub Transport role
or Edge Transport server role to receive email from any other SMTP server on the
Internet, other Exchange Server 2007 Hub Transport server roles, Edge Transport server
roles or other Exchange Server 2007 environments. You can configure multiple SMTP
Receive connectors with different parameters on a single Exchange Server due to
implementation or high availability reasons. You do not have to create SMTP Receive
connectors to route mail between Hub Transport server roles within the same forest.

An SMTP Send connector is required for an Exchange Server 2007 system to send any
SMTP email. It is required to send email to any SMTP server on the internet or to any
SMTP server within the same Exchange Server organization.
You can manage each of them using the Exchange Management Console or Exchange
Management Shell. To manage connectors using the shell use the Set-ReceiveConnector
and Set-SendConnector cmdlets.

Message Transport Components

To work with Exchange Server and troubleshoot message transport problems you should
know the internal workings of Exchange message routing.

Messaging Components are:

• Submission Queue
• Store Driver
• Microsoft Exchange Mail Submission Service
• Pickup Directory
• Categorizer

Messages from outside your Exchange organization enter the transport pipeline through
an SMTP Receive Connector. Messages inside enter the pipeline through the Hub
Transport server role.

Submission Queue
Each Transport server role (Hub or Edge Transport) has one submission queue that is
created by the categorizer when Exchange Transport Service starts. It stores all messages
on the local hard disk until they are processed by the categorizer for delivery. They
are then finally removed from this queue.

Store Driver
Messages sent by a mailbox user enter the transport pipeline when they reach the sender’s
outbox. The store driver on the Hub Transport retrieves it from the user’s Outbox and
then transfers it to the submission queue. After the message has been successfully added
to the submission queue, it is moved from the sender’s Outbox to the sender’s Sent Items.
Messages are stored in MAPI format and must be converted to Summary Transport
Neutral Encapsulation Format (S/TNEF) before being placed in the Submission Queue.
This conversion is the job of the store driver, too. If this conversion is unsuccessful, a
non-delivery report (NDR) is generated.

Microsoft Exchange Mail Submission Service

The Microsoft Exchange Mail Submission Service is a notification service that runs on
Mailbox server roles. It notifies the Hub Transport server role to pick up the message
from the sender’s Outbox. If there are multiple Hub Transport server roles on one Active
Directory site, the Message Exchange Mail Submission service attempts to evenly
distribute notifications between each transport role using static load balancing.

Pickup Directory
Each message that is transferred to the pickup directory has been successfully submitted
to the submission queue via the categorizer. Messages placed in the Pickup Directory
must be in the appropriate format and have read/write permissions configured. It allows
you to take a properly formatted text file and have the Hub Transport server role process
and deliver it. This can be very helpful when mail flow is being validated in the
organization or relaying specific messages or returning to the transport pipeline. Even 3rd
party applications may place messages in the Pickup directory rather than communicating
directly with the Exchange Server.

Categorizer
The categorizer always picks the oldest message from the Submission queue and checks
whether this message has to be routed internally in the Exchange organization or
externally.

On each Hub Transport server the categorizer performs the following tasks:

• Identification and verification of recipients

• Expansion of distribution lists
• Determination of routing paths
• Conversion of content formats
• Application of message policies

Implementation of Message Transports

Every time you install Hub Transport server roles in Exchange Server 2007
environments, message routing is enabled by default, but you may need to configure
additional options on the Hub Transport server role. This process can look like this:

• Configure server-specific settings

• Configure authoritative domains and email address policies
• Configure a postmaster mailbox
• Configure Internet message flow
• Configure messaging policies
• Configure administrative permissions:
o Exchange Organization Administrators
o Exchange Server Administrators
o Exchange View-Only Administrators
Each of these configuration settings are unique and need to be defined in a design
document before the configuration for each company.

Conclusion
As you have seen within this theoretical drilldown, Exchange Server 2007 email routing
is a little bit different to earlier versions, but this new release allows a clear and
easily understandable way to configure Email transport using role based installation and
configuration tasks.

In the next part of this article you will see how the tasks described can be
configured within Exchange Server 2007 using the GUI administration tools and the
Exchange Server Powershell, too.

If you still have any further questions, please do not hesitate to contact me.

If you missed the first part in this article series please read Exchange Server 2007 Email
Routing, Part 1 – Theoretical Basics.

In the first part of my article we had a close look at Exchange Server 2007 Email Routing
theoretical basics. Now we will have a look at how to configure Email routing within
Exchange Server 2007 and how we can configure the routing topology to meet our plans.

The main Exchange Server 2007 routing topology features are:

• No more routing groups

• No more routing group connectors
• Uses AD site links instead
• Uses least cost routing based on network layer’s OSPF capabilities
• Queues close to point of failure
• Improved bifurcation algorithm

This means no link state routing like in Exchange Server 2003 anymore.

Role Based Setup

Before you begin setting up your Exchange Server 2007 environment you should make
sure that your Active Directory Site structure is clear and does not contain any
configuration errors. This means you should probably rethink your configuration and
update it if necessary.

While setting up your Exchange Server 2007 machine, you have to choose which server
role you want to implement. Exchange Server Hub Transport role is the basis of your
routing structure. If you are running a one site Active Directory infrastructure, your
design will be quite simple, but if you are hosting Active Directory within multiple sites,
your Active Directory Site Links are the basis for your Exchange Routing Topology. This
means your site link costs are based on calculating the best way to route messages
between sites.

If you are installing Exchange Server 2007 in an existing forest, you will be prompted to
choose which of your existing routing groups you will connect with. This is because all
of your Exchange 2007 servers will exist in a special routing group that should only
house Exchange 2007 servers. In an ideal world, your first Exchange 2007 server will be
near one of your existing hub routing groups.

Understanding Intra-Organizational Mail Routing

Routing between two sites with only one Exchange Server 2007 in each site is quite easy.

Figure 1: Routing between two Sites

In an environment with at least three sites in one chain we can see new behavior when an
email is sent from the first to the third site. Compared to earlier versions of Exchange
Server, Exchange 2007 will now try to route the message directly.

Figure 2: Routing between three Sites

Exchange will now directly route the message to the third site, because use of the second
site is only an extra cost and does not have any further advantages. The amount of WAN-
Link would not decrease, but the site in between would have to use CPU and other
resources for receiving and sending the message. In addition this mail would take more
time.

Figure 3: Routing between three Sites in case of failure

Now Exchange will queue the mail to site C at the server nearest to its destination server.

Figure 4: Routing between three Sites in case of redundancy

In case of redundancy of site links, we always have the topology of routing with least
costs.

After having understood how to configure intra-organizational email routing, we will

now have a look at how to connect Exchange Server 2007 to the internet.

Configuring outgoing Email Transport

First, we will need to configure Exchange Server 2007 to accept outgoing email
messages. This means we will have to create a new SMTP send connector in the
organization configuration tab.

Figure 5: Configuring a New SMTP Send Connector

Figure 6: Adding an accepted Address Space

In this dialog box you will have to add all address spaces (or SMTP domains) your server
should accept and reroute emails.

Figure 7: Configuring the Smarthost

In this dialog box you will have to configure the destination server (relay server) of your
network environment. It is best to configure Exchange to use DNS MX records. This
means that you will just have to change your DNS configuration if you are changing your
servers IP addresses.
Figure 8: Configuring the local Hub Transport Server

Now we will have to add all source servers (formerly known as local bridgehead servers
in Exchange 2003 Server) that are able to use this connector for outgoing email.

To finish your configuration you will just have to click NEXT, NEW and FINISH which
will create the new connector.

Configuring incoming Email Transport

In Exchange Server 2007, the receive connector is a “receive listener”. This means that
the Receive connector listens for incoming connections that match the settings of the
receive connector. A receive connector listens for connections that are received through a
particular port and from a specified IP address or IP address range. You can also set
limits on the number of active connections that are supported by the receive connector.
The receive connector is a feature of the Edge Server Role and can only be configured
there.

If you would like your Exchange Server to accept emails from your Exchange Edge
Server, you will have to configure a subscription (using a XML file) and import this into
your Exchange Server 2007 organization.

To configure which email domains Exchange Server will accept, you will have to create
an “Accepted Domain” Policy in Exchange System Manager in Organization
Configuration under Hub Transport.
Figure 9: Configuring a new Accepted Domain

Exchange will allow handling of three options:

• Authoritative Domain
• Internal Relay Domain
• External Relay Domain

Conclusion
As you have seen above, Exchange Server 2007 allows for a wide variety of
configuration options to configure email routing. When looking at the intra-
organizational routing topology we can see that Exchange Server 2007 will completely
rely upon the Active Directory Site structure. This means that you will have to make sure
that your AD structure is clean and correctly configured before you implement Exchange
Server 2007.

When looking at external email transport scenarios, you will have to configure an SMTP
Send Connector from within your administration tool to make sure that outgoing email
works properly. To configure incoming email, it's best to set up an Exchange Server 2007
with an Edge Server role. Configuring an “Accepted Domains” policy will insure that
Exchange will only accept emails to domains it is responsible for.

Replacing Front end with CAS in Exchange 2007

Introduction
A lot of companies are still running on an Exchange Server 2003 environment (which has
been deployed some years ago now) and the design aspects and recommendations that
have been issued were only suitable at that time. This means that many may be running
an Exchange Server Front-End Solution that has been placed directly into the DMZ.

If these companies are planning to migrate to Exchange Server 2007, they need to check
whether to leave their front-end server there or replace it with a new machine with
Exchange Server 2007 installed on it, or to completely rethink the design of their
solution. This article will talk about the pros and cons for the migration and what solution
will be best for future requirements.

Two possible solutions

In general, there are two different types of solutions that are possible for an Exchange
Server 2007 front-end Server design:

• Replace the existing Exchange 2003 front-end with Exchange 2007 client access
service (CAS) role.
• Replace the existing Exchange 2003 front-end with a reverse proxy server like
ISA Server 2006.

These two types will be discussed in this article.

Replacing the existing Server with Exchange Server

2007 CAS
The easiest way to migrate the existing Exchange Server 2003 front-end to Exchange
Server 2007 is to install a new server with a 64 bit based Windows Server operating
system and afterwards, add an Exchange Server 2007 client access service role on it. You
then have successfully migrated all functionality from the old to the new server and you
can proceed to demote and decommission Exchange Server 2003.

This will mean that you would not change the design itself; it would just replace the
server with a new one running exactly the same features and providing the same
functionality. It would also not change any security settings or firewall configurations
because the ports you needed for Exchange Server 2003 are exactly the same with
Exchange Server 2007.

The required ports for communication between CAS Server and the internal servers are
defined in one of my older articles, and may be found here.
So, this solution is quite easy and could be smoothly deployed without any usage
interruptions.

Replacing the existing Server with a reverse Proxy

Server
The second way to migrate is to completely rethink the existing solution. With Exchange
Server 2007 you will not need a front-end server anymore. You would only need a
reverse proxy server (like ISA Server 2006) placed in the DMZ and to place the complete
Exchange Server 2007 into the LAN.

Figure 1: ISA Server as Reverse Proxy for OWA and Push Mail

Furthermore, this would mean that there are no Exchange Servers anymore in any of your
DMZ, leading to a more secure solution (from a reverse proxy server you would only
have to open HTTPS to communicate with your Exchange server(s) in the LAN). This,
would also lead you to open up to two ports (upon your configuration) from the DMZ to
the internal network and not about 8 to 11 ports that need to be opened, but this depends
on your design.

If you choose this design, you would need to implement a reverse proxy server solution.
A lot of firewalls give the possibility to configure a proxy and/or reverse proxy server on
them. So in a lot of designs you will not have to choose a new server solution with a new
product. If you do not have an existing reverse proxy server, you need to think of a new
solution like ISA Server 2006 which is available as software solution or hardware
appliance. The decision to choose between software or hardware appliance is up to you, it
does not matter when it comes to the functionality we need here.
I would suggest using ISA Server as reverse proxy solution because of the following:

• Best integration within your Exchange solution

• Logon would occur directly on your ISA Server box and not internally; ISA
Server would then behave as authentication and authorization in addition, too
• ISA Server 2006 provides an application filter out of the box that filters the traffic
for Outlook Web Access and/or Outlook Mobile Access to make sure that no
other unwanted traffic would cross your firewall
• ISA Server 2006 can act as RADIUS or LDAP proxy to ensure secure
authentication with Active Directory Services internally to your LAN
• As of today ISA Server is the only solution that provides this enhanced
functionality

If you choose to implement a reverse proxy server solution, the project itself needs to be
planned in more detail due to the fact that interruption from your internet mail solutions
(OWA and Active Server Sync) may occur.

The migration itself can be prepared well since a lot of things can be prepared before you
disable your existing Exchange Server 2003 front-end server and switch to your new
server. Here are a couple of points to help you do so:

• Installation of operating system and ISA Server on your physical hardware

• Prepare firewall configuration for ISA Server solution (with new IP address
running both solutions at one time is even possible)
• Configure publishing rules for Outlook Web Access and/or Active Server Sync

It is possible to test the new configuration before you put them into production, this
would entail:

• using another IP-address and external DNS name

• using a new digital certificate for the ISA Server

This sounds quite easy, but, it also means that if you are running Active Server Sync, it is
only this easy if you use a digital certificate on each mobile device that has a trusted root
certificate already installed in its certificate store. Otherwise, you would have to deploy
the new root certificated to all of your mobile devices, too.

Choosing the best solution

From a security point of view, the second solution described above is the most complex
yet secure solution. Configuring servers in the DMZ, with direct access to servers in the
LAN, is not as secure as it should be. If a hacker is able to act as your server in the DMZ,
he can successfully access your internal servers too and hack into them without additional
steps.
If you are already running a proxy server in your DMZ that is able to work as reverse
proxy server too, you should think about using that one. If you currently do not have any
proxies that might act as reverse proxy you should think about implementing ISA Server
2006 on a Windows Server 2003 machine, due to this server does not work with
Windows Server 2008 at present. If you want that solution, you should have to wait some
more months for the availability of Microsoft Forefront code named “Stirling”.

Exchange 2007 Queue

Brief
This article investigates message queues in Exchange 2007. I begin by highlighting the
differences in architecture between Exchange 2003 and 2007 in particular, discussing the
fact that Exchange 2007 uses a queue database. I then discuss the new look queue viewer
in Exchange 2007 and what it actually does! Finally I take a look at how the queue
viewer is built on PowerShell and suggest some ways in which that could be useful!

Message Queues, an Introduction

Exchange has always had a way of viewing the messages it was processing right back to
the early days of Exchange 5.x, and possibly even Exchange 4.0. However, the ease with
which this is possible and the functionality available to administrators has changed
throughout the versions. This is again the case with the transition from Exchange 2003 to
Exchange 2007. In Exchange 2007, the way queues work has changed fundamentally.
We have moved away from the Exchange 2003 method where each SMTP virtual server
had its own queue directory on an NTFS partition to Exchange 2007 using a standard
Extensible Storage Engine (ESE) Database for its queue information. On top of that the
user interface (UI) has changed completely in Exchange 2007 as it is now based on a new
Microsoft Management Console (MMC) v3 snap-in. To highlight the UI difference, take
a look at the screenshots below;

Figure 1: The location of Exchange 2003 Queues

In Exchange 2003 the UI for viewing queues made things fairly easy to find however, it
had the drawback of only being able to monitor one server’s queues at one time.
Figure 2: Viewing queues in Exchange 2003

In Figure 2 you can easily see the queue type and its status. In this example you can see
that there are several mails waiting to be sent which most likely are non-delivery reports
(NDRs) from spam mails!

With Exchange 2007, the queues are viewed in a new tool called “Queue Viewer” which
you can find alongside other utilities in the new Toolbox area, shown in Figure 3.

Figure 3: The new Toolbox area in Exchange 2007

When you open Queue Viewer, you can see that it is based on an MMC v3.0 snap-in as
shown in Figure 4:

Figure 4: The Queue Viewer UI

The major benefit of this is that you can now create your own custom MMCs using the
standalone viewer to monitor multiple Exchange 2007 servers at once:
Figure 5: Adding an MMC snap-in for Queue Viewer

Having looked at the UI changes, it is nearly time to move on to the fundamental theory
of the queues in Exchange 2007; however, before I do there is one other piece of info
which you should be aware of. Not all Exchange 2007 servers have queues! This is a big
difference to Exchange 2003 where, because of the fact that all servers were involved in
message transport, they all had an SMTP queue. In Exchange 2007 only Hub Transport
and Edge Transport servers have queues.

Queue Theory
So where does this database fit in? Well as mentioned briefly above, all queue activity
now occurs in a new ESE database. The main database file is called mail.que and by
default can be found here:

C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue

Figure 6: Folder containing queue database files

The other files are in the locations as described below:

• Trn.chk - The checkpoint file.

• Trn.log - The current transaction log file.
• Trntmp.log - The next provisioned transaction log file that is created in advance.
• Trnnnn.log - Other transaction log files that are created when Trn.log reaches its
maximum size.
• Trnres00001.jrs - The Reserve log file.
• Trnres00002.jrs - The Second Reserve log file.
• Temp.edb – Temp DB used to verify database schema on start-up.

You might wonder what happens with the logs in this scenario. Well, they are configured
for circular logging with transaction logs being deleted after they have been committed.

Just before we move on to another area, it is worth stating how to move the queue
databases. One important reason for moving the Queue DB and logs is performance.
Another slightly less well known reason is that the drive on which the Queue DB and
logs are stored must have 4GB or more free space otherwise the server will apply back
pressure and start slowing the flow of messages!

When moving the DB, the usual rules for splitting transaction logs and DB files apply. To
move the databases you must edit the EdgeTransport.exe.config file which by default is
located at the location below and then stop and restart the msexchangetransport service:

C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config

The key thing to bear in mind before editing the config file is that the parent directory has
the correct permissions as set up below; that way the directory will be created for you:
 • Network Service: Full Control
• System: Full Control
• Administrators: Full Control

The relevant lines are shown below. To move the database, you should edit the line
containing “QueueDatabasePath” and to move the logs, you should edit the line
containing “QueueDatabaseLoggingPath”. You can see in Figure 7 that I have moved my
DB and logs to H:

Figure 7: Editing the EdgeTransport.exe.config file (click to view a larger image)

Having looked at the Database it is now time to understand what it contains. There are
various different queues:

• Submissions: Used by the categorizer to gather all messages that have to be

resolved, routed, and processed by Transport agents.
• Poison Message: The poison message queue is a special queue that is used to
isolate messages that are detected to be potentially harmful to the Exchange 2007
system after a server failure.
• Remote Delivery: Remote delivery queues hold messages that are being delivered
to a remote server by using SMTP.
• Mailbox Delivery: The mailbox delivery queues hold messages that are being
delivered to a mailbox server by using encrypted Exchange RPC.
• Unreachable Destination: Each transport server can have only one Unreachable
queue. The Unreachable queue contains messages that cannot be routed to their
destinations.

Using Queues
Now that MMC v3 is used for queue viewer the UI is very simple. By default the queue
viewer opens and displays the queues for the transport server that you are logged on to.
To connect to another server use the Connect to Server task in the right hand action pane:

Figure 8: Showing Connect to Server

The main queue viewer window opens with two tabs along the top which show all queues
and all messages by default. When you open a queue by double clicking, another tab
appears showing only the messages in that queue:

Figure 9: Showing tabs in Queue Viewer

To manage the queues all you have to do is highlight the object to operate on and view
the actions pane on the right hand side of the window as shown in Figure 9.

A key new Exchange 2007 queue viewer feature is message filtering. An example of how
to use filtering is in the case of a spam attack. As an administrator you can take advantage
of the "Bulk Action" feature, which applies an action to all messages that meet the
parameters specified by the filter to remove spam messages with or without NDR.
Figure 10: The filtering UI shown in the messages tab

Figure 11: Some more filtering options

The other actions which you can perform in queue viewer are shown below:

• Suspend queue This action temporarily prevents delivery of messages that are
currently in the queue.
• Resume queue The opposite of Suspend queue.
• Retry queue When a connection to the next hop for a queue fails, a retry timer is
set. This forces an immediate connection attempt.
• Suspend message This action temporarily prevents delivery of a single message.
• Resume message The opposite of Suspend message.
• Remove message This action permanently prevents delivery of a message.
• Export message This action copies a message to the file path that you specify.
The messages are not deleted from the queue, but a copy of the message is saved
 to a file location. Before you export a message, you must suspend the message in
the queue.

Queues and PowerShell

Whilst I know that the whole of Exchange Management Console is based on PowerShell,
something that was really highlighted even further was the error message I got when I
had the queue viewer open and stopped the msexchangetransport service! You can see in
Figure 12 the PowerShell commands that run to provide the output to the Queue Viewer
UI.

Figure 12: PowerShell command error

It got me thinking about using PowerShell to manipulate the queues. To start off, I used
the PowerShell command below to show all commands with Queue in the name:

get-command *queue*

Figure 13: get-command *queue*

Then I tried the same command this time looking for commands with “message” in them:

Figure 14: get-command *message*

Armed with a knowledge of available commands I began by running a simple get-queue

command
Figure 15: get-queue

I then moved on to locate any queue with a message count of less than 100. In this
example three queues are shown all with 0 messages. All but the submission queue will
shortly be removed as their messages have been delivered. The submission queue is
persistent and is therefore always present, waiting for mail to be categorized.

Figure 16: get-queue with a filter

As you can see, the simplicity of the PowerShell commands make manipulating the
queues via script much easier than when using VBScript. Obviously the examples above
are simple but they could be taken a lot further. For example, you could run the following
to remove messages from queues which come from [email protected] with an
SCL rating higher than 5:

Remove-Message -Filter {FromAddress -like "*spammer.com*" -and SCL -gt 5}

-withNDR $false

Conclusion
Hopefully this has given you an insight into the new way message queues work in
Exchange 2007. For more information about the inner workings of queues, check out the
Exchange 2007 help file which can be downloaded here:

Exchange 2007 Dial Tone Recovery

Introduction
If you one day are faced with a relatively large corrupt Mailbox Store, restoring it can,
depending on things such as backup hardware, backup application and network speed, be
quite time consuming. Now the last thing you want to deal with in such a situation is
frustrated users (or even worse a yelling CEO!).

So how can you get your users to calm down (and your CEO to s… up) and get back to
work while you concentrate on getting the Mailbox Store back to life? There’s one simple
answer and that is, you can create a dial-tone database and thereby get message flow and
mailbox access recovered almost instantly. By using a dial-tone database your users can
start to receive and send mail again, they can even go check out old messages that existed
in their mailbox on the Exchange server (if their Outlook client has been configured to
use cached mode that is), bear in mind though they have to switch between Online and
Offline mode when prompted with the Outlook 2003 Exchange Recovery Mode dialog
box. I’ll talk more about Outlook 2003 Recovery mode in “Demystifying The Exchange
Dial-tone Restore Method (Part 2)”.

Using the dial-tone database restore method means that you, while restoring one or more
corrupted Mailbox Stores from the most recent backup, have users connect to a new
empty or blank Mailbox Store. The dial-tone restore method is by no means new; it’s
been used with previous versions of Exchange as well, but now that we have the
Exchange Server 2003 Recovery Storage Group (RSG) feature, the method becomes even
more attractive when restoring Mailbox Stores within your Exchange messaging
environment.

Note:
With previous versions of Exchange a dedicated Exchange recovery server was required.
Using a separate Exchange recovery Server meant you first had to restore the required
Mailbox Store(s) or database to the recovery server, then either export the data from the
restored database(s) to PST files using Exchange Server Mailbox Merge Wizard
(ExMerge) or copy the whole Exchange database from the recovery server to the
production server. As an Exchange database often is several gigabytes in size, this meant
you typically had to copy large amounts of data over the wire which, depending on the
network, could add several hours to the total recovery time.

Using the Recovery Storage Group feature makes it possible to restore Mailbox Stores
without the need to build and use a separate Exchange Recovery Server; instead you can
simply restore the Mailbox Store(s) directly to the Recovery Storage Group (RSG) on the
respective Exchange Server or any other Exchange 2003 Server in the same
Administrative Group. This makes it an easy and painless process to merge data from the
restored Mailbox Store(s) to the dial-tone database, or swap the restored database from
the Recovery Storage Group (RSG) to the dial-tone database in the original Storage
Group, then merge data from the dial-tone database to the restored Mailbox Store. I’ll
also talk more about swapping databases in “Demystifying The Exchange Dial-tone
Restore Method (Part 2)”.

Note:
If you’re not familiar with the Recovery Storage Group (RSG) feature, I recommend you
checkout MS KB article: 824126 - How to use Recovery Storage Groups in Exchange
Server 2003 which does a great job explaining how you can recover Mailbox Stores or
individual mailboxes using by restoring a Mailbox Store to the RSG.

Creating the Dial-tone Database

Alright we’re ready to have the dial-tone database created, so if it’s not already the case
you first need to dismount the Mailbox Store that are to be restored from backup. In order
to do so open the Exchange System Manager and drill down to the Mailbox Store under
the respective Storage Group. Now right-click the Mailbox Store and select Dismount
Store as shown in Figure 1 below.

Figure 1: Dismounting the corrupt Mailbox Store

In order to be able to create the dial-tone database the next step is to move the Mailbox
Store files (that is Priv1.edb and Priv1.stm) from the MDBDATA folder (by default
located under C:\Program Files\ExchSrvr\Mdbdata as shown in Figure 2) to another
location on the server.
Figure 2: Copying the Mailbox Store Files (Priv1.edb and Priv1.stm)

Note:
If you have the disk space available it’s highly recommended you don’t delete but move
the Mailbox Store files (Priv1.edb and Priv1.stm) to another location on the server
(preferably on the same logical drive), as you never know whether they are needed at a
later stage in the recovery process. Also remember to take a copy of any transaction logs
contained in the MDBDATA folder; these may very well be needed for transaction log
replay after restoring the original database to the Recover Storage Group (RSG).

We’re now ready to create the dial-tone database; this is done by right-clicking the
Mailbox Store we dismounted earlier, then selecting Mount Database as seen in Figure
3.
Figure 3: Creating the Dial-tone Database by mounting the Mailbox Store in Exchange
System Manager

After a couple of seconds you will be prompted with the dialog box in Figure 4 below.

Figure 4: Creating the Dial-tone database

Click Yes and again wait a couple of seconds for the next dialog box to appear then click
OK (see Figure 5).
Figure 5: The Dial-tone database was created successfully

We have now created the dial-tone database and from this moment on users can once
again connect to their mailboxes (although there’re still empty).

Now that the users can connect to the Exchange Server again it’s very important you send
out an email message informing them what’s going on. Such a message could look
something like the one shown in Figure 6 below.

Figure 6: Status Message to users affected by the Mailbox Store crash

That was it for part one, in part two I’ll show you what will happen when Outlook 2003
clients tries to connect to the dial-tone database that we created. I’ll also show you how to
restore the Mailbox Store from backup to the Recovery Storage Group (RSG), and finally
show you how to swap the database restored to the Recovery Storage Group (RSG) with
the dial-tone database in the original Storage Group then have them merged.

Part 2

Outlook 2003 Exchange Recovery Mode

Now that the dial-tone database has been created, the next time any user with an Outlook
2003 client configured with cached mode logs on, she will be faced with the dialog box
shown in Figure 1.

Figure 1: Outlook 2003 Exchange Recovery Mode

Outlook 2003 Exchange Recovery Mode lets you choose between Connect and Work
Offline, if you click Connect you’re connected with an empty Exchange Mailbox similar
to the one shown in Figure 2, that means email messages, rules, signatures, etc are gone,
but you’re able to search the Global Address List (GAL) as well as send and receive
email messages just like was the case before.

Note:
Be aware previous Outlook versions don’t receive the dialog box shown in Figure 1.
Instead a user who chooses to work online will, in most cases, end up with an unreadable
OST file, because the encryption data associated with the previous mailbox would be
overwritten with a new key from the new empty mailbox. It’s therefore recommended to
inform any user that accesses his/her mailbox with an earlier version of Outlook to open
Outlook in offline mode then export the data to a PST file, which then can be opened or
imported when opening Outlook in online mode. For more information I also suggest you
read MS KB article: 282496 - Considerations and best practices when resetting an
Exchange mailbox database.
Figure 2: Outlook 2003 in Online Mode accessing a Dial-tone database

If you click Work Offline the OST file (which is stored locally on the client) is opened,
from here you can access any email message which was synchronized between the
Exchange mailbox and the OST file prior to the Mailbox Store crash as shown in Figure
3 below.
Figure 3: Outlook 2003 in Offline Mode accessing the local OST file

Restoring the Mailbox Store from Backup

Now is the time to restore our crashed Mailbox Store from backup, we’re going to restore
it to a Recovery Storage Group, so before doing anything else we need to create this
special Storage Group. This is done by opening the Exchange System Manager, here you
drill down to and right-click the respective Exchange Server object located under the
Servers container. In the context menu select New then Recovery Storage Group as
shown in Figure 4 below.
Figure 4: Creating the Recovery Storage Group

Specify the drive you want to restore the Mailbox Store to (see Figure 5). If disk space
allows it, it’s a good idea to restore it to the same logical drive as the dial-tone database is
currently located on, as this will improve performance drastically.
Figure 5: Specifying Log and System Path location

Click OK.

Now that we have the Recovery Storage Group in place, we need to add the database (the
one we want to restore from backup) to this Recovery Storage Group. This is done by
right-clicking the Recovery Storage Group, then select Add database to recover, which
brings us to the screen shown in Figure 6. Here you should highlight the Mailbox Store
you want to restore, then click OK.
Figure 6: Adding the database to the Recovery Storage Group

Now name the Mailbox Store (see Figure 7) then click the Database tab.
Figure 7: Naming the Recovery Storage Group Mailbox Store

Here you should just accept the defaults, but make sure This database can be
overwritten by a restore is check marked as shown in Figure 8 below, then click OK.
Figure 8: Specifying the Recovery Storage Group Database location

We’re now ready to restore the Mailbox Store from backup, in this article we’re using
NTBackup but if you have implemented a third party product such as Veritas Backup
Exec that’s the one to use.

Start NTBackup by clicking Start > Run and type NTBackup, then select the Restore
and Manage Media tab as shown in Figure 9.
Figure 9: Restore and Manage Media tab in NTBackup

Note:
If you don’t get the screen shown in Figure 9 when opening NTBackup, it’s because it
starts in Wizard mode. If this is the case remove the checkmark in Always start in
wizard mode, exit NTBackup and open it again.

Now expand File > Information Store.bkf > Server\Microsoft Information

Store\First Storage Group and select the respective Mailbox Store as well as Log Files
(see Figure 10).
Figure 10: Expanding and selecting the respective Media item

Notice the Restore files to: text box has Original location.

Click Start Restore then specify the server to restore to and a temporary location for the
log and patch files. Also remember to check mark Last Restore Set (Log file replay will
start after this restore completes.) and Mount Database After Restore (see Figure
11), then click Next.
Figure 11: Specifying the server, temporary location for log and patch files

The restore will now begin and depending on how large the Mailbox Store is this can take
several minutes/hours. When the restore is complete simply click Close (see Figure 12)
and exit NTBackup.

Figure 12: Mailbox Store restore complete

That was it for Part 2; look forward to Part 3 where I’ll show you how to swap the
Mailbox Store (we just restored) currently mounted to the Recovery Storage Group with
the dial-tone database, which is currently the production database. To end the article, I’ll
show you how to merge the two databases.
And yes I promise you that the next article will be the last in this series!

Part 3

Verifying the State of the Restored Mailbox Store

It’s time to verify the restored Mailbox Store is visible under the Recovery Storage Group
in the System Manager as well as check that the respective mailboxes are listed under the
Mailboxes container object (see Figure 1).

Figure 1: Restored Mailbox Store under the Recovery Storage Group as seen in System
Manager

After restoring a Mailbox Store to the Recovery Storage Group it’s recommended to
dismount/mount it once, in order to ensure any required transaction logs have been
purged to the database, as well as to make sure the database is in a consistent state. If you
belong to the paranoid Exchange Admin’s you can double check the state of the database
by running an ESEUTIL /MH C:\Program Files\Exchsrvr\Recovery Storage
Group\database.edb against it (remember to do this while it’s dismounted). The line
State: should be in a Clean Shutdown state, as is the case in Figure 2.
Figure 2: State of the restored Mailbox Store

Swapping the Restored Mailbox Store with the Dial-

tone Database
Alright now that we have a consistent restore of the original Mailbox store, we’re ready
to have it swapped with the dial-tone database currently in production. Actually you
could go right away and start to merge the restored Mailbox Store to the dial-tone
database, but there are several disadvantages in doing so. The most noteworthy are listed
below:

• Single Instance Storage (SIS) will be lost meaning the Mailbox Store will become
much bigger than was the case prior to the crash.
 • Original mailbox rules, forms etc. will be kept in the state they were in before the
Mailbox Store crash, which mean users won’t have to do any modifications to
rules that for example move messages to custom folders plus the Outlook offline
files (OST files) still will be functioning.
• The time of the overall merge of data from one database to the other will be
greatly reduced. Since the dial-tone database is much smaller in size than the
original Mailbox Store. Imagine how long it will take to merge let’s say 30GB
into a database versus 1GB!

In order to swap the databases the first step is to dismount both of them by right-clicking
the Mailbox Stores and select Dismount Store in the System Manager.

Note:
Theoretically you could swap the databases by changing the logical path of each in the
System Manager, but I don’t recommend this method and therefore won’t go into details
on how you accomplish this.

Next step is to make sure the .EDB and .STM files associated with the Mailbox Store
which were restored to the Recovery Storage Group match the names of the .EDB and
.STM files associated with the dial-tone database, if they don’t now is a good time to
rename them.

Important!
You should only rename the .EDB and .STM files if you don’t need to replay any
additional log files into them.

It’s time to create a folder named NEW (or something else if you prefer) in the folder
holding the .EDB and .STM files for the Restored Mailbox Store as well as in the
Mailbox Store (Dial-tone database) currently in production, by default the path to each
are C:\Program Files\Exchsrvr\Recovery Storage Group and C:\Program
Files\Exchsrvr\MDBDATA (shown in Figure 3 below).
Figure 3: Path to the .EDB and .STM file of each Mailbox Store

Now move the .EDB and .STM files from the Recovery Storage Group folder to the
NEW folder created under the MDBDATA folder. Do the same for the .EDB and .STM
files held in the MDBDATA folder; just move them to the NEW folder in the Recovery
Storage Group folder instead. When the files have been moved you should move them
once again, this time from the NEW folder to the folder above it (that is the Recovery
Storage Group and MDBDATA folder). If you get a dialog box asking whether you want
to overwrite existing files, it’s because you did a copy and not a move in the previous
step. If this is the case just select Yes.

Back in the System Manager you should open the Properties of each Mailbox Store,
select the Database tab and check mark This database can be overwritten by a restore
(shown in Figure 4 below).
Figure 4: Database tab in the Properties of the Mailbox Store

Now mount both Mailbox Stores in the System Manager, when you have done so the
users can once again access their original Mailboxes (including rules etc.). In addition the
users will only be faced with the Outlook 2003 Exchange Recovery Mode dialog box one
more time, and that’s the first time they login after the databases have been swapped.

Merging the Databases

Okay we have one more step to do before we can call the dial-tone database recovery
method a success, and that is to merge the database that were created in the dial-tone
database during the period we restored the original Mailbox Store from backup. Before
Exchange 2003 SP1 were released the merging was done with the help of ExMerge, but
Exchange 2003 SP1 changed this as it included a new Recover Mailbox Data feature
that’s integrated into the System Manager console (you can read more about the feature
in this article over at the Microsoft Exchange TechCenter).

To merge the Mailboxes from the dial-tone database to the original database restored
from backup, drill down to the Recovery Storage Group > Mailbox Store > Mailboxes in
the System Manager console. Here you should select the mailboxes that need to be
merged, then right-click and select Exchange Tasks in the context menu as shown in
Figure 5 below.

Figure 5: Selecting the Mailboxes that need to be merged

Now click Next twice (see Figure 6).

Figure 6: Merge or copy mailbox items to selected user’s current mailbox

Make notice of the Destination Mailbox Store and click Next again (see Figure 7).
Figure 7: Destination Mailbox Store

Select Merge Data then click Next as shown in Figure 8.

Figure 8: Selecting Merge Data

Schedule the processing task or begin the merging immediately, then click Next (see
Figure 9).
Figure 9: Schedule the processing task

Let the task finish then click Finish (Figure 10 and 11).
Figure 10: Task In Progress

Figure 11: Completing the Exchange Task Wizard

We have now restored all mailbox data to the state it was in prior to the Mailbox Store
crash, as well as merged any messages that were received while the users were connected
to the dial-tone database, and can now call our disaster recovery a success.

Final words
Hopefully these 3 articles inspired you enough to go test out the dial-tone recovery
method in your test lab, so that you can make use of its benefits should you one day have
to deal with a large corrupt Mailbox Store in your Exchange messaging environment.

How does Recovery Storage Group works:

Introduction
Recovery Storage Groups (RSG) are one of the most administrator friendly features of
Exchange Server 2003 SP1. Prior to Exchange 2003 SP1, if you needed to restore a
mailbox, you were in for a whole pile of work. You would need to configure a
completely separate forest with an Exchange recovery server and then restore to that
server. Once that was complete you could export to PST and then import that PST into
the production mailbox. Not fun and I know of more than one place that had a policy not
to restore mail. You can imagine what that led to.

One of the features of Exchange Server 2003 SP1 is called Recovery Storage Groups.
Fellow MSExchange author Markus Klein wrote on using RSGs in his article titled
Recovering Mailboxes with Exchange Server 2003 Service Pack 1.

Recovery Storage Groups allow an administrator to mount a restored copy of an

Exchange database on any server in the same Administrative Group. Once the database is
restored to the RSG, the administrator has a number of options to restore the mailbox(es)
to the production server. You can restore a mailbox, a group of mailboxes, or the entire
database.

What’s Different About RSGs?

The first and foremost difference is that RSGs do not support any protocols except MAPI
and therefore cannot send or receive mail. They also cannot be bound to a user’s Active
Directory account. In fact the only user accessible way of accessing a mailbox in a RSG
is with ExMerge. Other than ExMerge, the only other way to access the mailbox is to
restore it to the production store.

Because RSGs are not meant for long term, and cannot be put into production use, there
are a number of things that they do not support such as online maintenance,
defragmentation, mailbox management, and system policies. Unlike a regular storage
group, you cannot change the location of the files. When you create the RSG you can use
the default locations or specify a different location for the files (see Figure 1). The only
way to change this is to delete the RSG and start over.

Figure 1: RSG File Location

A few other things that make RSGs different are:

• You cannot use RSGs to restore Public Folders

• Only one RSG is supported per Exchange server

How Does the Restore Work?

Once you have the RSG created and are going through the restore process, you will
probably notice that you are not prompted where to restore the database to. This has
caused a few administrators to cancel the restore thinking they have done something
wrong. For example, when restoring with NTBackup, the only information you need to
supply is where to restore to, and the location of the temp files (see Figure 2).
Figure 2: Restore Options

One thing to be aware of is that you can only restore backups taken with an Exchange
aware backup application. So why isn’t the production database overwritten? Simple, the
Information Store is smart enough to automatically redirect the restored database to the
RSG. When you create an RSG you are prompted to choose a database to recover (see
Figure 3).
Figure 3: Database Selection

When you start the restore, the Information Store checks to see if the chosen database is
in an RSG. If it is, the database is restored to the RSG, if it is not the restore stops. You
may also see event ID 9635 in the application event logs. The source of this error is
MSExchangeIS and the description will tell you that the database could not be found.

Once the RSG is deleted, the recovery process returns to its normal behavior. If you do
not want to delete the RSG, but don’t want to restore to the RSG, you can modify the
behavior in the registry.

Open up the registry and drill down to

HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters\System

Create a new DWORD called “Recovery SG Override” and set the value to 1. This will
allow you to keep the RSG, but the restored database will not be redirected. I don’t
recommend creating this key, and if you do require it, delete it when you are finished.
Last thing you want is to forget about it and then wonder why the 3 month old database
you just restored to an RSG actually overwrote the production database!!!
How Does the RSG Know Where to Restore the Mail
To?
With the RSG created and the database restored, you might now wonder how the mailbox
in the RSG connects to the mailbox on the production database. The RSG mailbox and
the production mailbox are linked with the following two Active Directory attributes

• msExchMailboxGUID
• msExchOrigMDB

The msExchMailboxGUID is unique for each mailbox and is created during mailbox
creation and never changes. The GUID of the mailbox in the RSG must match the GUID
of the production mailbox. This leads to a common issue with RSGs; you cannot restore a
deleted mailbox. When the mailbox is deleted so is the GUID and when the new mailbox
is created a new GUID is also created. Because the GUIDs do not match, a RSG cannot
be used to restore the data. Figure 4 demonstrates this link.

Figure 4: GUID Linking

The msExchOrigMDB attribute determines the originating database from which the
mailbox was a part of. This attribute directs the data to the proper database. The
combination of the msExchMailboxGUID, which determines which mailbox to restore to,
and the msExchOrigMDB attribute, which determines which database the mailbox is in,
allows the administrator to merge or copy the data into the production mailbox (see
Figure 5).

Figure 5: Merge or Copy Data

This leads to another common issue, what happens if the mailbox has been moved to a
different database since the backup was made? In such a case, the msExchOrigMDB
attribute can be edited with ADSIEdit.

If the mailbox has been moved to a different database, you must edit the
msExchOrigMDB attribute on the RSG so that it points to the database that now contains
the mailbox. To do this open ADSIEdit and drill down to

CN=Configuration,DC=domainname,DC=tld
CN=Services
CN=Microsoft Exchange
CN=ExchangeOrganizationName
CN=Administrative Groups
CN=AdministrativeGroupName
CN=Servers
CN=Servername
CN=InformationStore
CN=StorageGroupName
From this location, right-click on the database object and select Properties; record the
value for the distinguishedName. Next, locate the RSG database under the
CN=Configuration,DC=domainname,DC=tld container. Edit the msExchOrigMDB
attribute and enter the value you recorded earlier. Close ADSIEdit and you can now
restore the mailbox that was moved.

Conclusion
Recovery Storage Groups are a powerful tool available to Exchange administrators that
allow you to easily restore mailbox data. This article scratches the surface on how they
work, but I hope it answers some of the questions you had on the subject. If you want to
know more check out these great articles from other MSExchange authors:

Understanding Information Store:

If you don’t believe me, stop the Microsoft Exchange Information Store service and
count the seconds before your phone starts ringing!

The Information Store is made up of a number of components. Figure 1 shows a

graphical layout of a typical Exchange server.

Figure 1

Exchange 2000 and 2003 use the same Information Store but there are some differences
depending on the version. Table 1 describes these differences.
Store Features Exchange 2000* or Exchange 2003 Exchange 2000 or
Exchange 2003 Standard /w SP2 2003 Enterprise
Standard Pre-SP2

# of Storage Groups 1 + 1 RSG** 1 + 1 RSG** 4 + 1 RSG**

# of Stores 1 Mailbox store and 1 1 Mailbox store and 1 5 per Storage Group
Public Folder Store Public Folder Store
per Storage Group per Storage Group
Store Size Limit 16GB per Store 75GB per Store 16TB per Store

Table 1

* Any Exchange 2000 service pack level

**RSG = Recovery Storage Group

Storage Groups and Databases

A Storage Group will contain one or more Mailbox and Public Folder stores, depending
on the version and the needs of the organization. Mailbox stores contain the user and
system mailboxes and the Public Folder Store contains the Public Folders and their
contents. For most organizations, a single Storage Group, with one Mailbox Store and
one Public Folder Store is more than enough, however as the database grows in size,
splitting one large database into multiple smaller databases can ease the management of
backups.

A default Exchange installation will create a Storage Group that contains a Mailbox Store
and a Public Folder Store. Each Mailbox Store is made up of a database set that contains
two files:

• Priv1.edb is a rich-text database file that contains the email messages, text
attachments and headers for the users e-mail messages
• Priv1.stm is a streaming file that contains multi-media data that is formatted as
MIME data.

Similarly, each Public Folder Store is made up of a database set that also contains two
files:

• Pub1.edb is a rich-text database file that contains the messages, text attachments
and headers for files stored in the Public Folder tree.
• Pub1.stm is a streaming file that contains multi-media data that is formatted as
MIME data

For every EDB file there will be an associated STM file.

Exchange utilizes what Microsoft terms a single-instance message store. This single-
instance message store works on a per database basis. What does this mean? If an e-mail
message is sent to multiple mailboxes that are all in the same database, the message is
stored once and each mailbox has a pointer to the message. The transaction is also logged
in the transaction logs for the Storage Group that contains the database. However, if the
e-mail message is sent to multiple mailboxes that are located in different databases, the
message is copied to each database and written to the transaction logs for each Storage
Group that contains the database with a copy of the message.

For example, if I send 10 users a 1MB email message and all the mailboxes are located in
the same database, one copy of the message is written to the database and each mailbox
points to this message which will consume 1MB of disk space in total. If the 10 recipients
are located in two different databases, each database will get a copy of this message
which will consume 2MB of disk space. As you can see this is a much more efficient use
of space as opposed to the alternative of 10 1MB messages using up 10 MB of disk
space.

Aside from the database files, Storage Groups also contain system files and transaction
logs. There are two system files, Tmp.edb which is a temporary database where
transactions are processed, and E##.chk. The E##.chk file maintains the checkpoint for
the Storage Group. The ## represents the Storage Group number with the First Storage
Group file called E00.chk. This checkpoint file keeps track of the last committed
transaction. If you are ever forced to perform a recovery, this file contains the point at
which the replaying of transaction logs starts.

Transaction Logs
The transaction logs are some of the most crucial files when it comes to a working
Exchange server. Microsoft Exchange Server uses transaction logs as a disaster recovery
method that can bring a Exchange database back to a consistent state after a crash. Before
anything is written to the EDB file, it is first written to a transaction log. Once the
transaction has been logged, the data is written to the database when convenient.

Until a transaction is committed to the database, it is available from memory and

recorded in the transaction logs. This is why you will see store.exe use up to 1GB of
memory after the Exchange server has been in use for a while. After an Exchange server
is brought back up after a crash, the checkpoint file points to the last committed
transaction in the transaction logs which are then replayed from that point on. This form
of write-ahead logging is important for you to know.

There are four types of transaction logs:

• E##.log is the current transaction log for the database. Once the log file reaches
5MB in size it is renamed E#######.log and a new E##.log is created. As with
the checkpoint file the ## represents the Storage Group identifier. While the new
 E##.log file is being created you will see a file called Edbtmp.log which is a
template for Exchange server log files.
• E#######.log are the secondary transaction logs. They are numbered
sequentially starting with E0000001.log using the hexadecimal numbering format
and are 5MB in size.
• Res1.log is a reserved log file that is limited to 5MB in size. When the disk has
run out of space, transactions are written to this log file while you work on
clearing up space on the disk.
• Res2.log is another reserved log with the same function as Res1.log.

Transaction logs can grow at a fast pace as each and every transaction is recorded to the
log files. There are two ways to manage this growth with the recommended method being
a regular full backup of the Information Store. Upon successful backup, the transactions
are committed to the database and then purged.

The other method is to enable circular logging. Circular logging is disabled by default as
it only allows you to recover Exchange data since the last full backup. With circular
logging enabled the transaction logs are purged as the transactions are committed to the
database. If you have to restore from backup, the transaction logs will not be replayed
and all transactions since that backup will be lost.

The two reserved log files, Res1.log and Res2.log, are used to “save” 10MB of space on
the disk in case there is no more free space. When the disk runs out of free space, the
transactions are logged to the reserve logs as the Information Store shuts down
gracefully. You will not be able to restart the Information Store service until you clear up
some disk space.

Best Practices
As with anything there are some best practices you can follow in order to maintain a
healthy Information Store.

• Locating the Exchange program files, SMTP queues, transaction logs and
database files on separate disk arrays is ideal. If budget constraints will not allow
for this, locating the program files, transaction logs and SMTP queues on separate
partitions on one disk array and the database files on a separate disk array will
still offer some performance increases at a reduced cost.
• All files should be located on redundant disk arrays. RAID 1 is the minimum
recommended level, with RAID 5 offering an increase in performance and RAID
10 offering the best performance but at an increased cost.
• Perform regular, full backups of the Information Store to commit the transactions
and flush the log files. This can be done with the native Windows backup tool,
NTBackup, or a third party solution. Even if you live on the wild side and do not
keep backups of your data, it is important to do this to prevent the disk from
filling up with log files and running out of space.
 • Do not use circular logging. As mentioned circular logging will not allow you to
replay the transaction logs limiting you to recovering only the data from the latest
full backup set.

The Information Store is the most critical component of Exchange Server 2000/2003 and
a proper understanding of its structure is important to know for anyone tasked with
managing and maintaining an Exchange server.

Using ESEUTIL Tools:

Before we start using ESEUTIL and ISINTEG ensure the following:

• Make a backup of your Exchange databases even if you think the files are
damaged and lost.
• Use ISINTEG and ESEUTIL with some understanding about what these tools
really do.
• Ensure that you have done all other tests before you use ESEUTIL and ISINTEG.
• Dismount the store (then it is accessible for offline defrag, tests and more).
Figure 1: Dismount the information store

ESEUTIL
ESEUTIL is a tool to defragment your exchange databases offline, to check their integrity
and to repair a damaged/lost database.

ESEUTIL is located in the \EXCHSRVR\BIN directory. This directory is not in the

system path so you must open the tool in the BIN directory or enhance the system path
with the \EXCHSRVR\BIN directory.
Figure 2: Change the system path to point to the \EXCHSRVR\BIN directory

ESEUTIL /D parameters

Figure 3: ESEUTIL parameters

Defrag
Exchange 2003 defragments the Exchange database every night. But this is only an
online defrag of the database. An online defrag doesn’t reduce the size of the information
store. To reduce the size of the databases, you must use an offline defrag.

When should I use an offline defrag?

Under normal conditions you don't need an offline defrag, but when you add tons of new
users due to a merger or aquisition or when you delete many objects from the store it can
be necessary to do an offline defrag.

You can do a space dump with ESEUTIL /MS to determine the space. Also ensure that
you have 110% free diskspace associated with the Exchange database size.

Figure 4: ESEUTIL /MS

ESEUTIL parameters for defragmentation

Figure 5: ESEUTIL Defrag parameters

Depending on the size of the information store and your hardware, the defrag process can
consume a lot of time.

Figure 6: ESEUTIL defragmentation status

Check the integrity of the Exchange database

You can check the integrity of your Exchange database with ESEUTIL /G.

Please read NOTE 1 carefully in the following screenshot.

Figure 7: ESEUTIL integrity check

To start the integrity check for the PRIV1.EDB database, type the following command:

ESEUTIL /G „C:\Program files\exchsrvr\mdbdata\priv1.edb“

Figure 8: ESEUTIL integrity check status

Disaster recovery
With a good backup in hand and Exchange databases and logfiles on different hard
drives, it is no problem to recover from an Exchange disaster.
Just restore the data from backup and initiate a roll forward of the transaction logs. Well
done, the Exchange information store goes online.

But what should you do when your backup isn't readable or you don't have a backup?
Here's how these tools come to play.

Before you start:

• Make sure that the databases are really not startable

• Check the Application log for Exchange events that can tell you the cause of the
failure
• Make a backup of the database
• Restart the server so that a soft recovery can be done

ESEUTIL /P parameters

ESEUTIL /p repairs a corrupted or damaged database. Ensure that you have a minimum
of 20% free disc capacity in association to the Exchange database size.

Figure 9: ESEUTIL repair modus

Example:

ESEUTIL /P „c:\program files\exchsrvr\mdbdata\priv1.edb“

/Se:\exchsrvr\mdbdata\priv1.stm /Te:\tempdb.edb

This command will repair the database PRIV1.EDB. If you have no .STM file, you can
create one with ESEUTIL /CREATESTM. Read more about this here.

After running ESEUTIL, you can open a detailled logfile called >database<.integ.raw to
see the results.

As a last Step run ISINTEG –fix -test alltests. You can read more about ISINTEG later in
this article.

ISINTEG
ISINTEG is used to do some tests on your information store and to fix some detected
errors and problems.

Figure 10: ISINTEG parameters

ISINTEG is the only repair utility that understands the Exchange database as an
Exchange database.

What does this mean? ESE is a generic database engine that can be used by different
applications (Exchange, Active Directory).

ESEUTIL looks into the database as just another ESE database, and can see their tables
and indexes. ESEUTIL just fixes the database tables.
Now it is time for ISINTEG. ISINTEG is aware of the relation between database tables
and records that turn them into folders and messages.

After you run ISINTEG –FIX, you will see many warnings but you can safely ignore
these messages. You should only pay attendtion to the end of ISINTEG. There should be
zero errors reported. If there is an error, run ISINTEG again.

This example shows ISINTEG –test folder

Figure 11: ISINTEG –test folder

Conclusion
ESEUTIL and ISINTEG are two powerful tools for ensuring the health of your Exchange
information store and a good resource to recover from failures in the store.

Use these tools with caution when you want to repair your information store. It is always
a good idea to make a backup before you use ESEUTIL to repair your Exchange
databases.

In this article I have explained only a few features of ESEUTIL and ISINTEG. For a full
understanding of these tools, read the following KB articles.

Changes of Information store in Exchange 2007

Introduction
During the early stages of the development phase of Exchange Server 2007, rumors about
changing the store to SQL circulated the Internet. But these plans were dropped relatively
quickly and chances are we won’t see an Exchange product where the store is based on
SQL before E15 (yes that’s the version after E14!). But this doesn’t mean that Exchange
Server 2007 doesn’t introduce any store related changes and improvements, because
although the Exchange still is based on a more or less unchanged ESE database a lot of
work went into providing a much more scalable, reliable, and optimized product which
performs better than was the case with previous versions of Exchange.

Exchange 2007 – A True 64-bit Application

It shouldn’t come as a surprise for any of you that only the 64-bit version of Exchange
2007 will be supported in production environments. Because Exchange 2007 is real
native 64-bit application, it can access much more memory which ensures high
performance and reliability as mailbox sizes and the number of user accounts per server
increase. The default mailbox as well as Public Folder size in Exchange 2007 is nothing
less than 2GB!

Figure 1: New Default Mailbox Limits in Exchange 2007

Because it’s a 64-bit application, Exchange 2007 reduces input/output (I/O) requirements
up to 75 percent in I/O per second. Exchange Server 2007 also makes better use of
existing storage systems and will allow Exchange administrators to use low-cost options
like Direct Attached Storage (DAS) in even the most demanding environments.

As you can see in Figure 1 the Deleted items and mailbox retention settings also have
changed. In Exchange 2003 the default deleted items retention setting was 7 days, but this
is 14 days in Exchange 2007. This is also true for Public Folders.

Exchange 2007 Storage Groups and Databases

A Storage Group is a grouping of Mailbox and/or Public Folder Databases, which shares
a single backup schedule and a single set of Transaction log files. Storage Groups are
managed using their separate server process and the idea behind splitting databases up in
Storage Groups is primarily to reduce the overhead that results from multiple sets of
transaction log files.

As most of you recall, Exchange Server 2003 Standard edition supported 1 Storage
Group and 2 Stores – one Mailbox and one Public Folder Store (when excluding the
Recovery Storage Group of course). Exchange Server 2003 Enterprise Edition supported
a total of 4 Storage Groups each containing a maximum of 5 store databases. The limit of
a database in Exchange Server 2003 Standard edition was 16 GB (although raised to 75
GB when Exchange 2003 Service Pack 2 was applied). There was no limit on a database
when talking about Exchange Server 2003 Enterprise edition (well actually there is a 16
Terabyte limit but this limit is caused by hardware).

Exchange Server 2007 comes in two flavors, a standard edition and an enterprise edition,
just like previous versions of Exchange. The Mailbox Server when talking about the
Exchange Server 2007 Standard edition supports a total of 5 Storage Groups and 5
databases. Unlike Exchange 2003 and previous versions of Exchange there’s no longer a
database storage limit in the standard edition. The Mailbox server in the Exchange 2007
Enterprise edition supports up to 50 Storage groups and a maximum of 50 databases per
server. Exchange 2007 allows you to create up to 5 databases in each Storage Group as is
the case with Exchange 2003, but best practice is to create 1 database per Storage Group.
So why should you have a one to one relationship between storage groups and databases?
Well primarily because you’ll be up and running a lot faster considering disaster recovery
scenarios, etc.
Figure 2: Database Management in Exchange Management Console

Like is the case with Exchange 2003 it’s still ok to keep all Storage Groups on the same
spindles, but in terms of performance it’s better to keep them separated, although this
would be quite unrealistic for most organizations that were using, for example, 30
Storage Groups!

As I already mentioned databases in Exchange Server 2007 are still based on a more or
less unchanged Extensible Storage Engine (ESE). As most of you are aware, ESE relied
on two databases files, an .EDB and a .STM file. The purpose of the streaming file
(.STM) was to house raw Internet content message streams as defined in Request for
Comments (RFC 822). Since the .EDB file isn’t very suitable for storing raw Internet
content message streams, the idea of introducing the .STM file was understandable, but
with Exchange Server 2007 the .STM file has been removed together with the Exchange
Installable File System (ExIFS). The reason behind this decision was in order to reduce
the overall I/O footprint for Exchange Server 2007.

However, unlike previous versions of Exchange, Exchange Server 2007 no longer

maintains single-instance storage of message bodies, only for attachments. There is one
exception to this rule and that is when a set of mailboxes has been moved from an
Exchange 2000 or 2003 Mailbox store to an Exchange 2007 Mailbox database during a
transition. In this situation Exchange 2007 maintains single-instance storage for both
attachments as well as message bodies. For additional details see this blog post on the MS
Exchange Team blog.

Transaction Log File Size Changes

Another change in Exchange Server 2007 is that the transaction log files are now 1MB
instead of 5MB as was the case in previous versions of Exchange.

Figure 3: New Transaction Log File Size in Exchange 2007

So what’s the reason behind this decision? Well in previous versions of Exchange if a
crash destroyed the last few log files that hadn’t been committed to the database yet, you
would need to restore or repair the database to have it mounted again. Exchange Server
2007 introduces a new feature called Lost Log Resilience (or LLR in short) which will
hold the last few log files in memory until the database is shut down. This means that you
will never have a case where part of for example log file 5 has been written to the
database, but part of log file 4 hasn’t. The benefit of this is that if you don’t have
anything against losing the last few log files, you can tell Exchange to simply throw away
the data and mount the database.

So the reason why the log files has been reduced to 1MB is to reduce LLR exposure.
Now if you lose the last log, it costs up to 1MB of the most recent data instead of 5MB.

Another improvement worth mentioning is that the log file sequence numbers now can go
above 1 million. As some of you might be aware previous versions of Exchange had a
limit of 1 million, so if a database had been running long enough to generate a million
logs, you had to shut it down and start over from log #1 ("reset the log sequence"). This
would happen every few years for most databases. With the smaller log sizes and the
increasing amount of messages passing through most databases, the Exchange Product
group decided 2 billion log files (per storage group!) would be a better maximum log
number.

Public Folders
Public Folders are still supported in Exchange server 2007, but bear in mind they have
been de-emphasized which means that there’s a good chance they won’t be included in
the next version of Exchange (currently codenamed E14). With this in mind it’s a good
idea to start thinking about migrating to another solution such as SharePoint.

Note:
Even though Public folders have been de-emphasized in Exchange Server 2007,
Microsoft will support them until the end of 2016, so you have got plenty of time.

One major drawback is that the Public Folder related administration tasks you can do
from within the Exchange Management Console are extremely limited. So if you need to
do tasks other than create, delete and move Public Folder databases as well as configure
limits, etc. you will, depending on the specific task, need to do so using either the
Exchange Management Shell, an Outlook client or System Manager on an Exchange
2003 Server still part of the Exchange organization.

Figure 4: Creating a Public Folder using the Exchange Management Shell

So if your organization makes heavy use of Public Folders, I recommend you keep an
Exchange 2003 Server running in your organization, until you have migrated away from
the Public Folder hierarchy or until Exchange 2007 SP1 is released (which hopefully
includes administration tasks in the EMC GUI!).

High Availability with Exchange 2007

As you probably have seen in some of my recent Exchange 2007 articles, Exchange 2007
also includes several new high availability features such as Local Continuous Replication
(LCR), Cluster Continuous Replication (CCR) and Single Copy Clusters (SCC). I won’t
dig into those here but instead refer you to the respective articles:

• Demystifying the Local Continuous Replication (LCR) feature

• Installing, Configuring and Testing an Exchange 2007 Cluster Continuous
Replication (CCR) Based Mailbox Server (3 part article series)
• Installing a Two Node Exchange Server 2007 Single Copy Cluster (SCC) in a
Virtual Server Test Environment (3 part article series)

Note that LCR are supported with Exchange 2007 Standard edition, but that you need the
Exchange 2007 Enterprise edition in order to take advantage of the CCR and SCC
features. Since both CCR and SCC are based on the Microsoft Clustering Service
(MSCS), you also need to make sure you install Exchange 2007 on a server with
Windows 2003 Server Enterprise edition if you want to use these features in your
environment.

That was all for this time, you should now be even better prepared for the planning phase
of Exchange 2007 deployment in your organization.

Working of Recovery Storage in Exchange 2007

Introduction
The Recover Storage Group (RSG) feature, which was originally introduced back in
Exchange 2003, gives you as the Exchange administrator, the option of mounting a
second copy of a mailbox database (typically a mailbox database restored from backup)
so that you can extract data from one or more mailboxes in the respective database
without affecting the production databases if you need to do so during working hours.

Depending on how much you have used the new Exchange 2007 Management Console
(EMC), there’s a chance you may have noticed you can no longer create an RSG from
within the EMC. With Exchange 2007 this is instead done using the Exchange
Troubleshooting Assistant (ExTRA) which is launched via the Database Recovery
Management tool, which is found under the Exchange Toolbox work center, or by using
the Exchange Management Shell (EMS).

When mounting a copy of a Mailbox database to an RSG you can extract the data from a
mailbox and then merge the data with another mailbox located in a mailbox database in a
production Storage Group, but you can also extract the data and then copy it to a specific
folder in another mailbox.

Note
With Exchange 2003 RTM, the data was extracted, copied and merged with another
mailbox or mailbox folder using the Microsoft Exchange Server Mailbox Merge Wizard
(ExMerge) tool, but with Exchange 2003 SP1 the process was integrated in the Exchange
2003 System Manager GUI.

Recovery Storage Group Limitations

There are a few things you should be aware of when dealing with RSGs. First they cannot
be accessed by any protocols other than MAPI, and although they can be accessed using
MAPI this doesn’t mean you can connect to a Mailbox stored in a recovery database
using an Outlook MAPI client. MAPI is strictly used to access mailboxes using the
Exchange Troubleshooting Assistant (ExTRA) and/or the respective cmdlets in the
Exchange Management Shell. In addition you should be aware that you still cannot use
RSGs to restore Public Folder data but only mailbox data. It’s also worth mentioning that
even though you can create up to 50 Storage Groups on an Exchange 2007 Enterprise
edition server, you’re limited to one RSG per server, but it’s supported to add multiple
mailbox databases to an RSG as long as all databases belong to the same Storage Group.
Finally you should note that although it’s possible to add a restored mailbox database to
an RSG on another Exchange 2007 server, it’s important to understand that the Exchange
2007 server must belong to the same Active Directory forest.

Managing Recovery Storage Groups using the

Exchange Troubleshooting Assistant
You can create a Recovery Storage Group (RSG) either by using the Microsoft Exchange
Troubleshooting Assistant (ExTRA) tool, or by running the New-StorageGroup cmdlet
with the –Recovery parameter in the Exchange Management Shell.

To create the RSG using ExTRA you should first launch the tool by opening the
Database Recovery Management tool found under the Toolbox work center in the
navigation tree of the Exchange Management Console (EMC). Now let the tool check for
any tool or configuration file updates that may be available then click the Go to Welcome
screen link. Now enter an indentifying label for this activity (such as Create RSG) then
click Next. On the appearing Tasks list click Create a Recovery Storage Group then
select the Storage Group you want to link with the Recovery Storage Group as shown in
Figure 1, then click Next once again.
Figure 1: Selecting the Storage Group to link with the RSG

Now it’s time to create the RSG, but before you do so you need to give it a name (the
default name is Recovery Storage Group which should be ok in most situations). When
you have entered an appropriate name, click Create the recovery storage group (Figure
2).
Figure 2: Creating the RSG

After a little while you will be presented with a screen similar to the one in Figure 3 and
the RSG for the respective Mailbox Database has now been created.
Figure 3: RSG Result

With the RSG created we can move, copy or restore database and transaction log files to
the recovery storage group paths. To see the path for the recovery storage group log and
database files, click Show Create Recovery Storage Group Information. By default the
path is C:\Program Files\Microsoft\Exchange Server\Mailbox\<Storage
Group>\RSGxxxxxxxxx as you can see in Figure 4. The RSGxxxxxxxxx folder will
appear empty in Windows Explorer until you have either moved, copied or restored the
database and transaction log files to it.
Figure 4: Storage Group and Recovery Storage Group Paths

For the purpose of the example in this article, we will restore a Mailbox Database from a
backup using the Windows 2003 Backup tool. So let’s launch the Windows 2003 Backup
tool by clicking Start | Run and typing cmd.exe followed by hitting Enter. Since we will
restore the Mailbox Database by using this tool in Advanced Mode, click Advanced
Mode. Now select the Restore and Manage Media tab. Here we need to select the
Mailbox Database and Log Files we want to restore, when you have done so click the
Start Restore button.

Note
The Restore files to: drop-down box is set to Original location. Also notice we cannot
change this selection. But does this mean the Mailbox Database currently in production
will be replaced with the one we restore from backup? No this is not the case, first we
haven’t dismounted the production Mailbox Database and second we haven’t enabled the
This database can be overwritten by a restore option on the Mailbox Database property
page. Because of this the Mailbox Database will be restored to the Recovery Storage
Group which we just created.

Now specify the Exchange Server to which you want to restore the respective Mailbox
Database, then enter a temporary location for the log and patch files. Lastly check Last
Restore Set (Log file replay will start after this restore completes.) as this is the last
restore set. When you have done so, click OK and wait for the restore job to complete
then click the Close button.

The respective files have now been restored to the RSGxxxxxxxxx folder as you can see
in Figure 5.
Figure 5: Restored Mailbox Database in Windows Explorer

Since we didn’t check the Mount Database After Restore option, the Mailbox Database
will now be in a dismounted state, with this in mind let’s switch back to the ExTRA Task
Center. As shown in Figure 6 we now have several new Recovery Storage Group related
tasks available, since the Mailbox Database needs to be mounted before we can extract
data from it, we have to click Mount or dismount databases in the recovery storage group.
Figure 6: Selecting Mount or dismount databases in the recovery storage group

On the Mount or Dismount Database page, check the Respective Mailbox Database and
click Mount selected database (Figure 7).
Figure 7: Mounting the Mailbox Database using the ExTRA Tool

When the Mailbox Database has been mounted click Go Back to task center and then
select Merge or copy mailbox content. This will bring us to a screen similar to the one
shown in Figure 8, here you should just make sure the Mailbox Database you wish to
extract data from is selected, and then click Gather merge information.
Figure 8: Selecting a Mounted Database in the Recovery Storage Group

We now have the option of swapping the Mailbox Database mounted to the RSG and the
linked production Mailbox Database (a recommended step if you’re performing a dial-
tone database restore) by checking Swap database configurations as can be seen in
Figure 9. Since this option will swap the two databases, both of them needs to be
dismounted, which will affect mail service to the end-users whose mailboxes are stored in
the respective database.

Since we aren’t dealing with a dial-tone database restore in this example just click Next.
Figure 9: Database Swap Option

On the Select Merge Options page we should click Perform pre-merge tasks (Figure 10).

Note that you have the option of clicking Show Advanced Options. Under the Advanced
options we can specify different match and filtering options as well as the bad item limit.
This is also the place where you specified whether all merge mailbox data should be
merged to the respective mailboxes in the production Mailbox Database or should be
copied to a single target mailbox.
Figure 10: Specifying Merge Options

Final step is to select the mailboxes you want to merge. You do this by checking the box
to the left of each user name in the list as shown in Figure 11.
Figure 11: Selecting the Mailboxes to Merge

Now wait for the tool to merge the mailbox data from Mailbox Database in the Recovery
Storage Group for the selected mailbox. When the mailbox data merge has completed,
you should be able to see the content that was deleted from the production Mailbox
Database. You don’t even need to restart the Outlook or OWA client for the restored data
to appear!

When you have merged or copied the required Mailbox data, you can use ExTRA to
dismount and then remove the Recovery Storage Group. Be sure you remove the files in
the RSGxxxxxxxxx folder again after you have removed it, so that the files don’t take up
valuable disk space.

Working with Recovery Storage Groups using the

Exchange Management Shell
As mentioned in the introductory, you can also manage an RSG using the Exchange
Management Shell (EMS). If you have a fair amount of experience working with
cmdlets, restoring mailbox data from a Mailbox Database in a Recovery Storage Group
can be done a lot faster than when using ExTRA.
The first step is to create the RSG. In order to create an RSG via the EMS you need to
run the New-StorageGroup cmdlet with the –Recovery parameter. So to create a RSG for
the First Storage Group on a server named E2K7S04, type:

New-StorageGroup –Server E2K7S04 –LogFolderPath “E:\Program

Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG –Name
“Recovery Storage Group” –SystemFolderPath “E:\Program
Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG” –Recovery

The LogFolderPath and SystemFolderPath parameters are used to specify where the RSG
related files should be located. As you can see, we specified they should be restored to a
subfolder called RSG under E:\Program Files\Microsoft\Exchange Server\Mailbox\First
Storage Group\RSG. If you intend to do the same please make sure there’s sufficient disk
space available for the Mailbox Database you’re restoring from backup.

To see if a respective Storage Group is a Recovery Storage Group (as well as many other
types of information) you can use the Get-StorageGroup <storage group name> | FL
command. If the Storage Group is a Recovery Storage Group it will say True under
Recovery as shown in Figure 12.

Figure 12: Full List of Recovery Storage Group information

The next step is to add a recovery database (either moved, copied or restored from
backup) to the RSG, this is done by running the New-MailboxDatabase cmdlet with the
MailboxDatabaseToRecover parameter. So to add a recovery database to the Recovery
Storage Group on a server named E2KS04 with the edb file path pointing to E:\Program
Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG, type:

New-MailboxDatabase –MailboxDatabaseToRecover “Mailbox Database” –

StorageGroup “E2K7S04\Recovery Storage Group” –EDBFilePath “E:\Program
Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG\Mailbox
Database.edb”

With the Mailbox Database created in the Recovery Storage Group we now need to
configure it to allow overwrites by running the Set-MailboxDatabase cmdlet with the –
AllowRestore parameter. To allow file restores for the recovery database just created,
type:

Set-MailboxDatabase -Identity "E2K7S04\Recovery Storage Group\Mailbox

Database" -AllowFileR
estore $true

Now that we have created a recovery database in the Recovery Storage Group and
allowed it to be overwritten by a file restore, it’s time to restore the mailbox database
version from which you want to extract and copy or merge data to the mailbox database
in production. To do so launch the Windows 2003 Backup tool and restore the respective
Mailbox Database version using the same steps as we did when we used the ExTRA to
recover Mailbox data.

We now need to mount the restore Mailbox Database using the Mount-Database cmdlet.
In order to do so type:

Mount-Database –Identity “E2K7S04\Recovery Storage Group\Mailbox Database”

With the Mailbox Database mounted we can now extract Mailbox data from it. If you for
example want to merge the mailbox data of an existing user in the recovery database to
the production mailbox database, you need to type:

Restore-Mailbox –Identity <username> -RSGDatabase “servername\RSG

name\database name”

In Figure 13 we recovered mailbox data for a user called Test User 1on a server name
E2K7S04.

Figure 13: Restoring Mailbox Data from a Mailbox in a Recovery Storage Group
Note
Depending on the size of the mailbox that is to be recovered, this merging process can
take a long time.

If you need to recover mailbox data for all users in the RSG, you would need to use the
following command:

Get-MailboxStatistics -Database “Recovery Storage Group\Mailbox Database” |

Restore-Mailbox

Let’s suppose the mailbox in the recovery database from which you want to recover data
in the meanwhile has been deleted from the production mailbox database. In this case you
have the option of recovering the mailbox data to a target folder in another mailbox by
using the following command:

Restore-Mailbox –RSGMailbox “Test User 1” -RSGDatabase “servername\RSG

name\database name” –Identity “Test User 2” –TargetFolder “Test User 1 Recovered
data”

Like is the case when recovering data using the ExTRA tool, you should, when using the
Exchange Management Shell, remember to remove the RSG after the required data has
been recovered. To do so, first run the command to remove the recovery database:

Remove-MailboxDatabase –Identity “E2K7S04\Recovery Storage Group\Mailbox

Database”

Click Yes to the confirmation warning, then type the following command in order to
remove the RSG:

Remove-StorageGroup –Identity “E2K7S04\Recovery Storage Group”

Finally delete the RSG folder manually using Windows Explorer.

Conclusion
As you have seen throughout this article, the way we work with Recovery Storage
Groups (RSGs) has changed quite a lot with Exchange 2007. RSG’s can no longer be
managed using the Exchange Management Console (formerly known as the Exchange
System Manager); instead you need to use the Exchange Troubleshooting Assistant
(ExTRA) or the Exchange Management Shell (EMS). But despite the new methods used
to manage RSGs, not much has changed when speaking RSG improvements. For
example it’s still not an option to restore a Public Folder database to an RSG.

Transaction Log files:

Introduction
One of the most important components of Exchange server is the transaction logs.
Exchange server was designed to write all transactions to these log files and commit the
changes to the databases when the system allows. Users can send and receive messages
without touching the database thanks to this write-ahead method of logging.

When a message is sent, the transaction is first recorded in the transaction logs. Until the
transaction is committed to the Exchange database (EDB), the only existence of this data
is in the system memory and the transaction logs. In the event of a crash, you lose the
contents of the memory and all you are left with is the record in the transaction log. These
transaction logs are crucial to the recovery of a failed Exchange server, whether it was a
minor crash that required a reboot, or a more catastrophic failure requiring the
deployment of your disaster recovery plans. The same goes for other transactions such as
received messages, deleted items and messages moved to different folders.

For this reason, it is recommended to house the transaction files on a redundant storage
system, like a RAID 1 array, so that in the event of a hardware failure, no data is lost.
Losing a set of transaction logs will not prevent you from restoring from your backups,
but you will lose all the messages and changes since the last full backup.

Understanding Message Headers

When an Exchange server is started, and the Microsoft Information Store (Store.exe)
comes online. ESE checks the databases to determine whether they are in a consistent
state or/and inconsistent state. This information is stored with a flag in the database
header and signifies whether the store was shutdown cleanly (consistent) or if there are
outstanding transactions in the transaction logs that have yet to be committed. If you want
to determine if the database is in a consistent, or inconsistent, state you can use ESEUTIL
and append the /MH switch which will check the database header and report the state.

C:\Program Files\Exchsrvr\bin\eseutil /mh “Path\to\file.edb”

Running this command you will see some important information on the state of the
database (see Figure 1) as well as information on the backup state (see Figure 2).
Figure 1: Database State

Figure 2: Database Backup Timestamp

If ESE detects any inconsistency, it performs what is called a soft recovery. In a soft
recovery, the transaction logs are replayed to locate any transaction not yet committed to
the database. With multiple databases in a single Storage Group, the processing can be
quite complex. All the databases in a storage group use the same set of transaction logs
and it is possible that each database is in a different state of consistency. Luckily for
administrators, ESE handles this all in the background without any administrator
interaction required.

Viewing Transaction Logs

Opening a transaction log for viewing can be done with any text editor such as Notepad
or WordPad, but there is not much human readable text. The majority of the transaction
log is comprised of binary and non printable characters (see Figure 3).
Figure 3: Viewing Transaction Log

Not much to see, but that is not to say looking at a transaction log is completely useless
as there is some useful information that can be found. If you scroll through a log file you
can find header information (see Figure 4) and data, but because the transaction logs are
limited to 5MB in size, the data can end up being spread over multiple transaction logs.
As an example, let’s say that a user sends a 6MB Excel file; the first 500KB maybe
written to a transaction log, filling it up and triggering the creation of a new log. This
next log could be compromised of the next 5MB of the Excel file, and the rest of the data
going into a third transaction log.
Figure 4: Message Headers

Along with the header information, you will also be able to see timestamps for when the
log was created and a unique signature matching the transaction log to the database. The
signature is important as it ensures transactions are committed to the proper database. If
you tried to replay transactions to a different database the outcome could be disastrous.

Dumping Log Information

Just like when we used ESEUTIL with the /MH switch to view the state of the database,
we can use the same tool with the /ML switch to dump the header information of a log
file.

C:\Program Files\Exchsrvr\bin\eseutil /ml “Path\to\transaction.log”

Running this command will dump the header of the transaction log and allow us to garner
some important information. Let’s look at the first half of the dump (see Figure 5) and
what some of that data means and then we will look at the second half.
Figure 5: Log Header Information

Starting from the top we will see:

• Base name – The base name will show as e00 as that is the name of the log when
it was generated. Once full, it is renamed and a new e00 log is generated.
• Log file – This is the current name and location of the log file.
• lGeneration – This is the generation number. In this example the number is 36307
meaning that there are 36306 previously generated logs.
• Checkpoint – This line specifies which position the checkpoint file (e00.chk) was
in when this log was created. This example says NOT AVAILABLE which is not
a concern as another log file will have this information.
• Creation time – This is the time when this log was created.
• Prev gen time – This is the time when the previous log was generated.
• Env Systempath – Specifies the location of the checkpoint file.
• Env LogFilePath – Specifies the location of the transaction logs.
• Signature – The ties the transaction log to a specific database.
• Circular logging – This information determines if circular logging is enabled or
disabled.

One piece of information to note from this is the time between the Creation time and the
Prev gen time. In this example the time difference is 49 minutes and 37 seconds, which
tells us that this server is not under much load. If the time stamps were a lot closer
together, this would indicate a server that is under load.

The second half of this dump file (see Figure 6) contains the database information. Each
storage group has its own set of transaction logs and each storage group can contain
multiple databases. This section of the log specifies which databases these log files
belong too.
Figure 6: Database Associations

Transaction Log Best Practices

In order to maintain your transaction logs and a healthy Exchange server, there are some
best practices you should follow.

• Perform regular full backups to commit the transactions and flush the logs.
• Transaction logs create a high write load and should be moved to a dedicated
drive that can support a heavy write load.
• Protect transaction logs by placing them on a redundant array. RAID 1 is ideal for
transaction logs. RAID 5 is not as write friendly and RAID 1+0 is overkill in most
instances.
• Ensure there is enough room on the drive to contain all the transaction logs
created between backups. If the drive runs out of room, the MTA will stop and
Exchange will stop functioning.
• Do not place transaction logs on compressed drives as they will need to be
decompressed whenever Exchange access them. This will slow the system down.
• Do not use circular logging except in cases where the Exchange server does not
hold any mailboxes (i.e. NNTP servers).

Backup Types of Exchange

Basics
Windows 2003 has a Built-In Backup program called NTBACKUP which you can use to
backup your Windows environment and when you had installed Exchange 2003 on this
system, NTBACKUP is enhanced to allow backups of your Exchange Server databases.

NTBACKUP features
 • Local and remote backup of data
• Exchange Backup ready
• Scheduled Backups
• Volume Shadow Copy support
• Integration with Removable Storgae from Windows 2003

How do you enhance NTBACKUP with the capability to Backup Exchange 2003
without installing Exchange Server?

You must install the Exchange System Manager on the Backup Server to backup
Exchange Server. It is possible to backup the Exchange Server without Exchange System
Manager with the following trick:

Copy ESEBCLI2.DLL from the Exchange 2003 CD into the EXCHSRVR\BIN folder

Add the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\DLL
Paths – REG_EXPAND_SZ - esebcli2 - c:\exchsrvr\bin\esebcli2.dll.

After modifying the registry you can use NTBACKUP to backup the remote Exchange
Server by clicking – Tools – Remote Store.

Online or Offline Backup?

It is possible to Backup Exchange Online or Offline. The recommended method is to
Backup the Exchange Server Online. An online backup can backup the Exchange Server
databases without the interruption of Exchange services.

An offline backup is a simple copy of the Exchange database files. The Exchange
Information store must be stopped before NTBACKUP can be used to Backup your
Information store.

Volume Shadow Copy

Beginning with Exchange 2003 it is possible to do Exchange 2003 Volume Shadows
Copy backups with 3rd party Backup applications, but not with the built-in Windows
Server 2003 NTBACKUP utility.

The Volume Shadow Copy service coordinates its communication between Requestors
(backup applications), Writers (applications like Exchange Server 2003), and Providers
(software or hardware components that create the shadow copies). To use the Volume
Shadow Copy service to backup Exchange Server 2003, the backup program must
include an Exchange Server 2003 aware Volume Shadow Copy service requestor.
Because the NTBACKUP program has no such requestor, organizations must use third-
party backup applications or implement Exchange 2003 SP1 in its organization.

Backup choices

• Minimum selection is the storage group (SG) to truncate log files

• VSC can create a Snapshot from multiple SG at the same time

Restore choices

• You can choose the entire storage group or a single database or multiple databases
from a single SG
• Exchange 2003 RTM supports full backups and copy backups
• All databases must be mounted to purge logfiles

Backup
To start the Backup process click Start – Run – NTBACKUP.

Figure 1: Start the Backup process

During an online backup, the .edb, .stm, and .log files that comprise the Exchange store
are being backed up and checked for corruption. The Exchange database store is checked
for corruption at file system level. File system level damage may be caused by unreliable
hardware, firmware, or disks. This check is done by verifying the checksums on each 4
KB block or page in the database. If there is a checksum failure, backup will terminate
(Exchange will not allow you to back up an Exchange store with a wrong checksum in
it). This is tpyical for the 1018 error.
Choose a place to save the Backup files.

Figure 2: Choose a Backup device

It is possible to disable Volume Shadow Copy.

Figure 3: NTBACKUP options

The Backup process will begin.

Figure 4: The running NTBACKUP process

You can see the status of your Exchange Backups when you start the event viewer and
select the application log.

Figure 5: NTBACKUP status in the event log

Transaction Log files and NTBACKUP

Backup Type What to Backup Exchange Logs
Normal Backs up selected files and marks each Backup Logfiles and delete
file as backed up Transaction Logfiles
Copy Backs up selected files, but does not Backup Logfiles but doesn’t
mark any as backed up delete Transaction Logfiles
Incremental Backs up selected files only if they were Backup only Logfiles but
created or modified since the previous cannot be used with enabled
backup circular logging
Differential Backs up selected files only if they were Backup only Logfiles but
created or modified since the previous cannot be used with enabled
backup, but does not mark them as circular logging. Logfiles will
backed up not be deleted after Backup

The type of Backup depends on the configuration of circular logging. You can specify
circular logging settings at the Exchange Storage Group level.

Figure 6: Circular Logging settings

Restore
After a succesful Backup it is possible to do an Exchange Server restore in case of
emergency.
You must ensure that the Exchange database store to restore is not mounted. You can
dismount a Exchange Database Store in the Exchange System Manager by right clicking
the database.

Start the NTBACKUP program and select Restore and Manage Media.

Figure 7: NTBACKUP restore process

In the following screen you must select the Server to restore the data, a temporary
location for log and patch files (this directory must be empty).

Click Last Restore Set when this is the last restore device (this is also possible with
ESEUTIL)

Click Mount Database after Restore if you want to automatically start the restored
database.
Figure 8: restore options

Depending on the size of the database, the restore process can be very time consuming.

Figure 9: Restore Progress

You can read the Logfile after an successful or unsuccessful Exchange restore.
Figure 10: NTBACKUP Logfile

The following screenshots shows the Exchange Server MDBDATA directory. As you can
see, there are now more Exchange Server Transcation Logfiles except the actual logfile.

Figure 11: NTBACKUP Logfile

Conclusion
The Built-in Windows 2003 NTBACKUP program is suitable for small and medium
sized Exchange organizations which don't want to buy an expensive Third Party Backup
program.

1..Normal/full backups:- All files that have been selected

are backed up,

2.Copy backups:- All files that have been selected are

backed up, regardless of the setting of the archive
attribute.
3.Differential backups:- Designed to create backup copies
of files that have changed since the last normal backup.
The presence of the archive attribute indicates that the
file has been modified and only files with this attribute
are backed up.

4..Incremental backups:- Designed to create backups of

files that have changed since the most recent normal or
incremental backup. The presence of the archive attribute
indicates that the file has been modified and only files
with this attribute are backed up. When a file is backed
up, the archive attribute is cleared. If the file is later
modified, this attribute is set, which indicates that the
file needs to be backed up.

5..Daily backups:- Designed to back up files using the

modification date on the file itself. If a file has been

modified on the same day as the backup,

What is Circular Logging?

In a nutshell circular logging recycles the logs. Exchange relies on transaction or

write-ahead logs to store events before they are committed to the database. When
4 logs have been filled up, Circular logging assumes that the first log must have been
committed and recycles the logs to save disk space.

No Circular Logging Circular Logging

Log Numbers Disk Usage Log Numbers Disk Usage

1234 20 MB 1234 20 MB

12345 25 MB 2345 20 MB

123456 30 MB 3456 20 MB

Problem with Circular Logging

The fatal flaw with Circular Logging is it restricts disaster recovery. If you allow
Circular Logging to over-write the transaction logs then Exchange 2003 can only
restore as far as the last backup. When all the logs are available, Exchange 2003
automatically rolls forward the logs and replays the transactions up until the
Exchange Store stopped working.

In fact, circular logging prevents Exchange 2003 making differential or incremental

backups. So with circular logging in place, you are restricted to normal (full) backup.
 Where do you check the circular logging setting?

1. Open the Exchange System Administrator, locate the

Servers Icon.
2. Drill down to the Storage Group where you want to
enable circular logging. (Note Storage GROUP not Store...)
3. Right-click (The Storage Group), and select Properties.
4. On the General tab, tick Enable circular logging, and
then click Yes.

Why does Exchange 2003 have such a risky setting?

The main justification for circular logging is when you are very short of disk space.
Even in this situation Exchange 2003 has two files Res1.log and Res.log. However
these logs are only for the emergency when the disk is truly full. Exchange writes all
uncommitted transactions to these files, then shuts down the server.

Other suggestions for Circular Logging are for public folders or newsgroups where
you are less concerned with recovery since the last backup.

Disaster Recovery of Exchange 2003 Stores

When an email arrives, Exchange 2003 writes a transaction to the log. If the
server's disk is busy there will be a delay before the information is committed to the
store database file. Exchange also uses a checkpoint file. This file (E0.chk) records
which transactions have been written to the store database (Priv1.edb).

So, if you allow circular logging to over-write some of those transaction logs, then
you cannot recover any data after the last backup. However, if you disable circular
logging, then you Exchange 2003 replays the transactions and restores the Exchange
store to how it was before the disaster. This re-reading the logs is called a hard
recovery and happens automatically.

Summary of Circular Logging in Microsoft Exchange Server 2003

If you want a successful restore of Exchange Server 2003, then avoid circular
logging. There is only one occasion to select circular logging, and emergency in
which you are short of disk space.

Exchange 2007 extends AD schema

Microsoft Active Directory uses the Schema to represent the classes, attributes and
objects that are used to display what you can see in the GUI of the Active Directory
Users and Computers Snap In or other Snap Ins. The schema is part of the Schema
partition in Active Directory and the Schema partition will be replicated through all
Active Directory domain controllers in the Forest.

Because Active Directory schema changes are an important part of a healthy Active
Directory environment, only members of the Schema Administrators and Enterprise
Administrator groups have the right to extend and manage the Active Directory schema.

Requirements
Since Exchange Server 2007 is a 64bit application, you cannot install Exchange Server
2007 on a 32bit Server; but it is possible to use the Exchange 2007 32bit version for
Active Directory Schema extension. It is possible to extend the Active Directory schema
with a 32bit trial version of Exchange Server 2007 on a 32bit Windows 2003 machine.

You should always use the Active Directory Schema Master for expanding the Schema
for Exchange Server 2007 because of replication traffic.

Exchange Server 2007 prerequisites:

A successful Exchange Server 2007 installation depends on a lot of prerequisites. You

will need the following updates before installing Exchange Server 2007:

• Windows PowerShell 1.0 English-Language Installation Package for Windows

Server 2003 (KB926139)
• Microsoft .NET Framework Version 2.0
• .NET Framework Update for .NET Framework Version 2.0
• Microsoft Management Console (MMC) 3.0 if Windows Server 2003 R2 is not
used

Extending the Active Directory schema

If the user who is installing Exchange 2007 is a member of the Schema and Enterprise
Administrators group, Exchange setup automatically extends the Active Directory
schema and you don’t have to run the Active Directory extension manually. This
procedure is not common in larger environments where the Active Directory and
Exchange Management are strictly separated.

For this reason it is possible that a Windows Server 2003 Active Directory Administrator
who is a member of the Schema and Enterprise Administrators group can extend the
Active Directory schema without installing Exchange Server 2007.

Exchange Server 2003 uses the Setup switch Setup /Forestprep to expand the Windows
Active Directory schema but Exchange Server 2007 uses a new tool to extend the Active
Directory schema called SETUP.COM, which can be used with various parameters.
It is one of these parameters that you need to extend the Active Directory schema…

Setup.com /prepareschema

This setup parameter is responsible for adding additional schema attributes to the Active
Directory Schema which will be used by Exchange Server 2007 and its subsystems. This
Setup parameter is used in conjunction with the Setup.com /
PrepareLegacyExchangePermissions parameter, if Exchange Server 2007 is installed
into an existing Exchange Server 2003 environment.

Setup /PrepareLegacyExchangePermissions

This setup parameter prepares Exchange Server 2003 for interoperability between
Exchange Server 2003 and Exchange Server 2007. It requires Enterprise Administrator
rights and will be executed as part of the /PrepareSchema switch. Read more about this
setup switch at http://technet.microsoft.com/en-us/library/bb125224.aspx. You only have
to do this if it is a fresh Exchange Server installation.

Schema extension files

Exchange Server 2007 setup uses, like Exchange Server 2003, a lot of Schema extension
files in LDF (Lightweight Directory Exchange) format. During Schema extension, these
files will be imported into Active Directory. Exchange Server 2007 will use a lot more
Schema extension files, as you can see in the following image.
Figure 1: Schema extension files

The following image shows an example of a Schema definition file. The file you will see
here is called Schema0.ldf. This file and others will be imported during the Exchange
Server 2007 installation or the manual execution of Setup.com /prepareschema.
Figure 2: Detailed view of Schema0.ldf file

Use ADSIEDIT to view all Schema extensions during

Exchange Server 2007 setup
You can use ADSIEDIT to view all Schema entries in the Schema partition of Active
Directory. ADSIEDIT is one of the Windows Server 2003 Support tools which you can
find on the Windows Server 2003 installation CD.
Figure 3: Active Directory Schema partition after Schema extension

Setup.com /preparedomain

If you have other domains in which you would like to install Exchange 2007 Server,
execute the following command:

setup.com /PrepareAD

Property sets in Exchange Server 2007

You can use property sets in Exchange Server 2007 for attribute grouping that enables
access control for specific object properties. Property sets use one single Access Control
Entry (ACE) instead of an ACE for each individual property.

Exchange Server 2007 creates two new property sets exclusively for itself and doesn’t
use existing Active Directory property sets. During Active Directory Schema extension,
Exchange Server 2007 performs the following actions:

• Extends the Active Directory schema with new classes and attributes.
• Creates the property sets for Exchange Server 2007 and Exchange Information
and Exchange Personal Information.
• Adds the appropriate attributes to the Exchange Information and Exchange
Personal Information property sets.

Exchange Server 2007 SP1 Schema Extensions

Exchange Server 2007 SP1 comes with a lot of additional Schema extensions:

• ms-Exch-Foreign-Forest-Public-Folder-Admin-USG-Sid,<SchemaContainerDN>
• ms-Exch-Internal-NLB-Bypass-Host-Name,<SchemaContainerDN>
• ms-Exch-Mobile-Additional-Flags,<SchemaContainerDN>
• ms-Exch-Mobile-Allow-Bluetooth,<SchemaContainerDN>
• ms-Exch-Mobile-Allow-SMIME-Encryption-Algorithm-
Negotiation,<SchemaContainerDN>
• ms-Exch-Mobile-Approved-Application-List,<SchemaContainerDN>
• ms-Exch-Mobile-Max-Calendar-Age-Filter,<SchemaContainerDN>
• ms-Exch-Mobile-Max-Email-Age-Filter,<SchemaContainerDN>
• ms-Exch-Mobile-Max-Email-Body-Truncation-Size,<SchemaContainerDN>
• ms-Exch-Mobile-Max-Email-HTML-Body-Truncation-
Size,<SchemaContainerDN>
• ms-Exch-Mobile-Min-Device-Password-Complex-
Characters,<SchemaContainerDN>
• ms-Exch-Mobile-Require-Encryption-SMIME-
Algorithm,<SchemaContainerDN>
• ms-Exch-Mobile-Require-Signed-SMIME-Algorithm,<SchemaContainerDN>
• ms-Exch-Mobile-Unapproved-In-ROM-Application-List,<SchemaContainerDN>
• ms-Exch-Standby-Copy-Machines,<SchemaContainerDN>

Please note:
There are many more Schema changes during Exchange Server 2007 SP1 setup but I
cannot list all the changes in this article. If you are interested in what changes occur read
the following article.

Verifying Exchange Server 2007 SP1 schema extensions

It is possible to verify the Active Directory schema extensions with ADSIEDIT which is
one of the Windows 200x support tools.

Navigate to:

CN CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=DN-of-
forest-root-domaincontroller

In the Attribute Editor tab, scroll down to the “rangeUpper” attribute. If Exchange 2007
Service Pack 1 Beta 2 has extended the schema, the value should be 11116.

If you are using the RTM version of Exchange 2007 the value should be10637.

For Exchange 2003, the value should be 6870 and Exchange 2000 should return a value
of 4397.
Figure 4: Display Schema extension version

Conclusion
In this article I showed you how the Exchange Server 2007 setup extends the Microsoft
Active Directory schema and why Active Directory schema extensions are necessary. I
also showed you how the Exchange Server 2007 SP1 setup adds additional schema
changes.

RUS in Exchange 2003

The Recipient Update Service (RUS) is a very important component in your Exchange installation, it
is RUS that is responsible for updating address lists and email addresses in your Active Directory.

Many people ask a simple question, "I just created a new mailbox, but when I look at the users
properties in Active Directory Users and Computers, nothing is listed on the Email Address Tab,
what did I do wrong?", well the simple answer is nothing, the RUS takes it's time to update all the
information in AD, so give it some time and everything will appear.

What we will discuss here is how to ensure that the RUS is running correctly and some issue with
using RUS in a multiple domain environment.

By default your organization will have two RUS objects (Figure 1):
 Figure 1

a. The "Enterprise Configuration" Recipient Update Service is responsible for the updating
of the email addresses for the system objects such as the Message Transfer Agent (MTA)
and System Attendant.

b. The "Domain" Recipient Update Service is responsible for the updating of the address
information for recipient objects in the domain that it is responsible for, in Figure 1 our
domain is NWTRADERS

To adjust the properties for the Recipient Update Service, right click over the service and then
select Properties, the properties for the Recipient Update Service will now be displayed (Figure 2).
 Figure 2

Field Description
This is the domain that is serviced by this Recipient
Domain
Update Service.
This is the Exchange server responsible for the creation
Exchange Server and updating of the address list for the domain specified
in the Domain field.
The Windows 2000 Domain Controller that this Recipient
Windows 2000
Update Service will connect to when it creates and
Domain Controller
updates the address list.
How often the Recipient Update Service will run, if you
Update Interval leave it selected to "Always Run" it will update once
every minute.

It is possible to force the Recipient Update Service to start processing, you have two options
"Update Now" or "Rebuild", and both of these options are available by right-clicking on the Recipient
Update Service. The "Update Now" option will update the address list with changes, the "Rebuild"
option as its name implies will completely rebuild the address list.

In most cases, having a single Recipient Update Service for each Active Directory domain will be
sufficient, but if you have a single AD domain that spans across different physical locations it is
recommended that you create a Recipient Update Service in each Active Directory site, and also
ensure that you have a Global Catalogue server in each Active Directory site also.

OK, so we now understand what the Recipient Update Service does and how to configure it, lets
look at a bit of troubleshooting.

The first step in troubleshooting the Recipient Update Service, like most other services is to check
the Event Log, we are looking for the events that originated from the MSExchangeAL service.
The next step in troubleshooting the Recipient Update Service is to use ADSI Edit to check a
mailbox that should appear in the Global Address List. We need to check and see if the
"showInAddressBook" attribute is populated (Figure 3)

Figure 3

If the "showInAddressBook" attribute is not populated, the Recipient Update Service may not yet
have run, in most cases manually forcing the Recipient Update Service to run will resolve the
problems.

From time to time organizations have multiple Windows 2000 domains that host user's accounts but
may only have one domain that hosts their Exchange 2000 servers. In these scenarios we need to
create additional Recipient Update Services, or our Global Address List, will not be populated with
the account information from the domains that do not host the Exchange 2000 server.

The diagram below shows the scenario that we will use. We have two domains "nwtraders.msft" and
"research.nwtraders.msft", our Exchange server (London) is located in the "nwtraders.msft"
domain, but we have users in "research.nwtraders.msft" who have mailboxes on our Exchange 2000
server, so we will need to create a Recipient Update Service to keep our Global Address List in
order.
The first task that we must perform is to run the Exchange 2000 setup program with the
DomainPrep switch in the "research.nwtraders.msft" domain, the person creating the new Recipient
Update Service must also have Full Administrative Access on the Exchange 2000 Organization
object.

The next step is to create the new Recipient Update Service on the Exchange 2000 server (London).

1. Open the Exchange System Manager, expand the Recipients container, click on the
Recipient Update Services container, you should now be shown the existing Recipient
Update Services

2. Right click over Recipient Update Services and then select New > Recipient Update Service
from the menu, the "New Object - Recipient Update Service" dialogue box will now be
displayed (Figure 4).
 Figure 4

3. In the Domain box, we need to select the Windows 2000 domain that contains the user's
accounts that this Recipient Update Service will manage, in our case
"research.nwtraders.msft", you can use the Browse button to select the domain, then click
Next.

4. In the next dialogue box (Figure 5) we will select the Exchange 2000 server that will be
responsible for updating the Global Address List for this Recipient Update Service, in our
case "London", click Next.

Figure 5

5. You will now be shown a summary of the parameters that you entered (Figure 6), if they
all appear to be in order, click Finish to complete the setup of your new Recipient Update
Service.
 Figure 6

Well that concludes my brief rundown of the Recipient Update Service in Exchange 2000, and
hopefully this has given you a better understanding of this important Exchange 2000 service.

Introduction
The Recipient Update Service (RUS) is the component of Exchange that is responsible
for generating mail proxy addresses for all mail-enabled objects in an Exchange
organization. Normally this component runs in the background and requires little
configuration or maintenance. There are times when issues do occur and fixing them
should be a top priority in order to keep mail flowing. Let’s take a look at what the RUS
does before going into some common troubleshooting steps:

Description of RUS

When you perform the initial install of Exchange, the Recipient Update Service is
installed and a default recipient policy is created. This policy is responsible for ensuring
that all mail-enabled objects in the Exchange organization have a valid SMTP address
following the [email protected] naming format. You can create a new policy that
can be configured to create each SMTP address following a different naming convention
such as [email protected]. Microsoft has a list of best practices to
follow when creating and/or editing recipient policies.

• Create a new recipient policy and assign it a higher precedence rather than editing
the default policy
• Keep the number of recipient policies to a minimum
• Rebuild the RUS with caution
A lack of understanding of the RUS is the major cause of issues. Often administrators
apply a policy without understanding what will be changed. Exchange does not provide
much warning about the impact a change will make. On top of that, organizations using a
3rd party application to create and assign SMTP addresses, through MIIS for example,
can cause further damage by applying recipient policies blindly. So what do we do when
RUS takes a vacation?

Troubleshooting Common Issues with RUS

As previously mentioned the Recipient Update Service runs quietly in the background
and requires little or no maintenance. When issues do occur there are three basic steps to
troubleshooting RUS.

• Enable Diagnostic Logging

• Choose an object, or objects to monitor
• View the Application Log for errors

To begin troubleshooting RUS we first determine if we have more than one recipient
policy, if so, set the schedule for all but one to Never Run. In the case of multiple
policies, you may be required to go back and enable another policy if you find nothing
wrong with the first. Just ensure that only one policy is scheduled to run at a time.

Diagnostic Logging
With the schedule configured, the next step is to enable Diagnostic Logging and set it to
log the maximum amount of events on the following services and objects.

MSExchangeAL – LDAP Operations

MSExchangeAL – Address List Synchronization
MSExchangeSA – Proxy Generation

To do this, open up Exchange System Manager (ESM) and drill down to Administrative
Groups | Servers | Servername, right click the server you wish to configure logging on
and select Properties and then go to the Diagnostics Logging tab. Under Services, select
MSExchangeAL and set LDAP Operations and Address List Synchronization to
maximum (see Figure 1). Next select the MSExchangeSA services and set Proxy
Generation to maximum. (Note: Proxy Generation is not available on Exchange 2000
servers). Finally create a test object for the RUS to stamp.
Figure 1: Diagnostic Logging

Verify RUS is Running

With Diagnostic Logging enabled, wait a few minutes and you should see two events
show up in the Application event log with IDs 8011 and 8012. These events verify that
RUS has started. If you do not get these messages, restart the Microsoft Exchange System
Attendant service. Once this service is started you will see a number of new events
logged, the first of which, 9006 and 9008, notify you that Abv_dg.dll is loading and then
starting.

If event ID 9006 appears, but you never get event ID 9008, you are performing this task
on a front-end server. On a front-end server Abv_dg.dll does not exist and RUS must be
run on a back-end server.

Verify RUS Queries

If event ID 8011 and 8012 do appear in the Application event log, the next step is to
determine if RUS has queried for any changes, for this you will require ADSIEdit. Open
up ADSIEdit and connect to the Domain Controller that RUS is pointing to. Drill down to
Domain NC | DC=domain,DC=com | CN=Users (or wherever you created your test
object) and right click the test object selecting Properties. Locate the uSNChanged value
and record it. Next open up the Event Viewer on the Exchange server you have enabled
logging on and search for

Event ID: 8011

Description: Base DC

When the search is done, open the first event in the list that will include information
about the last search completed by the RUS.

Locate the line in the event (USNChanged>=########)(uSNChanged<=########) and

determine if the value you recorded for the test object falls into this range (see Figure 2).

Figure 2: USNChanged

Based on this information we can determine a few things:

• If the uSNChanged attribute is higher that the range shown in the event, RUS has
not queried this object yet. This is common when you have selected to rebuild the
RUS which, depending on the size of the domain can take anywhere from a few
 minutes to a few days. When you initiate a Rebuild, the RUS starts from scratch
with a uSNChanged value of 1 and queries all objects in the domain.
• If uSNChanged attribute value for the test object falls below the range in the event
RUS has passed this object. Open up the next oldest event with ID 8011 until you
find the event that contains a range that the value falls into. If you have trouble
finding it you can modify the test object and wait for it to be queried again and
find the event for it.
• If the Application log does not contain an event ID 8011 that has "Base 'DC" in
the event description, the domain RUS has not started processing yet or the event
was over written by more recent events. A rebuild operation can cause this as it
can generate a large number of these events.

You can determine if a rebuild operation is taking place by lowering Diagnostics Logging
on all items except the Address List Synchronization object and then filter event 8329,
which specifies the start of a rebuild operation. At intervals of 10% event ID 8332 will be
logged and when the rebuild is complete event ID 8330 will be recorded. If you see event
8329 and 8332, but no 8330 then the rebuild is still running and you should wait until it is
complete.

Verify RUS Query Results

At this point we should find event ID 8011 that will inform us that the search was
performed on a range of USNs, which includes the USN of your test object. Now we can
see whether this returned any results. Events 8012 and 8169 will give us the results in the
description.

Event Type: Information

Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8012
Date: 3/27/2006
Time: 7:56:52 AM
User: N/A
Computer: EX-01
Description: Search of directory DC-01.tlaconsulting.ca at base
'DC=tlaconsulting,DC=ca' returned 3 objects.

Event Type: Information

Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8169
Date: 3/27/2006
Time: 7:53:01 AM
User: N/A
Computer: EX-01
Description: Retrieved all directory changes under: 'DC=tlaconsulting,DC=ca'.
There are a few common scenarios that apply to Event 8012.

• If there is no 8012 event generated after an 8011 event occurs, Exchange did not
receive a response to the search. This is usually indicative of a network issue
where the Exchange server cannot contact Active Directory.
• When the search returns zero objects (and you are certain there should be some);
this usually indicates a permissions error. In this case the Exchange server
computer account does not have the correct permissions required to view user
objects. In order to view user objects, the Exchange server needs to be part of the
Exchange Enterprise Servers group.
• If more than 20 objects are found you will see multiple 8012 events, as results are
returned in groups of 20. You should see one 8012 event for every 20 objects that
the query returned.

Conclusion
The Recipient Update Service is a fundamental component of Exchange and ensuring it is
up and running is crucial to a properly functioning Exchange envirmoment. Hopefully
these steps help you determine the cause and aid in finding a resolution in the unfortunate
event that something does go wrong.

Hosting Multiple SMTP Domains on your Exchange

2000 Server
Many people in the Microsoft Exchange 2000 newsgroups seem to want to know how to
host multiple SMTP Domains on their single Exchange 2000 server, Microsoft has some
good Knowledgebase articles about the steps required, so I thought I would take the time
to make the documents a little clearer and offer some additional insight on how the
process works.

Lets start by looking at the actual process of using SMTP mail on the Internet, lets
assume we have two companies abc.com and 123.com, a user at abc.com has sent a
message to [email protected], what happens now.

The message for [email protected] would have been sent to the queue on the server at
abc.com that is responsible for sending out Internet based mail, now the fun begins.

What we need to do is find out what server at 123.com is responsible for receiving
Internet based mail, this is done using DNS, in DNS we have a special record called an
MX (Mail Exchanger) record, the MX record points to an A (Host) record of the server
responsible for receiving incoming Internet mail for that domain, the A record points to
the Public IP address of the server.

It is important to understand at this point that the DNS information is not necessarily
created by you, it must be on a public DNS server, that is accessible by the rest of the
Internet, so it may well be your ISP or Hosting company that would be responsible for
the DNS records that your organization needs, so make sure you speak with them about
your needs.

So back to our message that we need to send to [email protected], as we said it is sitting in a

queue waiting to get sent, the figure below illustrates the concepts of sending the
message.

Server1.abc.com now know what server is responsible for receiving

mail for the domain 123.com, because the Public DNS server told it.

Server1.abc.com will now establish a TCP session using port 25

(SMTP) with server1.123.com and the message will be transferred,
nothing too complicated about that.

The message is going to be received by

server1.123.com, and held in a queue,
server1.123.com, is now going to use the Active
Directory to locate the actual mailbox that the
message should be delivered too, in our case
[email protected], the mailbox might be on server1.123.com, in which
case it will be delivered or the mailbox may reside on another
server, if this is the case the message will be routed by Exchange to
the correct server (this is shown in the next diagram).

So the question is how does Active Directory know

what mailbox belongs to [email protected], well when
you install Exchange 2000 it creates what is know as
a “Recipient Policy” and the Recipient Policy is used by the Recipient
Update Service (RUS) to create the users SMTP email addresses, the
Recipient Policy also tells Exchange what SMTP domains it has the
responsibility for.

You can find your Recipient Policy by performing the following steps:

1. Open the Exchange System Manager

2. Expand Recipients
3. Click on Recipient Policies

4. You will now see the “Default Recipient Policy” listed in the right-hand pane of
the screen

5. If you right-click on the “Default Recipient Policy” and select Properties, you can
navigate to the “E-Mail Address” tab and see the address that will be created for you,
see the figure below:

So from the figure above we can see that Exchange will create an
SMTP address for our users using the @123.com address, notice the
checkbox “This Exchange Organization is responsible for all mail
delivery to the address”, if this was not check Exchange would reject
the mail, even though the Public MX record for 123.com pointed to
this server.

The information I have provided above, summarizes the steps used to

send SMTP mail, so back to the real question, how do you get your
Exchange environment to host more than one SMTP domain?

Our organization currently holds the mail for 123.com by we also want
it to host mail for 456.com, as we have seen one of the crucial elements
is the MX record, so you will need to ensure that an MX record as been
created for 456.com that point to the server who is responsible for his
mail.

So when a user at abc.com sends some mail to a user at 456.com, our sending SMTP
server will query the Public DNS server for an MX record for 456.com, this will be
resolved to server1.123.com, which in turn will be resolved to the IP Address
192.168.1.100

But as we know, we have to tell our Exchange organization that it is responsible for
handling the mail for 456.com, this is done using our Recipient Policy, so if every user in
our organization should have two email addresses one for 123.com and one for 456.com
we can edit our “Default Recipient Policy” and add the extra address as detailed below:

1. Navigate to the “Default Recipient Policy” and open its properties.

2. Click on the “E-Mail Addresses” tab and click on New

3. From the “New Email Address” dialogue box, select SMTP

4. In the “Address” box enter the SMTP domain name (including

the @ sign) that you would like to create, make sure that you also
check the “This Exchange Organization is responsible for all mail
delivery to this address”

5. Click OK, and you will now see the “E-Mail

Address” tab as shown below, make sure you check
the box next to the new SMTP address you just
created.

6. You will notice that one of the SMTP address

is listed in bold, this is referred to as the Primary
SMTP Address and will be used as the reply address
for the user, if you need to chance this, highlight the SMTP address
that you would like to make the Primary and click on the “Set as
Primary” button.

7. Click OK to exit out of the “Default Policy”

Properties, you will be prompted with a dialogue box asking if you
would like to apply the new policy, click Yes to the question.

I would suggest you force the “Recipient Update Service” to run, this
will ensure that your users accounts are updated, for more information
on the “Recipient Update Service” look at this article:

Hierarchy, Content & Email Addresses

There are two main elements regarding public folders, namely the
hierarchy and the content. To put it a basic way, the public folder
structure that you see in Outlook is the hierarchy, whilst what’s
actually stored in those folders is the content. Well, that’s fairly straightforward, so let’s
get a bit more in-depth.

The first area to check when troubleshooting any public folder replication issues is the
status of the hierarchy. For example, let’s say that you’ve installed a new Exchange
server into an existing Exchange organization and you suspect that this new server has
not been sent a copy of the hierarchy. In this case, the first thing you need to check is
whether the public information store on the new server is correctly configured with an
email address. Both public folder hierarchy and content changes are sent between
Exchange servers via email messages, so it therefore follows that if the public
information stores email each other, they’ll need an email address as well as a working
email path between them. It’s the job of the Recipient Update Service (RUS) to ensure
that objects are stamped with correct email addresses, and this includes the public
information store. The first thing you should therefore check is the public information
store’s email address which can be performed with ADSIEdit. You’ll find that ADSIEdit
is installed as part of the Windows 2003 Support Tools.

With the ADSIEdit snap-in open, right-click ADSI Edit and choose the Connect to…
option. In the resulting Connection Settings window, ensure that the naming context is set
to Configuration and then click OK. This will then bind to the configuration naming
context allowing you to navigate your way down to the public information store. You
will therefore need to work your way down the tree accordingly:

CN=Configuration, DC=domain, DC=com

CN=Services
CN=Microsoft Exchange
CN={your Exchange organization name}
CN=Administrative Groups
CN={relevant administrative group}
CN=Servers
CN={relevant Exchange server}
CN=InformationStore
CN={relevant storage group}.

In the example in Figure 1 below, you can see that I’ve navigated my way down to the
First Storage Group on the server DCEXCH1.
Figure 1: Public Store Location Using ADSIEdit

Now what you do is to right-click the public folder store shown in the right-hand pane
and choose Properties from the context menu. In the resulting property window, find the
proxyAddresses attribute and click the Edit button. This will bring up a similar window to
the one shown below in Figure 2. Here you can see an example of a public information
store that has been correctly stamped with both SMTP and X.400 email addresses; if
there were no values in the proxyAddresses attribute, we’d instantly know that the RUS
has not run against this store and would therefore need to start troubleshooting the
RUS. Note that it’s the enterprise RUS and not the domain RUS that is responsible for
stamping email addresses on system objects like the public information store, so make
sure you’re looking at the correct one.

During my early migrations from Exchange 5.5 to Exchange 2000, I remember that one
of the most common reasons for the RUS not stamping email addresses on new Exchange
2000 servers was due to a missing proxy address generator, such as those used by fax
gateways for example. Other common reasons included invalid domain controllers or
Exchange servers listed in the properties of the RUS. Check out the Links section at the
end of this document for some useful links for troubleshooting RUS issues. One other
thing worth noting is the format of the SMTP address assigned to the public store:
[email protected]. There will be more on the significance of this later in this
article.
Figure 2: Public Store Email Addresses

I mentioned earlier that as far as public information stores are concerned, they need both
an email address and a valid message path in order for the replication messages to be
successfully sent and received. As far as the valid message path is concerned, note that
it’s a good idea to check whether you have any transport links that disallow system
messages. This check process can be made really easy by using the Winroute tool. For
more information on using Winroute, see the Links section at the end of this article.

Replication Messages
Increasing the diagnostics logging level of your Exchange server is always useful when
troubleshooting issues. Diagnostics logging levels can be set for the MSExchangeIS
Public Folder object found on the properties of an Exchange server object in Exchange
System Manager. In the case of public folder issues, I’ve seen many Microsoft PSS
professionals in mailing lists and newsgroups recommended to set the diagnostics
logging categories shown below in Table 1 on both the source and destination servers
involved in the replication process. Doing so will allow you to get a clearer picture of
what is happening during the replication process. For this article, we’re going to
concentrate mainly on the replication incoming and outgoing categories.

Category Logging Level

Replication AD Updates Maximum
Replication Incoming Maximum
Messages
Replication Outgoing Maximum
Messages
Non-Delivery Reports Maximum
Replication Backfill Maximum
Replication General Maximum
Replication Errors Medium

Table 1: Recommended Diagnostics Logging Settings

Once logging has been set, the application event logs on both source and destination
servers should then begin to produce more detailed information about the replication
messages as and when those messages begin to flow. There are several different types of
replication message. Table 2 below shows the message type, purpose, direction of
message flow and additionally the associated event ID.

Type Purpose Direction Event ID

0x2 Hierarchy Replication Outgoing 3018
Incoming 3028
0x4 Content Replication Outgoing 3020
Incoming 3030
0x8 Backfill Request Outgoing 3014
Incoming 3024
0x80000002 Backfill Response Outgoing 3019
(Hierarchy)
0x80000004
Backfill Response (Content)
Incoming 3029
0x10 Status Replication Outgoing 3017
Incoming 3027
0x20 Status Request Outgoing 3017
Incoming 3027

Table 2: Message Types

Let’s take the first message type, the hierarchy replication message, as an example. If you
create or delete a public folder, or perhaps change that folder’s permissions, a hierarchy
replication message will be generated from the source server to the destination server. As
you might expect, the sending of the hierarchy replication message maps to the
Replication Outgoing Messages diagnostics logging category in Table 1 above, whilst the
receiving of the hierarchy replication message maps to the Replication Incoming
Messages category. It therefore follows that for each outgoing message from the source
server, there should be a corresponding incoming message on the destination server.
Consider the example replication message shown below in Figure 3. Here you can see
that the event category is shown as Replication Outgoing Message. The reason for this
message is clear when you examine the event details. The Type is set to 0x2 (hierarchy)
and the affected folder is called New Test Folder; this was a new public folder that I had
created.

Figure 3: Outgoing Replication Message Event

As I just mentioned, it is normal to expect to see a corresponding incoming replication

message on the destination server. Therefore, if you were troubleshooting a situation
where Outlook clients connected to the destination server were not displaying the New
Test Folder public folder, the next step would be to examine the event log on the
destination server for the corresponding incoming message event to make sure it had
been received. This event would have a category of Replication Incoming Message and
an event ID of 3028. You would expect the event description to again list a message type
of 0x2, since this would be a hierarchy message, and also to contain the folder name of
New Test Folder.

Naturally the same process applies to the other types of replication message. For
example, if a user posts a new message to a pubic folder, or perhaps modifies an existing
post in some way and saves it back to the public folder, the entire post is replicated and
will be seen in the event viewer as a content replication message (type 0x4) with event
IDs 3020 or 3030 depending on whether you are examining the source or destination
server.

Backfill request and response messages are part of the backfill process which itself is the
process whereby public stores that detect they are missing some replication updates re-
request these updates from other public stores. The backfill request is sent as message
type 0x8, whilst the response message will be type 0x80000002 for hierarchy messages
and 0x80000004 for content messages. Figure 4 below shows an example of a content
backfill response message. In this example, server DCEXCH1 is responding to server
EXCH3’s backfill request for the public folder called Items For Sale.

Figure 4: Content Backfill Response Replication Message Event

The final replication message types are status replication, type 0x10, and status request,
type 0x20. These are used by the public information stores to allow the receiving store to
ascertain as to whether it is synchronized with the sending store.

Tracking Replication Messages

Continuing with our example scenario above, it may be the case that the destination
server did not contain the corresponding incoming replication message event. If this
proved to be the situation, the next logical step would be to examine the message
transport. Probably the first thing to do would be to use the Message Tracking Center in
Exchange System Manager in an attempt to see what is happening.

You can see from Figure 5 below that I’ve tracked messages sent from the public folder
store on server DCEXCH1. To do this, I simply typed in [email protected] as
the sender of the message. You’ll recall from earlier in this article that this is the SMTP
address of the sending public information store; you can see that this has been resolved to
the friendly display name of Public Folder Store (DCEXCH1).

Figure 5: Tracking Public Folder Replication Messages

I personally find it very useful to ensure that subject logging is enabled within message
tracking. You can enable this on the General tab of the properties of your Exchange
server object in Exchange System Manager. You can see from Figure 5 above that
enabling subject logging makes finding your messages much easier, since all messages
after 22:33 have the subject field populated after subject logging was enabled. For
example, it can clearly be seen that the message sent at 22:45 is a hierarchy replication
message.

To drill deeper into the events associated with each tracked message, it is simply a case
of double-clicking the relevant tracked message. For example, double-clicking the
hierarchy message sent at 23:00 reveals the Message History screen as shown below in
Figure 6. Here we can see that the last entry shows us that the message has been
successfully delivered to the destination server EXCH3. Had the last two entries on this
screen not been present, we would have seen that the last line would have stated SMTP:
Message Routed and Queued for Remote Delivery. In this case, we would have known
that the message had likely queued on our source server and hence had not been
delivered. It would have then been time to check the message queues using the Queue
Viewer utility in Exchange System Manager on the source server.

Figure 6: Message Tracking History

One last thing to note here is that a single replication message is created even if there are
multiple replicas of that public folder. For example, if a public folder is modified on
server DCEXCH1 and a replica of that folder exists on both the servers EXCH2 and
EXCH3, you will find that only a single replication message is generated and is
addressed to both public folder stores at the same time. Naturally when tracking such a
message, expect the Message History window to show this as shown below in Figure 7.
Figure 7: Message Tracking History – Multiple Replicas

Summary
The most important thing to remember about public folder replication is that it’s
message-based replication. Knowing this means that, once you’re confident that the
public stores have correct email addresses, you can use standard tools in the form of
Exchange System Manager and the Event Viewer to start troubleshooting your
replication issues. Of course, there are always more complex issues that could arise that
are way beyond the scope of this article, but hopefully this article has given you a starting
point.

PF Part1

the administrator, public folders are a separate database.

Figure 1

This screenshot shows the Exchange databases on a single Exchange 2003 Standard
server. The priv1 database, composed of both an EDB and an STM file, contains the user
mailboxes. The pub1 database contains the public folders. Both databases in Exchange
2000 and in Exchange 2003 up to SP2 had a limit of 16GB. In the fast moving Internet
days, 16GB is not much. However, most mail accumulates in user mailboxes, leaving the
public folder database pretty empty. Later on I will show how public folders can be better
used to even this out, so you get a smaller mailbox database and more room to grow.

Public Folders contain the same type of folders you can access using Outlook, and can
hold mail, calendaring and task information. You can set security on these folders so that
only specific people will have specific types of access to these folders.

Creating Public Folders

Public folders can be created using Exchange System Manager or the Outlook client.
Figure 2

Outlook 2003 sort of hides the public folders, so you first have to access the Folder list,
then on the right side, open the Public Folder List, All Public Folders and the select “New
Folder…”

Figure 3

Exchange System Manager can only create folders that hold mail items, such as your
Inbox and Sent Items folders, while Outlook can also create other types of folders such as
Calendar items.
Figure 4

You can also create Public Folders using Outlook Web Access.

Figure 5
Figure 6

Public Folders Security

Public Folders have two types of security mechanisms – administration and client access.

Public Folder Administration security can only be set by Exchange System Manager. It
allows you to decide which of the Exchange administrators have the right to manage
security for the public folder and administrate the database (also called information
store).
Figure 7

In most cases, in a small to medium company you would mostly need to set client
permissions and not administrative rights. These can be set by the Outlook client and
Exchange System Manager, but not the Outlook Web Access client.

Figure 8
Figure 9

The above screenshots show the default security settings for Public Folders. The owner of
a public folder is the user who created it and gets full control of the folder. Authenticated
users (designated here as Default) are granted the right to add items and delete their own
items and anonymous users can add items but not read them.

When creating a new public folder that you want a user to administer, you can simply add
the user to the permission list and change the permission level to Owner.
Figure 10

The owner would be able to create subfolders for the folder you created and set further
permissions on it.

Using a Public Folder as a Mail Repository

Collaboration in even a small company is very important. A lot of people like Outlook so
much they use it as their primary work tool. If Chris wants to show Mark an e-mail or a
movie, he can either invite over or forward the item. Exchange has single instance storage
capabilities which means an item forwarded will only have one copy, but once you
forward an item, it is changed, so single instance storage loses its edge. This means you
have documents and other heavy mail items bouncing around, inflating your information
store database.

Also while Mark is very efficient in storing and cataloging important e-mails, once he is
on vacation or otherwise indisposed, he won’t be able to forward e-mails. This can cause
all kinds of problems. Instead, you can have departmental or project related mail folders
in the public folder repository.

Instead of moving mail items to folders in your own mailbox, you move them to a
specified public folder.
Figure 11

This way the item becomes available to the relevant department personnel, if you set the
right permissions.

Figure 12
If you are worried about mailbox limits you can also create public folders for “heavy
users” and only grant them permissions on those folders. They can move large items to
their private public folder, saving room.

Company Contact Folder

While storing contacts in Active Directory can be a valid solution, it has a few
shortcomings. You need to teach non technical personnel to use the Active Directory
Users and Computers console and install it on Windows XP workstations. Alternatively
you can use third party interfaces for managing contacts. However, since users are
already accustomed to Outlook you can simply create a shared contacts public folder.

Figure 13

The downside of this approach is that each user has to add this folder to his or her own
Outlook Address Book so that the contacts will appear there. This is done in the Outlook
Address Book tab of each folder in Outlook.
Figure 14

After doing so the contacts appear in the address book.

Figure 15
Public Calendar
A public calendar is also a useful tool. It can also save you money, because unlike a
dedicated mailbox, a public folder doesn’t require a license. You can have as many public
folders as you like. So, instead of creating a mailbox enabled user in Active Directory for
scheduling meetings in, say, a meeting room, you can simply create an accessible public
calendar folder.

Unfortunately, public calendar folders are not published in the free/busy folder, so you
can’t really do advanced scheduling with these folders.

Public Folder Favorites

It is also beneficial to add the public contacts folder or any other public folder that you
use frequently to your public folder favorites by dragging it there or by using the context
menu using Right-click and choosing “Add to Favorites”. Be sure to also add sub-folders.

Figure 16

If you use Outlook 2003, after adding a folder to the public folder favorites you will be
able to access it using the regular sections without the need to browse all the way to the
folder list.
Figure 17

If you have public calendar favorites, you will be able view them side by side to
determine which calendar is free and compare them to your own calendar.
Figure 18

You can also modify your Exchange account in Outlook 2003 Cache mode to download
public folder favorites so they are automatically available offline. From the Outlook
menu choose Tool > E-mail Accounts > Exchange Server Settings > More Settings
> Advanced.
Figure 19

Conclusion
Public folders is a handy and powerful tool, not always the easiest to set up, but providing
many benefits and granularity. If you know how to use it, it can also save you time and
money.

This article covered the basic of the basics. Public Folders, like most features in
Exchange, are full of hidden surprises. I will try to cover more of that in a future article.

PF Part2

Like mailboxes, public folders can also receive mail from the Internet. By default, public
folders do not receive e-mail until you mail enable them.

This is how the property pages of a public folder look when they are not mail enabled.
Figure 1

A public folder is mail enabled by using the Exchange System Manager.

Figure 2
Once a public folder is mail enabled we get additional property tabs, similar to those you
might recognize from mailbox enabled users.

Figure 3

You can change or add e-mail addresses to suit your needs by editing the SMTP address
or adding a new one.

By going to the content tab of the public folder and entering an account with access to the
folder you get a mini Outlook Web Access interface. I have sent an e-mail from the
Internet to the public folder. Notice that instead of the envelope icon you get a post it
icon, since Exchange treats e-mails sent to a public folder as posts.
Figure 4

This means you cannot reply or forward this e-mail. However, using the Outlook client,
you can overcome this by using the Reply or Forward buttons in the toolbar without
opening the post itself.
Figure 5

Folder Automation
While the word "automation" is generally associated with scripts and programming,
Outlook and Exchange provide some surprisingly strong automation features that require
no scripting at all.

The Administration property page of a public folder is where this magic happens. When
you press "Folder Assistant" you will be presented with a few automation options that
you can create by using rules.
Figure 6

Figure 7

If this looks familiar to you, you might have seen a similar dialog box for it in the Out of
Office options.
Figure 8

Don't forget that you also have some Advanced options.

Figure 9

I've used the folder assistant many times in conjunction with other software automation.
For example, a service on the Internet would send some data to the public folder and it
would then, according to the subject, forward the information to the right person or
group.

Another such scenario is a public folder which contains information that needs to be
accessible to an outside contractor. Sure, you can set up some other forms of Internet
access, or instead, simply forward relevant information to your outside contractor or field
agents.

The "Reply with Template" option can be used in help desk scenarios where the customer
needs to know that someone is taking care of him or her. Sure, this can also be done with
a mailbox, but remember: public folders are cheaper and more accessible. Also, the rules
run server-side even when Outlook is running.

Another way that this can be used is to help you better monitor backups. Most backup
utilities will e-mail you the results. After a while, if you're a busy administrator, there's a
chance you might start ignoring their sometimes cryptic messages which can get lost
inside your mailbox, and sometimes even find their way to your Junk e-mail. Instead,
why not set up a public folder for these messages, and have the folder just forward
critical errors? On second thought, why stop there? Most applications these days will
send you some kind of a notification, and monitoring applications, such as Microsoft
Operations Manager, will send you even more. I find that using a public folder is more
tidy while leaving you the option to forward important mail to your mailbox, or perhaps
an Internet pager.

You might have noticed that a folder can also be moderated as well, by using the
Moderated Folder button in the Administration tab of the public folder property pages.
For more information about this you can read this excellent article.

Shortcuts
What happens if you wish to access a specific public folder?

Inside Office you can use a hyperlink to access your folder. The easiest way of
constructing such a link is by using the web toolbar in Outlook. To enable this toolbar
right click the toolbar area and choose “Web”.

Figure 10

On the web toolbar you will now see the link to whatever folder you are using at the
moment.
Figure 11

You can insert these hyperlinks to an e-mail message or any other office document by
using brackets.
Figure 12

After pressing “Enter” the hyperlink will be created. Such hyperlink will also work in
Internet Explorer but you will have to replace Spaces with “%2520”. In our example the
URL will become:

outlook://Public%2520Folders/All%2520Public%2520Folders/Test

You will probably also get some security warnings too, for trying to launch an
application from Internet Explorer. Alternatively, you can use an Outlook Web Access
URL such as this: http://exchange/public/test. Unlike the Outlook client URLs, spaces are
replaced by %20, like this: http://exchange/public/Internet%20Newsgroups/

Make sure to replace, in the above examples, “exchange” with the name of your own
Exchange server. You can also drag an Outlook folder to your desktop or any other folder
on your hard drive to create a shortcut. The shortcut is a special Office file with extension
XNK. It can be copied to other machines or moved to one of the shortcut toolbars.

I hate to leave without leaving a piece of coding, so here is a code for accessing a folder
with VBScript (or VBA):

‘ActiveateTempPublicFolder.vbs
Set myOlApp = CreateObject ("Outlook.Application")
Set myNameSpace = myOlApp.Application.GetNamespace("MAPI")
Set myfolder = myNameSpace.Folders("Public Folders").
Folders("All Public folders").Folders("Test")

Myfolder.display
You can use this code to create an Outlook button. First create an Outlook macro.

Figure 13

Figure 14

Then place the code into the Microsft Visual Basic Editor.
Figure 15

Now exit the editor and return to Outlook and choose Tools | Customize. From the list of
categories select Macros.
Figure 16

Then drag our macro to a tool bar.

Figure 17

Rename the button to make it more readable by right clicking it and choosing “Name:”.
Figure 18

Press “Close” button and now your button is ready to use. Please note that you can create
your button in any Office application, not just Outlook.

Conclusion
As you can see the more you dig, the more possibilities you have for using and accessing
Public Folders. With very little effort you can maximize the use of your investment in
Exchange and while at it, tailor your system for ease of use.

How public folder referrals have changed in Exchange 2007

EDIT: This post has been edited on 5/19/2008 to add a note about pointing Exchange 2003 mailbox stores
to Exchange 2007.

Exchange 2007 saw a fundamental change in the elimination of a couple of well-known key concepts in
prior versions: Administrative Groups and Routing Groups. The elimination of the routing group, and
consequently the routing group connector, changes the way that public folder referrals are handled in
Exchange 2007.

Previously, the public folder server would call into the routing engine to gather routing cost information,
and use this information to control content referrals and pick servers for backfill requests. Now, the server
connects directly to Active Directory to get the inter-site costs among all the public folder servers.

However, there's a new problem: There's no way to indicate on an AD site connector that you don't want
public folder referrals to happen. No longer can you check a checkbox and stop PF referrals from
happening from one corner of your company to another. But don't panic! The server still implements a
method to ensure client referrals don't end up going to the wrong end of the planet. The server has the
notion of other servers which are "too expensive" to accept referrals. As of this writing, that "too
expensive" threshold is 500. Yes, that really needs to be configurable, and we will examine doing that in a
future release.

We still have the feature where you can specify a specific cost list for a single server. Instead of calling into
AD, we'll simply read this cost list and use whatever data it provides. Unlisted servers implicitly have an
"infinite" cost, so this provides a simple method for disallowing referrals from a specific server to a set of
other servers.

This new source of cost information also controls the backfill picker. Previously, the code always queried
for cost information once (an hour) and cached it. This cached info was used to prepare client referrals and
to pick servers to ask for backfill. Now that we're querying AD instead of the routing engine, all users of
that cost information benefit from the new source and all can see the same information.

It's important to note that Exchange 2007 exclusively uses the AD site connector cost information, while
pre-Exchange 2007 exclusively uses the data from the routing group connectors. Since all Exchange 2007
servers appear to be in a single routing group from pre-Exchange 2007's point of view, without some
additional configuration you may experience truly bizarre referrals for users whose default public folder
database is on a pre-Exchange 2007 server, but all the replicas live solely on Exchange 2007 servers. In this
specific case, the pre-Exchange 2007 server will perceive all the Exchange 2007 servers as having the same
cost (because they're all in the same routing group). Clients will get referrals all over the place. To prevent
this from happening, you should set all default PFDBs for all mailbox DBs to point to Exchange 2007 as
soon as you've replicated content to any Exchange 2007 servers. This will put all clients on the same
referral page and you won't end up with clients in Brazil being referred to servers in Belarus. NOTE: If you
have Exchange 2003 users that use OWA, you should not point the Exchange 2003 mailbox database to an
Exchange 2007 public folder database, until you move all users that need OWA public folder access to
Exchange 2007. To read more about this scenario, please see this blog post.

- Dave Whitney

Exchange 2007 mail-enabled public folder transport

Introduction

Usually there is one question that is always asked when dealing with mail-enabled public folders: How
does the message get delivered to a replica?

To answer that question, let's take a walk down memory lane.

Exchange 5.5

In Exchange 5.5 we used to store replica information in the directory (aka "home server" field on public
folders). This allowed us to determine a replica to route to immediately upon categorization of the message.

This did have its faults though. You had to manage each public folder and its home server designation (i.e.
a single point of failure). In addition, because we did store that information in the directory, DS/IS
Consistency Check needed to be executed routinely to clean up the directory or to re-home the replica if the
site containing it was no longer present.

Exchange 2000 / 2003

In Exchange 2000 / 2003 we moved away from storing replica information in the directory and instead just
stored it within the public folder hierarchy. Now the only thing stored in the Active Directory is a proxy
object for the public folder that basically tells us the email address and that it's a public folder proxy object.
So as a result of these changes we had to change the way transport dealt with SMTP messages destined for
public folders.

The basic process is (for in-depth information, take a look at

http://msexchangeteam.com/archive/2004/09/10/228114.aspx):

1. SMTP mail addressed to Public Folder comes into transport.

2. Transport categorizes the message and obtains a list of all PF stores for that hierarchy. We then pick a
store and route the message to it:

a. If a PF store is on the same server, we use that.

b. If there are no local PF stores, then we'll use a PF store in the same routing group.

c. If there are no local PF stores in the routing group, then we use the first entry in the list from
msExchOwningPFTreeBL entry.

This list always has the most recently added public folder stores to the organization at the top (and as a
public folder store is created when a new server is installed, normally this means the most recently installed
servers will be at the top of the list). What could happen is we pick a server that has just been added to the
org and may not have the full public folder hierarchy yet (and hence not know what to do with the
message). To prevent this in Exchange 2003, we don't select any stores younger than two days, unless there
is no alternative. See http://support.microsoft.com/kb/328870/en-us for more information on use of PF store
Age in routing decisions.

3. If there is a replica on this store, then the message is simply delivered. If not, the store returns the
location of the closest replica and hands the message back to transport – which then sends it on to the store
which actually holds the replica.

Exchange 2007 RTM

In Exchange 2007 we made some fundamental changes to the way transport works (see
http://technet.microsoft.com/en-us/library/aa998825.aspx for more information):

• No more routing groups. Instead we will use the Active Directory topology for determining the
least cost route.
• Direct Connections are preferred. When possible the source Hub Transport server will establish a
direct TCP connection with the destination Hub Transport server that resides in the Active
Directory site where the mailbox or replica resides. No more passing it along a chain of Exchange
servers if we can avoid it.

So how does that change Public Folder mail routing? Well let's take a look at the stages.

Routing Table Calculation

When the Microsoft Exchange Transport service starts on a Hub Transport Server (or when a change
notification occurs, or after 6 hours), it calculates a set of routing tables that is based on the snapshot of
information that is retrieved from Active Directory. The routing component refers to the routing tables to
determine how to route messages to recipients. When configuration changes are made, the routing tables
are rebuilt. The new routing tables are used to route new incoming messages. Messages in remote delivery
queues are also rerouted if the routing component determines that they are affected by the configuration
changes. For more information on the routing table calculation, please see http://technet.microsoft.com/en-
us/library/aa998825.aspx.

Public folder hierarchies are one item that is retrieved during the calculation of the routing tables.
Specifically, to ensure that proper delivery can occur to the public folder replica, the "best" public folder
store is chosen by reviewing the msExchOwningPFTreeBL directory entry (Note: The
msExchOwningPFTreeBL list always has the most recently added public folder stores at the top) using the
following criteria (at RTM):

1. First and foremost, if the list contains any legacy Exchange PF stores, they are removed if Exchange
2007 PF stores exist. Age of the store is not considered when building this list.

2. If the choice is between two (or more) Exchange 2007 PF stores, then the following criteria will be used:

a. Age Ranking (PF store less than 2 days old by default will not be considered, unless the store's age is less
than the threshold or is unknown).

b. If there is a local PF store on the same physical machine, we will use that.

c. If there is not a local PF store, then we will choose a store within the local Active Directory Site. If there
are multiple PF stores, the first server returned is chosen.

d. If there are no PF stores within the local Active Directory site, then we will choose a PF store in a remote
Active Directory Site, sorted by lowest cost (if the choice is between two or more remote AD sites). If the
result is a tie, the first server returned is chosen.

3. In the event that there are no Exchange 2007 PF stores, and if the choice is between two (or more) legacy
Exchange PF stores, then the following criteria will be used:

a. Age Ranking (PF store less than 2 days old by default will not be considered, unless the store's age is less
than the threshold or is unknown).

b. If there are multiple PF stores, then the first store is chosen.

Transport Steps

1. The Hub Transport server receives the message and categorization is performed. When the categorizer
receives a message, it looks up the email address in the directory. If the email address resolves to a public
folder directory entry it knows that it has to do something special.

2. The categorizer looks up the homeMDB attribute of the public folder's directory entry. This tells it which
PF hierarchy the folder belongs to (usually there's only one PF hierarchy and that's the default "Public
Folders" hierarchy associated with the default public stores that get created automatically).

3. Based on the routing table calculations performed by the Transport service, the "best" public folder
hierarchy store ("best" TLH) is used to determine which public folder store contains a replica that can be
used for delivery.

a. If the "best" TLH is located within the same Active Directory site as the Hub Transport server, then we
proceed to Step 4.
b. If the "best" TLH is not located within the same AD site, we will route the message to a Hub Transport
server in the destination AD site by using the routing table to determine the least cost route. We then
proceed at Step 1 with the destination Hub Transport server, the message is categorized (Step 2) and the
best TLH store is used to determine the public folder store that contains a replica (Step 3a).

c. If the "best" TLH is located in an routing group on a legacy Exchange server, then we will route the
message to the legacy Exchange server, and the legacy Exchange server will handle determination of
replica based on the steps outlined in http://msexchangeteam.com/archive/2004/09/10/228114.aspx.

4. Instead of transferring the message via SMTP to the hierarchy store for replica lookup, the Hub
Transport server will establish a connection to the store service on the mailbox server role that contains the
"best" TLH store. The store is then queried to determine if content for the folder (referenced by
legacyExchangeDN) is available (IsContentAvailable), which results in a response containing the list of
servers hosting the folder if the content is not available locally (store override). The list of servers hosting
the folder replica is listed in the same order provided in client folder referrals and the top entry is chosen by
transport. This referral tells us to which replica we should route the message, aka, the "best" replica.

5. The Hub Transport server then uses the routing table to determine the least cost route for the server that
contains the "best" replica and routes the message accordingly (see http://technet.microsoft.com/en-
us/library/aa998825.aspx for more information on how least cost routing occurs).

6. The message gets delivered to the public folder store.

Exchange 2007 SP1

In Exchange 2007 SP1 we are altering the behavior slightly. In RTM, we prefer an Exchange 2007 PF store
over a legacy Exchange PF store, regardless of age.

That's right in RTM, we do not consider the age of the public folder store in that case. What does that
mean? Well that means we may end up choosing a PF store that doesn't contain the entire hierarchy (as a
result of just being created and not having received or processed the hierarchy replication messages). If we
choose a PF store that doesn't have the hierarchy we cannot perform a lookup of the replica, and thus we'll
NDR the message.

That's not the best situation. So in SP1 the decision tree will be:

1. Age Ranking - PF stores less than 2 days old by default will not be considered, unless the all of the
stores are less than the threshold or the age is unknown.
2. Proximity - local server is preferred over local AD site over remote AD site over remote RG.
3. Cost - if the choice is between two remote AD site replicas.
4. If still a tie, the first server in the replica list returned by AD is chosen.

Hierarchy Lookup Failure Scenarios

If the Hub Transport Server cannot contact the "best" TLH store, then the message will queue on the Hub
Transport Server. What are the scenarios here? Well once we choose a "best" TLH store we will stick with
it unless one of the following happens:

• The TLH store can be contacted and we deliver locally in case of a local replica on the TLH store,
or we obtain a referral for replica delivery.
• If the Transport service gets restarted; though this could still result in the same TLH store being
chosen.
 • A different TLH store will only be chosen if an underlying topology change has occurred (routing
table recalculated as a result of that change), and a new "best" TLH store is found during route
recalculation).
• Message times out and NDRs.

General Queuing Scenarios

So you might be thinking, besides the hierarchy lookup failure scenarios, where might a SMTP based
message (and at this point it doesn't even really matter that it is destined to a public folder) queue?

So for the purposes of this discussion, let's discuss each based off of the following diagram (please click on
the thumbnail to see the full size):

Routing the Message to a Hub Transport Server

• If the SMTP message destined to a public folder comes from an external source (e.g. the Internet
SMTP server), and that server cannot contact the Edge Transport server, then the message will
queue on the source SMTP server.
o This can be mitigated by having multiple ingress SMTP points into the organization that
are physically separate, and by having an appropriate DNS infrastructure in place.
o In addition, each physical site should have multiple Edge Transport servers, so that the
server itself is not a single point of failure (again with the appropriate DNS infrastructure
in place).
• If the SMTP message destined to a public folder is successfully delivered to the Edge Transport
server, but the Edge Transport server cannot contact a Hub Transport server, the message will
queue at the source (the Edge transport Server).
o This can be mitigated by having multiple Hub Transport servers within the AD site since
the Edge Transport server (configured via EdgeSync) will balance traffic across the Hub
Transport servers for that AD Site. In the event that a Hub Transport server is
unresponsive, the Edge Transport server will attempt delivery to another Hub Transport
server within that AD Site. If all Hub Transport servers are unresponsive, then the
message will queue on the Edge Transport server.
• If the SMTP message destined to a public folder comes from an internal client (i.e. one that
submits messages to the store service like Outlook, OWA, or EAS), then if the mailbox
submission service cannot contact the Hub Transport server, the message will queue on the
Mailbox server (in the information store).
o This can be mitigated by having multiple Hub Transport servers within the AD site. The
mailbox store will prefer the Hub Transport role installed locally if there is one on the
box, and if that is unavailable, it will load balance traffic via round-robin algorithm
across the Hub Transport servers within the same AD site so that it can deliver the
 message. If all Hub Transport servers are down within the AD site, the message will be
queued on the Mailbox server until a Hub Transport server becomes available. Mailbox
servers cannot communicate with Hub Transport servers that are not members of its AD
site.

Routing the Message to its Destination

Once the Hub Transport server receives the message it will perform the steps outlined in the "Exchange
2007 RTM" section.

There are two potential scenarios that could result in replica delivery queuing and they depend on the
location of the replica:

1. Once the server hosting the best folder replica is chosen, if the Hub Transport server cannot contact the
mailbox server that contains the PF replica (intra-AD site), then it will queue on the Hub Transport server.
In this scenario, we will queue until the store service is responsive.

2. Once the best replica is chosen, if the Hub Transport server cannot contact the destination Hub Transport
Server (inter-AD site), then it will queue on a Hub Transport server. There are a few things with this
scenario:

a. For one, each AD site that has a Mailbox server, should consider having multiple Hub Transport servers
so that the Hub Transport server does not become a single point of failure.

b. In the scenario, where all Hub Transport servers are unresponsive (say because of network outage), the
source Hub Transport server will not be able to establish a direct connection with the destination Hub
Transport servers. So in this case, we will perform a back-off and get it as close as possible to the
destination AD site (re-route, i.e. choosing another least cost route, would only occur after a site topology
change).

Conclusion

We hope the above information helps explain how the routing process works for mail delivery to mail-
enabled public folder replicas