Send mail to Office 365 via an Exchange Server hosted in Azure

Those of you who have attempted to send mail to Office 365 from Azure know that sending outbound mail directly from an email server hosted in Azure is not supported due to elastic nature of public cloud service IPs and the potential for abuse. Therefore, the Azure IP address blocks are added to public block lists with no exceptions to this policy.

To be able to send mail from an Azure hosted email server to Office 365 you to need to send mail via a SMTP relay. There is a number of different SMTP relays you can utilise including Exchange Online Protection, more information can be found here: https://blogs.msdn.microsoft.com/mast/2016/04/04/sending-e-mail-from-azure-compute-resource-to-external-domains

To configure Exchange Server 2016 hosted in Azure to send mail to Office 365 via SMTP relay to Exchange Online protection you need to do the following;

  1. Create a connector in your Office 365 tenant
  2. Configure accepted domains on your Exchange Server in Azure
  3. Create a send connector on your Exchange Server in Azure that relays to Exchange Online Protection

Create a connector in your Office 365 tenant

  1. Login to Exchange Online Admin Center
  2. Click mail flow | connector
  3. Click +
  4. Select from: “Your organisation’s email server” to: “Office 365”o365-connector1
  5. Enter in a Name for the Connector | Click Nexto365-connector2
  6. Select “By verifying that the IP address of the sending server matches one of these IP addresses that belong to your organization”
  7. Add the public IP address of your Exchange Server in Azureo365-connector3

Configure accepted domains on your Exchange Server in Azure

  1. Open Exchange Management Shell
  2. Execute the following PowerShell command for each domain you want to send mail to in Office 365;
  3. New-AcceptedDomain -DomainName Contoso.com -DomainType InternalRelay -Name Contosoaccepted-domain1

Create a send connector on your Exchange Server in Azure that relays to Exchange Online Protection

  1. Execute the following PowerShell command;
  2. New-SendConnector -Name “My company to Office 365” -AddressSpaces * -CloudServicesMailEnabled $true -RequireTLS $true -SmartHosts yourdomain-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidationsend-connector1

Free/busy Exchange hybrid troubleshooting with Microsoft Edge

Those of you who have configured Exchange hybrid with Office 365 before know that free/busy functionality can be troublesome at times and not work correctly.

Instead of searching through Exchange logs I found that you can pin point the exact error message through Microsoft Edge to assist with troubleshooting.

To do so;

  1. Open Microsoft Edge and login to Office 365 OWA (https://outlook.office365.com/owa) with an Office 365 account
  2. Create a new meeting request
  3. Press F12 to launch developer tools
  4. Conduct a free/busy lookup on a person with a mailbox on-premises
  5. Select the Network tab
  6. Select the entry with “GetUserAvailability”devtools-getuseravailability
  7. Select the body tab (on the right hand side)
  8. The MessageText element will display the exact error messagedevtools-messagetext

Exchange Server 2016 in Azure

I recently worked on a project where I had to install Exchange Server 2016 on an Azure VM and I chose a D2 sized Azure VM (2 cores, 7GB RAM) thinking that will suffice, well that was a big mistake.

The installation made it to the last step before a warning appeared informing me that the server is low on memory resources and eventually terminated the installation, leaving it incomplete.

Let this be a warning to the rest of you, choose a D3 or above sized Azure VM to save yourself a whole lot of agony.

To try and salvage the Exchange install I attempted to re-run the installation as it detects an incomplete installation and tries to pick up where it failed previously, this did not work.

I then tried to uninstall Exchange completely by running command: “Setup.exe /mode:Uninstall /IAcceptExchangeServerLicenseTerms”. This also did not work as it was trying to uninstall an Exchange role that never got installed, this left me one option manually remove Exchange from Active Directory and rebuild the Azure VM. 

To remove the Exchange organisation from Active Directory I had to complete the following steps;

  1. On a Domain Controller | Open ADSI Edit
  2. Connect to the Configuration naming contextconfig-naming-context
  3. Expand Services
  4. Delete CN=Microsoft Exchange and CN=Microsoft Exchange Autodiscoverconfig-exchange-objects
  5. Connect to the Default naming contextdefault-naming-context
  6. Under the root OU delete OU=Microsoft Exchange Security Groups and CN=Microsoft Exchange System Objects delete-exchange-objects
  7. Open Active Directory Users and Computers
  8. Select the Users OU
  9. Delete the following:
    • DiscoverySearchMailbox{GUID}
    • Exchange Online-ApplicationAccount
    • Migration.GUID
    • SystemMailbox{GUID}ad-exchange-objects

After Exchange was completely removed from Active Directory and my Azure VM was rebuilt with a D3 size I could successfully install Exchange Server 2016.

Exchange Server 2016 install error: “Active Directory could not be contacted”

I recently worked on a project where I had to install Exchange Server 2016 on an Azure VM and received error “Active Directory could not be contacted”.

To resolve the issue, I had to complete the following steps;

  1. Remove the Azure VM public IP address
  2. Disable IPv6 on the NICipv6-disabled
  3. Set the IPv4 DNS suffix to point to your domain. If a public address is being used it will be set to reddog.microsoft.com by default.dns-suffix

Once done the installation could proceed and Active Directory was contactable.

Programmatically read email from an Exchange Sever Mailbox

I can’t recall how many times I have come across a requirement to programmatically read emails from an Exchange Server mailbox and take some action based on the presence of new messages. The component reading the emails can read the mail content, parse its contents and transmit the data to other downstream systems. In this blog I’m going to take a look at one way we can do this.

Objective

In my scenario there was a requirement to develop a program to retrieve mails from an Exchange mailbox and, based on a specific criteria, send the email to multiple users based on an distribution list identifier. Listed below are the steps, I intended to follow:

  1. Use an efficient calling mechanism to poll for new email based on a given criteria
  2. Read any new email messages
  3. Transform the received email to an SMTP-friendly message to be sent to a list.

Solution

I developed my solution in .Net, using C# as the language of preference, hooking into the Exchange Web Services (EWS) Managed API as the polling endpoint and using simple SMTP endpoints to send mails. Let’s look at the solution in a little more detail.

Prerequisites / Preparation

  1. Open Visual Studio and create a new Console Application
  2. Install Exchange Web Services (EWS) Managed API from NuGet Package Manager
  3. Add reference for System.Configuration (to support application configuration).

Create a connection to a given mailbox

When creating connections to an Exchange mailbox we need to know the version of the source Exchange environment. The code to connect will differ based on the target environment. At time of writing, the EWS managed API supports the following Exchange Server versions:

  1. Exchange 2007 SP1
  2. Exchange 2010 (inc. SP1 & SP2)
  3. Exchange 2013 (inc. SP1)

Use the latest (Exchange 2013 SP1) if you are using this to connect with Exchange Online in Office 365. Below is the code to connect and get a service instance attached to an Office 365 mailbox.

Remember to have a AutodiscoverRedirectionUrlValidationCallback function to enable SSL communication.

The sample below shows how to connect to a local Exchange 2007 environment.

Read email using the created service instance

Once the connection is up and running this is relatively straightforward. The process can be summarised as follows:

  1. Specify the mailbox folder to read messages from (i.e. inbox)
  2. Specify the source mailbox email identifier
  3. Specify any search filters
  4. Specify the aggregation criteria (OR / AND)
  5. Specify the maximum number of messages to be retrieved
  6. Retrieve message identifiers using the service instance.

… and some sample code …

Now we have the message identifiers, but the message body and other basic properties are missing. A second call will need to be made to the server retrieve extended properties for each message. Here is the code for that process:

Prepare the outbound mail for sending

I used a temporary custom object to transform the email from the EWS calls prior to sending. Below is the code used to create the class and the mapping logic.

The code below transforms the temporary mail object into a valid SMTP mail, validates the email identifiers, the mail needs to broadcast to, filters out the invalid mail Ids (if found) and sends the mails in multiple allowed batches.

last but not least.. Send the mail..

 

      mail.SendMail();

Happy Mailing!!!

Securing Emails Outside of Your Organization With Office 365 Message Encryption

​For those of you who have been concerned about email security for a number of years, you may remember a solution from Microsoft called Exchange Hosted Encryption (EHE).  This was a cloud based service which allowed organizations to encrypt emails according to certain defined rules.  For example, you could encrypt emails where the intended recipient was outside of your organization and certain keywords or regular expressions where detected such as a credit card number.  This was a very useful service for protecting emails sent to ANY user, regardless of the relationship with the user’s company.  There was no need to set up federation between the two organization.  All certificates were stored and maintained in the cloud which made it very simple to administer compared to an on-premises solution.

The problem with EHE was that it was a separate service.  It required a completely separate console to configure and administer .  Moreover, using EHE required an additional licensing cost for every user that needed to send encrypted email.  As a result, adoption of EHE was low except for industries where data security was paramount.  Some examples of industries where EHE is very popular include:

1) Financial services including banking and insurance

