The first thing we need to do is install the pre-requisites via a privileged PowerShell;

Import-Module ServerManager
Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart
















Once the machine has restarted you will need to ensure you set the machine name and a DNS suffix.

Assuming the checks all work you can click install and off you go;















Once all is installed the next step is to prepare a config bundle / auth package (I can’t quite remember what Microsoft call it) by issuing the following command in the EMS on the Edge server;
New-EdgeSubscription -FileName "C:\EdgeSubscriptionInfo.xml"

With that done you can either attempt to import the file via the EMS on a Hub Transport server or utilise the EMC. I chose the EMC as I kept on running into syntax errors and I was being impatient;















Unfortunately I hit an issue which was probably due to a very poor choice of mine in transfering the file. A quick rethink of moving the file and the Edge Synchronisation was complete;















The dialog shows a warning claiming the port 50636 needs to be available and the host be contactable, I checked with telnet and all was OK. So maybe the warning icon was just to draw my attention to it.

Once that is done simply issue the command;

Start-EdgeSynchronization

Unfortunately within minutes of me adding this server as a secondary MX I received a spam message which wasn’t very fun;

Return-Path: XXXXXXXXXX@yahoo.com
X-MS-Exchange-Organization-PRD: yahoo.com
Received-SPF: None (XXX-XXXX-XX.networksaremadeofstring.co.uk: XXXXXXXXXX@yahoo.com does not designate permitted sender hosts)
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.5705.600;SID:SenderIDStatus None;OrigIP:195.XXX.XXX.122
X-MS-Exchange-Organization-SCL: 5
X-MS-Exchange-Organization-SenderIdResult: NONE
X-MS-Exchange-Organization-AuthSource: XXX-XXXX-XX.networksaremadeofstring.co.uk
X-MS-Exchange-Organization-AuthAs: Anonymous

This is extremely easy to do but I haven’t posted anything in a while so I thought I’d document the process.

To start just load up the Programs and Features section of Control Panel, choose Exchange and select Uninstall.















The first screen is utterly pointless

At the next screen you need to deselect the options you no longer require. Ideally as I’m Uninstalling and not Modifying the installation I’d have thought you’d select that which you want to remove.






























Clicking next will start the uninstall process

Unfortunately even though this machine wasn’t actually doing anything there was still a connector that used this server as a source transport server so the uninstall of the Hub Transport Role failed.















To resolve this all you need to do is load up the Exchange 2010 Management console, navigate to the Hub Transport role within the Organisation Configuration and in the Send Connectors tab remove the Connector that uses the server as a source.















Running the uninstaller again allows all the Readiness Checks to pass















Nearly 2 hours later (This machine had virtually no RAM as I’d allocated it elsewhere) the uninstall completed















Easy as anything.

A base copy of Windows Server 2008 (non R2) will have the following pre-requisites;

.Net 3.5 (SP1)
PowerShell 2.0
Office 2007 System Converter Filter Pack

Once these are installed you will need to wield ServerManagerCmd and get some other things installed;

ServerManagerCmd -i RSAT-ADDS
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression
ServerManagerCmd -i Web-Net-Ext
ServerManagerCmd -i NET-WIN-CFAC

This went exceptionally smoothly and then it was time to run the Exchange 2010 setup.

Unfortunately it threw an error regarding the Net.Tcp Port Sharing service needing to be set to automatic;



















To fix this just set the service to auto start;
sc config NetTcpPortSharing start= auto

A quick retry of the Readiness checks came back with a clean bill of health and we are good to go!

Just over half an hour later Exchange 2010 is installed and ready to go!



















Since my last post regarding Exchange I’ve been using the Active Directory Certification Services to handle all my SSL stuff which worked lovely with IIS7 and Exchange 2010 so there was no need to do any of the crazy private key recovery stuff as we did with Exchange 2007.

A full install and even a test mailbox migration in just over an hour, not bad.

Cross Forest trusts are a possibility and merging one with the other (i.e having the Hosted Exchange solution bound to the existing domain) is another but there are many issues with that (mostly political).

What I intend to do is utilise the ‘Branch office’ concept that Read Only Domain Controllers were designed for to mock up a solution for Hosting the entire AD infrastructure remotely and having R/O DC’s on the customer premises.

What now?

For no other reason than that of satisifying my curiosity I built an entire AD infrastructure hosted at the data center and then had a remote ‘office’ running for a day without a local DC and then the following day with a Read Only Domain Controller sitting there.

There’s nothing new or crazy here other than maybe the fact that most people move bits of their AD infrastructure to the DC when its bandwidth requirements overwhelm their resources. What I’m playing with is the idea of having everything remote and only putting the stuff you need (NAS etc) in the office.

The Test

In the Red Corner we have a full Active Directory and Exchange infrastructure at the DC and then the ‘offices’ were built using a few Terminal Services servers running a respective amounts of users. The idea is to monitor traffic before dropping in a RO DC and then again afterwards.

The Infrastructure

Hosted Infrastructure

The Hosted infrastructure consists of a relatively standard Exchange 2007 deployment (if you follow the guidelines) visible to the world (selected ports only) is an Edge Transport server for handling the initial mail connections and the Client Access Server. Behind those is the Mailbox and Hub Transport (in reality these were on the same box but the diagram wasn’t as symmetrical then!).


The Domain controller is a special case because whilst we have no reason for the Internet at large to talk to it we need the read only Domain Controller at the client site to be able to communicate with it so an IPSEC LAN to LAN VPN was required.

The Results

AD Traffic From the TS to the Remote DC No Local DC

AD Traffic to the Remote DC with Local RODC

OWA Traffic During the Tests

Scripted behavior – so it was the same(ish) on both days

Conclusion

Well it did exactly what I expected it to do so nothing ground breaking there. It was interesting to see the spike just after I logged all the fake users off the Terminal Servers.

R/O DC’s were used because in an ideal world customers shouldn’t have write access to an AD infrastructure that a SysAdmin has an SLA to honor!

I took a selection of decommissioned mid-range [Pentium Dual Core / SATA I Disks etc] Workstations to which I installed CentOS 5.0 and the CleverSafe software. 4 IDE SliceStores and an Accesser provides enough IOP throughput for around 50 mailboxes. Ramping this up to 6 SATA SliceStores and there is enough IOP throughput for 70 mailboxes.

We’re obviously not talking about large scale Enterprise / Data Centre solutions here but for a small scale Exchange install [I'm thinking Test Lab setups maybe at a push a SOHO install] that needs reliable disk storage this seems to work quite well especially if used as the target storage for LCR [Consider that powering up a couple of old workstations is probably cheaper than the purchase of a decent SATA II hardware RAID card and extra disks.]

Utilising a 1Gb/s Network would improve the throughput considerably but for this test I was only utilising 100Mb/s between the Accesser and the Exchange server with a latency of around 40m/s so a constant Read Throughput of 2.8Mb/s will have to do.
 
 
DSNet offers access to the Storage ‘Vault’ via an iSCSI interface so there isn’t any extra work involved in preparing the Vault for use with Exchange 2007. Since this isn’t a normal SCSI device you have to disable “Synchronous Transfer” and “Tagged Queuing”. Their purposes are detailed here. Since these are enhancements to the operation of SCSI it shouldn’t adversely affect the operation of Exchange.

With the disks mounted and formatted it was a simple matter of changing the Queue and DB locations with PowerShell:
Move-StorageGroupPath -Identity "Second Storage Group" -LogFolderPath:"D:\Mailbox\Second Storage Group" -SystemFolderPath:"D:\Mailbox\Second Storage Group"

Running the Exchange server for a couple of days shows no degradation in usability even when a DSNet storage Vault was used for the Mailbox stores as well as the LCR.

Looking at other DSNets that are out there and looking at the potential for improvements in this DSNet then it may be possible to scale a DSNet out to production grade usability, if I have enough time and can get hold of some newer SATA II disks, better machines and a gigabit LAN infrastructure I’ll do a proper experiment and see what can be acheived.

Turns out that there has been a massive drop in Spam levels coming through some of the filters I have dotted around the place.

C&C or Spam Hosts?

I wrote a little script to see what percentages of machines that had made incoming connections that were then classified as spam were still alive.

The majority of hosts were still contactable in some way shape or form but weren’t listening on known SMTP ports, some were alive and actively listening on SMTP ports. A small percentage were totally offline.

This basic test appears to indicate that the Datacenter that went offline was merely a Command & Control hub rather than actual spamming hosts.

Elsewhere

Just to make sure that there were no anomolies with my graphs I checked a few other places and it does indeed appear that there is a worldwide drop in spam:


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
It probably won’t be long until the levels are back where they used to be but for now our AntiSpam servers can rest for a while.

IPv6 Only Domain Controllers:

The installation didn’t cause any trouble but after initially logging on and running a DCDiag we see this:

It turns out that the install of the DNS Server had set the NIC’s properties to be ::1 but the DNS Server was only listening on the Static Site Local address FEC0::2 and its self assigned Link Local. This of course caused all DNS reliant checks to fail and cause a whole world of pain.
 
 
 
 
 

Changing the NIC DNS properties to FEC0::2 resulted in a different set of errors:

There were actually 10′s of the System Log errors which made me panic for a bit till I remembered that this is expected behaviour. The expected behaviour is that if there are any Warnings or other bad apples in the Event logs DCDiag will throw some unfriendly errors.

These errors appear to be even more unfriendly owing to a bug in how the Event Viewer copes with IPv6 address.
 
 
 
 
 
 

A quick purge or the Event logs later and we are back in business:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Preparing the Exchange Server

Exchange 2007 has several prerequisites that need to be installed before Setup can be successfully launched. First I’ll add the prerequisites that don’t affect / require a machine to be bound to a domain, if they install correctly then I’ll bind it to the domain (and see how that goes) and finish off with the prerequisites that require a machine to be bound to the domain.

Installing the non-domain related roles / features went smoothly:

 
 
 
 
 
 
 
 
 
 
 
 
Unfortunately binding to the domain was not as smooth:

The first issue to resolve is whether Windows Server 2008 actually wants a A record or whether someone just hasn’t got round to updating the error dialog.
 
 
 
 
 
 
 
Firing up the NSLookup tool we see that [despite some timeouts (??)] DNS is working as expected. Although this was evident because the SRV lookups for the domain resulted in the name of the Domain Controller.

 
 
 
 
 
 
 
 
So I did what every curious Windows Admin knows might fix the problem, do it again. And who’d have guessed it?

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Hmm, well with that sorted and following a quick reboot its time to see if the final prerequisite piece of the puzzle works:

Excellent!

There are a few errors but these may not be show stoppers.

Onto the next stage!
 
 
 
 
 
 
 
 
 
 

Installing Exchange 2007 on an IPv6 Only 2008 Server

Well unfortunately we’ve stumbled at the first hurdle:

 
 
 
 
 
 
 
 
 
 
 
 
 
The link the error mentions tells us the following:

IPv6 is only supported in Exchange 2007 SP1 when it is installed on a Windows Server 2008 computer that has both IPv4 and IPv6 enabled. If you disable the IPv4 protocol, Exchange 2007 SP1 can't support IPv6.

Well screw that, the Install button hasn’t greyed out so onwards to Victory!

 
 
 
 
 
 
 
 
 
 
 
 
 
Setup claims to have installed, lets see if the SMTP element is contactable:

 
 
 
 
 
 
 
 
 
 
 
 

Using Exchange 2007 in a Native IPv6 Environment

OWA worked without any major hassles and sending internal email worked fine. Unfortunately trying to send email to an ‘external’ host resulted in a “451 4.4.0 DNS Query Failed”.

Looking through the Event Logs I found this:

 
 
 
 
 
 
 
 
 
 
 
Running the suggested powershell command did indeed show that no DNS Servers were set:

 
 
 
 
 
 
 
 
No matter what I did using netsh or the NIC GUI the error remained, I resorted to setting the DNS entries in the Hub Transport server properties:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
We now get another error but hey at least its progress:
451 4.4.0 primary target IP address responded with "421.4.4.2 unable to connect."attempted failover to alternate host, but that did not succeed.Either there are no alternate hosts, or delivery failed to all alternate hosts.

Turns out I forgot to make the Postfix server listen on its IPv6 address :/ A few quick config changes later and Victory is mine!

 
 
 
 
 
 
 
 
 
 
 

Conclusion

Well its a bit painful to get going but it appears to work once setup. I’ll keep this going with some scheduled in and out email to see if it dies after a week or so.

There were three issues to clear up. First there were 2,435,239 emails from the Botnet destined for a domain that was no longer hosted on the ‘backend’ server. Secondly none of this email was being Spam checked and finally the massive queues meant that the 568,372 legitimate emails stuck in the queue were being delayed by upto 8 hours.

Preventing Spammers getting to the queues

As it was evident that a Botnet was sending the spam the first thing to do was to enforce some of the settings that Postfix is capable of doing ‘out of the box’ to try and stop these hosts bombarding the server. [More information about these settings here: Leveraging Virtualisation to Fight Spam]

#Stop people hammering the hell out of us
smtpd_data_restrictions = reject_unauth_pipelining

#Start off with some blacklisting
# Check our black / white list | RealtimeBlacklist | Realtime blacklist
smtpd_client_restrictions = permit_sasl_authenticated, check_client_access hash:/etc/postfix/client_access, reject_rbl_client sbl.spamhaus.org, reject_rbl_client dul.dnsbl.sorbs.net

#Make clients use EHLO / HELO verbs
smtpd_helo_required = yes

#If we are being REALLY strict make them conform to the RFC
#strict_rfc821_envelopes = yes

#Now we make them say hello politely
# Crap remote hostname remote host not FQDN
smtpd_helo_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname

# Non FQDN target email Allow inside Only relay our domains
smtpd_recipient_restrictions = permit_sasl_authenticated, reject_non_fqdn_recipient, permit_mynetworks, reject_unauth_destination


Spam Checking

An article on FreeSpamFilter.org shows you how to add Amavisd-new, SpamAssassin, Pyzor, Razor, DCC, and ClamAV to a Postfix setup. The article is geared towards Fedora 4 but works equally well on CentOS (the server in question) and RHEL etc. The article is very indepth and doesn’t require any further explaination.

Clearing Out the Queues

The final issue (and the bit of this Blog that is different to the Virtualisation one linked to earlier) is that I had to clear out these queues no matter what!

Postfix have some detailed explainations of some of the troubleshooting tools available and advice on what to do in this situation.

I however decided to write some ‘Sledgehammer to open a nut’ type scripts to fix the issue.

First of all with the number of emails in the queue qshape was unusable and the majority of the mails were deferred. So this script looks in the deferred queue directory, matches the domain name in question and then calls postsuper to delete the mail from the queue:


#!/bin/bash
lastid=0

cd /var/spool/postfix/defer
grep -R "DOMAINNAME" * | awk '{print $1}' | while read line; do
   x=${line%:*}
   mailid=${x#*/}
   if [ $lastid = $mailid ]; then
     echo Deleting MailID $mailid
     postsuper -d ${mailid%:*}
     lastid=${mailid%:*}
   else
     lastid=${mailid%:*}
   fi
done


This second script is for handling the massive amount of bouncebacks that had been generated and were sitting there trying to be delivered to either some poor persons back scatter targetted address or non existant domain. Something to note is that this would obviously have deleted all legitimate bouncebacks etc.


#!/bin/bash
# Delete all bounce backs from MAILER-DAEMON
# Blah blah rfc compliance blah blah
postqueue -p | grep MAILER-DAEMON | awk '{print $1}' | while read line; do
   echo Deleting MailID $line
   postsuper -d ${line%\**}
done;


I’m pretty sure that some people will object to these scripts but they did the job and the server is now swatting these botnet spam surges with ease.

To get started you’ll need to download the Cmdlet from here.

Once download you will need to extract it somewhere (in this example I just dropped it in C:\) and then install it by running the following command:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe C:\NAMOS-HiddenTransportConfig.dll

You should get the following output:

Next Load up PowerShell and run the following command:
Get-PSSnapin -registered

You should see something similar to the following:










Now you can either type
add-pssnapin NAMOS-HiddenTransportConfig
into the console each time or create a shortcut similar to the following:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -noexit -command add-pssnapin NAMOS-HiddenTransportConfig

If you typed it into your current console you will not get any feedback unless it fails:

Now that the cmdlet is installed you have two commands at your disposal:
get-HiddenTransportConfig

This will get the entire EdgeTransport.exe.config file and format it nicely:

You can pass a single arguement to get-HiddenTransportConfig which is the name of a key to retrieve the details of just that key:












The other command at your disposal is:
get-HiddenTransportConfigDescription

This takes an arguement of a key name and then queries this website to get the most up to date description of that keys purpose.












Feel free to provide any feedback or suggestions. Please bare in mind that this software is provided AS IS without any warranty whatsoever

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

EnableResourceMonitoring

    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.
Of 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:

 
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:
ResourceMonitoringInterval
    This dictates the interval in which resources are checked the default is 00:00:02 [HH:MM:SS]

PercentageDatabaseDiskSpaceUsedHighThreshold
PercentageDatabaseDiskSpaceUsedMediumThreshold
PercentageDatabaseDiskSpaceUsedNormalThreshold
PercentageDatabaseLoggingDiskSpaceUsedHighThreshold
PercentageDatabaseLoggingDiskSpaceUsedMediumThreshold
PercentageDatabaseLoggingDiskSpaceUsedNormalThreshold
PercentagePrivateBytesUsedHighThreshold
PercentagePrivateBytesUsedMediumThreshold
PercentagePrivateBytesUsedNormalThreshold
    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.

TemporaryStoragePath
    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.

QueueDatabaseX

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.

QueueDatabaseBatchSize
    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.

QueueDatabaseBatchTimeout
    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.

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

QueueDatabaseLoggingFileSize
    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)

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

QueueDatabaseMaxBackgroundCleanupTasks
    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.

QueueDatabaseOnlineDefragEnabled
    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.

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

QueueDatabaseOnlineDefragTimeToRun
    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.

PercentagePhysicalMemoryUsedLimit
    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

DehydrateMessagesUnderMemoryPressure
    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)

versionBucketsHighThreshold
versionBucketsMediumThreshold
versionBucketsNormalThreshold
    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.

versionBucketsHistoryDepth
     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

PFReplicaAgeThresholdhours

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.

MaxIdleTimeBeforeResubmit

    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).

MailboxDeliveryQueueRetryInterval

    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.

IPFilterXPath

IPFilterDatabasePath
    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.

IPFilterDatabaseLoggingPath
    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

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

DatabaseCheckPointDepthMax
    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.

DatabaseCacheFlushStart
DatabaseCacheFlushStop
    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.

XPriorityMessageExpirationTimeout

HighPriorityMessageExpirationTimeout
NormalPriorityMessageExpirationTimeout
LowPriorityMessageExpirationTimeout
    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!

XPriorityDelayNotificationTimeout

HighPriorityDelayNotificationTimeout
NormalPriorityDelayNotificationTimeout
LowPriorityDelayNotificationTimeout
    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.

MaxPerDomainXPriorityConnections

MaxPerDomainHighPriorityConnections
MaxPerDomainNormalPriorityConnections
MaxPerDomainLowPriorityConnections
    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

Obviously you could omit the findstr arguement and view all the settings for this particular server.
 

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

MaxHighPriorityMessageSize

     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


 
 

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.

QueueGlitchRetryCount
    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!

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

Intriguing Entries

Recipient Resolver

ResolverLogLevel
    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.

ResolverRetryInterval
    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.

ExpansionSizeLimit
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.

DumpsterAllMail
    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.

DumpsterAllowDuplicateDelivery
    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.

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

DnsFaultTolerance

    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’

AgentLogEnabled

    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" />

MaxQueueViewerQueryResultCount

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

RoutingConfigReloadInterval

    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.

ByteEncoderTypeFor7BitCharsets

    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.

Unknowns

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

DeferredReloadTimeoutSeconds
     The timeout between retrying all deferred mail?

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

PrivateBytesHistoryDepth
     I can’t even begin to guess

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

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

References

Microsoft Technet
Exchange Team Blog