Exchange Server

It seems that Microsoft has decided to hold off releasing a new Exchange Server, saying the next version will not arrive until 2025. While some were expecting the next version of the on-premises Exchange Server to arrive this year, that is not happening.

Instead, Microsoft will roll out a new feature to Exchange Server 2019. Speaking to ZDNet, the company says:

“Microsoft will support Exchange 2016 and 2019 until October 14, 2025. And after October 14, 2025, only the next version of Exchange Server will be supported.”

The company thinks it has enough time to place more migration enhancements into Exchange Server 2019, have support cut-off windows, and roll out a new version.

Speaking of the new features coming to Exchange Server 2019, Microsoft says unique tools coming to the platform include improvements to Outlook on the web. Furthermore, the company is improving security, increasing scalability, and enhancing security.

Elsewhere, the architecture will get an update, while new integrations with OneDrive and SharePoint are coming.

Missed Release

It is worth remembering Microsoft was originally planning to roll out a new Exchange Server in 2021. So, why did not that happen?

“Unfortunately, 2021 had other plans for Exchange Server. In March 2021, we confronted a serious reality: state-sponsored threat actors were targeting on-premises Exchange servers.” Microsoft responds.

With the future Exchange Server 2025, Microsoft will require Server and CAL (Client Access License) licenses.

“We are moving the next version of Exchange Server to our Modern Lifecycle Policy, which has no end of support dates. We plan on continuing to support Exchange Server as long as there is substantive market demand,” Microsoft says.

Tip of the day: Tired of Windows´s default notification and other system sounds? In our tutorial, we show you how to change windows sounds or turn off system sounds entirely.

Source  Winbuzzer

Microsoft Exchange Server has had a tough 2021, with a series of vulnerability exploits endangering users on the platform. It seems the service is facing another new security threat. A security researcher from Guardicore found a major bug in Exchange’s Autodiscover protocol, resulting in nearly 100,000 login names and passwords leaking.

Autodiscover is a protocol in Microsoft Exchange Server that gives users the ability to efficiently configure apps with just a password and email address. Guardicore’s Amit Serper says a flaw in Exchange means tens of thousands of unique login information for Windows domains has leaked online.

“This is a severe security issue, since if an attacker can control such domains or has the ability to ‘sniff’ traffic in the same network, they can capture domain credentials in plain text (HTTP basic authentication) that are being transferred over the wire,” Serper points out in a technical report.

So, you’ve completed your migration to Exchange Online. Email flows smoothly into and out of the cloud, and all your mailboxes are now online. What’s next for your Exchange Servers, now that you’ve made the transition?

After completion you will have several tasks to perform to remove Exchange Servers from your environment, but there is one important caveat you need to know about; if you run Azure AD Connect then you can’t remove every Exchange Server from your environment. You will need to keep at least one around for management purposes. In this article, I’ll walk through what you can do to minimize what you keep and need to maintain, and what you can consider planning for in the future. You can also join me at TEC this week, on September 2nd.

Read more: Microsoft Patches Four More Exchange Server Vulnerabilities as the FBI Moves to Clean Infected Servers

If you run Azure AD Connect, you need Exchange for recipient management

At the time of writing (August 2021), Microsoft still haven’t removed the need to keep at least one Exchange Server around after migrating to Exchange Online – if you plan to still run Hybrid Identity.

This is because when you run Hybrid Identity, your on-premises Active Directory Forest and Domains remain the source of truth for objects that are synchronized to Azure Active Directory (Azure AD). Azure AD is the directory that Microsoft 365, including Exchange Online uses, and almost all attributes that are synced from your local AD are read-only in Azure AD and must be set and edited locally.

That means that when you create a new user account, you must create the user account in your local Active Directory. After creating the new user account, Azure AD Connect will run a synchronization job and see a new user account, and then create a new synced account in Azure AD. The new Azure AD account will be linked back to that account and if it’s missing vital attributes, you won’t be able to use the online tools, like the Exchange Admin Center, to fill in missing values or update values.

Your local Active Directory management tools aren’t designed to manage Exchange attributes, and whilst you can technically set Exchange-specific attributes using Active Directory Users and Computers (via the attribute editor), ADSIEdit.msc or by using PowerShell scripting, Microsoft do not support manually editing the attributes. Microsoft clearly state that you must use an Exchange Server, if you want the option of phoning up Microsoft for support:

There are good reasons why Microsoft have made this statement. Firstly, Microsoft have committed to providing a solution for removing the last Exchange Server from your environment, but as it’s a reasonably complex problem that needs to account for the needs of small, medium and large organizations, then providing a one-size fits all solution will be difficult. Solutions like cutting off the sync of Exchange attributes have been suggested in the community, but would result in stale and out of date data in AD; complex solutions for write-back or co-ordinated changes aren’t practical in many enterprise environments that are regulated, nor are suitable for smaller customers. And simply providing a set of PowerShell scripts to replace Exchange Management tools could work for some organizations, but would be too complex for smaller organizations to manage.

If you do choose to go it alone and remove the last Exchange Server there is another risk; that when Microsoft do provide a solution, whatever you’ve done yourself will break. This is because Microsoft have suggested the solution might require an update before removal can take place:

Finally, it’s reasonably rare to find either a third-party tool or scripts that a consultant or IT administrator have provided that sufficiently cover the same functionality as the Exchange Admin Center or Exchange Management Shell. Remember that the configuration stored and used within the local Active Directory includes several areas directly related to ongoing recipient management in Exchange Online:

• Remote Mailbox management for users, shared mailboxes and archives (i.e. management of the AD attributes linked to your mailboxes in Exchange Online)
• Mail User management
• Mail Contact management
• Mail-Enabled Security Group management
• Distribution Group management
• Accepted Domain and Remote Domain management
• Email Address Policy management and updates
• Autodiscover Service Connection Point management

Even when I’ve seen reasonably comprehensive scripts aimed at managing this, these don’t always provide the same validation functionality that the Exchange tooling does; for example – ensuring address uniqueness and RFC compliance when altering proxy addresses and the primary email address, or following the same logic when applying changes to Email Address Policies. Because scripts or tools are acting directly against Active Directory (which has little knowledge of Exchange) you can create scripts that make changes that would not be valid if performed through the Exchange tooling.

As Microsoft state – it is possible to examine everything Exchange does with regards to recipient management, but it is at your own risk. However as time goes on, and the risk of running Exchange on-premises appears to increase – there may be a time when the Microsoft 365 community of IT pros (and Microsoft MVPs like myself) weigh up the risks collectively and provide a solution. Right now though it’s not yet the time.

If you relay SMTP email on behalf of legacy application servers

The best thing you can do is upgrade line-of-business applications to their respective vendors’ SaaS equivalents or at the very least, upgrade to versions that have native support for Microsoft 365 and Exchange Online. There should be no vendor worthy of respect that appears to be confused by a request to configure their software so that it can send email directly using Exchange Online.

Such applications should not need to use an on-premises mail server to relay outbound mail to or through Exchange Online in 2021; Exchange Online has been around for ten years. And those vendors should not be shocked or confused that simply using authenticated SMTP with Exchange Online won’t be enough either; Microsoft announced in September 2019 (almost three years ago) that legacy authentications will no longer be supported in due time, and announced support for OAuth 2.0 with SMTP around 18 months ago. A vendor that has asked it’s development team to spend an hour looking into what they should do will have fast arrived at the conclusion that they should use Microsoft Graph to submit email messages, and build their integration in a way that doesn’t require a username and password to be stored and works seamlessly in environments that leverage Conditional Access policies and Multi-Factor Authentication. If your vendor claims they haven’t been asked if their application can work properly with Microsoft 365, then you should be suspicious, unless you are their only customer.

Unfortunately, getting on a call and grandstanding with the vendor won’t solve the fact they’ve done little except collect recurring revenue from you to support their solution. And if, like many organizations, you run tens of applications like this or have in-house bespoke applications relied upon that were created by developers who’ve long since left the business, you might find yourself in a difficult position.

That position is often one where you need to be able to accept unauthenticated, insecure SMTP messages and relay them either outbound through Exchange Online to your customers or to employee mailboxes. In that case, then the simplest option often is to continue to run several Exchange Servers, utilizing a copy of your existing relay receive connectors. As you’ve read above, you need the servers for ongoing management – so it often makes sense.

Recommendations for the “last Exchange Server”

Assuming you aren’t moving to cloud-only identities and removing Active Directory today (which some organizations are) then you are keeping Exchange running on premises. What this needs to be depends somewhat on your organization, but should be guided by several principles:

• The server(s) required to run Exchange Hybrid functionality for management and SMTP relay purposes is unlikely to be the same specification you needed to host Mailboxes on, and can be a lower specification.
• The server(s) are typically is suited to run as a Virtual Machine on-premises or in a cloud provider, so long as core requirements for access to Active Directory are met with no firewall rules in-between.
• You only need to run Exchange Server 2016 on these servers. There is no benefit today in running Exchange Server 2019, except for the ability to run on Server Core and support in-place operating system upgrades, and the free Hybrid license is only available for Exchange 2016 and below.
• The specifications for the last Exchange Server can be lower than normal Exchange Servers. The minimum requirements for Exchange Server are not typically sufficient, but 2 to 4 virtual CPUs and 12GB RAM, with a minimum of 100GB of disk space often work well as a starting specification. If you expect significant SMTP relay traffic, then you should size the servers appropriately to ensure mail queue database size and logs are meet your requirements, and ensure you have sufficient disk space to keep extended logs for security investigation purposes.
• You should not need to expose HTTPS services to the internet, now you’ve migrated all mailboxes (and public folders) to Exchange Online. You will first move your Autodiscover records to point directly at Exchange Online, and set your Service Connection Point to $null; no clients should be accessing these servers.
• If you are relaying SMTP mail outbound only and not receiving mail back to on-premises or running centralized transport, then you should not need firewall rules to allow SMTP mail to be received inbound to these servers.
• You may choose to restrict HTTPS and other connectivity on your internal network to the Exchange Servers, now that no internal clients require access to Exchange On-Premises. If you need more than one Exchange Server to provide HA for SMTP relay, Load Balancing functionality will only be relevant for SMTP relay and not for HTTPS, as HTTPS access will only be used for IT administrator access from secured clients.
• Don’t run the Exchange Mailbox role on a server running other related services, such as on an Active Directory Domain Controller or Azure AD Connect server.
• You must keep the Exchange Servers up-to-date. This needs to be the latest update, or immediately previous update (i.e. you remain supported for the small duration of time, such as a week, that it takes to agree the change to perform the updates); furthermore you absolutely must apply security updates as soon as you can after they are released. Do this whether or not the servers are published to the internet; it is common for a low-privilege account to be compromised and this account used to explore your network to find opportunities to gain escalated privileges.
• Ensure logging capabilities on the servers are set so that you keep enough security and access logs so that you can investigate a security incident, should Exchange be subject to a zero-day threat again. If you have the capability, ensure logs are consumed by your SOC or SOC service and analyzed in real-time for threats.
• Ensure you are installing EPP and EDR software. Exchange admins have questioned in the past the validity of running Anti-Virus software on Exchange Servers because AV software can attempt to scan database files and cause issues. This only happens if you don’t specify the correct exclusions. EDR (Endpoint Detection and Response) software, like Defender for Endpoint has specific capabilities and recommendations for Exchange too, so if you have purchased these products, use them.

A future without Exchange Servers on-premises

However, as Microsoft do say they will have a solution coming for removing the last Exchange Server – and that, given Exchange has become a cybersecurity target – you might actually want to restrict access to Exchange Servers or potentially even switch them off when they aren’t being used for management. So if you need SMTP relay for legacy applications, multi-function copiers and don’t want to poke a bunch of outbound SMTP holes in your firewall for direct delivery to Exchange Online – what can you do?

Whilst we’d hope that Microsoft will provide some guidance when they do finally release a way to remove the last Exchange Server, there are several options you can consider; after all – we are only considering standards-compliant SMTP relay with a known configuration on the Exchange Online side that can accept TLS-secured messages from known IP addresses and certificates.

The first option is to consider using Exchange Servers running the Edge Transport role. This role can be installed without connecting to any local Active Directory domain on standalone servers within a perimeter network area like a DMZ. The Edge Transport role doesn’t install any HTTPS services, and has lower minimum hardware requirements. Edge Servers are supported in a Hybrid Deployment, but the model for a sans-Exchange future would mean this model was not applicable, as no Exchange 2016 Mailbox servers would exist to provide an EdgeSync relationship, and you would instead create Send and Receive connectors directly on each Edge Server. Microsoft’s licensing FAQ indicates that a hybrid mail flow scenario would cover Edge Transport servers, as particular roles are not specified, but it’s important to check with your Microsoft account manager that this applies to you. Otherwise, the Edge Transport role provides the same ability to maintain relay Receive Connectors and a Send Connector onward to Exchange Online using the same skills you have today, and fulfils the need to remove Exchange from the corporate network and Active Directory.

Other options include firstly, using Windows Server’s IIS SMTP functionality. This is a configuration that some organizations have used with success, but remember – this is very similar to the SMTP functionality long-term Exchange admins will remember from Exchange Server 2000 and 2003. If you are considering IIS SMTP for mail relay, then it’s likely that you are desperate for an option to use, and perhaps a non-Microsoft solution might be more appropriate that has ongoing development and support. Open Source mail servers, like Exim, Postfix and Sendmail are well documented and capable of sustaining extremely high mail flow loads. They often form the underpinnings of cloud-based mail filtering solutions – but they require skills to setup and do require checks and maintenance – a Unix, Linux or BSD-based server running a Mail Transport Agent still needs to be patched, and can still be compromised.

If you’ve read this far and are thinking “No thanks – I don’t want to manage SMTP mail relay on-premises” – then consider whether beginning those efforts to press your legacy application vendors into making their software relay mail properly with Exchange Online is energy better spent and will result in a solution you don’t have to maintain.

