When you run the Hybrid Configuration wizard even in a tenant that uses Federated login, you might find that even if you’ve chosen only one of your federated domains, the redirect URL to Office 365 is set to your tenant domain (onmicrosoft.com) rather than the federated domain you chose in the wizard or would prefer to use:
If you’ve not this before, this results in the end use having to enter their User Principal Name at the Microsoft Online Services login page, before being redirected back to the ADFS services:
So the first thing you might do is the following to set your TargetOWAURL to the correct value:
Set-OrganizationRelationship "On Premises to Exchange Online Organization Relationship" -TargetOwaURL:https://outlook.com/owa/federateddomain
This results in the smoother (or even super-smooth if you check out my previous article) experience where the end use is redirect straight to AD FS login.
If you need to update the Hybrid Configuration – for example to add or change IP addresses of External Transport Server IP addresses, update the certificate or add/remove Hub Transport or Client Access Servers, then you’ll re-run the Hybrid Configuration Wizard.
A seemingly innocuous change to an IP address for outbound SMTP servers that doesn’t affect the organization relationship itself will result in the Redirect URL for OWA being set back to the tenant domain resulting in the scenario outlined above.
So, just bear that in mind when you need to re-run the Hybrid Configuration wizard.. It’s simple to deal with by ensuring your reconfigure your TargetOWAURL, just make sure you don’t forget
Earlier this week, Microsoft announced the next generation of their cloud online services, Office 365. This new suite of online services will offer Exchange Online, Sharepoint Online, Lync Online (the next generation of Office Communications Server) and the desktop Office Professional Plus suite.
When it comes to messaging, the next generation of Exchange Online provides Exchange 2010 SP1 along with mailbox sizes up to 25GB, online archiving features, Voicemail integration with On Premises PBX's and enterprise email features such as retention policies and cross-mailbox search.
One of the fundamental differentiators of Office 365 was announced on the Exchange Team Blog; the ability to integrate closely with On Premises Exchange. ADFS 2.0 powered Single Sign On will enable what has been known as "Connected Federation". This allows users to login using their On Premises Active Directory credentials, Mailbox Moves either way between On Premises and Exchange Online, Cross Premises Mail Tracking & Routing, and management of both On Premises and Exchange Online from from a familiar toolset - a single Exchange Management Console, and ECP and Exchange Management Shell. As well as all this, more basic, critical features like availability (free/busy) and Calendar and Contact sharing will be supported via Federated Sharing.
So - why would a cross-premises (where some mailboxes remain On Premises and some are hosted on Office 365) have a business case, especially where it hasn't been considered in the past? The key reason to consider a cross-premises deployment is so your business can take advantage the best of both worlds. It's already gaining traction in the server virtualization area (just look at what VMware are aiming for) and it's a great fit for messaging. When looking to move to Exchange 2010, a lot of enterprises are considering consolidating their Exchange infrastructure and avoiding managing mailbox servers at small branch offices. Hosting mailboxes in the cloud makes a lot of sense in this situation as it can remove a major point of failure - the internet or WAN links into the regional or main HQ. Road warriors commonly only need an internet connection, so again, hosting their mailbox using Office 365 makes a lot of sense. However - in larger offices, where the bandwidth required for all Outlook Clients to connect out to the internet, or where a loss of connectivity to Exchange could paralyse the business, it still makes sense to host Exchange On Premises. Utilizing a cross-premises deployment with Office 365 could save money and effort when it comes to those branch offices and mobile users, but also allows the user mailboxes to be moved back On Premises (or vice-versa) as the user's role in the organisation changes.
Of course, there are some questions and possible caveats that still need to be answered by Microsoft and assessed against your business needs before even thinking about whether Office 365 will be appropriate; for example, how are 25GB Office 365 mailboxes managed? If a user gets a new laptop, will they need to sync tens of gigabytes of data with their local copy of Outlook? Online Archives have been mentioned by Microsoft, so one might assume the 25GB will be split between the primary mailbox and the Archive. If so, it will be interesting to find out what those ratios are so the impact of an OST sync can be taken into account. The other critical area is backups. Anyone reading up about Exchange 2010 will no doubt have read that Microsoft is now advocating the use of 3+ Database Copies instead of backups, leaving "Recover from Deleted Items" the only option for recovering deleted data. Currently, they employ this method of backup on the "beta" of Office 365's Exchange Online, Live@EDU's Outlook Live so I wouldn't be too surprised if this is the case for Office 365 also.
So where does these leave the future of On Premises messaging? I think, given even the sort of caveats mentioned above, Office 365 and other cloud based services have a compelling business case, simply because the capital expenditure required to implement isn't required. Many On Premises deployments today take into account what the business projects it will need over the next 3 to 5 years and the appropriate hardware to meet the worst-case scenario is bought up-front whether it will be used to it's full capacity or not.
I believe that a more appropriate vision for the future of Exchange On Premises deployments has to be able to justify itself against cloud services cost models like Office 365's, which are targeted toward operational expenditure. In the future, On Premises Exchange deployments could also aim to look at this model where the business is charged back based on what they are actually using rather than buying it all up-front. Of course - initial investment is needed, but by only buying the capacity needed initially - thin provisioning mailboxes (i.e. providing larger mailbox quotas than the underlying disk storage allows) will reduce those costs considerably. This model of chargeback and building out capacity as it's required is already in widespread use in the virtualization area, and as someone who runs such an environment, I can say it works well and is popular with customers. Even if this sort of model doesn't equate exactly, it does provide a model to ensure costs can be compared with cloud messaging offerings fairly, and provides a little motivation to move away from over provisioning and wasted storage.
Another question typically on the minds of IT staff is "will a move to Office 365 cost me my job?". My personal opinion is that it most cases, no it won't - at least no more than a move to On Premises Exchange 2010 will. In larger enterprises, there may be some re-deployment where large Exchange Admin teams exists - but due to massive improvements in the product quality since Exchange 2003 (and to a lesser extent, Exchange 2007), Exchange 2010 takes a lot less work to keep running. A move to Office 365's Exchange Online service might require a similar level of planning as a move to Exchange 2010 (and will in most situations involve some Exchange 2010 servers in the mix anyway), and on-going administration still remains. Cloud services like Email might be sold as light-touch, especially by Google, but the reality is that the end users still require the same things. Someone still needs to do the IT work to create mailboxes (or automate that process), deal with shared mailboxes and distribution groups, override access rights and troubleshoot mail delivery issues. These can all be delegated - but they also can be delegated in the exact same way with On Premises Exchange 2010.
Whist it's common knowledge the Office 365 re-brand takes BPOS (Business Productivity Online Mouthful) under it's wing, it's definitely worth noting that Live@EDU is also being brought into the fold. Why does this matter? Because by understanding that Outlook Live and Live@EDU are basically the production beta for Office 365, you can start learning more about what Office 365 will offer straight away. For example, I've recently published a post about Federated Sharing with Outlook Live which I believe will also (with small modifications) apply to Office 365's Exchange Online. I also worked with Microsoft on a Q&A about what my employer can already do with Live@EDU, which includes some of these very benefits.
So, what does this all mean for Google? I think it's obvious that what Office 365 brings to the table will be a quantum leap over what Google Apps's GMail has provided so far. Up against the rich cross-premises, enterprise functionality offered by Office 365, GMail is more clearly defined as a consumer product competing in the enterprise market. That said, I am certainly not dismissing Google; for example, they have supported SAML 2.0 SSO for Google Apps for a long time, and provide excellent APIs that allow you to write your own rich provisioning systems.
Google also have a big advantage when it comes to smaller businesses, the sort of size where the company doesn't want or need internal IT infrastructure. These are traditionally the kind of companies who otherwise would stamp hotmail, gmail or yahoo email addresses onto their business cards and for them, Google is a well known brand and is easy to use. Office 365 will have some ground to make up here, but I think a major battle ground will be in the SME sector, competing in ground where server provision was previously provided by a Windows Small Business Server installations.
However Google still have massive hurdles in the enterprise to overcome. Take Jaguar, who faced problems when they first migrated, then had to overcome a user revolt, according to the comments from Jaguar employees here. Eventually Jaguar had to re-train it's staff to use Google Apps, according to this press release. Reports like this don't help the case for moving systems to Google's cloud (and neither do the incorrect cost comparisons) and don't forget, Google doesn't provide an exit strategy either. I never thought I'd say this a few years ago, but at the moment Microsoft provides the least lock-in for enterprise email in the cloud.
Comments for/against Google aside, I certainly think that Office 365 is a very interesting development and it will be worth watching what happens next. If you haven't registered for the beta of Office 365, you can register here.
As I'm very much into enabling cross-premises deployments (and have built my own solution against On Premises Exchange and the current certificate-based SSO solution for Outlook Live) I think that ADFS 2.0 is an important enabler when it comes to allowing transparent user access to services wherever they are. It's my understanding that Federation is on it's way to BPOS and Outlook Live, so if you're doing a deployment where you'll want users to login to OWA at a single point, it's well worth investing some time in looking at Ken's article and running through the setup in a lab environment.
Anyway - enough from me, happy reading! Access OWA with ADFS
Set up Federated Free/Busy and Calendar Sharing between Exchange 2010 SP1 and Outlook Live [Updated]
As organizations move to make use of cloud based services, like Exchange Online or Outlook Live, it’s pretty important to be able to integrate both the on-premises service and the cloud service so that end-users can continue to work as normal. That’s especially important with a service like Outlook Live, aimed at Education institutions, where typically staff, faculty and some students will continue to be hosted on-premise and the majority of students will be hosted in the cloud. A seamless experience makes life easier for users and thus easier for IT…
So, with Outlook Live and Exchange 2010 On-Premises there is a pretty good opportunity to get Exchange working seamlessly between both systems. I’ll be covering a unified login in a further article (once I’ve re-written the code we use in-house into a re-distributable form). But for now, I’m focusing on the user experience with free/busy and calendar sharing.
One of the areas users might expect to “just work” is free/busy and calendar sharing between on-premise and cloud. The options are there, it looks like it tries to do it.. But the end user just gets unfriendly error messages and “permission denied” errors. To get this up and running in Exchange 2010 SP1 is actually now pretty simple. Although SP1 allows self-signed certificates for Federation, you cannot use these with Outlook Live federation, and you'll need to perform an extra step. However it's still fairly straightforward…
First things first, we need a few things in-place and working already before we can get going. The main pre-req is Autodiscover, but I won’t cover how to set this up, as it's is covered in detail elsewhere on the good old ‘net..
Autodiscover working for On-Premises for the domain you want to use (using DNS names, not a service records)
Autodiscover working for Outlook Live for the domain you want to use (again, using DNS names, not a service record)
Separate domains for on-premises and Outlook Live (I’m testing getting shared working – follow up article to come)
Exchange 2010 CAS Connectivity to *.outlook.com
Org admin rights on Exchange 2010 SP1 and Tenant Admin rights on Outlook Live, along with Powershell access to both.
Access to manage the DNS for both domains and add TXT records.
External URL setup and tested for Exchange Web Services / WebServicesVirtualDirectory
Once that’s all setup and available, you should be ready to go..
Setting it up
To keep things simple, we’re not going to do anything too complicated, we’re going to set things up so all users in both on-premises and Outlook Live can see each other’s free/busy and share calendars (and contacts). Also, for the purposes of this article it’s assumed no Sharing Policy is setup already.
On our test setup, we’ve got two domains:
On Premises: rootuk.net
Outlook Live: test.rootuk.net
Basically we need to create four things on-premise:
- A Federation Trust to authenticate us against the MS Federation Gateway
- A new sub-domain ExchangeDelegation for the account namespace (in this example, ExchangeDelegation.rootuk.net)
- An Organization Relationship to say Outlook Live can see in for Free busy
- Finally a Sharing Policy to allow on-premise users to share their calendars with Outlook Live users.
In Outlook Live the trust with MS’s Federation Gateway is there by default so we just need the Organization Relationship to allow On-premise to see in and the Sharing Policy to allow the Outlook Live users to share with On-premise users.
First, we’ll setup the on-premise config, then get the Outlook Live stuff done. Afterwards we’ll test everything works.
On Premises Config
Step One – Setup a New Federation Trust using a trusted certificate [Updated 10th Nov 2010]
To setup a Federation Trust for use with Outlook Live, you need to use a certificate from an approved certificate authority. As this list is quite short, you may find it doesn't include you current SAN/UCC certificate provider (for example, if you use the JANET Certificate Service), however this isn't a major issue. The certificate you use for Federation doesn't have to be the same one you currently use for your other Exchange services, so fear not - you don't need to buy a new, expensive SAN/UCC certificate. I've found the cheapest one from GoDaddy works just fine.
If you've already got a supported certificate, you can skip this part and just use your existing certificate thumbprint for the New-FederationTrust command. Otherwise, to generate a new request for a single domain certificate just to use for Federation, use New-ExchangeCertificate:
New-ExchangeCertificate -GenerateRequest -SubjectName 'o=rootuk.net, cn=rootuk.net' -DomainName rootuk.net -FriendlyName 'Third Party Federation Certificate' -PrivateKeyExportable $true
Next, follow the standard process for your CA, by requesting, then downloading the certificate from the third party certificate provider:
After downloading the certificate, you now need to complete the certificate request by importing the certificate into Exchange:
Import-ExchangeCertificate -FileData ([Byte]$(Get-Content -Path c:\cert\certificate.crt -Encoding byte -ReadCount 0))
Note down the Thumbprint in the output, and then create the Federation Trust using that thumbprint value. Note that we’re choosing the "Legacy Provisioning Service" as part of this process. This is why we can't use a self-signed request – these only work against a new “Business” gateway. Outlook Live currently works against a legacy “Consumer” gateway and the -UseLegacyProvisioningService parameter switches us to use that one.
New-FederationTrust -Name 'Microsoft Federation Gateway' -Thumbprint 'thumbprint' –UseLegacyProvisioningService
NB.. You'll see in that example above I got an error the first time. This does happen occasionally and I've seen it reported in forums too. The error is "The request failed with HTTP status 403: Forbidden". Just retrying the command should work.
Next, we need to setup a record in DNS for the application ID using the ExchangeDelegation sub-domain and the main On-Premises domain we wish to use for federation. As of SP1, it's possible to use the "Federated Domain Proof" DNS TXT record, but as we're using the legacy method, we will use the Application ID method.
To add the App ID, you need to add a DNS record that contains your Application ID (shown as "ApplicationIdentifier" in the output from "New-FederationTrust", or by entering "Get-FederationTrust") and enter it in the form "AppID=<yourappid>".
If you use Windows DNS, it goes a little something like this:
Once those are both in, reload/HUP your DNS and make sure you can resolve it, both from your Exchange servers and from the outside world. The following command should work:
nslookup -querytype=TXT ExchangeDelegation.rootuk.net
nslookup -querytype=TXT rootuk.net
Now we’ve got the Federated Trust and DNS record sorted, we can get ourselves properly setup with the Federated Gateway. To do this, we first need to add the accepted domain of the Federated namespace:
New-AcceptedDomain -Name 'Federated Namespace' -DomainName 'ExchangeDelegation.rootuk.net' -DomainType 'Authoritative'
Next, we first use the Set-FederatedOrganizationIdentifier command to configure the account namespace:
Set-FederatedOrganizationIdentifier -DelegationFederationTrust 'Microsoft Federation Gateway' -AccountNamespace ExchangeDelegation.rootuk.net -Enabled:$true
Finally, add the main domain name of the On Premises domain:
Add-FederatedDomain -DomainName 'rootuk.net'
Assuming that completes successfully, we can move onto the next step..
Step Two– Setup the On-Premise Organization Relationship
The next step is to allow our Outlook Live domain to see our On-premise Free/Busy info. You can do this via Powershell or the Exchange Management Console:
Test that you can get the federation info for your Outlook Live domain. If you get an error, run the command again with the -Verbose parameter for a detailed error and check your autodiscover setup for Outlook Live:
Next, configure the relationship. The LimitedDetails option below is the most open setting for the relationship, which means any user who has chosen to show that much detail will also make it available to the Outlook Live tenant.
Get-FederationInformation test.rootuk.net | New-OrganizationRelationship -Name "Outlook Live" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel:LimitedDetails
If you'd rather configure via Exchange Management Console:
Navigate to Organization Configuration, and select the Organization Relationships Tab. Right click in the whitespace and choose “New Organization Relationship”:
in the New Organization Relationship window, Give a the new relationship a friendly name (e.g. Outlook Live). Select the checkbok "Enable this organization relationship", then choose to enable free/busy access. Choose “Free/busy access with time, plus subject and location” to select the widest access. This means any user who has chosen to show that much detail (i.e. people can see that on-premise right now) will also share it to Outlook Live.
Next enter the Outlook Live domain in the Automatically discover configuration information text box, and press Next.
Check for any errors, and press Finish. If there are errors, and it isn't a typo, then it’s likely to be an Autodiscover issue - but you'll find out most detail on the possible cause if you use the Powershell instructions above.
The new relationship should now be listed underneath Organization Relationships:
Step 3 – Setup the Sharing Policy
To enable our on-premise users to share their information with Outlook Live users we need a sharing policy setup. While you can setup multiple sharing policies and assign them to different users, for this basic sharing we’re going to modify the default sharing policy
First, check your settings. Note down the existing Domains value.
Get-SharingPolicy 'Default Sharing Policy'
Replace the domains value on the Default Sharing Policy setting the original value (or remove it, if you want) and adding the Outlook Live domain. For the Outlook Live domain we're setting the maximum scope for sharing:
Set-SharingPolicy 'Default Sharing Policy' –Domains '*:CalendarSharingFreeBusySimple', 'rootuk.net:CalendarSharingFreeBusyReviewer, ContactsSharing'
If you'd prefer to configure the sharing policy via the Exchange Management Console:
Navigate to Organization Configuration > Mailbox > Sharing Policies, then right click the Default Sharing Policy, then choose Properties:
In the Default Sharing Policy Properties, choose “Add”, then specify the Outlook Live domain. To allow for the maxium level of detail to be shared by individual users, select the last option “Calendar sharing with free/busy information plus subject, location and body, Contacts sharing:
And that’s it for On-Premise. Next.. We need to get the hosted environment setup with with the corresponding parameters:
Outlook Live Setup
For the Outlook Live setup you have to use Powershell – Exchange Management Shell isn’t supported when managing your hosted tenant. If you’re not sure how to connect Powershell see the guide on the Outlook.com help site, but it basically looks a little like this:
Step 1: Setup the Outlook Live Organization Relationship
We get to miss out the first step that we had to do on-premise, setup of the federation trust, because as a tenant of the outlook.com Exchange environment this has already in place.. So we can skip to getting an organization relationship setup with our on-premise domain.
First, we check that we can indeed discover the correct settings by using the Get-FederationInformation command, specifying the on-premise domain:
The output from the command should show details matching the Organization Identifier and Application URI we setup earlier, along with the details of the on-premise Autodiscover environment.
If it returns a failure you may need to double check your Autodiscover settings for the on-premise environment, or in some cases you may need to give it a little while (if you just setup your Federation Trust on-premise) and try again. For example, in my production environment it took around an hour for my production Outlook Live tenant to be able to discover the Federation Information although my test domains could see the same information without any issues.
So.. After you’ve tested Outlook Live can discover the Federation Information, it’s onto actually creating the Organization Relationship. The command is exactly the same as on-premise,we are really just swapping the domain:
Get-FederationInformation rootuk.net | New-OrganizationRelationship -Name "On-Premise" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel:LimitedDetails
Step 2: Setup the sharing policy
Finally, it’s on to the final step – getting the sharing policy sorted. Check out what the Default Sharing Policy currently is before we go and add our on-premise domain:
Then replace the Domains list for the Default Sharing Policy with a value that includes the on-premise domain. In the example below, I’m keeping the settings that were already there and adding the on-premise domain. For consistency, I'm also keeping the same sharing level as set on-premise:
Set-SharingPolicy 'Default Sharing Policy' -Domains '*:CalendarSharingFreeBusySimple', 'rootuk.net:CalendarSharingFreeBusyReviewer, ContactsSharing'
After that, it should all be done. Give it a little bit of time (say, 15 minutes) for everything to take effect and we should be ready to have a play..
Testing it out
For testing purposes on my two domains, on-premise “rootuk.net” and Outlook Live “test.rootuk.net”, I’ve created test accounts in each –“firstname.lastname@example.org” and “email@example.com”. For the screenshots I’ve used OWA, but it works equally well in Outlook.
The first test is for Free/Busy. I’ve created a few test appointments in both calendars and you’ll see availability works just as if the user was on-premise:
In Outlook Live, scheduling a new meeting with the on-premise user as an attendee:
Next, via on-premise Exchange 2010 SP1, with our Outlook Live user as an attendee this time:
The second test is to check it is possible to share a calendar either way, and this is where it strays slightly away from the full range of options available to users within a single environment.
The limitations we’ve got mean that the user must share the calendar using OWA or Outlook 2010, and must use the “share this calendar” options rather than setting permissions directly. The recipient of the permission must add the calendar using the resulting email (they can’t just add it by name) and it’s read-only. this of course means the process can’t be easily automated, but it does allow users to use a common workflow to share folders, via the “share” options.
Sharing a calendar in Outlook Live:
On-premise user receives the sharing invitation and chooses “Add this calendar” to add it:
After adding the calendar, it’s shown in red (in OWA, anyway) while the server retrieves the calendar:
After a minute or so, the Outlook Live calendar shows up alongside the On-premise calendar:
Finally, let's test it from On-premise to Outlook Live:
Select the Calendar’s “Share” option to share the calendar (it's worth noting that the OWA UI has changed between RTM and SP1.. but I digress):
Over in Outlook Live, the Outlook Live user receives the invitation and again, chooses the “Add this calendar” link:
After choosing to add the calendar, the on-premise calendar shows (again after a minute or so to do the first sync) alongside the Outlook Live calendar:
Contacts sharing is again a similar process, although it must be shared using Outlook 2010. Simply right click a contacts folder and choose Share>Share Contacts:
And that’s it – hopefully this will work for you, but if you have any questions or any issues, just use the comments form below.
Update - 10th November 2010: The original article used the -MetaDataURL parameter to use a self-signed certificate with the old "consumer" gateway. This is no longer valid. The article has been updated to reflect the new process, which requires an acceptable third-party certificate and the -LegacyProvisioningService parameter. If you have used the -MetaDataURL parameter to setup Federated Sharing you should remove and re-create both the organizational relationship (both sides) and the federation trust (on premises) using the updated information in "Step 1" of the On Premises Config. You do not need to remove/re-create the sharing policy.
Update - 15th December 2010: The article has been updated to use ExchangeDelegation.domain.com for the Federated Namespace based on advise from the Exchange team. This is a best practise and pre-req for cross-premises Free/Busy.