Yesterday, the Exchange Product made several announcements related to Exchange Server. The overall message throughout these announcements can be interpreted as that Microsoft is publicly declaring to be committed to developing and supporting the Exchange Server product. This is especially of interest to those customers running it as part of their on-premises infrastructure and assuring those that believe the road ahead was a dead end, eventually forcing them to move to Exchange Online, or look for alternatives.
ENow Software's Exchange blog built by Microsoft MVPs for IT/Sys Admins.
Michel de Rooij
Michel de Rooij, (MCSE: Messaging 2013, MCSA 2012, MCITP and MCTS: Exchange 2007 & 2010 server 2008, MVP: Exchange) Michel is currently a Consultant at Conclusion FIT. His professional focus is on Exchange and related technologies like Active Directory, PowerShell, Lync, Office 365, Unified Communications and messaging in general. His experience ranges from small to enterprise organizations, including migrations and transitions to greenfield as well as merger and disentanglement scenarios. He has background in developing which is helpful when scripting (tooling, solutions). You can follow Michel via twitter (@mderooij) or his blog www.eightwone.com.
In the announcement that was part of the release of the most recent set of Cumulative Updates for Exchange Server 2019 and 2016, Microsoft introduced some changes – features if you will – which were received with enthusiasm. An overview of these changes was given in a recent ENow blog article: "Exchange Cumulative Updates - April 2022". However, I want take the discussion further and zoom in on one of those features, which also happens to be a popular topic for customers running Exchange Hybrid deployments: The Last Exchange Server.
Back in September 2019, Microsoft announced it would start to turn off Basic Authentication for non-SMTP protocols in Exchange Online on tenants where the authentication protocol was detected as inactive. This is part of an overall movement to deprecate the less secure Basic Authentication, which is unfit to face the security challenges of the modern world, being subject to things like password spray attacks. It's modern successor, modern authentication or OAuth2, uses a token and claim based mechanism contrary to sending accounts and passwords, and is the preferred authentication method. When combined with Azure AD for authentication, Modern Authentication also supports features such as Multi-Factor Authentication or Conditional Access.
Anyone who has participated in migrations or transitions to Exchange is probably familiar or had to work around potential issues caused by the nickname cache. A “cache,” also known by its file extension, NK2 in older Outlook clients, is a convenience feature in Outlook and Outlook on the web (OWA). It lets users pick recipients from a list of frequently-used recipients. This list is displayed when the end user types in the first few letters:
Anyone who has participated in migrations or transitions to Exchange has most likely encountered or has had to work around potential issues caused by the nickname cache. A “cache,” also known by its file extension, NK2 in older Outlook clients, is a convenience feature in Outlook and Outlook WebApp (OWA) which lets users pick recipients from a list of frequently-used recipients. This list is displayed when the end user types in the first few letters.
The potential issue revolves around end users using those lists to send messages, as the list contains cached recipient information. Because this information is static, it may become invalid at some point. Thus, when users pick recipients when sending messages, they may be sending messages to non-existent recipients or invalid e-mail addresses, which create issues like non-delivery of e-mail.
In an earlier version of Outlook, this information was stored in local .NK2 files. In Outlook 2010 and up, this information is stored in your mailbox (AutoComplete Stream). Unfortunately, OWA utilizes its own cache mechanism while Outlook stores recipient information in other locations as well, like the ‘Suggested Contacts’ folder for example.
After some recent Exchange troubleshooting I decided to do a small write-up on an attribute most people working with Exchange know about, the infamous exchangeLegacyDN.
In the early days of Exchange, the NT world was flat. Exchange utilized its own hierarchical X.400 directory service and to uniquely identify objects it used an attribute called obj-Dist-Name. It contained a constructed value using elements like organization, containers and the canonical name to construct the entry, e.g. /o=Contoso/ou=EMEA/cn=Recipients/cn=User.
For those involved with Exchange migration projects or managing Exchange environments, at some point you probably have experienced a situation where individuals ended up with duplicate items in their mailbox. Duplicate items can be caused by many things, but most common are:
Many customers nowadays are running a virtualized Exchange environment, utilizing Database Availability Groups, load balanced Client Access Servers and the works. However, I also see environments where it is up to the Hypervisor of choice on the hosting of virtual machines after a (planned) fail-over. This goes for Exchange servers, but also for redundant infrastructure components like Domain Controllers or Lync Front-End servers for example.