The 100 migration batches limit and how to not run into it
As you might or might not know, in Exchange Online we have an upper limit of 100 migration batches. You can see this limit for MaxNumberOfBatches in the Exchange Online PowerShell Get-MigrationConfig: (To understand the MaxConcurrentMigrations limit of 300, you can check this blog post written by one of our migration experts, Brad Hughes.) 100 batches created at the same time should be enough for all O365 multi-tenant customers. But, as we have seen in support, sometimes there are support tickets opened because customers would see the error that says: “The maximum number of migration batches is already running. Please remove a batch before you add another one”. The main reason why this number of batches limit is in place is that having more than 100 batches causes performance problems and could cause outages for other customers in the multi-tenant system. Additional reading on resourcing for mailbox moves can be found here. Let’s say that you want to migrate 50,000 mailboxes to Exchange Online: you could create 50 batches with 1000 users each, and you would still have 50 batches available. If you need to complete all the migrations of users from Batch_1 at the same time, you can easily set -CompleteAfter at the migration batch level. Once this batch is completed, you could delete it to create room for another one. In real world, though, we have seen that our customers rarely want to complete large amount of mailbox migrations at the same time. This is usually the reason why large migration batches are not created but rather smaller batches are preferred. That way, all the migrated users from one migration batch at a time can be completed together. In this scenario, our recommendation is to have large batches for initial sync and if you need to complete the migration for users at a separate date, then you would complete the migration for groups of users in smaller batches, as needed. So how would you create small completion batches for already synced users from larger synced batches? Suppose you want to complete migration of users A, B and C, who reached Synced status and they are all contained in a large batch of 1000 users called Batch_1. To do this, first ensure that you have fewer than 100 batches created at the moment: (Get-MigrationBatch).count Then, proceed with PowerShell commands to get the users from the larger batch Batch_1 into the new smaller batch CompletionABC. Then complete this smaller batch and optionally, remove the completed migration batch: New-MigrationBatch -Name CompletionABC -UserIds EmailAddressOfUserA, EmailAddressOfUserB, EmailAddressOfUserC -DisableOnCopy -AutoStart Complete-MigrationBatch CompletionABC Remove-MigrationBatch CompletionABC Another method we sometimes see people using is setting -CompleteAfter on the move requests directly using Set-MoveRequest. We don't recommend this method because the Migration Service may overwrite the per-request CompleteAfter setting with the one from the batch without notice. This method of individually completing the move requests should only be done when you’ve started the migration through PowerShell, using New-MoveRequest cmdlet, without creating migration batches to contain those move requests. I hope this post gives you a better idea of how to manage migration batches with many users being migrated and not have to run into the limit of number of batches. See you in the cloud! Special thanks to Brad Hughes and Nino Bilic who contributed to this blog post and their precious help in my daily support job. Mirela Buruiana
[Japan region] Copilot Cowork not showing in the agents list despite all settings enabled
Hello, I'm based in Japan and my tenant region is Japan. I'm trying to enable the now-GA Copilot Cowork for my tenant, but Cowork does not appear in the agents list in the Microsoft 365 admin center, so I can't deploy it. Environment: Location / tenant region: Japan License: Microsoft 365 Copilot (assigned to target users and the admin account) All prerequisites appear to be in place and verified: Anthropic (AI provider acting as a Microsoft subprocessor): enabled Usage-based billing (Copilot Credits): enabled Discovery setting "AI experiences enabled by usage-based billing": set to allow users to discover and use Issue: Even with all of the above enabled, searching for "Cowork" under Integrated Apps → All agents returns no result. It also does not appear under Copilot → Settings → View all. As a result, I cannot deploy it to users, and Cowork does not show up for users at m365.cloud.microsoft either. Questions: Is there any additional setting required to make Cowork appear in the agents list? For a tenant in the Japan region, if there is a delay before the Cowork agent is provisioned after GA, what is the typical timeframe, and is there a way to check the rollout status for my tenant? Is there a specific admin role (e.g., AI Administrator) I should double-check on the account performing these steps? If anyone in the Japan region has resolved the same issue, I'd appreciate hearing how. Thank you.
Custom Agent Builder agent suddenly failing with "Oops, something happened" - no config changes
Hi All, We built a custom agent in Agent Builder (Microsoft 365 Copilot) that generates a Word risk assessment by grounding on a contract (either the document currently open via the Word Copilot add-in, or a file uploaded in the web browser chat), plus a fixed set of knowledge sources (guidance notes, playbooks). It worked reliably for about 5 days while I was testing it solo. We then rolled it out to appr. 20 users, and shortly after, it started failing consistently with a generic "Oops, something happened, try again" error, typically after a long delay, in both the Word add-in and the browser version. I can't confirm causation, but the timing lines up closely with when we expanded from single-user testing to ~20 concurrent users. I don't know whether this points to a tenant-level capacity/concurrency limit being hit, or its something else, just stating it in case others have seen a similar threshold effect. Is this a known concurrency/capacity limit for Agent Builder agents once usage scales up, or a separate backend regression affecting document grounding, and has anyone else seen this pattern after moving from single-user testing to broader rollout?Copilot Chat od kilku dni nie jest w stanie wygenerować żadnego pliku.
Każda próba użycia środowiska wykonawczego kończy się komunikatem „Niestety, osiągnięto maksymalną liczbę dostępnych komputerów. Spróbuj ponownie za godzinę”. Problem występuje od kilku dni i nie ustępuje, dni przy każdej próbie użycia funkcji wymagających środowiska wykonawczego (Python, tworzenie plików, ZIP, Excel itp.). Pozostałe funkcje Copilota działają poprawnie. Copilot w Excelu jest w stanie wykonywać operacje wymagające kodowania/Pythona. Problem występuje wyłącznie w Copilot Chat.
Has anyone seen Excel workbooks become corrupt after using M365 Copilot to summarize data?
We’ve run into an issue twice where a user opened an existing Excel sales workbook, used Microsoft 365 Copilot in Excel to summarize/analyze the data, received the response successfully, and then later could no longer open the original workbook because Excel reported it as corrupt. Internally, this has been reported as happening on some files but not all, and it has occurred twice so far. I’m trying to determine whether this is: a known issue with Copilot in Excel a workbook-specific problem related to file location/sync/versioning or something tied to workbook structure I did find public reports of related Excel Copilot issues — including Copilot crashing in Excel, failures that seem specific to certain workbooks, and Copilot-created Excel files being reported as invalid/corrupt — but I have not yet found a clear Microsoft-hosted thread describing this exact scenario with the original existing workbook becoming corrupt after summarization. If anyone has seen this, I’d appreciate any insight on: whether Microsoft has acknowledged a known issue whether this points to specific workbook features/structures whether there are logs or diagnostics that help isolate root cause whether there are best practices to reduce the riskCowork tasks not accessible - where are my cowork results?
I've been using cowork for several tasks/sessions, and I was impressed. When I was using it, I could switch between tasks/sessions and had always access to the results. Documents, and conversation. I even could continue and improve results a week later. Now, when I go to the cowork section in copilot, I still can see the list of cowork tasks at the left side. But each of them is completely empty. I mean white space, nada, nothing there.. not even a textbox to enter something. I tried with the M365 App, Edge, Firefox, new design. old design.. nada. So, what happened to my conversations and the generated documents? Is it a bug or expected behaviour? If it's expected, cowork is becoming less interesting for me. It means that I have to save my work/cowork all the time manually outside of the conversation (which I did for most of the generated documents, but not all) Help--- can I get the conversations and documents of each cowork session back, please? Dan
Has Anyone Successfully Used the Fabric Data Agent Connector with Copilot Agent?
Hi everyone, I'm facing an issue with a published Copilot agent in the Microsoft 365 app channel. The agent is configured with the Fabric Data Agent connector along with documentation as knowledge sources. However, while the agent works as expected with the Power BI connector, it fails to return responses when using the Fabric Data Agent connector in the Microsoft 365 app I understand the Fabric Data Agent connector is still in preview, but I wanted to check: Has anyone successfully used the Fabric Data Agent connector with a Copilot agent in the Microsoft 365 Copilot app? Is this a current limitation of the Microsoft 365 app channel or the preview connector? Are there any known workarounds? Is there any estimated timeline for the Fabric Data Agent connector to reach General Availability (GA) and support the Microsoft 365 app channel I'd appreciate any insights or experiences from others who have tested this scenerio Thanks!
