[BUG] New-PnPTeamsTeam returns nothing on Azure Automation using Managed Identity auth

[SabbeRubbish]

Reporting an Issue or Missing Feature

Creating a new MS Team using New-PnPTeamsTeam

Expected behavior

Return value = the created team object with properties like GroupId to continue modifying this team (adding channels, getting SiteURL to set sharing policies, ...)

Actual behavior

Return value on Azure Automation = $null

Steps to reproduce behavior

1. Create app registration with Groups.ReadWrite.All app-only permission
2. Run this code:

Connect-PnPOnline <url> -ManagedIdentity
$team = New-PnPTeamsTeam -DisplayName "doesn't matter" -MailNickName "doesn't matter" -Description "doesn't matter" -Visibility Public -Owners "myuserupn" -Members "myuserupn"
Write-Output "Created team $team"

$team will be $null.

This works on 3.1 and 2.12.0 in my VS Code console (not on Azure Automation). Even works on my local Azure Automation job.

What is the version of the Cmdlet module you are running?

Azure Automation only allows 2.12.0, so that's the version that has the issue.

Which operating system/environment are you running PnP PowerShell on?

• [x] Windows
• [x] Azure Automation

[SabbeRubbish]

Slight little bump here as this is still limiting my chances of getting to production for a customer :-)

[gautamdsheth]

@SabbeRubbish - is the team actually getting created in the tenant ? or is there an issue with the returned value ? Don't think its related to PnP , more likely something with Azure automation. Maybe also try Get-PnPTeamsTeam or something and check ?

[SabbeRubbish]

@gautamdsheth the team actually gets created. I think there is an issue with the returned value. I don't see how Azure Automation would interfere with this, I'm using multiple scripts that are hosted there and none of them have result returning issues. Checking whether it's created is also tricky, because neither the displayname or mailnickname are unique in a tenant, if one already exists (which shouldn't be the case in my situation, but that's not generally true) then it's sketchy to find all teams with a certain displayname and then getting the one that's most recently created. The cmdlet should just return the Group Guid.

When I just POST to /groups and then POST to /teams (which is my current reverse-engineered workaround) I get the Group Id back immediately.

[gautamdsheth]

The mailnickname is unique in the tenant. You should be able to find the group id using Get-PnPMicrosoft365Group cmdlet as well besides Get-PnPTeamsTeam which both support Filter query, check docs.

Since it works locally in VS Code as well as in your local azure automation, its difficult for us to even reproduce it. Even if we do manage to find a fix for it, it will be in 3.x version which isn't currently supported in Azure automation. Not ideal I know, but can't think of another way either 🤷‍♂️

Another option would be to use New-PnPMicrosoft365Group and specify CreateTeam parameter which does the same thing, maybe helps ?

[SabbeRubbish]

Hi gautamdsheth,

Thank you for your reply. Yes mailnicknames are unique, but if I create a new MS Teams or M365 Group with the same nickname in my request, it will append some random numbers to it when creating. This is different than for SP sites e.g. where you get an error, for MS365 groups, it will just create a new alias with a random suffix. Hence, I can't just fetch the group using its mail nickname, as it may have been suffixed. I understand reproduction is difficult and I appreciate your effort to try and find a fix.

I'll try the New-PnPMicrosoft365Group with the -CreateTeam option next week and I'll report back. Could be a better workaround than calling the REST API, as the cmdlets have retry mechanisms built-in.

[jackpoz]

Try including -ErrorAction:Stop as parameter, it might be the same issue as https://github.com/pnp/powershell/issues/4646#issuecomment-2560173697 where a User.* permission is required to fetch the needed information for Owners and Members, in addition to Groups.ReadWrite.All to create the group.

[gautamdsheth]

The latest nightly builds now work on Azure automation, maybe that might help in your issue . Has been quite a few changes in there, would be great if you could upgrade and test and let us know ?

[SabbeRubbish]

Try including -ErrorAction:Stop as parameter, it might be the same issue as #4646 (comment) where a User.* permission is required to fetch the needed information for Owners and Members, in addition to Groups.ReadWrite.All to create the group.

Hi Jackpoz, thanks for contributing. My app service principal has the User.ReadWrite.All app role, so that is not the case here.

[SabbeRubbish]

Hi all, I can confirm that the New-PnPMicrosoft365Group -CreateTeam workaround works - even on Azure Automation with PS 7.2 and PnP 2.12 I cannot test things on Azure Automation with the latest PnP PS as Automation still only allows up to PS 7.4 and PnP 3 requires PS 7.5.1...