Category Archives: hub transport

5.3.2 STOREDRV.Deliver: Missing or bad StoreDriver MDB Properties When Using Address Book Policy Routing in Exchange 2013

Exchange 2013, Hosting, hub transport


If your using the new Address Book Policy Routing Agent to assist in separating your tenant organizations, you may run into a situation where a user is not able to receive email sent to them.  If you check the message tracking logs with:

Get-MessageTrackingLog –Recipients

You may get a result similar to this one below:


As we can see, our original email to generated an Undeliverable.

Of particular note is the Recipient Status where it lists 532 5.3.2 STOREDRV.Deliver: Missing or bad StoreDriver MDB properties.

There are two causes of this.  The first seems to be a bug where the mailbox is hidden from address lists:


This appears to be fixed in Exchange 2013 CU2.  A workaround is to uncheck the hide from address lists box.  See this forum post by Greg Taylor of Microsoft:

The second cause, is not a bug but expected behavior. If the user you are trying to email to, is not a member of the GAL that is in their Address Book Policy, the email routing will fail.  I’ll give you an example.

In our case, we tried to email

The user has an Address Book Policy applied to him called ABP-Soa


If we check that address book policy with Get-AddressBookPolicy ABP-Soa we can see that the Default Global Address List is GAL-SOA


If we check the filter of that Global Address list with Get-GlobalAddressList GAL-SOA | select RecipientFilter:


We can see that the GAL is filtering for all recipients that are of the type UserMailbox that also has CustomAttribute1 set to value SOA.

If we check the mailbox


So, there is our problem.  SOA-User1 has the Address Book Policy ABP-SOA assigned to him, which forces him to get the Global Address List GAL-SOA.  But since we failed to set CustomAttribute1 to SOA on his mailbox, he is actually not even showing up in his own GAL.  This is causing the routing issue.  We can simply fix this by ensuring the user is presented in his own GAL, in this case adding CustomAttribute1 with a value of SOA:


And you should be all set. 

Issues with IPv6 and Transport Servers using DNS Delivery in Exchange 2007 and General Troubleshooting Steps

exchange 2007, hub transport


I recently ran into a little bit of an issue at a company I was working with regarding their Exchange 2007 installation.  At the company, we had installed 2 Edge Transport servers in their main site in NY, and 1 Edge Transport server at their secondary location in Boston. 

One of their user’s complained that when they sent email to a specific domain, say, they were getting delivery delayed messages, and eventually full blown NDR messages:

12-Oct01 14.39

12-Oct02 14.41

As we can see by the NDR, the message expired.  This happens when Exchange cannot connect to a certain destination mail server (such as the receiving company’s server is down), or there is no path to the destination.  The 1st is usually the fault of the receiving organization, the second is usually a configuration problem on your end.  Needless to say, we set out to troubleshoot.

Some basic stuff out of the way first.  All three Edge Servers were configured identical, and all experienced the same exact behavior.  All use Send Connectors, configured to deliver email using DNS, and thus connect directly to the destination domain.

The first thing I did, was the old telnet to the email server trick, and see if I can send email manually through telnet.  First, you need to figure out the receiving email server for the domain in question.  You can do this using the nslookup command.  In a command prompt, enter the command nslookup and hit return.  This will cause the machine your working off of to connect to its default DNS server, in NSLOOKUP mode.

Now, how do we find the server or servers that are responsible for receiving email on behalf of the organization?  Why, by searching for MX records of course!  In NSLOOKUP, tell the DNS server that you only want to know the MX records for a domain.  You do this by setting the query to MX only with the set q=mx command:

12-Oct04 14.49

Next, enter the domain you are having trouble with, such as

12-Oct05 14.50

All the entries listed, are servers that receive email on behalf of  Next, we want to see if we can send email to those servers, using telnet.  Which server should we pick?  Honestly, since they are all the same priority, to be really thorough, you can do all.  If one had a lower priority, start with that one, and work your way back up through the highest one.

Open up another command prompt, and run the command telnet 25 and hit enter:

12-Oct06 14.54

This is your greeting from the remote server.  Now, to send email, you must issue several commands.  First, introduce yourself using the helo command.  Replace with the external DNS name of the server your connecting from.  If you don’t, the remote server may tell you that you forged your name:, and it may reject your email:


12-Oct07 14.58


12-Oct08 14.59

The whole process will end up looking like this:

12-Oct10 15.05

Okay, we’ll this means email was successfully sent from my Edge Transport server, to their email servers.  So that means that their wasn’t any connectivity issue between the servers.  Hmmm.  Next, on to Connectivity Logging!

Connectivity logging is not turned on by default, but can be configured by right clicking on the server in the console, and going to properties->Log Settings:

12-Oct11 15.10

Check the box to “Enable Connectivity Logging” and then select browse for the location. 

When I checked the log, this is what I found for the domain in question:

12-Oct12 15.13

The 72.21….. IP address is actually my DNS server for this particular Edge Transport server, and as you can see, it’s returning a DNS failure for that domain.  Well, that’s odd, being with the NSLOOKUP we already determined that we could resolve names for that domain on this particular server.

As a test, I changed DNS servers to be ones from a completely different company and……same problem.

We’ll, now we now why the emails are expiring, they cannot figure out how to get to the domain in question, so they sit in the queue until they expire and the server generates an NDR.

So we know its a problem with name resolution, but have no idea why it would be failing.  The next step I took was to use a network analyzer like WireShark to see what was happening.  Here is a sample capture for the domain in question that was giving me problems:

12-Oct13 15.19

Well, well well, here we have a DNS failure of Standard Query AAAA.  So, what’s going on here?  We’ll it seems that the server is performing ONLY an IPv6 DNS lookup, and not doing a IPv4 lookup.  Since the domain doesn’t have an IPv6 record for their domain, the query is failing. 

I reached out to Microsoft and it seems that this is a fairly common issue with Exchange 2007 servers working on Windows Server 2008 machines, as they come installed with IPv4 and IPv6.  Microsoft does not have an official fix for it, but does have three potential solutions for the problem.

  1. Place a regular SMTP server ahead of the Edge Transport server, and have the Edge Server forward all outgoing mail to this server as a smart host. (this is in my opinion the worst solution)
  2. Create a new Send Connector for that particular domain as an address space.  Set all email to forward through this connector as a smart host and add all MX records as potential smart hosts for this connector (this works very well, with the only potential problem being if the problem is spread across a lot of domain’s, there is a lot of work for the administrator)
  3. On the Send Connector, check the “Use the External DNS Lookup on the transport server”

12-Oct11 15.10

Even if you do not configure specific External DNS servers on the Edge or Hub Transport servers, this will cause the server to only perform a standard IPv4 lookup, which will resolve the issue.

Hopefully this article can help you when troubleshooting email delivery issue’s, giving you some of the steps you can take to track down the specific issue your users are having.

The “Require That All Senders are Authenticated” Does Not Work As Expected in Exchange 2007

exchange 2007, hub transport


I recently ran across an issue where one company was setting the “Require that all senders are authenticated” checkbox on a particular mail distribution group in Exchange 2007.

01 Jul. 07 11.26

Most organizations will do this, to ensure that only users of the internal Exchange organization can email this group, effectively stopping external users from emailing it.  This is particularly useful if the group is an extremely broad group such as “ALLUSERS” or something similar.

The problem was that even with this checked, the group was still receiving emails from outside senders.  What gives?  Well, I started doing a little digging, and this is what I found.

The company had followed this article by Scott Landry of the Exchange Team.  The articles discusses two ways to allow application servers to relay through Exchange 2007, applications such as SharePoint. 

If you read Scott’s article, his tone indicates that these applications are really internal applications.  He also lists two method’s for doing so.  The first being to set the receive connector to externally secured, and the second with manually applying permissions using powershell.  The company who was having this issue, had used the first method, eternally secured, but was using it to allow a 3rd party SMTP server that was used for spam filtering on it’s DMZ, to relay into Exchange.  So what’s the problem?  Essentially the method they used, gave TOO much permission to the 3rd party server.  Let’s take a look.

Scott’s article states to create a new receive connector, and set this connector to allow the IP address of the 3rd party server.  So, assuming our third party server has an IP address of, the connector would look like the following:

02 Jul. 07 11.34

Next, the article states to edit the authentication and permissions tab’s, so that “Exchange Servers” are set on the Permission Groups tab:

04 Jul. 07 11.36

  and then “Externally Secured” is selected for authentication:

03 Jul. 07 11.35

After this, the 3rd party server would be allowed to relay.  So you ask, what’s the problem.  Well, by setting the above, most importantly the Exchange Servers on the Permission Groups, you are essentially telling Exchange 2007, that any email that comes in this connector, should be treated the exact same as if it originated from an Exchange 2007 server.  This means that the emails will bypass anti-spam settings, as well as appear as if they were sent from inside the organization.  Scott lays out exactly what permissions are set:

MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS ExchangeExternally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS ExchangeExternally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS ExchangeExternally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Submit}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Now, any email from this connector, will bypass the “Require That All Senders are Authenticated” check box, because according to Exchange 2007, they are authenticated!

So, how do you fix it?  It couldn’t be easier, Scott’s article already tells us how.  He lists Option 2, grant the relay permission to Anonymous Users on the connector.

If we change the permission group, so that only “Anonymous” is checked, and remove “Externally Secured” from the authentication tab:

05 Jul. 07 11.42

06 Jul. 07 11.42

And then run one little powershell command:

Get-ReceiveConnector “3rd Party Relay” | Add-ADPermission –User “NT AuthorityAnonymous Logon” –ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”:

07 Jul. 07 11.45

That’s it.  Now, the third party server can send emails into the organization, but they are treated as outside emails.  This means they will be subject to size limit’s, anti-spam, as well as being rejected if they are sent to a group that has the “Require That All Senders Are Authenticated” setting checked.

Changing SMTP Database Location in Exchange Server 2007

exchange 2007, hub transport

In Exchange 2007, the only two servers that understand the actual SMTP protocol are the Hub Transport and Edge Transport Servers. The Edge Transport are used as messaging hygiene servers located on your company’s DMZ, and Hub Transport servers are used internally to route email between sites, and to local Mailbox servers.

Exchange 2007 no longer uses the Windows Server SMTP service to handle SMTP traffic. As a matter of fact, you have to make sure this service is not installed before you install either the HT or ET roles! Exchange 2007 uses a new SMTP stack, and also uses a new SMTP database system. It now uses a Extensible Storage Engine (ESE, formally JET) database to store and track the SMTP database. For best performance, specifically on a busy Transport server, you want to move the default location of these files. Just like with a standard ESE database, you preferably want to move the DB to one array or disk, and the log files to another array or disk.

To change the location, you need to edit the edgetransport.exe.config file, located in C:Program FilesMicrosoftExchange ServerBin. The location is the same for both roles. This file holds the defaults for many of the various options of the Transport services, but for now we will focus on the SMTP database and logs option.

Find the following keys:

add key=”QueueDatabasePath” value = “C:Program FilesMicrosoftExchange ServerTransportRolesdataQueue”

add key=”QueueDatabaseLoggingPath” value = “C:Program FilesMicrosoftExchange ServerTransportRolesdataQueue”

As you can see the default location for both is C:Program FilesMicrosoftExchange ServerTransportRolesdataQueue. Let’s change this. We want our Database to go to D:SMTP DB and our logs to go to D:SMTP Logs. You should edit the keys so that now they look like this:

add key=”QueueDatabasePath” value = “D:SMTP DB”

add key=”QueueDatabaseLoggingPath” value = “D:SMTP Logs”

Save the file, and restart the Microsoft Exchange Transport Service for the changes to take effect. There will be a longer than normal delay as it moves the files to the new paths. Now check the D:SMTP DB location, you will see the following files:

  1. Mail.que – this is the ESE database
  2. trn.chk – this is the checkpoint file used by the database to determine its position in relations to the transaction log files

In D:SMTP Logs you will find the following:

  1. Tmp.edb – the temporary EDB file
  2. trn.log – the transaction log (always 5 MB)
  3. trnres00001.jrs and trnres00002.jrs – these are reservation files just like Exchange uses to ensure that the Transport service can write its transactions to disk in case the disk fills up. Note these are always 5 MB each
  4. trntmp.log – the temporary transaction log file

This allows us to move our Transport database and logs off of the system file, for better performance, specifically on a busy Transport server.