exchange remove management role assignment

Subscribe for Practical 365 updates

Please turn off your ad blocker and refresh the page to subscribe.

You may withdraw your consent at any time. Please visit our Privacy Statement for additional information

Exchange Server

Exchange server role based access control in action: using management roles.

Exchange Server uses a permissions model called Role Based Access Control (RBAC) to manage the delegation of permissions for Exchange administrative tasks. RBAC was first introduced in Exchange 2010 and continues to be used in Exchange Server and Exchange Online today. It’s important to understand how RBAC works because it is the mechanism that you use to apply a least-privilege approach to Exchange administrative permissions. RBAC is also how end users are granted permissions to perform tasks such as managing their own distribution groups.

In this tutorial we’ll look at:

• How RBAC works by examining the pre-defined RBAC management roles
• How to configure custom management roles

The Basics of Role Based Access Control

Whether you understand the inner workings of RBAC or not, you’re still making use of it every day when you perform Exchange administrative tasks. That’s because RBAC has a series of pre-defined management role groups, management roles, and management role assignments for a variety of common administrative scenarios.

Management role groups are the security groups in Active Directory. You can see the management role groups that Exchange creates during setup in the Microsoft Exchange Security Groups OU in Active Directory.

Some of those groups should already look familiar to you, such as Organization Management and Recipient Management. Some of the groups in that OU are for other purposes, such as the Exchange Trusted Subsystem group which contains computer accounts for Exchange servers. So if you want to see just the role groups, you can switch to the Exchange Management Shell instead and run the Get-RoleGroup cmdlet.

Notice how each role group has one or more assigned roles, which refer to management roles. An example of a management role is Mail Recipients.

Management roles are collections of management role entries. Management role entries are specific tasks that can be performed by users who are assigned with that particular role. Continuing with the example of the Mail Recipients role, the management role entries can be summarized by looking at the description of the management role.

So the Mail Recipients role contains a whole bunch of role entries to make that possible. Role entries have a naming convention of “RoleEntry”, so all of the role entries for the Mail Recipients role will be named “Mail RecipientsEntry”. This means that you can see the list of role entries for the Mail Recipients role by running the following command:

On my system there’s 125 role entries for the Mail Recipients role, so I won’t list them all here. But they basically include all the cmdlets you’d need for that purpose, such as Get-Mailbox, Set-Mailbox, and Enable-Mailbox (for mail-enabling an existing user). However, it is a separate management role called “Mail Recipient Creation” that has the role entries that permit creating entirely new recipients, such as New-Mailbox, New-MailUser, and New-MailContact.

Both the Mail Recipients and Mail Recipient Creation roles, along with others, are assigned to the role group named Recipient Management. You can see the role assignments for the Recipient Management role group by running the Get-RoleGroup cmdlet.

The Recipient Management role group is one of the Active Directory security groups that exists in the Microsoft Exchange Security Groups OU. Therefore, if you add a user account to the Recipient Management group, they are granted the ability to perform those administration tasks such as managing mail recipients, distribution groups, and performing message tracking. When that user opens the Exchange Management Shell, only the cmdlets that are included in the role entries for the management roles assigned to the role groups they are a member of will be available. For example, a Recipient Management role group member won’t have access to the New-AcceptedDomain or Set-AcceptedDomain cmdlets, but they do have access to the Get-AcceptedDomain cmdlet.

When the user logs into the Exchange Admin Center, they will also see only the sections that they have access to through their role group membership. For example in the screenshot below, the web browser on the left shows the sections visible to a Recipient Management role group member, and the browser on the right shows the sections visible to an Organization Management role group member.

Some of the differences are obvious, for example the Recipient Management role group member can’t see the compliance management section of the Exchange Admin Center. Others are not so obvious at first. Both users can see the mail flow section where things like Accepted Domains are managed. The Recipient Management role group holder can still see that section, because they need to be able to “see” the list of accepted domains in the organization when assigning SMTP addresses to recipients. But they can’t edit any of the accepted domains, nor can they add new ones.

As the final piece of the RBAC picture, there’s also the concept of management role scope. The management roles (such as Mail Recipients) assigned to the pre-canned role groups (such as Recipient Management) have a scope of “Organization”, which effectively means they apply to the entire organization. Management roles can be scoped to more specific area, such as to a single organizational unit in Active Directory.

So to summarize what’s been covered so far, RBAC is made up of:

• Management role entries, which are specific tasks that a user can perform, such as running the Set-Mailbox cmdlet.
• Management roles, which are collections of role entries, such as the Mail Recipients role.
• Management role scope, which defines where in the organization a management role is applicable to, such as the entire organization, a specific server, or a specific organizational unit.
• Management role assignments, which link management roles to role groups.
• Management role groups, which are security groups that users can be added to as members to grant them the permissions to perform administrative tasks.

Once you are comfortable with those basics, you can start looking at creating custom roles.

Creating a Custom RBAC Role

Let’s say that you have a user in the organization who is responsible for managing mail contacts. To provide them with the permissions to perform that task, without any additional effort on your part, you would need to add them to the Recipient Management role group. However, that role group permits them to do much more than just manage the mail contacts they are responsible for, so it doesn’t align with the least privilege approach to security.

The more sensible approach is to create a custom RBAC role and assign it to that user, or to a role group that the user can be made a member of.

The easiest way to create a custom role is by using the Exchange Admin Center. In the permissions section under admin roles , click the icon to create a new role group.

Give the role group a meaningful name, and set the organizational unit that you want to limit the role group to.

Next, click the icon to add a role. In scanning through the list of existing roles (remember, these are collections of role entries), there doesn’t appear to be one already created for managing mail contacts. So a custom role (or two) with the role entries for managing contacts needs to be created. Creating custom roles is easiest when you create the custom role based on an existing role, and then customize it for your needs. In this case, Mail Recipients and Mail Recipient Creation are the two roles to base the new custom roles on.

