After decommissioning the Resource Forest I still have an Exchange 2016 environment on-premises, but all my mailboxes are in Office 365. Users are provisioned in Active Directory, Remote Mailboxes are provisioned in Exchange 2016 and everything is synchronized to Office 365 using Azure AD Connect.
Do I still need an Exchange Hybrid Configuration? Unless there are plans to move resources back to Exchange on-premises there’s no need for a Hybrid Configuration. To stay in a supported configuration, an Exchange server on-premises is still needed for management purposes, but only Azure AD Connect is needed and not a full hybrid configuration.
Note. If you want to use the on-premises Exchange server for SMTP relay purposes you don’t need the Hybrid configuration either. Just make sure you have a SMTP Send Connector that points to Exchange Online Protection and you’re good.
Removing the Hybrid configuration consists of the following steps:
Disable Autodiscover SCP in Exchange
Remove the Hybrid Configuration from Active Directory
Remove Connectors in Exchange Online
Remove the Organization Sharing from Exchange Online
Disable OAuth
Disable Autodiscover SCP in Exchange
When all Exchange resources are in Exchange Online you no longer need the on-premises Service Connection Points (SCP) for Autodiscover. But make sure you have the correct CNAME records for Autodiscover that point to Autodiscover.outlook.com.
To disable the SCP records in Active Directory, execute the following command in Exchange Management Shell:
Remove the Hybrid Configuration from Active Directory
Removing the Hybrid Configuration from Active Directory is just one PowerShell command in Exchange Management Shell:
Remove-HybridConfiguration -Confirm:$false
There’s one pitfall here, this will also remove the outbound to Office 365 Send Connector from Exchange. If you want to keep SMTP relay from on-premises to your mailboxes in Exchange Online you have to manually recreate this connector (use yourdomain-com.mail.protection.outlook.com as a smarthost for this)
Remove Connectors in Exchange Online
In the Exchange Online Admin Center, remove the outbound SMTP connectors that point from Exchange Online to your on-premises Exchange organization. If you want to keep SMTP routing, keep the inbound SMTP connector, otherwise you can remove this as well.
Remove the Organization Sharing from Exchange Online To remove the Hybrid Organization Sharing from Exchange Online navigate to Organization | Sharing in the Exchange Admin Center and remove the organization sharing.
Disable OAuth on-premises
When used before you can disable the OAuth configuration as well from Exchange on-premises and Exchange Online.
In Exchange on-premises Management Shell, execute the following command:
These are the steps needed to remove the Hybrid Configuration from your Exchange environment.
Note. Microsoft recommends to leave the Exchange Hybrid option in Azure AD Connect.
Summary
In this blogpost I explained how to remove the Hybrid Configuration from your Exchange environment after you have moved all resources to Exchange Online.
The on-premises Exchange server is still needed for management purposes. After removing the Hybrid Configuration you can still manage your recipient Exchange Online using the on-premises Exchange server, all changes are replicated through Azure Active Directory.
Is that last Exchange server on-premises still needed? Yes, you need it for managing your recipients in Exchange Online. When you have Azure AD Connect running in your environment, the objects are managed in on-premises Active Directory. The source of authority is Active Directory. As long as Microsoft hasn’t fixed the source of authority problem, an Exchange server on-premises is still needed.
Two years ago I wrote a number of blogpost regarding an Exchange Resource Forest model and Office 365 starting at Exchange Resource Forest and Office 365 part I. There are four articles, at the end of each article you’ll find a link to the next article.
Over the years I have received several requests about how to decommission the Exchange Resource Forest when all mailboxes have been migrated to Office 365. This is a valid question, why keeping an empty forest with only an Exchange server, including the complex configuration with provisioning remote mailboxes. It is not too difficult to achieve, it’s just a matter of moving the Exchange server from the resource forest to the account forest. Unfortunately, not a word about supportability of such a migration, but it is a method that Microsoft uses for collapsing forests or Active Directory migrations.
To decommission the resource forest, the following steps need to be executed:
I will go through these steps in this last article of the series.
Step 0. The existing situation
This series started with Exchange 2010 in a resource forest and was configured in a hybrid environment. Exchange 2010 was upgrade to Exchange 2016 and now all mailboxes are moved to Office 365. The existing situations is shown in the image below:
Exchange 2016 is configured in a hybrid environment, there’s an Exchange 2016 Edge Transport server and the MX record points to this environment. Outbound email is sent directly from Exchange Online, but in my environment MX has never changed (because of Public Folders have existed for a long time in Exchange 2016). Azure AD Connect is running in the account forest and is combining information from the account and the resource forest, and sends this to Azure AD.
Step 1. Install Exchange in the account forest
The first step is to install Exchange 2016 in the account forest. This will make changes to the Active Directory Schema, Configuration and Domain partition, but existing user accounts will not be touched at this point. Because of this, Azure AD Connect won’t notice anything and no changes will be sent to Azure Active Directory.
Warning! Service Connection Point! When installing Exchange 2016 in the account forest you have to be aware that a Service Connection Point (SCP) is created during installation. Depending of the outlook clients being used, they can pick up this SCP in AD within minutes and when not configured correctly Outlook clients can end up with a corrupted profile (been there, done that unfortunately). To work around this, you can use Tony Murrays script as mentioned in the SSL Certificate warning during or after Exchange server setup blog. Make sure you use the same AutodiscoverURL as used in the resource forest (or set the well-known GUID of the SCP to NULL of course).
Other than this I won’t go into detail about installing the Exchange 2016 server, and I assume the Virtual Directories, SSL certificates, internal- and externalURL are identical. It is a new and most likely greenfield deployment, so you have to configuring everything, ranging from the Offline Address Book to the OWA and ActiveSync policies and everything between in between. Oh, and don’t forget stuff like the Accepted Domains and Email Address Policies to set the correct email addresses when creating new remote mailboxes. Did I also mention the routing infrastructure and SMTP relay options? It looks simple, but there’s quite a lot of work involved before even starting to move resources….
Step 2. Move Exchange resources to the account forest
The second step is to move resources from the resource forest to the account forest, to begin with the Distribution Groups followed by the mailboxes.
Moving Distribution Groups
You can use ADMT to clone Distribution Groups but exporting Distribution Groups using PowerShell works fine as well, for example with the following commands.
Import the CSV file in Exchange 2016 in the accounts forest and you’re good. Optionally you can export and import options like HiddenFromAddressListEnabled, MemberJoinRestriction, MemberDepartRestriction and ManagedBy when used of course. As long as the PrimarySmtpAddress property of the new Distribution Group is identical to the Distribution Group in the resource forest Azure AD won’t complain and everything will continue to work in Office 365 as expected.
Similar to this you can use the Get-ADGroupMember PowerShell command to export members of Distribution Groups and use Add-ADGroupMember to import the members in Distribution Groups in the accounts forest.
Moving Mailboxes
Moving mailboxes from the resource forest to the account forest is not a big thing. Remember that Azure AD Connect combines the user account in the account forest and the mailbox account in the resources forest and sends this to Azure AD. So, you can safely add properties to the user account in the account forest without breaking things.
You can use the Enable-RemoteMailbox command on the user account in the account forest without breaking things in Azure AD Connect. This also means that during testing you can use the Disable-RemoteMailbox command in the accounts forest, and Azure AD Connect won’t complain either.
To move mailboxes from the resource forest to the account forest I used PowerShell to export a list of mailboxes and their properties to a CSV file containing the following properties:
PrimarySmtpAddress.
RemoteRoutingAddress.
ExchangeGuid.
Alias.
DisplayName.
EmailAddresses (beware, this is a multi-value attribute).
HiddenFromAddressListsEnabled.
To export these properties, you can use the following commands on an Exchange server in the resource forest to get all information in a CSV file:
In my hybrid resource forest I had a few room mailboxes. These had a disabled account in the resource forest, but no account in the accounts forest. These had to be converted to linked mailboxes. To do this and to avoid disruption in Office 365 I moved the room mailbox back to Exchange 2016 and converted this room mailbox to a linked mailbox using the following commands:
And then moved the room mailbox back to Exchange Online to continue with the process of moving mailboxes to the account forest.
Quad Erat Demonstrandum, after enabling the remote mailboxes in the account forest and importing all additional properties Azure AD Connect continued to run as expected, no errors were logged in Azure AD and nothing strange happened in Exchange Online.
Step 3. Reconfigure Azure AD Connect
When all mailboxes and Distribution Groups are moved to the accounts forest, Azure AD Connect can be reconfigured. This is not a big deal. In the resource forest environment, Azure AD Connect takes the user account details from the accounts forest and combines this with the mailbox information from the resource forest based on the MasterAccountSID. But now all data can be read from the account forest, the resource forest can just be removed from Azure AD Connect.
When you start Azure AD Connect on the Azure AD Connect server, click Configure and select Customize Synchronization Options from the Additional tasks menu you’ll find there’s only a way to add additional forests and not the option to remove it.
To remove the resources forest from Azure AD connect the connectors to this forest should be removed from the configuration. This can be achieved using the MIISClient on the Azure AD Connect server (can be found in C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe). I typically have a shortcut to this useful application on my desktop.
Before starting stop the synchronization using the following PowerShell command:
Set-ADSyncScheduler -SyncCycleEnabled $False
Open the Synchronization Service Manager (MIISClient.exe) and click on Connectors. Select the connector to the resource forest, right click and select delete.
In the pop-up select the Delete Connector and Connector Space option, this will remove the connector and all configuration data. Click Yes to confirm and the forest is removed from Azure AD Connect.
The second step in reconfiguring Azure AD Connect is to refresh the schema so that Azure AD Connect ‘knows’ all properties are now coming from the account forest. In Azure AD Connect click on Refresh directory schema, enter the account forest credentials and that’s all.
Enable the synchronization again and start a full sync using the following PowerShell commands:
Set-ADSyncScheduler -SyncCycleEnabled $True
Start-ADSyncSyncCycle -PolicyType Initial
At this point we’ve successfully moved all Exchange resources from the resource forest to the account forest and removed the resource forest from Azure AD Connect. Exchange 2016 in the resource forest is no longer used and can be decommissioned at all. Before doing this, makes sure you copy the contents from the old administrator mailbox (in the resource forest) to the new administrator mailbox (in the account forest).
Cool: since there still is an Edge Subscription between the Edge Transport server and the old Exchange 2016 server (which at this point still has the remote mailboxes) mail flow is unaffected and is still delivered to the correct mailbox in Exchange Online.
Rerouting inbound mailflow is easy in this scenario. Create a new Edge Subscription between the existing Edge Transport server and the new Exchange 2016 server and you’re good. Make sure there’s a Send Connector from Exchange 2016 to Exchange Online Protection as well.
Note. Don’t forget to reconfigure internal mail flow like SMTP relay, applications, (multi-functional) devices etc.
Step 4. Reconfigure the Hybrid Configuration
Do you need to reconfigure the Hybrid Configuration? Theoretically not, Active Directory and Exchange information is sent to Azure Active Directory using Azure AD Connect and there’s no need to have a hybrid configuration. But, I also use the hybrid configuration for SMTP relay (I know, there are different solutions) and I’d like to have the option to move mailboxes back to Exchange on-premises, just in case.
Running the Hybrid Configuration Wizard here is not different than any other HCW deployment so I won’t go into detail about that.
Step 5. Decommission the Resource Forest
At this point we have a fully operations account forest with Exchange 2016 installed and Azure AD Connect up-and-running. The ‘old’ resource forest is not operational anymore and can be decommissioned. Remove the forest trust between the account forest and the resource forest and remove it. This can be as simple as turning off the VM’s and destroying them (never thought I would write that one down here 😊).
Summary
The Exchange resource forest has been used for quite a time, but with the move to Office 365 I have several customers decommissioning their resource forest. Although maintaining a resource forest can be quite complex, decommissioning it is not.
Install Exchange 2016 in the account forest, move Exchange resources to the account forest and reconfigure Azure AD Connect. These are the most important steps, although provisioning, SMTP relay and corresponding infrastructure are important too, and will take the most time I’m afraid.
But, when the resource forest is finally decommissioned it’s not anymore than a regular single forest, single domain Exchange hybrid configuration.
Two years ago I wrote a number of blogpost regarding an Exchange Resource Forest model and Office 365 starting at Exchange Resource Forest and Office 365 part I. There are four articles, all based on Exchange 2010 and at the end of each article you’ll find a link to the next article. In the more information section at the end of this blogpost you’ll find all links.
Over the years I have received numerous requests on how to continue; moving to Exchange 2016 in a Resource Forest or when all mailboxes are in Exchange Online, decommission the Resource Forest. This is not a problem, but brings a new challenge when it comes to the last Exchange server for management purposes that need to be kept. And yes, this blogpost is the preparation for the ‘decommision the resource forest’ blogpost 😉
I have a few customers running a resource forest environment, and all have this same problem. They must move away from Exchange 2010, either to Exchange 2016 or to Exchange Online (or both). In this blogpost I’ll discuss the upgrade from Exchange 2010 in a Resource Forest to Exchange 2016 (in the same Resource Forest of course) in a hybrid scenario. In one of the next blogs I’ll discuss the way to decommission the Resource Forest in a hybrid scenario.
Upgrading Exchange 2010 in a resource forest is not different then upgrading any other Exchange environment, not even when running this in a hybrid environment. These are the steps that need to be taken:
Design your Exchange 2016 environment (won’t cover that in this blogpost).
Prepare Active Directory for Exchange 2016.
Build your Exchange environment.
Change client access to Exchange 2016.
Run Hybrid Configuration Wizard.
Move Resources to Exchange 2016.
Decommission Exchange 2010.
Prepare Active Directory for Exchange 2016
Before you can install the first Exchange 2016 server, Active Directory needs to be prepared. This is only true for the resource forest, there’s no need to do this at the account forest.
You can prepare the Active Directory schema using the following command:
It is possible that the following error message is shown:
A hybrid deployment with Office 365 has been detected. Please ensure that you are running setup with the /TenantOrganizationConfig switch. To use the TenantOrganizationConfig switch you must first connect to your Exchange Online tenant via PowerShell and execute the following command: “Get-OrganizationConfig | Export-Clixml -Path MyTenantOrganizationConfig.XML”. Once the XML file has been generated, run setup with the TenantOrganizationConfig switch as follows “/TenantOrganizationConfig MyTenantOrganizationConfig.XML”.
Exchange 2016 can be installed on Windows Server 2012 R2 and Windows Server 2016, I always recommend the latter because of support lifecycle. Windows Server 2019 and Windows Server Core are not supported for running Exchange 2016.
I prefer to install the Exchange 2016 server unattended, especially if you must install multiple servers. You can use a command similar to this:
After installing the Exchange server, the server should be configured:
Virtual Directories; make sure you use the same internalURL and externalURL as the Exchange 2010 servers.
SSL Certificates.
Storage, Databases and Database Availability Group (when needed of course).
Relocate (IIS) logfiles.
Send and Receive Connectors (SMTP Relay).
Change client access to Exchange 2016.
When you have configured the Exchange 2016 it is time to test the proxy functionality from Exchange 2016 to Exchange 2010. The easiest way to test this is to edit the HOSTS file for the webmail.contoso.com and Autodiscover.contoso.com entries on a client and point it to the Exchange 2016 server.
From the client, connect to the new Exchange 2016 server and start OWA with an Exchange 2010 mailbox. You should see the initial blue OWA screen:
And after logging on the yellowish Exchange 2010 OWA user interface. It will automatically proxy to the correct Exchange 2010 mailbox server:
One important thing here is that this is a down-level proxy only. This means that when a client does a request to Exchange 2016 for a resource on Exchange 2010 (down-level proxy, like in the previous example) it should work. If a client does a request to Exchange 2010 for a request on Exchange 2016 (i.e. up-level proxy) it fails. This is shown in the following figure, and it does not work.
When all is configured and tested, DNS (internal and external) can be changed so that webmail.contoso.com and Autodiscover.contoso.com point to the new Exchange 2016 server. All clients will now connect to the new Exchange 2016 server and connect to their mailbox on Exchange 2010 without a problem.
One thing you must be aware of is RPC/TCP traffic (the original MAPI connection) between Outlook and Exchange 2010 if you are not running Outlook Anywhere. Outlook will still use RPC/TCP to connect to the CAS Array (this is the RPC Endpoint for Outlook) which is running on the Exchange 2010 servers. You can see that when checking the connection status in Outlook. In the following screenshot, outlook.exchangefun.nl is the CAS Array.
There are two entries shown, one is for the regular mailbox, the second is for accessing a shared mailbox on Exchange 2010.
When performing the Test E-mail AutoConfiguration check on Outlook 2010, you can see that RPC Connects to outlook.exchangefun.nl, but that OWA, EWS and OAB want to connect to webmail.exchangefun.nl, which is the Exchange 2016 server now.
So, Outlook connects using RPC to the Exchange 2010 server and using HTTPS to connect to the Exchange 2016 server. From Exchange 2016 the connection is proxied to the correct Exchange 2010 server.
When all is running well it is time to upgrade the Hybrid Configuration by running the HCW on the Exchange 2016 server. You can find the latest version of the HCW on http://aka.ms/hybridwizard.
The HCW will detect the optimal Exchange server to configure (which should be automatically the Exchange 2016 server). You should select the Exchange 2016 server for the Receive Connector Configuration and the Send Connector Configuration. For the Organization FQDN I typically use the default FQDN (like webmail.contoso.com) to keep everything consistent. Sometimes I see admins use something like hybrid.contoso.com but that doesn’t bring much, except for more complexity.
When reaching the end of the HCW you can select to upgrade the Hybrid Configuration. The original Hybrid Configuration was created on Exchange 2010, but now it is upgrade to Exchange 2016 so I don’t see any reason to not check the checkbox.
The easiest way to check the new Hybrid Configuration is to see if free/busy works cross-premises. Open a mailbox in Exchange Online and check if you can plan a meeting with a mailbox in Exchange 2010 and check the availability of this mailbox. Baron’s mailbox is in Exchange Online, my mailbox is in Exchange 2010 (still). The free/busy request is sent to webmail.exchangefun.nl which is now the Exchange 2016 server. From there it is proxied to the Exchange 2010, and it works like a charm:
To check if cross-premises mail security you can send an email from an online mailbox to an on-premises mailbox. If you check the headers, the SCL should have a value of -1 (which means it is treated as an internal message) and the X-MS-Exchange-CrossTenant-AuthAs should have a value ‘Internal’.
At this moment there is an Account and Resource Forest environment, where the Resource Forest contains an Exchange 2010/2016 coexistence environment. All clients, including Exchange Online connect to Exchange 2016 while recipients are still on Exchange 2010.
Move Resources to Exchange 2016
At this moment, mailboxes can be migrated from Exchange 2010 to Exchange 2016. And to be honest, this is not that exciting. It is fully transparent for users. It is an online process, so the mailbox content is copied from Exchange 2010 to Exchange 2016 while the user continues to work. Only when the move is finalized, the user is presented the following message box and needs to restart Outlook.
Now back to the RPC/TCP (MAPI) part earlier in this post. Exchange 2016 does not support RPC/TCP anymore, so when a mailbox is moved from Exchange 2010 to Exchange 2016, the protocol changes as well. In this case, it changes from RPC/TCP to Mapi/Http for Mailboxes, and to Outlook Anywhere for Public Folders (still on Exchange 2010, but Exchange 2010 does not support Mapi/Http).
Public Folders (if any) must also be moved to Exchange 2016. This can only be done when all mailboxes are moved to Exchange 2016. A mailbox on Exchange 2016 can access Public Folders on Exchange 2010, but a mailbox on Exchange 2010 cannot access Public Folders on Exchange 2016. The Public Folder migration is covered in my previous blogpost Exchange 2010 Public Folder migration, which was also performed on my Exchange resource forest environment.
In an Exchange 2010/2016 coexistence environment there are two Offline Address Books:
Default Offline Address Book – used in Exchange 2010
Default Offline Address Book (Ex2013) – used in Exchange 2016 (the name was not changed when Exchange 2016 was introduced, not sure if this is a cosmetic bug but it does work correctly).
When configuring the Mailbox databases makes sure the \Default Offline Address Book (Ex2013) is set on the OfflineAddressBook property of the Mailbox database.
One pitfall that always takes more time than expected is the Receive Connector configuration, especially for SMTP relay purposes. Multiple devices (scanners, faxes), printers, applications, access on IP level, lack of documentation etc. Use the Protocol logging features on the various Receive Connectors to figure out what devices or applications are using these Connectors and configure them to use the Exchange 2016 server. But beware, this can take a lot of time ☹
Edge Transport Server
You might have noticed I have an Exchange 2010 Edge Transport server running. This is used for SMTP traffic to and from the Internet. My MX record is pointing to the Edge Transport server, but cross-premises SMTP is delivered directly on the Mailbox server.
When is the best time to upgrade the Edge Transport server to Exchange 2016? There’s no real rule of thumb for this. The Exchange 2010 Edge Transport server works fine with an Exchange 2016 Mailbox server, but the other way around also works fine. I typically upgrade the Edge Transport servers to Exchange 2016 after installing the Mailbox servers, but before moving Mailboxes. But there are much more options when doing this.
Decommissioning Exchange 2010
When all resources have been moved to Exchange 2016 you can decommission the Exchange 2010 environment. This is just a matter of:
Decommissioning Mailbox database copies.
Decommission the Database Availability Group.
Remove Mailbox databases.
Remove the Public Folder databases (if not removed earlier).
Change/Remove Send and Receive Connectors (also see previous section).
When all prerequisites for the decommissioning process have been met, the actual Exchange 2010 servers can be uninstalled. I still see admins just removing the Exchange VM’s but this is not a good idea since the Exchange configuration continue to exist in Active Directory.
Properly remove the Exchange 2010 server using Control Panel and Uninstall or change a program by deselecting all options as shown in the following screenshot.
After a few minutes the Exchange 2010 server will be fully installed (the official way).
Summary
In this blogpost I explained how to upgrade Exchange 2010 to Exchange 2016 when running in a resource forest configuration, and in a hybrid configuration. The process is not very different from an upgrade in a ‘normal’ single forest, single domain environment, not even from a hybrid perspective.
The process is simple, upgrade Active Directory, install and configure the servers, change client access to Exchange 2016 and run the Hybrid Configuration Wizard. When done you can move resources to Exchange 2016 and when finished decommission the Exchange 2010 environment.
In part VI of this series I’ll discuss how to decommission a resource forest in a hybrid configuration.
As a consultant in messaging and collaboration I have created dozens of Exchange hybrid configurations that last years, ranging from Exchange 2010 to Exchange 2019.
Today we’ve run into an issue I have not seen before, the HCW8001 – Unable to determine the Tenant Routing Domain error:
Azure AD Connect was running fine, I checked the configuration (optional features) and found nothing strange and no errors were logged.
When checking the Microsoft Portal I could see Directory Synchronization was running:
The tenant routing domain is typically something like <tenantname>.mail.onmicrosoft.com and this is set in Office 365 when installing Azure AD Connect. But when checking the Accepted Domains (in Exchange Online) this domain is not available:
There’s no way you can add this <tenantname>.mail.onmicrosoft.com domain manually (also not via the Microsoft Online Portal) so you are out of luck (I tried the Azure AD Connect server multiple times, but it didn’t work).
You can open a ticket with Microsoft Support or see if you can create a new tenant and start over again. Since this happens rarely I would be surprised you run into this again with a new tenant.
Microsoft Teams works best when your mailbox is in Exchange Online, and you have a license for SharePoint Online, and you have OneDrive for Business enabled.
When you have your mailbox in Exchange on-premises your options are limited, you have basic Teams functionality like audio/video and files, but that’s basically it. Not a trace of the calendar or the option to manage meetings in Teams. This is what ‘cloud partners’ have been telling me for a long time: “no, you must migrate your mailbox to Exchange Online” (and we can help you with that I was they were thinking…)
But, if you have Exchange 2016 CU3 or higher things get better (I’m sorry if you are still running Exchange 2010). To enable the integration of Teams with on-premises Exchange 2016 you need to configure OAuth in your on-premises environment as outlined in my previous blog, and assuming you have Exchange hybrid configured of course.
When you have OAuth configured, Teams can access the on-premises mailbox on behalf of the user that’s logged on in Teams, making it possible to retrieve the user’s calendar. After configuring OAuth and without any additional configuration in Teams the user’s on-premises calendar (here in Exchange 2019) automagically appears:
In the Teams client this is a view of your calendar, and using the new meeting option you can create new Teams meetings, invite people, set recurrence, select a channel etc. Invites are sent to other recipients using the regular Exchange process, and when accepted a response is sent (or not) back to your inbox. I never knew this was possible, but this is cool stuff.
Integrating the calendar into Teams is a nice addition and it can help users with their daily productivity task. From a compliance perspective things are a bit different. Chats for example are not stored in the user’s mailbox, this is only possible for mailboxes in Exchange Online. The process responsible for copying Teams chat data from the Azure storage (outside of Office 365) simply cannot access the folder in the user’s mailbox.
But, for on-premises calendar integration in your Teams environment this is very nice.
