Browse Tag

Security

Vlad & Drew Microsoft Cloud Webinar Series

There is a constant release of new Microsoft cloud technologies and it is hard to keep up to date. There can be features that are released and the not widely seen or there could be questions about that feature that aren’t answered with the initial release. We want to try to close that gap of knowledge.

Vlad Catrinescu and myself, Drew Madelung, have begun putting together a webinar series where we will be targeting Microsoft modern workplace technologies and doing deep dives into specific feature releases. We want to bring experts from Microsoft and the community to share the details of what is being released and break down into the technology to really try to help everyone understand what the feature is meant to do, can do, and answer any outstanding questions.

Please join us and spread the word for these webinars. If you missed one, make sure you watch the recording! And if you have any suggestions for topics to deep dive into please let Vlad or myself know.

Upcoming Webinars

Previous Webinars

August 25th – Modern records management in a new world of remote work with Microsoft 365

In this webinar we were joined by special guests Roberto Yglesias and Tina Ying covering the latest news in Microsoft 365 records management. Records management in M365 has many new features and capabilities that we highlighted in this webinar. We also discussed real-world conversations on use cases of moving to modern records management in M365 and the challenges, opportunities, and overall guidance for this process.

August 3rd – Introducing Microsoft Lists – Your smart information tracking app in Microsoft 365

In this webinar, we jumped into the new functionality and features of the brand new solution called Microsoft Lists. We discussed what Lists can be used for, how to work with them, and details around the timing and availability of Lists along with demos of Lists themselves! With our special guest Mark Kashman who joined us this was a great overall webinar with a ton of questions.

July 7th – Enabling Sharing & Collaboration in OneDrive & SharePoint

In this webinar, we dived into sharing and discussing how it works, how it can be managed, and what’s new and upcoming in the world of sharing and collaboration in OneDrive and SharePoint. We were joined by Stephen Rice from Microsoft as we break down the details and background of sharing.

June 16 – Evolution of Office 365 Groups to Microsoft 365 Groups

In this webinar, we’ll were joined by Mike McLean from the Microsoft 365 Groups product team to discuss the evolution of Office 365 Groups to Microsoft 365 Groups. We reviewed the Office 365 Groups journey, and provided a behind-the-scenes look at the vision and strategy around the platform. Mike also shared details on improvements recently shipped that enhance how groups are managed across the Microsoft 365 suite and through Microsoft Graph.

May 20 – Review of the new experiences of managed metadata services (taxonomy and content types)

We were joined by product managers Sean Squires and Anupam Francis covering updates to the managed metadata service in Microsoft 365! In this webinar we talked about the updates coming to the managed metadata service. This includes experience updates to the term store, a new admin content type gallery, and improvements to managed metadata columns in lists and libraries. We will also talked about the new REST and Graph APIs supporting taxonomy updates.

May 26 – Enabling Sensitivity Labels for SharePoint Sites, Teams, Office 365 Groups and Office files

We were joined by Senior Program Manager Sanjoyan Mustafi for a free webinar covering Sensitivity Labels across Office 365! In this webinar we talked about the upcoming features around enabling more Office 365 workloads with sensitivity labels. This included new abilities to classify the containers of Office 365 Groups, Microsoft Teams, and SharePoint sites and the ability to enable sensitivity labels for Office files in SharePoint and OneDrive.

March 10th – Deep Dive into SharePoint Online Multilingual

We had the pleasure to host a webinar with Senior Program Manager Divyachapan (DC) Padur, and Senior Software Engineer Matt Mooty from Microsoft for a deep in multilingual in SPO. Recording below and a great collection of questions and answers came from it that we posted.

April 9th – Deep Dive into OneDrive Known Folder move

We were joined by Principal Program Manager Gaia Carini from the OneDrive team at Microsoft to talk all about Known Folder move. Recording is below.

Office 365 Groups Naming Policy

group1

Introduction

When Office 365 Groups were first released there was not an ability to control the names of Groups at all. One of the primary reasons for this was due to the cross workload functionality that make up Office 365 Groups. As a reminder, an Office 365 Group is the single Azure AD identity service that provides specific membership to Office 365 solutions like SharePoint, Exchange, Planner, Teams, etc. Within each of these workloads you have the ability to create and manage an Office 365 Group. If you make a change within one of workloads, for example SharePoint, there is communication between the workload and Azure AD with notifications on things like creation, changes, and deletions. 

With a separated system and Azure AD as the source, any policies need to be applied at the Azure AD level. As an example, an Exchange naming policy can be used (and at one point was the only option) for Office 365 Groups. If you set a naming policy within Exchange that would only work if you tried creating a group within Exchange. If I was on SharePoint Home and tried to create an Office 365 Group that naming policy would not trigger as I technically not working in Exchange. Exchange would learn about the Group after it is synced back to Azure AD but that would be too late. 

To resolve this issue Microsoft has released Office 365 Group naming policy capabilities at the Azure AD level. A naming policy is very important for proper control and a clean Global Address List (GAL). Since this is in Azure AD now the naming policy is applied to Groups that are created across workloads. 

Details

As I am writing this post in Dec 2017 this is currently still in Private Preview. 

Both of these currently can only be configured with PowerShell. The prerequisites for configuring these can be found in this post: Managing Office 365 Groups using Azure AD PowerShell V2.

The AzureADPreview PowerShell module version 2.0.0.137 is required.

Office 365 Group naming policies can be built using 2 different features and 1 is automatically maintained:

  • Custom blocked words
    • You can set specific blocked words that can be used within Group names. 
  • Prefix-Suffix naming policy
    • Using fixed strings or user attributes, you can add an automated prefix or suffix to a Group name. 
  • Microsoft Standard blocked words list
    • A set of words Microsoft manages that are not allowed. This includes your primary swear words. I tested quite a few good ones and they were all blocked automatically.

These administrators bypass or are exempt from the naming polices you configure but NOT the MS standard blocked words list:

  • Global Administrator
  • Partner Tier 1 Support
  • Partner Tier 2 Support
  • User Account Administrator
  • Directory Writers

Microsoft detailed information for the naming policy can be found here.


Custom blocked words

This is a comma separated list of words that you can configure. These words are blocked in Group names and aliases. Some examples of when you would want to configure blocked words:

  • Your department or business function names because you want to ensure you don’t have duplicate places for content
  • Regulatory words that you may have specific legal requirements around that you need to have more control over
  • Names of roles that you don’t want people to try to impersonate
  • Client, Vendor, or Competitor names

There are some things to know about these blocked words.

  • The checks are done AFTER appending the prefix/suffix to the Group name
    • If things like underscores (_) or dashes (-) are used in prefix/suffix they could stop your blocked word from working if there are no spaces
  • No sub-string searches are done
    • If “Drew” is the blocked word, “Andrew” would still work
  • Not case-sensitive
  • No character restrictions
  • No limit on the amount of words

Steps to set the Custom Blocked words

This is assuming you already have a directory settings template created, details in prior post, and connection information from the first section.

1 – Connect to Azure AD via PowerShell.

Connect-AzureAD

2 – Use comma delimited values for the blocked words.

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["CustomBlockedWordsList"] = "HR,Contoso,Payroll,CEO,CFO,CIO"
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

3 – Review your updated settings; you can now see the default values for the directory settings object.

Get-AzureADDirectorySetting | ForEach Values


Prefix-Suffix naming policy

These can either be fixed strings or actually attributes from the user themselves. These 2 types of capabilities are stored within 1 overall string that is concatenated. Because of this, you must always have [GroupName] included in your setting. That is how you are able to have a prefix & a suffix. 

Some examples of using strings:

  • GRP [GroupName]
    • This puts the fixed string of “GRP ” before all of your Group names
  • #[GroupName] Group
    • This will put the # symbol at the front of the Group name for better sorting in the GAL and then ” Group” as a suffix for better clarity
    • Special characters are removed from the Alias
  • OGRP – [GroupName]
    • Dashes can be used for separation as spaces are removed automatically in the Group Alias (like the rest of the special characters). That means “OGRP – Drew” as a group name becomes “OGRP-Drew@domain.com” as the alias instead of “OGRPDrew@domain.com”.

The next type of thing you can add are Azure AD user attributes. The following attributes are supported: [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion], [Title], [CountryCode]

Some examples of using attributes:

  • [Department] – [GroupName]
    • This will pull the users department stored in Azure AD before the Group name
  • [CountryCode] – GRP – [GroupName]
    • This will first put the Country Code stored in Azure AD followed by a fixed string and then the Group name

There are some things to know about using attributes.

  • The total prefix/suffix + string length is restricted to 53 characters
  • Empty attributes for users will be filled in with blank values. It is best to ensure your Azure AD information is fully established before using these attributes.
  • Extension attributes and custom attributes are not supported
    • If you put it in an unsupported attribute it just comes across as text

Steps to set the Prefix – Suffix naming policy

This is assuming you already have a directory settings template created, details in prior post.

1 – Use comma delimited values for the blocked words.

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["PrefixSuffixNamingRequirement"] = "GRP - [Department] - [GroupName]"
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

2 – Review your updated settings; you can now see the default values for the directory settings object.

Get-AzureADDirectorySetting | ForEach Values


Microsoft standard blocked words

There are a lot of unprofessional words naturally in the English language that most likely should never be part of an Office 365 Group name. This includes a primary set of things like swear words and other inappropriate words that your imagination may be able to come up with. This is a single setting to turn on the blocked words or off. 

Steps to set the Microsoft blocked words

This is assuming you already have a directory settings template created, details in prior post, and connection information from the first section.

1 – Use comma delimited values for the blocked words.

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["EnableMSStandardBlockedWords"] = $true
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

2 – Review your updated settings; you can now see the default values for the directory settings object.

Get-AzureADDirectorySetting | ForEach Values


And when you put it all together!

You get a blocked word of CEO and a naming policy pulling in a prefix of “GRP – ” with an Azure AD department of “NFL” and a suffix of ” – CEO”. You will also see the alias removing the spaces.


Where does the naming policy actually work?

As there are a lot of workloads across Office 365 that utilize Groups there are a lot of places that these policies need to work. Currently it is not supported in every workload. Microsoft has the detailed information for what is supported in their support article here

Here is the current breakdown in Dec 2017.

Where it works:

  • Outlook on the Web
  • Outlook Client – Doesn’t preview
  • Outlook Mobile – Doesn’t preview
  • Teams
  • SharePoint
  • Stream
  • Groups mobile app
  • Planner
  • Dynamics 365
  • Exchange PowerShell
  • Azure AD PowerShell
  • O365 Admin Center

Where it doesn’t:

  • Power BI workspace
  • Yammer
  • StaffHub
  • Azure AD Portal

Licensing

Any Office 365 subscription that has Exchange Online and SharePoint Online will support groups. That includes the Business Essentials and Business Premium plans, and the Enterprise E1, E3 and E5 plans.

There is a large collection of features that require specific types of Azure AD licenses. The Office 365 Groups naming policy requires Azure AD Premium P1 licenses for any users who are part of Office 365 Groups.

The full collection of licensing information is listed from Microsoft here.

Managing Office 365 Groups Using Azure AD Powershell V2

group1

Introduction

Azure AD PowerShell is an incredibly useful tool for management.  V2 was released as GA (general availability) in Dec 2016.  
This means that you could begin to utilize the new cmdlets in your production environment.  There is currently not dual functionality from the V1 MSOL cmdlets so both will still need to be used as V2 continues to develop.  There is also a preview set of cmdlets that you can download and use that has some extended features beyond just V2.  The V1 module will begin to be deprecated as V2 continues to advance.  I would recommend working with V2 when possible and only going back to V1 as needed.  

I won’t be going through all of the differences between these versions but will be shedding some light on the differences for Office 365 Group management from V1 to now.  This is a follow up to my original post: Managing Office 365 Group Creation via Azure AD

Links:

Licensing

Microsoft has made changes to the licensing for Office 365 Groups capabilities and the required Azure AD licensing to be able to use them. This is highlighted in the ‘Feature availability and licensing section’ of the following article: Learn about Office 365 Groups 

Quick V1 vs. V2 Examples

The big difference from V1 to V2 is that the majority of cmdlets that used *-MSOL* cmdlets are now *-AzureAD*.  The full list of cmdlets can be found through the links above. 

To connect using V1 you would use:

Connect-MsolService

V2 you now use:

Connect-AzureAD

To get a user in V1 you would use:

Get-MSOLUser

V2 you now use:

Get-AzureADUser

Managing Groups using Azure AD PowerShell V2

To perform Group management you will need to use the V2 Preview cmdlets (download above) until they are rolled into V2.  The same Office 365 groups settings in Azure AD PowerShell available in V1 are currently not available in V2.  Hopefully when that happens they won’t change much from when I am writing this. 

The primary cmdlets utilized in V1:

Get-MsolAllSettings
Get-MsolAllSettingTemplate
New-MsolSettings
Set-MsolSettings
Remove-MsolSettings

Their comparison in V2:

Get-AzureADDirectorySetting
Get-AzureADDirectorySettingTemplate
New-AzureADDirectorySetting
Set-AzureADDirectorySetting
Remove-AzureADDirectorySetting

The way that these are updated are also different.  That means you can not simply replace “MsolAllSettings” with “AzureADDirectorySetting” in your scripts.  There are different parameters that you need to pass and functions not available.  


You can currently see these values but not all can bet set. Please ensure you review Microsoft’s latest supported parameters as these are updated frequently. 

Name : ClassificationDescriptions
Description : A comma-delimited list of structured strings describing the classification values in the ClassificationList. The structure of the string is: Value: Description

Name : DefaultClassification
Description : The classification value to be used by default for Unified Group creation.

Name : PrefixSuffixNamingRequirement
Description : A structured string describing how a Unified Group displayName and mailNickname should be structured. Please refer to docs to discover how to structure a valid requirement.

Name : AllowGuestsToBeGroupOwner
Description : Flag indicating if guests are allowed to be owner in any Unified Group.

Name : AllowGuestsToAccessGroups
Description : Flag indicating if guests are allowed to access any Unified Group resources.

Name : GuestUsageGuidelinesUrl
Description : A link to the Group Usage Guidelines for guests.

Name : GroupCreationAllowedGroupId
Description : Guid of the security group that is always allowed to create Unified Groups.

Name : AllowToAddGuests
Description : Flag indicating if guests are allowed in any Unified Group.

Name : UsageGuidelinesUrl
Description : A link to the Group Usage Guidelines.

Name : ClassificationList
Description : A comma-delimited list of valid classification values that can be applied to Unified Groups.

Name : EnableGroupCreation
Description : Flag indicating if group creation feature is on.


Steps to Create new Directory Settings for Groups template

There are multiple templates that are part of your Azure AD tenant.  This template can contain a settings object which has a collection of values.  Within these values are where we can set the parameters above.  This needs to be done before you can set any values.  If you already have this you can move to the section below.  

1 – Connect to Azure AD via PowerShell

Connect-AzureAD

2 – Review if you have any settings currently configured in your tenant

Get-AzureADDirectorySetting | ForEach Values

3a – If you have directory settings returned it will look like this (properties subject to change over time)

 

3b – If you have NO settings returned it will look like this and new directory settings will need to be created

Run this command to create the new directory settings

$template = Get-AzureADDirectorySettingTemplate | where-object {$_.displayname -eq “Group.Unified”}
$setting = $template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $setting

4 – Review your updated settings; you can now see the default values for the directory settings object created for the Groups template

Get-AzureADDirectorySetting | ForEach Values


Steps to set Group Settings

1 – Connect to Azure AD via PowerShell

Connect-AzureAD

2 – Review if you have any settings currently configured in your tenant

Get-AzureADDirectorySetting | ForEach Values

3a – If you have directory settings returned it will look like this (properties subject to change over time)

3b – If you have NO settings returned it will look like this and new directory settings will need to be created and follow the steps above

4 – Examples of Group settings

All settings below will use the Get-AzureADDirectorySetting cmdlet and store that in a variable and then use the Set-AzureADDirectorySetting cmdlet with the updated settings.  The full command to run a setting update is:

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["SETTING NAME"] = ""
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

I will walk through some of the common scenarios and how to configure the settings parameters.  If you run any of the

Restricting Group Creation for all except users in a specific group

Enter the group you want to use in the “ENTER..” section.

$group = Get-AzureADGroup -All $True | Where-Object {$_.DisplayName -eq “ENTER GROUP DISPLAY NAME HERE”} 
$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["EnableGroupCreation"] = "false" 
$settings["GroupCreationAllowedGroupId"] = $group.ObjectId
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

Setting Group classification

Use comma delimited values for the classifications.

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["ClassificationList"] = "Internal,External,Confidential"
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

Setting Guidelines URL

Enter a valid URL to a page or document that holds your guidelines.

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["UsageGuidelinesUrl"] = "https://domain.sharepoint.com/sites/intranet/Pages/Groups-Usage-Guidelines.aspx"
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

Restrict all access for guest users to Groups including ones that were already granted access

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["AllowGuestsToAccessGroups"] = "False"
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

Restrict the ability to add any new guest users but not restrict existing

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["AllowToAddGuests"] = "False"
$settings["AllowGuestsToAccessGroups"] = "True"
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

Setting all Group settings

With some examples.

$group = Get-AzureADGroup -All $True | Where-Object {$_.DisplayName -eq “ENTER GROUP DISPLAY NAME HERE WHO WILL HAVE ACCESS TO CREATE GROUPS”} 
$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
$settings["ClassificationDescriptions"] = "Internal:This is internal only,External:External users can access,Confidential:Highly secure" 
$settings["DefaultClassification"] = "Confidential"
$settings["PrefixSuffixNamingRequirement"] = "ogrp-" 
$settings["AllowGuestsToBeGroupOwner"] = "false"
$settings["AllowGuestsToAccessGroups"] = "true" 
$settings["GuestUsageGuidelinesUrl"] = "https://domain.sharepoint.com/sites/intranet/Pages/Groups-Guest-Usage-Guidelines.aspx"
$settings["GroupCreationAllowedGroupId"] = $group.ObjectId 
$settings["AllowToAddGuests"] = "true"
$settings["UsageGuidelinesUrl"] = "https://domain.sharepoint.com/sites/intranet/Pages/Groups-Usage-Guidelines.aspx" 
$settings["ClassificationList"] = "Internal,External,Confidential"
$settings["EnableGroupCreation"] = "true"
Set-AzureADDirectorySetting -Id $settings.Id -DirectorySetting $settings

5 – Review your updated settings

Get-AzureADDirectorySetting | ForEach Values


Steps to remove Group Settings

1 – Connect to Azure AD via PowerShell

Connect-AzureAD

2 – Remove your directory settings, follow the steps above to create new

$settings = Get-AzureADDirectorySetting | where-object {$_.displayname -eq “Group.Unified”}
Remove-AzureADDirectorySetting -Id$settings.Id

More Scripts

All of these Office 365 Group scripts for V2 can be found on Github. Large thanks to Tony Redmond, Santhosh Balakrishnan, and Juan Carlos Martin for their work they have already done and multiple supporting scripts.  The scripts from this post are under the file: DrewO365GroupsScripts – Azure AD Cmdlets

Please feel free to contribute!

https://github.com/dmadelung/O365GroupsScripts

Locking a SharePoint Online Site Collection

Within SharePoint Online you have the ability to completely lock down a site collection so no one can get access to it.  This is set via PowerShell and the SharePoint Online Management Shell.  Here are instructions on how to get started using connecting to SharePoint Online via PowerShell.  This lock can also be set on a user’s OneDrive for Business site collection.

Along with the ability to lock a site collection you can also set a redirect URL for the tenant for any locked sites that are accessed.  That means that when a user tries to access that locked site they will be redirected to the URL that you provided at the tenant level.  This could be helpful to provide instructions or further info for anyone letting them know that the site they were trying to access has been locked.  If no redirect URL is set they will receive a 403 error. 

NOTE: As of writing this post you are not able to set a lock state of a site provisioned with an Office 365 Group even though the PS cmdlets say it should be possible.  I will demo the actions later in this post but I have contacted Microsoft on this error and they state it is currently as designed and the error received is incorrect. 

The PowerShell cmdlets that are used to set this up are:


Steps to lock or unlock a site collection

1 – Connect to SharePoint Online

Connect-SPOService