The next step is to remove the unwanted role entries from each of the custom roles, so that they’re only left with the capability to manage mail contacts.

So now we’re left with two custom roles called “Custom Role – Mail Contacts” and “Custom Role – Mail Contacts Creation”, each containing only the role entries required for managing contacts.

Back to the Exchange Admin Center, the two custom roles are now visible in the picker to add to the new role group we’re creating. Add the two custom roles, and also add the View-Only Recipients role.

Finally, add the users who will be performing the administrative tasks to the role group as members, and save the new role group.

When the members of the new “Mail Contact Managers” role group log in to the Exchange Admin Center, they’ll be able to see the recipients in the organization (just as they can see them in the global address list via Outlook), and in the Contacts area will be able to create new Mail Contacts. If the role group member shown above tries to create a contact in an OU other than the one their role has been scoped to, they’ll receive an error.

But if they choose the correct OU when creating the contact, they’ll be successful. The same OU restrictions also apply to modifying or deleting contacts.

In this tutorial I’ve demonstrated how to use pre-defined management roles in Exchange Server to assign RBAC permissions for administrative tasks. I’ve also demonstrated how to create custom roles and role groups to assign limited permissions to users for specific tasks.

About the Author

Paul Cunningham

The Real Person!

Author Dean acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.

I got some errors when using the commands provided, a little bit of back and forth with chatgpt got me to this.

$entries = Get-ManagementRoleEntry “Custom Role – Mail Contacts Creation\*” $filteredEntries = $entries | Where {$_.Name -notlike “*MailContact”} $filteredEntries | Format-Table Name, Role, Cmdlet foreach ($entry in $filteredEntries) { # Erstellung des vollständigen Identity-Werts $fullIdentity = “$($entry.Role)\$($entry.Name)”

Write-Host “Versuche, den Eintrag zu entfernen: $fullIdentity”

try { # Entfernen des Eintrags mit dem korrekt formatierten Identity-Wert und ohne Bestätigungsaufforderung Remove-ManagementRoleEntry -Identity $fullIdentity -Confirm:$false } catch { Write-Host “Fehler beim Entfernen des Eintrags: $fullIdentity” Write-Host $_ } }

feel free to use

edit: this is for exchange online / o365

Is an Exchange mailbox required on a domain account to add it to the Organization Management Role ? We are using Exchange 2016

It seems I can add domain user accounts and universal security groups to a role. But I’m wondering if there are any limitations in any of the permissions when there is no mailbox assigned to the account?

Thank, Bill

Yor admin account will need a mailbox to sign in to the ECP console on Exchange 2016.

You do not need to use the mailbox for mail . You can set the mailbox to reject all mail under: Mailbox features – Message Delivery Restrictions.

I am trying to create exactly this same thing in Office 365 Exchange and run into an issue with running the second removal command. One user posted the same issue but never got a response.

When running

Get-ManagementRoleEntry “Custom Role – Mail Contacts Creation\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “Custom Role – Mail Contacts Creation” to type “Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you specified in the Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value, and then try again. Parameter name: identity” + CategoryInfo : InvalidData: (Custom Role – Mail Contacts Creation:PSObject) [Remove-ManagementRoleEntry ], ParameterBindin…mationException + FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry + PSComputerName : outlook.office365.com

For some reason when running

Get-ManagementRoleEntry “Custom Role – Mail Contacts\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

It works fine but only leaves 2 cmdlets in there instead of the 4 you are showing. I basically need working script that enables a user to add and remove mail contacts in the ECP, that’s it.

Excellent article and thank you for posting this. I’m having trouble with the following: Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | Remove-ManagementRoleEntry

The error I get multiple times is: Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “CustomBNSKMailContacts” to type “Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you specified in the Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value, and then try again. Parameter name: identity” + CategoryInfo : InvalidData: (CustomBNSKMailContacts:PSObject) [Remove-ManagementRoleEntry], ParameterBi ndin…mationException + FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry + PSComputerName : outlook.office365.com

Any ideas? Thanks in advance – John

I know I’m a year late, but just in case anyone else comes across this same problem.

The syntax for that command needs to look like the below (using your example):

Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($_.id)\$($_.name)”}

Not sure if this was an error in the article or an Exchange vs EOL thing, or just something Microsoft have changed since, but hey.

Slight error in your script. Missing an *.

Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “*MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($_.id)\$($_.name)”}

thx for your post !

Hi Paul, I am a great fan of your articles – you save my a.. many times :). I try to find something, hope can help me with this. I need to understand what rights or group in RBAC – Exchange 2010 – give rights to user to change user account photo. Thumbnail photo I think is name of attribute.

Is I can see it, it’s possible to possible to limit 2: nd level support to only create/change users is specific OU, is it also possible to limit them to a specified DB? – we have all our users in site-specific databases.

Did this, and works great for write scopes, but why on god’s green earth can’t I seem to find a way to limit read scopes?

Does view only permission group members actually need a account with license on office 365 ?

Thanks Paul,

Very helpful article.

One question – is it possible to create a custom group from blank and only add the permissions you require, or is modification by removal from an existing group the only way?

Is there any role only can change user mailbox quota?

Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.

You can create a custom role for that.

Great writeup,

I’m looking to delegate ONLY certain functions to a specific group at my organization; We want them to be able to modify quotas, mailbox delegates, and e-mail addresses, but you don’t appear to be able to do that without a high level of control (or at least it doesn’t appear in the limited ECP).

Is there a way to give the same “view” as full admins for mailbox objects only?

I don’t understand your question. RBAC lets you control granular admin access all the way down to specific cmdlets and parameters of cmdlets. You can create custom roles to allow as much or as little admin access as necessary.

Dear Paul Cunningham, There are three OU into exchange 2016. When I user of any OU login in CEP, he can see all recipients of all OU but I want that “A user will only see his own OU recipients login exchange 2016 ecp” is it possible ?

i want to remove “wipe mobile device” permission from role My test role doesn’t contains clear-mobiledevice command but i can choose this option. Which role entry related with wipe mobile device?

My test role entries:

Set-CASMailbox Get-MobileDevice New-PartnerApplication Test-ClientAccessRule Set-ClientAccessRule New-ClientAccessRule Get-CASMailboxPlan Set-PartnerApplication Export-AutoDiscoverConfig Get-ActiveSyncDeviceAccessRule Get-ActiveSyncDeviceClass Get-ActiveSyncOrganizationSettings Get-ClientAccessArray Get-DomainController Get-OutlookProvider Get-RpcClientAccess New-ActiveSyncDeviceAccessRule New-OutlookProvider New-RpcClientAccess Remove-ClientAccessArray Remove-OutlookProvider Remove-RpcClientAccess Set-ActiveSyncDeviceAccessRule Set-RpcClientAccess Write-AdminAuditLog New-AuthRedirect Set-AuthRedirect Remove-AuthRedirect Get-AuthRedirect New-ClientAccessArray New-AuthServer Remove-AuthServer Set-AuthServer Get-PartnerApplication Set-AuthConfig Set-ClientAccessArray Get-ClientAccessRule Get-CASMailbox Get-AuthServer Get-AuthConfig Set-OutlookProvider Remove-ClientAccessRule Get-ActiveSyncDevice Remove-PartnerApplication Start-AuditAssistant Set-UnifiedAuditSetting Set-SweepRule Set-MailboxLocation Remove-SweepRule Remove-MailboxUserConfiguration Remove-MailboxLocation New-SweepRule Import-RecipientDataProperty Get-UnifiedAuditSetting Get-SweepRule Get-RbacDiagnosticInfo Get-OnlineMeetingConfiguration Get-MobileDeviceStatistics Get-MailboxUserConfiguration Get-MailboxPreferredLocation Get-MailboxLocation Enable-SweepRule Disable-SweepRule Add-MailboxLocation SetUserPhoto

i have a little bit extra for you excellent blog post. Thank you so much. Why this? When you use the role View-Only Recipients, you see to much of ecp functions from exchange. We reduce the view to the most necessary.

New-ManagementRole -Parent “View-Only Recipients” -Name “Custom Role – View-Only Recipients”

Get-ManagementRoleEntry “Custom Role – View-Only Recipients\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

I have not found a option to add more than one role to the custom view

Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-OrganizationalUnit” Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Recipient” Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Contact”

Now you have only 4 roles

Get-Contact Get-OrganizationalUnit Get-Recipient Get-MailContact

that is all!

Can you help with my above problem running Exchange 2016? I am unable to set the Write Scope to a specific OU. Please see above comments from me.

Problem was sorted out by upgrading from CU7 to CU8

Not working in Exchange 2016. Getting error when applying the role group to the Contacts OU as write scrope:

“Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”

Can you help?

What command are you running?

I am doing from the ECP. According to your guide, I set the Write Scope to a specific OU where we have got the contacts, and then the ECP throws above error.

The corresponding command would be something like:

New-RoleGroup -Name “Mail Contacts Manager” -RecipientOrganizationalUnitScope Contacts -Roles “Custom – Mail Contacts”, “Custom – Mail Contacts Creation” -Members contactadmin

Are you using the full path to the OU?

Yes. Using the Full path in ECP, it sees the OU, otherwise it would say it does not exist.

Ok. I haven’t seen the issue. Maybe there’s an ambiguous OU name causing problems or something like that. Perhaps running the command in the shell will work better.

I know it has been a while, but I just came across this same error:

“Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”

What I had to do was create it with the Write Scope set to Default, save it, then I could come back and change the write scope to an Organizational Unit.

Hope this helps someone in the future.

Thank you. This worked for me.

Perfect! Worked for me too

Awesome! Worked for me.

From ECP Create the Role with Default Scope. After it is created in 2nd Step Add the required OU. Worked for me .

Hey Poul, wonderfull article and really nicely written.

I have tried deploying this setup in our test/QA enviroments but i run into a error when the user needs to select the ou upon contact creation. I looks to me like there is some role/permission needed, if a user should be granted access to navigate the AD (so they can select the right ou which they are allowed to write to)

When the user tries to browse the AD, they are informed that they do not have permission to browse the ad, and the progress circle just keeps spinning.

Have you seen this problem before?

Leave a Reply Cancel reply

Latest articles.

Practical Sentinel: Ingesting Networking Data in Microsoft Sentinel

In this episode of Practical Sentinel, Thijs describes the different ingestion methods, how to choose the best method, and advises how to filter the ingested data.

Copilot for Microsoft 365: Datacenter Investments, Customer Spend, and Black Hat Exploits

Market analysts question if companies like Microsoft will ever generate a return on their AI investment. That hasn't stopped Microsoft spending $19 billion in FY24 Q4, so they must be hopeful. Meanwhile, at Black Hat USA 2024, a presentation exploring some vulnerabilities in Copilot should make all Microsoft 365 tenants with Copilot consider how to secure their organization better.

Crowdstrike Fallout, OneDrive Changes, and Planner Gets Copilot: The Practical 365 Podcast S4 E24

On this week's episode of the Practical 365 Podcast, Steve and Paul discuss the Crowdstrike outage, important changes coming to OneDrive for Business, Copilot for Planner Preview, and more!

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

• Whitepapers
• Write for Us!
• Cloud Computing
• Virtualization
• all Topics...

Lead Image © Isaac Marzioli, 123RF.com

Hands-on Exchange rights management

Rigorous rights.

Starting with Exchange 2013, Microsoft changed its messaging server to role-based access control (RBAC). Among other things, this approach makes it easier for Windows administrators to manage user rights.

Two types of roles can be assigned: end user and administrator. Administrator roles include permissions that can be assigned to administrators who manage a particular area of the Exchange organization. If a user is a member of several role groups, Exchange grants the user the privileges of these groups.

