Sunteți pe pagina 1din 3

How AQE works?

Can any one tell me how AQE works?actually i want to know how AQE(or categorizer)
come to know mail is not for within organisation & its for outside organisation?
Feb 5
Regardless of how a message enters the system, at some point it is passed to the
Advanced Queuing Engine. The Advanced Queuing Engine is the heart of the Exchange
transport and all messages are processed by it. This is a change from Exchange 5.5 where
“local” messages (i.e., messages where the sender and recipient are on the same system)
were handled entirely by the Information Store without involving the message transport.
This change to handle all messages in the same manner allows custom event sinks to be
used on all messages, including local messages.

The Advanced Queuing Engine sends the message to the Message Categorizer by adding
it to the Message Categorizer’s work queue.

In general, the task of the Message Categorizer is to examine the message and queue it
for delivery on the basis of certain message attributes. The specific tasks include the
following:

The Message Categorizer parses the sender name and asks the directory service to look
up the sender’s address.

If the envelope recipient list includes distribution groups, the Message Categorizer
expands the distribution groups to identify the individual recipients.

The Message Categorizer parses the recipient names and asks the directory service to
look up the recipient addresses. Any unresolved recipients are marked as unknown.

It applies the delivery restrictions and other limits for the sender and for each recipient.

If required, the Message Categorizer creates multiple copies of the message. This is
generally done for two reasons:

Messages destined for Internet users are formatted differently from messages destined for
Exchange users. If the message recipients include Internet and Exchange users, the
Message Categorizer creates two copies: one for the Exchange users and one for the
Inter- net users.

There are conflicting properties for different recipients, such as when a message contains
both a read receipt request and a hidden group. Read receipts should not be generated for
the members of the hidden group, because their membership must remain confidential.
The Message Categorizer creates two copies of the message: one copy without read
receipt requests for the hidden recipients and one copy with read receipt requests for the
other recipients.

The Message Categorizer determines where each copy of the message is to be delivered
(e.g., local delivery or sent to another system).

It then returns the message to the Advanced Queuing Engine.

The Advanced Queuing Engine sends the message to the Routing Engine by adding it to
the Routing Engine’s work queue.

The Routing Engine uses information about connectors, costs, and link states to
determine the next system to which the message should be transferred. A cost is
associated with each connector between two routing groups. When there are multiple
possible routes between two systems, the cost is used to determine the preferred (i.e.,
lower cost) route. The routing topology and connector costs are made available to all
Exchange servers in the organization.

With Exchange 5.5, one server in each Exchange site was responsible for collecting the
routing topology information, calculating the costs, creating a Gateway Address
Resolution Table, and relaying this information to other Exchange servers in the site.
However, Exchange 5.5 had no mechanism for communicating the status of connections.
Each server only knew the status of connections to adjacent systems and had no status
information on other network connections. Consequently, a message may start on a multi-
hop journey to its destination only to find that one of the downstream network
connections has failed. This is known as direct vector routing.

Exchange 2003 continues to use routing topology and connector costs, but now uses a
Link State Algorithm based on a Dijkstra algorithm that is a well-known, well-accepted
method of finding least cost. This algorithm, also known as Open Shortest Path First,
prevents looping and incorporates dynamic rerouting. Many network router vendors use
Open Shortest Path First in their products for routing network packets. The Link State
Algorithm communicates near real-time information about connector status between
routing groups within the Exchange organization. Because all servers know the status of
all connections, the originating Exchange server can make an intelligent routing choice
rather than starting a message on a multi-hop journey only to find that one of the
downstream network connections has failed.

One server in each Exchange Routing Group is responsible for collecting link state
information and the routing topology information: the routing group master. The routing
group master collects and relays this information to other Exchange servers in the
Routing Group, including the Routing Group’s bridgehead servers. The bridgehead
servers relay the link state information to bridgehead servers in other routing groups,
which then send the information to their local routing group master. Within a Routing
Group, link state information is communicated using TCP port 691. Between groups, the
information is communicated using SMTP.
Note The first server installed in a routing group automatically becomes the master, but
this designation can be changed manually.

Each link has one of two states: up or down. When a bridgehead server detects that a link
is unavailable, it marks that connector as down and sends the data to the routing group
master. The master immediately sends the change to the other servers in the routing group
and forwards the information to other routing groups.

Connector and cost information is kept in the Active Directory, but link state information
is only kept in the memory of each Exchange server. If one of the servers fails, the
remaining servers continue to redistribute the link state information.

Once the Routing Engine determines the next hop, it then returns the message to the
Advanced Queuing Engine.

Once the next hop for each copy of the message is determined, the message is queued for
delivery.

If the message is for local delivery (i.e., the recipient’s mailbox is in the local Information
Store), it is placed in the local delivery queue. The Store Driver (Store) takes the message
from the local queue and delivers it to the Information Store.

If the message is destined for another system, it is queued for delivery to the domain of
the next hop. The SMTP server takes the message from the queue and forwards it to the
appropriate system.

Missed point.

Exchange has a RUS Receipent update policy which keep tracks of all the valid emails in
the organisation. RUS polls information from global catalog which is accountable for all
objects in AD forest / organisation.

If it find ID in RUS it sends to Inbound Q else it will send to Global Cataloge to resolve
target user domain. and finally to oubound.

S-ar putea să vă placă și