Cloud Computing

How to Implement and Migrate to [email protected] Email

There is a lot of documentation out there about [email protected], however, it seems like it is hard to find a relatively quick and concise guide on how to roll out a [email protected] implementation.  In working with an educational institution recently, we found this to be the case.  Microsoft does have tons of documentation on their [email protected] website, but it is a bit overwhelming to put every piece together and know what basic steps to take to get mail moving to [email protected]  Hopefully this quick and to the point guide on the steps we took to roll out [email protected] will help out other admins out there who may be struggling with some of the documentation from Microsoft.  Please keep in mind the below steps do not account for every type of environment or Exchange configuration.

Initial Configuration 

The document assumes that you have already signed up on the [email protected] administration page where the institution has to be enrolled first.  There are initial steps with Microsoft that you need to do first.  This includes:

  • Submitting your WAN/Firewall information
  • Getting MX record information from Microsoft (they will provide that information when you have everything submitted and they have approved the application and have things setup on their end.
  • You will receive the MX and CNAME records that you will need to create on your forward facing Internet DNS so that clients from the outside can be directed to your [email protected] mail servers for queries of mailboxes not found internally.

Understanding Your Active Directory Attributes

At the heart of the [email protected] implementation is the Active Directory attributes associated with a user account.  As you most likely already know, when you install Exchange into an Active Directory environment, your schema is extended and the available attributes are much greater due to the specific Exchange attributes that are added.  Two of the most important attributes to understand when thinking about implementing [email protected] is the proxyaddress attribute and the targetaddress attribute.  Between these two attributes you can either have a working [email protected] environment or one that is broken.

One of the more popular implementations of [email protected] for a lot of schools or universities is the hybird environment where you still maintain an on premises Exchange environment and then have the [email protected] environment that is also part of the organization.  Many schools choose to shift student email to the cloud or [email protected] and maintain faculty/staff mailboxes internally in the on premises environment.  For the purposes of what we are going to describe here, this is the environment that we are targeting.  Many of the principles are exactly the same and depending on how you are wanting mail to flow also, will determine how you want to set this up.

Mail Flow Choices

As mentioned above, there are choices to be made concerning how you want mail to flow.  In [email protected], you can either choose to have mail delivered to [email protected] and then forwarded (cloud relay) or have mail delivered to your on premises server and then forwarded to [email protected] (on premises relay).  There are advantages to both of these.  Let me highlight what we consider to be the biggest reasons you would use either one.

  • On Premises Relay – This is the least disruptive to your current mailflow.  By default with your current Exchange environment the way it is before bringing [email protected] into the mix, you have an on premises relay.  Although, as you are correctly thinking, you hopefully not any kind of relay, especially an open relay, however, what we mean by this analogy is that your mail is delivered to your on premises environment first and then either delivered to a local mailbox or sent somewhere else.  So choosing this type of mail flow stays with keeping what you already have configured.  You won’t have to reconfigure your DNS or Exchange environment to a more major degree as you do with the cloud relay scenario.
  • Cloud Relay – With the cloud relay, you have mail delivered first to your [email protected] presence and then forwarded to your on premises Exchange servers.  The advantage to this scenario is that you get all of the speed, security, and robustness of the Microsoft frontend to your email environment.  You go through the Microsoft Forefront servers SPAM protection first and then mail is sanitized and sent down the pipe.  The downside is that this setup is much more invasive in your environment.  You will have to change more settings to get mail flowing through the cloud and then to your environment.

So as you can tell above, there are many decisions that have to be made beforehand so that it is known what direction/steps the implementation needs to take.  For many, the easiest implementation is going to be the on premises relay since normal mailflow is not interrupted and this type of implementation can be the stepping stone to the full cloud implementation in the future.  Many use this as a proof of concept in showing how well cloud email works, and then ease into the full cloud hosted solution.

Also, with many educational institutions, student email is the first to go to the cloud and the faculty/staff email remains locally housed in the on premises Exchange server.  This makes a lot of sense, since this allows an infinite number of student accounts to be housed on Microsoft servers and not in the on premises email system which can save tremendously on storage and hardware costs as well as personnel to manage all the local accounts and hardware.

Setting up your local Exchange 2010 environment for [email protected]

So many are left wondering, what do I do after getting things setup on Microsoft’s side with the enrollment, etc?  We will be using the Exchange 2010 SP1 environment as the example on how to setup your Exchange environment to pass mail on to [email protected]

Open up your Exchange Management Console and navigate to your Organization Configuration and then Hub Transport


You will need to create the Outlook Live Domain under your Accepted Domains tab.  Take a look below.  Notice the Outlook Live Accepted Domain is of the type “Internal Relay” and our on premises domain is “Authoritative.”



Notice below that you will select the option for this to be the Internal Relay Domain option.  You will of course plugin the information for your own Accepted Domain below.  Here we show the screenshot of after it has been created and the properties thereof.



Now after we create the Accepted Domain for Outlook Live, we need to create the Send Connector for Outlook Live




Now let’s take a look at the properties of the send connector for the Outlook Live environment.  Below, on the Address Space tab, you will enter the SMTP information for the Live environment you have created with Microsoft.


The network tab below will contain one of the Microsoft values they will provide.  You must enter this server name they give you exactly as it is specified.  It is actually a CNAME record and is defined in our connector as a “Smart Host” and it is not an intuitive name, so pay attention closely to what you enter.


Below, you associate the send connector with one or more of your Hub Transport servers



Active Directory Attributes – Make Mail Flow

Mailflow to [email protected] all comes down to how we define the proxyaddress  and targetaddress attribute in Active Directory.  To make mailflow to [email protected], we will setup our targetaddress as our [email protected] email address, and the proxyaddress value will contain both the [email protected] email address as well as the on premises authoritative domain email address.

So you are probably thinking about now, I have to manually alter these Active Directory attributes by hand!!!???  No.  We can do this with our on premises Exchange server.

Existing Users

If you have users that already exist in Active Directory and that have Exchange mailboxes associated to them, we must disassociate that user from that mailbox to get our user mailflow setup to flow correctly to LIVE.  In thinking about how you want to do this, most likely you don’t want to delete the user mailbox as you may intend to back these up to PST files or connect them to other user accounts (we will talk about that in a bit).

The way to properly disconnect a user from his/her mailbox in Exchange 2010 is you:

  • disable the user in the Exchange Management console or use the Disable-Mailbox commandlet in Exchange Management Shell.
  • This may not be intuitive as we might think that we are disabling the user in Active Directory.  However, that is not the case.
  • We are simply disabling the Exchange attributes.  The Active Directory user is not disabled, only the attributes.

Once the Exchange attributes are removed from the user, we can then run the enable-mailuser commandlets to set our attributes.  The syntax for that will be:

  • Enable-Mailuser -Identity %username% -ExternalEmailAddress “%username%@edu_email_address”
In the above, you would of course replace the [email protected] email address with your specific [email protected] email address convention.
Once you run the above command, if you take a look at the attributes on the user account, you will see that the proxyaddress and targetaddress attributes have been properly set for the user.


Forefront Identity Manager 2010
Forefront Identity Manager 2010 is Microsoft’s product that moving forward will be the supported platform of syncing user accounts and passwords to [email protected] from the on premises Active Directory environment.  There are a lot of forums and message boards out there still pointing to ILM 2007.  You can still at this point use either one, however, as with everything Microsoft, they are always moving forward.  For future support purposes, you will be doing yourself a favor by using the newer product in your environment.
The above piece concerning the object attributes is key, because these attributes are also the attributes that FIM2010 uses to sync user accounts to your hosted management agent(s).


FIM2010 wasn’t really hard to setup at all.  You simply run the installer and follow the prompts.  Microsoft has also made the management agent piece that is specific to [email protected] much simpler in that they have provided an installer package formerly known as GalSync but is now called OL_Sync for all practical purposes.  You can download the OL_Sync package for FIM2010 here.
When you run the OL_Sync package, it will prompt you to fill in your particular [email protected] environment information such as admin credentials and your hosted domain name, etc.  Pay attention to your entries here.
To get a good idea about how OLSYNC works with [email protected], take a look at this document from Microsoft which will help explain how the methodology works between FIM2010 and [email protected]


OLSYNC User Account
You must setup an OLSYNC user account on both your on premises environment as well as your Hosted [email protected] side of things.
  • To setup the user account on your on premises side take a look at this Technet document.
  • To setup the OLSYNC user on the LIVE side, take a look at this Technet document.


Setting up connection settings in FIM2010

Notice below how we are populating the connection information for the Hosted management agent.  The connection information for the remote powershell environment is found in the “Connect To” field.  The olsync user is the user that was setup using the link above for setting up an olsync user on the LIVE side.


Other FIM properties you will want to setup:
  • Under Connect to Active Directory Forest you will want to make sure you populate the connection information with an account that has permissions to connect to your local AD directory
  • Under the properties of the On Premises management agent, under the Configure Directory Partitions you will want to specify which containers you want FIM to look at when it syncs.  You can specify the entire directory or a specific OU or sub OU.
  • Under the Hosted management agent properties, look at the Configure Global Parameters section and look at the Provisioning Domain parameter.  Make sure that you specify the correct provisioning domain here.  We had fits on the first few runs because we had the on premises domain specified here and not the [email protected] domain.  If this is not set to the correct domain, FIM will not push user accounts to the LIVE side as you would expect.  This basically tells FIM, when it sees this provisioning domain attribute  attached to the user account in the form of the targetaddress, it is supposed to provision the user account in LIVE.
  • For the most part all the other defaults with the management agents as they come out of the setup after running the OLSYNC setup for FIM which was linked above in the article, should work for most environments.  As always though, be sure and test everything thoroughly as other areas of your particular FIM environment may need to be setup differently or altered to suite your needs.
Sychronizing Accounts
The recommended way to start sychronization of user accounts between FIM2010 and your LIVE enviroment is by using the StartSync.ps1 file that is found in your FIM2010 program directory under:
“c:Program FilesMicrosoft Forefront Identity Manager2010Synchronization ServiceSourceCodeScripts”
  • ***Note*** The first time you ever run this, you will want to run the script with a special parameter:  .StartSync -FirstRun
  • All subsequent runs of the synchronization script can be run without the “-FirstRun” parameter
Setting up Password Synchronization with FIM2010 and [email protected]
We have a previous post located here in which we detail how you go about setting up the password change notification service and the other pieces with FIM2010 and Active Directory to successfully synchronize user account passwords from your on premises domain to the hosted side or the LIVE side.


Back to top button