Wouldn't it be nice if you could stay in Microsoft Teams even when working with your emails? Microsoft Teams is getting even more mature by providing an App for integrating Outlook into the Microsoft Teams client.
At least it seems that this is the case. or was it?
Last week a new App, still in preview, showed up in the Teams Admin Center (TAC) of some demo tenants. I filtered the list of available apps using Outlook as a search term.
When selecting the app, the details showed that the app was still in preview (v0.41).
As long as the app is enabled within Teams, you can add the app to a Teams Setup Policy and make it available for users.
Your users can then access the Outlook App using the Teams app bar.
You can simply click on Outlook in the app bar and, voilá, you have your Outlook inbox in Microsoft Teams. Due to the architecture of Microsoft Teams, you have access to your Outlook on the Web version of your inbox.
Enjoy Microsoft Teams and Microsoft Outlook. - And remember today's date.
When you want to migrate your modern public folders from Exchange 2013 or newer to modern public folders in Exchange Online, you must prepare the public folder names for migration.
Public folder names are not allowed to contain the following:
The script Fix-ModernPublicFolderNames.ps1 fixes the public folder names to prepare migration to modern public folders in Exchange Online.
# EXAMPLE 1 # Rename and trim public folders .\Fix-ModernPublicFolderNames.ps1 # EXAMPLE 2 # Rename and trim public folders, export list of renamed # folders and folders with renaming errors as text files .\Fix-ModernPublicFolderNames.ps1 -ExportFolderNames
Are you located in Germany, Austria, or Switzerland? Join the Exchange User Group DACH to collaborate with other Exchange enthusiasts. Follow us on Twitter @exusg.
I was involved in a troubleshooting request for a hybrid mail flow issue. Before I take a closer look at the issue, let's talk about the hybrid setup.
A managed service provider runs separated on-premises Exchange Organizations for various clients. Also, the service provider runs it's own Exchange Organization in a hybrid setup with Exchange Online (EXO) utilizing centralized mail flow. Let's name the managed service provider Varunagroup, using the primary domain varunagroup.de.
The on-premises IT-Infrastructure consists of the following email components:
The following diagram illustrates the setup and the expected mail flow.
Let's name one of the clients Setebos AG, using setebos-ag.com as their primary domain.
Varunagroup's IT department activated journaling in Exchange Online, using an on-premises Journaling mailbox. After a few days, an IT administrator checked the inbox folder for journaling messages and journaling reports. The journaling inbox did not contain messages of Varounagroup senders or recipients only, but messages from client sender domains, e.g., setebos-ag.com.
In reality, the mail flow from on-premises to external recipients from any of the local Exchange organizations looked like shown in this diagram.
Why does the Variangoup journaling mailbox contain messages from Setebos senders sent to external recipients?
We choose a single message for troubleshooting purposes, originating from the Setebos.com domain, sent to a non-Varunagroup recipient.
The interesting piece of information is row 6.
You see that EXO resolves the target mail exchanger via DNS. The target is another Microsoft 365 tenant as we see an xxx.mail.protection.outlook.com host.
When checking the on-premises mail gateway connection log, we found the distracting information that the gateway resolved the target mail exchanger as xxx.mail.protection.outlook.com.
As a next step, we checked the extended message tracking log using the new Exchange Admin Center. We created a new custom query with the following search criteria:
When you troubleshoot connection issues with Exchange Online, always select the extended report. You'll receive the report as a CSV file attachment. Use the Data tab in Excel to import the CSV file. Do not access the content by simply clicking the received file attachment.
The interesting information is stored in the custom_data column for row source=SMTP and event_id=RECEIVE.
S:ProxyHop1=HE1EUR01FT049.mail.protection.outlook.com(10.152.0.221); S:ProxyHop2=AM0PRxxCAxxxx.outlook.office365.com(2603:10a6:208:fa::40); S:InboundConnectorData=Name=Inbound from [EXCHANGE ORG GUID]; ConnectorType=OnPremises; TenantId=[VARUNAGROUP GUID]; S:InboundTlsDetails=TLS=SP_PROT_TLS1_2_SERVER [...]; S:CorrelationId=d9ac6a10-8de9-4308-4205-07d865e8909b; S:MimeParts=Att/Emb/MPt:0/0/1; S:MessageValue=MediumHigh; S:Replication=AM6PRxxxxMBxxxx; S:FirstForestHop=AM0PRxxxxMBxxxx.eurprd03.prod.outlook.com; S:FromEntity=HybridOnPrem; S:Oorg=varunagroup.de; S:ProxiedClientIPAddress=81.173.212.44; S:ProxiedClientHostname=mx01.varunagroup.de; S:DeliveryPriority=Normal; S:AccountForest=EURPRxxAxxx.PROD.OUTLOOK.COM
The information in line 3 shows the actual name of the configured Varunagroup inbound connector, as shown in the Exchange Online connector configuration. The message did not enter the Varunagroup EXO tenant due to a mysterious connection, it was received by the dedicated inbound connector, configured by HCW.
The key to this question is the TLS certificate used by the centralized email gateway and the TLS common name filtering in Exchange Online.
The wildcard name *.varunagroup.de resulted in a matching string comparison for the incoming TLS common names of mx01.varunagroup.de and mx02.varunagroup.de. At the same time, the inbound connector matched the Edge Transport TLS certificate smtpo365.varunagroup.de.
Nobody knew, how the inbound connector configuration got "changed" to the wildcard name or for how long that configuration resulted in outbound messages from customer domains routed via the service provider tenant.
The solution contains two configurations.
The TLS common name behavior is by design and described in this blog post as FAQ #6(b). As a customer, you identify this as a misbehaving SMTP receive connector. But as described in the blog post, this is by design.
It is required that you understand the inbound routing behavior of Exchange Online if you have complicated outbound routing requirements. The blog post provides detailed information on how Office 365 inbound routing works and what you should be aware of.
Links
Enjoy Exchange Online.
The Microsoft 365 Virtual Marathon took place on May 27-28 2020.
The recording of my session "Exchange Hybrid - What, Why, and How" is available on YouTube.
Browse all recordings of the Microsoft 365 Virtual Marathon here: https://www.youtube.com/channel/UCrtmT6Ir1MIs0ZES7sKMmqA
Enjoy!
Microsoft 365 Groups are the backbone of various Microsoft 365 workloads. As you might know, each group utilizes a SharePoint site collection, and an Exchange shared mailbox.
When you create a new Microsoft 365 group, SharePoint Online must store the associated site collection somewhere. SharePoint Online uses predefined paths to determine the storage location. These paths are called: Managed Paths.
SharePoint Online uses two different pre-configured managed paths:
With /sites as the default setting for the Microsoft 365 tenant.
Whenever you create, e.g., a new team in Microsoft Teams, the associated site collection is stored in https://TENANTNAME.sharepoint.com/sites/TEAMNAME. As a SharePoint administrator, you see the site collection paths in the list of active sites in the SharePoint Admin Center.
But what can you do, if you want to store the associated site collections in the /teams managed path?
The SharePoint Admin Center provides you with an option to change the managed path for sites, created by users.
Open the SharePoint Admin Center, navigate to Settings -> Site Creation.
Change the setting for Create team sites under to /teams/.
The description of this setting is misleading. This setting affects not only SharePoint team site creation initiated by users on the SharePoint start page or OneDrive, but site collections created by Microsoft 365 Groups as well.
You do not need to enable the checkbox to let users create sites from the SharePoint start page and OneDrive. This setting is only required, when you want to enable self-service site creation of modern SharePoint sites for users. The modern SharePoint sites are based on Microsoft 365 Groups.
After changing the path, SharePoint Online creates new associated site collections for Microsoft 365 Groups in /teams/.
Enjoy SharePoint Online.