Where did my Remote Routing Address go?

Enable-Remotemailbox is a powerful and useful command, sparing admins the pain of creating and moving a local mailbox to Exchange Online. It does, however, seem to have some issues – specifically when creating the required RemoteRoutingAddress.

From what I have seen, On-Premises Exchange doesn’t treat the initial remote routing address as a distinct email address and it essentially disappears. It’s a bit quirky as Enable-RemoteMailbox doesn’t consume the EmailAddresses switch.

To make it work, try two separate commands when creating a remote mailbox. Note that the second one may fail if the DC you are connecting to isn’t aware of the remote mailbox object yet. You can get around this by using the same DC with the -DomainController switch or just waiting a bit and trying the second command again.

Enable-RemoteMailbox -identity <alias> -PrimarySmtpAddress user@contoso.com -RemoteRoutingAddress user@contoso.com  -Alias alias -shared -DomainController <FQDN of DC>

You will notice I am setting the RemoteRoutingAddress to the primary SMTP address in the first command. I do that because you have to set it to something. I plan on setting that in the next step to the actual remote routing address.

I also like update the alias here as well to ensure it matches to the existing SamAccountName in Active Directory, otherwise you may find it set to the “User Logon Name”. Of course, you can set this to anything you want.

Both the -shared and -DomainController switches are optional and available in the latest supported Cumulative Updates for Exchange 2013 and above.

Once enabled, add the additional email address with the correct RemoteRoutingAddress.

Set-RemoteMailbox -EmailAddresses @{add=”user@contoso.mail.onmicrosoft.com”} -RemoteRoutingAddress user@contoso.mail.onmicrosoft.com -identity <alias> -DomainController <FQDN of DC>

The RemoteRoutingAddress can be anything unique. It’s typically “user@<tenant>.mail.onmicrosoft.com” and should have an existing On-Premises send connector to ensure messages are routed to the Exchange Online mailbox.

The remote mailbox now has the correct email and remote routing address set and, more importantly, they should stick! I have not tested this against Exchange 2019, but I would assume the issue is still there.

Happy Hybriding.

Go Commando when Scripting. Checking out the new Powershell Secrets Module.

 

Everyone loves a good secret and anything to make it easier to store that secret and keep it from prying eyes is worth looking at. With that in mind, I was immediately interested when I read about the release of the new PowerShell Secrets Management Module.

Note that the current module uses the built-in Credentials Manager, which apparently can be exploited. Nonetheless, I have found it useful and easy to use and there is the promise to use extensions, including Azure and other “vaults” in the future.

So, how do you get this to work?

First install the module from https://www.powershellgallery.com/packages/Microsoft.PowerShell.SecretsManagement/0.2.0-alpha1

Install-Module -Name Microsoft.PowerShell.SecretsManagement -AllowPrerelease

If you find it’s not installing or loading correctly, be sure to update the local PowerShellGet  module. I found that I also needed to install the latest .Net version. After that, things worked as expected.

Now add the password/secret to the Credentials Manager on the local machine via the new module. Remember you are adding this in the context of the current user, so only the logged in user will have access to it.

Add-Secret -Name Test -Secret Secret

In the example above the secret is….well, Secret and the name is Test. Clever, right?

 

You can view it a number of ways:

Get-Secret -Name Test
System.Security.SecureString

Get-Secret -Name Test -AsPlainText
Secret

Get-SecretsVault

Name ModuleName ImplementingType
—- ———- —————-
BuiltInLocalVault

From the Credentials Manager on that machine, you can see it as well:

Let’s assume you have a script that needs a name and password to authenticate to the local domain. You could pass that new secret easily in this really basic example. (Again, running in the context of the user account on the local machine where you created the secret)

$User = “domain\User1”

$Pwd = (Get-Secret Test)

$UserCredential = New-Object System.Management.Automation.PSCredential ($User, $Pwd)

Get-ADUser -Identity <user> -Credential $UserCredential

Pretty nifty, right? All I had to do was grab the password on the fly from the vault using Get-Secret.

Anyway, that’s it. Not much to get it to work, but lots of potential. I am looking forward to using this module as it matures.

 

Renewing that pesky “Microsoft Exchange” certificate

 

You know the one I am taking about. The self-signed certificate with a friendly name of “Microsoft Exchange” that each server issues by itself to itself. They are valid for 5 years , then suddenly, they are not. When on-premises was king, you rarely saw any questions about these. They just worked – and as companies upgraded, new ones were created on the new version servers, mailboxes were moved and the old certificates disappeared as the servers were retired.

Today, as more migrate to Exchange Online, these old 2010/2013 servers seem to be kept around longer during the migration,  frozen in time and are now bumping into that 5 year certificate lifetime.

So why renew it? It doesn’t appear to be doing anything. Well Sir or Madam, that is the certificate bound to the “Exchange Back End”  IIS site and essentially secures all the internal communications. 

undefined

If it expires, you could start experiencing the following side effects:

Dizziness

Dry Mouth

Exchange Powershell errors

Inability to open EAC

Errors in the event logs such as :

event log errors

See that :444? That’s the backed port number 

 

To fix: 

First, simply renew the certificate. You can do this in Powershell or EAC by highlighting the “Microsoft Exchange” certificate and clicking Renew.

Second, you’ll want the server itself to trust this new self-signed certificate. Nicely enough, the original Exchange setup program does this for you. When you renew the self-signed certificate, not so much. Once that new certificate is created, open MMC and add the Certificates snap-in on that server. From there, choose the “Computer Account” and then “Local Computer”. 

Copy the new certificate from Personal/Certificates to Trusted Root Certificate Authorities/Certificates. If you access the properties on the new certificate and go to the “Certification Path” tab, it should show as OK.

Third, add the new certificate to the Back-end Binding and run IISRESET.

From the article I first linked above. Do the following:

 

  • Start IIS Manager on the Mailbox Server.
  • Expand Site, highlight Exchange Back End, and select Bindings from the Actions pane in the right side column.
  • Select Type https on Port 444.
  • Click Edit and select the Microsoft Exchange certificate.
  • From an administrator command prompt, run IISReset. ( Do this off-hours if this a standalone Exchange Server. If you are using a DAG, then move all the databases to other servers and have at it)

 

You’ll go from this:

PickCertBindings

To this:

BackEndUpdated

You are done for another 5 years. 

 

 

 

 

 

Authenticating trusted messages with Exchange and Office 365

One of the rather interesting side effects of moving your mailbox to Exchange Online is the change in behavior of the old trusty Safe Sender list. If if your mail client trusts only messages sent from a safe sender, all other messages will end up in junk mail. This is change from on-premises – where only messages marked as junk will be marked as SPAM. All others – including the trusted senders- will arrive in the inbox.

For the most part, this is not a big deal, simply inform your end-users of this change once their mailbox has been migrated and let them decide how to handle it; Keep using Safe Senders and whitelist any legitimate senders, or disable it and use the standard junk mail settings in the client.

There are specific scenarios where this could be problematic however. Many organizations have developed internal processes that send reports, alerts and updates anonymously from on-premises systems to their workforce. It’s very common to have dozens to hundreds of these processes, enabled over many years – each sending as an arbitrary SMTP address – essentially spoofing as an authoritative domain.  And it’s not as easy as it sounds to ask end-users – especially executives (who rely heavily on the Safe Sender option) to whitelist numerous addresses when it wasn’t required in the past.

Ah, the solution is easy. Just add your authoritative domain to Safe Senders. That will cover you for everything. Not so fast!

One, you can’t add an authoritative domain to the trusted list.

Two, Exchange Online doesn’t honor white-listed domains anyway.

One possible solution that is the least disruptive to the end-user: Trust those internal processes at the Exchange server level.

