Managing Email Address with Federated Users in Office 365 | Quisitive

I recently assisted a client of ours with implementing Identity Federation (single SignOn) with ADFS. This client was an original BPOS customer that was transitioned to Office 365. The client originally migrated to BPOS from on-premises Exchange 2003. Once we implemented Identity Federation all of the accounts became Federated users and now making any changes to email aliases. This has not been an issue for any of my previous Office 365 deployment as I have always setup the migration in a Hybrid Deployment with an Exchange 2010 SP2 server on-premises. With the Hybrid server, and configuring DirSync with the Hybrid Config checkmark, the email addresses for the users are replicated back to on-prem and can be modified with the EMC or directly via the ProxyAddresses attribute using ADSIEDIT or Attribute Editor in AD Users and Computers (assuming 2008 R2 DCs).

So for this client, when we installed and configured DirSync, the Hybrid Deployment checkmark was greyed out and unavailable. At the time I figured this was just because the Forest/Domain was not prepped for Exchange 2010 SP2, and really didn’t think much of it. Well that situation didn’t take long for that greyed out option to bite us. We wanted to switch around some email addresses and first attempted via the Exchange Online Management Portal and we get an error that cannot modify Federated user properties and the changes must be made on the on-premises Active Directory user account. Well that is pretty hard seeing how none of the email addresses are able to be sync down to the AD user account.

PowerShell to the Rescue! I needed to get the EmailAddresses from the Online account replicated to the AD Account ProxyAddresses. So what I did was create a PowerShell script that does this for me.

I designed the script to run from a Server 2008 R2 domain controller. The script starts out by importing the Active Directory cmdlets. It then creates a remote PowerShell session to Exchange Online. I then have it get all of the mailboxes in Exchange Online into the variable $Mailboxes. I then loop thru each Mailbox and connect to the online mailbox using the user UPN. The script then gets the EmailAddresses from the online mailbox and sets them into the $OnlineAd variable. The script then cycles through all the email addresses and adds them to the on-prem AD account ProxyAddresses attribute.

The script is below:

import-module activedirectory

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

$mailboxes = get-mailbox –ResultSize Unlimited

foreach ($MB in $Mailboxes)


                $UPN = $mb.UserPrincipalName

                $OnlineUser = Get-mailbox $mb.UserPrincipalName

                $OnlineAdd = $onlineUser.EmailAddresses

                foreach ($add in $OnlineAdd)


                                get-aduser -filter {UserPrincipalName -eq $UPN}|set-aduser -add @{proxyaddresses = $add}



So now my client can administer the email addresses for the Federated users by changing the ProxyAddresses attribute for the AD account. I warned them only to change the Addresses the are have “SMTP”, the primary or reply to address, or “smtp”, the alias addresses; and ensure they do not make any changes to any other type. I think I smell an app I could write to make the changing of only the smtp addresses via a GUI PowerShell interface.

So I blogged a little while ago about an issue with enabling Online Archive for a Migrated user in Office 365 Hybrid Deployment So I came up with a work around to fix this:

Login to Domain Controller (assumes 2008 R2 version) if not you will need to use ADSIEDIT.MSC

Open Active Directory Users and Computers

Browse to the user account you want to have enabled for Online Archive

Open the Account properties and choose the Attribute Editor tab (if this does not show up select the View menu from ADUC and ensure Advanced Features in selected)

Locate the MSExchangeVersion Attribute

Replace the value with 44220983382016

Login to Hybrid Exchange 2010 SP2 server

Launch the Exchange Management Shell (EMS)

Run the following command, replacing USERNAME with the user’s login name

Enable-RemoteMailbox USERNAME-Archive

Force a DirSync

This has worked well for me and I have not run into any issues with manually setting the MSExchangeVersion Attribute.

I am running into a problem trying to enable Online Archive for a migrated mailbox and getting this error:

[PS] C:\Windows\system32>Enable-RemoteMailbox smcneill -Archive

property ArchiveGuid can’t be set on this object because it requires the object to have version 0.10 ( or later. The object’s current version is 0.1 (8.0.535.0).

+ CategoryInfo : NotSpecified: (0:Int32) [Enable-RemoteMailbox], InvalidObjectOperationException + FullyQualifiedErrorId : 55181214,Microsoft.Exchange.Management.RecipientTasks.EnableRemoteMailbox

The environment I am working in is a Exchange 2007 on-premises with a Exchange 2010 SP2 (RU1) Hybrid server. The mailbox move to O365 works fine and so does ADFS SSO. Researching this seems that the only fix is to disable and then re-enable the remotemailbox, but this wipes the exchange info requiring the remote email address (and probably the LegacyDN) to be reset. This to me is not the best option.

When I look on the Mailbox online it has the proper version, so this appears to be a problem with the Migration process or DirSync not writing back the correct version to the RemoteMailbox object.

Any other thoughts on this?

Note: This post looks at the planning phase for ADFS 2.0 on Office 365 Beta for Enterprises. Configuring is covered in a separate post.

Office 365 supports identity federation which allows true single sign-on capabilities. This is achieved through Active Directory Federation Services (ADFS) 2.0. With identity federation, users can enter their Active Directory credentials to access Office 365 services.

An ADFS 2.0 solution consists of the following components:

There are three basic ADFS 2.0 deployment options for Office 365 with differing levels of access and availability:

  1. Single server configuration
  2. ADFS 2.0 server farm and load-balancer
  3. ADFS 2.0 Proxy server(s) for offsite users

Benefits of implementing ADFS:

The following are different sign-on experiences when using Federated Identity depending on location and status of computer:

EnvironmentSign-in Experience
Outlook 2010 on Windows 7No prompt***
Outlook 2007 on Windows 7Sign in each session*
Outlook 2010/2007 on Windows Vista or XPSign in each session**
Exchange ActiveSyncSign in each session**
POP, IMAPSign in each session**
Web Experiences: Office 365 Portal, Outlook Web App, SharePoint Online, Office Web AppsNo prompt
Office 2010/2007 using SharePoint OnlineNo prompt
Lync OnlineNo prompt
Outlook for Mac 2001Sign in each session**

* – Outlook 2007 will be updated after Office 365 has been made generally available to have same experience as Outlook 2010 on Windows 7

** – When first prompted, you can save your password for future use.  You will not receive another prompt until you change the password

*** – In beta period, you will be prompted when first accessing the services

Authentication Mechanisms when using Federated Identity:

ApplicationAuthentication Mechanism
Web browserWeb sign in, WS-Trust and WS-Federation (ADFS 2.0)
Outlook 2010 on Windows 7Web sign in, WS-Trust and WS-Federation (ADFS 2.0)
Outlook 2007 on Windows 7Basic over SSL, authenticated via the ADFS 2.0 proxy
Outlook 2010/2007 on Windows Vista and XPBasic over SSL, authenticated via the ADFS 2.0 proxy
Exchange ActiveSyncBasic over SSL, authenticated via the ADFS 2.0 proxy
POP/IMAP/SMTP clientBasic over SSL, authenticated via the ADFS 2.0 proxy
Lync OnlineWeb sign in, WS-Trust and WS-Federation (ADFS 2.0)

Note that Outlook 2007 is planned to be backported to support WS-Trust and WS-Federation after the beta period.

Two-Factor Authentication can be achieved for Office 365.

The following are requirements of ADFS 2.0:

Capacity Planning

When identity federation is enabled and configured in Office 365 there is no fall-back to a different form of authentication if ADFS servers fail. This means that if ADFS servers are not available, users will not be able to authenticate with Office 365 servers. It is very important to configure a highly available ADFS solution utilizing multiple servers and hardware or software load balancing. It is also critical to implement a monitoring solution for the ADFS servers. This includes both the internal ADFS servers and the ADFS proxy servers.

Namespace Planning

ADFS currently only allows for one namespace per ADFS farm/instance. If your company will support multiple namespaces for authentication, you will need to implement an ADFS infrastructure for each. Only internet routable domains that have been validated within Office 365 can be used in an ADFS deployment. If your organization has a non-routable domain for the AD infrastructure (such as .local, .priv, etc), you will need to add a UserPrincipalName (UPN) suffix in AD and configure each user with that UPN suffix (discussed in Part 2).


Part 1 of this post introduced ADFS 2.0 in relation to Office 365 and discussed environmental requirements required to implement.  Part 2 will walk through the configuration of ADFS 2.0 and Office 365.