Microsoft 365 Apps SHOULD NOT overwrite Office 2019/2021 one-time retail installs
I want to raise a serious concern about Microsoft 365 Apps being imposed over existing Office 2019/2021 installations that were activated with legitimate one-time installation retail keys. In our case, these are not Microsoft 365 subscriptions and they are not licenses we can simply deactivate and reactivate freely. They are one-time installation retail keys. Once the product has been installed and activated, removing Office and reinstalling it later can make the original key unusable or trigger “already used” activation problems. That is precisely why the current behavior is so damaging. We have PCs with legitimate Office 2019/2021 installations. These machines did not request a migration to Microsoft 365 Apps. However, after internet connection, Office update activity, or Microsoft account interaction, Office appears to silently update, convert, or replace the existing retail installation with the Microsoft 365 Apps version. This is not a minor inconvenience. It creates a serious licensing and operational problem: -A valid one-time Office 2019/2021 installation is replaced by Microsoft 365 Apps without clear, explicit consent. -The original retail installation is no longer cleanly usable. -Fixing the issue requires uninstalling Office, removing Click-to-Run/licensing/account leftovers, and reinstalling the previous Office 2019/2021 version. -But because these keys are one-time installation keys, that reinstall process can render the original key unusable or create activation failures. -In practice, a forced Microsoft 365 conversion can destroy the value of a legitimate one-time Office license. From a user’s perspective, this looks less like a normal software update and more like an exploitative commercial strategy: using Microsoft’s control over Office updates, account sign-ins, Click-to-Run, and activation systems to push already-paid retail users toward Microsoft 365 subscriptions. Even if Microsoft does not intend that result, the practical effect is that users who already paid for Office 2019/2021 can lose practical access to their licensed product and are then nudged toward paying again through a subscription. This should not happen. A perpetual or one-time installation Office license and Microsoft 365 Apps are different products with different licensing models. Microsoft should not silently replace or convert one into the other because a Microsoft 365 account exists on the PC, because the user signs into Office, because OneDrive is present, or because Office updates are enabled. At minimum, Microsoft should provide: -A clear opt-in confirmation before replacing, converting, upgrading, or rebranding Office 2019/2021 retail installations as Microsoft 365 Apps. -A supported way to block Microsoft 365 Apps from taking over one-time installation Office versions. -A clean removal tool that fully removes Microsoft 365 Apps, Click-to-Run leftovers, licensing remnants, and account-based activation conflicts. -A reliable way to restore the original Office 2019/2021 retail installation without invalidating or losing the original one-time key. -Clear separation between Windows account sign-in, OneDrive sign-in, Microsoft 365 entitlement, and local Office retail activation. Users who purchased legitimate one-time installation Office licenses should not be forced into Microsoft 365 Apps by unclear update behavior. If Microsoft wants users to move to Microsoft 365, that should be a deliberate, informed choice — not a silent process that leaves the user cleaning up the installation and losing access to a paid retail license. I am not asking how to install Microsoft 365. I am asking Microsoft to stop Microsoft 365 Apps from taking over valid one-time Office 2019/2021 installations without explicit consent.
Moving Office 365 Mailboxes to IMAP Servers - What’s the Best Approach
I’ve recently been looking into scenarios where organizations need to move mailboxes from Microsoft 365 to IMAP based email servers, and I noticed this is still a common requirement in many migrations. In most cases, the challenge is not just moving emails, but making sure everything like folder structure, old emails, and user data stays intact without creating too much disruption for users. From what I’ve seen, doing this manually can get very complex, especially when there are multiple mailboxes or large data volumes involved. That’s where migration tools usually come into the picture. Most tools simplify things by handling: 1. Secure connection to Microsoft 365 accounts 2. Bulk mailbox migration 3. Preserving folder hierarchy 4. Reducing downtime during the move 5. Avoiding duplicate data issues One thing I’ve noticed is that running a small pilot migration first always helps. It gives a clear idea of how the actual migration will behave before moving all users. Has anyone here worked on Office 365 to IMAP migration at scale? Would be good to know what approaches or tools worked best in your case and what challenges you faced during the process.Need to Restore PST Files to Office 365 Mailboxes - What's the Best Approach
Hey everyone, I have a task coming up where I need to restore several PST files back into Office 365 mailboxes. Haven't done this before at this scale and honestly not sure where to begin. I've looked at Microsoft's native import service through Purview but I have a few concerns: Some of the PST files are quite large — not sure how well it handles that I need to restore only specific folders for some users, not the entire PST I'm worried about data consistency after the restore Would prefer something that doesn't require too many admin roles or complex setup For those who have done PST to Office 365 restores — what approach worked best for you? Any tools, tips, or things to watch out for that you wish you knew before starting?
MCA billing account stuck in "under review" status for 4+ days, no resolution
I'm the Global Admin for a Microsoft 365 tenant (domain: fortunamg.net) recently transitioned from a GoDaddy CSP reseller relationship to a direct Microsoft Customer Agreement (MCA) billing account. After setting up the MCA billing account and adding a payment method, I attempted to make an edit to my billing account address (updating to the new 9-digit zip code format). This triggered an "Account under review" status, which states the review usually takes up to 2 days. It has now been over 4 days with no update or email notification. This review is blocking me from purchasing a subscription, which I need to do to restore an active Microsoft 365 subscription on this tenant (currently showing as "Disabled" following the GoDaddy detach). Billing Account ID: 7793dd6e-68c9-5362-c5e2-3fe091b9854c Domain: fortunamg.net Could someone help check the status of this review or escalate to the appropriate team? Phone support has been unable to resolve this. Thank you.Office 365 Mailbox Export to PST - Third Party Tools: What’s Your Experience?
Exporting Office 365 mailboxes to PST is still a common requirement in many Microsoft 365 environments, especially for backup, compliance, and migration scenarios. While Microsoft offers native options like Purview eDiscovery and Outlook export, many administrators also consider third-party tools when dealing with large mailboxes or bulk export requirements. In real-world scenarios, factors like speed, ease of use, permission handling, and consistency of exported data often influence the choice of tool. Some teams prefer native methods for compliance control, while others explore third-party solutions to simplify large-scale or repeated export tasks. For those working with Microsoft 365, what has your experience been with third-party PST export tools? Have they helped in your environment, or do you still rely mainly on Microsoft’s native options?
Migration from Hosted Exchange (Hybrid) to M365 Classic Outlook Client Problems and Solutions
Hello Everyone, I'm a tech who started on a 8088 processor in the 80's. Not mentioning the Vic20 and C64 since that hardly seem relevant! I'm posting here to hopefully help the next person with the issues I've had over the last few weeks. My client had to port his email from a provider with an on-perm Exchange server in a Hybrid setup with M365 to his own M365 environment. I expected this was to be about 3 hours of work for me - setup M365 environment, plan the cut-over window, update the Outlook clients on each PC. It ended up being roughly 20 hours of my time and at least 10 hours of dedicated time for my client. For those wanting to jump directly to what mostly fixed it use this link, it should get you past the dreaded "an encrypted connection to your mail server is not available" when trying to add the mail account into a clean profile. Use https://support.microsoft.com/en-us/windows/classic-outlook-troubleshooters-086e3d66-5404-4034-9cc5-545909dcc166 and pick "Classic Outlook Profile Setup Troubleshooter" Most hits are going to tell you its an autodiscovery issue, but if you're reading this I'm going to assume you've already confirmed that. Our issue was some ghost configuration, only on the PCs previously setup for mail on the old server. A new PC could add the same account without issue. Some of the research suggested this would not happen if the proper Microsoft migration process is followed to move the account - but in our case the previous provider was unable to perform the migration. I'll skip over the research we tried along the way, such as New Outlook Profiles, Registry entry changes, MS Personal users with the same email as MS Business Users, Autodiscover problems (including concerns that the base website for the client was offering invalid data), and so on. After each hit where we applied a fix we again had to try adding the mail to the profile, and each time we sat watching the little circle for up to 5 minutes only to get the same error. Now, once we found the link above - which did not come up in most searches - things got better, but not 100%. We added the profile ok but then Outlook gave a permission error while starting. To fix that, the user signed in must have administrative access and you use File Explorer to navigate to the folder identified in the error. In our case it was in folders kept under \Windows\System32\. When prompted that we need to grant permanent access we said yes. In our case this is where Outlook was storing the ost files. That worked for most of the clients, but we had one additional issue where the error was pointing to a folder that didn't exist. Just creating the folder was not enough, the final fix was to hold CTRL-SHIFT down while opening Outlook to start in administrative mode to allow it to create the ost file in the newly created folder. Finally 3 weeks after our cut over window, while the client had to use OWA, we were able to get outlook running. This was critical for my client because they did not have access to the mail history since the migration didn't happen - they had to open a copy of their PST in Outlook and use mail in OWA and constantly bounce back and forth. I hope this helps someone avoid the pain we went though!Migrating G suite to Office 365
Dears, Good day, I working on a company which hosted their email on G suite, and I want to migrate all mailboxes, calendar, tasks, files, all things to Office 365. kindly let me know the steps for Migration, we have 69 users needed to be completely migrated. Kindly advise
O365 Email Migration to Another Tenant while Deferring Migration of Sharepoint files
Hi, This is the context: ChildCompany has O365 and it has an Azure AD in hybrid mode synchronizing to a on-prem AD server. They have an internal domain ChildCompany.com, and an external domain ChildCompany.com where they also receive and send email using O365. ParentCompany is going absorb the ChildCompany some time in next year, and I was asked about the integration options. According to this https://download.microsoft.com/download/b/a/1/ba19dfe7-96e2-4983-8783-4dcff9cebe7b/microsoft-365-tenant-to-tenant-migration.pdf I could do a phased migration, where the end state is that they decomm their onprem AD and that they only use our ParentCompany systems. The business requirement is to start their integration with Email, and then in later phases do the Sharepoint integration as that requires way more analysis on their data sources, as they also have wikis and many other on prem legacy stuff. They are less than 50 users, so I can use Quest migration tools for the email part, but I wonder what needs to happen in what order. This is what I have in mind: Migrate their current O365 into our ParentCompany Office 365 subscription, so that they can continue logging in into their domain joined windows machines using childCompany.co, so they start using ParentCompany.com email addresses, but the problem then is how can they continue using their sharepoint and onedrive resources associated with the Azure and local domain at ChildCompany.com? This is more or less what I have in mind, for the intermediate step, the cutover: Child Company ParentCompany --------------------- ---------------- On-Prem | MS Cloud: | MS Cloud: ---------------|----------------------|-------------- Local AD (ADFS)| Azure Subscription | Azure Sub | Azure AD | Azure AD |--------------------- |--------------------- | O365 Sub -> | O365 Sub | Exchange mailboxes-> | Exchange mailboxes | Sharepoint? -> | ??? | -------------------- |--------------------- I wonder how could it be possible to defer the sharepoint and onedrive migration, so that the child company users can still work on their sharepoint files using their normal auth methods, while disabling childcompany.com as MX so they start using ParentCompany.com mailboxes.Is that even possible? Would make more sense to try to migrate everything at once? That is way more work, but I'm weighting my options.Cross tenant migration tools : New MS solution compared to Migration Wiz?
Hi, I'm looking for informations about advantages and limitations between new Microsoft Cross Tenant migration solution (Preview) and "Migration Wiz". Microsoft solution look more limited and doesn't seem to have Free/busy sync. What are the returns for those who did use MS cross tenant solution ? Thanks,