2 – Locking – Set the -LockState of the site collection to “NoAccess” while replacing the domain and sitecollection info to lock the site

  • This can also be a OneDrive for Business site collection (i.e. https://domain-my.sharepoint.com/personal/usersite)
Set-SPOSite -Identity https://domain.sharepoint.com/sites/sitecollection -LockState "NoAccess"

 

2(a) – Unlocking – Set the -LockState of the site collection to “Unlock” while replacing the domain and sitecollection info to unlock the site

Set-SPOSite -Identity https://domain.sharepoint.com/sites/sitecollection -LockState "Unlock"

3 – Navigate to the URL to confirm and use PowerShell to confirm locked state

Get-SPOSite -Identity https://domain.sharepoint.com/sites/sitecollection | select Title,URL,LockState


Steps to set a tenant redirect URL

1 – Connect to SharePoint Online

Connect-SPOService

2 – Set the NoAccessRedirectURL of the tenant to a URL while replacing the domain and sitecollection info

Set-SPOTenant -NoAccessRedirectUrl "https://domain.sharepoint.com/Pages/Locked-Site.aspx"

3 – Navigate to the URL to confirm the redirect.  This may take a few minutes

To remove the NoAccessRedirectURL you can pass in an empty string

Set-SPOTenant -NoAccessRedirectUrl ""

Trying to lock an Office 365 Group site

Here is the error you receive when trying to lock a group site:

 

Set-SPOSite : https://domain.sharepoint.com/sites/drewtesto365group is a OneDrive for Business site collection. The only valid parameters for this type of site collection are ‘-Identity’, ‘-StorageQuota’, ‘-StorageWarningLevel’, ‘-LockState’ and ‘-SharingCapability’.
At line:1 char:1
+ Set-SPOSite -Identity https://domain.sharepoint.com/sites/dre …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-SPOSite], ServerException
+ FullyQualifiedErrorId : Microsoft.SharePoint.Client.ServerException,Microsoft.Online.SharePoint.PowerShell.SetSite

The error declares it as a OneDrive for Business site collection and says that -LockState is a valid parameter yet still doesn’t work.  I opened a support ticket with Microsoft and this was their resolution:

“It is by design Issue. We can lock a site collection however we cannot lock a unified group site.”

If this is something that you need I would recommend adding to to Uservoice.  If you need to “lock” an Office 365 Group site the best way as it exists when I am writing this is to remove permissions within the group.


Getting status of all locked site collections in a tenant

Get-SPOSite | Where-Object {$_.LockState -eq "NoAccess"}

At this point Get-SPOSite will not return any OneDrive for Business or Group sites.  There is new parameter called “-IncludePersonalSite” which at some point should return OneDrive sites via this cmdlet.  If you run this now you get the error:

WARNING: SharePoint Online does not support these new features yet.

Get-SPOSite -IncludePersonalSite $true | Where-Object {$_.LockState -eq "NoAccess"}

 

Configuring Office 365 Group Classification

group1

Recently Microsoft released the ability to create classifications for Office 365 groups that allow end users set.  For example, you can now set classifications such as: internal, confidential, external, secret, top secret, low, medium, high, etc..  Group classifications are new and I am not sure the full story of how these will be utilized moving forward.  There are enhancements coming around classification within the security and compliance center that I hope this will be able to tie into at at some point.

Here is some info on the current setup of group classification (as of 10/31/2016):

  • They don’t actually technically do anything yet…
  • They are not on by default
  • The choices can only be set via PowerShell
  • They currently don’t show anywhere else other than “edit group” via Outlook
  • You can only have 1 set of classifications for a tenant
  • If you change a classification value, it does NOT go back and update existing groups that were classified but the existing groups that were classified do not lose the classification
  • It takes some time for classification changes to be visible in the GUI
  • Don’t put spaces between the comma delimited values (i.e. “internal,external” NOT “internal, external”)
  • You can use spaces within comma eliminated values (i.e. “secret,top secret”)
  • I tested some special characters such as ? and ! and they worked
  • I am not aware of a classification limit, i did a test with 15 without an issue

Here is the description of the new property:

2016-10-30-16_07_07-start

Prerequisites:

NOTE: Version 1.1.143.0 of the Azure AD PowerShell module includes many changes to renew the existing MSOL PowerShell cmdets. Over time the existing MSOL cmdlets will be replaced. The new module is called “AzureAD.” So where e.g. an existing cmdlet was named “New-MSOLUser”, which adds a new user to the directory, the new cmdlet’s name is “New-AzureADUser.

My scripts below are using Version 1.1.143.0.  Azure AD PowerShell Module Version Release History


Steps to set values for Group Classification

1 – Connect to Azure AD via PowerShell

Connect-MsolService

2 – Review if you have any MsolSettings currently configured in your tenant

Get-MsolAllSettings | ForEach Values

3a – If you have settings returned it will look like this (properties subject to change over time)

group2

Run this command to set ClassificationList to a comma separated list of values that you want.  (In my example I included “Internal,External,Confidential”)

$settings = Get-MsolAllSettings | where-object {$_.displayname -eq “Group.Unified”}
$singlesettings = Get-MsolSettings -SettingId $settings.ObjectId
$value = $singlesettings.GetSettingsValue()
$value[“ClassificationList”] = “Internal,External,Confidential”
Set-MsolSettings -SettingId $settings.ObjectId -SettingsValue $value

3b – If you have NO settings returned it will look like this a new template will need to be created

group3

Run this command to set ClassificationList to a comma separated list of values that you want.  (In my example I included “Internal,External,Confidential”)

$template = Get-MsolAllSettingTemplate | where-object {$_.displayname -eq “Group.Unified”}
$setting = $template.CreateSettingsObject()
$setting[“ClassificationList”] = "Internal,External,Confidential"
New-MsolSettings –SettingsObject $setting

4 – Review your updated settings; now Classification’s are available for Groups

Get-MsolAllSettings | ForEach Values

2016-10-30-16_14_29-start

You will now see it through the GUI when editing a group and will have the ability to set it.

2016-10-30-16_19_20-new-notification

And once you set a classification it will be viewable.

2016-10-30-16_20_55-photos

You can also set a classification using the Set-UnifiedGroup and New-UnifiedGroup cmdlets.

Set-UnifiedGroup interestgroup1@drewmadelung.com -Classification Internal

 

  • 1
  • 2