Earlier this week at the Microsoft Exchange Conference (MEC 2012) I led a session titled Configuring Rights Management Server for Office 365 and Exchange On-Premises [E14.314]. This blog shows three videos covering installation, configuration and integration of RMS with Exchange 2010 and Office 365. For Exchange 2013, the steps are mostly identical.
Installing AD RMS
This video looks at the steps to install AD RMS. For the purposes of the demonstration, this is a single server lab deployment running Windows Server 2008 R2, Exchange Server 2010 (Mailbox, CAS and Hub roles) and is the domain controller for the domain. As it is a domain controller, a few of the install steps are slightly different (those that are to do with user accounts) and these changes are pointed out in the video, as the recommendation is to install AD RMS on its own server or set of servers behind a IP load balancer.
Configuring AD RMS for Exchange 2010
The second video looks at the configuration of AD RMS for use in Exchange. For the purposes of the demonstration, this is a single server lab deployment running Windows Server 2008 R2, Exchange Server 2010 (Mailbox, CAS and Hub roles) and is the domain controller for the domain. This video looks at the default ‘Do Not Forward’ restriction as well as creating new templates for use in Exchange Server (OWA and Transport Rules) and then publishing these templates so they can be used in Outlook and other Microsoft Office products.
Integrating AD RMS with Office 365
The third video looks at the steps needed to ensure that your Office 365 mailboxes can use the RMS server on premises. The steps include exporting and importing the Trusted Publishing Domain (the TPD) and then marking the templates as distributed (i.e. available for use). The video finishes with a demo of the templates in action.
Lets imagine a scenario where you are using an on-premises Exchange Server and users’ use Outlook Web App, and then you move some mailboxes to the Office 365 cloud with Hybrid Coexistence enabled. The user might not know their mailbox has been moved and so yesterday they went to https://mail.company.com/owa, but today they need to visit https://outlook.com/owa/company.com (where company.com is the domain name in your login name).
But becuase the user does not know that their mailbox has been moved when they visit https://mail.company.com/owa they get an error that their OWA URL is out of date.
To fix this, and provide the user with the correct URL (https://outlook.com/owa/company.com) then you need to set the TargetOwaURL property of the Organization Relationship that you have configured for your Office 365 service domain.
Set-OrganizationRelationship name -TargetOwaURL https://outlook.com/owa/company.com
Now when users login with an account that has been moved to the cloud they will be told that their mailbox has moved, and that they should visit https://outlook.com/owa/company.com.
Some organizations though have an issue with this URL – it does not mention the company name in the domain name bit, and a name such as http://webmail.company.com/owa would be preferred for mailboxes moved to the cloud. To present the user with this URL after they login to on-premises OWA or for a URL that you can just tell them to use you need to do two things:
- Create a CNAME record in DNS for webmail that has outlook.com as the target FQDN. The CNAME record can be anything that is not already in use for the domain (for example it could be mail if that is not in use).
- The TargetOwaURL property of the Organization Relationship needs to be http://webmail.company.com/owa. The TargetOwaURL must finish with /owa or the on-premises OWA redirect page will error and the domain name used must be the domain name in your login name.
The outlook.com server will take the CNAME value provided by the browser and do realm discovery on this name – that is it will redirect you to the correct login server for your domain.
Or indeed, not working at all! I had the issue of it working one way only (On-Premise Exchange organization > Office 365) but the other way (cloud to on-premise) did not work at all.
The answer is shown in this video
This covers the reasons why Free/Busy (and the other federation features of MailTips, archive and move mailbox might not work both ways in a Hybrid Coexistence setup for Office 365 or between two Exchange on-premise organizations.
The reason I found was the Organization Relationship contained the wrong list of domains. There are three domains (at least) that are needed in the organization relationship. These are:
- Primary SMTP Namespace Domain (i.e. fabrikam.com)
- Namespace for other organization (i.e. service.fabrikam.com)
- Exchange Delegation domain (i.e. exchangedelegation.fabrikam.com)
In the organization relationship on-premise (or Org A if you are doing two on-premise organizations) set the following domains after the relationship is created. This includes the primary SMTP namespace and the service namespace for the other organization. This can be set with the following Exchange Management Shell cmdlet:
Set-OrganizationRelationship -Identity “To Cloud” -DomainNames “service.fabrikam.com”,”fabrikam.com” -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True –TargetOwaUrl https://outlook.com/owa/fabrikam.com -ArchiveAccessEnabled $True –MailboxMoveEnabled $True
In Org B (or on Office 365) use a similar cmdlet, but use the Exchange Delegation namespace and the primary SMTP domain. Also Office 365 does not let you set the MailboxMoveEnabled property to $True
Set-OrganizationRelationship -Identity “To On-premises” -DomainNames “exchangedelegation.fabrikam.com”,”fabrikam.com” -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True -ArchiveAccessEnabled $True
Supposedly Service Pack 2 for Exchange 2010 will do all this and more for you with the Hybrid Configuration Wizard, but its always useful for troubleshooting to discover what changes and why when you run a wizard to do things!