Don't Delete or Rename the Default MRM Policy

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

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

UPDATE: This script has been significantly updated and enhanced. Please read New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

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 ...