End-user roles begin with a prefix of My . For example, members of the MyDistributionGroups user role are allowed to create their own distribution groups and delete their own groups. This is not always desirable in an enterprise environment. By modifying the permissions, you can revoke these rights for normal users. The easiest way is to create a new role based on the existing MyDistributionGroups user role, then revoke the rights and assign the role to your users.

For existing role groups, whether administrative or end-user, you can add or remove roles and add or remove members.

When you copy a role group, you create a new name and optionally add or remove roles to the new group, all without affecting the original role group.

For standard groups, it makes sense to make copies before you change the groups.

In Exchange Server 2013, the administrative role groups are located in the Permissions area. The Get-RoleGroup commandlet (cmdlet) lets you check out the various groups in the management shell. Get-RoleGroupMember shows the members of a group (e.g., Get-RoleGroupMember "Organization Management" ). To add a user to a group, you can use the Exchange Management Console ( Figure 1 ) or the Exchange Management Shell:

To remove members from a management role group, you also use the Exchange Management Console or issue the following Exchange Management Shell cmdlet:

If you click on a group in the management console, you can see on the right-hand side which rights the group has and which members are assigned to it. To add a user to a group, double-click the group. You can then add new Members or removing existing ones.

Management roles summarize the cmdlets used to manage Exchange components ( Figure 2 ). Users who are members of a management role group are allowed to use the cmdlets stored in the administrative roles, which in turn are part of the management role groups.

Delegating Maintenance

Management role group substitutes can add or remove members from management role groups and modify the properties of a role group, but they do not have the right to use the functions of the management role group themselves.

The substitute configuration is handled by the ManagedBy option in the Set-RoleGroup or New-RoleGroup cmdlets. If you want to assign the user the rights to the group as well, you need to include them as a member of the role group. The ManagedBy option for the Set-RoleGroup cmdlet always overwrites the entire managed-by list for a role group.

To add individual substitutes to a role group without deleting the entire proxy list, you must save existing members, add the new member, and then save the list again ( Figure 3 ):

1. $RoleGroup = Get-RoleGroup "<management role group>" saves the role group settings in a variable.

2. $RoleGroup.ManagedBy += <Get-User mailbox to add>.Identity adds the substitute to the role group you saved as a variable in step 1. To add a universal group, use the Get-Group cmdlet.

3. Repeat step 2 for each substitute you want to add.

4. Set-RoleGroup "<management role group>" -ManagedBy $RoleGroup.ManagedBy adds the list of variables to the real management role group.

To view the users who are allowed to manage the group, you can use the cmdlet:

In addition to the default groups, you can create your own management role groups and assign users to them. New management role groups are created with the New-RoleGroup cmdlet ( Listing 1 ).

New Management Role Group

If you want to create role groups that apply limited rights, you can copy existing role groups. Again, it is best to use the Exchange Management Shell for the copy.

In the first step, save the role group in a variable:

To create a new role group, add the role group members and define who can delegate the new role group to other users with:

For example, you can copy the Organization Management role group with

to create a new group with fewer rights.

RBAC Manager

If you want a more convenient management option, the RBAC Manager [1] is your choice. It requires no installation and comprises a single EXE file and an XML control file. If the Exchange Management Tools are installed on a workstation, you can use RBAC Manager on a workstation ( Figure 4 ).

RBAC Manager lets you manage management roles, management role assignment policies, and management groups. Once the program is started, you can type the name of the server with which you want to connect and your credentials. Subsequently, the RBAC Manager connects to the Exchange organization and uses the logged-in user's rights. You have to install .NET Framework 3.5 on the server.

On Windows Server 2012, you can use the Server Manager for this. In the upper area, you can switch between managing management roles, assignment policies, management role groups, and management scopes. Role Groups let you manage the members, management roles, and role assignments.

You can create your own role groups or modify existing ones. RBAC Manager saves the changes to a logfile, which you can access from the Tools menu. In the logfile, you can see the PowerShell cmdlet that RBAC Manager uses to handle configuration tasks.

Monitoring the Management of Role Groups

In the Exchange Management Console, you can see who has made changes to the rights – that is, who has assigned administrator rights to other users – by:

• selecting Compliance management | Auditing | Run an administrator role group report ,
• choosing the role group you want to monitor, and clicking Search .

In the window, you will see all the changes. In the Exchange Management Shell, you can view the administrators and their permissions. The GetEffectiveUsers option for the Get-ManagementRoleAssignment cmdlet shows you the rights:

Use the call

to view a specific user, or use

if you want to view all the management roles for a user.

1 2 3 Next »

Buy ADMIN Magazine

US / Canada

UK / Australia

Related content

Subscribe to our ADMIN Newsletters Subscribe to our Linux Newsletters Find Linux and Open Source Jobs

Most popular.

• Secure microservices with centralized zero trust
• Discover vulnerabilities with Google Tsunami
• Security analysis with Security Onion
• Pentest your web server with Nikto
• Passkeys eliminate the need for password-based authentication

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

How To Add Or Remove Cmdlet Parameter From RBAC Management Role

In the previous posts on RBAC we have looked at customising various roles to ensure that the role contained the minimum amount of cmdlets.  RBAC provides even more granularity, and we can add or remove specific parameters from a cmdlet.  Since some folks asked for examples on this topic here are a couple of quick examples and some considerations….

If you want to use ECP, please read all the way down to the bottom.  The initial examples will work with the Exchange Management Shell but there are a couple of extra considerations for ECP.

Setting The Stage

As a scenario, let’s invent a crappy work task that some unlucky person could be asked to perform.  Let’s say there is a mobile phone management team within a large business and their sole responsibility is to assign mobile phones and numbers to people.  As part of this they need to be able to update the MobilePhone property of all users.  They should not be  able to modify any other attributes at all.

The cmdlet that we want is Set-User   and the MobilePhone parameter.

Locate The Cmdlets

This section builds and creates the custom RBAC role that we will use.  Firstly lets see where the relevant cmdlets and parameters live!

