Researching Exchange 2007′s EdgeTransport.exe.config

Whilst there are a lot of features in Exchange 2007 that can be configured and tweaked using the GUI and Powershell I have on several occasions (bare in mind I work in Managed hosting so these occasions are not all for the same installation) needed to ‘play’ with the settings in EdgeTransport.exe.config file [which should be located in C:\Program Files\Microsoft\Exchange Server\Bin\].

EdgeTransport.exe.config appears to be XML which is extremely useful for something else I’ll be releasing sometime soon and it also makes comprehension a breeze. Unfortunately whilst you can easily understand which variable you are changing its not always obvious what that variable does and what that impact could be.

On the subject of impacting changes it might be good idea to note that the features in this config file are probably hidden away to prevent us from breaking stuff!

Resource Related


    If you’ve heard of ‘Back Pressure‘ then you already know what this key does. Exchange 2007 Resource monitoring is a good idea until it strikes.
Back Pressure WarningOf course it should never strike as you should be paying attention to the warnings in the Event Log.

Back Pressure is a system resource monitoring feature of Exchange 2007 that responds to low resources by refusing incoming mail (its more complicated than that but I’m bitter)
The following system resources are monitored as part of the back pressure feature:

  • Free space on the hard disk drive that stores the message queue database.
  • Free space on the hard disk drive that stores the message queue database transaction logs.
  • The number of uncommitted message queue database transactions that exist in memory.
  • The memory that is used by the EdgeTransport.exe process.
  • The memory that is used by all processes.
    If email isn’t being delivered because of BackPressure you can either resolve the issue or change the key to false and restart the Transport service. Microsoft strongly discourages disabling back pressure checks.

    The following entries are related to Resource Monitoring:
        This dictates the interval in which resources are checked the default is 00:00:02 [HH:MM:SS]


        All these key’s have defaults of 0 and they define the percentage threshold for whether resource utilisation is considered Normal, Medium or High. The valid range is between 0, 3 – 100. The caveat is that the value must be lower than the severity above it.

        This seems to be some form of swap space, its not where messages get dumped for pickup and its not where queued messages live either. Moving it to a faster disk can’t hurt.


    One of the reasons why you may run out of disk space is either the transaction logs or the Queue’s. (By default everything lives on C:\) All queue related settings start with QueueDatabase.

        This parameter specifies the number of database I/O operations that can be grouped together before they are executed. Microsoft makes it very clear that you shouldn’t change this as the default (40) has been chosen carefully to ensure that if the I/O cost of a message exceeds the value specified in the QueueDatabaseBatchSize parameter, that message is committed to the queue database immediately. Otherwise, it will be combined with other messages received, and they will be committed to the queue database together.

        Waiting for the QueueDatabaseBatchSize buffer to fill could take some time so if the BatchTimeout is reached before the BatchSize limit is reached then the database I/O operations are performed.

        Dictates the number of ESE (Extensible Storage Engine) database connections that can be open.

        Dictates the maximum size of a transaction log file. When the maximum log file size is reached a new log file is opened. (As you can imagine this is what chews through disk space)

        Dictates the size of the memory buffer allocated for the Queue logging.

        Unfortunatly I can’t find much information about what these cleanup tasks actually are but this key limits how many of them can run concurrently.

        Allows the Queue database to be defrag’d whilst online. Microsoft doesn’t offer any reasons as to why you would want to disable this.

        Specifies the interval between defrag’s, uses the same HH:MM:SS format as other interval keys.

        Limits how long the Defrag process can run for, uses the same HH:MM:SS format as other interval keys.

    QueueDatabasePath & QueueDatabaseLoggingPath
        If you can afford to have a completely seperate disk for the Queue DB and Queue logs then this allows you to dictate where they are. After restarting the Transport it will move / recreate the files.

        This dicates the maximum percentage of Physical memory that all Exchange (well Transport related) processes can take up. When it hits this limit Message Dehydration starts

        If the limit delcared by PercentagePhysicalMemoryUsedLimit is reached and this key is set to true then in Memory Message content will be flushed based on criticality (i.e it’ll start removing mime content etc)


        A list of changes that are made to the message queue database is kept in memory until those changes can be committed to a transaction log. Then the list is committed to the message queue database itself. These outstanding message queue database transactions are kept in memory and are known as version buckets. The number of version buckets may increase to unacceptably high levels because of virus issues, problems with the message queue database integrity, or hard disk drive performance. As with other Threshold keys the value of a key can not be larger than a more severe key.

         I can not find any information about this key (which would suggest we should leave it well alone!) but with a default value of only 3 I can only imagine it might refer to the last 3 transactions logs that it has written the versionBuckets to.

    Useful Tweaks


    This key dictates the baseline age for public folder replicas. The public folder database that has the best age rating is selected as the preferred public folder database.


        This dictates the amount of time a mailbox or remote delivery queue that can be in a state of retry and messages will still be automatically resubmitted (if the messages are not in a suspended state).


        This key dictates how frequently the mailbox delivery queues on a Hub Transport server try to connect to a Mailbox server destination that can’t be successfully reached.


        This appears to dictate the path for the Content filter database (the Content Filter Agent). This probably isn’t too read/write intensive so probably doesn’t need to be moved.

        This dictates the log location for Content Filter Agent. As with the Database itself I doubt this is very read/write intentsive so probably doesn’t need to be moved.

    Shared Transport Database Cache

        This parameter specifies the maximum size of the database cache in memory.

        This parameter controls the total allowed size of all uncommitted transaction logs that exist on the hard disk drive. Setting the value of the DatabaseCheckPointDepthMax parameter too low can cause significant performance issues because uncommitted transactions are forcibly committed to the database instead of being written to transaction logs.


        These parameters enable or disable the removal of cached database transactions from memory when the cache is overused. The values of these parameters represent the percentage of the cache that is unused. When the free database cache resources drop under the specified percentage, a background process writes the cached database transactions to the transaction log.



        The message expiration time-out specifies the maximum length of time that a Hub Transport server tries to deliver a failed message. After this time an NDR is generated. The values for these have a slightly different time format as it is d.HH.MM.SS this allows you to specify days without having to count all the hours in 8 days!



        After each message delivery failure, the Hub Transport server generates a delay delivery status notification (DSN) message and queues it for delivery to the sender of the undeliverable message. This delay DSN message is sent only after a specified delay notification time-out interval, and only if the failed message wasn’t successfully delivered during that time. This uses the same d.HH.MM.SS format as the XPriorityMessageExpiration keys.



        The maximum number of connections per domain specifies the maximum number of connections that a Hub Transport server can have open to any single remote domain. I’m not sure about you but my first impression was that this read as Max Connections Per XPriority Domain and that this allowed you to designate a ‘High Priority ‘ delivery domain. In fact it seems (let me know if I’m wrong) its the amount of connections available for differing message priorities irrespective of the destination domain. One caveat to remember is that the sum of these values must not exceed MaxPerDomainOutboundConnections. You can check what this value is with the following PowerShell command:

    Get-TransportServer SERVERNAME | Format-List | findstr /B MaxPerDomainOutboundConnections
    Power Shell output for command involving MaxPerDomainOutboundConnections
    Obviously you could omit the findstr arguement and view all the settings for this particular server.

        In order to make use of the settings above you will need to ensure that this is set to true


         This allows you to dictate the maximum size of a High priority message coupled with this PowerShell command:
    set-mailbox test -DowngradeHighPriorityMessagesEnabled 1
    You can allow certain users to send quite large High Priority messages. Unfortunatly setting the variable doesn’t result in any feedback so best to check with the following PowerShell command:
    get-mailbox test | fomat-list | findstr /B Downgrade
    PowerShell output for setting a users DownGradeHighPriority Boolean PowerShell output for getting a users DownGradeHighPriority Boolean


    Queue Glitch

    Queue glitches are when a Hub or Edge transport server cannot connect to the next hop this puts the queue into a state of retry.

        This dictates the number of connection attempts that are immediately tried when a transport server has trouble connecting with the destination server. If you need more than the default then you probably need better network infrastructure!

        The queue glitch retry interval specifies the interval between each connection attempt that is specified by the QueueGlitchRetryCount parameter.

    Intriguing Entries

    Recipient Resolver

        Reporting and diagnostic information for recipient resolution is provided by performance counters, message tracking log entries, and recipient resolution logging. These sources can help you identify and diagnose problems with recipient resolution. The valid values for this parameter are Disabled, Enabled, and FullContent. The default value is Disabled. When the ResolverLogLevel parameter is set to Enabled, only message envelope data is logged. When the ResolverLogLevel parameter is set to FullContent, message envelope data and message header data is logged.

        Recipient resolution requires an Active Directory query and if the Active Directory query encounters any transient errors, the message is returned to the Submission queue and deferred for the time that is specified by the ResolverRetryInterval parameter.

    This dictates the maximum number of envelope recipients in a message, this is the limit of the Recipient expansion not an actual upper limit for the amount of recipients a message can be sent too.

    The Transport Dumpster

        Transport Dumpster is a new feature of Exchange Server 2007 Hub Transport servers through which the transport can defer the deletion of certain emails in their queues. The condition for an email to be retained in the transport dumpster is that at least one of the recipient’s mailboxes must resides on a CCR mailbox server. This retained email can later be re-delivered if necessary. The amount of mail retained in the queues is a Organization wide setting on the Transport Settings container.

    The idea is if an Active CCR mailbox server ‘fails over’ then messages that have not yet replicated can be ‘redelivered’ to the newly Active mailbox server.

        By default this is set to false, I can only assume that this means there is some algorithm or threshold that dictates what mail is retained in the dumpster if this is set to false. I dread to think what the overheads would be if setting this to be true allows you to store ALL email in the dumpster.

        Also set to false by default, I’m assuming that by allowing Duplicate delivery it will attempt a delivery even if its sure its already done it once just in case.

        I guess this means that a Hub transport server will flush whatever is in the dumpster upon startup.


        The default for this is ‘Lenient’ which I expect would allow a certain amount of DNS lookup failures for before triggering a DSN. The other option is ‘Normal’

  • LenientWhen the DNS query encounters a combination of valid MX records and invalid MX records, the DNS query continues until the DNS query time-out value of one minute is reached. The invalid MX records are discarded. And the valid MX record that has the lowest preference value is used to deliver the message to the destination messaging server.
  • NormalWhen the DNS query first encounters an invalid MX record, any resolved MX records that have a preference value that is greater than or equal to the invalid MX records are immediately discarded. The remaining MX record that has the lowest preference value is used to deliver the message to the destination messaging server without waiting for the whole DNS query to time out. Although this behavior may result in faster message delivery, the potential drawback of this behavior is the DNS query may have no valid MX records if the following conditions are true:
            The invalid MX record is the first MX record for the destination domain.
            The valid MX records have the same precedence value as the invalid one


        By default, Microsoft Exchange Server 2007 logs all anti-spam agent activity in the %programfiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog directory. To disable this logging change this to false.

    The following items can be added and control the Spam Agent logs:
    <add key="AgentLogMaxDirectorySize" value="system.int32" />
    <add key="AgentLogMaxFileSize" value="system.int32" />
    <add key="AgentLogMaxAge" value="system.timespan" />


        This is another unlisted key that would appear to dictate the maximum number of items returned when listing the contents of a queue.


        The routing table is recalculated and logged after a routing configuration change, or if no changes have been detected within the interval specified in this key. However, a regular routing configuration change occurs on every Hub Transport server and Edge Transport server when the server renews its Kerberos token with an Active Directory directory service domain controller. With this renewal, the routing table is recalculated and a new routing table log is created. The Kerberos token is renewed every six hours.


        In Microsoft Exchange Server 2007, the 7-bit transfer encoding method for MIME format is fixed to Quoted-Printable (QP) encoding. This key is only present in Exchange 2007 SP1. The value of this key can be one of the following:
    0 Always use default 7-bit transfer encoding for HTML and for plain text.
    1 Always use QP encoding for HTML and for plain text.
    2 Always use Base64 encoding for HTML and for plain text.
    5 Use QP encoding for HTML and for plain text unless line wrapping is enabled in plain text. If line wrapping is enabled, use 7-bit encoding for plain text.
    6 Use Base64 encoding for HTML and for plain text, unless line wrapping is enabled in plain text. If line wrapping is enabled in plain text, use Base64 encoding for HTML and 7-bit encoding for plain text.
    13 Always use QP encoding for HTML. Always use 7-bit encoding for plain text.
    14 Always use Base64 encoding for HTML. Always use 7-bit encoding for plain text.


        Despite going through technet, the Microsoft print pocket consultant and Exchange 2007 unleashed I’ve yet to find out what these keys do;

         The timeout between retrying all deferred mail?

         An attempt to prevent back scatter from clogging the deferred queue?

         I can’t even begin to guess

         Appears to be something that responds to either a component crash or an OS STOP error.

         The interval between attempts to deliver to a mailbox that is being moved?


    Microsoft Technet
    Exchange Team Blog

    Posted in Email, NAMOS
    0 comments on “Researching Exchange 2007′s EdgeTransport.exe.config
    1 Pings/Trackbacks for "Researching Exchange 2007′s EdgeTransport.exe.config"
    1. [...] Researching Exchange 2007’s EdgeTransport.exe.config [...]

    Leave a Reply