Exchange Message Flow

Exploring Message Flow:

Microsoft Exchange Server 2007 supports various types of message flow. In an organization that deploys Exchange Server 2007, messages flow within a single Active Directory site or between multiple Active Directory sites. A Hub Transport server manages message flow in an organization by using various components in Exchange Server 2007. You can control the message flow among various servers and between the servers over the Internet by using SMTP Send and Receive connectors.

Types of Message Flow:

• Inbound: In an inbound message flow, an Exchange Server 2007 organization receives an e-mail message over the Internet. A Hub Transport server or a gateway server, such as an Edge Transport server, accepts the message over the Internet and then routes the message to an internal Exchange Server 2007 server.
  
• Outbound: In an outbound message flow, an internal Exchange Server 2007 server sends an e-mail message from within the organization over the Internet. A Hub Transport server processes and identifies the message as an outbound e-mail message. The Hub Transport server then sends the message over the Internet either directly or by using a gateway server such as the Edge Transport server
  
• Local: In a local message flow, a Hub Transport server processes an e-mail message received by Exchange Server 2007 and then sends it to a mailbox in the same Active Directory site. Even if an organization has a single Mailbox server, all e-mail messages are routed through the Hub Transport server as part of the delivery process. Therefore, all Exchange Server 2007 organizations use local message flow
  
• Remote: In a remote message flow, a Hub Transport server processes an e-mail message received by Exchange Server 2007 and then sends the message to a mailbox in a different Active Directory site. Remote message flow takes place only if an organization has multiple Active Directory sites with Mailbox servers. Typically, small organizations and large organizations with centralized Mailbox servers in a single data center do not use remote message flow.

Components Used in Message Flow:

Message transport in Microsoft Exchange Server 2007 involves the interaction of various components :

• Microsoft Exchange Mail Submission service:
  
  The Microsoft Exchange Mail Submission service is a notification service that runs on Mailbox server roles in Exchange Server 2007.
  
  When a message becomes available for retrieval in the Outbox folder of a sender, the Microsoft Exchange Mail Submission service notifies a Hub Transport server in the local Active Directory site. If there are multiple Hub Transport servers in the site, the Microsoft Exchange Mail Submission service evenly distributes notifications among all the available Hub Transport servers.
  
  When the Microsoft Exchange Transport service starts on each Edge Transport server or Hub Transport server, the categorizer creates the local submission queue.
  
• Store driver: The store driver on the Hub Transport server role retrieves the message, which is in MAPI format, from the sender’s Outbox folder and converts it to the Summary-Transport Neutral Encapsulation Format (S/TNEF).
  
  S/TNEF is a type of Transport-Neutral Encapsulation Format (TNEF), which has no plain text part and is in eight–bit binary format. The store driver then submits the message to the submission queue and moves the message from the Outbox to the Sent Items folder.
  
• Submission queue: Messages can also enter the submission queue on a Hub Transport server from an SMTP Receive connector or from the Pickup directory. The submission queue stores all messages on disk until the categorizer processes them.
  
• Categorizer: The categorizer processes the messages one at a time and always selects the oldest message in the submission queue first. On an Edge Transport server, the categorizer verifies the recipient SMTP address of an inbound message and places it directly in the delivery queue.
  
  The message is then routed to a Hub Transport server. On a Hub Transport server, the categorizer processes all inbound messages based on the information about the intended recipients. The categorizer makes copies of messages that have multiple recipients, determines routing paths, converts content format, and applies organizational message policies.
  
  After the categorizer processes the message, the message is removed from the submission queue.
  

SMTP Connectors:

You need an SMTP connector to route messages between two Active Directory sites or between two Active Directory sites over the Internet. However, you do not need SMTP connectors to route messages within an Active Directory site. You can use an SMTP connector to route messages between Hub Transport servers and Edge Transport servers or between the Hub Transport servers over the Internet. Each Hub Transport server and Edge Transport server can have SMTP connectors to send or receive messages.

To manage the message flow in your organization, you can use the default configuration of the SMTP connectors that is provided by Exchange Server 2007. Based on the requirements of your organization, you can also configure the properties of SMTP connectors. You can specify the source IP addresses that should send or receive messages. You can also specify the maximum size of messages and configure permissions. In addition, you can enable protocol logging on an SMTP connector to identify the problems in the message flow.

Types of SMTP Connectors:

• Send: A computer that runs Exchange Server 2007 requires an SMTP Send connector to send any SMTP e-mail message. You need SMTP Send connectors to send an e-mail message to any SMTP server over the Internet or to any SMTP servers in your organization. By default, SMTP Send connectors are not configured on a Hub Transport server. However, SMTP Send connectors are dynamically created in the server memory to communicate with other Hub Transport servers on other sites. You cannot configure these dynamically created SMTP Send connectors or view them by using the management tools in Exchange Server 2007.
  
  When you create an SMTP Send connector, you must configure it with a Domain Name System (DNS) address space, which is used to identify the messages that are processed by the SMTP Send connector. For example, if you configure an SMTP Send connector with the contoso.com DNS address space, all messages with a destination address in the contoso.com domain will be processed by that SMTP Send connector. After you configure the DNS address space, you can configure the SMTP Send connector to deliver messages by looking up the mail exchanger (MX) records in DNS or to forward messages to a smart host.
  
• Receive: A computer that runs Exchange Server 2007 requires an SMTP Receive connector to accept any SMTP connection. An SMTP Receive connector enables a Hub Transport Server or an Edge Transport server to receive e-mail messages from other SMTP servers. These SMTP servers can include servers on the Internet, other Exchange Server 2007 Hub Transport servers, or Edge Transport servers.
  
  You can configure multiple SMTP Receive connectors with different parameters on a single Exchange Server 2007 server. Small-to-medium-size organizations may use only the two default SMTP Receive connectors. Large organizations may need multiple SMTP Receive connectors on a single server or on multiple servers. The default SMTP connectors manage the message transport within the same Active Directory forest. Therefore, you do not need to create SMTP Receive connectors to route e-mail messages between Hub Transport server in the same Active Directory forest.
  
  You must configure each SMTP Receive connector with: A port number on which the connector will receive connections. The local IP addresses that the SMTP Receive connector will use for incoming connections. A remote IP range that can send e-mail message to the SMTP Receive connector. The combination of these three properties must be unique for every SMTP Receive connector in your organization

SMTP Default Configuration:

By default, the following SMTP Receive connectors are created on each Hub Transport server:

• The Client Receive Connector that receives connections from SMTP clients, such as Microsoft Office Outlook Express
• The Default Receive Connector that receives connections from other SMTP servers by default
  
  The default configuration for the two connectors is similar, but with one important difference: the Client Receive Connector is configured on port 587 rather than port 25. This is because the Internet Engineering Task Force (IETF) working group process in Request for Comment (RFC) 2476 has proposed that port 587 should be used only for message submission from e-mail clients that require message relay.

Message Flow Scenarios:

• Single Site: Message flow within a single site begins when you submit a message to the message store on an Exchange Server 2007 Mailbox server.
  
  When you use Microsoft Office Outlook, the message is written in MAPI format and then sent to your Outbox folder. The Microsoft Exchange Mail Submission service detects that a message is available in the Outbox folder and notifies the store driver on an available Hub Transport server.
  
  The store driver connects to your Outbox folder by using MAPI and retrieves the message from the Mailbox server. The store driver also places the message in the submission queue on the Hub Transport server, and moves the message from the Outbox folder to the Sent Items folder.
  
  The categorizer processes the message in the submission queue. If a message is intended for a Mailbox server role in the same Active Directory site, the categorizer places the message in a local delivery queue.
  
  The store driver then delivers the message to the Mailbox server role by using MAPI.
• Multiple Sites:
  In a multiple-site message flow, after a message is retrieved and delivered to the Hub Transport server, the Hub Transport server searches the Active Directory to determine the mailbox location of the recipient. Then, the Hub Transport server determines the lowest cost route to the destination site by using the Active Directory site link information.
  
  If Hub sites have not been configured in the route to the destination site, the message is directly delivered to a Hub Transport server in the destination site. This is called Direct Relay Routing.
  
  The Hub Transport server of the destination site then delivers the message to the Mailbox server in that site. If a message has to be delivered to recipients in multiple sites, the message is delivered to a Hub Transport server in each site. If a message has to be delivered to recipients through the Internet, the Hub Transport server routes the message to an Edge Transport server.
  
  The Edge Transport server delivers the message to the appropriate Internet e-mail server, which in turn delivers the message to the recipient. In the absence of an Edge Transport server, the Hub Transport server delivers the message to an appropriate third-party Internet e-mail server by using an SMTP Send connector.
  
• Disrupted:
  A message flow is disrupted if no Hub Transport server is available in the destination site. In such a situation, the message is routed to the closest Hub Transport server along the most optimal route. This is referred to as Queuing Messages at the Point of Failure.
  
  The closest Hub Transport server then delivers the message when a Hub Transport server in the destination site becomes available. If a message has to be delivered to recipients at multiple sites, a copy of the message is delivered directly to the recipients at each site.
  
  However, if destination Hub Transport servers are not available, then the source Hub Transport server delays making copies of the message for each recipient and sends a single message that is queued for delivery at the Hub Transport server that is closest to the destination sites.
  
  When the destination sites become available, the queued message is sent to each site with a recipient. This is referred to as Delayed Fan-Out Routing.

Recovering Messaging Databases

Methods for recovering a database:

- Recover using Recovery Storage Group (RSG)
- Recover using Database Portability
- Recover using Dial-Tone Recovery

Recover data using RSG:

1. Use Exchange Database Recovery Management tool for creatingthe RSG.
2. Restore data using back to the RSG (Note: You don’t need to select an RSG to restore to.. If one exists, it is automatically used.)

Recover using Database Portability:
You can use the database portability feature in Exchange Server 2007 to recover a mailbox database when there is a server failure or a hard disk failure.

You can use this option when a Mailbox server fails, but the storage group and database files are available on hard disk or on a backup tape.

You can also implement database portability when the hard disk storing the database fails on one server, and the hard disk cannot be replaced. You can restore the database from the backup data on another Mailbox server.

By using database portability in Exchange Server 2007, you can move a mailbox database from one Mailbox server and mount it on another server. To mount the database on the new server, you do not need to modify the database or configure the server. However, you can mount the database only on a server in the same Exchange Server organization.

To recover a messaging database by using database portability:

1. First create a new database on an alternate server. The new database must have the same name as the database you are recovering. You can either create a new storage group or create the destination database in an existing storage group on the server. Then, configure the database so that you can overwrite it with the backup data.

2. You can now restore the backup copy of the database from the failed server and mount the database on the new server.

3. Finally, you need to modify the user accounts to refer to the new database by using an Exchange Management Shell command.
This command obtains a list of all mailboxes in the restored database and passes it to the Move-Mailbox cmdlet.

Get-MailboxStatistics -database Move-Mailbox -configurationOnly -target

4. When users try to access their mailboxes by using Microsoft Office Outlook 2007, they will be automatically redirected to the new server. However, you need to manually configure clients such as Microsoft Office Outlook 2003 and earlier versions to refer to the new Mailbox server. Outlook Web Access users are also automatically redirected to the new server.

Recover using Dial-Tone:
You can use dial-tone recovery to provide users with immediate access to their mailboxes and e-mail services even before you restore data to their mailboxes. To do this, create an empty mailbox database to replace the missing or corrupted mailbox database. By using dial-tone recovery, you can ensure that users experience minimum disruption of services after the failure of a database or a server.
Benefits of Using Dial-Tone Recovery
By implementing dial-tone recovery, you can ensure that users in your organization can access their e-mail messages and begin working much faster compared to a standard restore. When you perform a standard restore, users cannot access e-mail services until you restore the database completely. A standard restore can take several hours if the database is very large, and external users may start receiving non-delivery reports (NDRs).
Using Alternate Servers
If there is a server failure instead of a database failure, you can perform dial-tone recovery on an alternate server by using the database portability features of Exchange Server 2007. You also need to modify the user accounts to refer to the new database location.
Recovering Historical Data
After dial-tone recovery is complete, you can restore the data from backup to an RSG and then merge the mailbox contents in the recovered database with the contents in the dial-tone database. All the user mailboxes will now have all of their historical information as well as the received and sent messages since the implementation of dial-tone recovery

