Microsoft 365 Outlook Classic Latest Update Copilot issues
Hello to all, we are currently using the Microsoft 365 Outlook Classic, using version Version 2604 Build 16.0.19929.20172 (Current Channel) Copilot works as expected; However ever since the next update was released (Version 2605 (Build 20026.20076)) some users including me, have been getting the below error: I have tried uninstalling and installing the latest version directly, with the same issue. Scanned for any corrupted system files with no issues,but still get the error; I have tried the update Licence from the Outlook application, with no issues but the copilot something went wrong error keeps on persisting. Internet searches are very vague and the I have found some registry suggestions which I have also tried with no solution. The only way to get Copilot working on Outlook Classic was to revert to a previous working version, only then Copilot works as expected. This only happens in Outlook Classic; Copilot works fine on the latest version of Microsoft Office 365 with Word, Excel, etc. For those that maybe might ask why not switch to the New Outlook, we have had issues with it and it has been recommended to use the Classic Outlook for the time being. Has anyone been experiencing such issues please? Thanks for any help.Outlook Cached Mode Repeatedly Re-syncs Mailbox After Restart (Starts Again Around 3.99 GB)
Hi everyone, I’m experiencing a strange Outlook Cached Exchange Mode issue with a Microsoft 365 mailbox after a recent Windows rebuild and wanted to see if anyone has seen similar behavior. Environment: Microsoft 365 mailbox (Exchange Online) Outlook for Microsoft 365 Version 2605 Build 16.0.20026.20076 64-bit Windows 11 25H2 Fresh OS rebuild performed twice New Outlook profile created Office completely reinstalled OST recreated multiple times Issue: When Cached Exchange Mode is enabled, Outlook starts downloading/synchronizing mail normally, and the OST file continues to grow correctly. However, after every reboot or Outlook restart, Outlook again shows “Downloading…” starting from around 3.99 GB. Important observations: Online Mode works perfectly OUTLOOK.EXE closes properly after exit OST file is NOT deleted and continues growing Sync slider changes (1 month, 1 year, all mail) make no difference Disabling Outlook indexing did not help New Outlook profile did not help Reinstalling Office did not help Problem only started after OS rebuild Before rebuild, same mailbox worked normally in Cached Mode No pending office or windows update. It does not appear to actually re-download the mailbox from scratch because the OST size keeps increasing, but Outlook repeatedly processes/downloads from around the same 3.99 GB point after restart. Has anyone seen: Cached Mode replaying synchronization repeatedly after restart? Similar behavior on recent Current Channel builds? Security/EDR products interfering with OST synchronization state? Any known regressions with Outlook Version 2605 Build 16.0.20026.20076? Any suggestions or similar experiences would be appreciated.
Is Office 365 E3 Developer free
Hi, My tenant had a license named "Office 365 E3 Developer" which allowed us to use Outlook / Exchange (among other Microsoft Office products). This license isn't from the Microsoft 365 Developer Program, which come with free licenses. This license costed CA$11.60 a month per user when we initially purchased it. On May 2, 2026 it still costs $11.60, but when I received my monthly invoice for this tenant, this license was free. I searched around to see whether this license became free recently, but I couldn't find any info on this. The links I found all say it's a paid license. I was wondering if there's any info on this to see why it became free? Or is it a mistake and Microsoft'll be charging us the next billing cycle? Jason
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!Microsoft Rolls Out the New Calendar Sharing Model
An automatic upgrade is currently ongoing to move Outlook calendar sharing from the old MAPI-based model to a new REST-based model. The new model has been available to Outlook classic clients on an optional basis and is now becoming the default. The REST model is simpler and exploits the Exchange Online service instead of depending on client transactions. It’s also part of the transition to the new Outlook. https://office365itpros.com/2026/05/28/calendar-sharing-outlook/
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.
