Showing posts with label Exchange Online. Show all posts
Showing posts with label Exchange Online. Show all posts

The Future of Exchange Server

Tuesday, September 10, 2024

Microsoft published an important new article today detailing some of the requirements and recommendations for upgrading Exchange Server to the latest version, Exchange Server SE (Subscription Edition). Upgrading your organization from current versions to Exchange Server SE - Microsoft Community Hub

This article applies to all customers running Exchange Server on-premises, including hybrid customers using Exchange Server for hybrid management.

The blog post is dense with a lot of information, but the key important points are:

  • Exchange Server SE is the next version of Exchange Server and will be released the second half of 2025.
  • Exchange 2019 CU15 will be released Q4 this year. This will be the last cumulative update for Exchange 2019. There will be no future updates for Exchange 2016.
  • Exchange 2019 CU15 will allow for an in-place upgrade to Exchange Server SE. This is a first for Microsoft. Previous upgrades required new servers.
  • Exchange Server SE will only allow coexistence with Exchange 2016 CU23 and Exchange 2019 CU14/15.
  • Exchange 2013 will become totally unsupported with the release of Exchange 2019 CU15. You must upgrade or remove Exchange 2013 from your organization ASAP.
  • Customers should upgrade their Exchange 2016 servers to Exchange 2019 CU14/15 ASAP to prepare for Exchange Server SE.
  • After Exchange Server SE is released in 2025, Exchange 2016 and 2019 will be subject to throttling by Microsoft. See Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online - Microsoft Community Hub
  • The following table from the blog post illustrates the milestones and actions to take:



  • Licensing for Exchange Server SE will be similar to Exchange 2019 – You either must have an existing Microsoft 365 license for all users or you can buy server licenses and CALs with Software Assurance (SA).

Please reach out to EXPTA Consulting if you need help implementing these requirements. We also can meet with you to discuss options for removing the last Exchange Server from hybrid environments.

Read more ...

Lessons Learned and Best Practices for Autodiscover in a Hybrid Environment

Tuesday, June 20, 2023

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 ...

Exchange Online will Throttle and Block Email from Persistently Vulnerable Exchange Servers

Thursday, March 23, 2023

Microsoft announced that they will begin Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online.

They will begin slowly by blocking OnPremises (hybrid) connections from Exchange 2007 servers to Exchange Online, but plan to include all persistently vulnerable servers soon. A “persistently vulnerable server” is any Exchange server that has reached end of life (e.g., Exchange 2007, Exchange 2010, and very soon, Exchange 2013), or remains unpatched for known vulnerabilities.

If you have any Exchange 2007, 2010, or 2013 servers in your organization that are used for hybrid or SMTP relay, you must make plans to replace or remove them ASAP. You must also keep any Exchange 2016 and 2019 servers up to date with the latest Cumulative and Security Updates, as they are released.

I support this initiative. Organizations using Exchange Servers with known and unpatched vulnerabilities put themselves and their partners at risk. I look forward to seeing it include additional unsupported Exchange Server versions, and I understand their approach of rolling this out slowly and carefully at first.

There are millions of mailboxes in Exchange Online and they have a duty to protect those mailboxes. They know there are 16-year old Exchange 2007 servers currently connecting to their service that haven’t been patched in years and have dozens of known vulnerabilities. 

Microsoft is not forcing anyone to move to Exchange Online. They’re just not going to allow Exchange servers with known vulnerabilities to send hybrid (trusted) emails into their service.

It’s only 2007 for now, but eventually it will be any Exchange Server that is not running the latest or second to latest updates. It’s too risky for everyone.

The table below details the stages of progressive enforcement over time of a persistently vulnerable server:

thumbnail image 2 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online

Read more ...

Big Exchange News!

Wednesday, April 20, 2022

Lots of exciting announcements are being made today about Exchange Server on the EHLO Blog.

  • A new Exchange Management Tools update is being announced. This will allow customers who have completed their migration to Microsoft 365 Exchange Online an option to turn off (not remove!) their last Exchange Server. There are several large caveats to this -- The solution is PowerShell only, it does not support RBAC, and there is no auditing available. I'm working on a blog article that does a walkthrough and explains all the details.
  • The Hybrid Configuration Wizard is making several improvements, including MFA support.
  • Microsoft is changing the updates delivery model for Exchange Server to bi-annually, rather than (roughly) every quarter. This will allow customers more time for testing and deployment between releases.
  • Exchange Server 2019 is adding Windows Server 2022 support. Exchange 2019 CU12 and above can be installed on Windows Server 2019 or Windows Server 2022.
  • With the latest CUs, Exchange Server 2013/2016/2019 now supports Windows Server 2022 Active Directory environments. Exchange customers no longer need to put off upgrading their Domain Controllers.
  • New Microsoft Bounty Program for Exchange Server. A security vulnerability bounty program for Microsoft Exchange Server is being launched to help keep Exchange Server secure for all customers.
Read all about these exciting changes here: Released: 2022 H1 Cumulative Updates for Exchange Server

Read more ...

Notes and details on the eradication of Basic Authentication in Exchange Online

Wednesday, October 6, 2021



Unless you've been living under a rock, or are just blissfully unaware, Microsoft has been making a concerted push to remove Basic authentication from Exchange Online for some time.

There's a very good reason for this. Basic auth is a single factor authentication method (username/password), which is just too easy for the bad guys to guess and exploit. Modern Authentication, on the other hand, supports MFA and is much more secure. Disabling Basic auth in your tenant requires you to use Modern Auth for all authentication requests.

The trouble is that some legacy apps and clients still only use Basic auth. Fortunately, that list is getting shorter. As you may have read in the Microsoft Message Center or the Exchange Team Blog, Microsoft is currently disabling Basic auth in tenants that they've determined are not using it. I applaud this endeavor.

At a recent MVP meeting we discussed how this effort is being undertaken. Here are some notes and details on certain aspects that you might find useful or interesting.

  • Microsoft is examining tenants for actual Basic auth usage. They are not checking to see if the tenant has an Authentication Policy set or is using Conditional Access to block Basic authentication.
  • Basic auth is being disabled in the tenant configuration for all protocols except Autodiscover. Basic auth is required by Autodiscover for legacy (read, old) Outlook clients like Outlook 2013 and earlier. This alone is one of the best reasons to get off these old clients ASAP. See New minimum Outlook for Windows version requirements for Microsoft 365 starting November 1, 2021.
  • Basic auth for SMTP is being disabled for customers that don't use it by using the Set-TransportConfig -SmtpClientAuthenticationDisabled:$true command. Admins can reenable it by setting the value to $false. This setting can also be configured as a per-user setting, which is recommended. The user setting overrides the tenant setting.
  • Authentication Policies are the preferred way to disable Basic auth, rather than Conditional Access policies. CA policies only apply AFTER the user has already signed in.
  • You can use Authentication Policies to disable Basic auth for Autodiscover (and all other protocols). That means that if you may have two areas to check if you need to reenable Basic auth for a protocol -- the Auth Policy and the tenant configuration settings that Microsoft is using.
  • For a limited time, tenant admins can use the Basic Auth troubleshooter to run diagnostics and provide self-service options to reenable Basic auth for Exchange Online protocols such as POP3, IMAP4, Exchange ActiveSync, Exchange Web Services, Offline Address Book, MAPI, RPC and Remote PowerShell. Simply click the Help & Support button on any O365 portal and type Diag: Enable Basic Auth in EXO.

  • So far, they have disabled Basic auth in thousands of tenants since they started. Only 0.06% of tenants have reenabled Basic auth for a specific protocol, and all of them using the self-help troubleshooter.
  • Tenant admins can tell if Basic auth has been disabled in their tenant by connecting to Exchange Online PowerShell and running Get-OrganizationConfig | fl basic*. The BasicAuthBlockedApps property value will be 0 if Basic auth is still enabled or 255 if it's been fully disabled. This value is a bit mask for each of the following protocol values, totaling 255. Thanks to Greg Taylor for the secret decoder ring. 😊

Protocol

Action

Value

ActiveSync

Block Basic for Exchange ActiveSync

1

WebServices

Block Basic for Exchange Web Services

2

POP

Block Basic for POP3 Clients

4

IMAP

Block Basic for IMAP4 Clients

8

PowerShell

Block Basic for PowerShell

16

MAPI

Block Basic for MAPI Protocol

32

OAB

Block Basic for Offline Address Book

64

RPC

Block Basic for RPC Protocol

128

  • Be aware that if you've configured a client to connect using Basic auth (Outlook for Mac, for example), it will likely require you to reconfigure the client profile to use Modern Auth after Basic is disabled.
This information should be helpful in your "Death to Basic Auth" journey.

Read more ...

Announcing Microsoft Exchange Server vNext!

Tuesday, September 22, 2020

Some really exciting Exchange Server news was announced for on premises customers at the Microsoft Ignite virtual conference today! 

Microsoft will be releasing the next versions of Exchange Server, SharePoint Server, and Skype for Business Server the second half of 2021.  These new on-premises server versions will only be available with the purchase of a subscription license, using a similar subscription model to Microsoft 365.

The name for these new on-premises server products has yet to be announced, but it is likely that Microsoft will drop the year from the version name since the new subscription server will be evergreen. Pricing and availability will be announced closer to the release date.

It's important for on-premises customers to know and stay on top of the Exchange Server product lifecycle policies for support and planning.

Product

End of Mainstream Support

End of Extended Support

Exchange Server 2010

01/13/2015

10/03/2020

Exchange Server 2013

04/10/2018

04/11/2023

Exchange Server 2016

10/13/2020

10/14/2025

Exchange Server 2019

01/09/2024

10/14/2025

As mentioned in the article, Exchange Server 2016 and the End of Mainstream Support, CU19 is the last planned update for Exchange Server 2016 and is due in December 2020. After December 15, 2020, only CU19 or its successors will receive critical updates.

Exchange Server Upgrade Planning

In the near-term, customers who plan to stay on-premises should upgrade to Exchange Server 2019 ASAP to maintain both critical security and non-critical feature updates. This will also put your organization in the best position for when Exchange Server vNext is released in the second half of 2021.

You'll be able to install Exchange Server vNext into an org with Exchange Server 2013, 2016 or 2019. That's one more version than they used to support. And for the first time ever, you'll be able to perform an in-place upgrade from Exchange Server 2019 to Exchange Server vNext. Even in the same DAG. This will make it the easiest Exchange upgrade ever!

The bottom line is, if you're going to be staying on-premises long term - start planning and installing Exchange Server 2019 today!

New hybrid customers or customers who plan to keep some mailboxes on-premises should definitely upgrade to Exchange 2019 and later, Exchange Server vNext when it's released.

Hybrid customers who have completed migrating all their mailboxes to Exchange Online can continue to use their existing Exchange 2016 server for hybrid management. Microsoft hopes to deliver a serverless management solution soon, but it will later than the CU19 release.

Other Exchange and Exchange Online News

Another important bit of news on hybrid is that the new HCW will support establishing a one-to-many on-premises to cloud tenant configuration. This is helpful for divestments and customers with multiple tenants. Just be aware it only works for Exchange 2016/2019 and Hybrid Modern Auth only works with one tenant.

Microsoft is also opening the distribution of the Exchange Server 2019 Capacity Calculator. It previously was available only to Volume License customers. You can get it from https://aka.ms/ExCalc

"Plus Addressing" is now GA in Exchange Online. This lets users create "disposable" email addresses based on their primary email address. This lets users know where their email addresses are being leaked and create Inbox rules to handle them.

View the on-demand session, Exchange, Here, There and Everywhere, delivered by the ever-so-suave Greg Taylor.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

