Learn what's next for Exchange and Office 365 at Ignite - Full session list now available
This morning we released the complete list of sessions offered at Microsoft Ignite, including the full list of Exchange sessions. Ignite is the premier event for the Exchange community, bringing together the people who build Exchange and those who work with it every day. If you are one of the many Microsoft Exchange Conference (MEC) alumni, Ignite is the evolution of MEC. Be there as we talk about what’s coming next in Exchange, announce new Office 365 innovations and share our overall technology vision and strategy. Deep technical content At Ignite, we’ll have over 65 breakout sessions dedicated to Exchange on-premises and online, 9 hands-on-labs (HOLs) and 2 pre-day offerings for Exchange IT Pros – many of these offerings presented for the first time at Ignite. You will hear from Exchange engineering, deployment and support teams, as well as independent MVP experts. Ignite offers more than just Exchange content, providing easy access to a broad set of content across Microsoft technologies. You will find over 550 sessions ready for selection at Ignite. So go broad and deep with leading experts from Microsoft and the community on topics ranging from product overview, best practices, how-to, deep-dives, vision and roadmap – tailored by role, level, and specific interests. Here as few sessions you will find on the agenda for Ignite. Title Speaker Level Exchange Server Preferred Architecture Ross Smith IV 300 Under the Hood with DAGs Tim McMichael 400 Exchange Hybrid: Make Office 365 Work for You Michael Van Horenbeeck and Timothy Heeney 300 Experts Unplugged: Exchange Top Issues Exchange and Office 365 Support Teams 300 MVPs Unplugged: The Journey to Microsoft Exchange Online Exchange MVPs 300 View all sessions featuring Exchange product technology here. Unrivaled community & networking opportunities If you’ve been to MEC in the past, you know the real magic happens with the connections you make on site – impromptu geek-out whiteboard sessions, ad-hoc syncs and afterhours at the big and small parties. We are building a complete Ignite experience to deliver opportunities to network at Ignite as Exchange MVP Jason Sherry shared with us early in the Ignite planning process. "The key thing for me is the networking and open dialog that can easily be had with anyone there. Easy access to my peers and product group. We powwow and can then walk to sessions together. Interacting with your peers and socializing is the biggest benefit." – Jason Sherry, Exchange MVP & MEC Alumni, @JasonSherry We’re hosting six large theaters in the spacious expo hall at the event to serve as community zones – these provide a platform for community leaders to share their knowledge and experience with attendees as well as comfortable meeting places for the spontaneous conversations that crop up. The content in these theaters is 100% community-driven; you can expect community-run panel discussions, short fire-starter sessions in which you share an idea with the community and get immediate feedback and birds of a feather session in which people with similar interests gather for discussion, and maybe some of that ‘controlled chaos with clarity’ this community is known for. Mealtimes and after hours provide a whole new slew of opportunities to network and make connections, from scheduled events including the Welcome Reception Monday night and Attendee Party Thursday night to more informal gatherings including meal-time mashups with seating by topic or geography so every meal at the conference becomes a chance to meet someone with similar interests. Join in Register today and join us at Ignite!An update to Important notice for Office 365 email customers who have configured connectors
Since we posted this blog post, we have received positive responses from many of our customers, who have proceeded with changing their connectors (as per instructions in the post), thereby protecting their email/domain reputation. However, we are also aware of customers who are either in the midst of making this change or need some additional time to complete their changes. We understand a change like this can take some time, so we have decided to move our deadline from Feb 1 st , 2017 to July 5 th , 2017. We have also added more details in the original post. If you are an Office 365 email customer and your organization is hybrid (you have an on-premise environment), please take some time to read it! Carolyn LiuImportant notice for Office 365 email customers who have configured connectors
If you are an Exchange Online or Exchange Online Protection (EOP) customer and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action before the deadline (July 5th, 2017). If your organization has a hybrid deployment (on-premises plus Office 365), you often need to relay emails to the Internet via Office 365—i.e. emails from your on-premises environment (mailboxes, applications, scanners, fax machines, etc.) that are sent to Internet recipients will be routed to Office 365 first, then sent out. Figure: Email relayed from your on-premises email servers to the Internet via Office 365 For this relay to work, your organization needs to follow these steps: Create one or more connectors in Office 365 to authenticate emails coming from your on-premises mail servers, using either the sending IP address or a certificate. Configure your on-premises servers to relay via Office 365. Configure your setup so that: a) The sender domain belongs to your organization (i.e. you have registered your domain with Office 365). For more information, see Add Domains in Office 365. OR b) Your on-premises email server is configured to use a certificate to send email to Office 365, and the CN (Common-Name) or SAN (Subject Alternate Name) in the certificate contains a domain name you have registered with Office 365 and you have created a certificate based connector in Office 365 with that domain. If neither step 3a nor 3b is true, Office 365 will NOT be able to know deterministically whether the email sent from your on-premises environment belongs to your organization. Therefore, it is important that organizations with hybrid deployments ensure that they fulfill either step 3a or 3b. This protects your organization, your domain, and your IP reputation. Beginning July 5, 2017 (changed from Feb. 1, 2017), Office 365 will no longer support relaying emails if a hybrid customer has not configured either step 3a or 3b (see detail above). Such emails will get rejected with the following error message: “550 5.7.64 Relay Access Denied ATTR36. For more details please refer to https://support.microsoft.com/kb/3169958.″ Additionally, if your organization needs the following scenarios to continue to work (and most hybrid organizations do), you need to ensure that you follow step 3b. Your organization needs to send NDR (Non-Delivery Report) or bounce messages to a recipient on the Internet and needs to relay them through Office 365. You need to send emails on behalf of domains that do not belong to your organization. Your on-premises users have forwarding rules configured, and messages need to be relayed through Office 365. For example: Contoso.com is your organization’s domain. A user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding of all her messages to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization. Figure: When step 3b is followed, a forwarded email from contoso.com will be allowed to be relayed via Office 365 For more details, see the step-by-step instructions below. Create or Edit a certificate-based connector in Office 365 For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps. 1. Sign in to Office 365 admin center, and go to Admin > Exchange. 2. Go to mail flow > connectors, and do one of the following: If there are no connectors, choose ’+’ (Add) to create a connector. If a connector already exists, select the connector, and choose Edit to modify it. 3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your On-premises server is the sending source for your messages. 4. Enter connector name and other information, and then choose Next. 5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match the CN name or SAN in the certificate you are using to send email and this domain must be a domain you have registered with Office 365 (see Add Domains in Office 365). For example: The certificate you plan to use has CN or SAN as contoso.com. In that case, you can enter contoso.com in the dialog below and register contoso.com in Office 365 (see Add Domains in Office 365) The certificate you plan to use has CN or SAN as <hostname>.contoso.com or mail.contoso.com. In that case, you could enter *.contoso.com in the dialog below, and register contoso.com in Office 365 (see Add Domains in Office 365) Note: Existing hybrid customers that used the Hybrid Configuration Wizard to configure their connectors SHOULD check their existing connector and ensure that it is using *.contoso.com instead of mail.contoso.com or <hostname>.contoso.com, since mail.contoso.com or <hostname>.contoso.com may not be a registered domains with Office 365. Register your domain with Office 365 You can follow the steps to register your domain here - Add Domains in Office 365. Go to Setup > Domains in the O365 Admin Center to see the list of domains registered: Prepare your on-premises email servers to relay messages through Office 365 If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access. For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365. Carolyn LiuMicrosoft Hybrid Agent Preview Update
As you are aware, we released the Microsoft Hybrid Agent for Exchange Server as a preview on Feb. 5 th , 2019. The blog post for that release is located here. We have been busy working on a few improvements for the Hybrid Agent over that past two months and wanted to let you know of some new features now available in the latest build of the Hybrid Configuration Wizard. The three enhancements for the Hybrid Agent are: Multi Agent installation and configuration Agent status views Registration/Usage of a load balancer for the internal URL instead of a specific Exchange Client Access Server Multi Agent Deployment Option 1 – Use the Hybrid Configuration Wizard to install additional agents For existing Hybrid Agent preview customers who would like to install additional Hybrid Agents for redundancy, simply download the latest version of the Hybrid Configuration Wizard (HCW) and open the application on the machine where you would like to install an additional Hybrid Agent. Like previous HCW runs, start the application, select Next. Select a desired server to execute against, select Next. Provide credentials to sign into your Office 365 tenant, select Next. The HCW will gather configuration information, select Next when complete. Select the default option provided for either Full or Minimal, select Next. Select Exchange Modern Hybrid Topology, Next. Agree to the Terms, Next. A new page will be shown that will provide you with the status of your existing / previously installed agent. Make sure the status of the existing agent is accurate before proceeding to the next step. Select Install and additional agent option, Next. Example: The HCW will install the additional Hybrid Agent. When the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running (look for Microsoft Hybrid Service - mshybridsvc). At that point, you can either re-run HCW if you wish to make further changes to your hybrid config, or simply cancel the wizard. You can repeat this step on each machine where you would like an additional Hybrid Agent installed. Option 2 – Manually download & install additional agents A second option for installing additional agents is outside the HCW itself and is done by downloading and manually installing the agent on the desired machine. Go to https://aka.ms/hybridagentinstaller. Save the MSHybridService.msi to a location on your machine. From that machine, open a Windows Command console as Administrator and run: Msiexec /i MSHybridService.msi to install the hybrid agent. You will be prompted for your tenant Global Admin credentials. After the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running. You can repeat this step on each machine where you would like an additional Hybrid Agent installed. Checking the Status of Your Hybrid Agents Option 1 – Get status via the Hybrid Configuration Wizard (HCW) Start the HCW application, select Next. Select a server in your Exchange org, select Next. Provide credentials to sign into your Office 365 tenant, select Next. The HCW will gather configuration information, select Next when complete. Select default option provided for either Full or Minimal, select Next. Select Exchange Modern Hybrid Topology, Next. Agree to the Terms, Next. A new page will be shown that will provide you with the status of your existing installed agents. Cancel the HCW app when you are done. Option 2 – Get status via the Hybrid Management PowerShell Module With each installation of the Hybrid Agent, we install the Hybrid Management PowerShell module in the directory …\Program Files\Microsoft Hybrid Service\ on the machine where the agent is installed. By default, this module is not imported and so you will need to import it before you can use it. This module also requires the Azure module for PowerShell if not already installed. Please install the PackageManagement modules first and then see this article for how to install the Azure module. To import the Hybrid Management module, run the following from a Windows PowerShell prompt as Administrator: Import-module .\HybridManagement.psm1 After that you can run: Get-HybridAgent -credential (get-credential) to view agent status: Note: the ‘id’ value provided in the above snip is the agent identity and not your unique tenant guid assigned to the route. Directing your Hybrid Agent(s) to the load balancer instead of a specific server If you would like your Hybrid Agent(s) to direct requests to your load balancer instead of a specific Exchange Client Access Server, this can be done with the Hybrid Management PowerShell module. In preview, the Hybrid Agent supports routing requests to the load balancer for Exchange Server 2013 – 2019 Client Access Servers. You cannot use this if you only have Exchange Server 2010 CAS deployed. Follow the steps above to import the Hybrid Management module for PowerShell. From PowerShell, then simply use the Update-HybridApplication cmdlet to change the value of the internalURL (targetURI parameter) from a specific server to your load balancer endpoint. Before running this cmdlet you will need to get the unique guid value (e.g. 12345678-1234-1234-1234-1111111111111) of your tenant’s endpoint from either your MRS configuration or the Organization Relationship object (TargetSharingEPR). Example: PS C:\PowerShell> Get-OrganizationRelationship ((Get-OnPremisesOrganization).OrganizationRelationship) | Select-Object TargetSharingEpr TargetSharingEpr ---------------- https://e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx Or PS C:\PowerShell> Get-MigrationEndpoint "Hybrid Migration Endpoint - EWS (Default Web Site)" | Select-Object RemoteServer RemoteServer ------------ e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net To be clear, the ID parameter required in this cmdlet is not the agent ID, but the guid listed in your custom registered endpoint retrieved using the method above. Example: We really hope you are enjoying and benefitting from using the Hybrid Agent. We see a lot of usage and we’re working hard to improve it all the time. Thank you! Exchange Hybrid TeamMicrosoft Ignite 2018 - The Recap
Microsoft Ignite 2018 ended a few weeks ago, and what a great event it was. It was great to see so many of our customers, partners and friends there – thank you for coming to our sessions, thank you for coming to the booth, thank you for hanging out with us whenever the opportunity arose and thank you for giving us great feedback on what we’re doing. We’re still recovering but we heard you and are focused on doing a better job because of it. All of the sessions were recorded this year, and so here’s a handy reference to all the sessions in the Exchange and Outlook track, and some others we think you’ll find interesting, so you can refer back here whenever you want to find one. You will need an account in Tech Community to access them, but that’s something you should have anyway. So here’s a long list of sessions, in no particular order but grouped by technology as much as possible. Exchange Welcome to Exchange 2019! Panel discussion: Microsoft Exchange/Calendar/OWA Hybrid Exchange – Making it easier and faster to move to the cloud Scott Schnoll's Exchange and Office 365 Tips & Tricks Securing Exchange Online from Modern Threats So long and thanks for all the (email) phish Email Search in a Flash! Accelerating Exchange 2019 with SSDs Turbo charge your Exchange on-premises and Hybrid environment – Notes from the field How to add MFA to your Exchange On-Prem/Online mailboxes in 20 minutes or less Preparing to Move (or remove) Those Public Folders to the Cloud Why do we need to keep an Exchange Server on-premises when we move to the cloud? Making the best of the cloud: How Exchange Online is different from Exchange on-premises Azure Information Protection and Exchange Online - better together Securing your Office 365 environment from advanced phishing campaigns with Office 365 Advanced Threat Protection Outlook Deep dive into what’s new and coming soon to Outlook for Windows and Mac Outlook mobile in the Enterprise Deploying Outlook mobile securely in the enterprise What's Amazing and New in Calendaring in Outlook! Outlook on the web - What's new and why you should care! The Best (Outlook driven) Day of Your Life Success through people with LinkedIn and Microsoft 365 What's New in groups in Outlook Panel discussion: Microsoft Outlook (Windows, Mac, and Mobile) Let the intelligence built into Outlook help you to make time for what really matters Simple room booking in Outlook using new built-in Intelligence The Power of People in Outlook Security made real with Outlook mobile in-app experiences Outlook on the web: Don’t block your users, restrict them with conditional access/limited access! Adaptive Cards in Teams, Windows, Outlook and your own applications Create engaging, powerful new business processes in Microsoft Outlook with Adaptive Cards Office 365 Notes from the field: how we moved a large global bank to Office 365 Office 365 – Marriages, Divorces and Adoptions Getting stuff done: Solving Office 365 problems with PowerShell How to be an author and write about Office 365 Real-world best practices for managing Office 365 groups Embrace Office 365 Groups: What's new and how to get started Office 365 Groups automation inside-out Delivering Office 365 as an evergreen service: What to do, and more importantly, what not to do Understanding how Microsoft Information Protection capabilities work together to protect sensitive information across devices, apps, and services Secure enterprise productivity with Office 365 threat protection services including EOP, ATP, and Threat Intelligence Strategies for building effective, optimal and future proof connectivity to Office 365 that will delight your users Implementing a modern network architecture to get the most out of Office 365 Addressing global data residency needs with Multi-Geo in Office 365 Podcasts/Broadcasts Ross Smith IV & Greg Taylor on theCUBE Scott Schnoll & Jeff Mealiffe on theCUBE Ross Smith IV on Channel 9 talking about Outlook mobile Greg Taylor on Channel 9 talking about Exchange Server 2019 Greg Taylor, Tony Redmond and Paul Robichaux – Office 365 Exposed talking about random stuff It’s possible we missed a session you think we should have included (there were 750 or more after all), if so, add it to the comments section so people can find it. Thanks! Happy watching! And see you next year for more of the same. Microsoft Ignite 2019 here we come! Greg Taylor Director of Product Marketing Exchange Server and OnlineImportant notice for Office 365 email customers who have configured connectors
Note: This post, originally published in March, got accidentally re-published on 8/23/16 when updating step 5 below. We are leaving it published as a reminder to our customers as the time for this change is now closer. If you are an Exchange Online or Exchange Online Protection (EOP) customer and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action before the deadline (July 5th, 2017). If your organization has a hybrid deployment (on-premises plus Office 365), you often need to relay emails to the Internet via Office 365—i.e. emails from your on-premises environment (mailboxes, applications, scanners, fax machines, etc.) that are sent to Internet recipients will be routed to Office 365 first, then sent out. Figure: Email relayed from your on-premises email servers to the Internet via Office 365 For this relay to work, your organization needs to follow these steps: Create one or more connectors in Office 365 to authenticate emails coming from your on-premises mail servers, using either the sending IP address or a certificate. Configure your on-premises servers to relay via Office 365. Configure your setup so that: a) The sender domain belongs to your organization (i.e. you have registered your domain with Office 365). For more information, see Add Domains in Office 365. OR b) Your on-premises email server is configured to use a certificate to send email to Office 365, and the CN (Common-Name) or SAN (Subject Alternate Name) in the certificate contains a domain name you have registered with Office 365 and you have created a certificate based connector in Office 365 with that domain. If neither step 3a nor 3b is true, Office 365 will NOT be able to know deterministically whether the email sent from your on-premises environment belongs to your organization. Therefore, it is important that organizations with hybrid deployments ensure that they fulfill either step 3a or 3b. This protects your organization, your domain, and your IP reputation. Beginning July 5, 2017 (changed from Feb. 1, 2017), Office 365 will no longer support relaying emails if a hybrid customer has not configured either step 3a or 3b (see detail above). Such emails will get rejected with the following error message: “550 5.7.64 Relay Access Denied ATTR36. For more details please refer to https://support.microsoft.com/kb/3169958.″ Additionally, if your organization needs the following scenarios to continue to work (and most hybrid organizations do), you need to ensure that you follow step 3b. Your organization needs to send NDR (Non-Delivery Report) or bounce messages to a recipient on the Internet and needs to relay them through Office 365. You need to send emails on behalf of domains that do not belong to your organization. Your on-premises users have forwarding rules configured, and messages need to be relayed through Office 365. For example: Contoso.com is your organization’s domain. A user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding of all her messages to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization. Figure: When step 3b is followed, a forwarded email from contoso.com will be allowed to be relayed via Office 365 For more details, see the step-by-step instructions below. Create or Edit a certificate-based connector in Office 365 For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps. 1. Sign in to Office 365 admin center, and go to Admin > Exchange. 2. Go to mail flow > connectors, and do one of the following: If there are no connectors, choose ’+’ (Add) to create a connector. If a connector already exists, select the connector, and choose Edit to modify it. 3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your On-premises server is the sending source for your messages. 4. Enter connector name and other information, and then choose Next. 5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match the CN name or SAN in the certificate you are using to send email and this domain must be a domain you have registered with Office 365 (see Add Domains in Office 365). For example: The certificate you plan to use has CN or SAN as contoso.com. In that case, you can enter contoso.com in the dialog below and register contoso.com in Office 365 (see Add Domains in Office 365) The certificate you plan to use has CN or SAN as <hostname>.contoso.com or mail.contoso.com. In that case, you could enter *.contoso.com in the dialog below, and register contoso.com in Office 365 (see Add Domains in Office 365) Note: Existing hybrid customers that used the Hybrid Configuration Wizard to configure their connectors SHOULD check their existing connector and ensure that it is using *.contoso.com instead of mail.contoso.com or <hostname>.contoso.com, since mail.contoso.com or <hostname>.contoso.com may not be a registered domains with Office 365. Register your domain with Office 365 You can follow the steps to register your domain here - Add Domains in Office 365. Go to Setup > Domains in the O365 Admin Center to see the list of domains registered: Prepare your on-premises email servers to relay messages through Office 365 If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access. For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365. Carolyn Liu
