Microsoft Exchange refers to an older certificate that no longer exists, ID 12023.
We have one Microsoft Exchange 2013 server. The Windows Application log periodically displays the ID 12023 entry, which states that Microsoft Exchange could not load the certificate with the thumbprint 3E8XXXXXXXXXXXXXXXXXXXXXXXXXXXX from the local computer's personal certificate store. This certificate was deleted because it expired, and a new self-signed Auth certificate was created. Now, when running the Get-AuthConfig | Format-List CurrentCertificateThumbprint, PreviousCertificateThumbprint, NextCertificateThumbprint command, only the current certificate is displayed. The Microsoft Exchange 2013 server is running. The question is, what should I do to remove the ID 12023 entry from the Windows Application log?
Hybrid Configuration Wizard fails to run – manifest download error on all machines
Hello, I am unable to run the Exchange Hybrid Configuration Wizard (HCW) for our Exchange 2016 environment. The issue occurs on multiple machines and networks, so it does not appear to be a local configuration problem. Environment: Exchange Server: 2016 CU23 Windows versions tested: Windows Server 2016, Windows 10 (all fully updated) .NET Framework: 4.8 (Release 528040 / 4.8.03761) TLS: TLS 1.2 enabled, SSL 3.0/TLS 1.0/1.1 disabled Network: No proxy, firewall, or other network restrictions; internet access available Problem: When attempting to run HCW via https://aka.ms/HybridWizard, the wizard fails to start. I have also tried to run HCW offline by downloading Microsoft.Online.CSE.Hybrid.Client.application, but it immediately fails. The error log shows the following repeated messages: Downloading file:///C:/Users/.../Application Files/Microsoft.Online.CSE.Hybrid.Client_17_1_3902_0/Microsoft.Online.CSE.Hybrid.Client.exe.manifest did not succeed. Could not find a part of the path 'C:\Users\...\Application Files\Microsoft.Online.CSE.Hybrid.Client_17_1_3902_0\Microsoft.Online.CSE.Hybrid.Client.exe.manifest' This occurs on all tested machines (three PCs across three different networks). ClickOnce cache has been cleared, root certificates are up-to-date, .NET is 4.8, and TLS 1.2 is active. Attempts to resolve: Ensured TLS 1.2 is enabled and default in .NET and OS Verified .NET 4.8 installation Cleared ClickOnce cache (rundll32 dfshim CleanOnlineAppCache) Updated root certificates Tried multiple machines and networks Tried to run offline using .application file and local copy of Application Files Result: HCW fails immediately with DeploymentDownloadException / DirectoryNotFoundException for the manifest. The issue is reproducible on all tested machines. Request: Please advise if there is an official offline installation method for HCW or a way to obtain a working manifest. If this is a temporary issue with the hosted distribution, please confirm expected resolution or workaround. Thank you for your assistance.
Exchange Online Mailbox cannot see Unsynchronized On-Premises mailbox Free/Busy info and vice versa
Hello Everyone! I originally posted an issue on Microsoft Learn https://learn.microsoft.com/en-us/answers/questions/5651848/free-busy-not-viewable-from-on-premises-mailbox-to?comment=answer-12418292&page=1#comment-2404594 regarding Free/Busy issues with our On Premises Exchange Server which is running the latest version of Exchange SE and Exchange Online which is on our Microsoft 365 Tenant. At first, it would fail the Test-OAuthConnectivity, but that now seems to be fixed with renewing the OAuth Certificate and in addition, enabling the Dedicated Exchange Hybrid App as per https://learn.microsoft.com/en-us/exchange/hybrid-deployment/deploy-dedicated-hybrid-app . On initial deployment, we could not see Free/Busy between EXO and On-Prem Exchange but after 2 hours, it started working but only between On-Premises Synchronized to Microsoft 365 Mailboxes and EXO Mailboxes Our final problem is the viewing of Free/Busy information of On-Premises 'NON-Synchronized to Microsoft 365' mailboxes and EXO Mailboxes. Running the Free/Busy Troubleshooter on ExRCA just gives me a warning during the Determining where the target mailbox is hosted. Also using 'Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/EWS/Exchange.asmx -Mailbox<onpremnonsynchedmailbox>@domain.com -verbose | fl ' on our On-Prem EMS leads to the following error System.Net.WebException: The remote server returned an error: (500) Internal Server Error. at System.Net.HttpWebRequest.GetResponse() at Microsoft.Exchange.Monitoring.TestOAuthConnectivityHelper.SendExchangeOAuthRequest(ADUser user, String orgDomain, Uri targetUri, String& diagnosticMessage, Boolean appOnly, Boolean useCachedToken, Boolean reloadConfig) ResultType : Error Identity : Microsoft.Exchange.Security.OAuth.ValidationResultNodeId IsValid : True ObjectState : New Please advise on how we can fix this error.
Exchange 2019 SMTP random delays of 1 minute when sending email
Hello, We recently moved from a 3 server Exchange 2016 DAG to a single Exchange 2019 server. We are in a hybrid set up, all mailboxes in Exchange Online, mainly using the on-prem Exchange Server for SMTP and user management. When we had the DAG, we also had a load balancer in the setup. We've since taken that out and changed all DNS to point to the IP of the new 2019 Exchange Server. Everything seems to be running fine except we have a lot of on-prem apps and printers that use SMTP to send email. We are facing an issue where most emails have a delay of 1 minute and a few seconds, which causes the page where a user submits the email to wait for a response and just sits there for that minute. In some instances, our SQL jobs see this as a failure and retry, but then we get duplicate emails for those task notifications. Sometimes it is working fine, I can send 10 emails from a printer in a row with no delay then the 11th has the delay. I've worked with Microsoft to check settings and logs and they are indicating it is related to a networking problem but the delay is on the server itself when I analyze the message header of a delayed message as seen in the image (blacked out hostname of Exchange server). Next step in the message analyzer is from our public IP to Exchange Online which has no delays. Any guidance would be appreciated.EWS Autodiscover Process in Hybrid with "internal" Exchange Servers
Hi everyone, i really need help about the EWS Autodiscover process in a specific hybrid Environment. Customer is starting to use Exchange Online. For Full Hybrid configuration there is a seperate new Exchange SE with a valid certificate, NAT for IP Ranges from M365 and public available URLs for Autodiscover,EWS,... There are internal Exchange Servers which are used only for internal access. Those are the servers with all mailboxes. All URLs are configured for internal use (mail.contoso.internal) Migration is working, access to own calender is working, mailfllow is working. But there are problems to access other users calender. If a user which is migrated to Exchange Online (or via Teams) try to access another calender which is onPrem, there is no access. So i tried to use connectivity analyzer for teams integration to find out whats the problem. Result: Autodiscover resolves, connects to Hybrid and gets EWS URL as answer. But it gets the internal EWS URL from the internal Exchange Servers, not from the public available URLs which are configured at the hybrid server. I visualised the two scenarios. Number1: Thats how i thought it would work Autodiscover to autodiscover.contoso.com Hybrid answers with EWS URL: hybrid.contoso.com Connect from EXO to hybrid EWS URL Proxy to Internal Exchange Number2 : Thats what really happens Autodiscover to autodiscover.contoso.com Hybrid relays request to internal Exchange (Mailbox Server) Server answers with internal EWS URL: mail.contoso.internal Connect from EXO to internal EWS URL (which is obviously not working) So as you can see, the autodiscover process asks the internal Exchange for its EWS URLs and not as i expected the hybrid server's URLs. I always thought, the hybrid server works as a sort of proxy for every external connection from EXO. But it seems that the hybrid just relays the autodiscover request to the server which holds the mailbox. And this servers in this scenario cannot change their EWS URLs to a public resolvable FQDN. So my question is: Is this correct? Does the process always works like this or did i do anything wrong in the configuration? I hope you understand my explanation. Thanks in advance!!!Removing Retention Holds from Exchange Mailboxes
A new Exchange Online feature allows administrators to remove multiple types of holds from mailboxes (usually inactive mailboxes). It’s a great way to release holds that might be keeping inactive mailboxes lingering in a tenant. The feature doesn’t remove holds used to retain items required for eDiscovery or other compliance purposes. Even so, this is definitely a feature that needs to be carefully tested. https://office365itpros.com/2025/12/18/remove-retention-holds/
o365 public folder migration
Hi All, I have began a migration from on-prem exchange 2010 to o365 using minimal hybrid method I need to consider how i'm going to migrate public folders. I refer to two MS docs links below The first article suggests this method should be used when using a cutover or staged method https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/batch-migration-of-legacy-public-folders The second article references a hybrid setup but fails to mention if this includes the minimal hybrid option https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/set-up-legacy-hybrid-public-folders Can anyone clarify? Kind regardsExchange Server SE Licensing, Part II
Since posting my previous article about licensing and product keys in Exchange Server SE, I’ve received a ton of follow-up questions. Many of them were public, and I answered them publicly. Many were sent privately and answered privately, but I wanted to publicly share that information because I think it may generally be helpful. Discrepancies on Microsoft’s web site There were questions were about Microsoft’s https://www.microsoft.com/en-us/microsoft-365/exchange/microsoft-exchange-server-licensing-licensing-overview, which talks about Server licenses and Client Access Licenses (CALs), but doesn’t mention anything about a subscription, or Software Assurance (SA), or cloud subscription licenses. If you look at the https://web.archive.org/web/20250309171415/https:/www.microsoft.com/en-us/microsoft-365/exchange/microsoft-exchange-server-licensing-licensing-overview of that page (before Exchange Server SE was released) you’ll notice that the SE version is simply a copy and paste of Exchange Server 2019 version. I’ve said and written many times that licensing for Exchange Server SE is the same as it was for Exchange Server 2019, and that is a true statement. There were also questions about Microsoft’s https://www.microsoft.com/en-us/microsoft-365/exchange/microsoft-exchange-licensing-faq-email-for-business, which still talks about Exchange Server 2019 licensing, and also fails to mention subscriptions or SA. So, how does my article reconcile with the information on Microsoft’s licensing pages? The answer is that, while Microsoft’s licensing pages are accurate, they are also incomplete because they don’t mention anything about a subscription, SA, or cloud licenses. The good news is that I’m told by Microsoft that they will be updating those pages with complete information (and perhaps consolidating them). I don’t have a timeline to share, but updates to those pages are coming. But I’m not sure those pages actually matter, given that the source of licensing truth is https://www.microsoft.com/licensing/terms/, which has three main areas: Product Terms that describe the license terms and Use Rights of Products and Services for VL programs; Other Documents related legal materials referenced in the Product Terms; and Licensing Resources, which are links to additional information. You can (and should) also review Microsoft’s https://www.microsoft.com/licensing/terms/product/ForallSoftware/all#clause-705-h3-1 (ULTs), which apply to all software products licensed through Microsoft Volume Licensing. Note that these may not be your only rights and the only terms to which you are bound. For example, SA grants additional rights and comes with additional terms. And your VL agreement may include additional rights and terms. One of the “code changes” in Exchange Server SE RTM was the updating of a rich text file that ships with Exchange Server. This file contains the Microsoft Software License Terms (MSLT), to which you must agree in order to install Exchange Server. The MSLT is displayed, however, only when using the GUI version of Setup. But you don’t need to run Setup to view the MSLT; the file—License.rtf—is localized in several languages in the Setup files under \Setup\ServerRoles\Common\Eula\<language>. Using the Trial Edition Beyond 180 days There were several questions about using a Trial Edition beyond 180 days after installing it. Microsoft’s ULTs explicitly https://www.microsoft.com/licensing/terms/product/ForallSoftware/all#clause-723-h3-1 that “An assigned product key is required for licensed use of the software.” It also talks about technical measures that Microsoft may use to enforce these terms, but as I mentioned in my previous article, Exchange Server implements product keys, but it does not implement any activation or validation of the software. The MSLT for Exchange Server SE states “If you do not have a product key, then Section 2 (Trial) applies to you.” Some (but not all) of Section 2 is shown below. Paragraph 2 of Section 2 makes it clear that the software rights are time-sensitive and limited to 180 days after installation (2a), that you may receive periodic reminders about this time limit (2b), and that you may not be able to access data when the license term ends (2c). The language in Section 2 is used in the MSLT for multiple products. In the case of Exchange Server SE, an admin will see a message in the Exchange admin center when the Trial period ends (as described in 2b), but the product remains fully functional, and data is fully accessible, contrary to the statements in 2c. More on License Terms Paragraphs 6 and 7 on Section 2 are also worth noting: Paragraph 6 states that Microsoft is not obligated to provide support for Trial Edition deployments. While Microsoft has no obligation to provide support, they will do so, even for Trial Editions. In fact, they likely won’t ask about licensing or product keys unless its germane to the support case (for example, you can’t mount more than 5 databases on a server because it is a Trial or Standard Edition). Paragraph 7 discusses software updates, which in the case of Exchange Server SE, includes CUs, SUs, HUs, and IUs. Exchange Server SE does not check for updates, does not download updates, and does not install updates. It does include the optional Exchange Emergency Mitigation service, but that applies mitigations and does not download updates. Exchange Server SE also includes Feature Flighting which will be used by Microsoft in the future to enable features or changes present in an update, but it won’t download or install those updates automatically. Windows Server has the ability to check for and install updates, and an Exchange admin can opt into these automatic updates which include Exchange Server SUs; however, it’s a best practice to control updates to Exchange Server by installing them manually or using controlled automation. If you do install an SU manually using the GUI, then you’ll see additional License Terms, as shown below, that state the license requirements for installing the SU. Based on the above License Terms, if you don’t have a valid license for Exchange Server SE, then you don’t have the right to install the SU. Again, though, Exchange Server uses the honor system, and there is nothing that blocks the install. Client Access Licenses and Management Licenses One of the three ways to allow users or devices to legally access Exchange Server SE is by using CAL or ML equivalency licenses (the other two ways are L+SA or Exchange Online licenses). CALs are used by a user or a device, and MLs are licenses that are used by management software. “Licensing software with CALs and MLs can be complicated due to the technical nature of server products and networks.” That’s a direct quote from Microsoft’s https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license#tab-overview, and it’s very true. Microsoft has user CALs, device CALs, External Connector licenses, Server MLs for managing server operating systems (OSEs), OSE client MLs, user client MLs, and core-based licensing. Exchange Server SE (like SharePoint Server SE and Skype for Business Server SE) use the Server+CAL model (which is what the aforementioned Microsoft’s licensing pages are trying to convey). Microsoft also offers what are called CAL Suites, which is a single license that covers multiple products (e.g., one CAL that covers Exchange Server, SharePoint Server, Skype for Business Server, Windows Server, etc.). There is a Core CAL Suite and an Enterprise CAL Suite, and the Enterprise CAL Suite also includes licenses for online services such as Exchange Online Archiving for Exchange Server and Exchange Online Protection. If you have deployed on-premises and you do want to move to the cloud, Microsoft also offers CAL Suite Bridges, which is a subscription-based licensing path that moves you from L+SA to cloud subscription licenses. This is where things can get tricky when comparing licensing costs between on-premises and the cloud. Remember, cloud licensing is deployment-agnostic, so you can purchase cloud licenses and deploy solely on-premises. Ultimately, the most economical approach will depend on what you are buying and how much.
