New enhancements to the #AzureAD PowerShell 2.0 preview. Manage dynamic groups and more!
Published Sep 07 2018 08:29 AM 22.6K Views
First published on CloudBlogs on Nov, 03 2016
Howdy folks, This week we published a really cool update to Azure AD PowerShell v2.0 preview cmdlets. This update gives you some pretty killer new Azure AD functionality. The new thing I’m the most jazzed about is managing dynamic group settings using PowerShell. This was a top request from all you PowerShell folks out there. Previously, you needed to set rules for the creation and population of these groups using the management UX. Not anymore! And the new AzureADMSGroup cmdlets provide the functionality of Microsoft Graph to create and manage groups, which includes creating Office 365 groups and dynamic groups through PowerShell. With these cmdlets you can create new dynamic groups, set or update the dynamic group rule, and start and pause dynamic group processing. You can also use other Azure AD cmdlets to orchestrate all this in bulk. Imagine running a script that automatically creates dynamic groups for all your departments, all your device types, or maybe for all your managers in your directory. Now you can understand why I’m so excited about this! Managing dynamic groups through Azure AD PowerShell Create and manage a dynamic group by using the New-AzureADMSGroup cmdlet. In this example, we’re creating a dynamic security group called "All marketing users":
New-AzureADMSGroup -Description "Marketing team" -DisplayName "Dynamic groups with all Marketing users" -MailEnabled $false -SecurityEnabled $true -MailNickname "Foo" -GroupTypes "DynamicMembership" -MembershipRule "(user.department -eq ""Marketing"")" -MembershipRuleProcessingState "Paused"
When you execute this cmdlet, the following output is returned:
Id : db78a43d-ba08-4eab-8766-07280a4ba580 Description : Marketing team OnPremisesSyncEnabled : DisplayName : Dynamic groups with all Marketing users OnPremisesLastSyncDateTime : Mail : MailEnabled : False MailNickname : Foo OnPremisesSecurityIdentifier : ProxyAddresses : {} SecurityEnabled : True GroupTypes : {DynamicMembership} MembershipRule : (user.department -eq "Marketing") MembershipRuleProcessingState : Paused

Creating an Office 365 group with AzureAD PowerShell

You can also create an Office 365 group using the New-AzureADMSGroup cmdlet. In the example below, we’re creating a new Office 365 group for all the stamp collectors in our organization:
PS C:\Users\rodejo> New-AzureADMSGroup -Description "Stamp Collectors" -DisplayName "Office 365 group for all Stamp Collectors in our org" -MailEnabled $true -SecurityEnabled $true -MailNickname "StampCollectors" -GroupTypes "Unified"
And this is the output the cmdlet call returns:
Id : 92e93152-a1a6-4aac-a18a-bfe157e3b319 Description : Stamp Collectors OnPremisesSyncEnabled : DisplayName : Office 365 group for all Stamp Collectors in our org OnPremisesLastSyncDateTime : Mail : StampCollectors3545@drumkit.onmicrosoft.com MailEnabled : True MailNickname : StampCollectors OnPremisesSecurityIdentifier : ProxyAddresses : {SMTP:StampCollectors3545@drumkit.onmicrosoft.com} SecurityEnabled : True GroupTypes : {Unified} MembershipRule : MembershipRuleProcessingState :
Some things to note:
  • The value that you provide for the “MailNickName” parameter is used to create both the SMTP address and the email address of the group. If the MailNickName is not unique, a four-digit string is added to the SMTP and email addresses to make them unique, like in the example above.
  • The values for SecurityEnabled and MailEnabled are set and ignored when creating an Office 365 group because these groups are implicitly security and mail enabled when used in Office 365 features.
  • If you want to create a dynamic Office 365 group, you need to specify both “DynamicMembership” and “Unified” in the GroupTypes parameter, as in:
Set-AzureADMSGroup -Id c6edea99-12e7-40f9-9508-862193fcb710 -GroupTypes "DynamicMembership","Unified" -MembershipRule "(User.department -eq ""Marketing"")" -MembershipRuleProcessingState "Paused"

Managing the processing state of a group

Sometimes you may want to stop the processing of a dynamic group, like when you’re importing a large number of new users or reorganizing your group architecture. To do that, use the MembershipRuleProcessingState parameter to switch processing on and off. To switch it off, use:
Set-AzureADMSGroup -Id 92e93152-a1a6-4aac-a18a-bfe157e3b319 -MembershipRuleProcessingState "Paused"
And to switch it back on, use:
Set-AzureADMSGroup -Id 92e93152-a1a6-4aac-a18a-bfe157e3b319 -MembershipRuleProcessingState "On"
Other release updates This release also includes a few other changes and new cmdlets. Cmdlets to revoke a user’s Refresh Tokens: We got requests from several customers to provide capabilities to revoke a user’s refresh tokens. To address that need, we added these two new cmdlets:
Revoke-AzureADSignedInUserAllRefreshTokens

This cmdlet is used by the admin to invalidates all of their own refresh tokens issued to applications by resetting the refreshTokensValidFromDateTime user property to the current date-time. It also resets session cookies in a user’s browser. Use this command if you are concerned you account has been attacked or if you are trying to get back to a “clean” state when you are trying to verify a sign-in flow.

