![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2017\/10\/1-1.png\")
<\/p>\n2018 is already knocking at the door and more and more of my customers find their way towards the cloud. On one hand to Office 365, but mostly towards Exchange Online.<\/p>\n
During the Ingnite 2017, besides the announcement of Exchange Server 2019, Microsoft finally approved the upcoming support for tenant to tenant migrations.<\/p>\n
This helps a lot of decision-makers to go for the cloud and migrate their infrastructure. This, because of the freedom to still be able to change and adjust things after the migration is done. From my point of view Microsoft is on the right path in doing so.<\/p>\n
But still one has to be aware that a migration to the cloud can lead to unexpected issues. I\u2019ll describe some little and a big show stopper for you here. Please mention the big one during your migrations!<\/p>\n
So far so good. Let\u2019s first start with the little show stoppers.<\/p>\n
<\/p>\n
There are a lot of things to keep in mind when migrating to Exchange Online. One is the mailbox delegation and group\/shared mailbox ownership. It is not possible to have Send-As rights on an on-premises mailbox for a mailbox which was migrated to the cloud and vice versa!<\/p>\n
Furthermore it might be possible, that a mailbox migration to Exchange Online just fails with an error:<\/p>\n
<\/p>\n
In most cases it\u2019s just a simple issue. While looking at the Exchange user object I noticed, that this user doesn\u2019t have an \u201c.onmicrosoft.com\u201d STMP address.<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2017\/10\/2-1.png\")
<\/p>\n
So, what to do now? Very simple! Just go to \u2018Add\u2019 and create an additional SMTP address for that user with the \u2018.onmicrosoft.com\u2019 domain of your O365 tenant. Afterwards the migration will no longer fail.<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2017\/10\/3-1.png\")
<\/p>\n
A far bigger thing are 3rd<\/sup> party systems like ERP\u2019s and others which are accessing Exchange through the Exchange Web Services (EWS).<\/p>\n There are two EWS paths. One internal and one external. The challenge here is that applications which are using EWS can whether access on-premises mailboxes (internal), or<\/strong> cloud mailboxes (external). And here comes the solution for this challenge.<\/p>\n Here\u2019s what we did and why we did it.<\/p>\n First we added the \u201cApplicationImpersonation\u201d permission to the Discovery Management role. Members of the Discovery Management role group can perform searches of mailboxes in the Exchange organization for data that meets specific criteria and can also configure litigation holds on mailboxes. See https:\/\/technet.microsoft.com\/en-us\/library\/dd638105(v=exchg.150).aspx<\/a><\/p>\n The Application Impersonation permission is needed for the access through EWS using impersonation. Impersonation enables an account on an Exchange server to perform actions by using the permissions that are associated with another account. See https:\/\/msdn.microsoft.com\/en-us\/library\/office\/dd633680(v=exchg.80).aspx<\/a><\/p>\n In the next step we just added the account used by the application to the Discovery Management role. By this it now can use impersonation through EWS and can also perform mailbox searches.<\/p>\n To test the mailbox access through EWS you can use the following PowerShell script. It\u2019s using the default EWS dll path from Exchange Web Services API 2.2 is installed. Change the path if needed.<\/p>\n 2018 is already knocking at the door and more and more of my customers find their way towards the cloud. On one hand to Office 365, but mostly towards Exchange Online. During the Ingnite 2017, besides the announcement of Exchange Server 2019, Microsoft finally approved the upcoming support for tenant to tenant migrations. This helps […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[1923,2,3],"tags":[],"class_list":["post-612","post","type-post","status-publish","format-standard","hentry","category-microsoft-365","category-exchange","category-powershell"],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/612","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=612"}],"version-history":[{"count":14,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/612\/revisions"}],"predecessor-version":[{"id":638,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/612\/revisions\/638"}],"wp:attachment":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=612"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The challenge<\/h5>\n
The solution in steps<\/h5>\n
\n
<\/h5>\n
The solution explained<\/h5>\n
Test it<\/h5>\n
#requires -RunAsAdministrator\r\n\r\n$EwsDll = 'C:\\Program Files\\Microsoft\\Exchange\\Web Services\\2.2\\Microsoft.Exchange.WebServices.dll' # Path to EWS dll\r\n\r\n$Username = 'User@Contoso.com' # migrated to Exchange Online - Service account, which is member of the role \u201cDiscovery Management\u201d<\/strong>\r\n\r\n$Password = 'Pa$$w0rd'\r\n\r\nAdd-Type -Path $EwsDll\r\n\r\n$Service = New-Object -TypeName Microsoft.Exchange.WebServices.Data.ExchangeService\r\n\r\n$Arguments = @($Username, $Password)\r\n\r\n$Creds = New-Object -TypeName Microsoft.Exchange.WebServices.Data.WebCredentials -ArgumentList $Arguments\r\n\r\n$Service.Credentials = $Creds\r\n\r\n$Service.TraceEnabled = $True\r\n\r\n# Autodiscover approach (RECOMMENDED):\r\n\r\n# $Service.AutodiscoverUrl( $Username, {$True} )\r\n\r\n# Hardcoding the EWS endpoint:\r\n\r\n$Service.Url = \"https:\/\/mail.Contoso.com\/EWS\/Exchange.asmx<\/a>\"\r\n\r\n$Service | Format-List\r\n\r\n# A connection is established and information from the mailbox can be gathered. For example, OOF settings:\r\n\r\n$SmtpAddress = 'User@Contoso.com' #On-premise mailbox, or Exchange Online mailbox\r\n\r\n$Service.GetUserOofSettings($SmtpAddress)<\/pre>\n","protected":false},"excerpt":{"rendered":"