Problem with EMS console, Exchange Toolbox console and permission to serialize tokens
Hi, we setup fresh Windows Server 2025 and install Exchange 2019 with all updates for Server and Exchange. Then we made Upgrade In-Place to Exchange Subscription Edition but problems remained. After installation: Cannot launch "Exchange Toolbox console". Expand console in progress and crash. Error: FX:{714FA079-DC14-470f-851C-B7EAAA4177C1} Type is not resolved for member 'Microsoft.Exchange.Configuration.MonadDataProvider.MonadDataAdapterInvocationException,Microsoft.Exchange.Configuration.ObjectModel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Exeption type: System.Runtime.Serialization.SerializationException Exception stack trace: at Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request) at Microsoft.ManagementConsole.Executive.RequestStatus.BeginRequest(IMessageClient messageClient, RequestInfo requestInfo) at Microsoft.ManagementConsole.Executive.SnapInRequestOperation.ProcessRequest() at Microsoft.ManagementConsole.Executive.Operation.OnThreadTransfer(SimpleOperationCallback callback) EMS console. When it runs... VERBOSE: Connecting to ex01.domain.com. New-PSSession : [ex01.domain.com] Connecting to remote server ex01.domain.com failed with the following error message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:1 + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Micr ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException + FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed But If i run this command on localy on server New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://ex01.domain.com/PowerShell/ -Authentication Kerberos everything is ok. Snapin: Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn - works. 3. Search mailbox When I run: Get-MailboxSearch I get error: Get-MailboxSearch : The requesting account does not have permission to serialize tokens. AD Exchange server computer account is member of: Domain Computers Exchange Install Domain Servers Exchange Servers Exchange Trusted subsystem Managed Availability Servers So exchange computer account doesn't belong to: Domain Admins Schema Admins Enterprise Admins Organization Management I created a new user account: Admin123 and added it to local server Administrators group Discovery Management group Domain Users Server Management but Get-MailboxSerach give the same error. Could somebody help to solve these problems? Tanks in advance Tom
Outlook Desktop users continually prompted for credentials On-Prem Exchange SE
Battling ongoing issues with users being continually prompted for password using Outlook 2024 LTSC with on-prem Exchange 2019 SE. Removed Windows credentials, turned off cache mode, removed shared calendar(s), outlook connection status seems fine. Only (temp) workaround seems to be removing mail profile and recreating it. All other network resources on domain are fine. Any input appreciated. Thanks
Exchange SE HU6: PDF attachments truncated to 13 KB via Outlook Desktop — OWA unaffected
We've spent days isolating this and ruled out everything we could touch. The corruption survives agent disabling, Bitdefender removal, and BypassFiltering — and the message tracking logs show exactly where it happens. Environment: Exchange Server SE, Build 15.2.2562.41 (HU6 / KB5081755), Windows Server 2025 Problem: PDF attachments sent internally via Outlook Desktop (MAPI) arrive corrupted at ~13 KB (original: ~32 KB, no xref/EOF). All PDF sizes, all internal recipients affected. Started 21 May 2026. Key finding — OWA works, Outlook Desktop doesn't: Sending the identical email via OWA → attachment arrives intact. Outlook Desktop → truncated. Message tracking proof: Both paths deliver the message at full size (~42 KB) via STOREDRIVER DELIVER. Only the Outlook Desktop delivery shows an additional X-SDDS=0.106 step in the STOREDRIVER latency breakdown. That step does not appear in the OWA delivery. The corruption happens inside that MAPI/TNEF store write step — not in transport. Systematically ruled out: All transport agents disabled → still 13 KB Exchange Malware Agent + Set-MalwareFilteringServer -BypassFiltering $true → still 13 KB Bitdefender GravityZone fully uninstalled from server → still 13 KB EEMS mitigations: only PING1 and M2.1.0 applied, neither affects MAPI delivery Temporal correlation: Three Windows updates installed 21.05.2026: KB5087051 (.NET Framework 4.8.1), KB5087539 (Windows Server 2025 CU), KB5089717 (Servicing Stack). Exchange SE HU6 (KB5081755) was installed around the same period. Workaround: Sending via OWA works. Not acceptable long-term. Has anyone seen this? Is this a known regression in HU6 or KB5087051?
Will server to server migration work cross-domain/cross-active directory?
Back in 2016, I upgraded a client from Exchange 2008R2 to Exchange 2016. The way I did it was "the textbook way" I built the new Exchange 2016 server on the same network as the 2008R2 server, and migrated the mailboxes from the old server to the new server, using the migration tool in the ECP interface, then deinstalled the server. It was a pretty cake migration except for one problem - the internal AD domain name was "wonkulating.com" however the client had failed to maintain public registration for that domain, and had registered "wonkulatinggronkulator.com" for use on the Internet. So I set it up so that all internal and external access was to "email address removed for privacy reasons" User were happy, and the IT dept was able to kick the migration can down the road again. Well fast forward a decade. Now I'm an employee for the former client and worse I manage the IT group there - so my can-kicking bandaid has come back to haunt me now that it's time to update to exchange SE. (it also adds to the fun that there's a couple hundred more users on the network than there were a decade ago) I decided to cut the Gordion knot and kill off "wonkulating.com" since there's not a snowball's chance in hades we could afford to buy it now. So I built a new AD for wonkulatinggronkulator.com, and did the jiggery pokery with the DNS servers and setup trust between the forests and so on and now, servers on both domains are happy happy, I can apply both wonkulating.com and wonkulatinggronkulator.com security objects to server filesystems, users can login to either domain at any workstation regardless of what domain the workstation was joined to, and so on, and we are getting ready to migrate the users and workstations off the old AD and on to the new AD. My question to all of you is this. I'm planning on installing Exchange SE into the new AD forest wonkulatinggronkulator.com and we will move the users over in groups of 10 or 20 or so, so that staff can make sure everyone is happy, can login, get at their files, etc. But what I am wondering is if the exchange servers will cooperate with each other. I'm not using ADMT or any of that to move user objects over to the new server so userIDs will exist in parallel for some time to allow a gradual migration of file and application servers. (we are too big now for the come-in-on-weekend-and-hose-everything-up-in-a-mad-rush-migration-fueled-with-pizza-and-mountain-dew routine) It would be very nice to just kick off a migration job on one of the mailservers and have the inbox copied over, but if I have to I can tear out the mailbox on the old server into a PST file and jam it into the new server via import. Documentation on microsoft.com seems to say at some points the servers will cooperate with each other and at other points it seems to say each mailserver is atomic. Like most orgs we have a bastion host mailserver that touches the actual Internet, the exchange server is only allowed to provide OWA services to the Internet, while the bastion host server (running Linux, by the way) does the actual heavy lifting of spam scanning and filtering out scam mails. Only cleaned mail is passed to the on-prem exchange server. So if the servers -won't- cooperate cross-forest, then I can adjust mail routing on a per-user basis on the bastion host to send incoming mail to the server in wonkulating.com or the server in wonkulatinggronkulator.com depending on which server they are on. Technically, the ACTUAL user ID on the old AD is WONKULATING\exampleuser while on the new AD it will be WONKULATINGGRONKULATOR\exampleuser, so the servers SHOULD be smart enough to know they are different userIDs - except that the server on wonkulating.com was hacked up by me a decade ago to believe it was authoritative for BOTH "email address removed for privacy reasons" and "email address removed for privacy reasons" email addresses and that they were the same userID basically. So, I don't know what's going to happen until I try it and all of the documentation I can find on this matter is pretty fluffy, as it assumes you are moving from a domain name you own to a different domain name you own because you bought a company or something, or you are moving from one mailserver to the other inside of the same forest/domain. Lastly, suggestions to install Exchange SE into wonkulating.com then move it later into wonkulatinggronkulator.com will be /dev/nulled immediately, I'm done kicking the can down the road. There's more than 20 years of garbage in the wonkulating.com AD and the nonsense described here is just the tip of the iceberg. (you should see the GPO's in wonkulating.com, simply horrifying) Thanks!FIX - Outlook 2013,2016,2019 fails open mailbox Exchange 2019 on-prem in offline LAN
Exchange 2019 on-prem + Outlook 2013/2016/2019 in offline LAN Symptoms: - OWA works - ECP works - Autodiscover works - Test-MAPIConnectivity is successful - Outlook profile can be created - Outlook fails to open the mailbox / “Cannot start Microsoft Outlook” / “The set of folders cannot be opened” / “The attempt to log on to Microsoft Exchange has failed” - Environment has no internet connection Root cause: The Windows client had a default gateway configured, but the gateway IP did not respond to ping. In our case the client received 192.168.1.1 as default gateway, but this IP was unreachable in the offline network. Fix: Set the client default gateway to an existing reachable IP address, for example the Exchange/DC server IP 192.168.1.5. Internet access is not required, but the default gateway must be reachable/responding. After changing: Default gateway: 192.168.1.5 DNS: 192.168.1.5 mail/autodiscover DNS or hosts pointing to Exchange 2019 Result: Outlook 2013, Outlook 2016 and Outlook 2019 connected to Exchange 2019 successfully.Offboarding mailboxes fails with “PropTagToPropertyDefinitionConversionException.”
Hybrid M365 setup, just recently upgraded the on-prem server from Exchange 2019 to Exchange SE. After doing so, migrations from Exchange Online back to Exchange On-prem fail at 10% with the error “PropTagToPropertyDefinitionConversionException.” I opened a case with M365 exchange support, and after some time, they came back to tell me that the Exchange Online portion of the process is not at fault, and that I have to engage the on-premise support team (this seems a little nuts to me, as its all connected and all supported, but I've been in this business for 30 years now, and it's not the first time I've seen buck-passing), and/or ask this community for help. Hence, this post. That error appears exactly two places on the internet, as far as I can tell: a blog (in German) from an Exchange expert doing cross-tenant migrations, and a page at https://west.jcteams.info/bhit11/docs/EX1232513.html that seems to describe my exact issue. Neither had useful suggestions - mostly, they say this: Set-MoveRequest -Identity "<UserPrincipalName>" -SkipMoving FolderRestrictions Resume-MoveRequest -Identity "<UserPrincipalName>" That didn't actually work, but when I tried the same parameters with Set-MigrationBatch, they worked as long as I ignored the message "The SkipMoving parameter is deprecated. Use the MoveOptions parameter instead. If you have any scripts that use the SkipMoving parameter, update them to use the MoveOptions parameter." So what was a simple process is now a more cumbersome workaround. Does anyone have an idea on how to troubleshoot "PropTagToPropertyDefinitionConversionException?"
Exchange on-prem license
Hello, I have installed ExchangeServerSE x64 iso file its in trial version i want to license it. What kind of license do i need? I have the following information from the EAC: Version 15.2 (Build 2562.17) Standard Trial Edition Trial and from powershell: Edition : StandardEvaluation AdminDisplayVersion : Version 15.2 (Build 2562.17) Since i've installed the ExchangeServerSE x64 is this the correct license i should require? Exchange Server Subscription Edition (SE) license 5 × Exchange Server Standard CALs (one per user/mailbox) Environment details: Exchange version: 2019 (Version 15.2) Number of mailboxes: 5 Is this valid and the correct license? Kind regards, Filip M