Revoke-AzureADUserAllRefreshTokens
This cmdlet Invalidates all the refresh tokens (as well as session cookies in a user’s browser) of the user specified by the admin in the invoking the command. This is accomplished by resetting the refreshTokensValidFromDateTime user property to the current date-time.
Connect-AzureAD no longer requires -Force: We learned from your feedback that you’d rather not get the Connect-AzureAD cmdlet prompt for confirmation, so we removed the requirement to specify the -Force parameter to suppress confirmation prompting. Naming convention change for cmdlets that call Microsoft Graph: In a previous blog post we mentioned how we’re aligning AzureAD PowerShell V2 functionality with Graph API functionality . Since the AzureAD PowerShell cmdlets expose both the Azure AD Graph API and the Microsoft Graph, we decided to make a small change to the naming convention of our cmdlets. Moving forward, all cmdlets that call the Microsoft Graph will have “MS” in their cmdlet names, as in “Get-AzureADMSGroup”. The cmdlets that call the Azure AD Graph will not change, so there is also a “Get-AzureADGroup” cmdlet. We’ll be implementing these name changes in an upcoming release and will share all the details then. Getting started To get started using the New-AzureADMSGroup cmdlet, take a look at a short video we made detailing how to manage dynamic groups using PowerShell . Dynamic Membership for Groups requires an Azure AD premium license, so if you don’t have one already, make sure to sign up for a free trial license . I hope you’ll find these new capabilities useful! And as always, we would love to receive any feedback or suggestions you have. Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division
5 Comments
Steel Contributor

I'm surprised I am the 1st comment, this long after the post.  I want to say - this is a step up from say, creating an entirely new PS module for AzureAD (again).  I wish though that the official Cmdlet pages on docs.microsoft.com also explained the difference between the "MS" commands and non-"MS" commands.  There is no mention of MS Graph here for example: https://docs.microsoft.com/en-us/powershell/module/azuread/get-azureadmsgroup?view=azureadps-2.0

 

Seeing as there also are no comments here, it's a good sign that the mass majority of your customers have no idea what's going on and are going to need to Google search their way to find the answer to "what's the difference between Get-AzureADGroup and Get-AzureADMSGroup?" (using these 2 as an example).  The Azure AD PS saga continues...

 

Hopefully we will see more consistency between and consolidation of all the Azure AD PowerShell modules/cmdlets.

 

Example (re: consistency (and better PS practices): -All parameter needing $true in AzureAD v2, while not needing that in v1

Example (re: consolidation (and just good practices, period)):  https://dirteam.com/sander/2019/03/28/the-state-of-azure-ad-powershell-today/ - 4 Modules !!!!

Silver Contributor

@Jeremy Bradshaw +10,000 to your comment. I have not been using powershell for a while and I have been spinning my wheels trying to do some pretty simple stuff. 

Copper Contributor

As of writing this and in hopes of not wasting potentially hundreds of hours of technicians time around the world, this documentation is amazing, yet should probably include that the -MembershipRule options are only available in the AzureADPreview module. Yes, that's right, almost 6 years later and you still can't make a dynamic group with rules using AzureAD module.

I know that the article references the AzureADPreview module, but I have had several people run into the problem because the official documentation on docs.microsoft.com doesn't mention that you need to use the preview module.

If you have run into this problem, you can install the preview module like this:

 

#It can be install alongside the other module

Install-module AzureADPreview -Repository PSGallery -AllowClobber -Force

#if you have both modules, you should ensure that the correct module is the one you are using:

# Unload the AzureAD module (or continue if it's already unloaded)
Remove-Module AzureAD -ErrorAction SilentlyContinue
# Load the AzureADPreview module
Import-Module AzureADPreview

 

I know the post is old, but it scores really high in google searches for creating a dynamic group. If my reply here helps even one person, it was worth the time writing it.

 

 

Brass Contributor

@Dean Gross @Jeremy Bradshaw Alas, i'm another who has wasted a few hours on this.

 

However, i've tried to prevent it happening again. I've pressed the edit button on https://docs.microsoft.com on the pages for Get-AzureADMSGroup and Get-AzureADGroup cmdlets and added some very minor notes at the top and bottom about AzureAD Graph vs MSGraph and submitted the PR to github: Patch 1 - Get-AzureADGroup vs Get-AzureADMSGroup by tlourey · Pull Request #752 · Azure/azure-docs-p....

Perhaps a comment & thumbs up might help. 

 

Cheers gents. 

 

 

Steel Contributor

Good stuff, re: the PR.  I have since (my post), spent most of my Azure AD duties time not needing to worry about the newer things in the PS module.  I've found that for reliability, as in things remaining preditcable and stable, MS Graph v1.0 directly (and Beta for some stuff although slightly contradictory to my predictable label) is the way to go.

 

While the PS modules are the wild west where anything can be done or changed, MS Graph is what vendors are given to rely on for the solutions and apps they develop.  Thanks to that, MS Graph remains very predictable.  Only issue is when a certain thing isn't yet supported in Graph.  Then it's a waiting game where ETA's are hard to come by.  But other than that, things sometimes are only doable there, and not available in the PS modules.  An example is the LastSignInDateTime stuff.  I believe it's now in the module, but had been available in MS Graph beta for quite some time first.

Version history
Last update:
‎Jul 24 2020 02:02 AM
Updated by: