Email Coexistence for BPOS and Exchange: Part 2 – How to Synchronize Active Directory with BPOS


Part I of this article series explained how email coexistence with BPOS and your local on-premise exchange system works. We also walked through the first steps to configure this.

Moving Microsoft to the Cloud with BPOS

To recap, configuring email coexistence with BPOS requires the following steps:

  1. Add your own domain to BPOS and enable external relay (Covered in Part I)
  2. Verify the domain (Covered in Part I)
  3. Verify email traffic flow
  4. Enable Active Directory Synchronization
  5. Activate migrated users
  6. Migrate mailboxes to BPOS
  7. Optional steps: Configure SPF and secure the mail flow

This 2nd instalment covers steps 3 and 4:

  • Verify email traffic flow
  • Enable Active-Directory Synchronization

Step 3: Verify Email Traffic Flow

This step may seem out of order, but it’s actually very important. Before configuring Active-Directory sync, it’s crucial to verify that the two SMTP domains used for coexistence can successfully communicate.

As explained in part I of this article series, BPOS makes it look as if all users are using the same SMTP domain, whether using BPOS or your on-premise Exchange. However, behind the scenes it uses two different domains, and some tricky forwarding techniques. So, it’s important to verify that the two domains can talk to each other.

For this example we’ll continue to use the sample domain, and the BPOS domain

To verify email flow:
  1. In your BPOS environment, create a test user with a mailbox in the domain. For example,
  2. Create a test user in your on-premise Exchange environment. For example,
  3. Log on to the BPOS Outlook Web Access as
  4. Send an email message to
  5. Verify that UserTwo received the message, and reply back to the email.
  6. From OWA, confirm that UserOne received the reply.

If messaging doesn’t work, check to confirm that the domain has been added to your safe-senders list in Exchange. It may also be worth confirming that any 3rd party Spam filters aren’t rejecting the messages, and that your MX records are configured correctly to point at your on-premise Exchange.

Don’t move on until you’ve confirmed that basic mail-flow works as expected. Email coexistence won’t work if you can’t email between the two domains.

Step 4: Enable Active-Directory Synchronization

Active-Directory synchronization does exactly what you might expect. It copies your local active-directory user information over to BPOS.  This simplifies user administration, since BPOS automatically has a list of all users.  It also makes your full Global Address List available to all users, whether they are on BPOS or on-premise Exchange. Synchronization is performed using a tool called the “Active-Directory Synchronization Tool”, or Dirsync for short.

Dirsync will copy AD user information over to BPOS, with the exception of passwords. It will perform an initial sync, then re-sync every 3 hours. After running Dirsync, it’s important to make all user changes in your local AD, not on the Microsoft Online environment.

Before beginning, there are a few prerequisites.

  • Dirsync cannot be installed on a domain controller. It must be installed on a member-server joined to the same AD forest that you plan to sync with BPOS.
  • It cannot run on a 64-bit system, it must be installed on a 32-bit, Microsoft Windows Server 2003 SP2 or newer OS.
  • The .NET framework 2.0 or greater must be installed on the computer that will run Dirsync
  • Powershell must be installed
  • Enterprise Administrator credentials for your AD will be required
  • BPOS Administrator credentials will be required
To install Dirsync:

From the machine that you plan to install Dirsync on, open up the BPOS admin console, and go to the Migration tab.

In the “Directory Synchronization” section click on Configure.

BPOS: Directory Synchronization

The window that opens provides a series of steps.

Read the planning document under Step 1 and check the box.

Next, under Step 2, click the button to Enable Directory Synchronization.

BPOS: Enable Directory Synchronization

Now, under Step 3, click the download button which will take you to the download page for Dirsync.

Directory Synchronization tool download

Download and run the Dirsync setup file. Go ahead and install it using all default options.

Microsoft Directory Synchronization setup

Ensure that the option to “Start Configuration Wizard now” is selected, then click Finish.

Microsoft Directory Synchronization configuration

Enter your BPOS administrator’s credentials when prompted:

Microsoft Directory Synchronization configuration

And next enter your Active-Directory Enterprise administrator credentials:

Microsoft Directory Synchronization configuration

We want synchronization to start immediately, so leave the checkbox labelled “Synchronize directories now” selected, and click Finish

Microsoft Directory Synchronization configuration

Verify Synchronization

There are a couple of ways to verify that synchronization is working correctly.

First, open up the Event Log on the server running Dirsync.  Check the Application Log for events with a source of “Directory Synchronization” and Event ID 4. Events logged with ID 4 indicate that synchronization completed successfully.

BPOS: verify synchronization

Next, we can verify that users and groups were copied to BPOS. Dirsync copies all accounts over and automatically disables them in BPOS by default, so you’ll need to view “Disabled User Accounts” in BPOS to find the synchronized accounts.

To do this, log in to the BPOS admin center. Go to the Users tab, and click on the User List sub-tab.  Select “Disabled User Accounts” from the right-hand navigation pane. You should see a list of user accounts that were synchronized from your own Active-Directory.

Disabled User Accounts

If you can see user accounts from your domain, then congratulations! Directory synchronization is working correctly. For now, leave the accounts disabled. You should only activate accounts when you’re ready to complete the user migration process.

We’ll cover the final steps required to configure email coexistence in Part 3 of this series.  In Part 3 we’ll use the BPOS migration tool to copy mailbox data to BPOS, and configure the forwarding information that makes co-existence possible.

Email Coexistence for BPOS and Exchange: Part 1 – Introduction and Verifying Your Domain

Microsoft’s cloud service, the Business Productivity Online Standard (BPOS) Suite is designed to integrate with your existing on-premise Exchange system. BPOS can host your mail domains in parallel with your own servers.  It also can sync with your own Active-Directory, making it simple to migrate users to BPOS.

This is the first article of a three-part series. In this article, we’ll look at how Exchange coexistence with the cloud works, and start working through the technical steps to make this happen.

Moving Microsoft to the Cloud with BPOS


What is Email Coexistence?

First a definition: email coexistence refers to keeping some of your users on your own on-premise Exchange servers, and migrating other users over to BPOS – but you want all users to have the same SMTP domain. So in the example scenario in this article, all users keep the same addresses.

In our example, some users would use Exchange the traditional way – with a mail client like Outlook pointed at in-house mail servers.  However, some users have been migrated over to BPOS, and their mail client is pointed to cloud servers.  But all users have email addresses in the same domain, and all of them show up in the same Global Address List (GAL), making corporate-wide communication easy.

Email coexistence is a great solution, but it is not perfect. There are a few things you should be aware of:

  • This is an either/or scenario – users can’t maintain a mailbox on both systems. Old mailboxes on the on-premise Exchange should be removed as quickly as possible.
  • Free/busy data does not get exchanged between the two systems, so on-premise users can’t see free/busy data for BPOS users. For this reason, it may make the most sense to migrate entire workgroups to BPOS rather than just a few users.
  • One other feature that doesn’t work between the two environments is mailbox delegation – another reason to migrate entire workgroups at once.
How Email Coexistence Works

Before we start configuring email coexistence, a high-level overview of mail traffic flow is important. With coexistence, mail is routed as follows:

  • First, all incoming mail for our example domain,, continues to go to an on-premise Exchange system.
  • Second, the on-premise Exchange server receives the mail. The local Active-Directory syncs with BPOS, and a migration tool tells Exchange if the mail recipient is local, or has been activated in BPOS. Then, depending on the setting for each user, the Exchange server either delivers mail locally or forwards it over to BPOS.
  • Finally, BPOS receives the forwarded mail, and delivers it to users’ mailboxes.

BPOS Email Flow

The Trickery

Behind the scenes, this all works via some clever user trickery. The secret? The BPOS mailboxes don’t actually use your domain as its SMTP domain. BPOS actually uses a domain – such as

So, mail is simply being forwarded back and forth between two domains:, and

However, the system tricks users by displaying their login, mailbox, and sent mail as being part of the bpostutorials domain – hiding the long domain and saving users the agony of changing email addresses.


Step-by-Step: How to Configure Email Coexistence

Now that you understand the basic mail traffic flow, configuring mail coexistence takes a few simple steps.

1.       Add your own domain to BPOS and enable external relay

2.       Verify the domain

3.       Verify email traffic flow

4.       Enable Active Directory synchronization

5.       Activate migrated users

6.       Migrate mailboxes to BPOS

7.       Optional steps: Configure SPF and secure the mail flow

Let’s go through each of these steps in detail. We’ll cover steps one and two in this article, and finish off the process in our next articles in the series.

Step 1: Add Your Own Domain to BPOS and Enable External Relay

Open up the BPOS Admin site.  Click on the Users tab, then the Domain menu item. Then, click the “New” link in the upper-right corner.

BPOS: add domain & enable external relay

Enter your Domain name in the new window that opens up – in my example I’ve used And, since we’re setting up email coexistence in this article, click the option for “External Relay.”

(For a step-by-step guide to use BPOS as your primary mail system instead of email coexistence mode, check out our article on using your own custom domains with BPOS.)

BPOS: add domain & enable external relay

Click “Create” and a window like the one below will be displayed. Select the box to “Start the Verification Wizard” if you’re ready to go to the next step, and verify the domain now.

BPOS: verify domain

Step 2: Verify Your Domain

Verifying a domain is accomplished by creating a DNS entry called a CNAME, or Alias. Your DNS records are generally hosted by your domain registrar, though in some cases your DNS may be hosted elsewhere.

First we need Microsoft to tell us how to configure the CNAME. If you didn’t select the option to start the Verification wizard in the previous step, then go back to the Users tab, and click on the Domains menu item.  The newly added domain will now appear in the domains list. Click the “Verify Now” link.

BPOS: verify domain

Select your registrar from the drop-down if available, otherwise select “Other” and click “Next“.

BPOS: verify domain

On the next screen you’ll be provided with DNS settings that you’ll need to configure with your domain registrar. Don’t use the ones in the screenshot here, they will all be unique. Make a note of the Host name, and “Points To” information.

BPOS: create CNAME DNS record

Keep this window open. Now, fire up a new browser window and log in to your domain registrar’s admin site.  The example below was created using Go Daddy, but most registrars will have a similar tool. Microsoft has also compiled a detailed list of instructions for popular registrars.

Open up your registrar’s DNS tool and add a CNAME record. For example, with Go Daddy I would click the “Add New CNAME Record” button on the right-hand side of the screen.

BPOS: create CNAME DNS record on registrar

Enter the Alias information that BPOS gave you. Note that you usually don’t have to fully qualify an Alias (i.e. the full domain name isn’t required, just the host name).

BPOS: create CNAME DNS record on registrar

Success! Keep your registrar’s admin site open, because you’ll need it again in a minute.

BPOS: create CNAME DNS record on registrar

Flip back to your BPOS window (you left that open right?) and click the “Verify” button. If you did it right, then you should see a message like the one below. If it was unsuccessful then go back and confirm that you typed in the alias properly. Some registrars could take anywhere from 15 minutes to a 72 hours to activate the new records.

If it’s not working, try doing a DNS lookup from another system to confirm that the alias is configured properly. BPOS won’t verify the domain until it can resolve the new alias you created to the server name it provided you in the previous steps.

BPOS: verify domain

Verify that you’ve configured everything correctly so far by going back to the Domains window. You should see your domain listed with a Status of “Verified”, Inbound messaging “Disabled”, and a Type that shows “External Relay”.

BPOS: verify domain and enable external relay

Once you’ve added and verified your domain, you’ll be ready for part II of this series. In part II we’ll synchronize Active-Directory with BPOS. In part III, we’ll cover the final pieces of the puzzle: activating and migrating users.

HP Sizing Tool For Microsoft Exchange 2010

NEW: HP Sizer: Microsoft Exchange Server 2010

HP has developed the HP Sizer for Microsoft Exchange Server 2010 to assist you with proper server and storage sizing for Exchange Server 2010 deployments. It follows the success of the “HP Sizer for Exchange Server 2007”.

The algorithms developed and implemented in this tool showcase HP’s deep expertise with Exchange across the infrastructure; and are based upon extensive lab testing.

Based on your input, the tool provides a comprehensive bill of materials along with a deployment overview of the Exchange Server 2010 server roles and storage configurations. Once this Sizer is installed, updates can be downloaded automatically to the underlying software engines that are necessary to provide support for HP server and storage product information details.

You’ll find support for HP tower, rack mounted, or HP BladeSystem server platforms, as well as direct attached or SAN-based storage solutions. Additionally there are options for showing multiple site deployments, varied client types and access methods, all Exchange Server 2010 server roles, and Database Availability Group (DAG) high availability options.

Download this free tool now!

Designing An Active Directory Layout

Active Directory elements

When designing an Active Directory, you need to be completely clear of what each element or part actually means and how it fits into the overall design. The old saying goes: You can’t see the forest because of the trees, and you can apply this to Active Directory as well. It is all about trees and forests and leaves and branches.

The Active Directory forest

The forest, in terms of Active Directory, basically means every domain, organizational unit, and any other object stored within its database. The forest is the absolute top level of your Active Directory infrastructure. Of course, you can have more than one forest in a company, which actually represent security boundaries, and can therefore improve security between different business units or companies belonging to a single organization. The point behind the forest is that you have all your domains and domain tree within your organization contained within it. It is designed so that you can have transitive trust-links between all of the trees within one forest.

To read more about the technical layout of AD, please read Domains and Forests Technical Reference at:

To visualize a forest with its parts, please see the following image.

The Active Directory tree

A tree in Active Directory refers to a domain and all of its objects that adhere to a single DNS name. For example, a tree of would contain all other domains that end with “”. So,,, and all belong to the Active Directory tree of You cannot separate these unless you create a whole new forest for a sub-domain.

Organisational Units and Leaf Objects

In Active Directory, Organizational Units (OU), which are also called Containers, and Leaf Objects, which are non-containing objects such as computer accounts and user accounts, are directly related and even though you could have objects that do not belong to an OU, it isn’t recommended and isn’t really feasible.

Organizational Units are comparable to folders in a filing cabinet, and objects are the files. You can move files between different folders, and classifications or properties are applied to the files within a folder. For example, if you move a file into a folder classified “Top Secret”, the file will automatically fall under that classification. The same applies to objects within an OU, all properties or rules that apply to the OU apply to the objects within it. OUs, however, are mostly useful from an administrative point of view, not from an user’s point of view. If you think of how your files are organized, for example, on your computer, they are most likely to be organized into different folders. You can go ahead and set different folder settings, such as permissions, and it will affect all of the files within that folder, but anything outside that folder won’t have its permission affected. It is exactly the same principle with OUs. Any OU that will be created within an OU will contain all of the policy settings of the parent unless you change them. An object can also only belong to a single OU, just as a single file can only be contained within a single folder.

Leaf objects in Active Directory can be users, contacts, and computers. Or in short, any object that cannot contain other objects. They are called leaf objects because they are like leaves on a tree. And, as you can guess, they are the “lowest” class of objects within Active Directory. But if you now look at the forest-tree-branch-leaf concept, it is starting to make sense.

You can access the OUs and other objects through the Microsoft Management Console (MMC) or through the Users and Computers tool in the Administrative Tools. This second option actually just invokes the MMC with the correct view and is a lot quicker, as seen in the following screenshot:

active directory

Active Directory Sites

The Sites and Services MMC snap-in is a utility that a lot of Windows administrators, particularly in smaller organizations, completely overlook. This part of Active Directory, however, is one of the most crucial parts to understand and implement correctly.

If you have several locations in your organisation, you need to know about Active Directory Sites. Sites give you a very unique and well-designed approach to separate specific locations within your Active Directory. As the principle of an Active Directory domain is global-meaning that it is meant to be the same anywhere-it could present a problem for users who move from office to office, or for offices with network connections that are slow. Active Directory sites allow you to specify the IP address spaces or subnets used within your organisation and, therefore, bring the structure of your network into Active Directory. The usefulness of having properly organised and maintained Sites becomes more evident when you consider that any machine within an address space will use that Sites’ DC to authenticate. This is a great feature of AD and reduces unnecessary traffic. However, it requires having Sites and subnets properly updated and maintained. This is also particularly useful for defining different replication schedules for different locations within the same domain, and also to support users who travel. Once they log on through the other location, they are assigned an IP address from that network. The Windows locator service will then look up which DC is the nearest one, and the user won’t log on all the way to their usual DC (to read more about how the locator service works please refer to This saves bandwidth and speeds up the authentication process.

Bandwidth nowadays is cheap, especially in developed countries such as the USA or most parts of Western Europe. But just because it is cheap in some parts, does not mean it is cheap in other parts of your organization. If you are primarily located within developed countries, but your then company decides to open 10 or 20 small sales offices within not-so-developed countries, where bandwidth is expensive, then you really need to start using AD sites. Of course, the problem then is that because you haven’t used AD sites before, you need to make the appropriate changes to your infrastructure to accommodate them, and train staff appropriately in order to be able to implement, support, and manage them.

In this example, the argument might be brought up that each of these small branch offices has a local DC that also functions as a File and Print server where the local employees collaborate. This is great, but what about replication to and from your Hub site? Which is the data centre that hosts a critical part of your Active Directory backend? If changes to your AD are fairly frequent, for example, adding and removing users on a regular basis, then the Active Directory will replicate—if the Site links are properly configured—without compression every 15 minutes. Of course, depending on the size of your organization, this can be quite a strain on the link you have from that office. If the people at that office receive email and browse the Web over the same link, network performance will degrade significantly for users and cause unnecessary inconvenience.

To see what Sites look like in the Active Directory Sites and Services console, see the following screenshot:

active directory

Group Policy Objects

Group Policy Objects in Active Directory are a set of defined rules for settings about the user environment or the operating environment for a particular PC. They are treated as standalone objects because they can be linked to different OUs. This gives you the flexibility of creating one set of rules and applying it to different OUs in different OU structures, making settings deployment much easier and administratively quick.

The policy settings are quite extensive and if you want to get your hands dirty, you can create your own policy templates, giving you even more control over the machines and application settings located in your domain.

There are templates available for many settings, ready to use. The templates for these settings are called ADM templates and there are quite a few already included in the Windows 2003 installation. Some applications, such as Microsoft Office 2007, also provide ADM templates that can be loaded and modified (see for Office 2007 ADM templates). Using ADM templates, you do not need to write anything by yourself, and so it is a quicker way apply to GPO settings. The following screenshot shows Office 2007 ADM templates loaded in the Group Policy Editor.

active directory

Domain Design: Single Forest, Single Domain, and Star Shaped

A domain is not a security boundary within a forest. By default, all domains have transitive trust relationships within a forest and are therefore visible to each other. On top of that, all Global Catalogs contain the Security database and a rogue administrator can potentially gain access to different domains or even the entire forest. Please see for more details on such vulnerability. Even though this particular vulnerability no longer exists within Windows 2003, something causing similar effects can be a possibility.

This is the most common design version for small-and medium-size businesses, that have offices within one country or that are geographically close. It involves a single hub site and several small sites. A hub site is defined as a big data center where the majority of your infrastructure is housed. So if you have the headquarters and development for taking place in Los Angeles where 40 servers are housed in a datacenter and 900 people work, then that would be a hub site. In short, a hub site is a location where a large part of your crucial infrastructure operates.

From the hub site, all changes are replicated out to smaller sites, which can be small branch offices, small development locations, or pretty much any office that warrants its own domain controller. This puts control firmly into the one major hub site and all the branch sites just replicate with that. The advantage of this set-up is that you can push out a forced replication to all branch sites at once (provided your bandwidth supports this) and do not have to wait for any delayed replication schedules due to time zones and so on. The drawback is that if you do have a problem, due to human error, for example, and this gets replicated, everyone gets it at once. If, for example, an administrator at NailCorp deletes or renames by accident a service account that is used by a certain service throughout the organization, and he does not notice it, then after the next replication the service stops working. If the replication was star shaped and went to everywhere at the same time, the service stops everywhere at the same time. If the service is something that does not get recognized immediately, such as an antivirus policy update or some automatic update service from a third-party application, this failure will not get noticed immediately and the service will stop and won’t restart because it will be a logon failure. In this scenario, NailCorp could go on for days without anyone noticing.

As you can see in the following figure, in this design NailCorp would have a single hub site and three branch sites. Each site would have its own IP address range and would have, within Active Directory, its own site with DCs located inside it.

In this case, we only have a single forest and a single domain with different sites, but even in these sites all objects belong to the same forest and hence the same domain.

active directory


Domain Design: Single Forest, Single Domain, Empty Root, Star Shaped

Even though this architecture is no longer recommended, there are still quite a lot of companies that either use it or implement it. This is almost the same design as the previous one, except that it includes an empty root domain. Basically, it implies that the root of your forest is empty, meaning that there will be no computer accounts and no user accounts other than the Enterprise Administrators located in this domain. Within AD, a domain is not a security boundary. A forest, however is, so a multi-forest architecture would provide more security. An empty root domain has good and not-so-good points. The point is that this is a fairly safe design, which still adds layers of security. The other domain under the root domain – the child domain-will contain all of the user and computer accounts. This setup is beneficial from a security perspective in that the Enterprise and Schema Administrators groups are isolated from the other users and administrators. With this design, a few administrators can be selected to control the Enterprise and Schema Administrator groups, and all the other administrators reside in the child domains, configured to be Domain Administrators.

This will add a proper layer of security to the whole structure and will allow an easier structural change, should:

  • New companies be acquired and need transitional access, or
  • A separate AD be required for special access etc.

There has been some controversy about the necessity of an empty root domain. When Windows 2000 came out, the empty root was all the rage and everyone was doing it.

active directory

Domain Design: Multi-Domain Forest

This design is used a lot in larger corporations and companies that do a lot of Quality Assurance testing for software, or software development. It has a forest and multiple trees under this. This is also very good if your company has expanded a lot through acquisitions and you need to ensure that the acquired companies can access cross-domain files.

This design approach needs to be designed from the beginning because you cannot create a new forest on top of an existing one. Windows 2003, however, makes moving domain information and migrating between two Active Directories easier, with the tools that it provides.

active directory

Domain Design: Multi-Forest

This design, while administratively more complex, provides the best security. It also raises support costs and makes collaboration a little more difficult, but it definitely has its benefits. This design will have standalone forests for all of the business units or departments. This also means that by default they cannot see or access each other. Administrators then create trust relationships between the different domains that are within the forests. This will give the granularity needed. To visually understand this, please see the following image:

active directory

LRS—Lag Replication Site

These sites are also often called RLS (Replication Lag Site), DRS (Delayed Replication Site), and just plain lag site. Officially, there really isn’t a “correct” name as Microsoft and AD experts have referred to this concept in all four ways.

A lag site is a site in your AD that will contain at least one DC. This site is configured so that the replication only happens at a delayed schedule compared to all the other sites. This can be anything from one day to one week.

The purpose of lag sites is primarily to restore deleted objects quickly without having to go through the process of authoritative restores or even start working with tapes. If something gets inadvertently deleted, all that is needed is a replication in the opposite direction, from the lag site to the production DCs, and the deleted data is recovered. It is a clean, fast, and efficient way to recovery.

The other feature that is a natural by-product of a lag site, and used by quite a few organizations, is that in case of a disaster, it becomes easier, cleaner, and faster to recover a part of or your complete infrastructure. As lag sites are not used for authentication by users and DNS registration is disabled, they are considered stealth sites because they are not usable by any service or user.

Active Directory, as we have established, is a very complex infrastructure. There are a multitude of things that can go wrong at any given time, and human error, while the most common cause, is also the worst of the things that can happen if the changes are replicated out. Best practices generally include separating one or even two domain controllers per domain in your datacenter or somewhere else. (Create it in a new site in your Active Directory and make the link cost the highest possible. That means that it will only replicate the data with the main Active Directory once a week and the rest of the time just sit there. You can even design it so that there is no active replication going on by putting a firewall in front of the site and denying the traffic.)

Of course, you will get replication errors, but at least you have a working Active Directory in any event. If your infrastructure fails, all you need to do is complete an authoritative restore from the lag site, and activate the network link, meaning dropping the firewall if you have one, and promote or seize the roles of the domain controllers in the lag site. You will generally have a working infrastructure and since the lag site has an authoritative restore, all other DCs will replicate from it.

There are different approaches to lag sites. If you want to keep your Active Directory even more redundant and safer, you should definitely consider establishing a lag site.

active directory