Unlimited Exchange Online Archiving is no longer Unlimited

TLDR: Microsoft has added size restrictions to Unlimited Archiving (aka Auto-Expanding Archiving). The change will take effect beginning November 1, 2021. Once this limit takes effect, users will not be able to extend their online archives beyond 1.5TB.

Upcoming Changes to Auto-Expanding Archive

MC288051 · Published 29 Sept 2021 · Last updated 30 Sept 2021

 

Message Summary

Updated September 30, 2021: We have updated the content below for additional clarity. Thank you for your patience.

We will be removing the word ‘Unlimited’ from our service description and related public documentation for the auto-expanding archiving feature, and instituting a 1.5TB limit for archive mailboxes. This limit is not configurable.

 

Key points

• Timing: This change will take effect beginning November 1, 2021 and is applicable to all environments.
• Roll-out: tenant level
• Action: review and assess

 

How this will affect your organization

Once this limit takes effect, your users will not be able to extend their online archives beyond 1.5TB. As currently noted in our documentation, auto-expanding archive is only supported for mailboxes used for individual users or shared mailboxes with a growth rate that does not exceed 1 GB per day. Using journaling, transport rules, or auto-forwarding rules to copy messages to Exchange Online Archiving for the purposes of archiving is not permitted. A user's archive mailbox is intended for just that user. Microsoft reserves the right to deny auto-expanding archiving in instances where a user's archive mailbox is used to store archive data for other users or in other cases of inappropriate use.

If you have previously worked with Microsoft Support to provide exceptions for existing archives exceeding 1.5TB, those specific archives will not be affected by this change. You will not, however, be able to create any new archives that exceed 1.5TB.

 

What you need to do to prepare

You should check the size of archives in your organization if you are concerned that they might be close to the limit and consider deleting some of the content if you intend to continue adding to the archive. You can use Get-MailboxFolderStatistics to view archive mailbox size.

How to set OWA Language and Time zone using PowerShell

When a user first logs on to Outlook Web App (OWA), he/she gets prompted to set their language and time zone:

 

Can we, as administrators, pre-set these for users or change them after they have been set, for example? Of course! To do this, we use the Get/Set-MailboxRegionalConfiguration cmdlet:

The two parameters we are interested for this scenario are:

• Language: specifies the language setting, such as en-us, that would apply for the mailbox;
• TimeZone: specifies the time zone, such as Pacific Standard Time, that the mailbox in the specified region uses. The default value is the time zone setting on the server.

Let us say, for example, that we want to set everyone’s mailbox to American English and Pacific time. To do this, all we need to run is:

Get-Mailbox –ResultSize Unlimited –Filter {RecipientTypeDetails –eq "UserMailbox"} | Set-MailboxRegionalConfiguration –Language en-US –TimeZone "Pacific Standard
Time"

How to Change Exchange EAC Language

When we first login to the Exchange Admin Center (EAC), we are greeted with the language selection screen and time zone. But how do we change EAC’s language after that? The answer is to use Outlook Web App (OWA). Once you have logged into OWA, select the cog icon in the top right hand corner and then click Options:

Next, go to settings in the options menu, and on the right hand menu select regional. Now edit the language and time zone settings to what you want as these settings also apply to the EAC:

But what about for environments where administrators do not have mailboxes? How do they change EAC’s language if they do not have access to OWA? In this case, you can specify the language you want to use in the URL itself. For example, for American English, add ?mkt=EN-us to the EAC’s URL: https://mail.domain.com/ecp?mkt=EN-us

This works for both on-premises Exchange 2013 and above, and Office 365.

How to Disable Microsoft Stream

As an Office 365 Global Admin, you can prevent some or all users in your organisation from being able to use Stream. This is typically done in cases where employees are already using Office 365 Video or if Stream has not been approved by all parts of your organisation.

When a first user from any organisation signs-up for Microsoft Stream using their corporate credentials, Microsoft Stream service is registered as an application in the organisation's Office 365 tenant. The license is automatically assigned to the user who signed up. There are additional licenses available for the IT admin to assign to other users in the organization without them going through the sign up process.

Important: as an admin, you can unlicense users from the Office 365 admin center. However, even though you might have removed Microsoft Stream license from a user, they have the option to sign-up via a free trial and get access to your organisation's Stream portal.

 

To turn off Microsoft Stream for everyone, follow these steps:

1. As an Office 365 Global Admin, log in to the Azure portal;
2. In the Azure Active Directory (AAD) section, click Enterprise Application, and then in the Manage section, click All Applications;
3. Change the filters to Show All Applications with All Application Status, and then click Apply;
4. Search for Microsoft Stream Service from the list of applications, or search by the GUID 2634dd23-5e5a-431c-81ca-11710d9079f4 for Microsoft Stream Service:

5. Click the Microsoft Stream Service application, and then under Manage, click Properties;
6. Set Enabled for users to sign-in flag to No;
7. Click Save:

 

You have now blocked access to all users for Stream. When a user now tries to access Stream, they will receive the following error message:

RecipientNotFoundPermanentException when migrating a mailbox to Exchange Online

The other when migrating a mailbox from an on-prem Exchange 2013 environment to Exchange Online, I was faced with a RecipientNotFoundPermanentException error with the message “Error: Cannot find a recipient that has mailbox GUID '39c970e4-4869-47ee-b9af-f6fd6264ee0a'.”

 

These were the details for the mail user in Exchange Online (notice the ExchangeGuid attribute):

 And these were the details for the mailbox on-premises:

  

As you can see, the ExchangeGUID was the same! And where was that '39c970e4-4869-47ee-b9af-f6fd6264ee0a' GUID coming from?!

After much troubleshooting, I ended up logging a support ticket with Microsoft. According to the engineer, “this issue is caused due to multiple mailbox shards”. Unfortunately, he wouldn’t go into details as apparently it is all secret stuff... But he ran some diagnostics to resolve the issue, and after a few minutes all was well with the world again!

Block emails delivered directly to user@domain.onmicrosoft.com or user@domain.mail.onmicrosoft.com (MX Bypass)

Let’s assume I have my mailbox in Exchange Online with an email address of nuno@domain.com. External users can send emails directly to nuno@domain.onmicrosft.com (the tenant’s default domain) or to nuno@domain.mail.onmicrosoft.com (typically used in Hybrid environments) and they will be delivered to my mailbox. This is because these two managed domains are fully managed by Microsoft and have internet-routable MX records:

Not a big problem for “pure” Office 365 organizations as these emails are still subject to Exchange Online Protection (EOP) policies such as anti-spam and anti-malware. However, this is a problem for organizations that use a 3^rd-party service for message hygiene. In this scenario, these emails would completely bypass the 3^rd-party and all the security measures it enforces.

There are a few solutions out there that rely on mail flow (transport) rules to either reject or redirect these emails back to the 3^rd-party provider, but these never quite worked for me... The main reason is that transport rules are processed post onresolveMessage event and when this happens the email address for the recipient changes to the PrimarySMTPAddress which has the domain.com suffix.

The solution I ended up implementing was slightly different. I created an Inbound Partner Connector, set the sender domain address space to *, and restricted it to only accept emails if the sender presents the certificate I have configured on my on-prem Hybrid servers (you can also restrict it to your on-prem or 3^rd-party IP addresses). The following procedure assumes that we have a setup in which we have executed the Hybrid Configuration Wizard (HCW) successfully (which would have created the required connectors for mail flow).

First, we run the following command to get a list of inbound connectors configured by HCW. If you have Hybrid across multiple Exchange Organizations, then you’ll see more than one entry.

$onpremorg = Get-OnPremisesOrganization | Select OrganizationGuid, InboundConnector | Where {$_.InboundConnector -ne $null}

$onpremorg

If the Inbound Connector was configured by the HCW, then the attribute TlsSenderCertificateName will map either to the domain name included in the subject or subject alternate name attribute of the 3^rd-party certificate used, or it will contain the details of the certificate.

Next, we create the inbound partner connector using the following command:

