Microsoft 365 Groups are a more modern way to work in teams and to distribute email messages. We still have the option to use classic distribution groups.
Exchange Online provides us with an option to upgrade classic distribution groups to Unified Groups, which is the Exchange Online term for Microsoft 365 Groups.
When you try to upgrade an existing distribution group, you might receive an error.
PS C:\> Upgrade-DistributionGroup -DlIdentities info@varunagroup.de RunspaceId : b7f07a8b-cec0-45e8-a50d-00c278d48d76 dlIdentity : info@varunagroup.de ErrorReason : The specified distribution group is not eligible to be upgraded or you are not allowed to upgrade this distribution group. ExternalDirectoryObjectId : 0352193a-XXXX SuccessfullySubmittedForUpgrade : False Identity : IsValid : False ObjectState : Unchanged
When you get this error, verify that the distribution group owner is a licensed user. While there is no such requirement for a classic distribution group, the owner of a Unified Group must be a licensed user. After adjusting the group owner the upgrade is successful.
PS C:\> Upgrade-DistributionGroup -DlIdentities info@Varinagroup.de RunspaceId : b7f07a8b-cec0-45e8-a50d-00c278d48d76 dlIdentity : info@varunagroup.de ErrorReason : ExternalDirectoryObjectId : 0352193a-1XXXX SuccessfullySubmittedForUpgrade : True Identity : IsValid : True ObjectState : Changed
Enjoy Exchange Online.
You are hopefully familiar with the new Exchange Emergency Mitigation Service (EEMS) for Exchange Server 2016 and 2019. That is a new service providing automated emergency configuration of your Exchange servers by Microsoft in the case a security risk has been identified. Such emergency mitigation is a technical workaround until a proper security patch is available.
The service responsible for fetching the current list of published mitigations is MSExchangeMitigation.
Exchange Organisation following the official guidance for deploying Exchange Server won't see any specific issues with EEMS. It simply works.
But Exchange Server runs in many different infrastructures where you might end up in a situation with a non-working EEMS.
You see the following event log error:
Exception encountered while fetching mitigations : System.AggregateException: One or more errors occurred. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
In addition, you see the following in the diagnostic logs of the Exchange Server:
S:LogLevel=Information;S:Message=Started MSExchangeMitigation S:LogLevel=Information;S:Message=Fetching mitigations from https://officeclient.microsoft.com/getexchangemitigations S:LogLevel=Information;S:Message=Using Proxy http://[IPADDRESS]/ To Fetch Configurations S:LogLevel=Information;S:Message=No diagnostic data sent. DataCollectionEnabled is false S:LogLevel=Warning;S:Message=TLS certificate or its chain validation failed S:LogLevel=Error;S:Message=Exception encountered while fetching mitigations : One or more errors occurred.;S:Source=Microsoft.Exchange.Mitigation.Service.Mitigations.MitigationEngine
File location: V15\Logging\MitigationService
But what is the validation procedure failing? The solution is simple. The certificate revocation check for the certificate chain failed. The EEMS was not able to connect to the CRL-endpoints of each certificate in the certificate chain. CRL-endpoints are accessible by HTTP and not HTTPS for performance reasons. And outbound HTTP is often blocked for Exchange servers.
The Exchange Server must be able to validate the certificate chain successfully establish a TLS-connection to officeclient.microsoft.com. Certainly, you can disable the CRL check for the server. But this is something I do not recommend. The XML file containing the mitigation configuration is signed by an X509 certificate and your servers should be able to validate and check the CRL.
Ensure that your Exchange servers can communicate with the Internet to validate the certificate chain.
Enjoy Exchange Server.
When you prepare your on-premises public folder hierarchy ACLs for migration to Exchange Online or for moving from Exchange Server 2016 to 2019 you might see the following error:
Multiple objects with legacy DN ADCDisabledMail were found.
This error prevents you from removing orphaned entries from public folder ACLs. And when you do not clean up the ACLs, you cannot migrate public folders to Exchange Online or move public folder mailboxes from Exchange Server 2016 to Exchange Server 2019.
The affected objects are mail-disabled objects that were disabled with Exchange Server 2010 or older. The older Exchange Server version used something called Active Directory Connector (aka ADC). When mail-disabling a user or security group, ADC stamped the legacyExchangeDN attribute with ADCDisabledMail. Modern Exchange Server versions do not write that value to the attribute when you mail-disabled the object.
To successfully migrate or move your public folders you must clear the legacyExchangeDN attribute. Otherwise, you cannot remove the orphaned ACL entries.
Simply use the following PowerShell script to clean up those objects.
When you move mailboxes using migration batches you might encounter a situation that your batch contains migration users that fail during batch execution. One of the possible reasons is an existing move request for the affected users. You must remove those requests to successfully move mailboxes.
The following PowerShell example gets all failed migration users from a migration batch and removes existing move requests.
$r = Get-MigrationUser -BatchId MyMigrationBatch | ?{$_.status -eq 'Failed'} $r | %{Remove-MoveRequest -Identity $_.MailboxIdentifier -Confirm:$false}
Enjoy Exchange Server!
These are the results of the Exchange Server Questionnaire from August 2021.
First of all, I want to thank all of you who participated in the questionnaire. The results are pretty interesting. Even though, that the results are not 100% representative they provide a high-level view of the Exchange Organizations, the mail flow configurations, and the future plans regarding hybrid and Exchange Online.
With 55 replies the questionnaire is far from being a comprehensive representation of the Exchange organizations. But the answers provide an idea of the Exchange landscape used by organizations globally.
Exchange Server 2016 is the dominant version currently in use, followed by Exchange Server 2019. The vast majority of 93% runs modern Exchange Server versions. But there are still older and unsupported Exchange Server versions in use. 7% use Exchange Server 2010 and older.
76% of the organizations maintain up to ten Exchange servers. 20% prefer to rely on just one Exchange server. It is interesting that only 2 (not percent) plan to go hybrid or to move to Exchange Online.
The majority of on-premises Exchange organizations are in the 1,000 - 10,000 mailboxes range. Nevertheless, the SMBs with 1 to 1,000 mailboxes adds up to 50% of the Exchange organizations that took part in this questionnaire. There are just a few organizations that host more than 50,000 mailboxes.
There are Exchange organizations that do not use an SMTP-Gateway solution as part of the mail-flow implementation. Thor organizations that do not use a gateway solution run 1 to 10 Exchange servers on-premises. The majority of those have less than 1,000 mailboxes but there are a few that are responsible for more than 1,000 mailboxes. That leaves the question of why an organization prefers to not secure mal-flow with a gateway.
The use of SMTP gateways is a must, as you do not want to expose your domain member servers to the Internet, not even for the SMTP protocol. A majority of 28 answers for other gateways shows, that there are so many products available and that I did not choose valid answer options upfront.
The Other answers include:
65% of the Exchange organizations of this questionnaire already run in a hybrid configuration with Exchange Online. Only 35% are (still) not using a hybrid setup.
Of those who currently do not run a hybrid configuration only 37% plan on implementing Exchange Hybrid or migrate fully to Exchange Online. Staying on-premises is the only option.
The majority of the organizations still running only an on-premises Exchange organization plan on implementing Exchange Hybrid or migrating to Exchange Online by the end of 2021. None of the participating organizations has plans scheduled after 2022.
It is no surprise that Classic Full Hybrid is the most adopted hybrid configuration. And, no surprise either, none of the other classic hybrid options is implemented. The modern hybrid approach is implemented but with lesser.
The reasons for staying with an on-premises Exchange organization vary. the reasons mentioned are:
There are still organizations that choose an on-premises Exchange organization in favor of Exchange Online. I wonder if company policies for reducing the carbon footprint might drive the migration of on-premises data center resources to hosted cloud services.
Exchange Server vNEXT is in scope for 47% of the organizations. When comparing it with the used Exchange Server version currently in use (~50% Exchange Server 2016) it is an indicator that some companies just skip Exchange Server 2019. Some organizations prefer not to follow the full life-cycle of Exchange Server. s7% of those who do not want to implement Exchange Server vNEXT and want to stay on-premises are single server implementations of Exchange.
The product Exchange Server is still widely used in on-premises deployments. The reasons vary from legal and compliance requirements, network bandwidth constraints, and the overall costs for Exchange Online. Exchange Server vNEXT is a must-have for nearly 50% of the organizations participating in this questionnaire. There are still older and unsupported versions in productive use. Why this is the case is unanswered in this questionnaire.
Organizations running a hybrid Exchange configuration primarily use a Classic Full Hybrid configuration. This might be due to an early implementation in those days when nothing else was available, or due to requirements using Microsoft Teams with on-premises mailboxes. The adoption of Modern Hybrid shows that the Hybrid Agent approach helps organizations that cannot implement a Classic Full Hybrid.
I leave the results of this questionnaire to your interpretation and look forward to your replies, either to this blog post or by social media on Twitter and LinkedIn. Please use the hashtag #ExchangeQuest2021.
There will be a new Exchange Server questionnaire in early 2022, covering various implementation scenarios in more detail. If you want to see a specific Exchange topic covered in the 2022 questionnaire, just let me know.
Again, thank you all for participating in this questionnaire.