Security Updates Exchange 2013-2019 (Nov2020)

A quick blog on security updates for Exchange Server 2013, 2016 and 2019 released November 10th. These fixes address the following vulnerability:

  • CVE-2020-17085: Microsoft Exchange Server Denial of Service Vulnerability
  • CVE-2020-17084: Microsoft Exchange Server Remote Code Execution Vulnerability
  • CVE-2020-17083: Microsoft Exchange Server Remote Code Execution Vulnerability

The exploits can be fixed by single security update, which you can find in the table below per current Exchange version.

ExchangeDownloadBuildKBSupersedes
Exchange 2019 CU7Download15.2.721.4KB4588741
Exchange 2019 CU6Download15.2.659.8KB4588741
Exchange 2016 CU18Download15.1.2106.4KB4588741
Exchange 2016 CU17Download15.1.2044.8KB4588741
Exchange 2013 CU23Download15.0.1497.8KB4588741

Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2016 CU17 to Exchange 2016 CU16. 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-CU6-KB4588741-x64-en.msp.

Also, run the Security Update from an elevated command prompt, to prevent issues during installation. 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.

Security Updates Exchange 2013-2019 (Oct2020)

A quick blog on security updates for Exchange Server 2013, 2016 and 2019 released October 13th. These fixes address the following vulnerability:

  • CVE-2020-16969: Microsoft Exchange Information Disclosure Vulnerability
    An information disclosure vulnerability exists in how Microsoft Exchange validates tokens when handling certain messages. An attacker who successfully exploited the vulnerability could use this to gain further information from a user.

    To exploit the vulnerability, an attacker could include specially crafted OWA messages that could be loaded, without warning or filtering, from the attacker-controlled URL. This callback vector provides an information disclosure tactic used in web beacons and other types of tracking systems.

    The security update corrects the way that Exchange handles these token validations.

The exploits can be fixed by single security update, which you can find in the table below per current Exchange version.

ExchangeDownloadBuildKBSupersedes
Exchange 2019 CU7Download15.2.721.3KB581424
Exchange 2019 CU6Download15.2.659.7KB581424KB4577352
Exchange 2016 CU18Download15.1.2106.3KB581424
Exchange 2016 CU17Download15.1.2044.7KB581424KB4577352
Exchange 2013 CU23Download15.0.1497.7KB581424KB4536988

Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2016 CU17 to Exchange 2016 CU16. 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. Exchange2016-CU17-KB4581424-x64-en.msp.

Also, run the Security Update from an elevated command prompt, to prevent issues during installation. 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.

EWS.WebServices.Managed.Api

A short blog on the EWS Managed API and using the latest version with scripts leveraging Exchange Web Services (EWS), such as my Remove-DuplicateItems script. The installable EWS Managed API library was last updated in 2014 (version 2.2, reports as v15.0.913.22), and there have been few enhancements since then. These are included in the EWS.WebServices.Managed.Api package, which carries version 2.2.1.2.

Although this library was last updated in 2019, you might still need it to successfully run EWS scripts. The EWS.WebServices.Managed.Api package supports some Exchange Web Services calls which are not supported in the 2.2 version, and may lead to error messages like Exception calling β€œFindFolders” with β€œ2” argument(s) or other messages related to the (number of) arguments. This may be an indication a particular call was used to one of the EWS functions, but which is not supported by the installed EWS Managed API library. In those cases, installing this updated library might help.

The library is published on NUGet as a package. To install the package, we first need to register NuGet as a Package Source:

Register-PackageSource -provider NuGet -name nugetRepository -location https://www.nuget.org/api/v2

Next, install the package from the newly defined NuGet source:

Install-Package Exchange.WebServices.Managed.Api

The package installs by default under C:\Program Files\PackageManagement\NuGet\Packages. I have updated my scripts to include this location when searching for the required Microsoft.Exchange.WebServices.dll as well. Alternatively, you can copy this DLL from the ..\Exchange.WebServices.Managed.Api.<Version>\lib\net35 folder to the location where the script resides. When running my EWS-based scripts in Verbose mode, it will report as version 2.2.1.0.

Hopefully this blog will potentially save you some time troubleshooting, and myself answering some support messages. Enjoy!

Ignite: Outlook Calendaring Update

In the Ignite talk Outlook Calendar: Fundamentals and Collaboration, the unequaled Julia Foran laid out tons of new and coming features for the various Outlook platforms in relation to calendaring. You can watch the video on the Virtual Hub.

I tried to capture those in below table. For more information for some of these features, please watch the recording

