Query Mailbox by LegacyExchangeDN

In a large organization with mailbox quotas, you will see an ongoing number of events indicating that users are at the limit of their quotas. In the event log you will see:

Event Source: MSExchangeIS
Event ID: 8528
The mailbox for /o=ExchangeOrg/ou=AdministrativeGroup/cn=Recipients/cn=UserIdentifier has exceeded the maximum mailbox size. This mailbox cannot send or receive messages. Incoming messages to this mailbox are returned to sender.  The mailbox owner should be notified about the condition of the mailbox as soon as possible.

The overall identifier for the mailbox is the LegacyExchangeDN attribute for the user mailbox. Most of the time, you can look at this value and quickly figure out which user is having the issue. If it's a current user, you can wait or contact them. In a large environment, you may not personally know the users, and you can investigate whether this is a disabled account that needs to be removed.

Today I was looking at one of these events and saw that the final UserIdentifier portion of the LegacyExchangeDN attribute was a long GUID number. To find the actual user account I needed to query the mailbox with a filter for LegacyExchangeDN.

Get-Mailbox -Filter {LegacyExchangeDN -eq " /o=ExchangeOrg/ou=AdministrativeGroup/cn=Recipients/cn=UserIdentifier"}

Please note that using the -Filter parameter is much more efficient that doing Get-Mailbox and piping it to Where-Object. Using the -Filter parameter is almost instant whereas piping Get-Mailbox to Where-Object can take several minutes.

StartDagServerMaintenance.ps1 Error with 2 Database Copies

When you have a DAG with only two nodes, the StartDagServerMaintenance.ps1 script is smart enough to recognize that you can't have 2 additional copies of the database. However, if you have more than 2 DAG members, then the script complains that it can't run because the local database copy is required for redundancy.

I ran into this at a client where we created a database in the DR site for running test cmdlets with SCOM. There are two copies of the database in the DR site. Other databases have two copies in the main site and one copy in the DR site.

You can override the default behaviour with the switch OverrideMinimumTwoCopies.

Example:

StartDagServerMaintenance.ps1 -Server DAGnode1 -OverrideMinimumTwoCopies

Getting Status Totals in PowerShell

I was doing an Exchange migration on the weekend and had a large number of move requests. Being the slightly OCD computer person as most of us are, I wanted to see how things were progressing occasionally. However, I didn't want to be dumping stuff into spreadsheets and be counting items.

After few false starts, I ran across the Group-Object cmdlet. For me, this cmdlet is in the same category as Measure-Object. I've never had a need in the past. Now I'm happy to have it.

My solution:

Get-MoveRequest | Group-Object -Property Status

The results looked like this:

Synchronizing Remote IP Ranges Across Recieve Connectors

Exchange 2010 and later do a nice job of providing high availability with database availability groups (DAGs) and load balancing. However, one configuration detail doesn't automatically synchronize between multiple Exchange servers, and that is receive connectors.

If you create receive connectors for relaying output from printers or scanners then the connector you create is unique on each server. That's fine if you are pointing the devices at individual Exchange servers but to have high availability, you need multiple load balanced servers with the same configuration. To do this, you need to create the same receive connectors on each server.

During intial setup creating 2 or 4 receive connectors with the same settings for authentication and such isn't too big a deal. The item that's a pain is the remote IP ranges that are allowed to use the receive connector. Many organizations have a large list of individual IP addresses that are allowed to use the receive connector.

If there is a list of 50 individual IP addresses, it's a long process to enter once, let alone multiple times. Not to mention, there is the risk of administrators adding or removing IP addresses to the list on one server, but not others, or typos.

Here is a quick and easy way to synchronize the remote IP ranges from a receive connector on one server to another.

$Source=Get-RecieveConnector Server\ConnectorName
$Destination=Get-ReceiveConnector Server\ConnectorName
Set-ReceiveConnector $Destination -RemoteIPRanges $Source.RemoteIPRanges

In the example above:

• $Source is the connector you are copying the remote IP ranges from
• $Destination is the connector your are copying the remote IP ranges to

It is not necessary to use a variable for the destination receive connector. I did that to clarify what is happening in the Set-ReceiveConnector command. You could put the identity of the destination receive connector directly in the Set-ReceiveConnector command.

If you need to do this on a regular basis, you can put the receive connector into an array and use a foreach loop to set them all in a script like this:

$Source=Get-RecieveConnector Server\ConnectorName
$Destination=Get-ReceiveConnector | Where { $_.name -like "Relay*"}

ForEach ($d in $Destination) {
    Set-ReceiveConnector $d -RemoteIPRanges $Source.RemoteIPRanges
}

Can't Create Domain Certificate with Custom Template in IIS Manager

I was teaching an informal class this week on certificates and Active Directory Certificate Services (AD CS). When a class is informal, you don't necessarily create detailed lab activities ahead of time. It's more like you have a general flow you want to do. Consequently, something just don't work as you expect.

We used IIS Manager to create a domain certificate from the internal CA that we has setup. That part worked fine based on the Web Server template that exists automatically after installing AD CS.

After that I thought this would be a great way to demonstrate superceding a template. Turns out I was wrong. The wizard in IIS Manager will only request certificates based on the Web Server template. If you take that one away, the wizard for creating a domain certificate doesn't work. We were using Windows Server 2012 R2, but this behavior is also consistent in Windows 2008/2008 R2 (IIS 7/7.5)

The work around is to use the Certificates snap-in to create the certificate from AD CS.

Reference:

• http://blogs.technet.com/b/instan/archive/2011/04/06/why-can-t-i-see-any-certificate-templates-when-creating-a-certificate-request-within-the-iis-7-x-mmc.aspx

iOS 9 Increases Security Requirements

Apple recently released iOS 9 and this is important for Exchange administrators. Many implementations of Exchange 2010 are implemented on Windows Server 2008 R2 which does not meet the security requirements for iOS 9 to connect.

Apps on iOS 9 or later and OS X 10.11 or later use App Transport Security. App Transport Security defines minimum security standards that must be met for a network connection to be successful. The default behavior requires:

• TLS version 1.2
• Perfect forward secrecy
• SHA256 or better for certificate signature
• 2048 bit or better RSA key (or 256 bit or better ECC key)

If your Exchange server does not meet the App Transport Security requirements then the connection is dropped by iOS or OS X. This applies to web services. So, it will affect OWA, ActiveSync, and EWS (Outlook for Mac).

We are just starting to see iOS 9 installed by clients and are in the process of ensuring that servers meet the requirements.

NOTE: As of right now (Sept 20/15), iOS 9 does not appear to be enforcing the above requirements for internal applications but does for third party applications. We are continuing to update all Exchange servers to meet these requirements as they are best practices for security and because they could affect OS X 10.11 when released.

TLS 1.2

TLS 1.2 has been around since 2008 but is not enabled by default on Windows Server 2008 R2. Windows Server 2012 and later have TLS 1.2 enabled by default. Windows Server 2008 does not include TLS 1.1 or TLS 1.2.

To enable TLS 1.2 on Windows Server 2008 R2, you need to create a registry key and reboot the server:

1. Open Regedit.
2. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
3. In Protocols, create a new Key named TLS 1.2.
4. In TLS 1.2, create a new Key named Server.
5. In Server, create a new DWORD (32-bit) Value:
• Name: DisabledByDefault
• Value: 0
6. In Server, create a new DWORD (32-bit) Value:
• Name: Enabled
• Value: 1
7. Reboot the server.

 

Perfect Forward Secrecy

Perfect Forward Secrecy ensures that each connections uses a difference encryption key. Windows Server 2008 R2 support the use Perfect Forward Secrecy, but again, it's not enabled by default. There are a limited number of ciphers that use Perfect Forward Secrecy. It is a matter of enabling these ciphers and also changing the order of preference so that they are preferred.

I've done quite a bit of searching and there is no good guide for manually enabling Perfect Forward Secrecy. However, there are several scripts you can download and even a graphical tool.

My personal favorite is the graphical tool IIS Crypto from Nartac Software because it provides an easy way to see exactly which protocols and ciphers are being modified. Press the Best Practices button to view the optimal security settings and then Apply and reboot the server. This will enable TLS 1.2, disable SSL 2 and SSL 3 and enable Perfect Forward Secrecy in one step.

Script to enable Perfect Forward Secrecy and more:

•  https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

SHA256

SHA is the algorithm used to sign the digital certificates installed on your Exchange server. Many older certificates use SHA1 which is relatively insecure. You can update your certificate by regenerating the certificate. Most provides allow you to regenerate the keys at no cost. During this process you can select to use SHA256 and then import in Exchange Server.

2048 Bit Key

Several years ago, certification authorities started requiring a minimum key length of 2048 bits. So, it is unlikely that this is an issue for your certificate. However, if you had a certificate with a long lifetime, you can regenerate it with a 2048 bit key to bring it up to requirements.

Testing Your Configuration

The simplest way to verify the SSL/TLS configuration on your server is to use the SSL test from Qualys SSL Labs. This web site connects to your server and runs it through a variety of tests before providing a report on the SSL configuration. It's the fastest way to find out whether specific versions of SSL/TLS and ciphers are enabled or disabled.

Windows Server 2012 and Windows Server 2012 R2

This blog post has focused on Windows Server 2008 R2 because there is a lot of it out there running Exchange 2010. However, Windows Server 2012 and Windows Server 2012 R2 are used for many implementations of Exchange 2013.

Windows Server 2012 and Windows Server 2012 R2 support TLS 1.2 by default. If you have installed update KB2919355 released in April 2014, then Windows Server 2012 R2 uses Perfect Forward Secrecy. For Windows Server 2012, you need to configure the cipher protocols to enable Perfect Forward Secrecy just as was required in Windows Server 2008 R2. Again, using a script or IIS Crypto is the preferred method of enabling and reordering the necessary ciphers.

References

Links for reference:

• App Transport Security Technote: https://developer.apple.com/library/prerelease/mac/technotes/App-Transport-Security-Technote/index.html
• TLS versions: https://en.wikipedia.org/wiki/Transport_Layer_Security
• TLS/SSL Settings Reference: https://technet.microsoft.com/en-us/library/dn786418.aspx
• Qualys SSL Labs test: https://www.ssllabs.com/ssltest/index.html
• How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll: https://support.microsoft.com/en-us/kb/245030 
• Nartac IIS Crypto download: https://www.nartac.com/Products/IISCrypto/Download
• Update adds new TLS cipher suites and changes cipher suite priorities in Windows 8.1 and Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/2929781

Cannot achieve Exchange Server authentication

In a single server Exchange environment, you can get away with some misconfiguration because the Exchange servers don't need to communicate with each other. Recently I was working with a larger client that made a common configuration error on receive connectors. This client had the following configuration:

• multi-role DAG members in datacenter #1
• multi-role DAG members in datacenter #2
• all mailbox databases are replicated between the two datacenters
• 1 public folder database in each datacenter

Message delivery was working properly between servers in datacenter #1. Only passive database copies were in datacenter #2. However, there were issues with public folder replication. Some public folders were not replicating properly from datacenter #1 to datacenter #2.

Looking at the queues for servers in datacenter #2, you could see that the queue between AD sites had a large number of messages. The following error was present on the queue:

451 4.4.0 Primary target IP address responded with: "451 5.7.3 Cannot achieve Exchange Server authentication"

The servers had been configured with a receive connector for relaying with only anonymous authentication. This had been done to allow various applications to relay messages through as necessary. On the Network tab of the relay connector, Receive mail from remote servers that have the IP addresses was configured with a range of IP addresses that included the Exchange servers.

When an Exchange server receives an inbound request for SMTP, it uses the source IP address of the request to select the appropriate receive connector. The preferred receive connector has the most specific IP address range that includes the source IP address. A single IP address is preferred over a range and small range is preferred over a larger range. If connectivity fails due to authentication errors no other connectors are used and communication fails.

Normally when Exchange servers send SMTP messages between themselves, they use the Default receive connector which is configured for Exchange Server authentication. The Default receive connector has a source IP range of 0.0.0.0-255.255.255.255. When the server is first installed, this ensures that communication works properly. However, any receive connector you create is more specific than this and will be preferred over the Default receive connector.

That is what happened in this case. The relay connector that included the IP addresses of the Exchange servers was preferred over the Default receive connector that had the proper authentication settings. This is a common error.

The fix was to add the specific IP addresses of the Exchange servers to the Default receive connector on each server. This made the Default receive connector more specific than the relay connector.Once this was done the error disappeared and queues delivered messages properly.

One question is, why was only public folder replication affected and not mail flow within the AD site?

Within an AD site, the Hub Transport role on a server communicates directly with the Mailbox role on another server with the mailbox database by using RPC. So, the Default receive connector is not required for message delivery within the AD site.

In this case, the only inter-site SMTP messages were the public folder replication messages. No databases were mounted in Datacenter #2 . So, no email messages were sent there via SMTP. Database replication does not use SMTP.

The mail flow configuration in this scenario should be relevant for Exchange 2007, Exchange 2010, and Exchange 2013. However, the error message may vary slightly.