Forum Discussion
Is it possible to create Office 365 Groups with Azure AD PowerShell Module (2.0.0.98)?
You have to use the New-AzureADMSGroup cmdlet to create a new Office 365 Group. This is a variation of New-AzureADGroup that uses the Microsoft Graph to create the group.
[PS] C:\> New-AzureADMSGroup -Description “A Group for Juan to play with” -DisplayName “Juan's Office 365 Group” -MailEnabled $true -SecurityEnabled $true -MailNickname “JuanGroup” -GroupTypes “Unified”
But I would always run New-UnifiedGroup to create an Office 365 Group...
You have to use the New-AzureADMSGroup cmdlet to create a new Office 365 Group. This is a variation of New-AzureADGroup that uses the Microsoft Graph to create the group.
[PS] C:\> New-AzureADMSGroup -Description “A Group for Juan to play with” -DisplayName “Juan's Office 365 Group” -MailEnabled $true -SecurityEnabled $true -MailNickname “JuanGroup” -GroupTypes “Unified”
But I would always run New-UnifiedGroup to create an Office 365 Group...
Because when you run New-UnifiedGroup, the mailbox is created immediately. When you run New-AzureADMSGroup, the group object is created in AzureAD and then synchronized with EXO, which then creates the group mailbox.
Rob de JongMicrosoft
I think it depends a bit on the script you are building. If you want to create a new unified group and then immetiately execute a cmdlet that executes on the mailbox of the new group your best bet is New-Unifiedgroup, for the reason Tony explained. Please note though that in my test environment such a script will still fail about 25% of the time, since the mailbox may not be created yet when I execute the next cmdlet.
If your script sets a dynamaic rule for group membership on the new Unified group, you should use the New-AzureADMSGroup cmdlet, since the delay between New-UnifiedGroup and the actual creation of the groups in AzureAD will likely make a subsequent Azure AD cmdlet call fail if executed immediately after the New-UnifiedGroup cmdlet.Good points. Like any of the EXO cmdlets, it is wise to test that an object exists after creation before you proceed to try and use it. The point is that Office 365 uses a complete system of directory synchronization to ensure that objects show up at the right time in the right place and reasonably quickly to boot. So don't assume that something is there just because a cmdlet completes. Wait, test, and verify...