Turn Exchange Anonymous Relay On or Off with Toggle-ExternalRelayReceiveConnectors.ps1

Thursday, January 7, 2016
I wrote this PowerShell script to make it easy to identify and toggle anonymous relay rights on any of your organization's front-end Receive Connectors.

Most organizations require SMTP relays to internal and external recipients. This allows application servers and appliances, such as copier/scanners, to email messages to those recipients. An internal relay allows these devices to email internal (local) recipients. An external relay allows these emails to also be sent to external recipients outside the organization, such as joe@gmail.com.

It's fairly easy to setup an internal relay in Exchange - just create a new frontend receive connector, specify the IP addresses that can use this connector, and set security to allow Anonymous Users to connect to this receive connector, as shown below.

However, if you try to send an email to any SMTP address outside the organization, the relay connector will reject it with one of these errors (or similar):
550 5.7.1 Unable to relay
550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain
In order to configure the relay connector to allow sending to remote domains, you need to configure an extended right for Anonymous Users similar to this lengthy cmdlet:
Get-ReceiveConnector "Relay" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient
Trying to determine whether this setting has already been configured on a particular receive connector can be even more challenging. That's why I wrote the script Toggle-ExternalRelayReceiveConnectors.ps1.

The script will display a numbered list of all the front end receive connectors that exist in the entire organization. Connectors with the Anonymous/ms-Exch-SMTP-Accept-Any-Recipient right configured are listed in Yellow. All other connectors are listed in White. Simply enter the number of the connector you wish to toggle and press Enter. If it was off, it will turn it on. If it was on, it will turn it off. It's that simple!

Read more ...

How to Remove Mailbox Auto-Mapping in Outlook

Monday, December 28, 2015
Exchange 2010 Service Pack 1 (SP1) and later and Office 365 include a feature that allows Outlook clients to automatically map to any mailbox to which a user has Full Access permissions. If a user is granted Full Access permissions to another user's mailbox or to a shared mailbox, Outlook automatically loads all mailboxes to which the user has full access.

There may be times when you don't want to enable auto-mapping for a mailbox.

TechNet article, Disable Outlook Auto-Mapping with Full Access Mailboxes, explains how to disable auto-mapping behavior for mailboxes as you configure Full Access using PowerShell, but this doesn't help if you configure it from the Exchange Admin Console (EAC). If you or another admin configure Full Access to a mailbox using the EAC, there is no option to disable auto-mapping.

I've seen guidance saying that to remove auto-mapping you must remove Full Access from the mailbox account and re-add it again using the PowerShell method listed in the article above. But I found a better way -- simply run the same PowerShell command against the same mailbox with the -Automapping $false switch.

For example, say Keith Johnson has been granted Full Access to John Smith's mailbox and auto-mapping has been enabled (the default behavior). If you want to remove auto-mapping of John's mailbox in Keith's Outlook, do the following:
  • Open the Exchange Management Shell (EMS) or connect to Exchange Online using the Windows Azure Active Directory Module for Windows PowerShell and run the following cmdlet:
Add-MailboxPermission -Identity "John Smith" -User "Keith Johnson" -AccessRight FullAccess -Automapping $false
This command will remove auto-mapping of the mailbox in Outlook, but will not affect any other Full Access permissions. Outlook will automatically remove the full access mailbox from the list of mailboxes on the next Autodiscover refresh cycle.

Read more ...

Chrome Browser Now Warns About Weak SHA-1 Certificates

Monday, December 14, 2015

The Google Chrome web browser is now warning users if Outlook on the web (OWA) or other websites are using SHA-1 SSL certificates.

These certificates are no longer considered secure and should be replaced ASAP. Please read my article, "Is Your Organization Using SHA-1 SSL Certificates?" on Windows IT Pro for more information and steps you should take.

SHA1 certificates are being sunsetted by January 1, 2017. These certs should be replaced or re-keyed with SHA256 certs to improve security and prevent outages.
Read more ...

2015 Exchange Oscars

Wednesday, November 11, 2015
I'm honored to have be awarded the award for "Best at Knowledge Sharing" earlier this month at the 2015 MVP Global Summit in Redmond, WA.

Netmail and Binary Tree generously sponsored the second Exchange Oscars party at the Tavern Hall in Bellevue, WA. This was a really fun event where the Exchange product group and Exchange MVPs got together for food, drinks and awards.

The Exchange MVPs voted to give awards to the following Exchange product group members:

  • Most Helpful Product Group Member - Brian Day
  • Best Advice Given - Timothy Heeney
  • Best Tool - The Exchange Remote Connectivity Analyzer (ExRCA) - Brad Hughes and Shawn McGrath
  • Best EHLO Blog Post - Ross Smith IV

The Exchange product group also voted to give awards to the following Exchange MVPs:

The hilarious Greg Taylor did a fantastic job as MC of the ceremonies. Lots of fun was had by all!

Read more ...

Don't Delete or Rename the Default MRM Policy

Wednesday, October 28, 2015
I was troubleshooting an issue with an Exchange 2013 customer where their "Default Archive and Retention Policy" was not being automatically applied to archive-enabled mailboxes. Admins could manually apply the policy, but they wanted it applied automatically when the mailbox is enabled for an in-place archive or Exchange Online Archiving.

It turns out that the only retention policy that will be automatically applied is one named "Default MRM Policy". That name is hard-coded into the product, so if you delete it all you need to do is recreate it with that same name to make it the default policy. There is no property for that policy that makes it the default. It's just the name.

