From open source groupware solution Zarafa to Exchange: Part 2, Active Directory

Reading Time: 7 minutes

See also Part 1: A New Beginning

When using Zarafa there are several possible directory services you can use for authentication. I will restrict this post to situations relevant to Active Directory (AD) integration. Even if you did not use Active Directory (or Zarafa for that matter) previously, I believe this post still contains valuable information.

Getting to know your current environment is key if you want to change it. If you migrate from one version of a product to another, this is important, but if you change the vendor of a certain solution, a lot of extra information is crucial. It is very possible that specific information isn’t automatically transferred as it would with a migration of products from the same vendor, like an Exchange to Exchange (intra-forest) transition.

This post shows you what and how to inventory relevant AD information and in some cases even provides tips to prepare those objects for an Exchange implementation. In these situations, there is already an out-of-the-box Exchange 2013 server present in the same Active Directory. In my experience that shouldn’t be an issue and it makes an inventory much easier. As a best practice, I also install the Remote Server Administration Tools (RSAT) with the Active Directory PowerShell module on each Exchange server.

AD Objects

It is important to know what objects are used and in what way. Be certain you have inventoried the following objects:

• Distribution Groups
• Users
• Contacts
• Public Folders

If you have a domain joined computer with PowerShell, use it to extract this information from AD (with the exception of Public Folders). An alternative is CSVDE which can also export this information to a Comma Separated Value (CSV) file, usable in scripts or a spreadsheet program like Excel for further analysis.

Note:
Be sure to use the CSVDE -u unicode parameter if you have an international organization with international characters in Displaynames.

When integrated with AD, Zarafa is able to use the objects stored in it.

 

Distribution groups

This means that if you used Distribution Groups within Zarafa you can reuse them for Exchange without recreating them. This has several advantages:

• You don’t have to recreate groups
• Users that are accustomed using specific groups don’t have to change their behavior when selecting the correct group.

Do note that Zarafa does not require these groups to be of the Universal scope as it is required with Exchange. But, luckily, you can change this scope easily via Active Directory PowerShell. The example below converts all Global groups with the “DL_” prefix to the Universal Scope:

Get-ADGroup -Filter {(name -like "DL_*") -and (GroupScope -eq "Global")} | Set-ADGroup -Groupscope Universal

Furthermore, at least in earlier Zarafa builds, these groups do not necessarily have to be mail-enabled and might not have a SMTP address (which made using them from an ActiveSync client via the Zarafa ActiveSync Z-Push add-on impossible, by the way…). In Exchange this is required and when you mail-enable these groups they will receive an SMTP address. Configure your Exchange Email Address Policies (EAP) to meet your SMTP needs, specific for groups. And if those groups were used to grant permissions in any way, they need to be Security Distribution groups and not plain Distribution groups. You can do this via Active Directory and Computers (ADUC) MMC or when bulk changes are required via the Active Directory PowerShell with:

Set-ADGroup –Identity <name> -GroupCategory Security

Note that the Exchange Admin Center (EAC) doesn’t provide the option to mail-enable existing groups. You’ll have to do that via PowerShell. The example below first stores all Universal groups with prefix “DL_” in a variable and then mail-enables them:

$adgroups = Get-ADGroup -Filter {(name -like "DL_*") -and (GroupScope -eq "Universal")}

$adgroups.name | Enable-DistributionGroup

$adgroups.name | Set-DistributionGroup -HiddenFromAddressListsEnabled $true

Adjust this example to your needs. By storing the groups in a variable, you can modify them further with Set-DistributionGroup. In this example they also are hidden from the Global Address List (GAL). Be sure that you have implemented your EAPs before performing this action, otherwise these groups might get SMTP addresses you didn’t want (you could clean them up afterwards, but that’s extra work. And you know, us IT people are kinda lazy 😉 ).

Users and contacts can also be reused by Exchange, but be sure to configure Email Address Policies correctly according to your SMTP standardization. Be sure to check these policies AND your AD naming convention. As many Exchange and AD experts know, AD is quite US-focused and does not provide room for non-US naming conventions. It might be necessary to make changes in AD in order to get the most out of your EAP. Now, no AD naming convention will be perfect, but I would suggest you'd use a convention that will allow EAPs to generate the bulk of you SMTP addresses correctly. That will save administrative effort.

 

Public folders

Public Folders are a special breed. This is the case within Exchange, but certainly also within Zarafa. Most importantly, they cannot be mail-enabled within Zarafa. This provides us with important challenges. If you needed to direct mail into a Public Folder within Zarafa, you need to use something like Procmail to move specific mail into the folder. This means SMTP addresses are outside Zarafa and you have to examine several rules in order to determine which Public Folders will have to be mail-enabled within the Exchange environment.

That is, if you want to keep Public Folders… There are scenarios were you’d rather want Shared or Resource mailboxes. You will have to inventory and probably interview users of those specific folders in order for you to determine what to do with them. This is actually something I also do when migrating Exchange to Exchange (2010+).

On a side note, do remember that Public Folders in Exchange 2013 are no different from previous versions of Exchange from a user perspective (except that you are limited in OWA 2013…) but the infrastructure is vastly different. Be sure to read up this topic even if you have Exchange knowledge but just not up-to-date.

AD attributes

As Zarafa has a different philosophy regarding storing information, it is very likely that not all attributes are stored in AD. Having a more modular setup, one can use a transport service of their own choice. Postfix for instance. However, it is possible to have address rewrite rules on this SMTP entry point that will never show up in AD attributes.

Because of this, it is paramount to check you whole mail flow infrastructure for any rewriting. For instance, one costumer had contoso.com as default mail address in Zarafa and Postfix rewrote every SMTP address with a specific country TLD, such as contoso.nl, to contoso.com. However, as Exchange correctly doesn’t allow duplicate SMTP addresses, I prefer to keep all SMTP logic within Exchange. It’s easier and less prone to errors to manage all SMTP addresses within Exchange because your mail environment is less complex.

But let’s focus on what’s in AD. As said, Zarafa can integrate with Active Directory and even adds new application specific attributes, but also uses default properties.

Some are used differently, most important the mail address attribute. Below are screenshots of the Zarafa attributes added to a user account when performing an Zarafa schema update:

Most of the attributes make sense and, although I didn’t require this information when migrating, you could extract information from AD and use them again for Exchange mailboxes. That is, if it is required to have exactly the same values in the Exchange equivalent attributes. It shouldn’t be to hard to script this.

Do notice that in the Zarafa fields, no SMTP address fields are present. This is because it uses the default fields already present in AD, namely:

• mail
• otherMailbox

See an example below. The first screen show the mail field, which corresponds with the Emailadress field in the Account tab (because this a production environment I have redacted specific customer information):

Within Zarafa the “mail” field is read and used for the primary SMTP address of the specific user, however in Exchange this field is *written* by Exchange and should not be changed by an admin. Remember this when you implement Exchange and Zarafa side by side in the same Active Directory forest! Before you Exchange Mail(box) enable an user, be sure that the Email Address Policies will hand out the exact same primary SMTP address, otherwise you could break mailflow while Zarafa is still in production.

So, what about otherMailbox? It is how Zarafa handles multiple mail addresses besides the primary SMTP address. Exchange does this via the ProxyAddresses attribute. Below is an example showing a user which was Zarafa *and* Exchange mailbox enabled and had multiple addresses (again customer information redacted):

This example has a SIP addres as it was also Lync enabled, but be sure that it contains all the SMTP address as in use with Zarafa. Again preferably with the help of Email Address Policies.

To summarize it in a table:

Mail contacts and mail enabled groups, basically, work with the same principles shown here. As user mailboxes are most critical and most complex, I’ve focused my attention on these objects in this post.

Concluding

Luckily, in most cases you can re-use the same objects and mail(box) enable them in Exchange. Zarafa and Exchange can be implemented in the same AD forest (during migration), but there are some gotchas.

In some cases the groups used most be converted to another scope and be security enabled. Zarafa doesn’t make this distinction, Exchange does.

Zarafa handles the primary SMTP address somewhat differently than Exchange and good care has to be taken regarding Email Address Policies when mailbox enabling users who are also Zarafa Mailbox enabled. Be sure that the primary SMTP within Zarafa is the same as in Exchange.

Furthermore, additional addresses are stored in another AD Attribute (otherMailbox) than what Exchange uses (proxyAdresses). These should be re-entered, preferably with Email Address Policies.

Mail enabled Public Folders are probably the most work when migrating, as Zarafa doesn’t has the concept of Mail-enabled folders and thus nothing of the relevant data is stored within AD but rather on external solutions (in most cases Procmail).

See also Part 1: A New Beginning