We can use the Get-ManagementRole cmdlet to see where the cmdlet lives using the -Cmdlet and -CmdletParameters respectively.  Below we can see where both the Set-User and MobilePhone exist:

Since the Set-User with the MobilePhone parameter exists in the Mail Recipients role, let’s use that role.  As before the built-in roles are read only and we cannot make any changes to them.  So we need to make a copy of the role, and since this copy is writable we can make the necessary changes.  Our custom role will be called Mobile-Phone-Jockeys .

If we check the contents of our new Management Role, we will see that it contains all the cmdlets and parameters present in the original parent role – not surprising since it was a copy….

We need to remove all the cmdlets that we do not want, so the quickest way to do this is to get a list of cmdlets that do not match Get-User and then once we check the list, remove them.

Note: Always check the objects returned are as expected prior to piping to the remove cmdlet!

So in this case we would run:

Only when we are happy with what is returned should we run:

If we check to see what’s now in the Mobile-Phone-Jockeys Role, it only contains the Get-User cmdlet.

Add A Single Parameter

At this point the Get-User cmdlet is the only entry left in the Management Role.

Let’s add back the Set-User cmdlet, with *ONLY* the ability to set the MobilePhone parameter, and the identity parameter.

This is a great example of adding in a specific parameter, when the cmdlet did not already exist.

If you are wondering about the Identity parameter that is also present with MobilePhone , keep reading!

Add Multiple Parameters

Taking the example above we could have specified multiple parameters in the same command.  if we deviate from the example above slightly and pretend that our Mobile-Phone-Jockey role has now become responsible for also assigning office phones then they need to also set the Phone attribute.  You can specify multiple parameters, separated with commas.

Changing Existing Parameters

If we want to go about modifying a cmdlet’s list of parameters, a good guess would be that we would use the Add-ManagementRoleEntry or Remove-ManagementRoleEntry but neither will do what we need.  They just add or remove the entire Management Role Entry.  In the case of changing the available parameters on an existing role entry we need to use the Set-ManagementRoleEntry cmdlet.  Its Parameters switch has the following modes:

• When used with the AddParameter parameter, the parameters you specify are added to the role entry.
• When used with the RemoveParameter parameter, the parameters you specify are removed from the role entry.
• When neither the AddParameter nor RemoveParameter parameters are used, only the parameters you specify are included in the role entry. If you specify a value of $Null and neither the AddParameter nor RemoveParameter parameters are used, all of the parameters on the role entry are removed.

So if we want to remove all parameters from the Set-User cmdlet apart from MobilePhone and Identity we could run:

An alternative would have be to remove just the Phone parameter:

The end result is the same in this case, and you can choose the  method that makes the most sense!

Want To Live Like Common People

< Common People courtesy of Pulp >

One interesting thing to note is that when we try to prune out the parameters that we do not want, the common ones should typically be left.  They are needed to ensure that we can perform the basic aspects of the cmdlet.  This includes parameters like WhatIf, DomainController or Verbose.  None of these apply changes to a mailbox or user, but they allow us to control how the operation is performed.

Trying to see them can be a little tricky.  Look at the truncated display here indicated by the three periods:

To review all the parameters present in a Management Role Entry I like to do the following:

$Params.Parameters  will output the entire content of the attribute to the screen. If we split the  output to see what parameters are the common ones and what are specific to the Set-User cmdlet we will see:

Specific Parameters

AssistantName, CertificateSubject, City, Company, CountryOrRegion, Department, DisplayName, Fax, FirstName, HomePhone, Initials, LastName, Manager, MobilePhone, Name, Notes, Office, OtherFax. OtherHomePhone, OtherTelephone, Pager, Phone, PhoneticDisplayName, PostalCode, PostOfficeBox,  ResetPasswordOnNextLogon, SamAccountName, SeniorityIndex, SimpleDisplayName, StateOrProvince,  StreetAddress, TelephoneAssistant, Title, UserPrincipalName, WebPage, WindowsEmailAddress

Common Parameters

Confirm, Debug, DomainController, ErrorAction, ErrorVariable, Identity, IgnoreDefaultScope, LinkedCredential, LinkedDomainController, LinkedMasterAccount, OutBuffer, OutVariable, RemotePowerShellEnabled, Verbose, WarningAction, WarningVariable, WhatIf

Why is this worth mentioning, well if the necessary common parameters to run cmdlet are not present then it does not run, savvy?

If Identity is not specified for the Set-User cmdlet then you are going to see this fun error:

The operation couldn't be performed because object 'test-6' couldn't be found on 'exch-dc.tailspintoys.com'. + CategoryInfo          : NotSpecified: (0:Int32) [Set-User], ManagementObjectNotFoundException + FullyQualifiedErrorId : 98454A26,Microsoft.Exchange.Management.RecipientTasks.SetUser

Why can we not find the account? It is clearly there as we can see with the first command Get-User.

The identity parameter is not present on the Set-User cmdlet in the custom Management Role. This can be a little confusing as we can type "Set-user -Identity" so where is the Identity parameter coming from?   Note that the –identity parameter is visible since it is present within the Role Assignment Policy.  Role Assignment Policy is just for end user RBAC and is scoped to the individual user thus it cannot be used to modify other users. When we want to modify a user account that is not our own the Role Assignment Policy does not apply as it does not fall within  the scope of 'SELF", and we look to the other Management Role which is Mobile-Phone-Jockeys in this case.  Since Mobile-Phone-Jockeys does not have the Identity parameter the command fails to change the properties of user account Test-6".

Morale of the story?  Be sure to include the necessary common parameters else you will get some “interesting” results…

Testing time, and arguable the most important section!!   Let’s assign the Mobile-Phone-Jockeys management role to a test user called User-15.

And to confirm the Mobile-Phone-Jockeys management role contains:

Testing via Exchange Management Shell on User-15’s Windows 7 x64 desktop shows that RBAC is working and they can modify the Mobile number for a separate user (Test-6):

Happy days?  Well almost…