2) Healthcare

3) Lawyers

4) Contract management

Microsoft recently announced Office 365 Message Encryption as the next release of EHE.  There are a number of improvements in this release which make it far more appealing to deploy and utilize.  First, the service is based on Microsoft Azure Rights Management Services (RMS).  Office 365 integrates beautifully with Azure AD and Azure AD (RMS).  This means that Office 365 Message Encryption is a built-in capability of Office 365.  Deployment and configuration of the service can be performed directly from the Exchange Online Admin Console. 

The following plans include Office 365 Message Encryption:

1) Office 365 E3

2) Office 365 E4

3) Azure AD RMS

4) Enterprise Mobility Suite (Exchange Online not included)

Other Office 365 plans can add Message Encryption as an additional subscription SKU.  Running Exchange Online Protection (EOP) is a pre-requisite to running Message Encryption.

The behavior of Office 365 Message Encryption is controlled by Exchange transport rules.  These rules are configured by an Exchange Online administrator and apply across the organization.  Here are some examples of popular transport rules:

1) Encrypt all emails sent from legal council to a user external to the organization

2) Encrypt all emails sent to a user external to the organization where the phase “encrypt” appears in the subject line

3) Encrypt all emails sent to a user external to the organization where the body contains the number pattern XXXX-XXXX-XXXX-XXXX which resembles a credit card PAN.

When a user sends an email that matches one of these transport rules, the message is encrypted, converted into an HTML attachment, and then transmitted to the recipient.  When the message is received, the end user is given instructions on how to open the encrypted message.  The recipient does NOT require an email account that is trusted by the sender or federated with his organization.  The only requirements is that the email address of the recipient is configured as either a:

1) Microsoft Account

2) Microsoft Organization ID

If the email address of the recipient is NOT configured as one of the above accounts, he will be presented with instructions on how to do so.  This is required before the encrypted message can be opened.

To improve the Office 365 Message Encryption experience for end users, I recommend that you set up at least two transport rules:

1) Transport rule for outbound email based on business rules for data protection

2) Transport rule to decrypt inbound email on delivery to save internal users the extra step

Organizations using Office 365 Message Encryption can customize the experience for the end user.  They can add a corporate logo or standard disclaimer text to every encrypted email.  Customizing the experience requires the user of PowerShell as there is no UI available for message customization in the current release.

If you need assistance securing your corporate email, please contact Kloud solutions at the following URL:

http://www.kloud.com.au/#

End User Access To Spam Quarantine in Office 365

One of the ​features of Office 365 which gets very little attention is Exchange Online Protection (EOP). EOP is a Microsoft cloud service which protects Exchange Online in Office 365 from spam and viruses. EOP is a built-in capability of Office 365. There is no additional license required to use it.

Emails which EOP detects as spam are trapped in a quarantine area. Users were notified that email was quarantined by an automatically generated email message from EOP. The user could then decide if the email was truly spam or a false positive. If the user felt that the email was not spam, there was an option to release the email from quarantine. Released emails are immediately delivered to the user’s inbox.

Microsoft has released a new feature for Office 365 called the spam quarantine page. This new page allows end users to view their emails which are currently in quarantine via a web-based in interface using an Office 365 OrgID. Users can choose to release an email from quarantine and have id delivered to their inbox fromthe spam quarantine page. The console can be accessed via the following URL:

https://admin.protection.outlook.com/quarantine

There is an advanced search option in the spam quarantine page. This allows users to search for a speific email trapped in quarantine. The user can search using the following criteria:

1) Message ID

2) Sender Email Address

3) Recipient Email Address

4) Subject

5) Received

6) Expires

7) Type

If you are looking for guidance on how to migrate to and configure EOP to protect your Office 365 tenant, please contact Kloud Solutions at the following URL:

http://www.kloud.com.au/

Exchange Online Inactive Mailboxes

In an enterprise deployment of Office 365 Wave 14, one of the recurring pain points was how to handle mailbox data retention once a user left the business and the data is required for compliance purposes. There were a number of options available to handle this:

  • Leave the mailbox in-situ and disable the user account
  • Change the license SKU to Kiosk Plan 2 as it’s a cheaper license cost and disable the user account
  • Migrate the departed user mailbox back to the on-premises hybrid Exchange platform
  • Use a 3rd party cloud archive solution

While all of these will work, on an enterprise scale they’re quite clunky and even with an identity management solution in place, they’re not particularly practical or cost effective. Aside from the high administrative overhead, there’s a high cost to license most of these options or maintain on-premises infrastructure. And if you’re going to these lengths to preserve this data, you want it to be searchable through eDiscovery, in which case it should stay where the bulk of the mail already is: in the cloud.

With Office 365 Wave 15 and Exchange 2013, the Legal Hold functionality (now called In-Place Hold) has been enhanced to include the “inactive mailboxes” feature to cover a departed user scenario. When a user leaves the business, it is now possible to place the mailbox into In-Place Hold, then delete the corresponding user account. The mailbox will then be available to eDiscovery indefinitely and the mailbox license can be released back into the pool.

Once the retention requirements have been met, it is possible to remove the In-Place Hold and allow the mailbox to be deleted in accordance with the default deleted mailbox retention policy. Inactive mailboxes do not require any Office 365 or Exchange Online licensing.

The benefits of using the Inactive Mailbox feature are:

  • Visible in eDiscovery searches
  • Preserves the mailbox indefinitely
  • Hidden from users so no longer available in the GAL
  • Cannot send or receive email
  • No Active Directory / Office 365 account required
  • No license required

How to Create an Inactive Mailbox

  1. In-Place Hold
    When a mailbox is placed in In-Place hold, the content is preserved as is and cannot be changed. The mailbox can be on hold for a specified time or indefinitely. The mailbox is still subject to the standard Exchange Online deleted mailbox retention policy of 30 days, meaning that if the mailbox has been inactive for over 30 days and is taken out of In-Place Hold, it will be deleted permanently

    To create a new In-Place Hold that will be active for seven years, execute the following PowerShell command

    New-MailboxSearch “Joel-Test-Hold” –SourceMailboxes “joel.neff@showcase.kloud.com.au” –InPlaceHoldEnabled $True –ItemHoldPeriod 2557
  2. Delete Source Account
    With In-Place Hold activated on the mailbox, the associated account can be deleted from Active Directory or from Office 365. Once the seven year period has expired, the mailbox will be automatically deleted.

Accessing an Inactive Mailbox

As the associated account has been deleted, the mailbox cannot be opened in Outlook or OWA. The only way to access the content of the mailbox is to use the eDiscovery console from with the Exchange Admin Centre. The contents of the entire mailbox can be shown, or specific items related to a search query. All results can be exported to a PST file.

To run an eDiscovery search from PowerShell, I’m going to search for all email items in a particular mailbox that contain either the word “Kloud” or “Office 365” between the 1st of January and today:

New-MailboxSearch “Test-Search” -StartDate “1/1/2013” -EndDate “20/6/2013” -SourceMailboxes “Joel-Test-Hold” -TargetMailbox “Discovery Search Mailbox” -SearchQuery “Kloud” AND “Office 365” -MessageTypes Email -IncludeUnsearchableItems -LogLevel Basic

Manually Remove an Inactive Mailbox

Once the compliance requirements have been met, or the mailbox is no longer needed, it is possible to remove the hold placed on the mailbox and allow it to delete. As mentioned earlier, if the mailbox has been on hold for over 30 days, it will be permanently deleted once the hold is removed. If it has been on hold for less than 30 days the mailbox will be available for the remainder of the 30 day period since the hold was activated.

Set-MailboxSearch “Joel-Test-Hold” –InPlaceHoldEnabled $False
Remove-MailboxSearch “Joel-Test-Hold”

A complete list of the available Set-MailboxSearch parameters can be found at http://technet.microsoft.com/en-us/library/dd298064(v=exchg.150).aspx