Procedure:

1. On another server create a new Storage Group and Create new Database.Note: Use the SAME NAME as the database you'll recover.
2. Open Exchange Mgmt Shell and modify the user accounts to refer to the new database by using an Exchange Management Shell command.
3. This command obtains a list of all mailboxes in the restored database and passes it to the Move-Mailbox cmdlet.Get-MailboxStatistics -database
   Move-Mailbox -configurationOnly -target
4. This will give the users access to their mailboxes, while you prepare to merge backup data from and RSG to the new mailbox database.
5. Use the Exchange Database Recovery Management tool to create a RSG and restore data to the RSG (Refer to Recover using RSG prior section).
6. After db is restored from backup, use Exchange Database Recovery Management tool to merge data from RSG to the new database.
7. Manage Recovery Storage Group > Merge copy mailbox contents > Gather Merge Information
8. At the Select Merge Options > Perform pre-merge tasks
9. Select mailboxes to copy or merge and Perform Merge Actions
   

Exchange 2007 - Upgrading Email Policies

Upgrading Email Address Policies (EAP)

If Exchange 2007 organization resides with  legacy instances of Exchange 2000/2003. The deployment of Exchange 2007 within the same organization results in a coexistence with legacy Exchange and Exchange 2007. As with any coexistence/migration scenario, steps should be taken to convert/move legacy born objects to native Exchange 2007 objects. This section will talk about the steps you can take to upgrade your legacy LDAP filters for EAPs to the new syntax, allowing you to upgrade your Address List and Email Address Policy objects to the Exchange 2007 object version. Exchange 2007 uses a new style of filter syntax to replace the LDAP filters of previous versions.

Note: that if you decide not to upgrade the ALs or EAPs, there will be no broken functionality from the Exchange 2007 side. New users will still be provisioned according to those policies. However you will not be able to edit those objects from 2007 Exchange Management Console until they are upgraded.

To confirm the need to upgrade the filter (and the version) on your EAP. There are a couple of key indicators you can check. The first is that if you try to edit the EAP in Exchange 2007 GUI, you'll get a screen with this error - "Unable to edit the specified E-mail address policy. E-mail address policies created with legacy versions of Exchange must be upgraded using the 'Set-EmailAddressPolicy' task, with the Exchange 2007 Recipient Filter specified.":

Another way to check that doesn't rely on the GUI is to issue this one-liner:

Get-EmailAddressPolicy | Format-List Name,*RecipientFilter*,ExchangeVersion

This cmdlet will return all of your EAPs, and will include any properties containing RecipientFilter and the ExchangeVersion property. Look for these clues:

· LdapRecipientFilter is populated but RecipientFilter is empty - Exchange 2003 doesn't populate RecipientFilter; that's what we're about to do!

· RecipientFilterType is "Legacy"

· ExchangeVersion is "0.0 (6.5.6500.0)"

<Company> Email Address Policy Results (Pre-EAP Upgrade) –

· Sample One legacy (Exchange 2003) and One Native (Exchange 2007)

Legacy Sample

Name : Default Policy
RecipientFilter :
LdapRecipientFilter : (mailnickname=*)
LastUpdatedRecipientFilter :
RecipientFilterApplied : False
RecipientFilterType : Legacy
ExchangeVersion : 0.0 (6.5.6500.0)

Native Exchange 2007 Sample

Name : company
RecipientFilter : (CustomAttribute1 -eq 'company.com' -and Alias -ne $null)
LdapRecipientFilter : (&(extensionAttribute1=company.com)(mailNickname=*))
LastUpdatedRecipientFilter : (CustomAttribute1 -eq 'company.com' -and Alias -ne $null)
RecipientFilterApplied : True
RecipientFilterType : Precanned
ExchangeVersion : 0.1 (8.0.535.0)

 

Upgrading Default EAPs

Note: Once these changes are made, you can no longer manage the email policies within the Exchange 2003 System Manager.

IMPORTANT: This process is only for “Default” email policies. Upgrading Custom Email Policies.

Since the "Default Policy" EAP has a well-known filter, we can simply provide the Exchange 2007 equivalent of this well-known filter to do the upgrade. Here's the one-liner:

Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients

When you run this one-liner, you'll be prompted to ask whether you REALLY want to do the upgrade with this text: "To save changes on object "Default Policy", the object must be upgraded to the current Exchange version. After the upgrade, this object cannot be managed by a previous version of Exchange System Manager. Do you want to continue to upgrade and save the object?"

Once you've committed to a "Y" answer on this confirmation, the "Default Policy" EAP will be upgraded to Exchange 2007 version with the new Exchange 2007 filter in place. You can confirm this by looking at the same properties as before. Now you'll notice that there is a RecipientFilter property populated, that the RecipientFilterType is "Precanned", and that the Exchange version has bumped to 0.1 (8.0.535.0). Further, you may notice that you can no longer make changes to the recipient policy through Exchange 2003 ESM, although the Exchange 2003 Recipient Update Service (RUS) will continue to process these recipient policies just fine.

Upgrading Custom EAPs

What if you've created some special EAP or AL objects for your organization, over and above the built-in set of EAP and AL objects? How can you convert the "not-so-well-known" LDAP filter you have created into an equivalent OPATH filter for use by PowerShell?

Upgrading Custome EAPs is not as simple as upgrading Default Policies. There is more to than simply running a command.

http://msexchangeteam.com/archive/2007/01/11/432158.aspx

Script - Create New FreeBusy Connector

The following script can be used to create a new Transporter Suite Free/Busy Connector.  This can be for a new connector on an Existing Exchange Server or a new Connector on another Exchange Server.  Modify the code accordingly.

#Create a new Domino Free Busy Connector

# Transporter Commmand Parameters (New-DominoFreeBusyConnector)
#        -Name: Connector name#       
#        -DominoServer: Identifies the Lotus Domino server running the excalcon.exe task.
#        -DomainoSMTPDomains: Specifies the Domino SMTP domains that the Exchange transporter Domino Free/Busy Connector monitors for free/busy requests.
#        -NotesINIFile: Path to the Lotus Notes.ini file, including filename.
#        -RefreshIntervalSeconds: Number of seconds free/busy information will be retained for a previously requested user. The default is 900 seconds
#        -NotesPassword : The password associated with the local Lotus Notes ID file.
#        -MaintenanceIntervalMinutes : Determines how often the connector should verify that the Lotus Notes users are listed in the free/busy public folders.
#        -QueryWindowDays :Defines how many days of free/busy information to retrieve. The default is 60 days

#        -RequestTimeOutSeconds : Specifies how long to retry accessing a server before returning an error.The default is 15 seconds

Write-Host
Write-Host
Write-Host "C R E A T E N E W F R E E / B U S Y C O N N E C T O R"
Write-Host

$Password=Read-Host "Enter Notes Password: " -AsSecureString

#DELETE EXISTING CONNECTOR PRODUCTION
Remove-DominoFreeBusyConnector -identity '<ExchServerHostingTransporterSuite>-DominoFreeBusyConnector' -Confirm:$False

#NEW FREE BUSY CONNECTOR PRODUCTION
New-DominoFreeBusyConnector -Name '<ExchServerHostingTransporterSuite Domino Free Busy Connector' -NotesPassword $Password -DominoServer '<DominoServerHostingEXCALCON/DOMINO DOMAIN-ConnectedDomains 'company.com; exchange.company.com;' -NotesINIFIle 'D:\lotus\notes\notes.ini' -RefreshIntervalSeconds '300'

#START FREE BUSY CONNECTOR
Start-DominoFreeBusyConnector

#START SYNCHRONIZE ENTRIES
Start-DominoFreeBusyConnector -synchronizeEntries $True

Domino to Exchange 2007 Migration Tool Comparison

 

Domino/Notes to Exchange/Outlook migration tool set comparisons:

 ** Note:  These are Data Migration Tool Comparisons.  Not Coexistence features.