EXPTA Consulting provides professional upgrade, migration, and hybrid services for on-premises customers of all sizes. We specialize in Exchange, Microsoft 365, Active Directory, and identity solutions and pride ourselves on customer satisfaction.

Examples where we provide turn-key solutions or can work with your IT staff include:

  • Exchange and Active Directory Health Checks
  • Exchange on-premises upgrades and configuration
  • Exchange hybrid configuration and migrations to Exchange Online
  • Hybrid Modern Authentication (MFA) for Exchange on-premises
  • Public Key Infrastructure (PKI) design and deployment
Contact us today for a free consultation.

Read more ...

Roaming Signatures Update for Outlook for Windows

Monday, September 21, 2020

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 ...

Congratulations 2020-2021 Microsoft MVP!

Wednesday, July 1, 2020
I'm very pleased to announce that I have been awarded the Microsoft MVP Award again for 2020-2021 in the Office Apps & Services category! This is my 12th consecutive year to receive this award and it humbles me to work alongside such talented people.


The MVP Award is an important recognition to me and I'm honored to receive it. It includes several benefits, but the most important one to me are all the interactions with the great product groups at Microsoft. These relationships allow me to reach out to specific product team members to provide feedback and get clarification on product features and behaviors.

It's a mutually beneficial partnership -- under NDA, Microsoft is able to talk with MVPs about product futures, provide access to technology adoption programs (TAPs) to test new software, and solicit our MVP feedback. As MVPs, we are able to provide important and honest feedback to the product teams about how new features and behaviors will affect our customers, beta test new software and file bug reports, and be advocates for you, the customer.

As usual, I feel great!



Read more ...

Remove EWS Throttling in Microsoft 365 using Self-Service

Tuesday, June 9, 2020
A number of third party migration solutions use Exchange Web Services (EWS) for migrations to Microsoft 365. This protocol allows these mailbox migration tools to inject migrated items into the target mailboxes in Exchange Online using delegation or impersonation.

Throttling policies help ensure server reliability and uptime by limiting the amount of server resources that a single user or application can consume in Exchange Online. When high load factors are detected that degrade the performance of these resources, EWS connections are dynamically throttled based on the amount that each caller has contributed to this high load condition.

The result is that the third-party migration tool that uses EWS may be impacted by the EWS throttling policy. Migrations may slow or stop altogether.

See EWS throttling in Exchange for a full description of EWS throttling and limits.
Note: It's important to call out that EWS throttling policies do not affect Exchange hybrid migrations. Hybrid migrations use MRS not EWS. Do not use the steps in this article to try resolving slow hybrid migrations.


Read more ...

The Death of Basic Authentication in Office 365

Tuesday, September 24, 2019
Microsoft posted the article, "Improving Security - Together" where they explain that they will be turning off Basic Authentication in Exchange Online for EWS, Exchange ActiveSync (EAS), POP, IMAP and Remote PowerShell on October 13, 2020. That means that only apps that support modern authentication using OAUTH 2 will be able to connect to Exchange Online after that time. There are currently no plans to override this behavior.

I applaud this move, since it greatly improves the security posture for your tenant and Office 365 as a whole. The vast majority of bad actors use Basic authentication (username/password credentials) for their attacks. That said, there are caveats you should be aware of.

Exchange ActiveSync is probably the most heavily utilized protocol in this list. EAS has been shipping with every version of Exchange since Exchange Server 2003. Millions of users across the globe count on it to manage emails from their mobile phones and tablets. Many of these users have moved over to the Outlook mobile apps for iOS and Android, but a very significant number are still using the native email apps on their phones.

Apple started supporting modern auth in iOS 11, so any reasonably up-to-date iOS device should be unaffected by the removal of Basic auth for EAS. Android is a different story. There are so many older devices out there with different Android versions from different vendors, it's hard to say which devices will be affected. Some versions may have native support for OAUTH 2 using the AppAuth for Android library, while some mail apps in the Play Store may have built-in support in the app (Outlook for Android is one example). In the end, you really need to test your apps.