FeatureWinMacOWAiOSAnd
Personal calendar side-by-side
(Hotmail/Live/MSN, Google)
βœ”βœ”β­βœ”βœ”
Connect Shared & Delegated Mailboxesβœ”βœ”βœ”β­β­
Importing of ICS attachmentsβœ”βœ”β­πŸ•’β­
Calendar To-Do pane (My Day)βœ”β­β­
Calendar To-Do pane showing Tasks (My Day)βœ”πŸ•’
Calendar To-Do pane multiple Months supportβœ”1
Suggested Timesβ”β­βœ”πŸ•’πŸ•’
Advanced Room Finderβœ”1β­βœ”
Room Suggestions for Recurring Meetingsβ­πŸ•’β­β”β”
Room Suggestions showing Room Capabilities
(leverages Set-Place / Places REST API)
β­πŸ•’β­β”β”
Room Suggestions and Policies integration
AllowRecurringMeeting, BookingWindowInDays, EnforceSchedulingHorizon, MaximumDurationInMinutes
πŸ•’πŸ•’πŸ•’πŸ•’πŸ•’
Finding a Workspace
⭐1⭐⭐⭐⭐
Teams meeting quick-join
In-Calendar, Inbox or Search
⭐⭐⭐⭐⭐
Online meetings by default – OutlookπŸ•’β­β­β­β­
Built-in Breaks – End Late
Built-In Breaks – Start Late
Setting roams clients, org-wide config coming soon
βœ”
πŸ•’
πŸ•’β­πŸ•’πŸ•’
Meeting Insights – Outlook
Meeting Insights – Teams
πŸ•’β­
πŸ•’
βœ”
πŸ•’
⭐
❔
⭐
❔
Full Mailbox Delegates
Delegates receive full calendar permissions instead of the organisation (default) permissions
βœ”βœ”βœ”βœ”βœ”
Week Numbers
Setting not roaming yet
βœ”βœ”β­β­β­
Scheduling with time zone selectionβœ”βœ”βœ”β­βœ”
Sync local device calendars
Sync back in progress, controllable with InTune policy
⭐
Flexible Week Viewβœ”βœ”β­βœ”βœ”
Travel detection with time zone adjustmentβœ”βœ”β­βœ”βœ”
Automatic Removal of orphaned attendees
Attendees that left company get removed from meeting after first NDR to organizer.
πŸ•’πŸ•’πŸ•’πŸ•’πŸ•’

Legend
βœ” : Already available
πŸ•’ : Coming
⭐ : New Feature
❔ : Undetermined

Notes
1) Currently available to Office Insiders

Exchange Announcements @ Ignite 2020

Last Update: Added points from Exchange Online Transport – Manage Email, Optics, End User Experiences.

It shouldn’t come as a surprise that this year’s Ignite event is very different than previous years. However what is also different is that at this year’s digital experience, product groups lined up articles and pre-recorded sessions with deep-dive level 300-400 contents as well as articles to accompany those. The sessions, which are available through the Virtual Hub, were all launched right after the start of the event, including the prepared articles. Speaking of a flood flood of contents to digest.

To ease digesting all this information related to Exchange without going through all the videos and blogs, I prepared a summary of all the announcements made at and during Ignite for your reference. For reference, links to the original articles and sessions are at the bottom of this article. The list might not be conclusive; if you find something missing, let me know.

Exchange vNext

  • Exchange Server vNext is scheduled for H2/2021, and will be subscription-based.
  • Will support in-place upgrades from Exchange Server 2019, just like installing another Cumulative Update. Which makes you think, maybe it is just a CU with a high version offset to avoid clashing with its predecessor.
  • Support for this in-place upgrade process is limited to 2 years after release of vNext. If everything goes to plan, this means upgrades will be supported from Exchange 2019 CU11/12-CU19/20 to Exchange vNext RTM-CU8/9.
  • Will support co-existence with Exchange Server 2013, 2016 and 2019, which is 1 down-level more than previous editions (n-3 support instead of n-2).
  • Customers staying on-premises are recommended to upgrade to Exchange Server 2019 today, so they can benefit from an in-place upgrade to vNext when it gets released.
Image Source: Exchange – Here, There and Everywhere

Exchange Online

  • Exchange Online Management PowerShell module is now GA (v2.0.3). This module contains cmdlets leveraging Graph which can show significant performance enhancements in larger tenants, supports certificate-based authentication a.o.
  • Exchange Online Management PowerShell preview module (v2.0.4) supports Linux and PowerShell Core.
  • Cross-tenant migration of mailboxes is now in Public Preview. Separate programs for cross-tenant SharePoint Online and OneDrive for Business will also launched (register for private preview at aka.ms/SPOMnAPreview). An Azure Key Vault subscription is required on the target tenant. Management of these moves is done from PowerShell, after setting things up with some MSFT scripts which you can grab from GitHub here.
