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.
You are interested in OneDrive and OneDrive for Business? You want to know how you can integrate the OneDrive technology into your IT infrastructure securely?
Here is the list of OneDrive related sessions at Microsoft Ignite 2017
See you at Microsoft Ignite!
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.
This year's Microsoft Ignite Conference takes place on November 4 - 8 at the Orange County Convention Center (OCCC), Orlando, Florida.
Choose from over 1,000 Breakout and Theater Sessions to learn about new technologies and methods, or talk directly to Microsoft professionals and MVPs about your technical challenges. Select the sessions and hands-on experiences that are most interesting for you based on the Microsoft Learning Paths to suit your job role.
You will find me directly in the Modern Workplace & Modern Life in the exhibition area. Just stop by to learn more about the possibilities of modern and secure collaboration using Microsoft Teams, Mobile Productivity, and more.
Feel free to contact me via email to arrange an appointment at Ignite 2019: thomas@mcsmemail.de.
See you in Orlando!
On May 11th, the SharePoint Saturday Cologne took place at the new Microsoft Office in Cologne.
My session covered the migration of legacy public folders from Exchange Server 2010 to modern public folders hosted on-premises or Exchange Online. Additionally, I've talked about the pros and cons of a migration to Office 365 Groups and Microsoft Teams.
The slide deck is available on SlideShare.
Enjoy Exchange Server and do not forget about the end of support for Exchange Server 2010 on January 14th, 2010.
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.
SharePoint Conference North America is just 4 weeks away! Now is a great time to register and make your plans to BE THERE in Las Vegas.
See the schedule, available now, with over 160 sessions to immerse yourself each day on what you need to know about SharePoint, OneDrive, Yammer, Microsoft Teams, and Office 365. Check out The Road to @SPConf, which reveals the inside scoop about SharePoint Conference North America and what you can expect with the return of the SharePoint community.
Register today | Don't miss the conference