Feb 23 2017 10:06 AM
We recently completed the worldwide rollout for Office 365 Groups getting full-powered SharePoint team sites at the end of January 2017. Our next step is to now bring the ability to create SharePoint team sites connected to Office 365 Groups from SharePoint home beyond First Release. This next phase of rollout will begin today, and is expected to reach all customers worldwide over the next month. We also wanted to share some of the additional capabilities we’ve added to group-connected team sites since we first began roll out to First Release.
No matter where you create an Office 365 Group from – whether SharePoint, Outlook, Microsoft Teams, Yammer, or elsewhere – you consistently get the full collaborative power of a connected SharePoint Online team site among the other services groups provides (shared inbox, shared calendar, Planner plan, team notebook, and more).
This move beyond First Release includes the capabilities described in our November blog post:
The site permissions panel listed above has been enhanced to include options for adding members to the site’s Office 365 Group or simply sharing only the team site without providing access to other group resources.
The panel is intended to provide simple permissions management, but also includes a link to ‘Advanced permission settings’ for site owners that have a need to do things like add custom SharePoint permissions & mappings.
Note this panel also allows you to add users or groups to the ‘Site Visitors’ permissions group, so it is easy to provide read-only access to the site. All you need to do is add a new person or group via the ‘Invite people’ button, and then change their permission level to ‘Read’. The user or group’s permission level determines which permission group they appear under – those with ‘Read’ permission will appear in the ‘Site Visitors’ category.
Since new team sites are connected to Office 365 Groups, managing them involves possible interactions with Office 365 Group settings in addition to those provided by SharePoint. Examples include settings that apply to groups such as whether group creation is allowed in the tenant, which users are permitted to create groups, usage guidelines URL or group classification labels. Once the group-connected site is created, management of the site is likewise split between Azure Active Directory (AAD) PowerShell cmdlets and the SharePoint Online Management Shell. Anything dealing with creation, deletion, un-delete (restore) or membership happens through AAD. SharePoint-specific management, such as storage quota and link sharing policies, take place using the SharePoint management tools.
For governing modern site creation, this support page details the administrative controls, but is useful to summarize the relationship between a group’s policy settings and how the SharePoint ‘Create site’ experience behaves. By default, if group creation is enabled in the tenant, the ‘Create site’ command will appear on SharePoint home, and if a user is permitted to create groups they will get the site creation experience. If the user is *not* permitted to create groups, they will get the classic self service provisioning experience that results in the creation of a subsite. The table below describes how the combination of group and site creation settings work together:
* The current user is considered to have group creation permissions if the AAD property EnableGroupCreation is true, or it is false but the user is a member of the security group assigned to the GroupCreationAllowedId AAD property.
** Site creation is enabled via SharePoint Admin Center under Site creation settings:
In addition to managing site creation, we are also enabling the SharePoint Online PowerShell cmdlets to administer modern, group-connected site collections. This means that modern team site collections can now be enumerated with the Get-SPOSite cmdlet with the following example:
Get-SPOSite -Template GROUP#0 -IncludePersonalSite:$false
Most parameters for these site collections can also be set using the Set-SPOSite cmdlet, with the exception of those that would result in breaking connection with their corresponding Office 365 Group (e.g. you cannot set the Owner property using this cmdlet – you would need to set the Group’s owners via AAD). Please refer to the respective documentation for each of the above cmdlets for additional details. For more information on using PowerShell to manage Office 365 Groups, this article may be helpful as well.
In addition to the above, this phase of the rollout includes a couple of previously unannounced capabilities.
The first is a group membership management experience that lives in SharePoint itself. Now, when you click on the member count of the group in the site header, you will be presented with a new group membership panel that allows you to add members and change their roles between owners and members, or remove them outright. Users will no longer need to jump to Outlook to manage the group’s membership.
The second is Content Type Hub syndication – modern sites can now consume content types that have been published from a central content type hub. We heard feedback that this is an important feature to enable, and we are including it in this rollout.
As noted above, this rollout will take place over the course of a few weeks. We are very excited for you to take advantage of modern, connected team sites and look forward to any feedback or questions you may have. As always, please ask in a reply to this thread.
Thanks,
Tejas
May 05 2017 01:26 PM
Hi @Deleted - for more information on the admin site creation settings check out this help article:
The purpose of the first link - modern or classic is to support those who want to restrict O365 group creation to a subset of users (so those not in that group would get the classic option to create a team site subweb) - but unless this restriction is set (see article above for details on setting these AAD properties) the form will default to creating a modern, group-connected team site collection.
May 05 2017 01:28 PM
May 08 2017 07:33 AM
My Site Permissions Menu does not yet look like this..
I only have the option to Invite People
and Advanced Permissions Settings
Is this something thats still in rollout? or do i have to change something as an adminsitrator?
May 08 2017 06:11 PM
Hi,
Do you see this from an old site or a newly created team site? I think only new created team site has the new look, the old sites which you created in the past were still the old look.
May 08 2017 10:11 PM
@Jan Tibell wrote:My Site Permissions Menu does not yet look like this..
I only have the option to Invite People
and Advanced Permissions Settings
Is this something thats still in rollout? or do i have to change something as an adminsitrator?
We don't have it either. All "old" group sites.
May 09 2017 02:25 AM
All sites im talking about are Group-Connected Sharepoint Team Sites (created by creating a Office 365 Group) . Does not matter if they are brand new or if the group is a year old.
Still no way for me to manage the different permission levels in the Site Permissions panel
May 09 2017 04:14 AM
May 09 2017 08:19 AM
The updated permissions panel should be available to all customers for group connected site collections. At present, the panel will appear for Site Owners. It seems like you *are* seeing the panel but it is only showing you the Invite people button and the link to advanced permissions? Or are you not seeing the panel at all?
May 09 2017 11:22 AM
May 09 2017 11:29 AM
If you go to Advanced permission settings (i.e. user.aspx), do you see the 3 default SP Groups (i.e. Foo Group Owners, Foo Group Members, Foo Group Visitors)? If so, are there any entries under the Members SP Group?
May 09 2017 12:39 PM
May 09 2017 01:07 PM
That is definitely odd (and unexpected) behavior. Would you mind opening up a support ticket with us, so that we can investigate further?
May 10 2017 05:35 AM
@Tejas Mehta wrote:That is definitely odd (and unexpected) behavior. Would you mind opening up a support ticket with us, so that we can investigate further?
Could you please specifcy what exactly is unexpected so I could check out other groups within our ORG?
Should single username be listed under owners?
Should the group itself not be listed under members?
May 10 2017 06:07 AM
I can confirm that, in all Groups:
Always assumed this is the default and correct behavior...
May 10 2017 09:42 AM
The expected behavior is this:
1) All groups should have 3 default SP Groups: Owners, Members, Visitors
2) Within the Members SP group, the group's member claim should appear
3) Within the Owners SP group, you will see it empty by default as the group's owner claim is hidden in the UX
4) For public groups, you will see 'Everyone except external users' claim in the Members SP group
5) If the default SP groups are present, the three permission buckets (Owners, Members, Visitors) should be visible in the permissions panel --> this is what I'm referring to as odd behavior as it seems the above items appear to be right from your description.
May 10 2017 11:55 AM
Wow! Thank you very much @Tejas Mehta!
These questions have hovered in the community for months: finally we have a clear and authoritative response.
I am going immediately to bookmark this thread!
May 10 2017 10:12 PM
May 10 2017 10:28 PM
Ivan, would you mind opening a support ticket? We'd love to help investigate.
Thanks,
May 11 2017 06:29 AM
@Tejas Mehta is this expected behavior documented in the support articles anywhere? If not, can we get it there? :)
May 22 2017 01:37 PM