Example: Assume you are in hybrid mode and still have an Exchange Server on-prem. Create a receive connector on the Exchange Server. Scope the remote IP addresses to the internal SMTP servers that send these messages to end-users, then check the box ( or use powershell) to set the receive connector you just created as “Externally Secure”.

The receive connector auth and permissions will now look like this:

AuthMechanism           : Tls, ExternalAuthoritative
PermissionGroups        : AnonymousUsers, ExchangeServers

What you see in the headers of a received message:

X-MS-Exchange-Organization-AuthAs: Internal

X-MS-Exchange-Organization-AuthMechanism: 10

In the end, all messages that pass through this connector ( and eventually through the hybrid connector to Office 365) will be considered authenticated and will not be sent to junk mail – even if the sender is not in the Safe Sender List. Boom!

P.S. This is only an example. Do not enable this option if you do not trust or have control of the sending servers.

Using the new V2 ExO Powershell Module in a script (and the old way if you want!)

As you know, Microsoft announced the new Exchange Online REST-based Powershell commands at Ignite: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Exchange-Admin-Improvements-Announced-at-Microsoft-Ignite-2019/bc-p/985019#M27379

Loading the modules from a script is similar to loading the V1 version, passing the credential with $UserCredential in this example.

Import-Module $(Get-ChildItem -Path $("C:\Jobs\ExchangeOnlineManagement\") -Filter Microsoft.Exchange.Management.RestApiClient.dll -Recurse ).FullName
Import-Module $(Get-ChildItem -Path $("C:\Jobs\ExchangeOnlineManagement\") -Filter Microsoft.Exchange.Management.ExoPowershellGalleryModule.dll -Recurse ).FullName
$EXOSession = New-ExoPSSession -Credential $UserCredential
Import-PSSession $EXOSession

With the new version, you load two dlls: The API dll, followed the GalleryModule in that order.

Note that the path is an arbitrary one in this example. I simply copied over the module to that directory. By default, the V2 version will be installed into the \Users\\Documents\WindowsPowerShell\Modules\ExchangeOnlineManagement directory and you can reference that path instead.

Another thing to mention. From what I have seen, if you load the the trusty Azure MSOnline (Connect-MsolService) module in a scheduled task script after you load the V2 Exo module, it will fail, so load it before the V2 stuff. Maybe that will get fixed in a future version.

As always, disable any MFA for the service account you are using for this process. Ths new module leverages Modern Auth, just not MFA- same as the current V1 ExO friendly module.

If you are inclined to use the V1 version still, you can always use these tried and true methods:

$MFAExchangeModule = ((Get-ChildItem -Path $($env:LOCALAPPDATA+”\Apps\2.0\”) -Filter CreateExoPSSession.ps1 -Recurse ).FullName | Select-Object -Last 1) . “$MFAExchangeModule” Connect-EXOPSSession -Credential $Credential

or

Import-Module $((Get-ChildItem -Path $($env:LOCALAPPDATA+”\Apps\2.0\”) -Filter http://Microsoft.Exchange.Management.ExoPowershellModule.dll -Recurse ).FullName|?{$_ -notmatch “_none_”}|select -First 1) $EXOSession = New-ExoPSSession -Credential $Credential Import-PSSession $EXOSession

Consider using Conditional Access for these special accounts and only allow access from trusted IPs

Selectors: The Magic Sauce of DKIM

One question I see a lot is “How can I let 3rd party vendors send as our organization using DKIM?” It’s a lot easier than you think.

The trick is in the selector. Per RFC 6376:  To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using “selectors”.  

Implementing this is pretty straight-forward, so let’s get started.

Suppose you have your existing DKIM infrastructure handled by Office 365/ EOP.

When sending a message through Office 365/EOP, the header of the message is stamped with the required DKIM fields.

Check out the sample header in the received message below. Note the s=selector1. This tells the receiving server to check : selector1._domainkey.contoso.com.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=contoso.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qwJgpoXgR3MRDrSVO91kT+tYSpE//LjikNGicqlKjU0=; b=FnK8HjJFfEKHMq5EoIGJVzty4w+v7uE0UmQVFrVYr348e4tqfE66U/pZanlNfS7guhj2T5g5sqva7w1Wc1/+NOlC6CEBMrQiuFVDo0Akk8narhX9r9xs99Yniv…

In your organization’s external DNS, you have a CNAME record of that selector:

selector1._domainkey.contoso.com    canonical name = selector1-contoso-com._domainkey.contoso.onmicrosoft.com

Following the DNS pointer…

In the Office 365 DNS is something like this text record with the public signing key:

selector1-contoso-com._domainkey.contoso.onmicrosoft.com       text =

        “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBFDKKLKLKGNADCBiQKBgQDLODjPzMtm1EVPXU3OgPWgW+ABPqDtoHLnzmyTXdl+abC5M13ZovMLIrTbEJTT…

The receiving server can now run it’s calculations against the message knowing the public signing key.

So you can see where we are going with this.

If you want a 3rd party vendor authorized to send as your company and apply a DKIM key to each message, you have a few options:

Create a unique selector CNAME – different from the one you use for messages coming from your organization – in external DNS that points to the 3rd party vendor’s DNS which contains the public DKIM signing key. This is similar to what Office 365 tenants do.

or

Use a unique selector and create the DNS text record that has the public DKIM signing key provided by the vendor. Remember: They are generating the messages, so the 3rd party vendor has the private key, you do not!

Each method will work and it’s really up to you. Note that if you decide to create the text record in your DNS with the public key signing key, it will break DKIM for those messages if the 3rd party vendor decides to change the private signing key that they hold.

I think it goes without saying that the one thing you don’t want to do is provide “your” private signing key to a 3rd party vendor and have them sign messages using your “regular” selector – the one you use for messages that actually do come from your domain. At least I wouldn’t recommend that.

Once this is all setup, then it’s up to the 3rd party to set the selector correctly in the message header. So, if EOP is stamping “selector1” on all outbound messages, the 3rd party vendor can use anything allowed by RFC except selector1.

As an example, headers received from the vendor, sending as you, may stamp it with:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=contoso.com; s=contosoBULK

Receiving servers will now check the text record: contosoBULK._domainkey.contoso.com and depending on how you set it up, obtain the public signing key or get redirected by CNAME to another DNS.

This also works great for subdomains – i.e. have the 3rd party send as mail.contoso.com and setup the DKIM records for that specific SMTP domain.

There is no real limit to the number of selectors one domain can support, just ensure they are unique to each sender and are configured properly so receiving systems can correctly access the DKIM public signing key.

With the advent of so many cloud services, I suspect just about every organization has at least one 3rd party sending as their SMTP domain, so get your DKIM ( and SPF records!) right. I hope this helps understand that process a little bit better.

About Me

Hello Friends.  Andy David here. I’ll be posting things that I find interesting and maybe you will too. Expect stuff about Exchange, Office 365, AD, SharePoint and who knows what. I don’t plan to write extensive “How-To” articles. There are plenty of those.  Instead, look for the USA Today/SkyMall version of things. If you have a short attention span, this is the place for you!

I have been using Exchange since 4.0 debuted some 20 years ago. I built my first NT AD Domain then as well and named it “Domain”, not knowing any better. Doh.

I have been an Exchange MVP since 2002.  I also had the honor of naming “You had me at EHLO” for the Exchange Product Group Blog way back in the early 2000s.

I attempt to answer questions in a number of places:

https://social.technet.microsoft.com/profile/andy%20david/

https://www.reddit.com/user/adavid1608

https://techcommunity.microsoft.com/t5/user/viewprofilepage/user-id/86

https://docs.microsoft.com/en-us/users/AndyDavidMVP/

and can be found on Twitter: