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 CloudThe many ways to block automatic email forwarding in Exchange Online
Update 1/19/2021: We have updated and expanded the information contained here in a new blog post. Please go here to read it:All you need to know about automatic email forwarding in Exchange Online In support, I get this question quite frequently: “How do I block users from auto forwarding their mail outside my environment?” There are plenty of good reasons you may not want auto forwarding: you may have HIPAA laws to follow, regulatory compliance or data privacy concerns or simply because it makes you uncomfortable. A user can set up forwarding in a few different ways: 1. Create an inbox rule to forward using Outlook or Outlook on the web (also sometimes called by OWA, it’s old name). The types of forwarding via this method are: forward, forward as an attachment and redirect. In Outlook this is accessed through File > Manage Rules and Alerts In OWA this is accessed through Options > Mail > Inbox and sweep rules 2. Set forwarding on their mailbox using OWA options. In OWA this is accessed through Options > Mail > Forwarding. Users can select to Stop or Start forwarding and enter the address to forward to. This is set as a “ForwardingSMTPAddress” parameter on the mailbox. Methods to stop auto forwarding As an admin, you have a few different ways to prevent forwarding of emails outside of your environment. The main ways I have identified are listed below, along with a brief description of their pros and cons. Select the link to learn more: Remote Domain Pros: Applies to all the above-mentioned types of forwarding a user can set up. Quick and easy to configure. Cons: The user is not notified their forwarded message is dropped Use If: You have few exceptions to consider and just want an easy blanket option Transport Rule Pros: Allows you more granularity on conditions and actions, reporting is available Cons: Does not block the OWA “Start/Stop Forwarding” method Use If: You want to be able to notify the user their message was blocked, or if you have complex exceptions you need to allow for Role Based Access Control (RBAC) Pros: In OWA, users simply do not see the option to set forwarding up Cons: Does not remove the options in Outlook and does nothing for forwarding that was already set up. It only removes the option to set it up from view; it does not remove any rules already in place and for that matter, it continues to allow those rules to function (though admittedly you could always run a script to null out the parameter). Use If: You are a company that primarily uses OWA and have already ensured users do not have forwarding set to begin with. Remote Domain You can set up the remote domain option through the Exchange Online Admin Center > Mail Flow > Remote Domains and select the default remote domain. Uncheck the “allow automatic forwarding” box and repeat for any additional remote domains you may have set up that you want to drop auto forwarded messages to. The downside to this method is that the user is not notified that their forwarded message is dropped. However, as an admin, you would see the drop in a message trace as a failed message with the following Drop reason: “[{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward addressed to external recipient};{MSG=};{FQDN=};{IP=};{LRT=}]” Say you have a partner company, and your users may have legitimate reasoning to forward their mail to the partner; you can configure an additional remote domain for the partner domain with different settings. Transport Rule To set up a transport rule in Exchange Online Admin Center, navigate to Mail Flow > Rules and select the plus sign to create a new rule. If you are not seeing all options, ensure you select “More options” towards the bottom of the screen. You can add multiple conditions, but the key is to include “the message type is… Auto-forward”. In PowerShell that would be the parameter ‘-MessageTypeMatches AutoForward’ In the image, I have chosen to apply the rule to messages forwarded to all recipients outside the organization and I am rejecting the message with an explanation so the user is informed of the policy. You can also easily add exceptions here via the “add exception” button if certain senders or recipient domains should be allowed to forward. In addition, you can easily identify the users hitting this rule as well through PowerShell reporting or by the generating an incident report action. Role Based Access Control (RBAC) RBAC is the method to remove the forwarding options from user’s view in Outlook on the web. You may want to note that RBAC is cumulative, so if an administrator has an admin role that includes New-Inbox rule with the forwarding parameters, removing it with the steps above will not make it disappear. If you are less familiar with manipulating RBAC, I would point you to this blog post which does a deeper dive into RBAC in general. This tips and tricks guide is also incredibly handy. I have already identified the main user role that includes the cmdlets and parameters that need to be removed, however if you would like to find which roles include other commands you could run the following: Get-ManagementRoleEntry “*\New-InboxRule” Here are the steps to create a new management role and remove the forwarding options. 1.) Create the new role with parent “MyBaseOptions” New-ManagementRole -Parent MyBaseOptions -Name DenyForwarding 2.) Depending on what you want to do, I have 3 sets of sample CMDlets for you: Removes ability to create a new inbox rule in Outlook on the web with 3 specified actions: Set-ManagementRoleEntry DenyForwarding\New-InboxRule -RemoveParameter -Parameters ForwardTo, RedirectTo, ForwardAsAttachmentTo Removes ability to edit an existing inbox rule to change it to one of specified 3 actions: Set-ManagementRoleEntry DenyForwarding\Set-InboxRule -RemoveParameter -Parameters ForwardTo, RedirectTo, ForwardAsAttachmentTo Removes the page in “Forwarding” page in Outlook on the web options: Set-ManagementRoleEntry DenyForwarding\Set-Mailbox -RemoveParameter -Parameters DeliverToMailboxAndForward,ForwardingAddress,ForwardingSmtpAddress 3.) Create a new policy and add all the management roles, including our new one. You may need to tweak this command some if you already have other custom entries New-RoleAssignmentPolicy -Name DenyForwardingRoleAssignmentPolicy -Roles DenyForwarding, MyContactInformation, MyRetentionPolicies,MyMailSubscriptions,MyTextMessaging, MyVoiceMail,MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation 4.) Lastly, assign your policy to your cloud mailboxes Set-Mailbox –Identity user@contoso.com -RoleAssignmentPolicy DenyForwardingRoleAssignmentPolicy The result (if all of the CMDlets were used): Note: since this article was written, we have heard a question on blocking emails forwarded by Power Automate (Flow). To learn about that, please seeEmail exfiltration controls for Office 365 connectors. What do I suggest? How restrictive do you want to be? What are you worried about in your environment? There’s no one size fits all option. You can implement all three options if you really want. Personally, I like the combination of transport rule + RBAC. This combination covers all bases, yet still allows for exceptions if necessary. In that setup, the forwarding options in Outlook on the Web are completely removed, and if a forwarding Inbox rule in Outlook is created, messages can be blocked with an informational Non-delivery report back to the user. Special thanks to Ben Winzenz and Tim Heeney for their assistance and review of this content. Alana WegfahrtAutomatic Processing of Recurring Meeting Requests with Conflicting Instances
The behavior of the Resource Booking Attendant may seem confusing when it comes to processing a recurring meeting request where individual recurrences conflict with existing calendar items. Some administrators have tried working with calendar processing settings in the hopes of allowing double booking rooms with recurring meetings, as can be done with non-recurring meeting requests. As we'll see, double-booking a room with recurring meetings and the Resource Booking Attendant is impossible. If anyone's still confused hopefully this post will clear up what's going on. Recurring meeting request processing is handled according to the settings from Set-MailboxCalendarSettings in Exchange 2007 and Set-CalendarProcessing in Exchange 2010. Since each version uses the same options to deal with recurring meeting requests, let's use the Exchange 2010 SP1 documentation for Set-CalendarProcessing: Parameter Description ConflictPercentageAllowed The ConflictPercentageAllowed parameter specifies the maximum percentage of meeting conflicts for new recurring meeting requests. Valid input for this parameter is an integer from 0 through 100. If a new recurring meeting request conflicts with existing reservations for the resource more than the percentage specified by the ConflictPercentAllowed value, the recurring meeting request is automatically declined. When the value is 0, no conflicts are permitted for new recurring meeting requests. MaximumConflictInstances The MaximumConflictInstances parameter specifies the maximum number of conflicts for new recurring meeting requests when the AllowRecurringMeetings parameter is set to $true. Valid input for this parameter is an integer from 0 through 2147483647. If a new recurring meeting request conflicts with existing reservations for the resource more than the number of times specified by the MaximumConflictInstances value, the recurring meeting request is automatically declined. When the value is 0, no conflicts are permitted for new recurring meeting requests. When active, these two settings apply to whether Exchange accepts a recurring meeting request in its entirety, the whole series, but not whether individual instances are accepted. Individual recurring meeting instances are always declined. Examples So, for example, say a room mailbox is configured with the following settings: AutomateProcessing : AutoAccept AllowConflicts : False AllowRecurringMeetings : True ConflictPercentageAllowed : 40 MaximumConflictInstances : 6 A recurring meeting request which repeats 10 times (10 instances) is sent to the mailbox. Now let's suppose 5 out of 10 (or half) of the instances for that recurring meeting occur at the same time other meetings are scheduled in the calendar. In this case, the 50% conflict ratio exceeds the ConflictPercentageAllowed setting of 40. The result: The entire meeting request is rejected and the room sends a message back to the meeting organizer with the subject Declined All. The five conflicting instances are declined, as are the other five instances that didn't conflict with another meeting. Another meeting request is sent where there are 100 instances of a recurring meeting and 10 of them conflict with existing bookings. In this case the ConflictPercentageAllowed is not exceeded by the 10% conflict rate. However, we exceed the MaximumConflictInstances setting of 6. The result: Once again, the entire meeting request is rejected and all 100 instances are declined. For our last example, a recurring meeting request comes to this room where there are 10 instances and only 2 of them conflict with existing bookings. The result: Since we don't exceed either MaximumConflictInstances or ConflictPercentageAllowed, the room mailbox accepts the recurring meeting request series but declines to book the two instances that conflict. The meeting instances that don't conflict are accepted and booked and the room sends three emails back to the organizer, one with Accepted in the subject stating the recurring meeting request was accepted, and two with Declined in the subject for the two conflicting instances. So by these examples we see how a recurring meeting request with conflicting instances can be accepted or declined based on the calendar processing settings. However, it's important to repeat that a recurring meeting request instance that conflicts with another booking is ALWAYS declined. How all the settings work together Now I'd like to touch lightly on how all the settings that affect recurring meeting request processing work together, including the above discussed ConflictPercentageAllowed and MaximumConflictInstances, along with the AutomateProcessing, AllowConflicts, and AllowRecurringMeetings settings. AutomateProcessing: Must be set to AutoAccept to allow automatic booking of any meeting requests, recurring or not. Note, the default is AutoUpdate. AllowRecurringMeetings: Set to True by default. If it's changed to False, all recurring meeting requests are rejected. AllowConflicts: The parameter determines whether conflicting meeting requests are allowed. If set to True, sets the calendar to ignore the ConflictPercentageAllowed and MaximumConflictInstances settings. In this case, the calendar accepts all recurring meeting requests. Conflicting instances are always declined, but the number or percentage of conflicting instances don't have any impact on the entire series. If set to False (the default), we must turn to ConflictPercentageAllowed and MaximumConflictInstances to decide whether the entire recurring meeting request series is declined or not. This flowchart presents how a recurring meeting request is processed based on these settings. Figure 1: How recurring meeting requests are processed So what if an administrator wants the ability to double book a room? What alternatives are there? Use non-recurring meetings for instances that conflict. Set the mailbox to be managed by a delegate instead of the ResourceBookingAttendant alone. A delegate could then allow double-booking of conflicting recurring meeting instances. To summarize, a recurring meeting request with conflicting instances can be accepted or declined based on the calendar processing settings for the mailbox, which are configured using the Set-CalendarProcessing (Exchange 2010) or Set-MailboxCalendarSettings (Exchange 2007) cmdlets. However, individual instances of the recurring meeting request that conflict with another calendar item are ALWAYS declined. Thanks to Kristi Starr, Chris Korff, and Tom Kern for assistance with this material. Jesse Tedoff
