Detecting disconnected Exchange mailboxes

Here’s how to detect Active Directory accounts that had an Exchange 2010 SP1 mailbox at one time, but the mailbox has since been disconnected, aka disabled.

Essentially find all accounts where a msExchWhenMailboxCreated value exists and a homeMDB value does not exist.

Get-ADUser -LDAPFilter "(&(msExchWhenMailboxCreated=*)(!homeMDB=*))" -Properties CanonicalName, msExchWhenMailboxCreated | sort CanonicalName | ft CanonicalName, msExchWhenMailboxCreated -AutoSize

– or-

Get-ADUser -Filter {(msExchWhenMailboxCreated -like "*") -and -not (homeMDB -like "*")} -Properties CanonicalName, msExchWhenMailboxCreated | sort CanonicalName | ft CanonicalName, msExchWhenMailboxCreated -AutoSize

This allows us to know before creating a mailbox for a user whether we should first bother to look for a disconnected mailbox that may already exist for the user.


LDAP requests to Active Directory, Mac Lion, and DFS fail when domain name points to web servers

We set up (ports 389 and 636) on our hardware load balancer, forwarding the LDAP requests on to our Active Directory domain controllers.  It works just fine for most of our applications.  We did find that it failed with some applications, however, because our domain controllers were performing an “LDAP referral,” referring the LDAP client initially connecting to “” to instead use “”  Normally, LDAP requests to “” would work correctly in an Active Directory environment thanks to how Active Directory populates DDNS (courtesy of those “same as parent folder” A Records, and Domain Controllers respond in a Round Robin fashion to requests sent to the domain name).  However, in our environment, “” points to our web servers via our load balancer so that users can simply type “” into their web browsers.  The LDAP requests were simply being referred to something that couldn’t answer them.

We received some advice to use the standard ports 3268 and 3269 for clear-text and encrypted LDAP traffic, respectively, instead of 389 and 636 because AD would not do an LDAP referral when accessed via these ports.  This worked.  What might also work is configuring the hardware load-balancer (in our case) to divert port 389 and 636 traffic to the domain controllers while still sending port 80 traffic to our web servers.

Allowing additional ports 445, 139, 137, etc. through to the DCs also allowed us to set up our domain-based DFS namespace successfully.  Attempts at doing this had previously failed with the error “The namespace cannot be queried.  The RPC server is unavailable.”  Allowing these same ports through to the DCs also allows Mac OS X Lion (10.7) clients to connect to these domain-based DFS Namespaces/shares.  Their attempts to connect to the DFS domain-based namespace failed with “There was a problem connecting to the server “”.  The server may not exist or it is unavailable at this time.”

Giving your AD domain name to your web servers in DNS can cause other problems beyond the above.  We’ve so far been able to overcome any issues created by this design, but it would be better not to have this setup in the first place.


Create delivery reports from Message Tracking Log in Exchange 2010

By default, Exchange 2010 keeps 30 days of Message Tracking logs.  These logs are typically used for troubleshooting delivery problems, but you can generate delivery reports from them as well.  The following Powershell command returned all emails sent to the undergraduate population for as far back as we had data (no -Start or -End qualifiers were specified).

Get-ExchangeServer | where {$_.IsHubTransportServer -eq “true”} | Get-MessageTrackingLog -EventId “RECEIVE” | select TimeStamp,Sender,{$_.recipients},MessageSubject | Export-Csv C:\undergraduatestudents.csv

The “{$_.recipients},” in the above command is optional since we’re already searching for all messages sent to  It does tell you who else received a given message, however