Tenant preparation for mailbox migration.
Image Source: Cross-tenant mailbox migration, process overview
Set-OrganizationConfig -AllowPlusAddressInRecipients $true
  • Message Recall to orchestrate recall of message in Exchange Online as announced at Ignite 2019 is expected later this year (Q4/2020).
  • Admins can toggle the new Exchange Admin Center (was already in preview). It will become the default in Q1/2021.
  • The new Exchange Admin Center is also tailored for use on mobile browsers.
  • Outbound mail flow now supports MTA-STS (MTA Strict Transport Security).
  • The new Exchange Admin Center will host all mail flow related management options, which will be consolidated from the earlier Admin Center as well as the Security & Compliance Center.
  • The new Exchange Admin Center will get new mail flow insights and notifications, such as early certificate expiration notifications or detected reply-to-all storms.
  • Option to reduce message expiration timeout interval from the current default of 24 hours.
  • Administrators get the option to block users from moving groups (distribution groups as well as Microsoft 365 Groups) to the BCC line, which might break receivers’ inbox rules (Q1/2021).
  • Entitled organizations can appoint Priority Users. Priority Users are critical mailboxes that are monitored for mail flow issues. Requires minimum of 10,000 Office 365 E3 or E5 or Microsoft 365 E3 or E5 licenses with at least 50 monthly active Exchange Online users.
  • Microsoft 365 Network Connectivity functionality goes into preview, which is accessible via the admin portal (Health > Network Connectivity).
  • The stand-alone Network Connectivity test tool also goes in preview, and is available from connectivity.office.com.
  • Notifications for expired or soon to expire SSL certificates and Domains (Q4/2020).
  • Customizable message expiration (8-24hours, Q4/2020).
  • Reply-to-All storm protection v2 with customizable thresholds and reports (Q4/2020-H1/2021).
  • Client-agnostic improved Message Recall (Q4/2020).

Exchange 2019

  • Exchange Server 2019 Server Role Requirements Calculator or just Capacity Calculator is now available as separate download (v10.5, link).

Exchange Hybrid

  • New Exchange Hybrid Configuration Wizard, which will become available later month, will support connecting your Exchange on-premises environment to multiple tenants. Note that multiple Exchange organizations connecting to a single tenant was already an option, as mentioned in the supported Azure AD Connect topologies document (link).
Image Source: September 2020 Hybrid Configuration Wizard Update – Microsoft Tech Community
  • Multitenancy Exchange Hybrid will support up to 5 tenants.
  • Setting multitenancy up requires Exchange Server 2019 CU7 or Exchange Server 2016 CU18 or later.
  • Multitenancy does not enable SMTP domain sharing, which is logical as you can only setup domain once in Office 365.
  • Exchange Hybrid Modern Authentication (HMA) can only be configured with one single tenant.

Outlook Desktop/Mac

  • Office will get perpetual release (Windows & Mac) in H2/2021.
  • Attendees who left company get removed from meeting after first NDR.

Outlook Mobile

  • Play My Emails coming to Canada, Australia, India and the United Kingdom (Outlook for iOS and Android).
  • Option to ask Cortana to read out emails from specific people, time frame and topics in (Outlook for iOS, September).
  • Voice commands for email composition, calling and scheduling (October).
  • Sync contact folders with your phone by category (October).
  • Reactions to emails with emojis without filling your inbox (Q4)
  • QR connect to simplify work account setup (October).
  • Outlook for Mac will start using Microsoft Sync technology for enhanced performance and reliability. 
  • Widget support for iOS14 across apps.
  • Option to toggle new Outlook for Mac via in-app switch.

References to official sources

Module Updates: What’s New?

After updating your PowerShell modules which support managing parts of the Microsoft 365, some of us are curious about what changes are introduced with the updated module. In the world of continuous change, it is hard to keep track of these changes. New cmdlets or parameters get added to support new features, and some get removed as they become obsolete. So, how to discover what those changes are after updating to the latest module?

Time to blog on a small script I created for this purpose a long time ago, Compare-Cmdlets.ps1. This script has two operating modes:

  • Export currently available cmdlets and parameters for supported modules.
  • Compare two exports of cmdlets & parameters and report the differences.

Currently, the following command sets are supported:

ModuleTest CmdletExport File
AzureADGet-AzureADUserAzureAD-<version>.xml
ExchangeOnlineGet-MailboxExchangeOnline-<version>.xml
ExchangeOnlineManagementGet-ExoMailboxExchangeOnlineManagent-<version>.xml
MicrosoftOnlineGet-MsolUserMSOnline-<version>.xml
TeamsGet-TeamMicrosoftTeams-<version>.xml

Command sets are exported per module, where a module is assumed to be present by a simple check for cmdlet availability (specified in column Test Cmdlet). That is, if Get-Mailbox is available, the ExchangeOnline module is assumed to be available. It does not distinguish between the Exchange PowerShell module or ‘classic’ Remote PowerShell session, nor will it take into account the repository origin of the module, nor if the Get-AzureADUser is coming from the AzureAD or AzureADPreview module.

