Insights

Oct 2016

Benefits of keeping Exchange Server after migrating to Office 365!

Following my recent posts Why you don’t want to remove the last exchange server after migrating to Office 365 and How you CAN remove the last Exchange server after migrating to Office 365!, you may know that you must keep your Exchange server if you have AAD Connect installed in your environment.

In this post I would like to explain how to maximise the usage of the Exchange Server.

Why would you want to keep the last server?

The main reason to keep the last Exchange Server is for management purposes. Exchange admins usually use it to manage Exchange attributes via Exchange PowerShell and Exchange Administration Console. An experienced administrator will know that Exchange PowerShell provides additional management capabilities that are not available in Active Directory Module, such as Add-ADPermission, Get-ADSite and etc. These commands actually speed up scripting efforts.

Features often overlooked by administrators

Besides the PowerShell scripting effort, I would like to highlight two other major features that Administrators could easily fail to consider.

Feature 1: Secure mail routing between on-premises and EXO organizations

According to this Technet article, there are 3 methods to send email to Office 365 – SMTP client submission, direct send and SMTP relay.

When Microsoft recommends IIS, they recommend using IIS as an intermediary to use SMTP client submission.  It must authenticated using a mailbox.

I believe one of the reasons for this recommendation is they don’t want IIS to become an open relay mail server that can use any FROM address.  They want you to use a known email address from your accepted domain.

Another reason is IIS does not support “Secure mail routing”. Don’t get me wrong, all SMTP should able to send an email using TLS, but Microsoft divides the TLS distinctly into three; Encryption only, Certificate Validation and Domain Validation.

With the encryption only option, TLS is used to encrypt only the communication channel. No certificate authentication is performed. Exchange 2007 and any IIS SMTP services fall into this category.

With Exchange 2010 onwards, we can configure to use the local certificate authentication for outbound connection. Microsoft also calls out in a blog, that under certain circumstances, email might not flow if you don’t have this configured.

In layman’s terms, if you look up the message header of the sent email, you will notice that X-MS-Exchange-Organization-AuthAs. If the value is “internal”, it means this email is authenticated and sent via Exchange server. Only Exchange Server that has been setup correctly will be able to send as “internal”. If this email is sent via IIS, the value will be “Anonymous”, and subject to SPF and other spam filters.

Feature 2:  End user an interface to manage Exchange attributes

Exchange Administration Console provides an end user interface to manage Exchange attributes, such as contact information and distribution groups.

When you move users to Office 365, cloud users can no longer be managed on-premises distribution group via Outlook. Also, if you move from on-premises Exchange server, you might miss the ability to allow users to update their contact details.

Exchange server allows the use of Role-based Access Control (RBAC), and with some configuration, you can grant users the ability to perform these activities.

Joe Palarchio from Perficient has written a blog to allow users to access Exchange 2013 EAC for group management. This will allow users to manage their own distribution groups.

I’ve been unable find a way to allow end users to update their own contact details. With inspiration from this blog, I have written the following command to allow end users to access Exchange 2013 EAC for user management. You can look at the parameters to add/remove attributes you want to let users modify, and those you do not.

At a high level:

  • Create a new “Manage-MycontactInformation” role from an existing role
  • Remove (and add) any commands that allow actions other than updating contact information
  • Create a new role group and assign it a newly created role
  • Change the write scope of the role assignment such that it only applies to groups for which the user is the owner in Exchange

New-ManagementRole -Name “Manage-MyContactInformation” -Parent “Mail Recipients”

get-managementroleentry “manage-mycontactinformation\*” | ? {$_.name -ne “get-recipient” -and $_.name -ne “remove-userphoto” -and $_.name -ne “set-userphoto” -and $_.name -ne “set-mailbox”} | Remove-ManagementRoleEntry -Confirm:$false

$temp= get-managementroleentry mycontactinformation\set-user

get-managementroleentry “Mail Recipients\get-*” | add-managementroleentry -role manage-mycontactinformation

add-managementroleentry “manage-mycontactinformation\set-user” -parameters $temp.parameters -overwrite

add-managementroleentry “manage-mycontactinformation\set-mailbox” -parameters “identity” -overwrite

New-RoleGroup -Name “Self-Managed User Management” –Description “Members of this management role group can update basic contact information of user-self” -Roles “Manage-MyContactinformation”

Set-ManagementRoleAssignment “Manage-mycontactinformation-Self-Managed User Management” -RecipientRelativeWriteScope Self

Lastly, you need to add users to the new “Self-Managed User Management” Group in Active Directory.  Users will then be able to manage their own contact information via the EAC. You can further control the attributes, modifying them by looking at the $temp.parameters attribute.

Hopefully this article will give you some direction when you need to validate the reasons to keep or decommission last Exchange Server in your environment.

Leave a Reply