I was attempting to enable directory synchronisation for Office 365 last week when I came across an error in the Microsoft Online Services Directory Synchronization Configuration Wizard.  The error stated:

"An error occurred. Error Code: 15. Error Description: Directory synchronization is not activated for this company."

This error is shown below.

I was sure that I had activated directory synchronisation within the Office 365 portal.  After some investigation, it turns out that there is a delay in this activation process.  Here are the overall process details and the symptoms that you may see:

1. Log into the Office 365 portal

2. Under the Management section, select Users

3. Here you'll see an option to setup directory synchronisation

4. If you click the setup link, you'll be presented with a screen where you can activate directory synchronisation.

5. After you've activated directory synchronisation, this will be confirmed in the same screen.

6. Back at the Users screen, you'll now see that you can 'manage' directory synchronisation.

7. If you now run the Microsoft Online Services Directory Synchronization Configuration Wizard straight away, you may receive the error stated at the beginning of this blog post.

8. If you log out of the Office 365 portal and log back in again, you will see that the Office 365 portal states that directory synchronisation option is again available for 'set up' rather than 'manage', hence leading you to believe that directory synchronisation has not been enabled.

If you see this happen don't worry, as there is a delay between selecting the option to enable directory directory synchronisation and the directory synchronisation process being available.  If you have enabled directory synchronisation then you do not need to enable it again; it will show as enabled in the portal once the background processes are complete.  The same issue will be seen if you use the Set-MsolDirSyncEnabled cmdlet rather than enabling directory synchronisation via the Office 365 portal.

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.

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....

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

Microsoft has released the 64-bit version of the Directory Synchronization tool for Office 365.  The community post is here, so please do go and take the time to review the information presented there.  However, I'd just like to call out from the community post the following statement : "...the functionality of the 64-bit version of the directory synchronization tool is identical to the 32-bit version...".  This obviously means that the 64-bit version does not contain any new features over the 32-bit version, which in turn means that if you are currently running the 32-bit version, there is no real need for you to go and download the 64-bit version as a replacement; the 32-bit version will continue to function.