The best way to do that is to setup or reconfigure a mail account on your mobile devices. If you're prompted for modern auth to setup your account, as below, you should be good to go.

OAUTH 2 (Modern Auth) prompt

If you get a Basic authentication prompt within the app, you're app probably doesn't support OAUTH 2. Download the Outlook mobile app for iOS or Android, or another email app that supports it.

The POP and IMAP protocols are less often used, but when they are, it's typically for app integration with a line of business app. Examples include help desk ticketing systems, ERP solutions, life-cycle management systems, etc. These apps are usually critical to the business, so anything that affects email connectivity must be carefully planned. Microsoft is planning to add OAuth support to both POP and IMAP in the next few months, but the apps that use these protocols must also be updated to support it. That means software updates for these LOB apps (assuming they will support OAUTH 2), possible additional support costs, contracts, etc. Plan ahead and talk with these vendors now to see how they plan to support OAUTH 2. You may even need to go so far as to change LOB solution providers.

Read more ...

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

Tuesday, September 10, 2019
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 ...

How to Create a Hub Transport Rule Based on Any Attachment

Tuesday, August 13, 2019
Transport rules are cool. Except when they don't work the way you expect.

I wanted to create a transport rule that blocks outgoing email to external recipients that contains an attachment, except for members of the "Allow Outbound Attachments" group. So, I created the following rule:


The trouble is, that it blocks any email that is not sent as plain-text, even though there is no attachment. Not good.

I examined the headers on emails with and without attachments and found the X-MS-Has-Attach X-header has a yes value when there's an attachment and is <blank> when there isn't.
...Message-ID: <BL0PR01MB4243EF8B4D8DD1624C9C6E77D4D20@BL9PR01MB4243.prod.exchangelabs.com>References: <1db58e8b507e4f7f81a892f1bb48654e@ex.contoso.com>In-Reply-To: <1db58e8b507e4f7f81a892f1bb48654e@ex.contoso.com>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator:Authentication-Results-Original: spf=none (sender IP is )...
I modified the rule as below and it now works perfectly.


It's worth noting that the header values are not cAsE sensitive.

Read more ...

HCW Organization Configuration Transfer breaks Outlook connectivity to Office 365

Thursday, May 2, 2019
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
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 ...

How to work with Inactive Mailboxes in a Hybrid Environment

Tuesday, January 29, 2019
Earlier today the Exchange team posted an article on the EHLO Blog explaining how to manage inactive mailboxes in Exchange Online. That blog post is geared mainly toward cloud-only tenants. This article gives information about the differences between inactive users and shared mailboxes and how to configure them both in a hybrid environment.

Inactive vs Shared Mailboxes

Most customers are interested in a way to remove the Office 365 license from terminated users to reduce costs, while maintaining access to their email. There are two ways to do this.

Inactive mailboxes are mailboxes that have been put on litigation hold and the Office 365 licenses have been removed from the user account in Azure AD. Normally when you remove an Exchange Online license from a user account, the mailbox becomes disconnected and will eventually be purged from EXO (30 days by default). However, if the mailbox is placed on litigation hold before the user account is deleted or unlicensed, EXO is unable to delete the mailbox until the lit hold is removed.

Shared mailboxes are mailboxes that multiple users can access to read and send e-mail messages. Shared mailboxes allow a group of users to view and send e-mail from a common mailbox. This type of mailbox also does not require an EXO license, but has some limits placed on it to prevent abuse.

I put together a table that lists some of the important differences between Inactive and Shared mailboxes that may help you chose which one to use. Neither require an EXO license.

Characteristic
Inactive Mailbox
Shared Mailbox
Requires an EXO license
No
No
Accessed by
Only by users with Discovery Management role
Any user with Full Access rights or with Discovery Management role
Can receive new emails
No
Yes
Can send new emails
No
Yes
Mailbox size limit
100 GB
50 GB
Supports online archive mailboxes
Yes
Yes, but requires a license
Messages can be changed or deleted
No
Yes

Note: There are other limits and requirements, as well. See Exchange Online Limits for the complete list.

