This is a deep dive presentation based on real-world experience implementing Hybrid Exchange environments, presented at the Office 365 UK User Group on the 9th April, 2013.
SkyDrive version here: http://sdrv.ms/10Mlf8A
The Exchange Admin Center The EMC and ECP rolled into one Easier browser-based "single pane of glass" If you're Exchange 2010 on-prem, then EMC can still connect Assuming you have Exchange 2013 on premAlong with Exchange Online PowerShell
Improved Client Experience Full ground up re-write Great expereince across new devices like tablets and mobiles Windows and iOS tablets have Best support Android is Light IE7 is downgraded to Light Access Offline mode for OWA Supported by IE10 on Win 8 Supported by Chrome on XP and above plus Mac Supported by Safari on Mac And of course apps both OWA and Outlook 2013 OWA performance issues with IE8, so upgrade as high as possible Check Light Good and Best support here: http://technet.microsoft.com/en-us/library/jj150522(v=exchg.150) Can't disable OWA for users at present http://support.microsoft.com/kb/2835562
Hybrid Features have no major improvements Stuff's upgraded.. But Federation, Mailbox moves are effectively the same
Address Book Policies What's ABP? GAL Segregation Introduced On-Prem in Exchange 2010 SP2 Available in Exchange 2013 and Wave 15 You need to be assigned the Address Lists RBAC role Documentation just updated: http://technet.microsoft.com/en-us/library/hh529931(v=exchg.150).aspx Was missing originally due to an oversight New-ManagementRoleAssignment -Role "Address Lists" -User admin@exchlabs01.onmicrosoft.com
Site Mailboxes A mailbox for a SharePoint Site Some people don't want to keep everything in Exchange! Collaboration add-on to SharePoint, in a way Exposed via the SharePoint Site and within Outlook 2013 No cross-premises story - either on-prem, or in the cloud.
Public Folders New Improved Modern Public Folders PF live within Mailboxes to get rid of the old PF issues Migration story from on-prem in the works from Microsoft, not available yet Migrate to Exchange 2013 Modern Public Folders, then to the Cloud Suggested to keep each PF Mailbox under 15GB for migration to the cloud Bear in mind limits of 50 PF mailboxes with a combined size of 1.25TB per tenant http://technet.microsoft.com/en-us/library/jj819283.aspx
Compliance In-Place Hold replaces Legal Hold Query-based search and hold features Time-based hold features E.g. place all mailboxes within Finance under hold for 6 years Deleted Mailboxes under hold remain using the Inactive Mailboxes features No cost http://blogs.technet.com/b/exchange/archive/2013/03/21/preserve-mailbox-data-for-ediscovery-using-inactive-mailboxes-in-exchange-online.aspx
Exchange Online Protection Replaces FOPE Integrated with Exchange Online's EAC Can be licenced for on-prem only as direct FOPE replacement, requires DirSync etc Evaluate carefully as Exchange terms like Transport Rules replace Policies
Why Hybrid Exchange 2010 needs itEase of Pilot You've got a way back Test, test and test again Transition, not migration What's the lowest impact on users Is user experience important? Whos' going to manage the migration Use the skills you have, don't learn now ones for a migration you'll only use once
Why not Hybrid Of course it's not always needed Smaller migrations - cutover or staged A cutover - you're planning on moving everything in one go The big bang approach can work! And of course, you don't always have an on-premise Exchange IMAP migrations But don't - they can work, but look at MigrationWiz and similar Quest is great, but for smaller organizations too complicated
Challenges for Exchange 2007 and 2003 Organizations To do it propoerly, you're looking at a migration of Client Access services Let's walk through that Implementing a legacy namespace Then.. Moving AutoDiscover and other servciesEffectively, you're doing a lot of the hard work for an Exchange 201x migration What are your options Wave 15 is here, so you're looking at Exchange 2010 SP3 or Exchange 2013 CU1 Unless you're 2003, in which case it's 2010 SP3 2013 CU1 simplifies the Hybrid Configuration Wizard BUT 2010 SP3 has a better co-existence story than 2013
Challenges for Exchange 2010 Organizations Should you implement 2013 CU1 for your Hybrid Server Why? You don't need a Hybrid Server on 2010... You'll need 2010 SP3 *in your Internet facing site* You're working from the outside-in, so you can upgrade just that site first If it's a single site and you can't upgrade the rest of the org? You can make a site within a site You'll need a DC, CAS and HUB Is SP3 stable? What about PDF and WAV files It's a non-issue, IU available if you experience it No emergency rollup on the way at the moment http://support.microsoft.com/kb/2822208
Hybrid Challenges for Wave 14 Hybrid tenants You will need to upgrade to Exchange 2010 SP3 And re-run the Hybrid Configuration Wizard Did you make any changes?
External URLs You need your AutoDiscover and Internet facing External URLs to be correct In particular, that's EWS and AutoDiscover Test the BASICS using the Remote Connectivity Analyser EWS Tests Including AutoD
Certificates Again, it's coming in from the Internet so VALID third party SSL certificates Common Vendors like GoDaddy, Verisign, Digicert are fine The Federation Certificate for MFG is self-signed though If you've setup Federation in pre-SP1 days consider That this uses the Consumer Gateway Look to remove and re-add this using a self-sign cert If you never used it, the chances are the cert expired This is a PITA to clean up Contact MS support - though possible to do via ADSIeditThe ADSIedit method will be a pain as there are many references, So contact MS If you do have to strip it out, expect a ~7 hour wait for the new one to take effect If you fail at the Get-FederationInformation stage, check this: Internally From another Exchange org And from Exchange Online PowerShell The HCW will be default look for AutoD for *EVERY* domain in the Hybrid Config Are ALL your domains on the SAN for AutoD? Exchagne 2013 built in solution Set-HybridConfiguration -Domain "domain.com, autod:primary.com" Word is, this maybe back-ported to Exchange 2010 but no confirmation yet SSL Offload Where are you likely to find this? Typically a larger existing Exchange 2010 org You'll probably avoid this from the get-goif you're implementing Exchange 2010 servers for Hybrid Exchange 2013 doesn't support SSL offload yet, so it shouldn't be a problem Everything will work for the HCW But, you won't be able to move mailboxes Can you just get rid of SSL offload Find out why it's enabled. Is it part of the architecture sizing? What will the effects be on the: Load Balancer, which will now need to re-encrypt And the Client Access server? Any workarounds? Yes! You could implement a different namespace Additional SAN: hybrid.company.com Use this *only* when you are specifying a name for Remote Move requests It could be the same name as the SMTP certificate name, if that's unique
Pre-Authentication What's Pre-authClient (or in this case, Office 365) has to authenticate against LB/TMG first Credentials entered are passed onto back-end Exchange TMG, I'm looking at you But TMG and ISA aren't all bad as the pre-auth and SSO can be used alongside AD FS for single sign on And now, KEMP and F5 What's the problem? Federated Sharing (not AD FS) using Web Services Security /WSSecurity -.e.g /EWS/Exchange.asx/WSSecuritySolutions? Rules *before* pre-auth rules to exclude these filenames See Tim Heeney's article: http://community.office365.com/en-us/wikis/exchange/1042.aspx Or disable pre-auth on /AutoDiscover/* and /EWS/* Oh no, security risk! MS aren't even recommending pre-auth for Exchange Current recommendation is 3 arm LB 1 in Server VLAN 1 in Internal LAN 1 in DMZ None with pre-authWhat's easier to troubleshoot?
SMTP mail flow Make sure you understand you mail routing first If you're not combining you Hybrid CAS and SMTP, make sure your certificates are in place on the Hubs HCW will define the address ranges for the Receive Connector Routing through something else? You may need to think about this one as it depends on the exact setup For example: Allow firewall rules and DNS entries direct to Hub Servers so they see the remote IP address Or you might need the IP Exchange sees to be different to what it sees for general mail You won't expect it to go via a Third Party SMTP gateway on the way in (or out) Remember, this is internal mail (effectively) and already going through EOP (FOPE) to get to you
Federated Sharing Firstly - it's reliant on AutoDiscover and EWS Remember our pass-thru for pre-auth above When troubleshooting, examine IIS logs and event logs Event logs can be especially useful if it's going to an internal AD site/traversing CAS servers You can manually specify the EWS endpoint in the Org relationship on the Exchange Online site Avoid this unless you really need to Again, SSL offload can cause problems An example - customer configured SSL offload and removed binding except for SSL localhostWas that a bad idea? Why did they have a self-sign cert bound to local host? OWA makes an SSL connection to EWS on localhostSo even with SSL offload, have the SAN cert bound to the Exchange website properly Note that you can't have another EWS virtual directory on the same server For co-existence, remember the limitations of Federated Sharing Re-share Calendars Availabiltiy should work without issue though We'll cover that more later
Planning Most of your work is in the planning Obvious issues like multi-forest, resource forest etc Use the base tools - OnRamp replaces Deployment Readiness Tool https://onramp.office365.com/OnRamp ExDeployhttp://technet.microsoft.com/en-gb/library/ee681665(v=exchg.141).aspxhttp://technet.microsoft.com/en-gb/library/jj218681(v=exchg.150).aspxMAP (Microsoft Assessment and Planning) Toolkit for Microsoft Online Services http://technet.microsoft.com/en-us/solutionaccelerators/dd537571.aspx
PlanningPer-user discovery within your environment Active Directory User, Group and Department Data Exchange Data Mailbox Sizes Messages Sizes including large messages Outlook Clients ActiveSync Clients IMAP/POP3 Clients SMTP senders, like Application Servers and MFCs EWS Clients, like Outlook 2011 for Mac BES Clients Shared and Collaboration Mailboxes Who Shares with who? Any clean up required from a previous cross forest migration Local knowledge Statistics and data aren't everything Who are the real VIPs Groups of users you can get on-board And those that you can't and will complain loudly It's also effectively a cross-forest migration so where people are may matter too
Understanding collaboration issues during co-existence The larger the organization the more sharing they're likely to do Sharing relationships may cross many boundaries You might not be able to discover all sharing Default Reviewers Cross premise, users will need to re-share Calendars Those that are migrated retain sharing permissions Federated Sharing doesn't provide access to Shared Mailboxes Use your discovery information to at the very least, find departments with heavy collaboration E.g. If Finance and HR share heavily migrate them together or one after the other
Migration concurrency depends on more than one factor Max moves per DB on premise Max moves per DB in the cloud Test your throughput during the times you'll migrate Obviously yours and Microsoft infrastructure is busiest at certain times Move Requests are the lowest priority Leavers or other unused mailboxes provide good candidates for throughput testing Just watch out for those still used to retreieve historical data Record your statistics and consider your planned batches Remember, you can move mailboxes back and re-test
Double check your pre-reqsIs it an on-prem mailbox Is it a mail user in the cloud Is it licenced Is the UPN on prem valid and matches in the cloud Have details like email address synchronised successfully Did it have any oversized items Does it require Linked Mailbox cleanup, like Mailbox Permissions that need fixing
Documentation User and IT documentation Involve IT support staff who'll be on the ground early and listen to them Consider an end user portal FAQS Checks users can do themselves Videos and guides on how to perform updates Even personalise per user, such as providing planned
Building Migration Batches Consider using Distribution Groups Provides a communications channel Provides a great feed to test scripts Provides an in-AD method for IT staff to check quickly if someone is to be migrated And provides input to your Remote Moves
Pre-Pilot and Pilot Phases Before the main pilot, iron out every issue you can Treat the pilot like the real deal It's your one chance to get it right Don't just use IT, use real users IT might have configuration or changes not allowed elsewhere IT bods have a tendancy to click past and error that will scare a user A successful pilot with representative users is likely to equal a successful migration Formally collect user feedback and act upon it Get the IT staff involved's input too. Their feedback is essential
The Migration Itself It was all in the planning right, this should be easy! Make sure you've got appropriate resources Don't be scared to scale up Some customers of mine have migrated 1000s per night Keep reviewing feedback from users and IT You might not need to act on it though
Post-Migration Time to get rid of on-premises? SMTP senders may be worth keeping a server for Remember our app servers and copiers? Big benefits with provisioning too when creating Remote Mailboxes But - it's an Exchange Server to patch and maintain