Source Winbuzzer

So, you’ve completed your migration to Exchange Online. Email flows smoothly into and out of the cloud, and all your mailboxes are now online. What’s next for your Exchange Servers, now that you’ve made the transition?

After completion you will have several tasks to perform to remove Exchange Servers from your environment, but there is one important caveat you need to know about; if you run Azure AD Connect then you can’t remove every Exchange Server from your environment. You will need to keep at least one around for management purposes. In this article, I’ll walk through what you can do to minimize what you keep and need to maintain, and what you can consider planning for in the future. You can also join me at TEC this week, on September 2nd.

If you run Azure AD Connect, you need Exchange for recipient management

At the time of writing (August 2021), Microsoft still haven’t removed the need to keep at least one Exchange Server around after migrating to Exchange Online – if you plan to still run Hybrid Identity.

This is because when you run Hybrid Identity, your on-premises Active Directory Forest and Domains remain the source of truth for objects that are synchronized to Azure Active Directory (Azure AD). Azure AD is the directory that Microsoft 365, including Exchange Online uses, and almost all attributes that are synced from your local AD are read-only in Azure AD and must be set and edited locally.

That means that when you create a new user account, you must create the user account in your local Active Directory. After creating the new user account, Azure AD Connect will run a synchronization job and see a new user account, and then create a new synced account in Azure AD. The new Azure AD account will be linked back to that account and if it’s missing vital attributes, you won’t be able to use the online tools, like the Exchange Admin Center, to fill in missing values or update values.

Your local Active Directory management tools aren’t designed to manage Exchange attributes, and whilst you can technically set Exchange-specific attributes using Active Directory Users and Computers (via the attribute editor), ADSIEdit.msc or by using PowerShell scripting, Microsoft do not support manually editing the attributes. Microsoft clearly state that you must use an Exchange Server, if you want the option of phoning up Microsoft for support:

There are good reasons why Microsoft have made this statement. Firstly, Microsoft have committed to providing a solution for removing the last Exchange Server from your environment, but as it’s a reasonably complex problem that needs to account for the needs of small, medium and large organizations, then providing a one-size fits all solution will be difficult. Solutions like cutting off the sync of Exchange attributes have been suggested in the community, but would result in stale and out of date data in AD; complex solutions for write-back or co-ordinated changes aren’t practical in many enterprise environments that are regulated, nor are suitable for smaller customers. And simply providing a set of PowerShell scripts to replace Exchange Management tools could work for some organizations, but would be too complex for smaller organizations to manage.

If you do choose to go it alone and remove the last Exchange Server there is another risk; that when Microsoft do provide a solution, whatever you’ve done yourself will break. This is because Microsoft have suggested the solution might require an update before removal can take place:

Finally, it’s reasonably rare to find either a third-party tool or scripts that a consultant or IT administrator have provided that sufficiently cover the same functionality as the Exchange Admin Center or Exchange Management Shell. Remember that the configuration stored and used within the local Active Directory includes several areas directly related to ongoing recipient management in Exchange Online:

• Remote Mailbox management for users, shared mailboxes and archives (i.e. management of the AD attributes linked to your mailboxes in Exchange Online)
• Mail User management
• Mail Contact management
• Mail-Enabled Security Group management
• Distribution Group management
• Accepted Domain and Remote Domain management
• Email Address Policy management and updates
• Autodiscover Service Connection Point management

Even when I’ve seen reasonably comprehensive scripts aimed at managing this, these don’t always provide the same validation functionality that the Exchange tooling does; for example – ensuring address uniqueness and RFC compliance when altering proxy addresses and the primary email address, or following the same logic when applying changes to Email Address Policies. Because scripts or tools are acting directly against Active Directory (which has little knowledge of Exchange) you can create scripts that make changes that would not be valid if performed through the Exchange tooling.

As Microsoft state – it is possible to examine everything Exchange does with regards to recipient management, but it is at your own risk. However as time goes on, and the risk of running Exchange on-premises appears to increase – there may be a time when the Microsoft 365 community of IT pros (and Microsoft MVPs like myself) weigh up the risks collectively and provide a solution. Right now though it’s not yet the time.

If you relay SMTP email on behalf of legacy application servers

The best thing you can do is upgrade line-of-business applications to their respective vendors’ SaaS equivalents or at the very least, upgrade to versions that have native support for Microsoft 365 and Exchange Online. There should be no vendor worthy of respect that appears to be confused by a request to configure their software so that it can send email directly using Exchange Online.

Such applications should not need to use an on-premises mail server to relay outbound mail to or through Exchange Online in 2021; Exchange Online has been around for ten years. And those vendors should not be shocked or confused that simply using authenticated SMTP with Exchange Online won’t be enough either; Microsoft announced in September 2019 (almost three years ago) that legacy authentications will no longer be supported in due time, and announced support for OAuth 2.0 with SMTP around 18 months ago. A vendor that has asked it’s development team to spend an hour looking into what they should do will have fast arrived at the conclusion that they should use Microsoft Graph to submit email messages, and build their integration in a way that doesn’t require a username and password to be stored and works seamlessly in environments that leverage Conditional Access policies and Multi-Factor Authentication. If your vendor claims they haven’t been asked if their application can work properly with Microsoft 365, then you should be suspicious, unless you are their only customer.

Unfortunately, getting on a call and grandstanding with the vendor won’t solve the fact they’ve done little except collect recurring revenue from you to support their solution. And if, like many organizations, you run tens of applications like this or have in-house bespoke applications relied upon that were created by developers who’ve long since left the business, you might find yourself in a difficult position.

That position is often one where you need to be able to accept unauthenticated, insecure SMTP messages and relay them either outbound through Exchange Online to your customers or to employee mailboxes. In that case, then the simplest option often is to continue to run several Exchange Servers, utilizing a copy of your existing relay receive connectors. As you’ve read above, you need the servers for ongoing management – so it often makes sense.

Recommendations for the “last Exchange Server”

Assuming you aren’t moving to cloud-only identities and removing Active Directory today (which some organizations are) then you are keeping Exchange running on premises. What this needs to be depends somewhat on your organization, but should be guided by several principles:

• The server(s) required to run Exchange Hybrid functionality for management and SMTP relay purposes is unlikely to be the same specification you needed to host Mailboxes on, and can be a lower specification.
• The server(s) are typically is suited to run as a Virtual Machine on-premises or in a cloud provider, so long as core requirements for access to Active Directory are met with no firewall rules in-between.
• You only need to run Exchange Server 2016 on these servers. There is no benefit today in running Exchange Server 2019, except for the ability to run on Server Core and support in-place operating system upgrades, and the free Hybrid license is only available for Exchange 2016 and below.
• The specifications for the last Exchange Server can be lower than normal Exchange Servers. The minimum requirements for Exchange Server are not typically sufficient, but 2 to 4 virtual CPUs and 12GB RAM, with a minimum of 100GB of disk space often work well as a starting specification. If you expect significant SMTP relay traffic, then you should size the servers appropriately to ensure mail queue database size and logs are meet your requirements, and ensure you have sufficient disk space to keep extended logs for security investigation purposes.
• You should not need to expose HTTPS services to the internet, now you’ve migrated all mailboxes (and public folders) to Exchange Online. You will first move your Autodiscover records to point directly at Exchange Online, and set your Service Connection Point to $null; no clients should be accessing these servers.
• If you are relaying SMTP mail outbound only and not receiving mail back to on-premises or running centralized transport, then you should not need firewall rules to allow SMTP mail to be received inbound to these servers.
• You may choose to restrict HTTPS and other connectivity on your internal network to the Exchange Servers, now that no internal clients require access to Exchange On-Premises. If you need more than one Exchange Server to provide HA for SMTP relay, Load Balancing functionality will only be relevant for SMTP relay and not for HTTPS, as HTTPS access will only be used for IT administrator access from secured clients.
• Don’t run the Exchange Mailbox role on a server running other related services, such as on an Active Directory Domain Controller or Azure AD Connect server.
• You must keep the Exchange Servers up-to-date. This needs to be the latest update, or immediately previous update (i.e. you remain supported for the small duration of time, such as a week, that it takes to agree the change to perform the updates); furthermore you absolutely must apply security updates as soon as you can after they are released. Do this whether or not the servers are published to the internet; it is common for a low-privilege account to be compromised and this account used to explore your network to find opportunities to gain escalated privileges.
• Ensure logging capabilities on the servers are set so that you keep enough security and access logs so that you can investigate a security incident, should Exchange be subject to a zero-day threat again. If you have the capability, ensure logs are consumed by your SOC or SOC service and analyzed in real-time for threats.
• Ensure you are installing EPP and EDR software. Exchange admins have questioned in the past the validity of running Anti-Virus software on Exchange Servers because AV software can attempt to scan database files and cause issues. This only happens if you don’t specify the correct exclusions. EDR (Endpoint Detection and Response) software, like Defender for Endpoint has specific capabilities and recommendations for Exchange too, so if you have purchased these products, use them.

A future without Exchange Servers on-premises

However, as Microsoft do say they will have a solution coming for removing the last Exchange Server – and that, given Exchange has become a cybersecurity target – you might actually want to restrict access to Exchange Servers or potentially even switch them off when they aren’t being used for management. So if you need SMTP relay for legacy applications, multi-function copiers and don’t want to poke a bunch of outbound SMTP holes in your firewall for direct delivery to Exchange Online – what can you do?

Whilst we’d hope that Microsoft will provide some guidance when they do finally release a way to remove the last Exchange Server, there are several options you can consider; after all – we are only considering standards-compliant SMTP relay with a known configuration on the Exchange Online side that can accept TLS-secured messages from known IP addresses and certificates.

The first option is to consider using Exchange Servers running the Edge Transport role. This role can be installed without connecting to any local Active Directory domain on standalone servers within a perimeter network area like a DMZ. The Edge Transport role doesn’t install any HTTPS services, and has lower minimum hardware requirements. Edge Servers are supported in a Hybrid Deployment, but the model for a sans-Exchange future would mean this model was not applicable, as no Exchange 2016 Mailbox servers would exist to provide an EdgeSync relationship, and you would instead create Send and Receive connectors directly on each Edge Server. Microsoft’s licensing FAQ indicates that a hybrid mail flow scenario would cover Edge Transport servers, as particular roles are not specified, but it’s important to check with your Microsoft account manager that this applies to you. Otherwise, the Edge Transport role provides the same ability to maintain relay Receive Connectors and a Send Connector onward to Exchange Online using the same skills you have today, and fulfils the need to remove Exchange from the corporate network and Active Directory.

Other options include firstly, using Windows Server’s IIS SMTP functionality. This is a configuration that some organizations have used with success, but remember – this is very similar to the SMTP functionality long-term Exchange admins will remember from Exchange Server 2000 and 2003. If you are considering IIS SMTP for mail relay, then it’s likely that you are desperate for an option to use, and perhaps a non-Microsoft solution might be more appropriate that has ongoing development and support. Open Source mail servers, like Exim, Postfix and Sendmail are well documented and capable of sustaining extremely high mail flow loads. They often form the underpinnings of cloud-based mail filtering solutions – but they require skills to setup and do require checks and maintenance – a Unix, Linux or BSD-based server running a Mail Transport Agent still needs to be patched, and can still be compromised.

If you’ve read this far and are thinking “No thanks – I don’t want to manage SMTP mail relay on-premises” – then consider whether beginning those efforts to press your legacy application vendors into making their software relay mail properly with Exchange Online is energy better spent and will result in a solution you don’t have to maintain.

Join me at TEC this week

For more on removing the last Exchange Server, join me this week for TEC. I’m presenting “Removing the last Exchange On-Premises Server“ where I talk through the above – and much more. I’d love to see you there.

Source Practical365

Microsoft Exchange servers are once again the target for attacks. Through this year, Microsoft Exchange Server exploits have led to massive breaches. Now, another threat is ongoing and affecting servers across Asia and the U.S. Known as LockFile, this is a ransomware attack that was found by Symantec.

LockFile has been active since at least July 20. Threat actors conducting successful attacks can take control of Windows domains and encrypt devices. Once they have control over one device, they can potentially spread the ransomware across a network.

Symantec points out LockFile uses the PetitPotam exploit, using the vulnerability after breaching Microsoft Exchange servers. The company says it is unclear how the initial breach of Microsoft Exchange Server is done.

While Microsoft has been patching the platform during the year, there is no current fix for the PetitPotam vulnerability. Alongside Symantec’s discovery, the Cybersecurity & Infrastructure Security Agency has also issued an advisory:

“Malicious cyber actors are actively exploiting the following ProxyShell vulnerabilities: CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207. An attacker exploiting these vulnerabilities could execute arbitrary code on a vulnerable machine. CISA strongly urges organizations to identify vulnerable systems on their networks and immediately apply Microsoft’s Security Update from May 2021—which remediates all three ProxyShell vulnerabilities—to protect against these attacks.”

A 2021 to Forget for Microsoft Exchange Server

Microsoft Exchange Server was successfully attacked through an exploit first used by the HAFNIUM group. More hackers have since leveraged the exploit for their own attacks. Microsoft sent out patches for all versions of the service, including those out of support. Although, these patches need users to install the update.

Microsoft says updating Exchange Server is the best way to avoid the exploit. Furthermore, the company has launched a tool to help customers know if they have been breached. In April, Microsoft released a new update of security patches for Exchange Server.

However, as we recently reported, some attacks persist and are targeting organizations that have not patched their systems.

Tip of the day: The Windows 10 Clipboard history feature provides the functionality across device, space, and time, letting you copy on one computer and paste the text days later on a different PC. All of it is possible via the Windows 10 clipboard manager, which lets you view, delete, pin, and clear clipboard history at will.

In our tutorial we show you how to enable the feature, clear clipboard history, and enable/disable clipboard sync to meet your preferences. You can also create a clear clipboard shortcut for quick removal of stored content.

Source Winbuzzer

After a company has effectively migrated to Microsoft 365 and adopted new cloud services, the number of objects, like users, guests, and groups in a tenant is constantly growing. The same applies to Exchange Online.

Even if you’ve followed guidance for Microsoft 365 group expiration or identity lifecycle management, the result is comparable – the number of objects that you are managing is increasing, becoming more of a challenge for administrators. In this article, we’ll examine how to manage Exchange Online at scale using PowerShell.

Maintaining large sets of objects

As we’re all aware, Microsoft is constantly developing different portals and admin centers for admins to use daily for managing the service. Recently, Microsoft announced the new admin center for Exchange as generally available.

One of the drivers for the new portal is performance and the ability to perform bulk operations. It is REST-based and shaped for minimizing your wait time, reducing errors, and much more. Simply put – it can improve your experience as an administrator.

PowerShell can empower

Despite the improvements to the new admin center for Exchange, it remains limited in terms of functionality and leaves room for performance gains. To see improvements, you must move away from the admin center and use PowerShell. For Exchange Online specifically, you want to install and make use of the Exchange Online PowerShell (EXO) V2 module.

This module combines the legacy as well as the new cmdlets. As of today, nine new cmdlets leverage the new REST-based architecture. Nine may not seem like that much – but think about that in relation to the operations you perform daily, and they are quite sufficient.

Most commands that you use are for retrieving mailbox or recipient attributes or statistics – such as information about the mailbox or all folders within a mailbox.

The new cmdlets allow you to reduce the number of requested attributes, which results in less data transferred over the wire. The ability to do this is called Property sets.

Combining the new cmdlet architecture with smaller improvements like using Property Sets can lead to increased performance. However, since Property Sets are not defined automatically you need to be aware of what you’ll need to retrieve when updating your scripts to the new cmdlets.

Aside from a new architecture, the usage of PowerShell unlocks several tasks. You can easily perform bulk operations based on your filtering, and it also allows you to gather properties that are not even visible in the new Exchange admin center.

Server-side filtering is more important than you might realize

It’s important to emphasize that currently, Microsoft recommends using client-side filtering for optimal performance using the Exchange Online V2 module. However, this applies only to this module.

Below is a brief example, highlighting the difference:

In the first example, the filtering takes place after your client has received all the items. The second example asks the server to filter on the cloud side, and then send the result to the client. This has at least two implications that mean the results from each example provide different output.

First off, we specified the parameter “-ResultSize 20000.” This means we will receive 20000 mailboxes, however, it is likely the collection contains several types of objects in addition to UserMailbox. For example:

Secondly, this demonstrates another issue – you might not retrieve all objects you expect. As you can see in the example above only 13219 are UserMailbox.

When using the server-side filter, however, we will receive the correct result:

Therefore, it can be worth taking a performance hit when using the server-side filter to ensure you receive accurate results.

Use Microsoft Graph with PowerShell for maximum performance

It should be noted that if you need to modify objects using PowerShell, you are limited to the Exchange Online V2 PowerShell module. Unfortunately, Microsoft Graph currently does not provide a way for altering Exchange Online attributes.

However, that does not mean you cannot use Microsoft Graph at all. Since it is intended to retrieve data quickly, you can bypass the overhead of the Exchange Online V2 module for filtering data you want to retrieve.

When you do this, you must make sure that the filter you want to use is supported by Microsoft Graph. But for most scenarios, you should be able to. The full list of query parameters supported by Microsoft Graph is available on Microsoft Docs.

Before you do combine the use of the Exchange Online V2 module with Graph scripting, you need to consider whether it’s worthwhile. To give some insight as to when this will make a difference, consider that overhead for certain modules can make a huge difference.

In an on-premises environment, you can leverage LDAP queries with a filter and passing the result to Exchange. With this, you improve dramatically the overall performance as LDAP is optimized for queries. The same principle applies to Microsoft Graph.

Here is an example of a query using the Exchange module and the corresponding using Microsoft Graph:

Multi-threading your PowerShell scripts provides another option for performance improvement

While this technique is more advanced, it can improve performance to a level you have not yet seen.

Multi-threading, put simply, means that you fork several threads (which you could think of as a sub-process) from your running PowerShell script and have every thread running your code on both your client and on the server-side. This technique is primarily useful for gathering data. The advantage is that you perform a scale-out for your job and several threads work in parallel instead of sequential order for you. The Exchange Online V2 PowerShell module uses this in the architecture. To give you an idea of the power of using multi-threading, take a look at the first single-threaded example:

In the second example using multi-threading we see a 44% improvement in retrieval time:

Managing multiple Exchange Online environments from one PowerShell session

Another feature of the new Exchange V2 module is the ability to connect to multiple tenants in one PowerShell session. This can be extremely helpful during tenant-to-tenant migrations. But, you’ll need to take care of some important pre-requisites and limitations before using the feature:

• You’ll need to ensure that you prefix each connection – without doing this, you will retrieve only objects from the last established session.
• The new cmdlets Get-EXO* are already prefixed and will be available ONLY to the last established connection

In the following example, I connected to a source and target tenant. As the new cmdlets are only available to the last established connection, I connect first to the target as I want to leverage the new cmdlets for gathering data:

Note: To distinct the objects from the tenants, I selected PrimarySmtpAddress and UserPrincipalName.

I used the following commands and order:

Summary

I hope this article provided you with the information and motivation to begin looking into other ways of managing your Exchange Online environment when you have many objects to manage, and/or on a large scale.

Remember, you can use more than the Exchange Online V2 module for PowerShell management. You should try and leverage multiple tools, such as Microsoft Graph to improve the performance of your scripts and administrative tasks. Using these techniques you can build a solid foundation to reduce the time it takes to retrieve information and statistics from your environment, and build scripts to automate routine tasks.

Source Practical365

There’s no good way of putting this other than to say that if you run an unpatched Exchange server that’s open to internet access, you are a blithering idiot. By unpatched, I mean a server that is not completely up to date with all security updates issued by Microsoft.

Way Too Many Unpatched Servers Remain Online

Despite the horrendous damage wreaked in March 2021 by the Hafnium exploit, it seems like there’s still many Exchange servers connected to the internet which are vulnerable to attack. An August 21 report says that almost 2,000 Exchange servers have been hacked in the previous two days. Even worse, an August 8 scan for vulnerable servers identified 30,400 servers ready and waiting to be attacked from the sample examined. And then there’s the small matter of the list of over 100,000 internet-connected Exchange servers being circulated in the cybercrime community to make it easy for attackers to find potential prey.

Earlier this month, Steve Goodman sounded the alarm about the ProxyLogon technique developed by Orange Tsai, a security researcher in Taiwan. If you’re unconvinced that this is a threat, have a look at this YouTube video. The point is that the vulnerabilities uncovered by Tsai are known to attackers and can be exploited against unpatched and unprotected servers which sit there on the internet like a big fat target.

Get Patched or Get Online

If you can’t wrap your head about the need to protect servers, you should move online and let Microsoft take care of the block and tackle necessities of network security. People with no interest in applying security patches shouldn’t run servers. Get out of the way and let others protect your users and your organization. It’s the decent thing to do.

Source Practical365

For many organizations, Exchange Online (EXO) will be their first access point into Microsoft 365. While there are many similarities in how the cloud service is managed compared to an on-premises Exchange deployment, there are also many new concepts and risks introduced. The responsibilities of a traditional Exchange Administrator after moving to EXO are vastly different from what they were previously used to.

In this article, I will outline the most important steps an Exchange Online Administrator needs to take to make EXO secure by default. While there are a lot of nifty security tools we can leverage with the appropriate licensing, all the steps outlined in this article can be achieved with basic licenses.

Disable Legacy Authentication

This one should be no surprise to anyone. The first step that should be taken to make your Exchange Online environment secure by default is to disable Legacy Authentication. In the context of Microsoft 365, Legacy Authentication is not a single protocol, more an umbrella term used to describe any protocol that uses Basic Authentication. Steve Goodman wrote a great article on how to do this which I strongly recommend you review.

For tenants with Azure Active Directory Premium, Conditional Access can be used to block Legacy Authentication at a tenant, app, or user level. But as Conditional Access only applies after the initial authentication occurs, Legacy Authentication should still be turned off at a service level in Exchange.

Microsoft is pushing to disable Legacy Authentication and has recently announced that they will be retiring it from any tenant that is not currently using it. Owners of these tenants will be notified by a Message Center Notification.

Implement Multi-Factor Authentication

Multi-Factor Authentication (MFA) is an extremely effective method to provide additional verification for user sign-ins. With the abundance of Phishing attempts that occur daily for large organizations, it can often be the last line of defense against an attacker gaining access to confidential data. It is also extremely easy to implement.

For tenants with Azure Active Directory Premium, Conditional Access can be implemented to allow for some cool scenarios such as bypassing MFA on trusted devices, from trusted networks and even reassess the requirement based on user state changes with the continuous evaluation feature.

If you don’t have Azure AD Premium though, you can still protect your tenancy with Azure AD Security Defaults. This will allow you to enforce MFA for all users very easily, although the flexibility of Conditional Access is lost here.

Understand and Secure Exchange Online Mail Connectors

Out of the box, Exchange Online has default send and receive connectors and unlike Exchange On-Prem, you can’t see or modify them. Exchange Online has some top-class mail protection available through Microsoft Defender for Office 365 but that requires additional licensing to leverage. Some organizations will opt to maintain a third-party service instead of fully moving inbound and outbound mail protection to Microsoft, and that’s fully supported in Exchange Online however there are some considerations to this configuration.

The most important consideration is the default connectors I mentioned above. When you set your MX records to route inbound mail via a third-party gateway, it’s important to remember that MX records are not an enforced mail route, they are simply letting other mail systems know the advertised/preferred public mail route. By default, nothing is stopping external systems from sending mail directly to Exchange Online, bypassing your third-party protections.

To protect against this, a new connector is required in Exchange Online to ensure that mail from external domains is only accepted from your designated sources. This connector needs to specify “*” as the domain to catch all inbound mail and can be set up like the example shown in Figure 1:

My recommendation is that for any mail connectors you set up, to use certificate validation wherever possible and to enforce TLS. IP-based restrictions are available but not as secure as using a public certificate and enforcing TLS.

With this connector set up, when a mail is sent directly to Exchange Online for your organization, it will be denied with a delivery status notification 5.7.1:

Implement SPF, DKIM, and DMARC

Sender Policy Framework (SPF), DomainKeys Identified Mail Standard (DKIM), and Domain-Based Message Authentication, Reporting & Conformance (DMARC) are email security controls that protect public mail domain reputation. They are used to ensure that your outbound mails can be verified while helping to ensure spoofed mails from your domains are blocked by recipients.

While you can’t control the protection standards of other organizations’ mail systems, you can help them to determine if mails received from your domains are legitimate and be informed when your domain is being spoofed.

Let’s look at a brief description of each control:

• SPF uses a public DNS TXT record to inform organizations about the authorized source mail systems for your domain. It does this by publishing source IP addresses/ranges for your domain. It also has a lookup functionality to allow you to specify A records or MX records as authorized sources.
• DKIM does a similar job to SPF by allowing you to verify the source of your emails but can be more effective in complex scenarios as it uses certificate signing for outbound mails. An encrypted header is added to outbound mail using a DKIM signing certificate, which can be validated against a public key that is advertised via a public DNS CNAME record.

For a detailed breakdown of SPF and DKIM setup, check out Alan Byrne’s article here.

• DMARC is a little different in that it’s not a specific control, rather a set of instructions that external mail servers should honor when validating SPF and DKIM from your domain. DMARC works by publishing these “instructions” in public DNS for receiving servers to follow when they get an email from your domains. This record is a TXT record that can specify the following values:
  • v – What version of DMARC is being used? (Currently, the only version is version 1)
  • aspf – Should SPF be verified?
  • adkim – Should DKIM be verified?
  • p / fo – What should happen if SPF and/or DKIM fail? (Nothing, Quarantine, Reject)
  • rua – Should aggregate reports be sent back you your mail system and to what address?
  • ruf – Should individual failure / forensic reports be sent back to your mail system and to what address?
  • sp – Should there be a separate policy for subdomains?
  • pct – *What percentage of mails should DMARC apply to?

*When rolling out DMARC, you can specify a percentage of mail to apply it to, gradually working towards 100%

A fully implemented DMARC TXT record will look like this:

With each of these controls in place, you aren’t just helping to protect your domain against spoofing, but also minimizing the likelihood that your legitimate mails will be seen as spam on the recipient side. This doesn’t replace having appropriate outbound mail filtering in place but goes a long way to protecting your public domain and gaining insights into potential issues.

Enable Admin Consent for Azure AD Apps

Securing user authentication is an effective step in preventing unauthorized access to data within your organization but there are other means that attackers can use to get control of a user’s account. One of these methods is by creating an application which requests users to grant permissions to aspects (scopes) of their data / profile. This can be very useful for application developers who need to access services on behalf of the user, say for example, allowing a scheduling app access to a user’s mailbox / calendar.

The risk with this type of access is that we don’t (by default) predefine which applications can access our tenancy and a user may end up consenting to access from a malicious app. Once the application is granted permissions on the defined scopes, it doesn’t need the users password or MFA to access data on behalf of the user. The user will be prompted to consent when they sign up for the app, similar to Figure 3:

To combat this risk, you can configure Admin Consent in Azure AD. This prevents users from directly granting consent to applications and instead will allow an administrator to approve it after ensuring it’s safe. I recommend checking out this article for a detailed breakdown of how to implement admin consent in Azure AD.

Implement External Email Tagging

Helping users to easily identify external mail can go a long way towards protecting against phishing/spoofing attempts. Adding a tag to mail as it comes in makes it clear to end-users that they should be extra vigilant if the mail contains sensitive content. There are a few ways to implement tagging for external mail, each delivering a similar result, so whichever one you use is up to you.

The first way to accomplish this is to implement a transport rule to prepend a disclaimer to emails that originate externally such as the one shown in Figure 5:

This rule can even add HTML content to draw the user’s attention, an example of this is shown in Figure 5:

The drawback to this method is it tends to break any message preview function in mail clients as the first few lines of text will always be the disclaimer.

Another way this can be implemented is simply prepending some text to the subject. This can also be done with a transport rule. To stop this rule triggering every time there is a reply to a message trail, make sure to add an exception to the rule as shown in Figure 6:

For organizations who solely use Outlook to access Exchange Online from different platforms, there is also the built in external email tag functionality which can be enabled organization wide. This tag (Shown in Figure 7) will only show up in Outlook / Outlook Web so the mail apps in your organization will need to be considered.

Turning on this feature is as simple as running a single command in Exchange Online PowerShell as shown in Figure 8:

Mobile Application Management

Microsoft Endpoint Manager (MEM) / Intune – if you are licensed for it – can provide some powerful features to ensure that when users connect to data in your organization, that the data can be protected from export to an untrusted device or location. By implementing Mobile Application Management Policies, export of data from corporate applications (such as Outlook Mobile) can be restricted. This unlocks a lot of BYOD scenarios without putting corporate data at risk. It’s important to note that Mobile Application Management will only work with supported applications so if enabling MAM, make sure to also restrict mobile access to these applications using Conditional Access as shown in Figure 9:

Configure Microsoft Defender for Office 365

Microsoft Defender for Office 365 (formerly Office 365 ATP) is a powerful tool for protecting Exchange Online from all types of malicious email traffic such as Phishing, Malware and regular Spam. While it does require some premium licensing, the feature-set and protection available provides a lot of value for money by making available a lengthy list of features.

Getting started with Defender for Office 365 doesn’t need to be a pain either.

Define Data Loss Prevention Policies

Data Loss Prevention (DLP) policies can allow organizations to secure and control data as it leaves the organization. By defining DLP policies particular patterns (or Sensitive Information Types) can be detected within content as it is shared externally, and a set of rules are applied to determine if the data is allowed to exit the tenancy.

For example, an email with a list of credit card numbers can be blocked due to the contents, while a single credit card number can be sent but with Office Message Encryption applied. It’s important to note that DLP should be used alongside user vigilance and training, it isn’t designed to replace good practice when it comes to protecting data.

Once defined, DLP can then be extended to SharePoint Online, OneDrive and even Microsoft Teams. To make sure you can extend the policies, they need to be configured as Unified Policies within the Microsoft 365 Compliance Center. Having a single set of rules in the tenant for what can (or can’t) be shared externally via any method, will avoid “Loopholes” in the controls.

For an in-depth look at DLP Policies in Office 365 I highly recommend checking out this article by Paul Cunningham.

Note: DLP for Exchange requires a minimum of Exchange Online Plan 2 licensing

 Summary

There are a lot of methods you can implement to improve the security of your Exchange Online environment, and even more tools out there made by Microsoft and third-party companies that can assist with security initiatives.

And while there are many advanced features and settings to consider down the road, in this article I’ve detailed some of the most important steps that can immediately be implemented out-of-the-box to align your Exchange Online tenant with a good security baseline and posture.

Source Practical 365

There is little debate over whether the Microsoft 365 E5 license is a fantastic product. However, over the past two years, the E5 license offering has matured greatly, and it seems like Microsoft customers would be even more receptive to the upgraded license. If anything, customers will see major benefits from a one-stop-shop approach that replaces the need for third-party endpoint protection and mail hygiene solutions with Microsoft 365 E5 services like Microsoft 365 Defender for Endpoint and Microsoft 365 Defender for Office 365.

But does everything residing only in Microsoft 365 E5 truly belong there?  I’ve been pondering this question for a while now and believe that there is a compelling case for certain premium features to make the journey over to Microsoft 365 E3.

Pros vs. Cons

The benefits are two-fold in my opinion: First, it makes important security features that are no longer simply “nice to have” more accessible to a wider customer base.  It also gives Microsoft the incentive to stay at the leading edge of innovation and bring new and exciting features to their premium offering. While this rationale definitely made sense to me, I was curious as to what my colleagues thought, so I decided to pose the question on my Twitter feed:

The responses were numerous and quite varied, with many opinions on the matter. Before we examine the responses, it should be noted this licensing discussion revolves around Microsoft 365, not Office 365 – two very different things. For example, basic Microsoft 365 E3 security capabilities are not included within the Office 365 E5 license. For more information on how Microsoft 365 and Office 365 differ, you can also refer to this Microsoft page.

Which Features are the Most Wanted in Microsoft 365 E3?

After tallying up the responses, most of those voting for Microsoft 365 E5 were only voting for those specific E5 features.  However, there were two clear favorites in Privileged Identity Management and Auto labelling (Table 1):

Other non-feature specific responses included:

• Eliminate add-on licenses such as Viva and SharePoint Syntex, and add these to Microsoft 365 E5
• Custom license bundles with competitive pricing
• A new SKU for Power BI read-only included in Microsoft 365 E3
• Eliminate Microsoft 365 E3 entirely, and change Microsoft 365 Business to no user limit
• Make tenant wide license feature activation less confusing
• Custom search indexes

So, some quite interesting responses indeed, and overall, a wider range of answers than I anticipated.  What, if anything, can we derive from this straw poll? Let’s examine some of the key takeaways.

Privileged Identity Management and Auto Labeling – an Expensive Luxury

Privileged Identity Management (PIM) enables just-in-time and approval-based access to privileged roles within Microsoft 365.  This means that users who require occasional access to elevated roles do not need to have them permanently assigned to their accounts.  They instead activate the roles on-demand for a limited period of time.

The benefits of this are self-evident – the attack surface is reduced when there are less privileged accounts.  Without PIM available, powerful admin roles will inevitably be granted to users and then forgotten about, which creates a potential vulnerability.

Auto labeling with Microsoft Information Protection provides the means to automatically assign a sensitivity label to Microsoft 365 content based on matches to built-in sensitive information types.  This is an important feature as it reduces the burden on the end-user, who oftentimes do not realize when it’s appropriate and important to apply a label to their emails and documents.

So, what would the impact on Microsoft be if these features were included in Microsoft 365 E3?  It’s difficult to speculate, but these are only two features of Microsoft 365 E5. Their inclusion in the more affordable licensing tier would demonstrate that Microsoft is committed to making important security and compliance features accessible to their wider customer base, and not just those who can afford the cost of a Microsoft 365 E5 subscription.

This is also unlikely to significantly affect subscriptions to Microsoft 365 E5.  Many Microsoft 365 E5 features are justifiably included in the premium subscription, and Cloud App Security and Advanced eDiscovery are two good examples of this.  We have also seen recent innovations with Microsoft 365 E5, such as Insider Risk Management and Communication Compliance.  Therefore, it seems there will still be plenty of exclusive features for Microsoft 365 E5 subscribers.

Questions to Consider

An important question that may provide somewhat of an answer to this debate is, “Where should you start with your Microsoft 365 Security and Compliance posture?”  In this article, Microsoft recently provided updated Security and Compliance guidance aimed specifically at the UK public sector.

They separate their Security and Compliance control capabilities into three categories – Good, Better, and Best.  Microsoft recommends “starting with Better“, which does require some Microsoft 365 E5 functionality.

If “Better” is the minimum recommendation for a Security and Compliance posture for Microsoft 365 public sector customers, then there’s also an argument to be made that even the lowest SKUs (e.g., Office 365 E1) should have at least “Good” security controls.

If you’re surveying Microsoft customers, they will of course answer that they would like the most useful parts of Microsoft 365 E5 as part of Microsoft 365 E3. But If “Better” is the recommended and essential starting point from Microsoft, then why sell products that don’t include these key features?

Playing Devil’s Advocate

Whilst this survey clearly shows there is an appetite for more choice when it comes to Microsoft 365 licensing, there are some other perspectives to consider.

For example, if Microsoft Defender for Office 365 were to be included in Microsoft 365 E3, this could lead to protests from third-party vendors from a competition law standpoint. There are many widely adopted third-party security products used with Microsoft 365 and if a premium feature like Defender became more widely accessible, then many customers may be tempted to discontinue such third-party subscriptions.

We should also consider that some of the premium features of Microsoft 365 E5 may have a clear ongoing cost to Microsoft to run, and these couldn’t simply be thrown into Microsoft 365 E3.  This may be the case for Auto-labelling, for example.

Teams Phone System is a difficult one. Customers must bring their own SIP trunk or purchase calling plans.  On that basis, should they also have to purchase Microsoft 365 E5?  There may be ongoing costs to Microsoft for Teams Phone System that justify this, but we can’t say for sure.

That being said – there is one glaring offender within Microsoft 365 E5 that I find impossible to defend.

Teams DLP Does Not Belong in Microsoft 365 E5!

The presence of Data Loss Prevention for Teams within Microsoft 365 E5 only, is baffling to me.  The arguments above on adding PIM, Auto labeling, or any other Microsoft 365 E5 feature to Microsoft 365 E3 can be debated and counter-argued, as can the need for more customization within license SKU’s.

If I’m going to stick my neck out on one opinion though, it’s that I genuinely don’t feel that DLP for Teams is correctly allocated when it comes to licensing.  How can it be fair for DLP to apply to the other key services within Microsoft 365 within the Microsoft 365 E3 subscription, but not the most relevant product in Microsoft’s recent history – Teams? It’s difficult for me to wrap my head around this decision.

Summary

Licensing is often a confusing and divisive subject, and at the end of the day, it’s all about opinions – of which there will be many.  Whilst no one could expect Microsoft to “give away the farm,” there is always a balance that can be struck or a compromise to be made.

What is clear is that there’s a common view from customers and partners that unless some of the premium features are added to Microsoft 365 E3, these customers will need to either consider buying Microsoft 365 E5 licenses; uplift current licenses for some or all users; or continue to rely on third-party alternative solutions.

Source Practical365

Some Complexities to Consider When Upgrading Scripts

Last month, I wrote about upgrading Exchange Online PowerShell scripts to use the Get-ExoMailbox cmdlet instead of its older Get-Mailbox counterpart. One of the reasons I advanced is that Get-ExoMailbox is faster at retrieving mailbox data, which led to some questions about performance in general. It’s easy (and quick) to fetch data for a few mailboxes, but once you need to deal with hundreds or thousands of mailboxes, it’s important to optimize.

Filtering Data

Which brings me to the topic of filters. It’s common to need to process just a few mailboxes of the full set available in a tenant. Filters apply conditions for PowerShell to select the right mailboxes. The better the filter, the faster you get the mailboxes you want.

Filters come in two variants: server-side and client-side. Server-side means that the data coming back from the server is filtered and ready to go. Client-side means that data comes down from the server and is filtered on the client. Generally speaking, for best performance, the golden rule is to use server-side filtering whenever possible.

Server-side filtering happens when the Filter parameter passes a query against mailbox properties to the server. Exchange PowerShell supports a wide range of filterable properties which can be used with its cmdlets. For example, this command returns mailboxes with the Office property set to Dublin.

The equivalent client-side filter fetches all mailboxes and pipes the set to a Where command to filter out the desired mailboxes:

At first glance, you’d expect this code to work because the approach works with Get-Mailbox. But it doesn’t because the Office property is not in the default property set returned by Get-ExoMailbox. Remember, part of the reason why the REST cmdlets are faster than their Remote PowerShell counterparts is the reduction in the number of properties they return. To make our code work, we must tell Get-ExoMailbox to fetch the Office property.

You don’t have to worry about specifying properties when you use server-side filtering because Exchange applies the filter on the server. The property restriction only applies for data returned to the client.

Remember that other parameters cause filtering to happen on the server too. Combining these parameters together creates an even more precise query. In this example, we add the RecipientTypeDetails parameter to instruct Exchange Online to return only user mailboxes:

Specifying the number of objects to be returned is also another form of filter:

The critical point is to be as specific as possible in requesting data from the server. This will speed processing up and mean that you don’t need to discard information when it gets to the client.

Inconsistencies in Filters

A couple of inconsistencies exist in the way that server-side filtering happens for the new cmdlets. For example, you need to be careful with wildcards. Microsoft’s documentation says:

The -like and -notlike operators are limited in using wildcards (*). Specifically, you can only use wildcards at the beginning of a string value, at the end of a string value, or both.

This text makes it seem like you could take a command like this:

And upgrade it to use Get-ExoMailbox instead:

But the command fails with an invalid filter clause, which proves the need for testing even when a statement in Microsoft documentation gives reassurance that something should work.

Reversing Advice

For years, people have applied the golden rule to use server-side filtering to fetch mailbox data. But as we’ve just seen, the REST-based cmdlets do not work in the same way as the older cmdlets. In fact, the Exchange Online development team found that client-side filtering is faster for the new cmdlets, including Get-ExoMailbox. Microsoft says that they’re working on improving server-side filtering for the cmdlets.

After running some tests, it seems like the cause for Microsoft’s assertion is the way that Get-ExoMailbox needs to “warm up” when finding mailboxes. This includes preparing for result pagination, connecting to mailbox servers, and so on. The effect of warming up is easily seen by running the same query multiple times. The first run is always slowest and runs thereafter are much faster, and is easily verified using the Measure-Command cmdlet to run a command several times.

However, with an eye on future performance improvements, I’m not sure that I want to follow Microsoft’s recommendation to use client-side filtering with Get-ExoMailbox. The performance penalty at present doesn’t seem excessive and staying with server-side filtering avoids the need for further change in the future. However, this theory must be tested in the context of individual scripts. For some, it will be best to convert to client-side filtering, for others, the best decision is to stay as is.

Source Practical365