M365 Group: update value of CreationOption

Question

Inquiry/Questions

This is related to updating an M365 Group attribute CreationOption with a specific value of "ExchangeProvisioningFlags:3552" rather than an incorrect null per Microsoft basic support.

• Can the CreationOption be updated with Global Admin access?
• What proven methods have successfully facilitated this update?
• Are there specific pointers or command logic examples to efficiently update this attribute?
• Any nuance or pitfall insights from others overcoming similar attribute updates?

Related Resources

• Resource behavior options not being properly set by aad o365group add

  milanholemans commented on Aug 27, 2023

  All right found the culprit for this issue. Will provide a PR with the fix. Thank you for bringing this to the surface @alpozz!

  This change probably occurred sometime around May-June 2023. Groups I've created in May and early June were configured correctly, but groups created in early August appear not.

  In that case, probably something changed on the API we use because I can't see any significant changes since this option was introduced.

• Provision resources for a group

  resourceProvisioningOptions is a string collection that specifies group resources to be provisioned as part of the Microsoft 365 group. These resources can be specified during group creation or update.

  Supported values for resource : team

  Description : Provision a team for this group in Microsoft Teams. Additionally, this value can also be added on group update through a PATCH operation, in order to provision a team from an existing Microsoft 365 group. If not set, the Microsoft 365 group isn't associated with a team.

Self-Efforts

• Installed latest versions of Cloud Sync and Entra Connect; verified absence of on-prem to Azure AD sync errors.
• Conducted backend comparisons with functioning groups; inconsistency not identified.
• Added and removed members to other Teams existing before Exchange decommissioning; no issues.
• Newly created M365 Team-enabled groups function correctly upon access grant.
• Users granted access to problematic Team encounter issues; access seems limited to those with prior access only.
• Opened Microsoft support service tickets for further investigation.

Furthermore, I'll start digging into the Microsoft documents regarding group update and patch operations. To streamline my research and testing, I'm seeking more precise starting points or guidance from others knowledgeable in this area.

PowerShell Attempt & Detail

Connect-MgGraph -Scopes 'Group.ReadWrite.All'
$group = Get-MgGroup -Filter "DisplayName eq 'Broken Team'"
$creationOptions = @{
    ExchangeProvisioningFlags = 3552
}

$updateObject = @{
    creationOptions = $creationOptions
    resourceBehaviorOptions = @("HideGroupInOutlook", "WelcomeEmailDisabled", "SubscribeMembersToCalendarEventsDisabled")
    resourceProvisioningOptions = @("Team")
    serviceProvisioningErrors = @()
}
$json = $updateObject | ConvertTo-Json
Update-MgGroup -GroupId $group.Id -BodyParameter $json 

Error Output

Update-MgGroup : An unexpected 'StartObject' node was found for property named 'creationOptions' when reading from the JSON reader. A 'StartArray' node was expected.
At line:21 char:1
+ Update-MgGroup -GroupId $group.Id -BodyParameter $jsonPayload
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: ({ GroupId = 5df...oftGraphGroup }:<>f__AnonymousType0`2) [Update-MgGroup_Update1], RestException`1
    + FullyQualifiedErrorId : Request_BadRequest,Microsoft.Graph.PowerShell.Cmdlets.UpdateMgGroup_Update1

Broken Team Get

(Get-MgGroup -Filter "DisplayName eq 'Broken Team'").AdditionalProperties

Output

Key                         Value 
---                         ----- 
creationOptions             {}    
resourceBehaviorOptions     {}    
resourceProvisioningOptions {Team}
serviceProvisioningErrors   {}

(Get-MgGroup -Filter "DisplayName eq 'Broken Team'").AdditionalProperties | Select-Object Keys, Values | Format-List

Output

Keys   : {creationOptions, resourceBehaviorOptions, resourceProvisioningOptions, serviceProvisioningErrors}
Values : {System.Object[], System.Object[], Team, System.Object[]}

Working Team Get

(Get-MgGroup -Filter "DisplayName eq 'Working Team'").AdditionalProperties

Output

Key                         Value                                                                               
---                         -----                                                                               
creationOptions             {ExchangeProvisioningFlags:3552}                                                    
resourceBehaviorOptions     {HideGroupInOutlook, WelcomeEmailDisabled, SubscribeMembersToCalendarEventsDisabled}
resourceProvisioningOptions {Team}                                                                              
serviceProvisioningErrors   {}

(Get-MgGroup -Filter "DisplayName eq 'Working Team'").AdditionalProperties | Select-Object Keys, Values | Format-List

Output

Keys   : {creationOptions, resourceBehaviorOptions, resourceProvisioningOptions, serviceProvisioningErrors}
Values : {ExchangeProvisioningFlags:3552, HideGroupInOutlook WelcomeEmailDisabled SubscribeMembersToCalendarEventsDisabled, Team, System.Object[]}

---

The Story/Issue

In an M365 tenant, most Team-enabled M365 groups function similarly and were created using identical PowerShell commands. However, one Team group does NOT appear in either version of the Teams desktop app or teams.microsoft.com for newly granted members or owners.

Although other features such as SharePoint and Azure settings function properly, the Team and chat functions are inaccessible for newly granted member or owner access, despite being correctly listed as such in all M365 portals where checked.

Microsoft Service Tickets

I raised a Teams service ticket with Microsoft for resolution/troubleshooting assistance. Despite a week-long diagnostic, they advised contacting the Azure team since they found no issues.

The Azure team then discovered that the CreationOption for this group is null, unlike the expected value of "ExchangeProvisioningFlags:3552", which is set for properly functioning Team groups.

• Note: All other Microsoft 365 Teams-enabled groups, which were created using the same PowerShell commands during the presence of Exchange 2010 in the on-premise environment with null values, appear to function correctly.

  Works correct many other M365 Groups

  Key                         Value 
  ---                         ----- 
  creationOptions             {}    
  resourceBehaviorOptions     {}    
  resourceProvisioningOptions {Team}
  serviceProvisioningErrors   {}
  

I'll suggest this go to the SharePoint Microsoft 365 Team next. The Azure Team has mainly compared the two new groups created post-Exchange 2010 decommissioning and post-Exchange 2016. However, all other groups created pre-Exchange 2016 with null values continue to grant access correctly to Teams app, chat, etc. If I figure out a way to get the attributes updated, I will still try that regardless.

Recent Changes

If this is even applicable, perhaps an Exchange 2010 hybrid separation, or transitioning to Exchange 2016 contributed to nullifying a certain attribute of the M365 group, causing the Team to not display for new members and owners on both the app and Teams.Microsoft.com (V1 and V2).

Hybrid Environment

We're currently managing AD account Exchange attributes with a single Exchange 2016 server and plan to transition to Exchange 2019 and eventually Exchange Online, all managed solely through PowerShell.

We have an Entra Connect server using both Cloud Sync (filtered OUs) and Entra Connect which also assists with the M365 cloud created groups being populated back in the specific OU in on-premise AD via Group writeback.

Answer 1

As per the part 2 question related to further troubleshooting the anomalous M365 Teams issue experienced, this nuanced problem was resolved by using the below solution.

Everything worked per normal standards once the main issue was resolved without too much worry otherwise. Therefore, changing the CreationOption property value per vendor guidance was not necessary in this case to resolve main problem.

---

Quick

If discrepancies are observed between the membership displayed in the Teams app and the expected membership shown in the M365 admin portals, switching the Group configuration to 'assigned,' removing all members explicitly, allowing sufficient time for replication, and then reverting the configuration back to 'Dynamic' may resolve.

---

Tip

Begin by confirming that an existing owner of the Team can access the 'Manage Team' option in the Teams app. Compare the Teams app members that are listed for an owner with access with all the M365 admin portals as Global Admin against the group's membership and note differences.

Solution (Steps)

Important: Backup the Dynamic membership rules if necessary before following these steps.

1. Within Microsoft Entra admin center, go to the Group.
2. Click Properties, change Membership type to "Assigned", and press Save.
3. Go to Manage | Members, and explicitly remove members from the group within Entra while leaving owners as-is.
4. Now is the important part of waiting for all environmental and system replication to occur within your environment, step away for an hour or longer if possible (e.g. after close of business).
5. Confirm with Entra Admin, Teams Admin, and M365 Admin Centers that the members are all removed as per #3 from the Group.
6. As per #2, now toggle Membership type to "Dynamic", and press Save.
7. Go to Dynamic membership rules, and add/edit back in the necessary membership rules, and press Save.
8. Once again, wait for all environmental and system replication to occur within your environment, step away for a while, etc.
9. Confirm in all the M365 admin portals again #5, that now all members are listed correctly.

   • Confirm any newly grant Team "Owners" and "Members" access is back working.

   • Confirm from Teams desktop app as owner from the Manage Team option, that all members are assigned per the dynamic membership rules as expected.

     

---

Main Challenge

If you're encountering issues with Team-enabled Microsoft 365 Groups sourced from the cloud, configured for Dynamic Group Membership via rules, and experiencing sporadic failures in honoring these rules for member (and/or owner) access to Teams, this solution might be applicable to your situation.

Despite being an owner of a Group for several weeks, it appears errors encountered while running some MS Graph MgTeam commands stemmed from access issues with backend systems due to this problem too.

Granting new owner access may also be impacted by the issue too. Once the solution was effective, owner permissions worked as expected, and the MS Graph MgTeam commands worked properly too without error.