At Microsoft Ignite conference last September, we demoed an approach for a self-built Office 365 Groups Governance Toolkit. Since Microsoft 365 is an evergreen service and continues to evolve, today we have more group settings available and we extend our provisioning function to work with group naming policies as well. See here how this can be accomplished by including new Graph requests.
Foreword
You can find the previous articles of our governance story at Provisioning an Office 365 group with an approval flow and Azure functions-part 1, part 2, part 3, part 4, part 5 and part 6 and the source code at martinagrom/Ignite2018GroupsGovernanceToolkit.
While we have new features in Microsoft Graph which we will show here, another important aspect is that Azure Functions v2.0 are GA´ed since Ignite and the experimental Functions v1.0 will be discontinued in near future. Microsoft has not officially announced a specific date, but they recommend to switch to v2.0, and PowerShell support was (and still is) always "experimental" in v1.0. Azure Functions v2.0 run in containers and work with the .NET Standard library, so they will support PowerShell 5.x and PowerShell 6.x only (PS 6.x can run on Linux, macOS, and Windows). Anyway, we continued to extend our existing Azure Functions in v1.0 and we will update all scripts in the public GitHub repository in near future as well. Also, the functionality will be available as an SaaS product soon.
Setup Group classification and more settings
To create or modify the Office 365 tenant´s group settings, you can use the following script at Setup-Group-Classification.ps1.
When setting a PrefixSuffixNamingRequirement in the tenant settings, all groups must follow that rule. For example, if this setting is set to "Team.[GroupName]_[Department]", and a user creates a new Office 365 group "NewHires", the name must match "Team.NewHires_HR", if the user´s department is set to "HR". With that simple mechanism, consistent group names within the tenant are enforced. Also more group properties are available as described below.
Use the Microsoft Graph for group settings
Now, this functionality is also present in the Microsoft Graph v1.0 which allows to use these settings in other programming languages as well – thanks to Mikael Svenson for the hint! So, let´s open aka.ms/ge – the Graph Explorer playground tool – and test the new methods.
Tip: To get or set group settings and group data, the authenticated users needs to have the Group.ReadWrite.All and the Directory.ReadWrite.All Administrator permission, otherwise you get a Failure - Status Code 401, Unauthorized response. Graph Explorer informs if insufficient permissions are existing and asks for adding the required permissions and to reauthenticate with the new consent then.
Get the group lifecycle policy
So, the first request delivers existing policies with a HTTP GET against groupLifecyclePolicies. If there´s no group expiration defined, we get an empty value array as here.
https://graph.microsoft.com/v1.0/groupLifecyclePolicies
So let´s have a look how to set group settings.
Set general group settings in the Azure portal
Administrators can modify the group expiration in the Azure Portal, or with PowerShell or with Graph.
Set the group lifecycle policy
The Group expiration settings can also be defined in the Azure portal, or with PowerShell.
When running the query again, we see the new group expiration settings. In our sample, the settings look as here.
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#groupLifecyclePolicies",
"value": [
{
"id": "533f29a2-918b-4e43-9d03-759d9e352887",
"groupLifetimeInDays": 90,
"managedGroupTypes": "Selected",
"alternateNotificationEmails": "admin@sometenant.onmicrosoft.com"
}
]
}
Modify the group expiration with Graph
Now we can change values, as setting the expiration time from 90 to 60 days with Graph Explorer. The HTTP request is now a PATCH operation and the settings id is added to the URL and the Request Body holds the data we send to the API as here.
https://graph.microsoft.com/v1.0/groupLifecyclePolicies/533f29a2-918b-4e43-9d03-759d9e352887
{
"groupLifetimeInDays": 60,
"managedGroupTypes": "Selected",
"alternateNotificationEmails": "admin@sometenant.onmicrosoft.com"
}
As result, the new settings are returned.
Set a Groups naming policy
Again, this can be done in the Azure Portal or with PowerShell. In here, Blocked words (a CSV file) can be uploaded and a Naming Policy can be defined as in the following screenshot.
A BlockedWord.csv file can be downloaded from the portal, filled out and uploaded. The blocked words for group naming are simple stop words as here.
Get a Groups naming policy with Graph
In Graph Explorer, we now see more group settings with a GET request against the groupSettings method.
https://graph.microsoft.com/v1.0/groupSettings
So, the complete result in my sample looks as here:
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#groupSettings",
"value": [
{
"id": "479c4228-bc37-4c14-a5e9-fd351bd49f23",
"displayName": "Group.Unified",
"templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
"values": [
{
"name": "CustomBlockedWordsList",
"value": "boss,ceo,account"
},
{
"name": "EnableMSStandardBlockedWords",
"value": "false"
},
{
"name": "ClassificationDescriptions",
"value": ""
},
{
"name": "DefaultClassification",
"value": ""
},
{
"name": "PrefixSuffixNamingRequirement",
"value": "[Department]_[GroupName]"
},
{
"name": "AllowGuestsToBeGroupOwner",
"value": "false"
},
{
"name": "AllowGuestsToAccessGroups",
"value": "true"
},
{
"name": "GuestUsageGuidelinesUrl",
"value": ""
},
{
"name": "GroupCreationAllowedGroupId",
"value": ""
},
{
"name": "AllowToAddGuests",
"value": "true"
},
{
"name": "UsageGuidelinesUrl",
"value": ""
},
{
"name": "ClassificationList",
"value": ""
},
{
"name": "EnableGroupCreation",
"value": "true"
}
]
}
]
}
Modify tenant-wide groupSettings
Again, we can modify settings with a PATCH operation as well. So, we add the settings id and the returned data with additional stop words again:
https://graph.microsoft.com/v1.0/groupSettings/479c4228-bc37-4c14-a5e9-fd351bd49f23
{
"displayName": "Group.Unified",
"templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
"values": [
{
"name": "CustomBlockedWordsList",
"value": "boss,ceo,account,event,badword"
},
{
"name": "EnableMSStandardBlockedWords",
"value": "false"
},
{
"name": "ClassificationDescriptions",
"value": ""
},
{
"name": "DefaultClassification",
"value": ""
},
{
"name": "PrefixSuffixNamingRequirement",
"value": "[Department]_[GroupName]"
},
{
"name": "AllowGuestsToBeGroupOwner",
"value": "false"
},
{
"name": "AllowGuestsToAccessGroups",
"value": "true"
},
{
"name": "GuestUsageGuidelinesUrl",
"value": ""
},
{
"name": "GroupCreationAllowedGroupId",
"value": ""
},
{
"name": "AllowToAddGuests",
"value": "true"
},
{
"name": "UsageGuidelinesUrl",
"value": ""
},
{
"name": "ClassificationList",
"value": ""
},
{
"name": "EnableGroupCreation",
"value": "true"
}
]
}
Adapt the request, as for classification, enable group creation or other settings as required. If successful, that request returns a HTTP status code 204 as here.
Another GET will deliver our new values. Simple as that.
Summary
The shown Graph methods above allow to programmatically access the new Office 365 group settings. We could use these queries for provisioning a new Office 365 Group or Team with a name that complies with the policy settings or develop our custom interface that informs the user about such tenant settings. It´s great to see that the Microsoft Graph evolves and we now can use the new methods for getting and setting group policies as required by your organization.
Finally, we hope you enjoyed our open source Office 365 Groups Governance Toolkit series. As a quick reference, find all articles here:
Office 365 Groups Governance Toolkit series