Unpacking Endpoint Management is back - and we’ve got a lot to talk about
If you've been missing real, candid conversations about endpoint management, good news! Unpacking Endpoint Management is officially back. This series is all about what actually works. No fluff, just practical tips, proven strategies, and honest discussions to help you optimize and simplify the way you manage and secure endpoints today (and prepare for what's next). We're bringing together people from across Microsoft Intune, Security, and Customer Experience engineering and product teams, along with guest practitioners, to share what's worked, what hasn't, and what we've learned along the way. And yes…we're absolutely here for the tough questions. A quick update on the hosts Danny Guillory, a familiar face to the community and a Product Manager for Intune and Configuration Manager, will continue to host the series. He's joined this season by Rachelle Blanchard as co‑host, bringing a strong community and discovery lens to the series. Rachelle focuses on surfacing real customer questions and guiding conversations toward practical outcomes, helping ensure each episode reflects how endpoint management works in the real world. Up next What should we cover? Drop ideas below in the comments. Sign in to the Tech Community and follow this post for the latest updates on upcoming episodes. Catch up on demand You may have missed them, but you don't have to miss out on the learnings. Watch and learn when it's convenient for you. Policy: from hybrid to cloud-native Device security with Microsoft Intune Trends in endpoint management (live from Tech Takeoff 2026) Not sure where to start? Watch our most recent episode, App management at scale with Intune, now on demand! What's the format? This web series is streamed live on Tech Community, LinkedIn, YouTube, and X. In addition to open discussion, we answer your questions so sign in (or sign up for) the Tech Community and RSVP to submit questions early and throughout the live show. How do I join? There's no call or meeting to join. Simply head to aka.ms/JoinUEM. Show up at start time, watch live, and jump into the discussion with us. Help shape the series This series is for you - so tell us what you want to hear. Drop a comment below with: Topics you'd like us to cover Tough questions you want answered Speakers you'd love to hear from We can't wait to get started - and even more excited to hear from you along the way. Join the Community to get early insight into what's coming for Intune, connect with experts, and share real-world feedback that helps shape the product. 👉 aka.ms/JoinIntuneCommunityThe 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!