Migration Capability	Detail	MS Transporter	CMT - Universal Binary Tree	Quest - Notes Migrator
Mail	Will it move mail?	Y	Y	Y
Encrypted Mail	Will it decrypt mail?	N	Y	Y
Archived Local	Will it import archives from local client?		Y	Y
Archived Server	Will it import server based archives?	Y	Y	Y
To-Do	Will it migrate To Do Lists to Tasks?	Y	Y	Y
Keep-To-Do-Assignments	Will it keep all the information?	N	Y	N
Doc Links	Are they converted?	Y	Y	Y
Excluded hidden folders- custom	Will it migrated user private folders?	N	Y	Y
Personal Address Book	Will it do local names.nsf to contacts?	Y	Y	Y
Personal DL and Membership	Will it translate these names.nsf to contacts?	Y	Y	Y
Server Groups	Can it migrate server groups?	Y		Y
Mail InDB	Can it migrate Mail-in databases?	N	Y	Y
Document Library	Can it migrate document libraries?	Y	Y	N
Discussion Library	Can it migrate Discussion libraries?	Y	Y	N
iNotes Contacts	Will it migrate iNotes contacts to Outlook contacts?	N	Y	Y
Filter Mail	Filter mail based on date?	Y	Y	Y
Filter Attachment	Filter based on size?	*	Y	Y
Filter Calendar	Filter calendar based on date?	*	Y	Y
Filter To-Do	Filter based on date?	*	Y	Y
Powershell	Does it interface with Powershell?	Y	N	Y
Migrate to PST	Will it migrate mail directly to a PST?	N	Y	Y
PST Contains Calendar	Will it migrate calendar directly to PST?	N	Y	Y
PST Contains Tasks	Will it migrate tasks directly to PST?	N	Y	Y
PST Contains Contacts	Will it migrate Contacts directly to PST?	N	Y	Y
Custom Address Mapping	Custom address translation during migration of data?	N	Y	Y
Rules	Will it move Notes client rules to Outlook Rules?	N	Y	N
Rooms/Resources		N	Y	Y
Custom Reoccurring Meeting	Will it migrate rooms and resources to Exchange?	N	Y	Y
Pre-Processing	Do you have any pre-processing setup options?	*	Y	Y
Post-Processing	Do you have any Post-Processing setup options?	*	Y	Y
Domino Directory Manipulation	Does it change the Domino directory?	*	Y	Y
Batch Mode	Can it be  batched?	*	Y	Y
Config Files Required	Does it require a config file for batch migrations?	*	N	Y
Migrate All Document Views	Does it migrate documents not in any folder?	N	Y	Y
Users Created Required ?	Does it require mailbox to exist?	N	Y	Y
Merge Contact to User	Does it do AD manipulation?	Y	N	Y
Mail Enabled users required?	Does it do AD manipulation?	N	Y	Y
Mailboxes Created required?	Does it do AD manipulation?	N	Y	N
Reporting	Are reports available?	N	Y	N
End-User Option	Can an end user DITY?	N	Y	N
Purge mail mode	If you have to restart the migration can you  purge mail first?	Y	Y	N
Merge Mail mode	If you have to restart the migration can you  merge the information without remigrating?	Y	Y	N
Maximum Threads	Can thread count be modified to increase performance?	16	Y	32
Skip Empty Folder option	Can you skip empty folders?		Y
Pre Migration Customizable AD Scripts	Do you provide  free scripts to enhance the process?		Y
Post Migration Customizable AD Scripts	Do you provide  free scripts to enhance the process?		Y
Reschedule Meetings Post Migration	Can you reschedule a meeting successfully POST Migration?		Y

Exchange Back Pressure

After setting up an Exhange 2007 test environment on a Virtual Machine, I noticed an interesting issue with the routing of mail. Actually no mail routed at all, and the user connected whether it be via Outlook or OWA could not send any emails. No warnings, error messages or NDRs were evident to the user and the emails would simply remain within their "DRAFTS" folder.

During my investigation on the Exchange Mailbox server. I noticed a warning within the application log for an

EventID 1009 - warning event with the Source and Category Labeled as "MSExchangeMailSubmission". The description of the event was as follows "The Microsoft Exchange Mail Submission Service is currently unable to contact any Hub Transport Server in the local Active Directory Site. The servers may be too busy to accept new connections at this time".

After discover of the warning on the Mailbox Server I investigated the Hub Transport application log and discovered a warning EventID 15002, Source MSExchangeTransport, Category: ResourceManager. Although a warning this targeted the source of the problem, "Resources". More indepth look at the warning displayed the following information:

The resource pressure is constant at High. Statistics: Queue database and disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que") = 67% [High] [Normal=62% MediumHigh=64% High=66%] Queue database logging disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\") = 67% [Normal] [Normal=91% MediumHigh=93% High=95%] Version buckets = 1 [Normal] [Normal=40 MediumHigh=60 High=100] Private bytes = 19% [Normal] [Normal=71% MediumHigh=73% High=75%] Physical memory load = 83% [limit is 94% to start dehydrating messages.] Inbound mail submission from other Hub Transport servers, the Internet, the Pickup directory, the Replay directory, and the Mailbox server, if it is on a Hub Transport server, has stopped.Loading of e-mail from the queuing database, if available, continues.

Granted servers were not down and services were up and running; however mail was still not flowing. So I decided to do some research and I found a technet article that references this thing called "Back Pressure" for Exchange 2007. Basically Back Pressure is a resource monitoring feature built into Exchange 2007 Hub and Edge Transport server roles, which affects message delivery depending upon the current state of system resources available.

On a Hub or Edge Server the following three levels of system resource utilization are used:

• Normal The resource is not overused. The server accepts new connections and messages.
• Medium The resource is slightly overused. Back pressure is applied to the server in a limited manner. Mail from senders in the authoritative domain can flow. However, the server rejects new connections and messages from other sources.
• High The resource is severely overused. Full back pressure is applied. All message flow stops, and the server rejects all new connections and messages.

All configuration options for back pressure are available in the EdgeTransport.exe.config application configuration file that is located in the C:\Program Files\Microsoft\Exchange Server\Bin directory. The EdgeTransport.exe.config file is an XML application configuration file that is associated with the EdgeTransport.exe file. EdgeTransport.exe and MSExchangeTransport.exe are the executable files that are used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server. Changes that are saved to the EdgeTransport.exe.config file are applied after the Microsoft Exchange Transport service is restarted.

So in order to get my messages flowing referenced the warning EventID 15002 description and modified the "High" level values so that the calculation of my available resources would not exceed this value. Granted, you can increase the available resources (i.e. diskspace) by adding resources, however in my case this was a VM so I decided to go risky route and increase the EdgeTransport.exe.config file values to prove the concept.

In my case I modified the following line entry "PercentDatabaseDiskSpaceUsedHighThreshold" and increased it from 80 to 95.

Once I modified, saved the file and restarted the Transport service, messages were flowing out of the client "Draft" folders. Then I noticed that mail flow seized again, so I resorted to creating another drive/volume for messaging QUEUE and Logs then changed the Queue and Logs location. Of which can ALSO be performed by modifying the EdgeTransport.exe.config file. How to Change the Messaging Queues can be referenced HERE. Once I allocated enough space for the messaging queues, messages were flowing and Exchange was happy.

Reference Back Pressure
Reference Changing Messaging Queues

Protocols - OCS Web Conferencing

Conference Protocols

Office Communications Server 2007 multimedia conferencing uses a variety of protocols for signaling, conference management, data collaboration, multimedia, and communication among conference components.

SIP (Session Initiation Protocol). An IETF (Internet Engineering Task Force) standard signaling protocol for initiating, managing, and terminating sessions between one or more participants, including Internet telephone calls, multimedia distribution, and multimedia conference sessions.

HTTP (Hypertext Transfer Protocol). A standard Internet protocol that in Office Communications Server 2007 is for communication between the Focus and conferencing servers, downloading Address Book Server updates to clients, and downloading meeting content to users.
C3P (Centralized Conference Control Protocol). A custom protocol for communicating conference creation and control commands from clients to Office Communications Server 2007. C3P commands are carried as XML in SIP SERVICE or INFO messages.

PSOM (Persistent Shared Object Model). A custom protocol for transporting Web conferencing content.

SRTP (Secure Real-Time Transport Protocol). An IETF standard protocol that is used in Office Communications Server 2007 for securely transporting audio and video content to various media devices.

RTCP (Real-Time Control Protocol). An IETF standard protocol used in conjunction with SRTP to convey information about the signal quality of an audio-video conferencing session to various media devices.