Here's some of the back story. Exchange 2007 introduced Managed Folders, which was an early form of retention management, but it was rather clumsy to work with. Exchange 2010 SP1 and later uses message records management (MRM) policies and policy tags. MRM policies are collections of policy tags that tell Exchange server how manage mail data. Some tags apply by default, such as the "Default 2 year move to archive" tag. Others are personal tags that users can chose to apply to one or more mail items, or entire folders, such as "1 Year Delete". Exchange setup creates the "Default MRM Policy" which includes a default set of policy tags.

The Default MRM Policy does not actually apply to any mailboxes by default, unless the the mailbox is given an archive mailbox. At that time, Exchange looks for an MRM policy named, "Default MRM Policy" and automatically applies it to the mailbox. If the Default MRM Policy does not exist, no retention policy is applied.

If you want to apply a different MRM policy you need to manually update the retention policy in the EAC (Mailbox User > Mailbox Features < Retention Policy - see above) or from EMS:
Set-Mailbox <username> -RetentionPolicy "Sales Dept MRM Policy"
For hybrid customers and those using Exchange Online Archiving, you manage MRM policies for on-prem mailboxes on-prem. The policy settings for these mailboxes will sync to Exchange Online with the DirSync process and will be applied to the online archive mailbox.

If a user mailbox and archive mailbox are both in the cloud, you will apply the cloud version of the Default MRM Policy in Office 365. Here, you should configure the Office 365 version of the Default MRM Policy to match the same settings as on-prem.

Read more ...

Enabling Kerberos Authentication in a Mixed Exchange 2013 / 2016 Environment

Tuesday, October 27, 2015
Recently, the Exchange Team published an article, "Exchange 2016 Coexistence with Kerberos Authentication" explaining how to enable Kerberos authentication in a mixed environment. Using Kerberos authentication for Exchange is a best practice and is part of the preferred architecture.

The Kerberos article above gives all the details of how to create the alternate service account (ASA) account and necessary SPNs in Active Directory, as well as how to configure Exchange to use Kerberos.

Once the ASA account is configured on the first Exchange server (2013 or 2016) using the RollAlternateServiceAccountPassword.ps1 script, you run the same script on your other 2013 and 2016 servers to copy the ASA account and password to those servers. We are told to use the 2013 version of the script to deploy across all Exchange servers, even 2016.

However, if you run the Exchange 2013 version of the script from Exchange 2013 targeting an Exchange 2016 server, you will get an error as shown below:

It appears that the Exchange 2013 script invokes a remote PowerShell call to the Exchange 2016 server because we can see a warning that the Get-ClientAccessServer cmdlet is being deprecated. Exchange 2013 would not know this. The script then fails due to a serialization error.

The fix is to copy the 2013 version of the RollAlternateServiceAccountPassword.ps1 script to your Exchange 2016 servers and run it from there. You will see several warnings that the Get-ClientAccessServer cmdlet is being deprecated, but the script will complete successfully.

Another gotcha in the article, Configuring Kerberos authentication for load-balanced Client Access servers is in the step to Enable Kerberos authentication for Outlook clients. This step instructs you to enable Kerberos for the MAPI virtual directory using the following command:
Get-MapiVirtualDirectory -Server CAS-1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm, Negotiate
If you are a hybrid customer or have configured OAuth for any other reason, the command above will remove OAuth as an authentication method for IIS. A better way of doing this would be to use the following two commands:
$server = Get-MapiVirtualDirectory –Server CAS-1
$server | Set-MapiVirtualDirectory -IISAuthenticationMethods ($server.IISAuthenticationMethods += "Negotiate")
This will add Negotiate (Kerberos) to the existing IIS authentication methods if it does not already exist.

Read more ...

Set-AutodiscoverSCP.ps1 script is now on the TechNet Gallery

Thursday, October 8, 2015
How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured when the Front-End Client Access role or components are installed during setup. In most load balanced environments the valid SCP should be something like https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Outlook will prompt users with a security warning because the server FQDN is not on the Exchange certificate and it is not trusted.


Older versions of Outlook (~Outlook 2010 RTM and earlier) used to use the oldest SCP value in the AD site, but newer versions use the newest SCP for foreground and background Autodiscover requests, causing these errors.

I wrote a script, Set-AutodiscoverSCP.ps1 (available in the TechNet Gallery), that automatically updates the SCP for the server your specify to the value you provide as soon as the new SCP for that server is detected in AD. It will continually poll Active Directory until it finds the new SCP value and sets it to the one you specify. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:
Set-AutodiscoverSCP.ps1 [-Server] <String> [-NewSCP] <String> [[-DomainController] <String>] [<CommonParameters>]

Two examples of usage:
PS C:\>Set-AutodiscoverSCP.ps1 -Server exch01 -NewSCP https://autodiscover.contoso.com/autodiscover/autodiscover.xml
Example #1 continually queries the local Active Directory domain until it finds an SCP for server EXCH01 and then sets that SCP to https://autodiscover.contoso.com/autodiscover/autodiscover.xml.

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch01.contoso.local -NewSCP https://autodiscover.contoso.com/autodiscover/autodiscover.xml -DomainController dc03.contoso.local
Example #2 is almost the same as the command in the previous example, except it continually queries DC03.CONTOSO.LOCAL for the SCP record and configures it on that domain controller. This is useful when configuring the SCP for a new Exchange server in a different Active Directory site.

I’ve included error handling for the following conditions:
  1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
  2. The script checks that the server you want to configure is pingable. If the server cannot be pinged, the script will terminate.
  3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script on the TechNet Gallery as needed.

Read more ...