New-InboundConnector -Name “Block Direct Delivery” -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName (Get-InboundConnector $onpremorg[0].InboundConnector).TlsSenderCertificateName -RestrictDomainsToCertificate $True -RequireTls $True

Once this connector is in place, any external senders that try to email nuno@domain.onmicrosft.com or nuno@domain.mail.onmicrosoft.com will receive the following NDR:

Emails sent to Exchange Online mailboxes routed through the on-prem Exchange servers, will always use the Inbound connector created by the HCW, while service emails like notifications from Teams, SharePoint Online, etc., will use the default connectors.

If you use a 3^rd-party service for message hygiene but your emails flow directly from the 3^rd-party to Exchange Online, you can still use this method, but instead of restricting the connector to a certificate using the RestrictDomainsToCertificate parameter, you can restrict it to the IP(s) of your 3^rd-party service by using the RestrictDomainsToIPAddresses parameter.

Collecting Microsoft Teams Logs

Microsoft Teams has three different types of logs, which get stored on different locations.

Web Logs
Consists of most Teams client activity.

• Windows: to capture logs, open Teams and press CTRL+ALT+SHIFT+1 in the client, and the logs will be downloaded to %downloads%\MSTeams Diagnostics Log.txt
• MAC: press Command+Option+SHIFT+1 in client to download logs to Downloads\MSTeams Diagnostics Log.txt

Desktop Logs
This log has most information about framework and bootstrapping information, app bootstrap process, plugin initialization, update management and SSO/ADAL Sign in information.

• Windows: %appdata%\Microsoft\Teams\logs.txt
• MAC: ~/Library/Application Support/Microsoft/Teams/logs.txt

Media Stack Logs
This log has media connectivity related information.

• Windows: %appdata%\Microsoft\Teams\media-stack
• MAC: ~/Library/Application Support/Microsoft/Teams/media-stack

Microsoft Teams Mobile client (iOS):
To collect log on Teams mobile client, open Microsoft Teams app -> Settings -> Report an issue. A new email will open with log.txt attached.

How to disable Office 365 self-service purchase

I am sure by now you have heard or read about Microsoft plans to allow Office 365 users to make self-service purchases for the Power Platform. This created such a storm of critics and complaints that Microsoft postponed the introduction of this feature to January 14, 2020. Additionally, it has finally released a way for admins to block such feature.

“Beginning January 14, 2020, self-service purchase, subscription, and license management capabilities for Power Platform products (Power BI, Power Apps, and Power Automate) will be available for commercial cloud customers in the United States. Self-service purchase gives users a chance to try out new technologies and lets them develop solutions that will ultimately benefit their larger organizations. This capability will not be available to tenants in the US that are government, nonprofit, or education, at this time. Central procurement and IT teams will have visibility to all users buying and deploying self-service purchase solutions through the Microsoft 365 admin center, and will be able to turn off self-service purchasing on a per product basis via PowerShell.”

On November 19, Microsoft updated their self-service FAQ and stated that “Admins can also control whether users in their organization can make self-service purchases. For more information see Use AllowSelfServicePurchase for the MSCommerce PowerShell module.”

The MSCommerce PowerShell module is now available on PowerShell Gallery. The module includes a PolicyID parameter value for AllowSelfServicePurchase that lets you control whether users in your organization can make self-service purchases.

You can use the MSCommerce PowerShell module to:

• View the default state of the AllowSelfServicePurchase parameter value — whether it's enabled or disabled;

• View a list of applicable products and whether self-service purchase is enabled or disabled;

• View or modify the current setting for a specific product to either enable or disable it.

To use the MSCommerce PowerShell module, you need:

• A Windows 10 device;

• Administrator permission for the device;

• Global or Billing Admin role for your tenant.

Install the MSCommerce PowerShell module

Download the MSCommerce PowerShell module from the PowerShell Gallery. To install the MSCommerce PowerShell module with PowerShellGet, run the following command:

Install-Module -Name MSCommerce

Import MSCommerce into the PowerShell session

After you install the module, import it into the PowerShell session by running the following command:

Import-Module -Name MSCommerce

Connect to MSCommerce