You think you are done, and the testing was OK.  But then you get a call saying that  ECP cannot be used, as the option to view other mailboxes is not present.  Huh?  Are the permissions not correct?  Permissions are correct as we tested them, so what gives?  This is what User-15 sees in ECP, note there is no Manage My Organization option along the top, and the shortcut on the right pane does not take us their either.  The shortcut has this link:

https://mail.tailspintoys.com/ecp/PersonalSettings/HomePage.aspx?showhelp=false&#

How to fix this? We need to make ECP display the Manage My organization option.  We do this by adding cmdlet(s) that will force the option to be displayed, and the in this case we will add Get-Mailbox and Get-Recipient .  Lets add them in:

With the modified Management Role Entries, User-15 now sees:

Note that the Manage My Organization is visible, and so are the mailboxes in the organization. The shortcut to Manage your organization link now takes us to the organization management page in ECP .

Double clicking to edit one shows that that User-15 has the permissions to edit the Mobile Phone field as it is not locked out.  Fields in grey are locked out.

Concluding Thoughts

We can see that RBAC allows for a great deal of customisation, right down to the individual parameters that are available!  This is an amazing amount of flexibility, and there is one glaring thing that should be striking Exchange 2003 and 2007 admins at this point.  Did we change a single ACL to the objects in AD?  NO!  Not a single one.  We focussed on the business requirement, which was to allow the phone team to update the mobile number assigned to users, and did not have to think about ACLs.  This is a huge win as having to get change records cut to modify AD ACLs is a challenge.

This is made possible by the Exchange Trusted Subsystem universal security group as it is that group that has the permissions to the AD objects.  RBAC enforces and controls the cmdlets and parameters that you can see and thus use thereby controlling what changes are made to the Exchange objects.

Rhoderick Milne [MSFT]

Leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

How do I remove Azure role assignments with PowerShell?

I currently have a function app that is using RBAC and am trying to update the permissions. I am trying to run an Azure PowerShell command that will remove the role assignments, so I can then assign a new role.

Which results in:

I have also tried:

I don't have permissions to remove a role assignment manually and have to do it through a pipeline job. However, I'm not sure which cmdlet/parameters are needed to pass in. Am I missing information, using a wrong module?

• azure-devops
• azure-pipelines
• azure-powershell

The objectId parameter of remove-AzRoleAssignment is meant to identify a user, security group or service principal, not the role as is shown in your example code.

-ObjectId Azure AD ObjectId of the user, group or service principal.

Next to this:

Use the Remove-AzRoleAssignment commandlet to revoke access to any principal at given scope and given role. The object of the assignment i.e. the principal MUST be specified. The principal can be a user ( use SignInName or ObjectId parameters to identify a user ), security group (use ObjectId parameter to identify a group) or service principal (use ServicePrincipalName or ObjectId parameters to identify a ServicePrincipal. The role that the principal is assigned to MUST be specified using the RoleDefinitionName parameter .

More information: Remove-AzRoleAssignment

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged powershell azure-devops azure-pipelines azure-powershell or ask your own question .

• The Overflow Blog
• Scaling systems to manage all the metadata ABOUT the data
• Navigating cities of code with Norris Numbers
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• Tag hover experiment wrap-up and next steps

Hot Network Questions

• Sharing course material from a previous lecturer with a new lecturer
• What's the polarity of this electrolytic capacitor symbol?
• Suitable tool bag for vintage centre pull rim brake bike
• How can I obscure branding on the side of a pure white ceramic sink?
• Specified data directory does not exist - but it does
• Someone wants to pay me to be his texting buddy. How am I being scammed?
• Package 'gettext' has no installation candidate, but package exists
• Why didn't Walter White choose to work at Gray Matter instead of becoming a drug lord in Breaking Bad?
• Should I pay off my mortgage if the cash is available?
• Isn't an appeal to emotions in fact necessary to validate our ethical decisions?
• Generating a normally distributed variable using a known range, but an unknown mean, in R
• To what extent do value sets determine polynomials mod p?
• What is the lowest feasible depth for lightly-armed military submarines designed around the 1950s-60s?
• A burning devil shape rises into the sky like a sun
• Short story in which in which "aliens" from the future appear at a man's door
• Short story about a committee planning to eliminate 1 in 10 people
• "Undefined" when attempting analytical expression for a RegionIntersection and its Area in V14.0
• the helper fuctions for a url shortener
• How can we objectively measure the similarity between two scatter plots whose coordinates are known?
• Is groff ignoring `.nh` command?
• Returning to France with a Récépissé de Demande de Carte de Séjour stopping at Zurich first
• Why did Borland ignore the Macintosh market?
• Argument of Complex Numbers with unknown values
• Why would luck magic become obsolete in the modern era?

Get the Reddit app

Microsoft Exchange Server subreddit. Post blog posts you like, KB's you wrote or ask a question. Open forum for Exchange Administrators / Engineers / Architects and everyone to get along and ask questions.

2019 Reset Password role troubles

Little back story, I’m trying to enable the mailbox for a room. This is for a Surface Hub 2S device account. I’m trying to run Set-Mailbox -EnableRoomMailboxAccount and have to supply the password.

The problem is even though I’m in the organization management security group I don’t have the reset password roll. Four Exchange 2013/2016 I see mention of running Install-DefaultRBAC but that doesn’t seem to work and I can’t add the Reset Password role to the Organzation Managment role. Has anyone else run into this? i can post the exact errors tomorrow.

By continuing, you agree to our User Agreement and acknowledge that you understand the Privacy Policy .

Enter the 6-digit code from your authenticator app

You’ve set up two-factor authentication for this account.

Enter a 6-digit backup code

Create your username and password.

Reddit is anonymous, so your username is what you’ll go by here. Choose wisely—because once you get a name, you can’t change it.

Reset your password

Enter your email address or username and we’ll send you a link to reset your password

Check your inbox

An email with a link to reset your password was sent to the email address associated with your account

Choose a Reddit account to continue

Office 365 - Cannot Grant Permission To Manage Address Lists

So I’m trying to segment the GAL in O365 and I’m unable to assign the required permission to manage the address list. I get the following error:

“You don’t have access to create,change, or remove the “ mydomain.onmicrosoft.com \Address Lists-GAL Management” management role assignment. You must be assigned a delegating role assignment to the management role or its parent in the hierarchy without a scope restriction.”

First is that I’m not trying to manage the ‘.onmicrosoft.com’ domain, I’m trying to manage my own domain. Second, I’ve checked around and seen this fix recommended at least a dozen places:

Add-pssnapin Microsoft*

Install-CannedRbacRoles

Install-CannedRbacRoleAssignments

I’m able to run the first command ok, but the second and third commands return this error:

“The term ‘Install-CannedRbacRoles’ is not recognized as the name of a cmdlet, function, script file, or operable program”

I tried adding a custom write scope hoping it would refer to may domain but returns the same error about the .onmicrosoft.com domain. I’ve tried with different admin accounts, including the main/default admin account. I’ve also tried editing existing role assignements but no matter what those two errors are stopping me from creating a new custom address list in the GAL.

Any advice? Thank you!

Well, now I’m making things worse. I tried to edit the Organization Management admin role using the new custom scope I created and now when you try to edit it, it says:

“Roles were assigned to this role group using multiple write scopes or exclusive write scopes. Therefore, you can’t view the write scope or manage the assigned roles here.”

…which I get, because I did indeed do that. Any way to uh… undo that?

For further information, I already upgraded our subscription plan to Small Business Premium. I do have the Address List role, it just won’t let me assign it. To ANYONE. No. Matter. What.

Related Topics

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

New-Management Role Assignment

This cmdlet is available in on-premises Exchange and in the cloud-based service. Some parameters and settings may be exclusive to one environment or the other.

Use the New-ManagementRoleAssignment cmdlet to assign a management role to a management role group, management role assignment policy, user, or universal security group (USG).

For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax .

Description

When you add a new role assignment, you can specify a built-in or custom role that was created using the New-ManagementRole cmdlet and specify an organizational unit (OU) or predefined or custom management scope to restrict the assignment.

You can create custom management scopes using the New-ManagementScope cmdlet and can view a list of existing scopes using the Get-ManagementScope cmdlet. If you choose not to specify an OU, or predefined or custom scope, the implicit write scope of the role applies to the role assignment.

For more information about management role assignments, see Understanding management role assignments .

You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet .

This example assigns the Mail Recipients role to the Tier 2 Help Desk role group.

This example assigns the MyVoiceMail role to the "Sales end-users" role assignment policy. First, the IsEndUserRole property on the MyVoiceMail role is verified to be sure it's set to $true, indicating it's an end-user role.

After the role has been verified to be an end-user role, the role is assigned to the "Sales end-users" role assignment policy.

This example assigns the Eng Help Desk role to the Eng HD Personnel role group. The assignment restricts the recipient write scope of the role to the contoso.com/Engineering/Users OU. Users who are members of the Eng HD Personnel role group can only create, modify, or remove objects contained within that OU.

This example assigns the Distribution Groups role to the North America Exec Assistants role group. The assignment restricts the recipient write scope of the role to the scope specified in the North America Recipients custom recipient management scope. Users who are members of the North America Exec Assistants role group can only create, modify, or remove distribution group objects that match the specified custom recipient management scope.

This example assigns the Exchange Servers role to John. Because John should only manage the servers running Exchange located in Sydney, the role assignment restricts the configuration write scope of the role to the scope specified in the Sydney Servers custom configuration role group. John can only manage servers that match the specified custom configuration management scope.

This example assigns the Mail Recipients role to the Executive Administrators role group. The assignment restricts the recipient write scope of the role to the scope specified in the Exclusive-Executive Recipients exclusive recipient management scope. Because the Exclusive-Executive Recipients scope is an exclusive scope, only users of the Executive Administrators can manage the executive recipients that match the exclusive recipient scope. No other users, unless they're also assigned an assignment that uses an exclusive scope that matches the same users, can modify the executive recipients.

This example assigns the Mail Recipients role to the Contoso Sub - Seattle role group. The administrators in this role group should only be allowed to create and manage mail recipients in specific databases that have been allocated for use by the Contoso subsidiary, A. Datum Corporation (adatum.com). Also, this group of administrators should only be allowed to manage the Contoso employees located in the Seattle office. This is done by creating a role assignment with both a database scope, to limit management of mail recipients to only the databases in the database scope and a recipient OU scope, to limit access to only the recipient objects within the Contoso Seattle OU.

This parameter is available only in the cloud-based service.

The App parameter specifies the service principal to assign the management role to. Specifically, the ObjectId GUID value from the output of the Get-ServicePrincipal cmdlet (for example, 6233fba6-0198-4277-892f-9275bf728bcc).

For more information about service principals, see Application and service principal objects in Microsoft Entra ID .

You can't use this parameter with the SecurityGroup, Policy, or User cmdlets.

This parameter is available only in on-premises Exchange.

The Computer parameter specifies the name of the computer to assign the management role to.

You can't use this parameter with the SecurityGroup, User, or Policy parameters.

The Confirm switch specifies whether to show or hide the confirmation prompt. How this switch affects the cmdlet depends on if the cmdlet requires confirmation before proceeding.

• Destructive cmdlets (for example, Remove-* cmdlets) have a built-in pause that forces you to acknowledge the command before proceeding. For these cmdlets, you can skip the confirmation prompt by using this exact syntax: -Confirm:$false .
• Most other cmdlets (for example, New-* and Set-* cmdlets) don't have a built-in pause. For these cmdlets, specifying the Confirm switch without a value introduces a pause that forces you acknowledge the command before proceeding.

-CustomConfigWriteScope

The CustomConfigWriteScope parameter specifies the existing configuration scope to associate with this management role assignment. If you use the CustomConfigWriteScope parameter you can't use the ExclusiveConfigWriteScope parameter. If the management scope name contains spaces, enclose the name in quotation marks (").

-CustomRecipientWriteScope

The CustomRecipientWriteScope parameter specifies the existing recipient-based management scope to associate with this management role assignment. If the management scope name contains spaces, enclose the name in quotation marks ("). If you use the CustomRecipientWriteScope parameter, you can't use the RecipientOrganizationalUnitScope or ExclusiveRecipientWriteScope parameters.

-CustomResourceScope

The CustomResourceScope parameter specifies the custom management scope to associate with this management role assignment. You can use any value that uniquely identifies the management scope. For example:

• Distinguished name (DN)

If the value contains spaces, enclose the value in quotation marks (").

You use this parameter with the App parameter to assign permissions to service principals. For more information, see For more information about service principals, see Application and service principal objects in Microsoft Entra ID .

-Delegating

The Delegating switch specifies whether the user or USG assigned to the role can delegate the role to other users or groups. You don't need to specify a value with this switch.

-DomainController

The DomainController parameter specifies the domain controller that's used by this cmdlet to read data from or write data to Active Directory. You identify the domain controller by its fully qualified domain name (FQDN). For example, dc01.contoso.com.

-ExclusiveConfigWriteScope

The ExclusiveConfigWriteScope parameter specifies the exclusive configuration-based management scope to associate with the new role assignment. If you use the ExclusiveConfigWriteScope parameter, you can't use the CustomConfigWriteScope parameter. If the scope name contains spaces, enclose the name in quotation marks (").

-ExclusiveRecipientWriteScope

The ExclusiveRecipientWriteScope parameter specifies the exclusive recipient-based management scope to associate with the new role assignment. If you use the ExclusiveRecipientWriteScope parameter, you can't use the CustomRecipientWriteScope or RecipientOrganizationalUnitScope parameters. If the scope name contains spaces, enclose the name in quotation marks (").

The Force switch hides warning or confirmation messages. You don't need to specify a value with this switch.

You can use this switch to run tasks programmatically where prompting for administrative input is inappropriate.

The Name parameter specifies a name for the new management role assignment. The maximum length of the name is 64 characters. If the management role assignment name contains spaces, enclose the name in quotation marks ("). If you don't specify a name, one will be created automatically.

The Policy parameter specifies the name of the management role assignment policy to assign the management role to. If the value contains spaces, enclose the value in quotation marks (").

The IsEndUserRole property of the role you specify using the Role parameter must be set to $true.

You can't use this parameter with the App, SecurityGroup, Computer, or User parameters.

-RecipientAdministrativeUnitScope

This parameter is functional only in the cloud-based service.

The RecipientAdministrativeUnitScope parameter specifies the administrative unit to scope the new role assignment to.

Administrative units are Microsoft Entra containers of resources. You can view the available administrative units by using the Get-AdministrativeUnit cmdlet.

-RecipientGroupScope

The RecipientGroupScope parameter specifies a group to consider for scoping the role assignment. Individual members of the specified group (not nested groups) are considered as in scope for the assignment. You can use any value that uniquely identifies the group: Name, DistinguishedName, GUID, or DisplayName.

-RecipientOrganizationalUnitScope

The RecipientOrganizationalUnitScope parameter specifies the OU to scope the new role assignment to. If you use the RecipientOrganizationalUnitScope parameter, you can't use the CustomRecipientWriteScope or ExclusiveRecipientWriteScope parameters. To specify an OU, use the syntax: domain/ou. If the OU name contains spaces, enclose the domain and OU in quotation marks (").

-RecipientRelativeWriteScope

The RecipientRelativeWriteScope parameter specifies the type of restriction to apply to a recipient scope. The available types are None, Organization, MyGAL, Self, and MyDistributionGroups. The RecipientRelativeWriteScope parameter is automatically set when the CustomRecipientWriteScope or RecipientOrganizationalUnitScope parameters are used.

Even though the NotApplicable, OU, MyDirectReports, CustomRecipientScope, MyExecutive, MailboxICanDelegate and ExclusiveRecipientScope values appear in the syntax block for this parameter, they can't be used directly on the command line. They are used internally by the cmdlet.

The Role parameter specifies the existing role to assign. You can use any value that uniquely identifies the role. For example:

If you use the App parameter, you can't specify admin or user roles; you can only specify application roles (for example, "Application Mail.Read").

-SecurityGroup

The SecurityGroup parameter specifies the name of the management role group or mail-enabled universal security group to assign the management role to. If the value contains spaces, enclose the value in quotation marks (").

You can't use this parameter with the App, Policy, Computer, or User parameters.

-UnScopedTopLevel

By default, this parameter is available only in the UnScoped Role Management role, and that role isn't assigned to any role groups. To use this parameter, you need to add the UnScoped Role Management role to a role group (for example, to the Organization Management role group). For more information, see Add a role to a role group .

The UnScopedTopLevel switch specifies that the role provided with the Role parameter is an unscoped top-level management role. You don't need to specify a value with this switch.

Unscoped top-level management roles can only contain custom scripts or non-Exchange cmdlets. For more information, see Create an unscoped role .

The User parameter specifies the user to assign the management role to.

For the best results, we recommend using the following values:

• UPN: For example, [email protected] (users only).
• Domain\SamAccountName: For example, contoso\user .

You can't use this parameter with the App, SecurityGroup, Computer, or Policy parameters.

The WhatIf switch simulates the actions of the command. You can use this switch to view the changes that would occur without actually applying those changes. You don't need to specify a value with this switch.

Input types

To see the input types that this cmdlet accepts, see Cmdlet Input and Output Types . If the Input Type field for a cmdlet is blank, the cmdlet doesn't accept input data.

Output types

To see the return types, which are also known as output types, that this cmdlet accepts, see Cmdlet Input and Output Types . If the Output Type field is blank, the cmdlet doesn't return data.

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources