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 LiuMicrosoft 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 OnlineWhy can't I modify the objects on my ADC Tools created Recipient CA?
If you create a Recipient Connection Agreement (RCA) with the ADC tools wizard and then go in to view the settings of that RCA, you may notice that the “Select the objects that you want to replicate” options on the From Windows tab are grayed out and you cannot make changes… Example: The reason for this is because of the custom filter created for the RCA by the ADC tools. If you look at the values for the attribute msExchServer1SearchFilter on the agreement itself, you will see a filter specified that is similar to: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=ORG1/ou=SITE1/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE))); This is a custom search filter that (in this case) searches for objects in Active Directory that are either of class user, contact, or group AND that also belong to the Administrative Group called SITE1 (or that have been deleted and need that deletion to replicate across to the 5.5 Directory) Since this is a “custom” filter, the objects can’t be edited via the normal GUI interface and that is why the check boxes are not modifiable. Once again you can see from the filter that the connection agreement is in fact already set to replicate users, contacts or groups despite what the GUI seems to indicate at first glance. If you have multiple Administrative groups that have users in the same Active Directory location you would have multiple auto-created RCAs as these will ONLY replicate objects that match the Administrative Group listed in the filter. For example, a second Administrative Group (called AG2) with objects in the same Active Directory location would have a filter like the following: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=ORG1/ou=AG2/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE))); Ultimately, if you want or need more flexibility with connection agreements (such as limiting or modifying the objects controlled by the RCA) you should create the connection agreements manually using the ADC Services Snap-in instead of having the ADC tools create them automatically. - Kyle LewallenWhy can't I do a Deep Traversal (subfolder) Search on the MAPI Public Folder Tree?
I am sure many of you have at one time or another wanted to do a Deep Traversal (subfolder) Search on the MAPI Public Folder Tree. However, as many of you probably know, Exchange does not allow for Deep Traversal (subfolder) Searches on the MAPI Public Folder Tree: http://support.microsoft.com/default.aspx?scid=kb;en-us;254911. The reason you cannot do this is because when the Public Folder system was designed, it was decided that load balancing would be accomplished by putting only some of the content on some of the servers. For example, if there exists 3 folders and 3 servers. Folder1 may be replicated between servers 1 & 2, folder2 between servers 2 & 3, and folder3 between 1 & 3. If the client created a search folder that simultaneously searched all three folders, they’d get different results depending on which actual Public Folder Server they were connected to. To address this issue, search folders cannot be created that search the content of multiple folders; deep traversal, or subfolder, being a special case of “multiple folders”. One way to get around this “limitation” is by setting up a Non-MAPI Public Folder Tree because you can do a Deep Traversal (subfolder) Search against that: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_exch2k_specifying_a_deep_traversal.asp?frame=true. However, you cannot view this Public Folder Tree via MAPI (i.e Outlook). So what is the difference you ask? Well, the thought behind Application Public Folder Stores was that, for the most part, the content of the folders would not be replicated to any other server. There’s no actual architectural limitation to enforce this – Exchange originally just foresaw organizations would create only one Application Public Folder Store at all and so replication wouldn’t be an issue. Therefore, users can create Search Folders that can search the content of multiple folders. Given this, though, you do actually step back into the original problem. Namely, the search folder itself is replicated among servers but the content is always generated locally. Also, clients are never referred to a different server – search folders always seem (to the client) to have their exclusive replica on the server presently being queried. So, users should be aware that they will get different results depending on which server they contact for the content, and of course replication latency adds a new dimension to the differing results. - Chris AhlersThe New Cluster Clean Upgrade Method
Prior to releasing Exchange Server 2003 we didn’t test this scenario, and since we only support scenarios that we have tested and have confidence in this was considered unsupported. However, with so many customers interested in this method of upgrading we decided to test it and document the process. A KB article will be released describing the process, but for now here are the steps you need to know. Summary: In some cases it may be preferable to do a clean install of the operating system or Exchange Server rather than upgrading. On a cluster, your existing Exchange 2000 virtual server can be preserved and upgraded even if you need to clean install Windows 2003/Exchange 2003. Some custom configuration may be lost using this method, we recommend performing a standard upgrade if at all possible. Please read and understand all the steps and issues thoroughly before beginning this upgrade process. This kb article covers clusters that meet the following requirements: Windows 2000 SP3 Exchange 2000 SP3 Two nodes Active/Passive configuration Upgrading to: Windows 2003 Exchange 2003 Steps: For this example I’ll run the EVS on node2 while I upgrade node1, but it doesn’t matter which node is upgraded first. 1. Evict the passive node and rebuild Make sure the EVS and all cluster resources are all running on node2 (active node). Use cluster admin from node2 to stop the cluster service on node1 and then evict it from the cluster. On node1, format the disk and clean install W2k3. Rejoin node1 to the cluster (Important! This must happen before running Exchange setup) On node1, clean install E2k3. 2. Configure services On node 1, run services.msc and set Distributed Transaction Service startup type to Manual If you are using POP3 or IMAP set the start up type to manual on each service. (If you are not using these services consider deleting the resources and setting the services to disabled). If you are using full text indexes please see the note below for special instructions. On node2, take the Microsoft Exchange System Attendant resource offline (this will take all Exchange resources offline) 3. Upgrade the Exchange Virtual Server (EVS) Move the offline EVS to rebuilt node (node1) On node1, right click the System Attendant resource and select upgrade EVS The upgraded EVS cannot be failed over to run on the older version node (node2). To prevent this from happening change the System Attendant resource possible owner list to include only the upgraded node. Right click the System Attendant resource and select properties. On the “general” tab next to “possible owners” click “modify”. Under Possible owners select the name of the node that hasn’t been upgraded, and click the ? arrow button to remove it from the list. Click ok. Bring the EVS online 4. Repeat 1-2 (with node2 as the passive node) Running Exchange setup on node2 should add it back to the possible owner list for the System Attendant resource After both existing nodes are upgraded to Windows Server 2003 additional nodes can be added to the cluster. Issues: Full Text Indexes begin a Full Population after upgrading the Exchange Virtual Server After the cluster node has been upgraded to Exchange 2003, the Exchange Virtual Server has been upgraded, and the cluster resources come on-line, a full population will begin on all full-text indexes and the indexes will be disabled for searching. To avoid having the full population begin automatically, manually start and then pause a full or incremental population on all the full-text indexes on the server prior to upgrading the Exchange Virtual Server. If the indexes are already paused when you upgrade, they will remain paused and the upgrade will finish normally. After you have finished upgrading, you can manually resume building the indexes when it is convenient to do so. Once the indexes have been built, you can enable searching on the newly built indexes. One Way Upgrade Once an EVS is upgraded it cannot be run on a node with older versions of Windows and/or Exchange. Other Applications Must Be Installed Again After Upgrade Workflows, virus scanning, event sinks, and any other application installed on your existing server will need to be reinstalled and configured. Make sure all applications you are planning to bring forward are compatible with the newer versions of Windows and Exchange. Customized Registry Keys Lost Any feature that is enabled by setting a registry key (such as journaling) will not be carried forward with this upgrade. Any customization, performance tuning, manually set or altered registry key will not be persisted using this upgrade method. These will need to be manually reset. No Active/Active support Using this method of upgrading Active/Active clusters is not supported. Risk of Downtime Increased by time between upgrading first and second nodes Once the Exchange Virtual Server has been upgraded it cannot be run on the older version node. If anything happens to the upgraded node during this time, it has no passive node to fail to. To reduce the risk of downtime, upgrade the second node soon as possible after upgrading the first. The risk of downtime is increased the longer the EVS has only one node available to run on. - Carol SwalesAre ghosts modifying distribution groups in your mixed-mode environment?
We've seen a few issues recently where members of DGs (Distribution Groups) in mixed-mode Exchange 200x and 5.5 seem to randomly and mysteriously disappear. We thought we'd share one known root-cause and also show you how to prevent the problem while doing your migration, if for whatever reason you are still running Exchange 5.5 =). One easy way to prevent this problem (and a few others) is to ALWAYS use the Exchange 2003 post SP1 cross-site mailbox migration wizard if you ever have to move mailboxes in a mixed-mode environment. With that said, typically the problem occurs when you use a directory export/import to move mailboxes between Exchange 5.5 sites. For example, if you have two Exchange 5.5 sites Site S (Source) and Site D (Destination) and you would like to move all the mailboxes in Site S to Site D you might perform the following steps. (When we refer to a DL we mean a Distribution List on the Exchange 5.5 side and when we refer to DG we mean a Distribution Group on the Active Directory side) Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source Exchange 5.5 server in Site S Delete the source mailboxes in Site S Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also wait for the Active Directory Account to become mailbox-disabled. Do a directory import of the mailbox information in Site D to recreate the mailboxes. Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site The problem occurs after step 4. The following key points should help you understand why. Replication between Exchange 5.5 sites is governed by USN-Changed values. Any changes made to an object in a directory in one site only replicate to other sites if that object's USN-Changed value is higher than the corresponding value in some other site. For the special case of a mailbox deletion, you would expect the USN-Changed value for any DL that the mailbox is a member of to increment after the mailbox deletion. This is, however, not necessary because when you delete a mailbox from its 'home' site, the member property of the DL changes and the read-only copy of the mailbox in all the other sites gets deleted. When the read-only copy is deleted in all the other sites the DL membership is updated as well. The salient point is without incrementing a DL's USN-Changed, all the necessary changes for the sites to be in-sync are properly accounted for. This works well for a pure Exchange 5.5 environment but creates a problem for a mixed-mode one with an ADC (Active Directory Connector) in the mix. As we know, the ADC compares the msExchServer2HighestUSN value on the RCA (Recipient Connection Agreement) to the USN-Changed value of an object in the Exchange 5.5 directory to determine whether the Exchange 5.5 object should be replicated to the AD. If the USN-Changed on an object is greater than the msExchServer2HighestUSN on the RCA, the object has been changed in the Exchange 5.5 directory and needs to be updated in the AD. If msExchServer2HighestUSN is greater than or equal to USN-Changed, no changes have occurred on the 5.5 object that need to be updated (replicated to) on the AD side. See the following knowledge base article for further details 253840. In this situation, since the DLs' USN-Changed isn't incremented in the 5.5 directory when you delete the mailboxes, the corresponding DG (Distribution Group) membership in the AD isn't updated. If you later make changes that increment the USN-Changed on the DL, the entire object (including the earlier deletions) is replicated to the AD side and so some members seem to randomly disappear from the DG's members list. While replication in Exchange 5.5 is object-based and replication in the AD is attribute-based, Exchange 5.5 to AD replication is still object-based (think lowest common denominator). The solution to this problem is to force the USN-Changed on the DL to increment after performing the deletions in step 3. A DL's USN-changed increments under the following scenarios: If you use the Exchange 5.5 Administrator program to open the DL's properties, modify any value and click Apply or OK (Or if you modify the DL's properties by doing an directory export/import with the standard header fields) If you use the Exchange 5.5 Administrator program to open a mailbox's properties and remove a DL from the list of DLs that the mailbox is a member of If the DL is updated by DRC or ADC replication changes from other 5.5 sites or from the AD respectively Again, a DL's USN-Changed does not increment when you use the Exchange 5.5 administrator program to delete a mailbox from the DLs membership. To force the USN-Changed value on the DL to increment you need to make a 'dummy' change that falls under a, b or c after step 3. Our new steps to ensure we avoid the problem would therefore be: Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source 5.5 server in Site S Delete the source mailboxes in Site S Use the Exchange 5.5 Administrator program to modify the "notes" field on all the DLs that contained the deleted mailboxes to force an increment of USN-Changed value. This step is critical Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also trigger RCA replication and make sure that the 'member of' list for the AD user accounts that correspond to the deleted mailboxes is empty (except built-in groups such as Domain Users etc) Do a directory import of the mailbox information in Site D to recreate the mailboxes Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site. Add the migrated mailboxes to the corresponding DLs manually using the Exchange 5.5 Administrator program. This step may not seem necessary but it is. Usually an administrator may notice that the member list is still present on the AD after performing the previous steps and therefore assume that nothing more needs to be done on the Exchange 5.5 side. Later when some other change increments the USN-Changed the deletions replicate to the AD and members seem to randomly disappear from DGs. Everything should work fine and dandy at this point and you needn't worry about 'ghosts' modifying your DGs! - Jasper Kuria and William YangI'll have some transaction log files for breakfast day
With viruses spreading quick out there today, we had several cases where Exchange transaction logs got either deleted, quarantined or "cured" by file-level anti-virus software that is running on Exchange servers... the result is a bad thing... stores down, transaction logs missing. In some cases the only thing you can do is go back to the last backup if one that is good is available. Otherwise - you are looking at possible repair (= data loss) + Isinteg (maybe 2-3 times) + mandatory offline defrag = a lot of time that is lost :( Please, do not let Exchange directories be scanned by file-level AV. Not "on-demand" one, not the memory resident one. Have Exchange directories excluded, the M: drive excluded, and actually - exclude specifically .log, .edb and .stm files too just to be extra careful. To be more specific, excluding the following on Exchange server is a GREAT idea: Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder. You can verify the locations by pulling up properties of your databases in ESM and checking the Database tab. Exchange MTA files in the Exchsrvr\Mtadata folder. Additional log files such as the Exchsrvr\server_name.log file. The Exchsrvr\Mailroot virtual server folder. The working folder that's used to store streaming temporary files used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location. The temporary folder that is used in conjunction with offline maintenance utilities such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure where you run the file from when you run the utility. Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder. Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder. The Exchange 2000 Server drive M. More appropriate reading: 328841 XADM: Exchange and Antivirus Software 823166 Overview of Exchange Server 2003 and Antivirus Software Nino BilicApplication Access Policy Support in EWS
Administrators who want to limit the app access to a specific set of mailboxes can create an application access policy. Application access policy support for Microsoft Graph was released in 2019. Today, we are announcing that we are adding support for application access policies to Exchange Web Services (EWS) in response to customer feedback...
