Modern Team Sites and Site Collection Administrators

This is a brief solution to an issue I encountered while working on implementing Microsoft Teams in an Office 365 environment. When a “Team” is created, an Office 365 group, a shared OneNote notebook, a shared mailbox, and Sharepoint Modern Team Site are automatically created as well. However, even when the Team is created by a Global Office 365 Administrator, that Administrator is not the Site Collection Administrator for the generated Team Site.

This is expected behavior from Sharepoint, as the Site Owner and Site Collection Administrator roles are meant to be separate (the Site Owner being a normal employee while the Site Collection Administrator typically being a member of the IT department). The way to resolve this is:

  1. Install the Sharepoint Online PowerShell module
  2. Open the Sharepoint Management Shell
  3. Connect to your O365 Tenant
  4. Run this command for each site collection:

Set-SPOSite -Identity -Owner -NoWait

EDIT: I noticed that many of the Teams that I created as the Office 365 Global Administrator did not have this issue. I only encountered this sporadically.

Offline Files and DFS

A few months ago, my boss and I were stuck on a user’s issue: they continually reported drops of a network drive while on a VPN connection. The user would navigate the drive’s folder structure, going many subfolders deep, but would then get disconnected randomly: left only with their Offline Files cache of their Desktop and Documents. They would then have to uncheck the “Work Offline” button in File Explorer in order to get access to network files, and start the digging process over. Naturally, this was very frustrating for the user, so we began analyzing what factors could’ve been at play.

Many variables came to mind: the VPN settings themselves, the Offline Files cache, the WiFi chipset in the user’s laptop, their home WiFi connection, etc. We tested the VPN connection to the drive using different networks and hotspots, purchased a USB WiFi adapter and disabled the existing WiFi chipset, along with verifying the VPN configuration on the firewall, but the solution was actually related to the drive itself.

This network drive (we’ll call it the Z: Drive) was a DFS share used by the entire company, and this was the first issue we had heard regarding connectivity issues over the VPN. The Z: Drive was also responsible for storing users’ Desktop and Documents for folder redirection. After considering that the issue could be related to the DFS share, we set up a test where we had two SMB shares (one on a Server 2012 R2 machine and one on a Server 2016 machine, as Server 2016 was the host OS for the DFS target) mapped as network drives alongside the Z: Drive. We then connected to the VPN and waited for a drop to occur. The Z: Drive would drop and be inaccessible, but at the same time, the other two network drives could be accessed without issue.

Thus, the resolution: disabling slow-link mode via Group Policy. Slow-link is part of the Offline Files feature in Windows, where the client computer, based on bandwidth and/or latency values, transitions to using the Offline Files cache of network files rather than accessing them directly. This transition would disconnect users entirely from the folders in the Z: Drive they needed, as the Offline Files cache only contained their Desktop and Documents.

After this solution was implemented, we received no more complaints from the user, and in fact, other laptop users came out of the woodwork to state that they were having a much more stable experience with the Z: Drive. The lesson learned here was that we spent too much time focusing in on common problem elements (the VPN, the WiFi connection) instead of considering all the aspects of the problem.

TL;DR: The solution was to disable slow-link mode via Group Policy.
Our GPO was configured as such:

Computer Configuration -> Administrative Templates ->

Network -> Offline Files -> Configure slow-link mode = Disabled