More detailed information can be found at the original blog post here. The security update also fixes the OWA redirection problem for Exchange hybrid deployments introduced with the November security updates.
Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU11 to Exchange 2019 CU10. Also, the security update download has the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level, e.g. Exchange2019-CU10-KBXXXXXX-x64-en.msp.
As a reminder, run the Security Update from an elevated command prompt to prevent issues during installation. In other words: Do not just double-click on the .MSP file. And on a final note, as with any patch or update, I’d recommend to apply this in a test environment first, prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates, and follow a more agile approach; the ratings are an indication of the urgency.
Happy new year to all my dear readers and followers. While some thought after 2020 things would improve soon, 2021 proved to be another year of dealing with measures. That said, 2021 was not very different compared to 2020 from a work perspective, with many organizations now professionalizing their quickly adopted digital transformation, further normalization for work from home scenarios. The year again proved to be a challenge for those busy working on customer projects while catering to the community as well. In the end, it is all about finding a balance, especially if you are working from home and the rest of the household is as well.
Now, without further ado, here are some of this blog’s and GitHub’s top entries for 2021.
General Stats
Number of views: 271,751 (3,086,610 all-time)
Unique visitors: 168,011 (1,627,860 all-time)
Number of posts: 17 (647 total)
Followers: 508
Busiest day: March 4, 2021 (5,616)
Popular time of day: Wednesday, 3pm
Popular blogs
Not surprisingly, posts related to the Hafnium security updates lead the way in 2021:
While I published some additional scripts on my GitHub repository, some scripts like the script to download Ignite sessions or remove duplicate items from Exchange mailboxes remain popular. I performed a total of 144 updates on the scripts, and have 102 people following my GitHub profile.
A long overdue blog on a solution which was created per request of an Exchange fellow. The original scenario is an organization spinning off, thereby changing their primary e-mail domain. They wanted to inform relations and partners using the old e-mail addresses of this change. However, this solution might also be helpful to organizations after merger and acquisitions or rebranding.
For the sake of the example, let us suppose Fabrikam was acquired by Contoso. Targeted mailboxes are migrated from the Fabrikam tenant to the Contoso tenant. Fabrikam will contain Mail-Enabled Users forwarding messages to their Contoso mailbox counterparts. The migrated mailboxes now hosted in Contoso will be configured to send notifications to senders which sent mail to the old Fabrikam address.
While organizations can resort to 3rd party tools to set up an Exchange Transport Rule with a generic message, a little script might also do the job, offering a more granular and controlled solution.
Solution The scripted solution is available on GitHub here. It will configure an Inbox rule on the targeted Exchange mailbox(es), which would be the new/migrated mailbox. The rule will trigger when messages land in the inbox which were sent to a specific e-mail address, i.e. the previous e-mail address. It will send out an automatic response, which can consist of a custom subject, message body with an optional embedded image. The configuration of the response is defined in an customizable external XML file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<config>
<rule>Contoso Autoresponder</rule>
<subject>Please update your email recipient to Contoso</subject>
<body>Dear Sender,
Thank you for your message. Fabrikam is now a whole Contoso subsidiary, and the fabrikam.com e-mail address will change to contoso.com. Your e-mail was forwarded to my new e-mail address.
Please update contact information, distribution lists, etc. to update [OldMail] e-mail references with my new [Identity] e-mail address.
[logo]
The Contoso Corporation is a multinational business with its headquarters in Paris.</body>
<logo>Contoso.png</logo>
</config>
The elements that can be used in the config are:
<rule> defines the name of the Inbox rule to be created. When the script runs, it will update any existing previously created inbox rules of the same name.
<subject> defines the subject of the response.
<body> defines the message body. You can use the following macros here:
[OldMail] will get replaced with the original e-mail address.
[Identity] will get replaced with the new e-mail address.
[Logo] will get replaced with the embedded image.
Optionally, <logo> refers to the file name of the image to embed.
Requirements To run the script, you need the following:
Exchange Server 2013 SP1 or later, or Exchange Online.
Exchange Web Services (EWS) Managed API 2.21 or later (how to, NuGet package exchange.webservices.managed.api).
When using modern authentication or OAuth2, the MSAL library is required (NuGet package Microsoft.Identity.Client). Also, you need to have registered an App in Azure Active Directory with sufficient permissions (e.g. full_access_as_app). After registering the app, Tenant ID, Application ID and certificate or secret is what you need to use with the script to run successfully.
In addition to installing the NuGet packages, you can also store their DLLs in the same folder as the script for portability.
The available parameters and switches are as follows:
Identity specifies one or more e-mail addresses of mailboxes to process. Identity supports the pipeline (see examples).
OldMail specifies one or more old e-mail addresses to use when configuring the autoresponder message. When specifying multiple identities, the number of OldMail entries need to match the number of identities.
Server specifies the Exchange Web Services endpoint, for example outlook.office365.com for Exchange Online. When omitted, Autodiscover will be used.
Impersonation to use impersonation when accessing the mailbox. When using modern authentication, impersonation is mandatory.
TrustAll to accept all certificates including self-signed certificates.
TenantId specifies the ID of the Tenant when using a mailbox hosted in Exchange Online.
ClientId to specify the Application ID of the registered application in Azure Active Directory.
Credentials to specify the Basic Authentication credentials for on-premises usage or against Exchange Online when modern authentication is not an option.
CertificateThumbprint is the thumbprint of the certificate to use for modern authentication. The certificate with the public key needs to stored with the registered application for authentication. The certificate with the private key should be present in the local certificate store.
CertificateFile and CertificatePassword can be used to specify a certificate file to use. The file should contain the private key; the password protecting the certificate file can be specified using CertificatePassword as a secure string.
Secret can be used to specify the secret to authenticate using the registered application. The secret needs to be provided as a secure string.
Template specifies the XML template file to use when configuring or clearing the autoresponder inbox rule. The format has explained above.
Clear specifies if any you want to remove the inbox rules with name specified in the template. Use this when you want to remove autoresponder rules from mailboxes. When using Clear, you don’t need to specify OldMail.
Overwrite specifies if any existing inbox rules with name specified in the template should be overwritten. When omitted, the script will skip processing mailboxes with inbox rules with conflicting names. Use this when you want to configure the autoresponder only on mailboxes which do not have the rule.
Note that usage of the Verbose, Confirm and WhatIf parameters are supported.
Examples Nothing more explanatory than an example. When we want to configure the autoresponder on a single mailbox, we can use something like:
Here, the autoresponder will get configured on the specified mailbox, triggering when mail has been sent to michel@fabrikam.com using the configuration defined in template.xml. Modern authentication will be used for authentication, using variables for Tenant, Client and in this case secret.
When you want to configure autoresponder for multiple mailboxes, you can for example use a CSV file. It needs to contain two elements which will be passed through pipeline, Identity and OldMail:
After defining the response in a file template.xml, we can use this CSV to configure inbox rules on the Contoso mailboxes identified by Identity, triggering when mail is sent to their OldMail addresses:
What will happen is that for every set of Identity and OldMail, the mailbox specified by Identity will be configured with an inbox rule. When an existing rule is found, which is determined using the <rule> element in the XML template, it will get overwritten. The specified certificate will be picked from the local certificate store to authenticate against Tenant with TenantId, as application specified by ClientId.
Note that when the user opens Manage Rules & Alerts in Outlook, the configured inbox rule will be visible. This allows the user to remove it when it is no longer required. After a certain period, administrators can centrally remove these rules as well running the script using the Clear switch.
And finally, an example of how this may looks to senders when they receive an autoresponse message, using the sample configuration from the beginning of this article.
Application Access Policy When using the script with modern authentication, you can leverage features such as conditional access to set boundaries for script usage. Also, you can configure application access policies to scope the registered app (script) to a subset of mailboxes. To accomplish this, assign an ApplicationAccessPolicy to the app.
To be more convenient in managing permissions, you can define a distribution group and assign the Application Access Policy with group scope (PolicyScopeGroupId). You then only need to add/remove members as you need to configure mailboxes.
More information about Application Access Policies here. Note that the permissions mentioned to not include full_access_as_app as permission, but it works.
EWS, why not Graph? Microsoft already announced back in 2018 that development on Exchange Web Services will halt in and focus will shift to Graph. As part of this move, a more recent statement announced deprecation of some least-used API per March 2022, stimulating organizations to switch to using Graph. However, the organization looking for a solution wished for an automatic response with HTML as well as an embedded logo. Because of this, I had to use a template as a reply action.
But where Exchange Web Services supports reply with a template, Graph does not offer this functionality. So, until there is more feature parity between Exchange Web Services and Graph, or EWS goes completely out of service, solutions may still be forced to have a look at EWS for certain tasks.
Another month, another Patch Tuesday! A quick blog on November’s security updates for Exchange Server 2013 up to 2019. The vulnerabilities addressed in these security updates are:
Vulnerabilities mentioned in the table above are addressed in the following security updates. Exception is Exchange 2013 CU23 which seemingly only gets fixed for CVE-2021-26427; it is unclear if that is because of Exchange 2013’s lifecycle phase or because the problem does not exist in those builds.
More detailed information can be found at the original blog post here. Check the KB articles for any known release notes, such as the possible cross-forest Free/Busy issue and HTTP headers containing version information.
Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU11 to Exchange 2019 CU10. Also, the security update download has the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level, e.g. Exchange2019-CU10-KBXXXXXX-x64-en.msp.
As a reminder, run the Security Update from an elevated command prompt to prevent issues during installation. In other words: Do not just double-click on the .MSP file. And on a final note, as with any patch or update, I’d recommend to apply this in a test environment first, prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates, and follow a more agile approach; the ratings are an indication of the urgency.
Vulnerabilities mentioned in the table above are addressed in the following security updates. Exception is Exchange 2013 CU23 which seemingly only gets fixed for CVE-2021-26427; it is unclear if that is because of Exchange 2013’s lifecycle phase or because the problem does not exist in those builds.
More detailed information can be found at the original blog post here. Check the KB articles for any known release notes, such as the possible cross-forest Free/Busy issue and HTTP headers containing version information.
Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU11 to Exchange 2019 CU10. Also, the security update download has the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level, e.g. Exchange2019-CU10-KBXXXXXX-x64-en.msp.
As a reminder, run the Security Update from an elevated command prompt to prevent issues during installation. In other words: Do not just double-click on the .MSP file. And on a final note, as with any patch or update, I’d recommend to apply this in a test environment first, prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates, and follow a more agile approach; the ratings are an indication of the urgency.
The Exchange Team released the quarterly Cumulative Updates for Exchange Server 2019 as well as Exchange 2016.
Be advised that these CUs will introduce something which is called the Exchange Emergency Mitigation Service. This service is designed to distribute and implement mitigations addressing potential threats. For this, the URL Rewrite Module needs to be installed on the Exchange server. When you have Exchange running on Windows Server 2012 R2, you will also need an update for the Universal C Runtime (KB2999226). Periodically, the EEM service will reach out to the Office Config Service (OCS) through endpoint https://officeclient.microsoft.com, and update its set of configured mitigations. More on EEM and managing its configuration here.
Links to the updates as well as a description of changes and fixes are described below. The column Schema and AD indicate if the CU contains Schema (/PrepareSchema) and Active Directory (PrepareAD) changes compared to the previous CU. Refer to the Exchange Schema page for schema and related versioning information.
5006980 Bad signature error using PerfView in Exchange Server 2019 and 2016 (KB5006980)
5006982 On-premises Exchange queues back up because of incorrect default value (KB5006982)
5006983 Exchange Server 2019 and 2016 certificates created during setup use SHA-1 hash (KB5006983)
5006984 PrepareAD fails if Computers container or RODCs are renamed or moved in Exchange Server 2019 and 2016 (KB5006984)
5006986 Opening an Outlook message from the desktop removes line spacing (KB5006986)
5006988 Export of .pst file is unexpectedly triggered again in Exchange Server 2019 and 2016 (KB5006988)
5006989 Accepted domains with wildcards for subdomains are not honored when Edge server maps AddressSpaces (KB5006989)
5006990 Exchange CU installation fails after you configure fallback to use default character set (5006990)
5006991 Mail quota warning messages no longer sent daily in Exchange Server 2019 (KB5006991)
5006992 No room lists found when trying to add a room in OWA in Exchange Server 2019 or 2016 (KB5006992)
5006993 Can’t log on to OWA in Chrome if SSL is offloaded in Exchange Server 2019 and 2016 (KB5006993)
5006994 BCC values not retained in Sent Items in a shared mailbox in Exchange Server 2019 and 2016 (5006994)
5006995 Korean email messages display some recipients incorrectly in Exchange Server 2019 and 2016 (KB5006995)
5006996 Export-AutoDiscoverConfig exposes admin password and does not work against domain controllers that require signing (KB5006997)
5006997 Korean messages in OWA display “From” as “Start date” after you filter the list in Exchange Server 2019 and 2016
5006999 “401” error and Outlook repeatedly prompts for credentials in Exchange Server 2019 (KB5006999)
5007042 Error window appears when you view features in OWA Virtual Directory (KB5007042)
5007043 Exchange Server SU updates Add/Remove Programs incorrectly (KB5007043)
5007044 Start-MailboxAssistant not available in EMS in Exchange Server 2019 (KB5007044)
Exchange 2016 CU22 fixes:
5006980 Bad signature error using PerfView in Exchange Server 2019 and 2016 (KB5006980)
5006982 On-premises Exchange queues back up because of incorrect default value (KB5006982)
5006983 Exchange Server 2019 and 2016 certificates created during setup use SHA-1 hash (KB5006983)
5006984 PrepareAD fails if Computers container or RODCs are renamed or moved in Exchange Server 2019 and 2016 (KB5006984)
5006986 Opening an Outlook message from the desktop removes line spacing (KB5006986)
5006988 Export of .pst file is unexpectedly triggered again in Exchange Server 2019 and 2016 (KB5006988)
5006989 Accepted domains with wildcards for subdomains are not honored when Edge server maps AddressSpaces (KB5006989)
5006992 No room lists found when trying to add a room in OWA in Exchange Server 2019 or 2016 (KB5006992)
5006993 Can’t log on to OWA in Chrome if SSL is offloaded in Exchange Server 2019 and 2016 (KB5006993)
5006994 BCC values not retained in Sent Items in a shared mailbox in Exchange Server 2019 and 2016 (5006994)
5006995 Korean email messages display some recipients incorrectly in Exchange Server 2019 and 2016 (KB5006995)
5006996 Export-AutoDiscoverConfig exposes admin password and does not work against domain controllers that require signing (KB5006997)
5006997 Korean messages in OWA display “From” as “Start date” after you filter the list in Exchange Server 2019 and 2016
5007042 Error window appears when you view features in OWA Virtual Directory (KB5007042)
5007043 Exchange Server SU updates Add/Remove Programs incorrectly (KB5007043)
Notes:
If these Cumulative Updates contain schema changes compared to the Cumulative Update you have deployed, you need to run Setup with /PrepareSchema. If they contain Active Directory changes, you need to run /PrepareAD. Alternatively, permissions permitting, you can let Setup perform this step. Consult the Exchange schema versions page for schema and related versioning information.
When upgrading from an n-2 or earlier version of Exchange, or an early version of the .NET Framework, consult Upgrade Paths for CU’s & .NET.
Don’t forget to put the Exchange server in maintenance mode prior to updating. Regardless, setup will put the server in server-wide offline mode post-analysis, before making actual changes.
When using Exchange hybrid deployments or Exchange Online Archiving (EOA), support requires you to trail at most one version (n-1).
If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
Cumulative Updates can be installed directly; no need to install RTM prior to installing Cumulative Updates.
Once upgraded, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles.
The recommended upgrade order is internet-facing, non-internet-facing servers first, followed by Edge Transports.
Caution:
As for any update, I recommend to thoroughly test updates in a test environment prior to implementing them in production. When you lack such facilities, hold out a few days and monitor the comments on the original publication or forums for any issues.
With the introduction of Exchange 2010 at the end of 2009, a native feature was added to Exchange Server for which organizations required 3rd party products before that. The feature which I am talking about is Exchange’s Personal Archives, Online Archives, or In-Place Archiving as it is called nowadays.
Background Archives were introduced at a time when Office 365 was in its early days, many organizations were running Exchange on-premises with mailbox quotas as bandwidth and storage were limited or relatively expensive. It was up to end users to make sure their mailbox remained within its limits, either by removing either old items, large items or just move them out of their mailbox to those pesky .PST files.
Archives introduced benefits such as lowering disk footprint by taking infrequently used items out of the primary mailbox (which then could only synchronize in full) to the archive, which is basically an additional mailbox for long-term storage. Exchange’s built-in Messaging Records Management (MRM) through retention policies and tags can be used for automatic moving of older items to the archive.
Archives also come with few downsides, especially in the early days. Most notably are perhaps clients not supporting archives at all, or searches not spanning both mailbox and archive. Also, and this is not to be underestimated, end users do not always grasp the concept of archives and the impact on the tasks and tools they use. It’s not uncommon to see people panicking about “missing data” in service tickets, only to discover their “missing data” was moved to their archive by the company retention policy after some digging.
In recent years, I have seen archives becoming less relevant, and organizations adopting the large mailbox concept in favor of lean and mean mailboxes with archives. There are still exceptions of course, usually in the form of substantial – usually shared – mailboxes. For those, staying with Exchange Online archives – and when needed auto-expanding archives – is usually still an option due to the different type of mailbox interaction, or to circumvent Exchange’s storage limitations or Outlook for Desktop’s synchronizing of offline cache files before issues might be seen. The maximum number of items per folder is such a limit, however these have been raised or done away with in recent years. Non-stubbing 3rd party archive solutions taking data out of Exchange can also be a option.
The Problem Switching to the large mailbox concept creates a problem for those organizations that have already enabled in-place archives for their end users: How to get that data back from those archives to the primary mailbox. While retention policies can move data in opposite direction, there is no such thing as a reverse-retention policy. Also, not every organization would like to instruct end users to unarchive this contents themselves, as it is prone to failure, blocks Outlook for Desktop from doing anything else and might result in abandoned operations which limits future actions as moves are still happening in the background.
When investigating a possible solution I found that there is no other way to accomplish this, than to programmatically move contents from the in-place archive to the primary mailbox. While there is a ‘archive’ operation for mailbox items (which moves it to the assigned Archive folder, not the in-place archive) there is no other single API call to perform this task. Also, the solution would have to use Exchange Web Services, as a limitation in Microsoft Graph makes it incapable of moving messages between multiple mailboxes.
Note: If I overlooked something in this area, please let me know.
Solution To help organizations accomplish this task, I wrote a PowerShell script which requires the following:
Exchange Server 2013 SP1 or later, or Exchange Online.
Exchange Web Services (EWS) Managed API 2.21 or later (how to, NuGet package exchange.webservices.managed.api).
When using OAuth, the MSAL library is required (NuGet package Microsoft.Identity.Client). Also, you need to have registered an App in Azure Active Directory; the Tenant ID, Application ID and certificate or secret is what you need to provide the script with to operate successfully.
In addition to installing the NuGet packages, you can also store the DLLs in the same folder as the script.
Note: Untested with Primary mailboxes on-premises and Exchange Online Archives.
The script Invoke-Unarchive will perform the following tasks:
Invoke-Unarchive will move contents from the in-place archive back to the primary mailbox.
The most optimal operation will be chosen:
Folders present in archive but not in primary mailbox will be moved in one operation.
Folders present in archive and primary mailbox are merged. Items in those folders are moved in batches.
The same steps are repeated recursively per folder for the whole archive.
If, after moving, a folder in the archive is empty, and it is not a non-removable well-known folder, it will be removed.
Optionally, Invoke-Unarchive can also move contents stored in the Recoverable Items from the archive to the primary mailbox.
Invoke-Unarchive will handle throttling, either by honoring the returned back-off period or by adding delays between operations.
Moving items is asynchronous, and Invoke-Unarchive needs to wait for Exchange to complete the previous move to folder X before it can move the next set of items to folder X.
Do not forget to reassign retention policies causing archival, or you might have the run the script again at later moment.
Syntax The parameters to call Invoke-Unarchive.ps1 are:
Identity to specify one or more mailboxes to unarchive items for.
Server to specify the FQDN of the Client Access Server to use. When omitted, Autodiscover will be used.
IncludeRecoverableItems to instruct the script to process deletions stored in the Recoverable Items as well.
Impersonation to use impersonation when accessing the mailbox. When using modern authentication (OAuth), impersonation is mandatory.
Force to force moving of items without prompting.
NoProgressBar to prevent progress status.
TrustAll to accept all certificates including self-signed certificates.
TenantId specifies the ID of the Tenant when using a mailbox hosted in Exchange Online.
ClientId to specify the Application ID of the registered application in Azure Active Directory.
Credentials to specify the Basic Authentication credentials for on-premises usage or against Exchange Online when OAuth is not an option.
CertificateThumbprint is the thumbprint of the certificate to use for OAuth. The certificate with the public key needs to stored with the registered application for authentication. The certificate with the private key should be present in the local certificate store.
CertificateFile and CertificatePassword to specify the file of the certificate to use. The file shoud contain the private key, and the password to unlock the file can be specified using CertificatePassword.
Secret can be used to specify the secret to authenticate using the registered application.
Note that Credentials, CertificateThumbprint, CertificateFile + CertificatePassword and Secret are mutually exclusive.
Example Below shows an example run against a test-mailbox using modern authentication (OAuth). The common parameter Verbose is used to display additional output.
Final Notes The EWS operation – especially moving items – is not necessarily slow, but against Exchange Online processing large archives can take considerable amount of time due to throttling. When moving a significant number of items using Outlook for Desktop, you will likely run into Outlook abandoning the operation after which you need to wait for Exchange to finish pending moves before you can continue with this task. Using the script, you can take away this unarchiving task from end users by running the operation in the background in one or multiple runs.
A new Microsoft MVP award cycle, a new moment to have a look at the MVP statistics. Below numbers are taken from the public MVP site. While July 1st is the first day of the new award cycle, it usually is recommended to wait few days for the site and data behind it to get updated. and new and renewed awardees turning in their Non-Disclosure Agreement before showing up on the site. Because people get awarded every month, the comparison to July of every year should give an idea of the yearly trend.
Disclaimer: A percentage of MVP awardees are anonymous, and do not disclose information regarding expertise or location. There are currently 133 anonymous MVPs, and they are not taken into account in below statistics.
The following table contains the awardees per award category from July of 2019, 2020 and 2021, and change percentage compared to the year before. I will leave the interpretation up to you.
Expertise
Jul2019
Jul2020
%
Jul2021
%
Cloud and Datacenter Management
232
209
-10%
219
5%
Microsoft Azure
409
463
13%
534
15%
Office Apps & Services
491
512
4%
556
9%
Business Applications
166
240
45%
323
35%
Data Platform
332
358
8%
392
9%
Developer Technologies
644
697
8%
770
10%
Enterprise Mobility
106
113
7%
133
18%
AI
84
122
45%
138
13%
Office Development
47
64
36%
69
8%
Windows Development
119
110
-8%
120
9%
Windows and Devices for IT
57
43
-25%
42
-2%
Total
2687
2931
9%
3296
12%
Count
2634
2849
8%
3223
13%
Note: The total number of MVPs doesn’t equal the total number of awardees, as MVPs can be awarded in more than one category. A total of 77 MVPs are awarded in two or more categories.
When zooming in on the Office Apps & Services category, the awards per country are shown below, including the % change compared to last year. As you might notice, there are quiet a number of new countries being represented: Ghana, Greece, Peru, Senegal and Vietnam. This supports the current Diversity & Inclusion mindset, and in my opinion is a good thing.
Country
Number
Country
Number
Country
Number
Country
Number
AUS
26 (8%)
FRA
22 (22%)
NZL
6 (0%)
LKA
1 (0%)
AUT
3 (0%)
DEU
30 (25%)
NGA
3 (50%)
SWE
10 (11%)
BEL
5 (0%)
GHA
1 (100%)
NOR
6 (0%)
CHE
3 (0%)
BIH
1 (0%)
GRC
1 (100%)
PAK
1 (0%)
TWN
4 (0%)
BRA
10 (25%)
HUN
2 (0%)
PER
1 (100%)
THA
2 (0%)
BGR
3 (50%)
IND
12 (-8%)
POL
6 (0%)
NLD
22 (0%)
KHM
1 (0%)
IRL
2 (100%)
PRT
3 (0%)
TUR
2 (0%)
CAN
34 (3%)
ISR
3 (200%)
RUS
9 (0%)
UKR
2 (0%)
CHN
17 (0%)
ITA
5 (0%)
SAU
1 (0%)
ARE
2 (100%)
COL
6 (20%)
JPN
20 (0%)
SEN
1 (100%)
GBR
38 (15%)
HRV
5 (0%)
KOR
14 (16%)
SRB
1 (0%)
USA
131 (6%)
CZE
2 (0%)
MKD
2 (0%)
SGP
4 (33%)
URY
1 (0%)
DNK
6 (0%)
MYS
1 (0%)
SVK
1 (0%)
VNM
1 (100%)
EGY
1 (0%)
MEX
7 (40%)
SVN
2 (0%)
SLV
1 (0%)
MMR
1 (0%)
ZAF
4 (0%)
FIN
6 (50%)
NPL
1 (0%)
ESP
14 (16%)
And finally, the number of Office Apps & Services and total number of MVP’s over the last years.
OAS & Total PER CYCLE
Jul2017
Jul2018
Jul2019
Jul2020
Jul2021
Office Apps & Services MVPs
449
383
491
512
535
% Change
-15%
28%
4%
4%
Total MVPs
3490
3030
2634
2849
3223
% Change
-13%
-13%
8%
13%
If you have questions or comments, please leave them in the comments below.
When looking at the MSRC information, you will notice 3 additional CVE issues addressed for July 13th. However, as far as I can see CVE-2021-34473, CVE-2021-34523 and CVE-2021-33766 were addressed in the April 2021 and eventually the May 2021 Security Updates, which also would explain MSRC’s mention of earlier CUs, such as Exchange 2019 CU8.
CVE-2021-33768 does not seem applicable to Exchange 2019 CU9 or Exchange 2016 CU20.
CVE-2021-34470 is only addressed in the security update for Exchange 2013 CU23.
More detailed information can be found at the original blog post here, which mentions some specific post-deployment instructions:
When running n-1 CU of Exchange 2019 (CU9) or Exchange 2016 (CU20), and you do not plan to upgrade to the latest CU yet but do wish to install this Security Update, you must also update the AD Schema using the CU10 or CU21 installation files.
When you are running Exchange 2013 CU23 in your organization, and no later Exchange builds are present, you need to deploy a schema update immediately after deploying the Security Update. After deploying the SU, from an elevated CMD prompt, run Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms from Exchange’s bin folder. You you need to separate the update from deploying the update, see end of article for a tip.
The blog also mentions some issues, which are identical to the ones mentioned with the May 2021 Security Updates:
Accounts ending in ‘$’ cannot use EMS or access the ECP.
Cross-forest Free/Busy might stop working resulting in 400 Bad Request (solution).
Running cmdlets against EMC using invoked runspace might result in no-language mode error (info).
Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU9 to Exchange 2019 CU8. Also, the security update download has the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level, e.g. Exchange2019-CU9-KBXXXXXX-x64-en.msp.
On another note, after deploying the security updates Exchange will start reporting its version number in the HTTP response header.
As a reminder, run the Security Update from an elevated command prompt to prevent issues during installation. In other words: Do not just double-click on the .MSP file. And on a final note, as with any patch or update, I’d recommend to apply this in a acceptance environment first, prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates, and follow a more agile approach. The rating implies a form of urgency.
OWA/ECP and HMAC errors There are reports of the Security Update breaking OWA/ECP. Symptoms are browsers displaying an HMAC error:
Server Error in '/owa' Application.
ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1
It is likely related to “Microsoft Exchange Server Auth Certificate”, which can be expired, invalid or for other reasons not being picked up. The reported solution is renewing the “Microsoft Exchange Server Auth Certificate”. This procedure can be found here. Do note that it may take an hour for the certificate to become effective. Meanwhile, you can check the comments in the original Exchange Team post, which is lively with feedback and responses.
Exchange 2013 CU23 SU & Schema Updating Because with Exchange 2013 CU23 schema preparation needs to occur immediately after deploying the SU on (the first) Exchange 2013 CU23 server, a tip might be that you could deploy Exchange 2013 CU23 Management Tools on a workstation, install the SU on that workstation, then run the PrepareSchema from there before deploying the SU on any Exchange 2013 CU23 server.
This might also be helpful in multi-domain organizations, or organizations where AD and Exchange are managed by different teams or require separate changes. Note that performing the schema update this way requires Visual C++ 2012 Runtime, otherwise you will run into a “Exchange Server setup didn’t complete the operation” and the ExchangeSetup.log will contain “Could not load file or assembly ‘Microsoft.Exchange.CabUtility.dll”.
The Exchange Team released the quarterly Cumulative Updates for Exchange Server 2019 and Exchange 2016. Biggest change for both editions is support for Anti-Malware Scan Interface (AMSI) integration, available on Windows Server 2016 and Windows Server 2019. It allows real-time scanning of HTTP payloads, blocking known malicious content before it reaches Exchange.
Links to the updates as well as a description of changes and fixes are described below. The column Schema and AD indicate if the CU contains Schema (/PrepareSchema) and Active Directory (PrepareAD) changes compared to the previous CU.
5004612 Message body not displayed in OWA if the message was added in Outlook to a new mailbox
5004613 OutOfMemory exception when moving a public folder that has a large ICS sync state
5004614 Korean text is garbled in calendar invitation to a user with a Chinese display name
5004615 “InvalidOperationException” and Store Worker process crashes during mailbox move
5004616 Changing the email address in EAC doesn’t work in modern browsers
5004617 TLS 1.2 is not set as default after you install Exchange 2019 with Edge Transport role
5004618 MSExchangeMailboxAssistants 4999 Crash in ELCAssistant.InvokeInternalAssistant with System.NullReferenceException
5004619 Mailbox creation through ECP fails after installing Exchange Server 2019 or 2016 April update
5004622 “Cannot Send Mail – Your mailbox is full” error when you use iPhone mail to send very large attachments
5004623 PrepareADSchema required because of Active Directory schema change
Exchange 2016 CU21 fixes:
5004612 Message body not displayed in OWA if the message was added in Outlook to a new mailbox
5004613 OutOfMemory exception when moving a public folder that has a large ICS sync state
5004614 Korean text is garbled in calendar invitation to a user with a Chinese display name
5004615 “InvalidOperationException” and Store Worker process crashes during mailbox move
5004616 Changing the email address in EAC doesn’t work in modern browsers
5004618 MSExchangeMailboxAssistants 4999 Crash in ELCAssistant.InvokeInternalAssistant with System.NullReferenceException
5004619 Mailbox creation through ECP fails after installing Exchange Server 2019 or 2016 April update
5004622 “Cannot Send Mail – Your mailbox is full” error when you use iPhone mail to send very large attachments
5004623 PrepareADSchema required because of Active Directory schema change
5004629 No version updating after you install Exchange Server 2016
Notes:
If these Cumulative Updates contain schema changes compared to the Cumulative Update you have deployed, you need to run Setup with /PrepareSchema. If they contain Active Directory changes, you need to run /PrepareAD. Alternatively, permissions permitting, you can let Setup perform this step. Consult the Exchange schema versions page for version number comparison.
When upgrading from an n-2 or earlier version of Exchange, or an early version of the .NET Framework, consult Upgrade Paths for CU’s & .NET.
Don’t forget to put the Exchange server in maintenance mode prior to updating. Regardless, setup will put the server in server-wide offline mode post-analysis, before making actual changes.
When using Exchange hybrid deployments or Exchange Online Archiving (EOA), support requires you to trail at most one version (n-1).
If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
Cumulative Updates can be installed directly; no need to install RTM prior to installing Cumulative Updates.
Once upgraded, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles.
The recommended upgrade order is internet-facing, non-internet-facing servers first, followed by Edge Transports.
Caution:
As for any update, I recommend to thoroughly test updates in a test environment prior to implementing them in production. When you lack such facilities, hold out a few days and monitor the comments on the original publication or forums for any issues.
EighTwOne (821) 