What to do? SE or Decommission
I’ll start by outlining our current environment for context: Two standalone Exchange Server 2016 VMs. Primarily used for recipient management in a hybrid setup. Also functions as an anonymous relay for two LOB applications — one of which requires the mail service to reside on the same network as the application (as per vendor requirement). We have not opted for Extended Support (ESU) and installed the latest available Security Update last week. Management has been presented with the following options to move forward: 1) Perform a legacy upgrade — build two new servers and migrate from Exchange 2016 to Subscription Edition (SE). 2) Migrate LOB applications to another SMTP service — this would allow continued use of Exchange Management Shell for recipient management (by setting up a new server, preparing the schema for SE, and following Microsoft’s decommissioning process). 3) Migrate both LOB applications to another SMTP service and management to alternative platforms such as Easy365 or ManageEngine, removing the dependency on Exchange entirely. This post is mainly to gather some insights and general discussion around the best path forward. From a risk management perspective, since we’re effectively sitting on a time bomb without further Microsoft updates, I’m leaning toward option 2, especially given that all mailboxes have long been migrated to Exchange Online. What should I be watching out for with this approach? It seems many have taken a similar path — I’d appreciate hearing about any challenges or pitfalls you encountered and how you mitigated them during implementation.
Exchnage 2019 on prem EMS not working. Recreating Exchange Virtual Directories failed
I have two exchange 2019 on prem in DAG. Recently EMS (Exchange management shell) on both servers stop working and I tried to delete and recreate on MAIL2 but unsuccessful. Basically it return error that The AD configuration for virtual directory 'Powershell' already exists I tried to delete first with Remove-PowerShellVirtualDirectory I tried clean up IIS and AD but still getting this error, even that in ADSI edit I delete all powershell objects for MAIL2 Exchange Health Checker: beside that server is in maintenance mode, nothing interesting. just the last line: Default Web Site/PowerShell has authentication set, which is unsupported. Error form PowerShell: New-PowershellVirtualDirectory : The AD configuration for virtual directory 'Powershell' already exists in 'CN=Powershell (Exchange Back End),CN=HTTP,CN=Protocols,CN=MAIL2,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Company Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=rcompany,DC=local', please remove this AD configuration manually. Parameter name: VirtualDirectoryName At line:1 char:1 New-PowershellVirtualDirectory -Name "Powershell" -Role "Mailbox" -Re ... CategoryInfo : InvalidArgument: (MAIL2\Powershell (Exchange Back End):ADObjectId) [New-PowerShellVirtualDirectory], ArgumentException FullyQualifiedErrorId : [Server=MAIL2,RequestId=2bb82483-c56a-4e4f-8d08-c81691b34bd1,TimeStamp=11/4/2025 2:31:50 PM] [FailureCategory=Cmdlet-ArgumentException] B318F342,Microsoft.Exchange.Management.SystemConfigurat
Help~After installing Exchange 2019, mail is stuck in Draft in OWA
Hi all I dont undertand this symptom. Now I installed one new DC, one new Exchange 2019(CU13) in active directory domain. and I just set recieve connector(check anonymous user in Default Exchange) and created send connector and I sent mail to my own mailbox(administrator), and I also sent mail to other mailboxes, but I only have stuck Draft folder in OWA. before install Exchange 2019 CU13, I installed Exchange 2029 CU15 but it was same symptom so after removing Exchange 2019 CU15, I reinstalled Exchange CU 13. but it was same. DC and Exchange OS are Windows Server 2022 Standard on Dell H/W. ipv4 192.168.10.202 subnet 255.255.255.0 GW 192.168.10.1 Dns1 192.168.10.201(DC) It's the same as the link below, but there's nothing solved. T.T https://www.reddit.com/r/exchangeserver/comments/1daxga2/exchange_server_2019_emails_get_stuck_in_drafts/#:~:text=Here's%20some%20information%20about%20emails%20getting%20stuck,lots%20of%20space%20may%20not%20always%20work. If anyone knows how to solve this problem, please help me
Exchange Server 2019 to Subscription Edition (SE) Licensing and Migration Guidance
1. Current Infrastructure Setup Component Detail Notes Product Microsoft Exchange Server 2019 Enterprise Edition Servers 3 Virtual Servers (VMware) Configured in a Database Availability Group (DAG) Version Cumulative Update (CU) 15 Licenses Server License and 1100 CALs (Standard/Enterprise) Purchased in 2019 without Software Assurance (SA). 2. Core Licensing and Compliance Queries We require definitive guidance on the following compliance and purchase requirements: Software Assurance (SA) Requirement: Is Software Assurance mandatory for our existing Exchange Server 2019 setup for ongoing compliance and full support? Please advise on the status of our current setup without SA. Standalone SA Purchase: As our Exchange Server licenses/CALs were purchased in 2019 without SA, is it possible for us to purchase standalone Software Assurance for our existing Exchange Server 2019 licenses now, or must we purchase a completely new license with SA? Client Access License (CAL) Migration: Will our existing Exchange Server 2019 Standard/Enterprise CALs be compatible and automatically migrate to the Subscription Edition (SE) requirement, or must we purchase new CALs specifically for Exchange Server SE? Please clarify if the old CALs will become obsolete. 3. Recommended Migration Path (Budgeting Focus) Based on the licensing realities, we need advice on the most financially responsible path to move to Exchange Server SE. Please guide us on which of the following scenarios is recommended: Option A: Purchase Software Assurance for our existing Exchange Server 2019 infrastructure, and then migrate to SE, utilizing the same 2019 CALs (if permissible). Option B: Forego purchasing SA for the 2019 environment and directly purchase new Exchange Server Subscription Edition (SE) licenses and corresponding new CALs (if necessary). We look forward to your detailed guidance to ensure full compliance and a smooth transition to Exchange Server SE. Thank you, Narayan Das Senior System AdministratorIssue with DnsConnectorDelivery
Background: We are currently migrating from Exchange 2016 to 2019 in a hybrid environment. We have 2 2016 servers both in our main datacenter, and 2 2019 servers, one in our main datacenter and one in our offsite datacenter. Backup datacenter has its own DCs that are replicas of our main datacenter's DCs. Exchange 2019 has been installed and updated to CU 11. Problem: When I run the hybrid configuration wizard and select all 4 servers to be included in the send and receive connectors, everything completes and no errors appear. However, mail gets stuck in the DnsConnectorDelivery queue on the server in our backup datacenter. The NextHopDomain for the stuck mail is our M365 domain, domain.mail.onmicrosoft.com As soon as I remove the server in the backup site from the send and receive connectors, mail flows correctly again. I've done a lot of internet searching and it seems the issue has something to do with our MX record, but both domains have the correct record in their DNS. What could be causing the issue? Any help is appreciated!Games hardware vendors play
Regretfully, some hardware vendors continue to play games with the server and storage configurations they publish through Microsoft's ESRP (Exchange Solution Reviewed Program). Of course, the solution isn't really reviewed in any realistic sense of the word... https://www.petri.com/games-vendors-play-exchange-hardware-configurations
Exchange synch/profile issue
Dear community, I need help to solve a problem. 1.) I'm using Outlook classic 2016 2.) I need two mail accounts in outlook a.) my gmail account - all good with that one b.) my AWS Workmail account 3.) all used to work fine till I had another problem with teams integration into my calendar which I tried to fix without success. After a while I thought, that when I setup outlook from scratch that this could solve the problem - but it got worse. 4.) when I started the newly installed outlook, I can load my gmail account, and when I add my AWS Workmail account, I get the message that the account was successfully added and need to restart Outlook. 5.) After the restart I get the two messages: - The name cannot be matched to a name in the address list. - Cannot start Microsoft Outlook. Cannot open the Outlook window. The set of folders cannot be opened. An unexpected error has occurred. 6.) so the AWS Workmail is not loaded. I also tried to add the account manually in all different ways but without success. The integration of the AWS mail account on my Android Outlook works perfectly fine. I dont know where the problem is and tried to get answers from AI and Microsoft Support without success. Anyone has an idea? Many thanks, RobArbitration mailbox
Issue: Arbitration Mailbox Issue During Exchange 2016 to 2019 Migration. Environment Overview: Mixed Exchange environment: Exchange 2016: EX1-16, EX2-16, DR1-16, DR2-16 Exchange 2019: EX1-19, EX2-19 Currently migrating mailboxes from Exchange 2016 to Exchange 2019. Issue Description: One system mailbox was found on an orphaned Exchange server and i removed manually. Post-removal, errors were observed related to the Migration and Federation arbitration mailboxes. Both mailboxes appeared under the User container but were not functioning correctly. A user-type mailbox with the display name “Migration” appeared. I thought this may cause issue with arbitration mailboxes. Remediation Steps Taken: Removed the user-type mailbox with the display name “Migration.” Manually removed both FederationMailbox and MigrationMailbox objects. Verified that the Exchange Trusted Subsystem has correct permissions on the Microsoft Exchange Security Objects (MSEO) container. Executed Setup.exe /PrepareAD, Its Re-created the Federation and Migration related users. Executed the following command to enable the arbitration mailbox: Enable-Mailbox -Identity <GUID-of-MigrationMailbox> -Arbitration (command executed successfully). Current Problem: Despite successful execution of the Enable-Mailbox command, the msExchRecipientTypeDetails attribute is not updating to the expected value. Current value: 8388608 and display name also looks wrong because its show “Microsoft Exchange Approval Assistant” seems to be incorrectly tied to the migration mailbox. This issue is preventing proper functionality of the migration mailbox, and as a result, the remaining mailboxes cannot be moved from Exchange 2016 to Exchange 2019.new Exchange Installation Autodiscover
Hi I have had a lab environment and suspended this to get experience with a new setup. Old setup had a ADFS server in place. New lab setup is based on Windows Server 2025, 1 DC, 1 Exchange server SE. Installation is ok. Client is a Windows 11 machine with Outlook 2019. DC is synching to EntraID. All based on German language. GPO for autodiscover is set. As well the DNS records. Post installation is the part where I am have an issue at. At least in the part of the autodiscover. Adding the primary mail address is always leading in pointing to the company authentification page adfs.xy.com which was in the old lab in place. I cant see any DNS entry neither on my external DNS provider nor internal (brand new setup) and have no clou where to search further. Wensearch did also not lead me to any solution. And a workaround to disable autodiscover is not my goal. Therefore I am happy to get any idea where to look at to get read of the adfs link. Appreciate your support. THY mame
