Category: Exchange

I ran into the following error when uninstalling an Exchange 2010 server:

This computer is responsible for expanding the membership of 15 distribution groups. These must be reassigned to another server before setup can continue.

To find which distribution groups have an Expansion Server set you can run the following from the Exchange Management Shell:

Then run the following to null out the value for the distribution groups:

I recently completed a migration from Exchange 2013 to Exchange 2016 and after the Exchange 2013 server was uninstalled that’s when the issues with OAB started. I confirmed that all the mailbox databases were set with the Offline Address Book.

I confirmed that the OAB Virtual Directory was set with the correct URL.

I ran the Outlook Test Email AutoConfiguration and noticed that in the output it didn’t have a line for OAB.

It turns out that the Offline Address Book needed to be set for Global Web Distribution.

Now when I check the OAB both the Web Distribution settings have been enabled.

You will need to perform an IISreset for the settings to be applied.

Fixing a corrupt content index on an Exchange database with only one copy can be done in the following method:

If you run the following command you can see the content index state and error message.

Next you will need to stop the following services:

Now you will need to delete the content index folder which is a GUID in the same location as the database edb file. It has three sub folders that all need to be deleted.

NOTE: If you try and delete the files without stopping the search services you will get an error that the file is in use.

With the files successfully deleted you can start the services:

Now wait a few minutes for the content index folder to be re-created.

To verify this worked you can run the same command from before:

SCOM Alerts can be related to SSL certificates and it is worth checking the IIS BackEnd Site Binding to see if the certificate is valid. One example of this is the alert for OutlookRpcDeepTestMonitor. Also note that if the server alerting is getting a “proxying to unknown” error that the Certificate issue is likely on a different Exchange Server.

Open IIS, browse down to Site and Exchange Back End. Click bindings and edit the site bindings on port 444. The site should be bound with the certificate called “Microsoft Exchange”. When you view the certificate I found the certificate being used had an error “The CA Root certificate is not trusted”.

To fix this issue the self signed certificate needs to be exported from the Personal Store and imported into the Trusted Root CA.

Run mmc

Add the Snap-in for Certificates

Browse down to Personal and Certificates and Export the self-signed certificate where the friendly name is “Microsoft Exchange”.

Export it using the format P7B and select the option to “Include all certificates in the certification path if possible”

Name the file and Save it anywhere you like.

Browse down to Trusted Root Certification Authorities and right click Certificates -> All Tasks and Import…

Select the certificate you exported, click next and ensure the certificate is placed in the Trusted Root CA.

Now back to IIS when you view the certificate that is bound to the Exchange Back End Site it should look like this:

Now you need to restart the Exchange Health Manager service MSExchangeHM on the server that reported the issue or restart it across all the Exchange Servers:

The SCOM alert for MSExchangeDelivery service is failing due to this exception:

It turns out the health mailbox was full and unable to accept new messages.

To resolve this issue I stopped the MSExchange Health Manager service and deleted all the AD accounts for Health Mailboxes. Health Mailboxes can be found in the Monitoring Mailboxes OU which is inside the Microsoft Exchange System Objects OU by default. After removing the AD objects I restarted the health manager service and new health mailboxes are created automatically.

Read Receipts can easily be disabled on a per message basis at the Outlook client by clicking the No button.

If you wanted to go the extra mile you can setup a rule within Exchange that would disable them on all inbound emails.

Create a new mail rule and select modify message

In the new rule window give it a name “Disable Read Receipt”

Apply this rule to all messages

Do the following and select “Remove this header” and enter the text “Disposition-Notification-To”

Now the header details that are requesting the read receipt are removed from the message and no action will be required from the end user.

If you wanted to perform the same task from the Exchange Management Shell you can run the following command:

When working with disconnected mailboxes I have found where the recently deleted/disabled mailbox doesn’t appear in the Admin Center.

From the exchange management shell you can run the following to find a mailbox, in this case I’m looking for a mailbox for Mark Taylor

The information returned was the following:

As you can see the disconnect date and disconnect reason are blank.

I know the mailbox was on the database MDB01 so again from the shell you can run the following:

Now the results of the previous command show it was disabled and also the ECP shows the mailbox can be reconnected.

When the mailbox doesn’t have a disconnect date or reason it is still possible to reconnect it to the AD account from the exchange management shell by running:

I was recently asked to determine how much of the mailbox database is taken up by recover deleted items?

It’s good to understand that the recoverable items folder resides in the non-IPM subtree of each mailbox. The non-IPM subtree is a storage area within the mailbox that contains operational data about the mailbox. This subtree isn’t visible to users using Outlook, Microsoft Office Outlook Web App, or other email clients.

With Exchange 2013 this provides the following key benefits:

• When a mailbox is moved to another mailbox database, the Recoverable Items folder moves with it.
• The Recoverable Items folder is indexed by Exchange Search and can be discovered using In-Place eDiscovery.
• The Recoverable Items folder has its own storage quota.
• Exchange can prevent data from being purged from the Recoverable Items folder.
• Exchange can track edits of certain content.

The Recoverable Items folder contains the following subfolders:

• Deletions   This subfolder contains all items deleted from the Deleted Items folder. (In Outlook, a user can permanently delete an item by pressing Shift+Delete.) This subfolder is exposed to users through the Recover Deleted Items feature in Outlook and Outlook Web App.
• Versions   If In-Place Hold or Litigation Hold is enabled, this subfolder contains the original and modified copies of the deleted items. This folder isn’t visible to end users.
• Purges   If either Litigation Hold or single item recovery is enabled, this subfolder contains all items that are purged. This folder isn’t visible to end users.
• Audits   If mailbox audit logging is enabled for a mailbox, this subfolder contains the audit log entries.
• DiscoveryHolds   If In-Place Hold is enabled, this subfolder contains all items that meet the hold query parameters and are purged.
• Calendar Logging   This subfolder contains calendar changes that occur within a mailbox. This folder isn’t available to users.

If you wanted to know how much data you had in recoverable items you can try the following:

The above shows each of the recoverable item folders for each mailbox

Now I have the total size of all the recoverable items for all the mailboxes in Bytes. Thankfully powershell has an easy way to convert that to GB for me. You don’t need to divide by 1024 then divide by 1024 then divide by 1024 etc. You can copy the result of the Sum and divide it by 1GB.

54GB is the total amount of space used by Recoverable Items.

Now the question came around how much space is taken up by Legal using In-Place Hold. I ran the following command:

I was recently working with a customer who had issues with logging into OWA. The users would get the following error:

Something went wrong

We can’t get that information right now. Please try again later.

X-FEServer: <servername>

Date: 8/3/2017 4:13:24 PM

In the event viewer under the application logs I found the following warnings:

Log Name: Application

Source: MSExchange OAuth

Date: 8/3/2017 11:13:08 AM

Event ID: 2004

Task Category: Configuration

Level: Warning

Keywords: Classic

User: N/A

Computer: <servername>

Description:

Unable to find the certificate with thumbprint EF6392A5E64713AD43598B7A0FF75080964FB096 in the current computer or the certificate is missing private key. The certificate is needed to sign the outgoing token.

To find the existing certificate for which the authentication configuration is looking you can run:

I found that the certificate returned wasn’t listed when I ran the command Get-ExchangeCertificate. I was required to create a new exchange certificate by running the following commands:

Now to set the AuthConfig to the newly created certificate we need to run the following:

Now when I check the AuthConfig you can see the update certificate:

Within minutes and without any service restarts managed availability had determined OWA to be healthy: