Microsoft Tech Community Live:  Microsoft Teams Edition
November 09, 2021, 08:00 AM - 12:00 PM (PST)

Team Creation with Graph API not creating SharePoint site

New Contributor



I am using Powershell / GraphAPI to create:


A M365 Dynamic Group

Then a Team based on this Group


The issue i have is both are created as expected, but I never get a Sharepoint Group Link on the M365 Group, and therefore no Sharepoint back end from the Team.


I am using a Service Principle in Azure, with the below Application API permission to GraphAPI






Any help appreciated - i can get this to work ok if im just using some powershell cmdlets to cerate the groups and Teams - but there are issues with using the MicrosofTeams cmdlets with the applicationid (on version 1.1.9 anyway). Besides i was hoping GraphAPI would be a smoother way of doing this!


Are there other permissions I need from the Service Principle for Teams to create the SharePoint site? I seriously cant see any other options.


Below is the Group missing the Sharepoint Link.




This is the code to create the M365 Group 


#Prepare generic OAuth Bearer token header
$headers = @{
"Content-Type" = "application/json"
Authorization = "Bearer $accessToken"

#Create the Office 365 Group - Post Request
$NewGroup = @{
Description = "MyTeam"
"owners@odata.bind" = @("")
DisplayName = "MyTeam"
groupTypes = @("Unified","DynamicMembership")
membershipRule = "(user.userPrincipalName -Contains `"USERNAMEHERE`")"
membershipRuleProcessingState = "On"
mailEnabled = $false
mailNickname = "myTeam"
securityenabled = $false
$creategroupbody = ConvertTO-Json -InputObject $NewGroup
$response = Invoke-RestMethod -Uri "" -Body $creategroupbody -Method Post -Headers $headers -UseBasicParsing
$groupid = $



... and this creates my team


$teamBody =
"memberSettings": {
"allowCreateUpdateChannels": true,
"allowDeleteChannels": true,
"allowAddRemoveApps": true,
"allowCreateUpdateRemoveTabs": true,
"allowCreateUpdateRemoveConnectors": true
"guestSettings": {
"allowCreateUpdateChannels": true,
"allowDeleteChannels": true
"messagingSettings": {
"allowUserEditMessages": true,
"allowUserDeleteMessages": true,
"allowOwnerDeleteMessages": true,
"allowTeamMentions": true,
"allowChannelMentions": true
"funSettings": {
"allowGiphy": true,
"giphyContentRating": "strict",
"allowStickersAndMemes": true,
"allowCustomMemes": true

$newTeam = Invoke-RestMethod -Uri "$($Groupid)/team" -Method PUT -Headers $headers -Body $teamBody


I grab my bearer token with further code - thats working fine, i get the token to do run the above.


$env:graphApiDemoAppId = "xx" # HIDDEN
$env:graphApiDemoAppSecret = "xx" # HIDDEN
$env:tenantId = "xx" # HIDDEN

$oauthUri = "$env:tenantId/oauth2/v2.0/token"

# Create token request body
$tokenBody = @{
client_id = $env:graphApiDemoAppId
client_secret = $env:graphApiDemoAppSecret
scope = ""
grant_type = "client_credentials"

# Retrieve access token
$tokenRequest = Invoke-RestMethod -Uri $oauthUri -Method POST -ContentType "application/x-www-form-urlencoded" -Body $tokenBody -UseBasicParsing

# Save access token
$accessToken = ($tokenRequest).access_token





Ian Fraser


3 Replies
It is not about permissions, but the fact that the SharePoint folders are created later in the provisioning. The fastest way to create them is to go ahead and click on Files tab in the created channel.

However you can do a workaround
- after team creation
- retrieve the SharePoint Site information connected to the team
- retrieve the document library info (drive info: $targetDriveIDURI = "" + $teamID + "/drive" )
- knowing you channel name create a dummy file in the channel (yes, the channel folder doesn't exist but it is created during this process)
$createfileURI = "" + $targetDriveID +"/root:/" + $channel.displayName +"/dummy_remove.txt:/content"
$fileResponse = Invoke-RestMethod -Method Put -Uri $createfileURI -Headers @{"Authorization"="Bearer $accessToken"} -Body $createfileContent -ContentType "text/plain"

After that you have the folder available for further use.

Note: this doesn't work in Private channels. For those there is a need to wait or click in the UI.
I was getting a similar issue, but mine where not Dynamic Groups. Read in an article that there was some idiosyncrasies between the teams client and the graph api. Turns out that the graph api for creating groups does not add "owners" to "direct members" so that when the owners access the team/site the site creation is failing as they are not added as members of the site correctly. By having the "owners" in the group "members" list when calling the API for Group it seemed to fix the issue for me.
best response confirmed by ThereseSolimeno (Microsoft)

@Shane_Blake Hi - thanks for reply. I actually raised a PS call in the end, and it turned out to be a problem that Microsoft had to fix at the back end - related to creating the SharePoint site on the time. I think it was a timing issue.


It wasnt fixed as part of my call, sounds like it was being fixed anyway.


I did read about the direct members - i add them now as part of my code anyway so we dont have just an owner without being a member. But it doesnt seem to effect anything for me if they are just owners - the site creation is all via Graph anyway so it doesnt care. 


Im using AD groups (on prem) and have a sync framework to manage membership - it fits in with our onboarding processes so we can assign Teams to departments / functions using AD Attributes, and the AD groups add 'exceptions' ie someone from department A wants to join the department B team, we drop them in the Exceptions AD group for the Department B team and the script does the rest. Ideal for Service Desk / integration into a JLT process. Decided to avoid cmdlets and do purely RESTAPI as ive hit so many issues with bugs.