I was working with a customer last week that is interested in deploying the RBAC split permissions model rather than the default shared permissions model that is used in Exchange 2010.  I just wanted to step through the configuration process in this article and also wanted to amplify an important point regarding permissions bypass found in the RBAC split permissions deployment instructions on TechNet.

Let's first take the scenario of a default installation that uses shared permissions.  In my lab environment, my user account has been delegated the Exchange Organization management role.  As a result of these permissions, I can elect to perform some Active Directory related tasks within the Exchange Management Shell or Exchange Management Console such as the deleting of Active Directory user accounts when deleting the corresponding mailbox.  For example, in Figure 1 below you can see that I have the ability to perform the Remove command when right-clicking a mailbox in the Exchange Management Console; this in turn also removes the Active Directory account.  The same result can be achieved by running the Remove-Mailbox cmdlet in the Exchange Management Shell.

Figure 1 - Removing Active Directory Objects

Having been delegated the Exchange Organization management role also means that my user account can create new Active Directory objects in addition to deleting them.  How can this situation be addressed?  How can we ensure that pure Exchange administrators cannot, say, delete Active Directory objects?  Deploying RBAC split permissions is one of the options available to you to achieve this.  Switching to RBAC split permissions largely involves running a series of Exchange Management Shell cmdlets, as it's not possible to configure RBAC split permissions via the Exchange Management Console.  Let's walk through the process.

The first thing to do is to create a new role group for the Active Directory administrators.  This role group should be assigned the roles required to allow its members to modify Active Directory objects, namely the Mail Recipient Creation and Security Group Creation and Membership roles.  Optionally, the Role Management role can also be included at the same time if required, since this allows members of the new role group the ability to assign the Mail Recipient Creation and Security Group Creation and Membership roles to other role assignees in the future.  I'll also talk a bit more about the Role Management role later in this article, as there is a permissions bypass issue that you may want to address.

The cmdlet to use to create the new role group is the New-RoleGroup cmdlet, which will create the new role group in the Microsoft Exchange Security Groups Organizational Unit (OU) along with the other default role groups.  The -Roles parameter is used to specify the management roles to assign to this role group and I also like to include the -Description parameter as the default role groups also have their description fields populated with meaningful descriptions of what the role group does.  The full command that I have run is:

New-RoleGroup "Active Directory Administrators" -Roles "Mail Recipient Creation", "Security Group Creation and Membership" -Description "Members of this management role group have permissions to manage Active Directory objects"

The result of running this command is the new role group as you can see from Figure 2.

Figure 2 - New Active Directory Administrators Role Group

The next step is to create delegating role assignments between the Active Directory Administrators role group and the roles assigned to this role group; the roles assigned were the Mail Recipient Creation and the Security Group Creation and Membership roles.  These delegating role assignments give the role assignee, namely the Active Directory Administrators group members, the ability to assign the role to other role assignees if required.  The following commands will achieve this objective:

New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup "Active Directory Administrators" -Delegating

New-ManagementRoleAssignment -Role "Security Group Creation and Membership" -SecurityGroup "Active Directory Administrators" -Delegating

Now that we have our Active Directory Administrators role group created, I'm going to add my Active Directory account to it.  Furthermore, another Active Directory account, named Sally, that has also been delegated the Exchange Organization management role will not be made a member of this new role group so that we can compare the permissions available to the two accounts.  To add my account to the new role group, the command to run is simply:

Add-RoleGroupMember "Active Directory Administrators" -Member Neil

To ensure that only members of the Active Directory Administrators role group can modify membership of this same group, the ManagedBy parameter of the role group is set to the Active Directory Administrators group via the Set-RoleGroup cmdlet:

Set-RoleGroup "Active Directory Administrators" -ManagedBy "Active Directory Administrators"

This makes the change that you can see in Figure 3.  By default, the ManagedBy attribute was set to the Exchange Organization management role group when it was first created.

Figure 3 - Setting The ManagedBy Attribute

Operationally, if a non-member of the Active Directory Administrators role group then tries to modify the membership of this group, the operation will fail with a permissions failure as you can see in Figure 4:

Figure 4 - Membership Change Permissions Failure

However, members of the Exchange Organization management role group can bypass the security check we configured as a result of the Set-RoleGroup command earlier in this article.  Specifically, it's actually anyone who is assigned the Role Management role which is the case, by default, for anyone who is a member of the Exchange Organization management role.  For example, the other Exchange administrator called Sally is a member of the Exchange Organization management role group but is not a member of the Active Directory Administrators role group that we have just created.  In this scenario we do not want to give Sally the ability to manage Active Directory objects, such as deleting Active Directory accounts when deleting mailboxes.  However, Sally can run the following command to grant herself membership of the Active Directory Administrators role group:

Add-RoleGroupMember "Active Directory Administrators" -Member Sally -BypassSecurityGroupManagerCheck

The -BypassSecurityGroupManagerCheck parameter allows Sally to add herself to the Active Directory Administrators role group even though we have previously configured the group such that only members of the group itself can manage the group membership.  To prevent this from happening, we can remove the Role Management role group from the permissions assigned to our Exchange administrators.  However, I'm not going to go that far in this article as I'm going to choose to monitor the membership of the Active Directory Administrators group.

To complete our RBAC split permissions configuration, we need to remove the management role assignments for the Mail Recipient Creation and Security Group Creation and Membership management roles.  To do this, we can run the following commands:

Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | fl name

Get-ManagementRoleAssignment -Role "Security Group Creation and Membership" | fl name

The results of running these commands are shown in Figure 5.

Figure 5 - Management Role Assignments

It's now just a case of removing the management role assignments not linked with the Active Directory Administrators role group using the following commands:

Remove-ManagementRoleAssignment "Mail Recipient Creation-Organization Management-Delegating"

Remove-ManagementRoleAssignment "Mail Recipient Creation-Organization Management"

Remove-ManagementRoleAssignment "Mail Recipient Creation-Recipient Management"

Remove-ManagementRoleAssignment "Security Group Creation and Membership-Organization Management-D"

Remove-ManagementRoleAssignment "Security Group Creation and Membership-Organization Management"

All that's left to do now is to logon as Sally and confirm the permissions that are available to this administrator.  Remember, this administrator is not a member of the Active Directory Administrators role group and therefore should not be able to, for example, delete Active Directory objects when deleting the corresponding Exchange mailbox.  As you can see from Figure 6, this is now confirmed as the Remove menu option is not available to this administrator:

Figure 6 - Remove Command Missing

You should all have seen the blogs posts and tweets by now that the RTM versions of the Wave 15 suite of products are now on MSDN, etc.  Don't forget the standalone versions of the Exchange 2013 help files, that you can find at:

http://www.microsoft.com/en-us/download/details.aspx?id=35395

I personally find having an offline copy of these invaluable.  Especially good for reading on those long train trips....

Recently, I was involved in a discussion about how it might be possible to create MailTips on a per-domain basis.  In Exchange, it's possible to create a remote domain for a specific address space, such as contoso.com, and configure different settings for that domain such as automatic forwards, automatic replies, out-of-office settings and so on.  The specific question relating to MailTips and remote domains was essentially :

"Is it possible to configure MailTips on a per-domain basis?"

In this particular case, the desired outcome was to use MailTips to remind users within a particular Exchange organization that they were sending email to another user that was from one of a number of trusted partners, such as partners working for Contoso and therefore having an SMTP address ending with contoso.com.  A quick look through the Understanding MailTips topic (http://technet.microsoft.com/en-us/library/dd297974.aspx) didn't reveal any information on setting MailTips on for a particular remote domain, although the MailTips Architecture section of the topic did discuss MailTips over organizational relationships.  What if you don't have or don't want an organizational relationship?

Let's say, for example, that your Global Address List (GAL) has several mail-enabled contacts for a number of trusted partners working for Contoso and you want MailTips to be seen by your users when they are sending messages to these contacts.  Additionally, you also have a number of mail-enabled contacts in the GAL representing users at a free email service provider such as Hotmail.  You also want to ensure that your users are reminded they are sending to Hotmail when they are addressing these contacts.  One way to achieve MailTips in this scenario is to configure custom MailTips.  In order to filter the contacts in the GAL correctly, we can make use of the custom attributes that ship with Exchange Server 2010.  For example, we could set CustomAttribute1 on all mail-enabled contacts for the company Contoso to a suitable string such as "Contoso".  We can then identify these contacts and set a custom MailTip using the following command:

Get-MailContact | Where {$_.CustomAttribute1 -eq "Contoso"} | Set-MailContact -MailTip "This person works for Contoso"

This command returns all mail-enabled contacts whose CustomAttribute1 attribute is set to "Contoso", then proceeds to set the custom MailTip accordingly.  The result is that when a user addresses this contact they receive the custom MailTip as you can see below:

To create a custom MailTip for contacts that use services such as Hotmail, we can run a command similar to this:

Get-MailContact | Where {$_.PrimarySmtpAddress -match "hotmail.com"} | Set-MailContact -MailTip "This person uses Hotmail.com"

Of course, there's an administrative overhead with this approach but it perhaps goes some way to addressing the need of custom MailTips for specific sets of contacts.

This morning I've noticed a few updates for Office 365 related material released on the Microsoft downloads site recently.  Here's a quick list in case you missed them:

Office 365 Integration Module for Windows Small Business Server 2011 Essentials

Office 365 ROI Case Studies - Small and Medium Sized Businesses

Microsoft Office 365 purchase and operation step-by-step guides for midsize businesses and enterprises

It also appears that the Exchange Server 2010 Install Guide Templates have been updated.  I'm not entirely sure exactly what has changed without reading them, but it's always good to have the latest versions as found here:

Microsoft Exchange Server 2010 Install Guide Templates

If you are not sure which Office 365 plan is right for you, then you'll be pleased to hear that Microsoft has released the Office 365 Advisor.  This is a tool that can help you find the right Office 365 plan and also estimate your costs.  When you access the advisor at the link in this blog post, you'll see this screen:

If you select the Plan Advisor, you'll be asked questions such as the number of employees in your organization, the level of IT support your company has, your current email solution, the version of Office you have deployed and whether you want to host video conferences and online meetings or not.

Once you've answered the questions, your plan results are revealed on screen.  You can print the results or download a PDF version of the output, as well as share the results via email or your favourite social media outlet!

The Cost Calculator allows you to estimate the monthly costs of your chosen plan.  It also advises you of other Office 365 plans available that may be more suitable.

If you're thinking about Office 365 and you're not sure which plan is right for you or how much it will cost, check out the Office 365 Advisor.