That said, here’s how this is works. Load up PowerShell and have your modules installed and ready. Some modules like ExchangeOnlineManagement require connecting to the service first to import the cmdlet functions, so for ExchangeOnlineManagement run Connect-ExchangeOnline first. Same applies to the newer Teams modules, where the Skype Connector functions are only available after running New-CsOnlineSession.

Then run Compare-Cmdlets to export the cmdlets and parameters for those modules. The commands will by default be exported to an XML in a subfolder named ‘data’. The name of the file is mentioned in the table above. If you want to use a different folder to store the XML files, use DataFolder parameter.

Note that with Exchange, the cmdlets available to you depend on which role you have been assigned in Exchange’s Role-Based Access Control model. For example, if you haven’t explicitly assigned Mailbox-ImportRequest to your account, you will not see it in the exports. Therefor, when exporting module changes, it is required using an account with the same roles assigned to have proper exports. But when needed, you can also use it to report on command set differences between two Exchange Online accounts.

After updating some of the modules, or downloading one of the command set reference XMLs I stored with the script on GitHub, you can use Compare-Cmdlets to compare different versions of module exports. For example, to compare the cmdlets of Microsoft Teams module 1.1.4 with those after updating to 1.1.5, use

.\Compare-Cmdlets.ps1 -ReferenceCmds data\MicrosoftTeams-1.1.4.xml -DifferenceCmds data\MicrosoftTeams-1.1.5.xml

From the output, we see for example that:

  • The cmdlet Get-TeamChannel has a new GroupId parameter.
  • The cmdlet New-CsGroupPolicyAssignment parameter PolicyType has been removed.
  • The cmdlet Add-TeamChannelUser is new.

Note that common parameters (e.g. Verbose and ErrorAction) and optional common parameters (e.g. WhatIf) are left out of the equation. Also, parameters are not compared in depth and only presence is checked. If for example a parameter changes type (e.g. string to multivalue), Compare-Cmdlets does not pick that up.

As-is, the script is made to run on demand from an interactive PowerShell session. Ideally, this would run scheduled and serverless from within the service, reporting changes by e-mail.

The script Compare-Cmdlets.ps1 can be downloaded from GitHub here. If you find this useful, would like to comment or have suggestions, use the comments below or leave them on GitHub.

Exchange Updates – September 2020

The Exchange Team released the quarterly Cumulative Updates for Exchange Server 2019 as well as Exchange 2016. Like recent Cumulative Updates for these products, they require .NET Framework 4.8. Apart from fixes as well as security updates included from the previous CU, the Exchange 2019 CU7 also comes with an update for the Exchange Sizing Calculator.

Links to the updates as well as a description of changes and fixes are described below.

VersionBuildKBDownloadUMLPSchemaPrepareAD
Exchange 2019 CU715.2.721.2KB4571787VLSC NY
Exchange 2016 CU1815.1.2106.2KB4571788DownloadUMLPNY

Exchange 2019 CU7 fixes:

  • 4570248 Get-CASMailbox uses wrong LDAP filter for ECPEnabled in Exchange Server 2019
  • 4576652 Updates for Exchange Server 2019 Sizing Calculator version 10.5
  • 4570252 Intermittent poison messages due to NotInBagPropertyErrorException in Exchange Server 2019
  • 4576649 System.InvalidCastException when you change passwords in Outlook on the web in Exchange Server 2019
  • 4570251 Inbox rule applying a personal tag doesn’t stamp RetentionDate in Exchange Server 2019
  • 4570245 ESEUtil /p fails if any long value (LV) is corrupted in Exchange Server 2019
  • 4570255 NullReferenceException occurs when running TestFederationTrust in Exchange Server 2019
  • 4576650 Can’t add remote mailbox when setting email forwarding in Exchange Server 2019 Hybrid environment
  • 4570253 CompletedWithErrors without details for mailbox migration batches in Exchange Server 2019
  • 4570247 CSV log of Discovery export fails to properly escape target path field in Exchange Server 2019
  • 4570246 EdgeTransport crashes with Event ID 1000 (exception code 0xc00000fd) in Exchange Server 2019
  • 4570254 MSExchangeMapiMailboxAppPool causes prolonged 100% CPU in Exchange Server 2019
  • 4563416 Can’t view Online user free/busy status in Exchange Server 2019
  • 4576651 Can’t join Teams meetings from Surface Hub devices after installing Exchange Server 2019 CU5
  • 4577352 Description of the security update for Microsoft Exchange Server 2019 and 2016: September 8, 2020

Exchange 2016 CU18 fixes:

  • 4570248 Get-CASMailbox uses wrong LDAP filter for ECPEnabled in Exchange Server 2016
  • 4570252 Intermittent poison messages due to NotInBagPropertyErrorException in Exchange Server 2016
  • 4576649 System.InvalidCastException when you change passwords in Outlook on the web in Exchange Server 2016
  • 4570251 Inbox rule applying a personal tag doesn’t stamp RetentionDate in Exchange Server 2016
  • 4570245 ESEUtil /p fails if any long value (LV) is corrupted in Exchange Server 2016
  • 4570255 NullReferenceException occurs when you run TestFederationTrust in Exchange Server 2016
  • 4576650 Can’t add remote mailbox when setting email forwarding in Exchange Server 2016 Hybrid environment
  • 4570253 CompletedWithErrors without details for mailbox migration batches in Exchange Server 2016
  • 4570247 CSV log of Discovery export fails to properly escape target path field in Exchange Server 2016
  • 4570246 EdgeTransport crashes with Event ID 1000 (exception code 0xc00000fd) in Exchange Server 2016
  • 4570254 MSExchangeMapiMailboxAppPool causes prolonged 100% CPU in Exchange Server 2016
  • 4563416 Can’t view Online user free/busy status in Exchange Server 2016
  • 4576651 Can’t join Teams meetings from Surface Hub devices after installing Exchange Server 2016 CU16
  • 4577352 Description of the security update for Microsoft Exchange Server 2019 and 2016: September 8, 2020

Notes:

  • These Cumulative Updates do not contain schema changes compared to their previous Cumulative Update.
  • There are Active Directory changes requiring you to run PrepareAD. Consult the Exchange schema versions page for object version numbers.
  • 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), you are allowed 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 installed, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles.
  • The order of installation shouldn’t matter with the β€œevery server is an island” concept, yet recommended is to upgrade 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.

Security Updates Exchange 2016-2019 (Sep2020)

A quick blog on security updates for Exchange Server 2016 and Exchange Server 2019 released September 8th. These fixes address the following vulnerability:

  • CVE-2020-16875: Exchange Memory Corruption Vulnerability
    A remote code execution vulnerability exists in Microsoft Exchange server due to improper validation of cmdlet arguments. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the System user. Exploitation of the vulnerability requires an authenticated user in a certain Exchange role to be compromised. The security update addresses the vulnerability by correcting how Microsoft Exchange handles cmdlet arguments.

The exploits can be fixed by single security update, which you can find in the table below per current Exchange version.

ExchangeDownloadBuildKBSupersedes
Exchange 2019 CU6Download15.2.659.6KB4577352KB4540123
Exchange 2019 CU5Download15.2.595.6KB4577352KB4540123
Exchange 2016 CU17Download15.1.2044.6KB4577352KB4540123
Exchange 2016 CU16Download15.1.1979.6KB4577352KB4540123

Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2016 CU17 to Exchange 2016 CU16. 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. Exchange2016-CU17-KB4577352-x64-en.msp.

Also, run the Security Update from an elevated command prompt, to prevent issues during installation. 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.

Self-Service Purchasing II

It was in October 2019, that by means of Message Center bulletin MC163609 Microsoft announced that end users would receive the self-service purchasing option for Power Platform licenses (PowerBI, PowerApps and Flow). The announcement received quite some negative feedback, mostly because of the absence of administrative controls, with the risk of bypassing corporate purchasing as well as potential legal implications. Microsoft delayed the introduction, to launch it few months later in January this year, including the much requested controls.

Now MC220282 has appeared in the Office 365 Message Center, which announces the same self-service purchasing options for Microsoft Visio Plan 1 & 2 and Microsoft Project Plan 1 & 3. These purchasing options becomes available per September 15th.

The Message Center bulletin reads, “This change will not impact any existing settings you may have in place to manage self-service purchasing”. While true, administrators still might be faced with unexpected self-service capabilities for these new licenses. In this blog, I’ll talk you quickly through how to start managing these self-service capabilities, and how to modify these new ones.

Connecting and Managing

To start managing self-service capibilities, you need to install the MSCommerce PowerShell module, which Microsoft published at the PowerShell Gallery:

Install-Module MSCommerce

If you previously installed MSCommerce, update your module using:

Update-Module MSCommerce -Force

The current version of the module at the time of writing is 1.6. Now, to starting using the cmdlets provided in the module, you need to first connect to your Office 365 tenant:

Connect-MSCommerce

After completing login and succesfully completing any multi-factor authentication challenge, you can inspect the current self-service capabilities policy. First, there is a global policy named AllowSelfServicePurchase, which can be inspected using:

Get-MSCommercePolicies | Select PolicyId
Get-MSCommercePolicy -PolicyId AllowSelfServicePurchase | fl

As you can see, the default option for purchasing options is set to Enabled. This value can’t be modified, which means every new product added to self-service purchasing will be enabled by default. This also means admins may need to monitor the message center for self-service purchasing changes, and when required proactively monitor and disable this capability for new products. To inspect the current setting for every current product, use:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

As you can see, the self-service purchasing for the Power Platform products have been disabled. However, because the DefaultValue is Enabled, the purchase capabilities for these new products have been set to Enabled. If we want to disable this capability for these products, use the following cmdlet:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | % { Update-MSCommerceProductPolicy -PolicyId $_.PolicyId -ProductId $_.ProductId -Enabled $false }

Note that self-service purchase capabilities are not available for Office 365 Government, Nonprofit, and Education tenants.

Approval Flow

In another bulletin (MC213897), Microsoft announced the roll-out of an feature for end users to request licenses trough a customizable message or workflow. This option should become available when self-service purchasing has been disabled. It allows admins assign requested licenses from the pool or make required purchases, and also report on these requests to track interest. The bulletin has been updated recently to mark completion of roll-out of the message part of this feature; the request part is scheduled for completion in September. Unfortunately, I haven’t been able to locate settings related to these features yet, but these might appear any time soon. The screenshot from the bulletin gives an indication of what to expect:

To read more information on Self-Service Purchasing capabilities in the Self-Service Purchase FAQ,

Exchange Online Management using EXOv2 module

Exchange2019Logo

Update (22Nov2020) Updated API permissions to reflect removal of Exchange app permissions, replaced with Office 365 Exchange Online permissions.

Early June, Microsoft released a new PowerShell module
for managing Exchange Online. This module got announced at Ignite 2019 already, but it took
few months between going into preview end of last year before it finally reached Generally Available status. Usage of this module offers substantial improvements over the existing methods to connect to Exchange Online using Powershell, such as:

  • Leveraging the PowerShell module ecosystem to install and update the module. This as opposed to the click-to-run Microsoft Exchange Online Powershell Module or connecting through PowerShell remoting.
  • Support for Multi-Factor Authentication. This is something which the click-to-run module also offers but is not available when using PowerShell remoting.
  • Robustness. Existing sessions could easily timeout when you took a short break from the console. Or worse, your script could terminate in the middle of execution. This required you to reconnect or forced you to add resilience to your scripts by handling with these disconnects from the back end. The cmdlets of the EXOv2 module should be more robust and resilient.
  • Introduction of the Graph API support, which should show improvements in terms of speed. Microsoft indicated an 4-8 times improvement should be achievable, but your mileage may vary depending on the operation.
  • Support for PowerShell 6/7, core, and non-Windows operating systems is coming.

Exchange Online Management v2 module

The module has been baptized EXOv2 to indicate a major change compared to the click-to-run module (hereafter referred to as EXOv1), and also because it uses Graph API, just like the AzureAD v2 module. The module is available in the PowerShell Gallery, and installation is straightforward. Open a PowerShell 5.1 or later session in elevated mode and run:

Install-Module ExchangeOnlineManagement

The EXOv2 cmdlets which are REST-based and and leverage Graph API have their nouns prefixed with β€˜EXO’, e.g. Get-EXOMailbox. Currently, there are 9 EXO cmdlets in the GA module, as well as few additional ones (more on those later). The regular commands such get Get-Mailbox are available as well after connecting to Exchange Online. This is similar behavior to the EXOV1 module, e.g.

Connect-ExchangeOnline [-UserPrincipalName <UPN>]

When required, satisfy the Multi-Factor Authentication logon process, and you
are done. Be advised that the EXOv2 module also supports
Delegated Access
Permissions
(DAP), allowing partners to connect to customer tenants by
specifying
-DelegatedOrganization <mycustomer.onmicrosoft.com>
when connecting.

Also note that apart from the EXO cmdlets, the current module also offers few other interesting commands and helper functions apart from the ones for housekeeping:

  • Connect-IPPSSession to connect to Security & Compliance center or Exchange Online Protection, depending on licensing. This command was also available in EXOv1.
  • Get-UserBriefingConfig & Set-UserBriefingConfig. These are a bit out of context, as these commands allow you to enable or disable the Cortana Briefing for users.
  • IsCloudShellEnvironment indicates if you are running from PowerShell or Azure Cloud Shell, which might be useful in scripts to determine the current context.

The EXOv2 cmdlets and their regular equivalents are shown in the table below:

EXO v1 or Remote
PowerShell
EXO v2
Get-MailboxGet-EXOMailbox
Get-MailboxFolderPermissionGet-EXOMailboxFolderPermission
Get-CASMailboxGet-EXOCASMailbox
Get-MailboxFolderStatisticsGet-EXOMailboxFolderStatistics
Get-MailboxPermissionGet-EXOMailboxPermission
Get-MobileDeviceStatisticsGet-EXOMobileDeviceStatistics
Get-RecipientGet-EXORecipient
Get-RecipientPermissionGet-EXORecipientPermission

What you might notice is the absence of any Set-EXO* cmdlets. This is true, and there is no word yet on if and when Set cmdlets will be introduced. That said, the biggest speed gain is often in bulk retrieval of data, not so much in altering one or more attributes. Until then, do not
de
spair though, as you can pipe output of the EXO cmdlets to their regular cmdlet,
e.g.

Get-EXOMailbox michel | Set-Mailbox -EmailAddresses @{Add='michel@myexchangelabs.com'}

