Lessons Learned and Best Practices for Autodiscover in a Hybrid Environment

Outlook uses the Autodiscover service to get real-time connection information for your mailbox and any other mailbox you connect to. Without Autodiscover you may be able to get Outlook to connect, but it won't connect correctly. For example, Exchange Web Services (EWS) connectivity in Outlook can only be made using Autodiscover.

Outlook normally performs Autodiscover requests when you setup a mail profile for the first time and from then on, periodically in the background. This is how automapped shared mailboxes get automatically added to Outlook. Outlook also runs an Autodiscover request when your mailbox moves between servers or databases, as when a failover event occurs. Autodiscover is also used whenever you check free/busy availability of another user's calendar.

Domain-joined computers in an Exchange Server or hybrid environment normally use a Service Connection Point (SCP) published in Active Directory to get the URI Outlook should use for Autodiscover requests. This is set using the Set-ClientAccessService -AutoDiscoverServiceInternalUri <value> cmdlet in the Exchange Management Shell (EMS).

There's a lot of documentation in the web that says you should set the AutoDiscoverServiceInternalUri value to $null after a hybrid migration is complete. But is that the right thing to do?

It's a long answer, so strap in. 😉  Tl;dr at the end.

First, know that Autodiscover behavior changes depending on the Outlook client and build version, as well as possible non-standard registry settings.

Microsoft 365 Apps for Enterprise always tries https://outlook.office365.com/autodiscover/autodiscover.xml first (Autodiscover-V2) regardless of your DNS settings. Microsoft's assumption is that if you’re running that version, your account is probably in the cloud. If your mailbox is indeed in EXO, that process looks like this and only takes 1-2 seconds:

Autodiscover-V2 will fail if your account is missing in EXO or not migrated yet and Outlook will then start the regular Autodiscover-V1 process. Note that the Autodiscover-V2 process can also be skipped with the following reg key. I see this often in older enterprise environments.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

Office 2016/2019 clients normally only do the regular Autodiscover-V1 process, which is well known:

1. Check for Local Data preference (configured via GPO to use an autodiscover.xml file stored locally on the computer)
2. Check for Last Known Good (LKG) cached data
3. Some later builds use heuristics to determine if the user account comes from Azure AD and will check against https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml 
4. SCP (see *notes below)
5. DNS
• Root domain (https://contoso.com/autodiscover/autodiscover.xml, which nearly always fails)
• Autodiscover URI (https://autodiscover.contoso.com/autodiscover/autodiscover.xml)
6. HTTP redirect
• http://autodiscover.contoso.com/autodiscover/autodiscover.xml
7. SRV
• Value from _autodiscover._tcp.contoso.com 443 0 0 in DNS

*Note that the SCP process won't work in several scenarios:

• The computer is not domain-joined
• SCP is $null
• SCP is not available via LDAP because the domain-joined machine is disconnected from the DC
• Registry keys can, and most often will, override the default Autodiscover behavior

Here’s what the process looks like for an M365 mailbox user in a hybrid environment from a domain-joined computer on the LAN. The SCP is set to https://autodiscover.contoso.com/autodiscover.autodiscover.xml (the on-prem Exchange Server). This process took 52 seconds to complete. Remember, this is the same process that Outlook goes through when creating a new mail profile, too.

When the SCP is set to $null it skips the first five lines, but execution time is nearly the same. It gets there, but it's not efficient and takes a really long time.

If we set the SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, the process only takes about 1 second.

As you can see, setting the SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml is much more efficient than setting it to $null when the migration is complete.

Tl;dr:

The Service Connection Point (SCP) is set using the Set-ClientAccessService -AutoDiscoverServiceInternalUri <value> cmdlet.

• If you're a hybrid customer and you still have mailboxes on-premises that use Outlook:
• Set your SCP to https://autodiscover.contoso.com/autodiscover/autodiscover.xml.
• Create an A record for autodiscover.contoso.com in internal and external DNS resolving to on-prem Exchange for computers that can't reach AD.

• If you're a hybrid or cloud customer and all mailboxes that use Outlook or in EXO:
• Use Microsoft 365 Apps for Enterprise, which always checks EXO first. It also provides the best experience, features, and performance for cloud mailboxes.
• If you're hybrid, set your SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml.
• Create a CNAME record for autodiscover.contoso.com in external DNS resolving to autodiscover.outlook.com. This way, older clients that don't use Autodiscover-V2 will use the HTTP redirect method to get to EXO.

Read more ...

CHANGE LOG: View Quarantine add-in for Outlook

View Quarantine add-in for Outlook Change Log

---

Please see How to install an Outlook add-in to view the Microsoft 365 End-User Quarantine for a full description and installation instructions.

---

Version 1.0.0.0: Microsoft won't certify my add-in because they say it "does not provide significant value or benefits to commercial marketplace customers". I think most of you will disagree. I'll keep trying to get it certified, but in the meantime you can always install it from my website using the procedures from my blog article.

Version 1.0.1.0: Added automatic localization for 37 languages. Reinstall the add-in to if you need one of these languages. Please let me know if my translations need adjustments.

Version 1.1.1.0 : Added new manifest.xml (option 1) and ZIP file (option 2) deployments for GCC (Government Cloud) and GCC High (Government Cloud High) tenants.

Read more ...

Install an Outlook add-in to view the Microsoft 365 End-User Quarantine

This article explains how to install an Outlook add-in called View Quarantine that will open the Microsoft 365 end-user quarantine in a browser with a single click. This makes it really easy to access the quarantine directly from Outlook. And since this is a true Office add-in, it also displays and works in Outlook mobile and Outlook on the web!

I'm happy to announce that the add-in now also works with Microsoft Government Community Clouds (GCC and GCC High)! View the change log for status and feature updates.

The add-in shows in the Outlook ribbon when viewing any folder that contains mail items. 

The View Quarantine add-in for Outlook

Simply click the button to open the Microsoft Defender Online end-user quarantine in your default browser. You may need to sign-in to view the quarantine.

The Microsoft 365 end-user quarantine

I originally built this add-in using the Build your first Outlook add-in - Office Add-ins documentation. This gave me a good head start to build and customize the add-in.

The add-in consists of three files plus icons in various sizes for the different platforms.

Source File	Description
commands.html	An HTML "wrapper" that calls the JavaScript used by the add-in when the button is clicked.
commands.js	The JavaScript functions that provide status and open the end-user quarantine in a browser.
manifest.xml	The real heart of the add-in. It defines the unique ID for the add-in and describes when to display the View Quarantine button and how the add-in functions.
assets folder	Contains six icon files of different sizes and opacity for Outlook, OWA, and Outlook mobile.

I'm currently in the process of publishing this add-in to the AppSource marketplace via the Microsoft Partner Center. Please see the change log. In the meantime, there are two ways you can install the View Quarantine add-in now.

Option 1 -- Install via the Web

You can install the add-in from my website until Microsoft publishes it on AppSource.

• Open Outlook and click the Get-Add-ins button in the ribbon. Alternatively, click File and click the Manage Add-Ins button at the bottom.
• Click My add-ins in the top left.
• Click the + Add a custom add-in dropdown at the bottom of the window under Custom add-ins, then select Add from URL...
• Enter the following URL: https://www.expta.com/quarantine/manifest.xml and click OK.
• If your mailbox is in a GCC tenant use the following URL: https://www.expta.com/quarantine-gcc/manifest.xml
• If your mailbox is in a GCC High tenant use the following URL: https://www.expta.com/quarantine-gcch/manifest.xml

• You will see a warning before installation. Click Install to install the add-in.

• The add-in will now be listed under Custom add-ins. Note: To remove the View Quarantine add-in at any time, click the ellipses (...) and select Remove.

• Close the Add-ins window to add it to the Outlook ribbon.

Option 2 -- Install from Source Files

You can also install the add-in using the manifest.xml file in my source files.

• Download the correct source files from my website:
• View Quarantine for most world-wide tenants
• View GCC Quarantine if your tenant is GCC
• View GCC-High Quarantine if your tenant is GCC High
• Extract the ZIP file to a local drive or network share.

• Open Outlook and click the Get-Add-ins button in the ribbon (shown above).
• Click My add-ins in the top left.
• Click the + Add a custom add-in dropdown at the bottom of the window under Custom add-ins, then select Add from file...
• Browse to the manifest.xml file and click Open.
• You will see a warning before installation. Click Install to install the add-in.

• The add-in will now be listed under Custom add-ins.

• Close the Add-ins window to add it to the Outlook ribbon.

Deploying to All Users in the Organization

Once you're satisfied that the add-in is installed and working properly, you can deploy it to all users in your organization. Here's how to do that:

• Open the Microsoft Admin Center and navigate to Settings > Integrated Apps > Add-Ins.
• Click Deploy Add-In and Next.
• Click the Upload Custom Apps button.
• Select I have a URL for the manifest file and enter one of the following URLs:
• For standard M365 use https://www.expta.com/quarantine/manifest.xml
• For GCC use https://www.expta.com/quarantine-gcc/manifest.xml
• For GCC High use https://www.expta.com/quarantine-gcch/manifest.xml
• Select whether to install the add-in for everyone or specific users.
• Select a Deployment Method.
• Fixed (Default). The add-in will be automatically deployed to the assigned users and they will not be able to remove it from their ribbon.
• Available. Users may install this add-in by clicking the Get More add-ins button on the home ribbon in Outlook and going to Admin-managed.
• Optional. The add-in will be automatically deployed to the assigned users but they can choose to remove it from their ribbon.

I hope you enjoy this free Outlook add-in and you find it useful!

Read more ...

Send as SMTP alias is now available in Exchange Online

One of the longest running user requests is finally a reality. Users can finally send emails as one of their alias SMTP addresses. At least they can in Exchange Online in Microsoft 365. We'll need to wait and see if this comes to on-premises Exchange Servers. I can't imagine why it wouldn't, but it will probably only come to Exchange 2019 in a future CU or Exchange Server vNext.

UserVoice may no longer exist, but ancient stone tablets have been unearthed that show this has been requested by users for a long, long time.

Exchange Admins can assign alternate email addresses, or aliases, to user mailboxes. Users can receive emails for any of their aliases, but up till now, emails and replies can only be sent using their primary SMTP email address.

With the new behavior, emails sent using one of their aliases show the From address and the Reply-To address as the alias SMTP address that's being used. And there was much rejoicing.

You enable Send From Alias using Exchange Online PowerShell. Simply run the following cmdlet:

Set-OrganizationConfig -SendFromAliasEnabled $true

Once set, users can send emails using one of their configured alias addresses in Outlook or OWA.

To do this in Outlook, the user must first show the From field for new emails using the Options menu. Then they can pick an alias address they've previously used or click Other Email Address and type in the one they want to use.

To do this from Outlook on the web, create a new message, click the (...) ellipses, and click Show From. Then type the email alias you want to use for the new email.

Emails will be delivered to recipients showing the user's full name and the From email address:

If we examine the SMTP headers we see that the From address and the Return-Path values are using the specified alias.

It's important to have valid SPF, DKIM, and/or DMARC records set for the alternate alias' domain to ensure delivery can be made. This is an important consideration with customers in merger and acquisition scenarios.

In my testing I found that when the user receives emails or replies to the alias, Outlook always replies from the primary email address. The user will need to manually change the From address if they want to "continue the lie". Hopefully, this will be fixed in the future.

Read more ...

Important Outlook Connectivity Update for Microsoft 365

Here we go again.

It appears that Microsoft going to actively block connectivity for older versions of Outlook on November 1, 2021 -- less than 11 months from now. 

Previously, Outlook connectivity has always been best effort for older versions, meaning that if you can connect to Microsoft 365 with an older non-supported version, then great. If you can't connect, you are required to install a supported version.

The reasoning for this is noble - Microsoft doesn't want older less secure versions of Outlook to connect to the service. Most Office 365/Microsoft 365 customers are already running Microsoft 365 Apps for enterprise (aka Office ProPlus) which is always up-to-date, so no problem.

But future Microsoft 365 and hybrid customers will need to upgrade all their clients prior to migration, and a lot of enterprises won’t be able to update in that time.

The bottom line is, if your clients are not already running Microsoft 365 Apps for enterprise and you plan to migrate to Microsoft 365, you need to start upgrading your Office apps now.

Here is the notification from Microsoft:

Update to Microsoft 365 and Outlook for Windows connectivity

MC229143

 

	Major update: Announcement started
	Applied To: All

 

To ensure that we meet performance expectations, we are updating the supported versions of Outlook for Windows that can connect to Microsoft 365 services.  Effective November 1, 2021, the following versions of Outlook for Windows, as part of Office and Microsoft 365 Apps, will not be able to connect with Office 365 and Microsoft 365 services.  Office and Microsoft 365 Apps Outlook for Windows Version Office 2013 15.0.4970.9999 and older Office 2016 16.0.4599.9999 and older Microsoft 365 Apps for enterprise (formerly Office 365 ProPlus) 1705 and older Microsoft 365 Apps for business (formerly Office 365 Business) 1705 and older [Key Points:] Major: Retirement Timing: November 1, 2021 Action: Ensure Outlook for Windows client are updated accordingly [How this will affect your organization:] Versions that are newer than minimum version requirements listed above, but are not the currently supported version, may experience connectivity issues. To see a list of the currently supported versions, visit Update history for Microsoft 365 Apps (listed by date)(for Microsoft 365 Apps) or Latest updates for versions of Office that use Windows Installer (MSI)(see “Latest Public Update” for Office 2013 and 2016). Supported versions of Outlook for Windows in Office and Microsoft365 will continue to connect to Microsoft 365 services as expected.   [What you need to do to prepare:] We recommend that all users upgrade to the supported versions of Office and Microsoft 365 Apps.

Read more ...

Recap of Exchange and Outlook News for Microsoft Ignite 2020

I wrote up a recap of the exciting Exchange and Outlook news and announcements from Microsoft Ignite 2020.

There were a number of important announcements and quite a bit of technical content published on-demand. Most of it is still available on the Virtual Hub. Read all about it on the Enow Software blog.

Read more ...

Roaming Signatures Update for Outlook for Windows

Microsoft announced that it will be rolling out roaming signatures soon in Outlook for Windows. It's expected that this feature will come to Exchange Online for now. Customers using third-party signature solutions will want to prepare for this. Review Outlook roaming signatures options.

(Updated) Outlook for Windows Introduces Roaming Signatures

MC215017, Plan For Change, Published date: Jun 2, 2020

Major update: Announcement

Applies To: All

This message is associated with Microsoft 365 Roadmap ID 60371

When this will happen

We will begin rolling this out to Microsoft 365 Monthly Channel, Targeted, in late September (previously July). (This is Insiders Slow Channel which will soon be called Microsoft Beta.)

We expect to roll this out to the Monthly Channel, Production, in late October (previously August).

How this will affect your organization

The feature is on by default.

Traditionally, signatures were stored locally on a user's Windows device. With this feature, signatures will now be associated with an email account.

Signatures will be stored in the user mailbox and will be available on any devices running Outlook for Windows that has been configured with that email account.

When the feature becomes available, Outlook will read the existing local signatures. Outlook will copy signatures selected as default for New messages or Replies/forwards to the account mailbox, making them available across multiple devices.

What you need to do to prepare

The feature is on by default.

Because this new feature is changing how Outlook manages signatures stored on a local drive, third-party add-ins which provided this functionality will no longer work when this feature is enabled. Learn how to mitigate this for your users.

I know a lot of customers like me are looking forward to this update!

Read more ...

Roaming Signatures coming to Outlook for Windows

Read more ...

Make a clickable link for Teams chat in Outlook or a website

Here's a handy tip on how to make a one-click link that opens a Teams chat to you or someone else.

Simply use the following URL for the hyperlink:

http://teams.microsoft.com/l/chat/0/0?users=someone@domain.com

For example, I use a  Teams icon in my Outlook signature that opens a Teams chat to me.

The link will open a web page where the user will sign-in with their Microsoft account. If the Teams app is installed on the client's computer, the web page will offer to open the chat in the Teams client, otherwise they can use the Teams web browser experience.

Teams launcher in browser

Teams chat in a browser

Read more ...

Progress on syncing Outlook signatures

Microsoft is finally making progress on storing your Outlook signature in the cloud. Strong emphasis on "cloud" -- I don't expect this to come to Exchange Server on-premises anytime soon, if at all.

Unifying the Outlook signature experience so users don't need to setup their signature every time they use a new device is the number 1 most voted request in UserVoice.

According to this Microsoft 365 Roadmap notice, we should start seeing it in February 2020!

Read more ...

Syncing Email Signatures Across Devices is soon to become a reality!!

Will wonders never cease. Just when I was convinced that Outlook UserVoice was the place where all good ideas go to die, I received the following update:

"Thank you to everyone who voted. We’re happy to report that we’re working on sync’ing signatures across devices. More details to come as we have them.

Sincerely,
Ricardo, Duncan, Sunder and David on behalf of the Outlook team"

After I posted the article, "Storing email signatures in the Exchange mailbox" on this blog, this UserVoice request became the top voted request on the Outlook UserVoice website by a wide margin, with over 7,915 votes. It has more than twice the number of votes than the #2 most voted item. Thank you to all of you who voted!

This new feature will undoubtedly come to Office 365 ProPlus customers first, so if you're hot on seeing it, make sure you're using the latest and greatest version of Outlook. I'll let you know when the new feature lands.

Read more ...

HCW Organization Configuration Transfer breaks Outlook connectivity to Office 365

5/16/2019 Update -- The latest version of the HCW (version 16.0.3054.9 ) no longer syncs the OAuth2ClientProfileEnabled property, which caused the issue. Thanks to the Exchange product group for fixing this so quickly.

Recent versions of the Office 365 Hybrid Configuration Wizard (HCW) offer a feature called Organization Configuration Transfer, which is documented here. Organization Configuration Transfer (OCT) copies the organization policy objects from on-premises to Exchange Online (EXO), and updates values in EXO with the values from on-premises.

OCT is an option when running the HCW, not a requirement. It is designed to reduce the number of policies and objects that need to be configured in EXO by copying them from on-prem. Admins can also occasionally re-transfer settings using OCT in order to update EXO with new or updated on-prem policies and configurations.

OCT was updated to OCT-V2 on November 2018 to include several additional objects that were not previously synced, including the Organization Config object. This poses a problem if your on-prem environment is not configured for hybrid modern authentication because it will turn off access to EXO from Outlook and Skype for Business. This happens when the OCT overwrites the OAuth2ClientProfileEnabled property using Set-OrganizationConfiguration. On-prem environments without hybrid modern auth have this property set to false, where online it is always true (unless you want to deny modern auth).

Review the objects that OCT will transfer

The OCT will update the OAuth2ClientProfileEnabled property to FALSE

Turning the OAuth2ClientProfileEnabled property to false disables modern authentication for clients like Outlook and Skype for Business, and users will be continuously prompted for authentication and will be unable to connect to Exchange Online. Hilarity does not ensue.

This happened in my own environment. I discovered using Admin Audit Logging that the OAuth2ClientProfileEnabled property in the Organization Config was set to false the Friday before the problem started on Sunday morning. That date/time corresponded to the HCW logs. I had re-run the HCW and the Org Transfer Friday afternoon, which set the property to false.

Fiddler showed the same error described in the Auth_URI Failures section of the HMA article (https://blogs.technet.microsoft.com/exchange/2017/12/06/announcing-hybrid-modern-authentication-for-exchange-on-premises/):

HTTP/1.1 401 Unauthorized

Cache-Control: private​

Server: Microsoft-IIS/10.0​

request-id: 3e5472dd-320e-4378-85e1-e22f00b53d38​

X-CalculatedBETarget: dm6pr04mb6185.namprd04.prod.outlook.com​

X-RUM-Validated: 1​

X-UserType: Business​

x-ms-diagnostics: 4000000;reason="Flighting is not enabled for domain 'cloud@expta.com'.";error_category="oauth_not_available"​

X-DiagInfo: DM6PR04MB6185​

X-BEServer: DM6PR04MB6185​

X-AspNet-Version: 4.0.30319​

Set-Cookie: X-BackEndCookie2=cloud@expta.com=u56Lnp2ejJqByMzPms7OyJ3Sz5rNntLLnczJ0sbMz8rSm5qdm8vOy8uezcmegcfMycrGmc3L0sjMx5vSy8/JnNLHnpzM0prMypnMzcabz5vPxoHNz87G0s/K0s3Gq83NxcrIxcvMgZGeko+Nm8/L0Y+NkJvRkIqLk5CQlNGckJKBzw==; expires=Wed, 29-May-2019 22:57:43 GMT; path=/autodiscover; secure; HttpOnly​

Set-Cookie: X-BackEndCookie=cloud@expta.com=u56Lnp2ejJqByMzPms7OyJ3Sz5rNntLLnczJ0sbMz8rSm5qdm8vOy8uezcmegcfMycrGmc3L0sjMx5vSy8/JnNLHnpzM0prMypnMzcabz5vPxoHNz87G0s/K0s3Gq83NxcrIxcvMgZGeko+Nm8/L0Y+NkJvRkIqLk5CQlNGckJKBzw==; expires=Wed, 29-May-2019 22:57:43 GMT; path=/autodiscover; secure; HttpOnly​

X-Powered-By: ASP.NET​

X-FEServer: BYAPR02CA0010​

WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@*", token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https://login.windows.net/common/oauth2/authorize", error="invalid_token",Basic Realm=""​

Date: Mon, 29 Apr 2019 22:57:42 GMT​

Content-Length: 0​

Tenants who have modern authentication enabled in EXO or any tenant created after August 2018 would normally have this enabled.

To easily check if this is affecting your Exchange Online environment run the following cmdlet in EXO PowerShell:

(Get-OrganizationConfig).OAuth2ClientProfileEnabled

Tenants who have modern authentication enabled in EXO or any tenant created after August 2018 would normally have this value set to True. If it isn't, run the following cmdlet:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Note that it takes up to 30 minutes before the change becomes effective.

I've been working with the product team to remove this property transfer from OCT, since no one can think for a good reason for this property to sync in the first place. In the meantime, if you use OCT in the HCW you should remove the checkbox for Organization Config on the right-hand side.

Read more ...

Enable Outlook Automapping for Exchange mailboxes

When a user is delegated full access rights to another mailbox, automapping will automatically add that mailbox to that user's Outlook. Automapping does this when Outlook runs a background autodiscover process and discovers that the user has been given full access to another mailbox. The user doesn't need to add the mailbox manually to Outlook and will be unable to remove the additional mailbox.

Automapping is enabled by default, but it can be disabled by running the following cmdlet:

Add-MailboxPermission TeamMailbox -User kmeyer -AccessRights FullAccess -AutoMapping $false

The cmdlet above gives user Ken Meyer full access to the TeamMailbox mailbox and disables automapping for that mailbox.

I published the Enable-AutomappingForFullAccessMailboxes.ps1 script for Exchange in the Microsoft Script Center Gallery. The script re-enables Outlook automapping on mailboxes where users have been given full access rights. It runs on Exchange 2010-2019 and Exchange Online, and must be run from the Exchange Management Shell (EMS).

Read more ...

Introducing the OME Test Tool

tldr; Send an email to OMETest@expta.com and the service will respond with an email encrypted by Office 365 Message Encryption. If your test email includes an attachment, that attachment will be included in the OME encrypted response as an encrypted attachment. Use this service to test how encrypted emails are handled by your email clients and mobile devices.

The well-intentioned folks over at Microsoft are doing it again, but you know what they say about the road to hell...

In late December message ID MC170958 showed up in the Office 365 Message Center entitled, "New Office 365 Message Encryption policy for sensitive information." This feature is intended to keep user emails that contain sensitive information safe by automatically encrypting them. This will be done by creating a new Exchange mail flow rule in your tenant to use Online Message Encryption (OME), which was recently renamed to Office 365 Message Encryption.

Message Center ID MC170958

The Message Center notice included a link to https://docs.microsoft.com/en-us/office365/securitycompliance/new-ome-encryption-policy, but that link no longer works for most users. Perhaps Microsoft is rethinking this, but it still shows in the Message Center for some customers.

While the idea of keeping users from doing something stupid is a noble one, to me this reeks of Skynet. I really don't like the idea of anyone or anything inserting logic and a new business process into my emails and mail flow. What if my emails to customers start being encrypted because my item numbers resemble a bank account number? What if I have a complex transport configuration?

It's easy enough to opt-out of this change by running Set-IRMConfiguration -AutomaticServiceUpdateEnabled $false, but shouldn't I really have to opt-in instead of opt-out?

January 25 UPDATE: Microsoft has indeed rethought this a bit. They will still be creating the OME transport rule, but it will not be enabled by default:

Updated Message Center Notification

I'm sure automation like this might help small customers who don't have the time or skills to properly manage and secure their infrastructure, but for enterprise customers this could be a real disaster. OME encrypted emails require the recipient to authenticate with a Microsoft account to read them. Despite what Microsoft thinks, not everyone has (or wants) an account with them or uses Microsoft Office. This causes a barrier that a lot of email recipients will find difficult. It should be noted that one-time passwords are also supported. Read Microsoft Plans to Launch Automatic Email Encryption for Office 365 Tenants for Tony Redmond's take on this.

I created an OME test service in Office 365 that you can use to test the end-user experience of receiving an OME encrypted email. Simply send an email to ometest@expta.com. In a short while the service will automatically respond with an encrypted message. If you include an attachment with your email, that attachment will also be returned in the OME message as an encrypted attachment.

Note: The OME test service will not respond to messages that contain ": " in the subject. This prevents mail loops caused by rules that automatically reply or forward messages.

You should test access to this encrypted email from Outlook or any desktop email app, your mobile device, and your web browser to see how each client handles OME encrypted emails. You may be required to create a free Microsoft ID to view it.

You'll notice that you cannot preview OME encrypted emails in the Outlook preview pane. They must be opened to view them.

OME encrypted emails cannot be viewed in the preview pane

Outlook will attempt to download a rights management service user license to make the reading experience fairly straightforward, assuming you're signed into Office 365. Other email clients will be more cumbersome and recipients without a Microsoft account will need to sign up for one to read the email. Honestly, I can't imagine my parents having to deal with this from their mobile phones.

This is what an OME protected email looks like on an iPhone

I use the native Apple mail client, not the Outlook app. If you're like me, you have more than one email account on your mobile device. When you click "Read the message" you'll need to authenticate with the same email address it was sent to - something that may not be readily apparent from an "All Inboxes" view, like on the iPhone. If you use the wrong account you get an unhelpful "The item was not found" error.

Once you successfully sign-in to Office 365 you can view, reply, or forward the email via OWA. If you use the Outlook app for iOS or Android, your experience will be better.

This is the OME encrypted email

I hope you find that the OME tester utility is useful. Please let me know if you have any issues.

Reference:

• https://docs.microsoft.com/en-us/office365/securitycompliance/ome
• https://docs.microsoft.com/en-us/office365/securitycompliance/ome-faq

Read more ...

Outlook 2016 support in Office 365 after Oct 13, 2020

UPDATE, Sept. 6: Microsoft has updated its Office support statement. Read Helping customers shift to a modern desktop:

Office 2016 connectivity support for Office 365 services
In addition, we are modifying the Office 365 services system requirements related to service connectivity. In February, we announced that starting October 13, 2020, customers will need Office 365 ProPlus or Office 2019 clients in mainstream support to connect to Office 365 services. To give you more time to transition fully to the cloud, we are now modifying that policy and will continue to support Office 2016 connections with the Office 365 services through October 2023.

---

What a difference a word makes.

On April 20, 2017 the Office Blog wrote an article about Office 365 system requirements changes for Office client connectivity. It references the updated System Requirements for Office, which states:

“Effective October 13th, 2020, Office 365 will only allow Office client connectivity from subscription clients (Office 365 ProPlus) or Office perpetual clients within mainstream support to connect to Office 365 services. (Please refer to the Microsoft support lifecycle site for Office mainstream support dates.)”

The blog says this "will make it easier for enterprises to deploy and manage Office 365 ProPlus". Perpetual clients is the term for traditional MSI-installed Office, usually from media or a UNC share.

The problem is the word "allow" should be "support". "Allow" implies that Microsoft will actively block all connectivity from Office clients that are not in mainstream support. According to the Microsoft Lifecycle Policy, Microsoft Office 2016 mainstream support ends 10/13/2020.

Even the beginning of the System Requirements for Office is at odds with the statement above. It says:

"Office 365 is designed to work best with Office 2016, Office 2013, and Office 2016 for Mac. Previous versions of Office, such as Office 2010, Office 2007, and Office for Mac 2011 may work with Office 365 with reduced functionality."

This is the traditional support statement we've seen for years. You can continue to use legacy versions of Office with Office 365, you just can't get support for it. If it works, great. If it doesn't, upgrade.

Of course, Microsoft's and my own recommendation is to use the latest and greatest versions of Office. In particular, you should be using Office 365 ProPlus, especially for users who use Office 365. But there are a lot of enterprise and SMB customers who still buy Office using perpetual licenses. They like the fact that they own it and don't have to pay for a monthly subscription per user. Some hybrid customers have a large number of seats on-prem, without having to pay for Office 365 ProPlus licenses for these users. Some SMB customers have Office 365 plans that don't include Office 365 ProPlus.

Recently, I've heard from customers that Microsoft Office 365 Support is telling them that Office 2016 won't be able to connect to Office 365 after October 13, 2020 and are referencing this support statement. That's heavy-handed fear mongering and it has to stop.

I'm currently in conversations with the Exchange product group about the new support statement. We agree that the word "allow" should be changed to "support", but they don't control the website or message - the Office Team does. We're still in talks, trying to get the word changed. I'll let you know here how that goes...

Read more ...

Cross-Premises Mailbox Delegation in Hybrid Office 365

Exchange hybrid organizations commonly ask about delegating mailbox permissions between on-premises and cloud users. I'm happy to say that this is finally becoming a reality. This is being rolled out to all Office 365 tenants by the end of April 2018.

Gone are the days when you had to migrate users with delegated permissions at the same time to keep delegation working when migrating to Exchange Online. To enable cross premises delegation you first need to configure it in Exchange on-premises EMS with the following cmdlet:

Set-OrganizationConfig -ACLableSyncedObjectEnabled $true

This is all you need to allow an on-prem user to become a delegate of a cloud user's mailbox.

If you want to allow a cloud user to become a delegate of an on-prem user, you need to reconfigure the msExchRecipientDisplayType attribute for the remote user in on-prem AD. This will allow the cloud user's mailbox to become ACLable. The default value on-prem for a mailbox that has been migrated to Exchange Online is -2147483642. This value must be changed to -1073741818.

The following on-prem cmdlet will change the value for a particular mailbox:

Get-ADUser user@contoso.com -Properties msExchRecipientDisplayType | where {$_.msExchRecipientDisplayType -eq -2147483642} | Set-ADUser -Replace @{msExchRecipientDisplayType = -1073741818}

And this cmdlet will change the value for all migrated mailboxes:

Get-ADUser -Filter * -Properties msExchRecipientDisplayType | where {$_.msExchRecipientDisplayType -eq -2147483642} | Set-ADUser -Replace @{msExchRecipientDisplayType = -1073741818}

Once this is done, the cloud users can become a delegate for on-prem users. Note that there is no need to force directory replication using AAD Connect. It just works. Note that it may take up to two hours before Office 365 recognizes the change.

Here's how this looks in Outlook. First, I'll show how it looks before I run the cmdlets.

Begin by clicking File in Outlook and then Account Settings > Delegate Access. This will open the Delegates dialog box.

Remote user is not ACLable

Click Add to open the Add Users window. Notice that my Jeff Guillet account has a red circle with a line through it. That means my mailbox is not ACLable. If I try to delegate to that mailbox I get the error, "The user cannot be added. Non-local users cannot be given rights on this server."

After I run the cmdlets above, I follow the same steps. Now my Jeff Guillet user account can be added for delegation.

Remote user is now ACLable.

I can now configure the level of delegation and optionally send the delegate an email summarizing these permissions.

For details on Full Access, Send-As, and Send-On-Behalf-Of permissions in a hybrid environment, please read Overview of delegation in an Office 365 hybrid environment.

Read more ...