Tuesday, November 13, 2012

Cross-Forest Free/Busy – the Simple Version

I am currently on a project which involves cross-forest mailbox migration (as part of the AD migration/consolidation). In such cases the migration is a process which can take considerable amount of time, so naturally coexistence is important. So mail routing and GALSync need to be in place, and what offers the most value to the business is the Free/Busy lookups cross-forest. Now we all know that starting with Exchange 2007, but truly it is better implemented in Exchange 2010 and higher, there is what we call Exchange Federation. Exchange Federation allows federating two partner companies to share the Calendar and Contact information cross-forest. While this feature allows for sharing more than just Free/Busy, but also the subject of the appointments, the location, etc. (what I call "Rich" Free/Busy), it requires that both organizations have at least one Exchange 2010 CAS server present, and involvement of Microsoft Federation Gateway.

Now on my project the source environment is Exchange 2007 and implementing an Exchange 2010 is not feasible. So my good friend and colleague Arno Zwegers (who is an Exchange Ranger) has pointed out to me that we could offer a "simple" Free/Busy lookups without deploying Exchange 2010 CAS box in the source. This method also does not require access to the Microsoft Federation Gateway (which means you do not need publicly signed certificates per se, as long as the CAs which issued the certificates are mutually trusted).


It is possible to provide free/busy lookups cross forest between two Exchange 2010 or 2007 or a mix of these, without the need of using the Microsoft Federation Gateway. This will offer only basic free/busy information.


  • It only works for Outlook 2007 or more recent clients. Outlook 2003* users will NOT be able to see Free Busy/Availability information from people located in the other side (so between non-migrated and migrated users).
  • It will only work for mail enabled objects that exist in the Global Address List. So it will not work when an object is not listed in the Global Address List. So you need to maintain an up-to-date GAL (GALSync, Script, whatever…)

To be able to access Free/Busy information between Contoso Forest and Fabrikam Forest the following needs to be done:

  1. The host files on ALL CAS servers in both forest need to be adjusted. Entries which will be pointing to respective autodiscover records should be added.
    autodiscover.contoso.com & autodiscover.fabrikam.com
  2. In Contoso Forest create an account "freebusy"(plain user account-CONTOSO\freebusy)
  3. In Fabrikam Forest create an account "freebusy"(plain user account-FABRIKAM\freebusy)
  4. In Contoso Forest: Logon to a CAS server and run the following commands:

Add-AvailabilityAddressSpace –Forestname "fabrikam.com" -AccessMethod OrgWideFB –Credential (get-Credential)
When prompted for the credentials use the "FABRIKAM\freebusy" credentials.

Set-AvailabilityConfig –OrgWideAccount freebusy
freebusy here is the local account we created earlier.

  1. In Fabrikam Forest: Logon to a CAS server and run the following commands:

Add-AvailabilityAddressSpace –Forestname "contoso.com" -AccessMethod OrgWideFB –Credential (get-Credential)
When prompted for the credentials use the "CONTOSO\freebusy" credentials.

Set-AvailabilityConfig –OrgWideAccount freebusy
freebusy here is the local account we created earlier.

Now wait for 15-30 minutes and try scheduling an appointment between 2 users from 2 different forests.

I have successfully tried this in the situation with 2010 and 2007, but I am quite sure it will work for Exchange 2013 as well. (@Arno, Correct me if I am wrong)

* To accommodate Outlook 2003 clients which use Public Folders to retrieve the Availability information exFolders can be used to sync the System and Free/Busy Public Folders between two forests. "exFolders" is the new name for the old IORepl Tool (Inter-Org Replication Tool), which offers the possibility to synchronise Public Folders cross-forest.


  1. Hi Leiby,

    I just stumbled upon this post looking for a cross forest co-existence solution. Essentially, Company A is going to merge with Company B. They will eventually create a new forest and Exchange org but at the beginning they just need to be able to sync the GAL, see Free/Busy and have mail routing between the companies. Will this solution you posted handle the GAL sync and free/busy requirement? Or in your experience is there a better solution?

    Thank you,

    1. Kevin,
      The method I describe is only facilitating a "Simple" Free/Busy information sharing between the 2 forests. "Simple" here means that only the actual Free or Busy information will be displayed! No Subject or location information etc. is included. If you have Exchange 2010 on both sides you could opt for the so called "Exchange Federation" which will allow richer Free/Busy sharing between the 2 forest (controlled by a policy of course). This is a tad more complex to implement since you will need public certificates or exchange root certificates between the forest need to be exchanged.

      Regarding the GALSync - well why don't you use FIM 2010? When only the preconfigured GALSync Management agent is used the solution is absolutely free (the only costs you will have is licensing the OS for that server which could easily be virtualized). One FIM server is sufficient for multiple forests and it does not matter which forest you place it in. I have setup Galsync with as many as 8-10 forests in the past. GALSync management agent is a predefined fully functional management agent in FIM and can be set up really easily (there is enough info to be found on internet how to do this). You could also go the old fashioned way and use a script to create contacts in the respective forests representing the users, but then you need to device a procedure to keep it up to date. If you ask me - go down the FIM 2010 road - will save you lots of headache...

      Cheers and thanx for dropping a line


    2. Hi Leiby
      This forum wan't updated for a while now so not sure if you'll see my post but I just spoken to Microsoft about your claim that FIM is free "when only the preconfigured GALSync Management agent is used" and they said that they couldn't find this info anywhere in their documentation.
      So I was just wondering how did you find out about this and if you can point me to some documentation?

    3. Milan,

      My bad, and let me explain why I refer to the option of using FIM GALSync is free:
      The real costs for FIM are the CALs which depending on your Enterprise agreement can be anywhere between 10 and 15 euros/dollars per synchronized user per year! Now if you use just the GALSync Module you do not have to pay the CALs no matter how many users you have! What you do have to pay is of course the Windows Server OS license and the one time license fee for the FIM server itself. At one of my clients I remember they had to pay 15k for the FIM server license (the one time fee).

      So yes you are right it is not FREE - but when you are syncing large amount of users the 15k plus the OS license is almost "Free" when you take into account that there is no need for CALs. Wondering what your Microsoft contact can tell you about this.



  2. Hi Leiby,

    While searching about GAL synchronization i found your post and got some informative points. Thanks for sharing. In my scenario actually i was looking for the solution for GAL Synchronization between two exchange servers and found a automated solution (http://www.lepide.com/exchangemigrator/). Let see it will help me to create GAL objects from source to destination Exchange Server and also vice-versa. I am going to try this.

    Any other suggestion please help me.
    Thanks in advance


    1. Walter, There are multiple solutions out there. Maitaining GALSync can be done by FIM for example. So any tool that does this will work.

    2. Hi there, What ports are required cross forest for FIM GalSync?
      LDAP to DCs and PowerShell remote to Exchange CAS?

    3. Correct LDAP ports and 443 for remote powershell (might also be 80 depending how your env. is configured). Some insist on using LDAPs (I am sure google will tell which port that is)