Set primary SMTP as targetAddress with PowerShell

This will show you how to step forward if you would like to set the targetAddress for all users within an Active Directory OU, to the primary SMTP address from the proxyAddresses attribute.

STEP 1: Update the script with the right OU, something like:

Get-ADUser -SearchBase "OU=Europe,CN=Users,DC=corp,DC=contoso,DC=com" 

STEP 2: Start PowerShell as an Admin on the local network with access to the local Active Directory. Import the ActiveDirectory module and run the script.

Import-Module ActiveDirectory

(You might have to update execution policy!)

//xostmoen – Alexander Østmoen

# xostmoen

# This script get all users in AD from a specified OU and all sub-OU's
# It also fetches the ProxyAddresses from the object

Get-ADUser -SearchBase "OU" -Filter * -Properties ProxyAddresses | foreach {

$proxyAddress = $_ | Select -ExpandProperty ProxyAddresses | ? {$_ -clike "SMTP:*"}

#For each user, we find the primary SMTP address, and set this to be the new targetAddress

Set-ADuser $_ -Add @{targetAddress="$proxyAddress"}


450 4.7.320 Certificate validation failed

I wanted to share something peculiar that happened while working with a customer the other day.
We had finished a hybrid setup with Exchange 2013, and most of the users where still on-premise. The minute we switched the mail flow to go through Exchange Online Protection instead of their old setup, we started having some challenges. Even though we didn’t experience any challenges when we did the testing of the mail flow on beforehand.

Now some of the messages took forever to go through Office 365 and Exchange Online Protection, but some went through straight away.

When tracing the messages, we could see this error message on the deferred messages:

Reason: [{LED=450 4.7.320 Certificate validation failed [Message=SubjectMismatch] [] [LastAttemptedIP=] []};{MSG=SubjectMismatch};{};{IP=};{LRT=11/1/2017 12:12:45 PM}]. OutboundProxyTargetIP: OutboundProxyTargetHostName:

The strange thing in this case, was that some messages seemed to be OK, but the other half seemed to have a problem with the certificate.

After some time it came to me that the receiver connector on the on-premises Exchange server contained some settings for the certificate for “”, and this is something that is automatically configured by the Hybrid Configuration Wizard:

Set-ReceiveConnector -Identity 'SERVERNAME\Default Frontend SERVERNAME' -TLSCertificateName [CERTNAME] -TLSDomainCapabilities [CERTDOMAINCAP]

Then I came to the discovery; only one of the two Exchange servers with a receiver connector had been configured with the TLS Certificate settings.

By using PowerShell:

Get-ReceiveConnector -Identity 'SERVERNAME\Default Frontend SERVERNAME' |fl

I could see that the attributes TlsCertificationName and TlsDomainCapabilities where set for one of the servers, but not the other.

“Easy!” – you say,  “then we just need to run it for the other one as well? ”
Of course, the only thing to remember is to get the correct Certificate Name, and then run the Set-Receiveconnector cmdlet.

First i had to find the Thumbprint of the Certificate by running:


Take note of the Thumbprint for the right certificate, then go on…

$certificate = Get-ExchangeCertificate -Thumbprint 0011223344556677889900112233445566778899
$tlscertificatename = "<i>$<$certificate.Issuer><s>$<$certificate.Subject>"
Set-ReceiveConnector -Identity 'SERVERNAME\Default Frontend SERVERNAME' -TLSCertificateName $tlscertificatename -TLSDomainCapabilities

Now after running this, and checking that everything is right with the Get-ReceiveConnector cmdlet, things started working as it should again.

//xostmoen – Alexander Østmoen