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
AuthServer in Exchange Online
The result of Get-AuthServer is different between on-prem and EXO. The list of objects from EXO get-authserver includes some "IssuerIdentifiers" that include a "{tenantid}" pattern. Was this supposed to be expanded by a script, or by HCW? (HCW has never run to completion without exceptions.) There seems to be no documentation about this: no list of default entries, no documentation on the expected form, few mentions of the use of Set-AuthServer/New-AuthServer, and the options don't match the properties.
Exchange 2019 AvailableNewMailboxSpace
Hello! Colleagues, have you encountered a situation where Exchange 2019 does not provide accurate information about the amount of free space in databases (AvailableNewMailboxSpace) via EMS? Using this command: Get-MailboxDatabase -Status | Sort-Object Name | Select-Object Name,@{Name=‘DB Size (GB)’; Expression={[math]::Round($_.DatabaseSize.ToGb(),2)}},@{Name=‘Free Space (GB)’;Expression={[math]::Round($_.AvailableNewMailboxSpace.ToGb(),2)}} | Format-Table -AutoSize Exchange 2016 displays the information correctly, but 2019 does not display it correctly in gigabytes or the numbers are unclear. Do you know of another way? Thank you!Which ExchangeServerApp is the right one? How to tell?
From running HCW multiple times w/ various exceptions, we have a number of separate ExchangeServerApp instances in Entra. How can I definitively tell which one (or more) is the correct instance? I can't find any of the UUIDs in the Entra entries anywhere in the Exchange Server configuration. I can't run the ConfigureHybridExchangeApplication script because (from the error it gives) it doesn't handle the multiple app identifiers. I submitted feedback but haven't heard back from the CSS-Exchange people. Any guidance appreciated.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 Administrator
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 meIssue 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
