Hybrid Organization Configuration Transfer
We are very happy to announce a new feature that will help you the admin reduce the amount of time needed to configure config objects once hybrid setup is complete. What does this feature do? This feature enables a one-time transfer of key organization policy objects during the onboarding process from Exchange on-premises to Exchange Online. This feature is tightly integrated into the existing Hybrid Configuration Wizard. The administrator running the HCW can choose to migrate either all the detected objects while onboarding from Exchange on-premises to Exchange Online or choose not to transfer any. This is only a one-time transfer though, to avoid the need to have you set them up manually. Once the one-time transfer is complete, you will need to manually update values in either On-prem or Online to keep them in sync if you change anything. We’re supporting this config transfer whether you are migrating from Exchange Server 2010, Exchange Server 2013 or Exchange Server 2016, and we’re delivering this feature in phases. Phase 1 will be launched at the end of June 2018. Which is… kind of… pretty much now, really. What kind of Policy objects are in scope? The objects we’re including in phase 1 are: Retention Policy Retention Policy Tags OWA Mailbox Policy Mobile Device Mailbox Policy Active Sync Mailbox Policy However, in phase 1 only new objects/policies will be copied over from on-premises to cloud. Any existing objects/policies in Exchange Online will not be modified. How do I use this cool new feature? This feature is completely integrated into the existing Hybrid Configuration Wizard. Just downloading the latest HCW is all you need to do. As you can see from the screenshot, we’ve added a checkbox at the bottom of the Hybrid Features page to allow you to enable this feature and to copy over objects from your Exchange on-premises organization to Exchange Online. What’s next? In phase 2, in addition to copying several new objects (Organization Config, DLP Policy, Active Sync Device Access Rule and Active Sync Organization Settings) from on-premises to cloud, the admin will be given a choice to update existing objects in the cloud if the attribute values are different from those on-premises. We hope you enjoy this new feature and look forward to hearing any feedback or comments, either here on the blog or directly in HCW – we’ve built an awesome feedback system into the HCW and we love to hear what our customers have to say. Kavya Chandra Program Manager, Office 365 Enterprise CloudChanges coming to the SMTP Authenticated Submission client protocol
There are a number of client protocols offered by Exchange Online to allow email clients to send email from their mailboxes. One of the most widespread protocols is SMTP Authenticated Submission (also known as SMTP Client Submission) which is supported by most email service providers. This non-proprietary protocol is used to send email by legacy email clients, third-party software and services, and devices such as multi-function printers. Changes that we’re making to how this protocol works in Exchange Online may adversely affect the rate at which these clients or devices can send email. Starting June 1, the following changes will begin rolling out for SMTP Authenticated Submission protocol: Sent email will now be stored in the Sent Items folder of the mailbox. Only three concurrent connections to our service per mailbox will be allowed. Additional connections will be rejected with one of the following errors: 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded. 432 4.3.2 concurrent connection limit exceeded Exchange Online uses a number of mechanisms to protect the service from abuse and ensure fair usage by users. One such protection is the Recipient Rate Limit (RRL) which limits the number of recipients per day to 10,000. The aim is to deter the sending of bulk email (and as mentioned on the service limits page, you should send bulk email using a specialized third-party provider). This change to the SMTP Authenticated Submission protocol will further protect the service from large bursts of emails in a short amount of time from automated systems. This will not affect the majority of SMTP Authentication Submission users who only send from one email client or multi-function device for a given mailbox. For customers who have numerous devices sending emails using the same mailbox (for example, printer@contoso.com), there’s a small chance that multiple devices will try to send email at the same time. Any devices that are rejected would just need to retry. The same is true if an application that uses a cloud mailbox to send email tries to send multiple messages at the same time (and that behavior depends on how the application was designed). Most applications and devices that send email should be able to handle errors and retry sending email. However, retrying will reduce the overall rate at which email can be sent. If this change adversely affects you, you have a few options: Use a different mailbox for each application or device. If you’re trying to send thousands of copies of the same message (for example, a newsletter) in parallel using a third-party application, you may need to send it out in batches or use distribution groups. If time is important (for example, an alert system that generates multiple alerts at the same time), you’ll need to use a third-party delivery service that’s designed to send large amounts of email. Sean StevensonPermanently Clear Previous Mailbox Info
We are introducing a new parameter that can be called by using the Set-User cmdlet in Exchange Online PowerShell. The feature is focused for customers doing migration of on-premises mailboxes to the cloud and you will be able to use it within three weeks or so (Edit 1/19: we updated this due to slower than expected rollout): Customers who have Hybrid or on-premises environments with AAD Connect / Dir Sync may have faced the following scenario: User Jon@contoso.com has a mailbox on-premises. Jon is represented as a Mail User in the cloud. You are synchronizing the on-premises directory to the cloud in preparation to migrate to Exchange Online. Due to issues with the on-premises sync or due to a configuration problem, the user Jon@contoso.com does not get the ExchangeGUID synchronized from on-premises to the cloud. If the Exchange GUID is missing from the object in the cloud, assigning an Exchange license to Jon@contoso.com will cause Exchange Online to give the user a mailbox, converting the object from a Mail User to a User Mailbox. (Adding the license is a step required for the migration of the mailbox from on-premises to the cloud.) The end result is the user that has 2 mailboxes: one on-premises and one in the cloud. This is not good. Mail flow issues will follow. Those doing these types of migrations will know that the ExchangeGUID value is very important as it helps Exchange Online identify that the user has a mailbox on-premises, and if an Exchange license is assigned in the cloud, a new mailbox should not be created. The immediate fix for this situation is to remove the Exchange License from Jon@contoso.com. This will convert the cloud object for Jon back to a Mail User. Mail flow should be restored at this point. The problem now is that you have an “unclean” cloud object for Jon. This is because Exchange online keeps pointers that indicate that there used to be a mailbox in the cloud for this user: PS C:\WINDOWS\system32> Get-User Jon@contoso.com | Select name,*Recipient* Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails ---- ---------------------------- ------------- -------------------- Jon UserMailbox MailUser MailUser Re-assigning the license after that will always err on the side of caution and Exchange Online will try to re-connect the (duplicate, temporary) mailbox in the cloud (and mailboxes can be reconnected for 30 days). Therefore Jon’s account in the cloud can’t be licensed in preparation for migration. Up to now, one of the few options to fix this problem was to delete *only in the cloud* Jon’s object and re-sync it from on-premises. This would delete jon@contoso.com from the cloud – but from all workloads, not only Exchange. This is problematic because Jon could have his OneDrive or SharePoint data in the cloud only and deleting his account means that this will be deleted too. If the account is then re-created, Jon and the tenant admin would have to work to recover to his new account all the data he used to have in OneDrive or SharePoint just because Exchange data needed to be “cleaned up”. The new parameter in the user cmdlet will allow tenant admin to clean up Exchange Online Jon’s object without having to delete it. To clean the object, you can run the following command: PS C:\> Set-User Jon@contoso.com -PermanentlyClearPreviousMailboxInfo Confirm Are you sure you want to perform this action? Delete all existing information about user “Jon@contoso.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to continue? Yes Yes to All No No to All [?] Help (default is "Y"): Y Executing this leaves you with a clean object that can be re-licensed without causing the 2-mailbox problem. Now you can on-board Jon’s on-premises mailbox following the usual steps. An alternative – a call to support to do the clean-up for you - is also not needed. Remember, cleaning up the user means that the older associated disconnected (duplicate) cloud mailbox is not recoverable. If you want to keep it or be able to check it’s content, we recommend using Soft Deletion or Inactive Mailboxes to keep the mailbox. Note: This command is expected to be executed when you have an on-premises mailbox and a mailbox in the cloud for the same object due to bad AAD Connect configuration, to clean the object that can be re-licensed. The procedure allows you get out of the dual mailbox state and enable you to re-try on-boarding the mailbox immediately. If you execute this for a user whose mailbox is cloud only after delicensing the user (and intend to later re-license the same user and expect to have a new clean mailbox for the user) - then this will not happen immediately. To avoid potential loss of mailbox data due to unintended/mistaken execution of the command, we retain the mailbox data for 30 days so that you may recover it. If your intention is to clean-up cloud only mailbox then you may hard delete the user account to re-create a clean mailbox. Mario Trigueros Solorio
