Office 365 supports the upload of PST files to Azure storage for a direct import to mailboxes hosted in Exchange Online. The steps are described in detail in the online documentation at Microsoft Docs.
Import CSV using an email address
But you might encounter the following error after starting the import job using the Security & Compliance dashboard.
X-Psws-Exception: Microsoft.Exchange.Configuration.Tasks.ManagementObjectAmbiguousException,The operation couldn't be performed because 'TeamMailbox-Sales@varunagroup.de' matches multiple entries.
X-Psws-Warning: When an item can't be read from the source database or it can't be written to the destination database, it will be considered corrupted. By specifying a non-zero BadItemLimit, you are requesting Exchange not copy such items to the destination mailbox. At move completion, these corrupted items will not be available at the destination mailbox.
Before you were able to start the import job the job configuration, the CSV file, and the content of the PST file were analyzed successfully. There was no hint of multiple entries for the target mailbox.
The detailed error message can be retrieved using the View log link. A clear text message is stated in the Status detail column, but you need to expand the width of the column.
The hint provided in the status detail column states that there are multiple identities for the primary email. At this point in time, I do not know, how this possible when the target account is synchronized with AAD Connect.
Use the target mailbox GUID instead of the target email address as the target address in the CSV configuration file.
Connect to Exchange Online Remote PowerShell session and query the mailbox GUID for the target mailbox(es).
# Query target mailbox GUID for a single mailbox
Get-Mailbox TeamMailbox-Sales@varunagroup.de] | FL Guid
Create a new import job referencing the same PST file already copied to the Azure storage.
Import CSV example using the mailbox GUID
The import job will now be executed as expected.
Do you need assistance with your Exchange Server platform? You have questions about your Exchange Server organization and implementing a hybrid configuration with Office 365? You are interested in what Exchange Server 2019 has to offer for your company?
Contact me at email@example.com
Follow at https://twitter.com/stensitzki
When you want to migrate your legacy public folders from Exchange 2010 to modern public folders in Exchange Online you must prepare the public folder names for migration.
Public folder names are not allowd to contain the following:
The script Fix-PublicFolderNames.ps1 fixes the public folder names in preparation for migration to modern public folders.
# Rename and trim public folders found on Server MYPFSERVER
.\Fix-PublicFolderNames -PublicFolderServer MYPFSERVER
This is a map of the current datacenter footprint of Exchange Online, as presented during Microsoft Igite 2017 in Orlando.
There is a difference between Exchange Online datacenters hosting mailboxes and front door endpoint datacenters. Front door endpoints are public peering locations providing client connections with higher reliability and lower latency.
It's going to be an interesting week next week at Microsoft Ignite in Orlando, FL.
There will be a lot announcements about Microsoft Technologies to come.
The conference is the best opportunity to learn about new technologies and to extend your IT professional network.
If you want to talk about OneDrive for Business, Exchange On-Premises and Exchange Online solutions, or how you can move to cloud service contact me by email or Twitter to schedule a meeting.
See you in Orlando.
This blog post focusses on an issue where your Exchange Online users are not able to send emails to other Exchange Online recipients outside of your organization when using a 3rd Party Centralized Email Flow Setup. The term 3rd Party Centralized Email Flow Setup describes a solution where you not follow the preferred hybrid architecture proposed by the Exchange product group, but use a 3rd party software as a centralized email gateway.
You have followed the recommendation to secure the Exchange Online inbound connector for your on-premises email servers by using a certificate name or the remote IP address of your on-premises email gateway.
The on-premises email security gateway utilizes a self-signed certificate to secure TLS connections. The gateway is configured to use two different send connector setups:
In this case Exchange Online Protection (EOP) will not be able to differentiate between tenant internal inbound mail flow and mail flow targeted to other tenants. Therefore, email messages sent from your Exchange Online users to recipients located in other Exchange Online tenants will be discarded.
Interestingly enough, this will happen silently. Your gateway solution will log a successful delivery to Exchange Online Protection. The tenant administrator of the recipient domain will not find an any information in the Exchange Online message tracking logs.
The following diagram illustrates the setup.
The solution for this problem is pretty simple. Just use dedicated certificates for each connector targetting Exchange Online.
Change the Internet Connector to fully trusted 3rd party certificate. In this case you are not required to modify the existing Exchange Online inbound connector setup.
The new connector configurations are:
The following diagram illustrates the new setup: