Update 9/29/2022: By popular request, I modified the Get-EventSession script so it is now able to also download MEC sessions (-Event MEC). See below for details.
A quick post for those that are looking for a simple way to download the Microsoft Exchange Community (MEC) Technical Airlift 2022 sessions for offline viewing, here’s a simple way to accomplish this:
Get youtube-dl.exe here. Youtube-dl is a tool to download videos or playlists from Youtube.
Get aria2c.exe here. Aria2c can be used to download media using multiple streams, reducing time it takes to download video content.
Put the executables from both downloads in the same folder, and, using a a (PowerShell) command prompt, run the following:
“C:\MEC2022” is the folder where the downloaded files will be stored. Change when needed. For file naming, variables are used with define the name of the downloaded files using a prefix of the sequence number (from the playlist) together with the title of the video (session).
–external-downloader tells youtube-dl to use specified download utility (aria2c) instead of its own engine. The external-downloader-args parameters define concurrency and chunk size.
The last part is the URL for the MEC 2022 playlist.
9/29/2022: Alternatively, you can now use Get-EventSession (version 3.7 and up) to download MEC sessions. The script will parse the information shared through the playlist, but some usual attributes are missing, but there also some new attributes, such as likes and views. To use the script to download MEC session videos:
Note: If you do not specify format, YouTube videos will be downloaded in ‘best’ possible quality, which will be .webm by default. You can prevent this, and download 1080p movies, by specifying -Format 22.
Yesterday, I had the pleasure of presenting at the Microsoft Exchange Conference Community Technical Airlift 2022. I talked about the challenges that organizations are facing that use Exchange scripts in their work processes or run them scheduled unattended.
Some of the challenges I mentioned, apart from the upcoming demise of Basic Authentication, and resources to methodically assess and make the necessary changes, are:
Get your code more secure leveraging Certificate Based Authentication, especially for scheduled tasks.
Get current with the most recent version of the Exchange Online Management Module for PowerShell.
The same exercise with regards to AzureAD when using MSOnline or AzureAD modules, and the inevitable move to the PowerShell Graph SDK.
In the end I also quickly demonstrated how much easier and secure things can be when utilizing Azure Automation, which might especially appeal to organizations that want to totally get rid of any infrastructure for running jobs.
You can watch the presentation below. All sessions are you published on YouTube, and its playlist can be accessed at aka.ms/MEC2022.
The presentation as well as the deck and script used in the live demonstration can be retrieved from GitHub. The Analyse-ExoScript used in the demo can be found on GitHub as well, or look at the accompanying blog I wrote a while ago here.
Note that during MEC, it was announced that the next GA release of the Exchange Online Management module will be version 3. This jump is likely to prevent any confusion with earlier GA and preview releases. It was said the next GA release might be as early as next week, which should be good news for organizations who’s policy it is to not run Preview software in production environments.
If you have any questions, ask them in the comments or send me a message via the contact form.
Updated: 1.2 adds default ExchangeOnlineManagement cmdlets scanning and authentication options.
Since the original announcement on deprecation of Basic Authentication, organizations had time to analyze their environment which may include Exchange-related procedures and tools. These usually also contain scripts or commands, which depend on the Exchange Online Management module. A previous blog on its history and how version 2 of this module lends itself for unattended operation with certificate-based modern authentication support can be found here.
The initial release of the Exchange Online Management v2 – or EXOv2 – module offered a an additional small set of cmdlets which utilized REST-based services. Apart from the functional discrepancies, such as having to specify a property set to indicate which properties to return, the big advantage of these added commands was that they did not depend on the Windows Remote Management (WinRM) client using Basic Authentication for token exchange. Disabling Basic Authentication on WinRM client lead to messages such as:
Connecting to remote server outlook.office365.com failed with the following error message : The WinRM client cannot process the request. Basic authentication is currently disabled in the client configuration.
This dependency makes it challenging for organizations to turn off Basic Authentication altogether, or lead to problems when they did. Fast forward to the present, where the Exchange Online Management module in its current release is offering nearly all Exchange cmdlets in REST-based form, with full functional parity.
While I expect Microsoft to reach full command parity before they flick the Basic Authentication switch to off, there are also other use cases for which analyzing scripts might be helpful:
Ths initial purpose was identifying commands which require RPS (Remote PowerShell), and thus thus require WinRM Basic Authentication enabled. Because the Exchange Team did an amazing job in catching up in the recent months, only few Exchange Online cmdlets are still lacking REST support in my tenant at this moment, e.g. New-ApplicationAccessPolicy. But then again, your mileage may vary, as the recent Preview 7 module removed few UnifiedGroup related cmdlets which had issues.
New Exchange Online commands may not receive immediate REST support.
Organizations might want to cross-reference commands with scripts.
Identifying Exchange Online commands and parameters in scripts helps in determining the minimum set of permissions required to run the script.
To analyze and report on Exchange Online scripts, I created a simple script Analyze-ExoScript.ps1. This script, which is available on GitHub here, does the following:
Connect to Exchange Online using RPS and inventory the commands available. Note that this requires the UseRPSSession switch when connecting, which is only available per 2.0.6-Preview3 of the module. If your organization only runs GA versions of the module, this script cannot be used.
Connect to Exchange Online using REST and inventory the commands available. It will re-use the account used for authenticating the RPS session, which should prevent receiving another authentication dialog or MFA challenge.
Cache cmdlet information in an external file to prevent having to connect to Exchange Online for every run. The file is named EXO-CmdletInfo.xml and will be stored in the same folder as the script.
Process the script and report on the Exchange-related commands used.
Usage Calling Analyze-ExoScript is straightforward:
File is the name of one or more files which you want to analyze. Note that the script accepted pipeline output, so you can also feed it filenames using Get-ChildItem for example.
The ShowAll switch tells the script to output all found commands, not only the Exchange ones.
The switch Refresh tells the script to ignore saved command information, trigger reconnecting to Exchange Online in order to refresh the command sets.
Credential specifies the (Basic Authentication) credential to pass to Connect-ExchangeOnline.
Organization and AppId can be used to specify the tenant ID (x.onmicrosoft.com) and registered application ID to use with Connect-ExchangeOnline using Modern Authentication. This also requires one of the following:
CertificateThumbprint of the certificate to use for authentication.
CertificateFile of the file containing the certificate to use, together with CertificatePassword to specify its password.
When asked to authenticate, make sure your role has the necessary Exchange-related permissions as that will determine the Exchange Online cmdlets available to you, and consequently also the commands which Analyze-ExoScript will recognize in scripts to process.
For example, to process a script Fix-MailboxFolders.ps1, use:
The output consists of objects, which allow for further filtering:
The returned properties are:
Command is the Exchange Online command identified
Type will tell you if the command supports REST or requires RPS.
Parameters are the parameters used together with the command. This includes common parameters, which might be less usable for role assignment purposes.
Alt contains alternative REST-based cmdlet you could consider using for performance reasons, e.g. Get-EXOMailbox instead of Get-Mailbox.
File and Line are the file containing the command and on which line it is located.
AST To analyze code, I leveraged PowerShell feature called Abstract Syntax Tree, which was an interesting exploration in itself. PowerShell AST can be used to decompose PowerShell code into tokens. This is way better than simply looking for strings, and does away with having to interpret code yourself to see if something is a command, comment or just some string. AST allows for analysis of these tokens, in this case filtering on commands which are related to Exchange Online. If you want to get started on AST, check out this article, or plunge in the PowerShell SDK straightaway.
Final Words When every Exchange Online command discovered is found to be offering REST support, you can turn off Basic Authentication on the client, for example through GPO or by reconfiguring WinRM:
winrm set winrm/config/client/auth @{Basic="false"}
Only thing you might need to refactor is if and how the script connects to Exchange Online, as Basic Authentication allowed for connecting to Exchange Online using (stored) credentials for example. Examples on how to use more secure Modern Authentication-based methods to connect can be found in an earlier article here.
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.
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.
EighTwOne (821) 