Inactive mailboxes are just that -- inactive. The mailbox contents are in stasis and cannot be changed. No new emails can be sent or received by an inactive mailbox. The original user cannot access the mailbox because the account has been deleted or the Office 365 license(s) have been removed. Only users with the Discovery Management role can access the historical mailbox contents. If a user was granted full access to that mailbox prior to removing the license(s), the mailbox may still show in Outlook, but the contents will be inaccessible.

Some organizations chose to convert mailboxes for terminated users into shared mailboxes instead and assign full access to the user's manager or another team member or group. That way, emails sent to the shared mailbox don't bounce with an NDR and the user with full access can respond for the termed employee. Just keep in mind the size and archive limits listed above. See Correcting Shared Mailbox provisioning and sizing for more details.

How to Configure an Inactive Mailbox in a Hybrid Environment

Normally in a hybrid environment all user and mailbox management is done on-premises and the configuration changes sync to the cloud. However, configuring litigation hold for an inactive mailbox is performed directly in Exchange Online.

Follow the first two steps listed in the EHLO Blog article. These are performed in the Microsoft Exchange Online Powershell Module.

1. Put the mailbox on a hold (which will also place the Archive on the hold, if it is present). For this scenario I’ve used LitigationHold, but, any hold from Exchange Online, or Security and Compliance can be used:
Set-Mailbox David -LitigationHoldEnabled $True -LitigationHoldDuration Unlimited
Note: The hold setting may take up to 60 minutes to take effect.

2. Ensure the mailbox has Litigation Hold enabled:
Get-Mailbox David | fl PrimarySMTPAddress, Identity, LitigationHoldEnabled, LitigationHoldDuration, MailboxPlan, PersistedCapabilities, SKUAssigned
User properties should now show:

PrimarySmtpAddress : David@contoso.com
Identity : David
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
MailboxPlan : ExchangeOnlineEnterprise-0527a260-bea3-46a3-9f4f-215fdd24f4d9
PersistedCapabilities : {BPOS_S_O365PAM, BPOS_S_ThreatIntelligenceAddOn, BPOS_S_EquivioAnalytics, BPOS_S_CustomerLockbox, BPOS_S_Analytics, BPOS_S_Enterprise}
SKUAssigned : True

3. Wait for Azure AD Connect to replicate the change back to on-premises or you can force AAD replication using the following command on your AAD Connect server:
Start-ADSyncSyncCycle -PolicyType delta
4. Now you can either delete the user's AD account from on-premises, which will sync to ADD and remove the user account there. The inactive mailbox will not be deleted because it's on indefinite litigation hold. Use the procedures here to access the inactive mailbox.

How to Configure a Shared Mailbox in a Hybrid Environment

First, it's important to know that it's recommended that you do not convert a mailbox that was migrated to Exchange Online to a shared mailbox. The mailbox should be moved back to on-prem, converted to a shared mailbox, and remigrated to Office 365 again. The reason is that AAD Connect doesn't sync the correct attributes back to on-premises. See Convert a user's mailbox in a hybrid environment for more details.

That said, it is possible to convert a migrated user mailbox to a shared mailbox by updating AD on-premises manually. Jetze Mellema blogged about it here. Just follow these steps:

1. Sign-in to the Exchange Online Admin Center and navigate to Recipients > Mailboxes.

2. Select the user account you wish to convert and select Convert to Shared Mailbox on the right-side pane. The mailbox will now show under Shared mailboxes in the Exchange Admin Center in Exchange Online.

3. In AD on premises, change the following two attributes for the user account. This can be done using ADSIEdit or the Advanced view of AD Users and Computers on the Attributes tab.
msExchRemoteRecipientType: 100
msExchRecipientTypeDetails: 34359738368
4. Remove the Office 365 licenses from the Shared mailbox.

5. Disable the user account in AD on-prem and Windows will manage its password. The mailbox will now show under Shared mailboxes in the Exchange Admin Center on premises.




Read more ...