migration
793 TopicsEdit/Mass Edit Powerpoint linked file addresses
As the title suggests I'm looking for a way to manually edit or ideally mass edit the address to linked files in powerpoint. For context I play several games where I need to keep track of what builds I have on which character, and sometimes their in-game inventory. Unfortunately the games don't really have the greatest inventory management for the in-game item side of things. In addition the only way sometimes to remember a character's build is to log onto that character and pull up their build page. With enough characters it can be pain remember what I have where even though I enjoy the games themselves. To get around some of the flaws I have powerpoints I use to keep track of certain things like inventory and build. One ppt may have photos of all the current builds for each character, another may have photos of their inventory and so forth. Certainly not ideal but once the initial setup was done, it's been fairly easy to maintain and I only have to update an odd photo here or there if something changes. Which brings me to my potential issue here. I've been keeping the ppts on a thumb drive along with the photos so I can have everything in one place. Recently the drive decided it was done and checked into that silicone repository in the sky and no longer works. Fortunately however I was able to move everything over to a newer drive before the old one finally checked out. While I was able to save my data, I also introduced 2 side effects I wasn't thinking of at the time in my haste to avoid losing everything. When moving everything over I moved things over in batches to avoid taxing the failing drive too hard and placed each batch in its own folder to avoid copying the same thing more than once. So think something like Folder 1, Folder 2, Folder 3, and so on. To conserve on file size of the ppt itself I always chose the option of "Link to File" when inserting the photos to the slides instead of the basic "Insert" or "Insert and Link" options. This means 2 things, the drive location is no longer correct, and the folder location is no longer correct in the links. While I could in theory just change the drive letter and make the folder structure the same again, moving it in batches actually let me organize the raw photos better, but means I now need to correct the addresses for the ppts themselves since the old links no longer work. In the program I know we can go to Info, then press the Edit Links To Files button, and try to change stuff there. The problem is that I can only change one thing at the time there. On top of that if I press the Change Source button, it wants me to find the photo individually vs just chanting the text address of the photo. These wouldn't be issues if it was just a few photos we're talking about as I could just go in, relink by hunting each one and roll. However there are around 250 photos that I would have to do this for, and it would be very tedious. Plus the fact the previews don't work anymore either. (yes i'm one of those kinds of gamers) So what I'm hoping you folks can help me with is a way to edit the text addresses manually for the links. Ideally in mass groups, but I can do it one at the time if I have to. For example let's say I have photo one and it's address looks like "D:\Game1\Character Group1\CharacterA\Build1\Photo1" on the old drive. What I want is a way to change it to say "E:\Game1\Batch1\Character Group1\CharacterA\Build1\Photo1" type of thing. Ideally I'm hoping for a way to change those addresses in mass. If I have to text edit them all one by one, that's still alot faster than having to hunt and relink each photo individually. Thanks in advance for any advice.16Views0likes0CommentsMSSP migration to Unified portal: how are you sequencing your customer portfolio?
Following the automation and SOAR discussion, I wanted to open a conversation specifically focused on the MSSP and multi-tenant side of the migration, because this is where the coordination challenges are an order of magnitude higher than the technical ones. A few things I am working through before writing this up as Part 5 of the migration series. On Workspace Manager: Microsoft's own documentation now points you away from Workspace Manager at the point of onboarding to the Defender portal, directing you to Microsoft Defender multitenant management instead. For MSSPs who built their operating model around Workspace Manager, this is a significant structural change. For those implementing now, the recommendation is to go straight to the multitenant portal. I am interested in what the transition has looked like in practice for teams who were mid-flight on Workspace Manager when this became clear. On access delegation: one of the more honest framings I want to include in the article is around the GDAP plus Unified RBAC gap. A Microsoft employee confirmed in the RSAC 2026 thread that Unified RBAC support for GDAP in the Defender portal is on the roadmap with no firm date. MSSPs choosing between Entra B2B and the governance relationships model today are making an architectural call that is difficult to reverse. I want to present this accurately, and real experience from practitioners will sharpen that framing. On the connector deployment constraint: you cannot deploy connectors from a managed workspace configured with Azure Lighthouse alone, you also need GDAP. This makes a layered delegation architecture, Lighthouse plus GDAP plus B2B or governance relationships, necessary rather than optional. I am curious whether MSSPs are already running this layered model or whether most are still trying to make Lighthouse work as a single mechanism. On migration sequencing: the question I want to ask specifically is how teams are structuring their customer portfolio migration. Are you running waves based on customer complexity, based on contract renewal timing, based on customer risk appetite, or some other factor? And when something goes wrong in one tenant's migration, how are you containing the impact on the rest of the programme? Sharing the full article once it is written. Happy to discuss anything above in more detail in the thread.114Views0likes1CommentThe 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 Buruiana35KViews0likes9CommentsMicrosoft 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.127Views0likes2CommentsThe Sentinel migration mental model question: what's actually retiring vs what isn't?
Something I keep seeing come up in conversations with other Sentinel operators lately, and I think it's worth surfacing here as a proper discussion. There's a consistent gap in how the migration to the Defender portal is being understood, and I think it's causing some teams to either over-scope their effort or under-prepare. The gap is this: the Microsoft comms have consistently told us *what* is happening (Azure portal experience retires March 31, 2027), but the question that actually drives migration planning, what is architecturally changing versus what is just moving to a different screen, doesn't have a clean answer anywhere in the community right now. The framing I've been working with, which I'd genuinely like to get other practitioners to poke holes in: What's retiring: The Azure portal UI experience for Sentinel operations. Incident management, analytics rule configuration, hunting, automation management: all of that moves to the Defender portal. What isn't changing: The Log Analytics workspace, all ingested data, your KQL rules, connectors, retention config, billing. None of that moves. The Defender XDR data lake is a separate Microsoft-managed layer, not a replacement for your workspace. Where it gets genuinely complex: MSSP/multi-tenant setups, teams with meaningful SOAR investments, and anyone who's built tooling against the SecurityInsights API for incident management (which now needs to shift to Microsoft Graph for unified incidents). The deadline extension from July 2026 to March 2027 tells its own story. Microsoft acknowledged that scale operators needed more time and capabilities. If you're in that camp, that extra runway is for proper planning, not deferral. A few questions I'd genuinely love to hear about from people who've started the migration or are actively scoping it: For those who've done the onboarding already: what was the thing that caught you most off guard that isn't well-documented? For anyone running Sentinel across multiple tenants: how are you approaching the GDAP gap while Microsoft completes that capability? Are you using B2B authentication as the interim path, or Azure Lighthouse for cross-workspace querying? I've been writing up a more detailed breakdown of this, covering the RBAC transition, automation review, and the MSSP-specific path, and the community discussion here is genuinely useful for making sure the practitioner perspective covers the right edge cases. Happy to share more context on anything above if useful.Solved531Views2likes7CommentsNeed 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?73Views0likes1CommentMCA 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.78Views0likes2Comments