This construction will also provide the additional benefit of parallel processing of objects as they pass through the pipeline, but more on that later.

Now comes another thing you should be aware of, and that is that these EXOv2 cmdlets might not use the same parameter sets as their v1 equivalent. Simply said, you cannot perform a simple Find and Replace operation in your script replacing Get-Mailbox with Get-EXOMailbox to start enjoying benefits of the new module.

When running a cmdlet like Get-EXOmailbox, you might notice that it returns only a subset of the attributes you might expect. Similar to what Properties does for Active Directory module, the EXOv2 module requires you to specify the individual Properties to return. Alternatively, you can use PropertySets to select a predefined set of attributes. For example, Get-EXOMailbox supports PropertySets such as All, Minimum (default), Policy, Quota and Retention to name a few. When needed, you can combine PropertySets, so something like the following is possible:

Get-EXOMailbox -Identity michel -PropertySets Quota,Policy

A small note on the PropertySet All: Just like Get-ADUser .. -Properties
*
is considered bad practice as you can impact resource usage and usually return more than what you need, using -PropertySets All
for every call is also a bad idea. All is convenient, but make sure you only return the data you need. Be a good person.

To see which EXOv2 cmdlets support PropertySets, use:

(Get-Command -Noun EXO* -Module ExchangeOnlineManagement).Where{$_.Parameters.propertySets}

Performance

Now, I suppose we want to get an indication of the performance enhancements by comparing EXOv2 and equivalent operation using v1 cmdlets. In this simple example we are returning quota information for some 50.000 mailboxes:

In this case, it is not the 4-8x improvement, but more than twice as fast is significant nonetheless. Especially if you are running interactively. To see the impact of parallel processing in the pipeline, we run the following:

As shown, there is a substantial increase in performance, but of course your mileage may vary depending on things like the number of objects, the attributes you require, and any filtering
applied.
Note that the PropertySet StatisticsSeed used in the example is a very minimal set of attributes which you can use if you only wish the refer to the objects, such as userPrincipalName, primarySmtpAddress and externalDirectoryObjectID.

Speaking of filtering, one would expect that server-side filtering (-Filter) would show an improvement in terms of speed over client-side filtering (Where), as filtering at the source is far more efficient in terms of result set and data to send over. However, it seems that due to the nature of a shared environment, sending superfluous data over the wire is less of a penalty than local filtering. Of course, your mileage may also vary here, so experiment what works best for your situation. Also, not every attribute is supported for filtering with these EXO cmdlets, which lies in how Graph exposes data. More information on that here.

When your session times out or disconnects, you will see that the module tries to reconnect your session; something which you would have to programmatically solve for the v1 module or regular remote PowerShell:

Certificate-based Authentication

Exchange administrators often have a requirement to run unattended scripts against Exchange Online, for example scheduled reports or as part of another process. In the past, this lead to setups where service accounts and stored credentials were used. Later this was improved by the ability to apply Conditional Access to limit these logons to on-premises infrastructure.

The problem with Multi-Factor Authentication is that it requires interaction with end-user to approve the sign-on. Of course, while your token is still valid, you can easily (re)connect to Exchange Online just by providing the Username Principal Name, which will reuse the token if it didn’t expire. But all in all, these solutions are high maintenance, and far from ideal from a security perspective.

Here comes certificate-based authentication, which is supported in version 2.0.3 and up of the EXOv2 module. In short, certificate-based authentication allows you to log on to Exchange Online using:

  • PowerShell
  • EXOv2 module
  • A (self-signed) certificate containing private key
  • Enterprise App registration in Azure Active Directory which contains the public key of this certificate, and proper assigned Azure AD role(s).

Note: Enterprise app registration may require Azure AD P1/P2 license.

To install the EXOv2 2.0.3 version of the module (preview at time of writing), use:

Install-Module ExchangeOnlineManagement -AllowPrerelease

Note that it might complain if you have the GA version of the module installed, in which case you need to uninstall the GA module first, or you can install them side-by-side by specifying -Force.

Next, we need to create a self-signed certificate. To accomplish this, we can use the script published here. To create the certificate, simply use:

.\Create-SelfSignedCertificate.ps1 -CommonName 'EXOv2' -StartDate 7/30/2020 -EndDate 7/30/2021

Note that you need to provide a password to protect the PFX file containing the private key. Also do not forget to import the PFX in your local certificate store. When importing, you can mark the certificate as non-exportable, which prevents admins to transfer the certificate to other systems.

Import-PfxCertificate -CertStoreLocation Cert:\CurrentUser\My -FilePath .\EXOv2.pfx -Password (Read-Host -AsSecureString)

After importing, you can check for the certificate’s presence using:

Get-ChildItem Cert:\CurrentUser\My | Where {$_.Subject -eq 'CN=EXOv2'}

The Subject should be the CommonName you used when generating the certificate. The thumbprint of our certificate is 49A4A73B4696718676770834BCD534DE35030D2C. We are going to use this later on to connect.

Now we need to set things up in Azure Active Directory:

  1. Open up the Azure Active Directory Portal, and navigate to Active Directory.
  2. Select App registrations, and click New registration.
  3. Give the App a meaningful Name, and select Accounts in this organizational directory only. Set Redirect URI to Web and leave the URL blank. Then, click Register.

    clip_image013[4]

    Note that our App has been assigned an Application (Client) ID. Make note of this value, as we will need it to connect later on.
  4. Next, we need to configure the App permissions. Select API permissions. User.Read should show up as default. Click Add a permission, and locate Office 365 Exchange Online from the APIs my organization uses tab. Select Application permissions, and in the next screen expand Exchange and check Exchange.ManageAsApp. We are done here, so click Add permissions.
  5. Only thing left now is to Grant admin consent, which can be done by clicking Grant admin consent for <tenant>. When done, the Status column for Exchange.ManageAsApp permission should have changed to Granted for <tenant>.

    API Permissions
  6. Now we need to associate this App with out certificate. Select Certificates & Secrets, and click Upload certificate. Pick the certificate file which we generated earlier, and select Add.

    clip_image017[4]
  7. Last step is to assign the App one of the built-in Azure AD roles. Go to the Azure Active Directory blade, and select Roles and administrators. Unfortunately, only the following built-in Azure AD roles are supported at this moment:

    Global Reader, Global Administrator
    Security Reader, Security Administrator
    Helpdesk Administrator, Compliance Administrator
    Exchange Administrator

    Select one of the roles, and click Add assignments in the assignments overview screen. Note that when picking security principals, the App might not show up initially, and typing its first few letters might help. Click Add to assign the role.

    clip_image019[4]
    Note that the UserName mentioned in the overview is the Application ID.

Now we are done configuring the back end, we can look again at connecting. This should now be as simple as running:

Connect-ExchangeOnline -CertificateThumbprint '49A4A73B4696718676770834BCD534DE35030D2C' -AppId '0d3f8f4c-34fb-4a22-8466-80fd7379593b' -Organization '<tenant>.onmicrosoft.com'

Where:

  • CertificateThumbprint is the thumbprint of the self-signed certificate you created earlier.
  • AppID is the Application (Client) ID of the registered App.
  • <tenant>.onmicrosoft.com the initial domain name of your tenant.

Note that you can also connect specifying the CertificateFile instead of Thumbprint, but then you need to provide the password as well via CertificatePassword. Having the certificate in the certificate store of the administrator account or account running the task and just specifying the thumbprint is more convenient and requires zero interaction.

If all steps above were followed correctly, you should now be connected to Exchange Online, without any MFA interaction.

A final note is that Connect-IPPSSession mentioned earlier does not support certificate-base authentication.

What about other Workloads

You can use the same certificate-based authentication to connect to several other workloads as well. That is, provided you have installed the required PowerShell module and the Azure AD role you assigned to the Application has adequate permissions. You can use the commands below to connect to these workloads. A small note that the commands to connect may use a different parameter names for AppId or Organization, e.g. AppId, ApplicationId or ClientId and Organization and TenantId are same things in the examples below.

AzureAD (2.x or Preview)

Connect-AzureAD -CertificateThumbprint '49A4A73B4696718676770834BCD534DE35030D2C' -ApplicationId '0d3f8f4c-34fb-4a22-8466-80fd7379593b' -TenantId '<tenant>.onmicrosoft.com'

MicrosoftTeams (GA or Test)

Connect-Microsoftteams -CertificateThumbprint '49A4A73B4696718676770834BCD534DE35030D2C' -ApplicationId '0d3f8f4c-34fb-4a22-8466-80fd7379593b' -TenantId '<tenant>.onmicrosoft.com'

Microsoft Graph

Connect-Graph -CertificateThumbprint '49A4A73B4696718676770834BCD534DE35030D2C' -ClientId '0d3f8f4c-34fb-4a22-8466-80fd7379593b' -TenantId 'eightwone.onmicrosoft.com'


Audit

The logons which are performed in the context of the Application are viewable in the Azure Sign-Ins at https://aka.ms/iam/rtsp

Note that this view is currently in preview, and there might be a slight delay before logon shows up.

Final Notes

It would be nice if there would be a way to incorporate Exchange granular Role-Based Access Control model into the permissions model. Granting Apps only the built-in Azure AD roles is somewhat limiting, and it would be nice to restrict accounts in only being able to run the cmdlets and parameters they need to use.

When running Exchange cmdlets, you will find these in the audit log but with the <tenant>\AppID as UserName. Therefore, best thing to do is to use a single App registration for each individual administrator or process, instead of using a single App registration and multiple certificates.

And finally, it would be nice if the various teams would align their cmdlet and parameter naming schemes for consistency.