There are lots of great new features included with the Exchange 2010 SP1 beta. One of the new things that is really cool is the addition of Database Scopes. You can use Database Scopes with RBAC to control what type of access administrators have to your Exchange databases. I’ve been really impressed with everything that can be done with RBAC in the RTM version of Exchange 2010, and it gets even better in SP1. In this post, I’ll cover an example of how you might use a Database Scope with RBAC.
Scenario
Let’s say you manage a group of support staff that will be responsible for administering Exchange databases on mailbox servers in your Phoenix office. You need to allow these administrators to manage only the Exchange databases in the Phoenix office and they should not be able to modify databases on servers in other sites. In order to accomplish this, you can assign the support staff the built-in Databases role and use a Database Scope to limit their level of access.
Step 1: Create the Database Scope
There are two types of database scopes in SP1; database filter scopes and database list scopes. In this example, we’ll create a database filter scope. Only databases with the prefix of “PHX” will be available to the support staff:
As you can see in the above screen shot, you’ll receive a warning letting you know that this scope will only be applied to users connecting to Exchange servers running SP1.
Step 2: Create the Role Assignment
Next, you are ready to assign the role. Use the following command to assign the built-in Databases role to the “Phoenix DB Admins” security group. Notice that the CustomConfigWriteScope is set to the database scope we created in the first step:
Again, you’ll receive a warning letting you know that this assignment will only be applied to users connecting to Exchange servers running SP1.
Step 3: Testing it out
Now you are ready to test this out. Launch EMS as one of the members of the “Phoenix DB Admins” group. To keep it simple, just try to modify the deleted item retention for a database:
So, as you can see, the above commands work since the database name is prefixed with “PHX”. Now try modifying one of the databases in New York:
Now you get an error stating that the database is not within the users management scope…Mission accomplished.