Exchange 2010 to Microsoft 365 Migration – Recommended Approach and Tools
I’m looking for guidance on migrating Exchange 2010 (on-premises) to Microsoft 365 / Office 365. Is a direct migration from Exchange 2010 supported, or is an intermediate hop (such as upgrading Exchange or setting up a hybrid configuration) required? Additionally, could you please recommend any reliable tools that can help with this migration? I also have a few PST files that need to be migrated as part of the process. I’d appreciate insights on best practices, common challenges, and lessons learned from real-world migrations. Thanks in advance for your help.
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.
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 AdministratorExchange Hybrid Configuration Wizard - Error 1603 - Connector registration failed
Did any of you encounter this error while installing hcw on an exchange server? Here is the event viewer error details: Connector registration failed: Make sure you are a Global Administrator of your Active Directory to register the Connector. Error: '"The registration request was denied. "'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
