Cleaning up unused domains from Exchange users

One of the challenges I had recently when migrating users from Exchange 2007 to Exchange Online (who had been migrated over from Lotus Notes before that) was that they had loads (and loads!) of proxyAddress entries. Every domain the company we integrated had ever owned was stuck onto those mailboxes - but we'd decided to only use a handful in Exchange Online.

When migrating the mailbox from on premise to Exchange Online, the migration failed with the message that the domains on the mailbox were not part of the list of Accepted Domains configured for Exchange Online. Obvously, we could do 2 things: Add all the domains to the Accepted Domains - or clean up the mailboxes. While it did seem like a daunting task, I opted for the latter.


In retrospect, it didn't turn out to be much work: I just wrote a Powershell script that does it for me. If you want to use it, just copy/paste the script below to a text file on your Exchange server, adjust the domain names and the mailbox database in which you want to search for mailboxes, save it with a PS1 extension and run it (NB: it will NOT run on Exchange 2013 without some tweaking as I needed it for Exchange 2007)

$MSOnline = "domain1,com,,"

Get-MailboxDatabase -Identity "<YOUR MAILBOX DB>" | Get-Mailbox | foreach {

#write-output $_.EmailAddresses.count
for ($i=0;$i -lt $_.EmailAddresses.Count; $i++)
$address = $_.EmailAddresses[$i]
$domain = $address.AddressString.toString().Split("@")[1]

if (!$MSOnline.Contains($domain) -AND $address.PrefixString -eq "SMTP" ) {
write-host "removing $address"
$i = $i – 1
Set-Mailbox -Instance $_
#write-output $_.EmailAddresses.count
#Write-output "remaining: " $_.EmailAddresses


Anonymous Relay in Exchange 2007

Sending mails from applications servers that don't support SMTP authentication in Exchange 2007 is easy.

Just build a custom receive connector, add your servers' ip addresses, in the "Network" tab, turn everything off in "Authentication" and allow "Anonymous users" in the "Permission Groups" tab.

That's it. .... most of the time.... 

Works great - except when it doesn't work. Like when your application also wants to mail to the rest of the world (And not just your own organization). That's called relaying - and is really, really bad if it happen without your knowledge. If you want to enable it for this connector you'll need to switch over to Powershell in the Exchange Management Shell and grant those pesky anonymous users the right to actually send to any recipient.


To do so, use the following script:

Get-ReceiveConnector "<your receive connector>" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"


PrepareAD complains about the Default Global Address List

Recently I was doing an Exchange 2003 to Exchange 2010 transition. When running /PrepareAD, things didn't go as expected: Exchange threw me a curve ball with the following output:

Setup is going to prepare the organization for Exchange 2010 by using 'Setup /PrepareAD'. 
No Exchange 2007 server roles have been detected in this topology. After this operation,
you will not be able to install any Exchange 2003 or Exchange 2007 servers.

Configuring Microsoft Exchange Server

    Organization Preparation                                  FAILED
     The following error was generated when "$error.Clear();
        install-GlobalAddressLists -DomainController $RoleDomainController" was run:
"Active Directory operation failed on The object
'CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,
CN=Our company,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=lan'
already exists.".

The Exchange Server setup operation didn't complete. More details can be found
in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.

Exchange Server setup encountered an error.

That didn't look to good. Google-ing didn't do too much for me, either - I found a lot of info about incorrectly set ACLs on address lists - but that wasn't the case here.

I used ADSIEdit.msc on the Domain Controller, went to the Configuration container and then down the path to where the Default Address List entry was hidden. Opening its properties was no success either, giving me the strong impression that there's something seriously corrupt here.

Workaround for me: I simply renamed the CN. So now it reads "CN=Invalid Exchange 2003 Default Address List" - and from there on things went okay again.