Finally, connect to the PowerShell module with your credentials. This command connects the current PowerShell session to an Azure Active Directory tenant. The command prompts you for a username and password for the tenant you want to connect to. If multi-factor authentication is enabled for your credentials, you use the interactive option to log in.

Connect-MSCommerce

View details for AllowSelfServicePurchase

To view a description of the AllowSelfServicePurchase parameter value and the default status, based on your organization, run the following command:

Get-MSCommercePolicy -PolicyId AllowSelfServicePurchase | FL

View a list of self-service purchase products and their status

To view a list of all available self-service purchase products and the status of each, run the following command:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

View or set the status for AllowSelfServicePurchase

After you view the list of products available for self-service purchase, you can view or modify the setting for a specific product. To get the policy setting for a specific product, run the following command:

Get-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KP0N

To enable the policy setting for a specific product, run the following command:

Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KP0N -Enabled $True

To disable the policy setting for a specific product, basically preventing users from purchasing licenses themselves, run the following command:

Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KP0N -Enabled $False

To disable all three at the same time, you can use the following command:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | ForEach {Update-MSCommerceProductPolicy -PolicyId $_.PolicyID -ProductId $_.ProductID -Enabled $False}

The onboarding move could not be created because user ‎is already being moved

When migrating mailboxes to Exchange Online in a Hybrid environment, you might encounter the following error:

PS C:\> Get-MigrationUser user@domain.com | FL

Identity            : user@domain.com
BatchId             : Pilot Migration 1
MailboxEmailAddress : user@domain.com
RecipientType       : MailboxOrMailuser
Status              : Failed
StatusSummary       : Failed
MigrationType       : ExchangeRemoteMove
State               : Failed
WorkflowStep        : DataMigration
WorkflowStage       : Injection
ErrorSummary        : The onboarding move could not be created because user 'User' is already being moved.

If you have already checked all your migration batches (Get-MigrationBatch) and/or all your individual move requests (Get-MoveRequest “user”) and there is absolutely no move request associated with this user, then it is very likely you still have a move request for the user in your on-premises Exchange environment.

So, go to your on-premises environment and remove the local move request for that particular user. This should clear the msExchMailboxMoveRemoteHostName AD attribute. Other attributes related to move requests that you can also check are:

• msExchMailboxMoveBatchName
• msExchMailboxMoveFlags
• msExchMailboxMoveRemoteHostName
• msExchMailboxMoveSourceMDBLink
• msExchMailboxMoveStatus
• msExchMailboxMoveTargetMDBLink

Understanding Office 365 Exchange Online migration endpoints

For a few years now, Microsoft has provided pretty much the same types of migration for organizations to use to migrate email data to Exchange Online in Office 365 from on-premises messaging systems, be that Exchange or not. Additionally, end users themselves can also import their own email, contacts, and other mailbox information to an Office 365 mailbox created for them, but that’s typically only used in very small migrations.

Part of the migration process, excluding some third-party migrations, is the configuration and use of one or more Exchange Online migration endpoints. These are simply a connector from Office 365 to the on-premises email system, and that’s what this article focuses on.

To read the full article, please head over to TechGenix or click on this link: Understanding Office 365 Exchange Online migration endpoints.

Office 365 Admin App for Windows 10

Microsoft has released the beta version of the Office 365 Admin app for Windows 10, which is available for both Windows 10 Desktop and Mobile!

This app gives admins the ability to administer Office 365 directly from their desktop. It supports notification integration with Windows 10 as well as Microsoft Partner scenarios, allowing admins to easily switch organizations if they manage Office 365 for multiple tenants. The mobile version has the exact same user experience making switching from desktop to the mobile app extremely easy.

To install it, search for “office 365 admin” in the Windows App Store and you should find it straight away. Click Install and, once installed, click Open: 

Alternatively, once installed, search for “office 365” in your start menu:

Simply add an account for an Office 365 tenant you want to manage:

Once logged in, the app’s dashboard provides some high level information about the service and the tenant itself:

We can search for all users provisioned in the tenant:

As well as perform a variety of actions on user accounts or gather further information about them:

We can check the current health of the Office 365 tenant:

Read any available messages:

And much, much more! Give it a try :)

Updating AADSync Scheduled Task

If you ever need to update AADSync’s scheduled task, it is likely that you will need to update the credentials it runs under. When you do that, and if you do not assign the correct permissions, you might get the following error message:

 

This is because the account used does not have the required permissions. Make sure you add it to the local Admins group and to the local ADSyncAdmins group.

Office 365 Compliance Center

The new Compliance Center contains the key compliance-related features for an Office 365 administrator to manage compliance across Office 365, Exchange Online and SharePoint Online.

 

Currently many of the compliance features are still accessible through service-specific management interfaces, such as the Exchange Admin Center. However, this will change in the future as more service independent compliance features are added to the Compliance Center.

 

Consolidating compliance functionality across services into this single area will make compliance features easier to access and enhance your end-to-end task-based experience.

 

To access the Compliance Center you can either go directly to its URL at https://compliance.protection.outlook.com/Ucc or, if you are an Office 365 administrator:

1. Sign in to Office 365;

2. Select the app launcher icon in the upper-left and choose Admin:

 

3. In the lower-left navigation, expand Admin and choose Compliance:

 

4. You are then taken into the new Compliance Center:

 

 

As mentioned, this is currently being rolled out so it is possible that you will not see all the features in here just yet. For example, there will be an Auditing section as well which is not yet present in my tenant.

 

Stay tuned for a full article on the new Office 365 Compliance Center!

AADSync Performance Counters Error

While working on a project recently, I came across the following error on my AADSync server:

Log Name:      Application
Source:        ADSync
Date:          1/12/2015 12:47:11 PM
Event ID:      6313
Task Category: Server
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      AADSync.contoso.com
Description: The server encountered an unexpected error creating performance counters for management agent “xxxxx.onmicrosoft.com – AAD”.

Performance counters will not be available for this management agent.

To fix this issue in AADSync, you can either perform a clean install (often out of the question) or run the following commands to reload the performance counters:

1. Stop AADSync’s service;
2. Delete the following registry key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADSync\Performance];
3. Recreate the Performance key;
4. Run the following two commands from an elevated command prompt:
• unlodctr.exe ADSync
• lodctr.exe “C:\Program Files\Microsoft Azure AD Sync\Bin\mmsperf.ini”
5. Start AADSync’s service.

Exchange Online Protection Quarantine

A decade ago, Bill Gates predicted a spam-free world by 2006. Although we are seeing a small decline in spam, this is unfortunately far from coming true... Exchange Online Protection (EOP) does a great job, in my opinion, at filtering out obvious spam. According to the latest figures from Microsoft, ten million spam messages are blocked every single minute on average by EOP, 10 million! That is an impressive number. However, every day attackers around the world come up with new techniques to fool spam detection engines. Threats take different forms, such as an unidentified spam campaign, unknown malware or a completely new virus. This means that a small percentage (around 3%) of email that is likely to be spam still comes through and are sent to users’ Junk E-mail folder. Users obviously do not want spam in their inboxes, but they often have to review this folder to make sure no good messages (false positives) are mixed in with the bad.

 

EOP provides two main methods of handling spam detected by its content filters. Administrators can configure it so that spam is sent to the Junk E-mail folder in Outlook and Outlook Web App (OWA), which is the default option, or to direct it into a web-based quarantine.

 

Sending spam to the Junk folder is the most common choice as that is what users have been using for many years. But from experience I also noticed that this is the case as not everyone is aware of the quarantine feature. On the other hand, some customers have non-Exchange email systems that do not support the Junk E-mail folder approach, have a 3rd party filtering system that sends spam reports to users, or simply prefer the spam quarantine.

 

Since EOP was launched it has supported spam quarantine, but initially administrators were the only ones who had access to this quarantine, through the Exchange Admin Center, and only they were able to release spam messages... But for some time now administrators can configure EOP to give users self-service management of spam-quarantined messages. So let us have a look at how this works and how we can configure it.

 

 

In this article, we will explore the Quarantine feature of EOP, including how to enable, configure and manage it both from the administrator and end user perspectives. To continue reading, please go to the Exchange Online Protection Quarantine article at MSExchange.org.

Speeding up the Exchange Hybrid wizard in global deployments

If you ever ran the Exchange Hybrid wizard in an environment with servers all over the world, it is likely that it took a few hours to run. But why?

 

If we look at the wizard’s logs ($exinstall\Logging\Update-HybridConfiguration), we will see that most of the changes are fairly quick. However, it eventually goes on to run a Get-WebServicesVirtualDirectory to analyse the EWS virtual directories (VDs) across all Exchange servers in the environment to determine if any need to be configured. If this comes back true, then the wizard runs the same cmdlet again followed by a Set-WebServicesVirtualDirectory to enable the MRS Proxy for VDs that currently have it disabled. After all the necessary EWS VDs are configured, the wizard runs a Get-WebServicesVirtualDirectory for a third time to validate the configuration/changes made.

 

The problem here is running the *et-WebServicesVirtualDirectory cmdlet between servers in different countries or even continents. How long does it take for you? Usually it should be a few minutes for each server, but I have seen cases where it takes 30 minutes or more. Now multiply that by the total number of Exchange servers and it can quickly turn into hours and hours...

 

If, for example, your environment also has Exchange 2007 servers, although these do not use or have the MRS Proxy service, because the wizard simply runs the Get-WebServicesVirtualDirectory cmdlet, this returns 2007 servers (instead of filtering them out...), which contributes to delaying the process.

 

So, to speed things up a bit, you can manually login to all the servers, enable the MRS Proxy and only then run the Hybrid Wizard. Typically I was only enabling it on the Hybrid servers or servers that I was planning to use for mailbox migration, but the wizard enables it across estate anyway...

 

 

To recap, the Mailbox Replication Service Proxy (MRS Proxy) facilitates cross-forest mailbox moves and remote move migrations between an on-premises Exchange organization and Exchange Online. During cross-forest and remote move migrations (aka hybrid migrations), a Client Access server acts as a proxy for incoming move requests for the Mailbox server. The ability of a Client Access server to accept these requests is disabled by default. To allow the Client Access server to accept incoming move requests, we have to enable the MRS Proxy endpoint.

Azure Active Directory Connect Public Preview

The latest version of the Azure AD Connect has been released – the March 2015 Public Preview update.

The Azure AD Connect wizard Public Preview provides a guided experience for integrating one or multiple AD forests with Microsoft Azure AD. Optionally you can configure Exchange Hybrid deployment, password change write-back, ADFS and Web Application Proxy.

Azure AD Connect encompasses functionality that was previously released as DirSync and AADSync. These tools will eventually stop being released individually and all future improvements will be included in updates to Azure AD Connect.

This latest version has been updated with new capabilities, support for additional sync options, Additional Tasks and “Pilot Mode”.

You can download it from the Connect website.

Dynamic Distribution Lists in a Hybrid Environment

In a hybrid deployment environment between Exchange Online and on-premises Exchange organizations, neither DirSync nor AADSync can be used to synchronize dynamic distribution lists (DDL) to Exchange Online. Therefore, mailboxes that have been migrated to Exchange Online cannot see DDLs in their GAL or email them.

 

To work around this issue, create a MailContact in Exchange Online for the DDL, and then grant permissions so that only authenticated senders can submit messages to the new contact. This object should have the following mappings:

 

On-Premises DDL	Cloud MailContact
Name	Name
proxyAddress	ExternalEmailAddress
Alias	Alias

 

You should also consider the scope of the DDL before mailboxes are moved to Exchange Online. If the scope included only mailboxes, the scope must be expanded to include mail users and mail contacts. To do this, open the properties of the DDL and on the membership tab (in Exchange 2013), also select Mail users with external email addresses. If using the Shell, add MailUsers to the IncludedRecipients property of the DDL.

 

Exchange Online users can now select the DDL from the GAL. When they do, messages will be delivered to the members of the group as defined by the settings for the group.