What’s this RBAC in Exchange Server 2010 anyway? – Part 1

This is part one in my series of posts about Role Based Access Control. If you find an error of any sort, have any questions or thoughts about it please do not hesitate to drop a comment or contact me.

Role Based Access Control is the new way of handling user rights in Exchange Server 2010. Before RBAC you had to work with ACL and it could be quite tricky and hard to troubleshoot. With RBAC you can set wide or very specific rights for both administrators and end-users, enabling you to have more detailed control. You can set both administrative rights in Exchange server 2010 and you can give users the right to administer their own mailbox and distribution groups. First, let´s just take a look on the different components that RBAC consists off:

Component Explanation
Role holder Mailbox that is assigned to a role group
Management role group Universal security group for managing Exchange Server permissions
Management role Container for grouping other RBAC components
Management role entry Defines which Exchange Server cmdlets an administrator can run
Management role assignment Links the management role group to a management role
Management role scope Defines where the administrator can perform the tasks

There are two primary ways of assigning permissions to users, management role groups and management role assignment policies. We will start by looking at Management Roles, Management Role Entries and Management Role Types, they are fundamental to groups and policies.

Management Roles

Management roles is a way to logically group a number of cmdlets which makes it easier to identify the specific roles an administrator or user should have access to. One role can provide access to view or modify the configuration of Exchange 2010 components. For example mailboxes, transport rules, ActiveSync policies and recipients. These roles can be grouped together in to management role groups and management role assignment policies. We will look more at these two further on. Management roles can be assigned to role groups, role assignment policies and directly to users. The latter is not recommended though, assigning roles directly to users will most likely make you environment unnecessarily complex to administrate.

NOTE: End-user management roles can only be added to role assignment policies, not management role groups.

Built-in management roles

There is a large number of pre-made built-in management roles that will be enough for most scenarios and covers a lot of different areas of Exchange Server 2010. These roles can’t be changed or altered in anyway. You can however create your own management roles and include the built-in ones. A new management role can be changed but that is an advance procedure and not recommended. I will not cover that topic in this post but might add it later.

There are a large number of built-in management groups, here are some examples:

  • Mail Recipient Creation Role – Enables the right to create mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups
  • Move Mailboxes Role – enables administrators to move mailboxes between servers
  • Databases Role – enables the right to create, manage, mount, and dismount mailbox and public folder databases

A complete list of roles can be found here: http://technet.microsoft.com/en-us/library/dd638077(printer).aspx

Management Role Types

Management Role types defines the scope for management roles. It is divided into 3 different categories:

  • Administrative or specialist – Has a broad impact in the Exchange organization, Roles of this role type enable tasks such as server or recipient management, organization configuration, compliance administration, and auditing.
  • User-focused – User specific scope, enables user oriented tasks such as user profile configuration, self-management and management of user-owned distribution groups.
  • This type enables tasks such as application impersonation and the use of non-Exchange cmdlets or scripts.

There are numerous types to choose from, a couple of examples follow:

  • Databases – This role type is associated with roles that enable administrators to create, manage, mount, and dismount mailbox and public folder databases on individual servers. This type affects specific servers.
  • MailTips – Associated with roles that enable administrators to manage mailtips, affects the entire Exchange organization.

Unscoped Top Level Management Roles

With the use of Unscoped Top Level Management Roles you can control access to custom scripts and non-Exchange cmdlets for users. Since these rules have no parents that defines its content it is called Top Level and considered equal to built-in management roles. Unscoped roles always enable the user to do organization wide configurations. Granting a user this access will give him or her access to any object in the Exchange Server 2010 organization. These roles should be used with caution but they can be very useful. For example, you can create a script and include it in a role. When you assign that role to a user, he or she will be able to perform only the specific functions provided by the script.

Create an Unscoped Role

To create a new Unscoped Role:
New-ManagementRole <name of new role> –UnscopedTopLevel

Management Role Entries

Entries are the basic part of a Management Role. It is included in every role, without entries there would be no roles. An entry can be a cmdlet, permission or a script that you want to include in a role. Entries can be added or removed depending on what type of role you are editing. To add a script you need to use the previously mentioned Custom Management Role.

View Role Entries

To view a list of role entries on a specific role:
Get-ManagementRoleEntry <role name>\*

If you want to view the details of a single role entry:
Get-ManagementRoleEntry <role name>\<cmdlet name> | FL

There are plenty of more variations of the Get-ManagementRoleEntry command and information on this can be found here: http://technet.microsoft.com/en-us/library/dd351179.aspx

Add a Role Entry to a Role

To add entries to a role use this command:
Add-ManagementRoleEntry <child role name>\<cmdlet>

Again, there is more information that can be found here: http://technet.microsoft.com/en-us/library/dd335180.aspx

Change a Role Entry

To add parameters to a role entry use this command:
Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>, <parameter…> -AddParameter

To remove parameters from a role entry:
Copy Code Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>, <parameter…> -RemoveParameter

More information here: http://technet.microsoft.com/en-us/library/dd298005.aspx

Remove a Role Entry from a Role

You can of course remove an management role entry from a role:
Remove-ManagementRoleEntry <management role>\<management role entry>

And there is of course more information to this as well: http://technet.microsoft.com/en-us/library/dd297947.aspx

Custom Management Roles

When the built-in management roles aren’t enough you can create and configure custom management roles. These are based on built-in management roles and inherit all parent entries. You can change a custom management role to match your specific needs by removing inherited entries. Note that you can only use inherited entries. You cannot add other specific entries to a custom management role. I would not recommend the use of custom management roles unless it is absolutely necessary, they are quite complex. Built-in management roles will be enough for most scenarios.

Create a Custom Management Role Management Role Entry

Entries are the basic part of a Management Role. It is included in every role, without entries there would be no roles. An entry can be a cmdlet, permission or a script that you want to include in a role. Entries can be added or removed depending on what type of role you are editing. To add a script you need to use the previously mentioned Custom Management Role.

Unscoped Top Level Role Entries

When used with a Custom Management Role, an entry is called Unscoped Top Level Role Entry. There are a couple of things to consider when creating these entries.

  • All parameters for the entries needs to be specified, Exchange will try to verify these. Only specified Parameters will be available to the users.
  • Remember to update the role manually if you change any of the entries. Exchange does not update the role.
  • All scripts must be placed in the Exchange 2010 scripts directory (Default: C:\Program Files\Microsoft\Exchange Server\V14\Scripts).
  • Remember to install all Non-Exchange cmdlets on all servers. Also remember to add the Windows PowerShell snap-in name for the cmdlet.

Management Roles Summary

Management roles can be divided in a number of different parts:

  • Built-in Management Roles – represents a number of predefined roles that cannot be changed. Will cover most needs
  • Unscoped Top Level Management Roles – Controls access to custom scripts, permissions and non-exchange cmdlets, always organization wide.
  • Custom Management Roles – Based on Built-in Management Roles, inherited entries can be removed.

We also have two types of entries:

  • Management Role Entries – Included in every role, can be a cmdlet, permission or a script.
  • Unscoped Top Level Role Entry – Define all parameters, manual role update after changes.

Last but not least:

  • Management Role Types – Defines the affecting scope for management roles, three descriptive categories.

In my next post I will continue with Scopes, Management Role Groups and Management Role assignment Policies, thanks for reading!

Part 1 in this series can be found here!

Part 2 in this series can be found here!

Part 3 in this series can be found here!

Advertisements

Show and move “hidden” Arbitration mailboxes in Exchange Server 2010

So, let’s say you have a new installation of Exchange Server and you want to move all mailboxes, including Arbitration, from the default database created during the installation to a new mailbox database. Here is how to do it…
 
First of all, if you just try to delete the default database you will get this message:
 
DatabaseRemoveError
 
Stating that the database isn’t empty, even though it does look empty if you do a get-mailbox for the specific database:
get-mailbox -Database “Mailbox Database 1905367170”
 
DatabaseRemoveError2
 
There is a switch that you should use if you want to see all mailboxes, even the “hidden” Arbitration mailboxes:
get-mailbox -Database “Mailbox Database 1905367170” –Arbitration
 
This gives us different result then the first get-mailbox command:
 
DatabaseRemoveError3
 
As you can se the database isn’t as empty as we first thought. To move these mailboxes to the new database you can easily pipe the result of the get-mailbox command and create new move requests for all Arbitration mailboxes:
get-mailbox -Database “Mailbox Database 1905367170” -Arbitration | New-MoveRequest –TargetDatabase “MailboxDatabase1”
 
DatabaseRemoveError4
 
So, good luck with the moves and please let me know if you bump in to any problems, thanks for reading!

Update Rollup 3 for Exchange Server 2007 Service Pack 2

As usual you can find more information on the subject on Microsoft Support: http://support.microsoft.com/Default.aspx?kbid=979784

If you want to go straight to the download you can find it here: http://www.microsoft.com/downloads/details.aspx?FamilyID=c781326a-7b81-444d-9836-760fa1e3a28a&displaylang=en

Update Rollup 2 for Exchange Server 2010 RTM (KB 979611)

Microsoft has released Update Rollup 2 for Exchange Server 2010 RTM and it is available for download here: http://msexchangeteam.com/archive/2010/03/05/454155.aspx

A complete list can be found here: http://support.microsoft.com/?kbid=979611 and here are some of the improvements:

  • KB 977633 This fixes IMAP4 clients ability to log on to their mailboxes if the mailboxes are located on Exchange 2003 backend servers and if the clients are connecting via Exchange 2010 CAS servers.
  • KB 979480 IMAPid was not working correctly after moving a lot of users from one Exchange 2010 server to another*. IMAP4 users complained about the inbox not being updated any more. Old messages were still visible, but messages which were received after the mailbox move were not visible. The problem affected different IMAP Clients. The problem did not affect MAPI clients and OWA. Now it is fixed up. *(Specifically this occurred in the situation with same DAG, now local storage instead of iSCSI storage, all servers are Exchange 2010 with Update Rollup 1 installed on Windows Server 2008 R2).
  • KB 979431 When user migrated from Exchange Server 2003 to Exchange Server 2010, and that user connected via POP3, the POP3 service crashed. This was fixed up so it will not crash.
  • KB 979563 Push Notifications didn’t work because Exchange Server 2010 was not sending SOAPAction header in the notify callback. This caused Exchange to receive a HTTP 500 response from the notification client and the webservice failed. Push notifications should now properly send that SOAP header.
  • KB 980261 We fixed passive page patching when diagnostic tracing code was needed for forensic analysis that was generating a -1022 error case.
  • KB 980262 Source side log copier errors are more gracefully handled when the log has a bad block and the read fails.
  • KB 979566 Activesync proxy was failing for linked mailboxes in a CAS to CAS proxy scenario where the users token is serialized and sent in the request. When attempting to create the client security context from the SID, a AuthZException was thrown because we did not have access to the token information of the linked account, so now for this it no longer throws exceptions.
  • Exchange Server 2010 RTM VHD

    Finally Microsoft has released a VHD based on Exchange Server 2010 RTM. Well, it was actually released a couple of weeks ago but I have been busy so I missed it…

    Anyway, you can find it here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=53f7382a-3664-4de3-8303-31e514d69f02

    Exchange Server Pre-Deployment Analyzer Released

    Another great tool from Microsoft. You can use this tool to scan your environment before deploying Exchange Server.  It does an overall topology readiness scan which gives a detailed report of any issues within your organization that will prevent you from installing Exchange Server.

    Read more about ExPDA on the Microsoft Exchange Team Blog: http://msexchangeteam.com/archive/2010/02/24/454083.aspx

    And if you want to download ExPDA directly you can do so here: http://www.microsoft.com/downloads/details.aspx?FamilyID=88b304e7-9912-4cb0-8ead-7479dab1abf2&displaylang=en