In discussing Office 365 a term that comes up very often is federation. This is overused, misunderstood and often improperly used term, worse still, it refers to a wide variety of things that are federated, therefore, let me explain the four types of federation and the benefits of them in Office 365;

1) Calendar Federation
2) Domain (Lync) Federation
3) Identity Federation
4) Exchange Federation

Calendar Federation
This is an ability to turn on federation in your Exchange environment to allow people outside your organization, and visa-versa, to see and even modify your calendar as if you both worked for the same organization. There are a number of prerequisites to enable this very cool feature, however, to the end user, it is transparent. This is not the federation I want to discuss today.

Domain Federation  or Lync Federation or External Communications
Already seeing the first issue here, it is referred to, commonly, as three different things! The ability to federate Lync environment with other organizations which will enable presence, IM, chat, Lync calls and even web conference cross organization! All parties appear as part of the same organization. In Office 365 this is a snap to configure. You simply click the Manage link under Lync in the Admin Center and then under External Communications you have three simple choices (my words here); “except all but those I block”, “block all those except those I allow”, turn off federation (should say “turn off External Communication for crying out loud). This is not the federation I am discussing today.

Identity Federation or Single Sign One
This is the ability to utilize one set of credentials, your on-premise credentials, to access Office 365 services and features. There is a clear benefit to users when you set up single sign-on: First, it allows them to use their corporate credentials to access the services in Office 365 and secondly, users don’t have to respond to numerous challenges/sign in again or remember multiple passwords. In addition to the user benefits there are a number of benefits to administrators such as:

• Policy control: From one place the administrator manages password policies, workstation restrictions, lock-out controls, and more.
• Access control: The administrator can restrict access to Office 365 so that the services can be accessed through the corporate environment, through online servers, or both.
• Reduced support calls: Forgotten passwords are a common source of aggravation and support calls. When users have fewer passwords, they are less likely to forget them.
• Security: User identities and information are protected because all of the servers and services used in single sign-on are mastered and controlled on-premises.
• Support for strong (multi-factor) authentication

While identity federation will reduce end user headaches, save administrators time and ease their burden while empowering other capabilities, this is not what I want to cover today.

Exchange Federation or Rich Coexistence or Hybrid
We finally come to Exchange federation! First things first, this is the old term for what was properly called Rich Coexistence and is now, inaccurately, referred to as Exchange Hybrid deployment. Hybrid configurations, according to the rest of the World, describe a situation where some services, applications or “Finished Services” are running on premise with other beneficial or “Attached Services” running in the Cloud or hosted. A great example of this is running Exchange Server on-prem but leveraging Forefront Online Protection for Exchange (FOPE) in the Cloud. Another reverse example is SharePoint Online in the cloud with Rights Management (RMS) running on premise (which reading in Foley’s blogs last night, is built into SharePoint 2013). In these examples Exchange on prem and SharePoint online are “Finished Services” and email hygiene or FOPE in the cloud and RMS on prem are “Attached Services” the combination of these is a Hybrid configuration. Whew! Moving on, “Rich Coexistence” occurs when Exchange server on premise and an Exchange server in the cloud are connected via an Exchange Gateway (CAS/HUB server) now, wrongfully called the Exchange Hybrid server. When you run an Exchange Server on premise and an Exchange Server in the cloud you are normally doing this for one of two reasons;
1) You are conducting a staged migration and users will leverage both platforms for a period of time.
2) You are moving some of your users or types of users to the cloud and keeping some users on-premise, most likely, for a period of time that is forever.

No matter which of the two scenarios you are in this is normally called a user segmentation because you are segmenting users and determining which users will utilize the cloud and which users will run on prem. Put your nurses and physicians in the cloud, keep admin on premise, give truck drivers and factory folks cloud and keep your corporate folks on prem. You do this because it saves hard dollars, absolutely lessen the management burden, will provide new capabilities while offering the greatest flexibility and control. The reason you would deploy in rich coexistence are;

1) Free/Busy information can be shared (if you are on Exchange 2007 or later).
2) Erroneous mail tips will not be displayed (this person is outside your organization)
3) Message trace will be complete not “successfully handed off to another server”
4) Admins can perform “remote mailbox moves” to/from cloud or from the Exchange Management Console. Best of all, these moves are transparent to the end users!
5) Records Managers have one place for managing records
6) Mailboxes on-premise and Cloud can be searched from one tool.
7) Cross premise Outlook Web Access (OWA) access which is cool.

I am going to make two recommendations here; First, a customer should almost always configure rich coexistence/hybrid. Second, a customer should ALWAYS leverage the assistance of a Microsoft Office 365 Partner in configuring rich coexistence/hybrid.