Ever wondered why your company’s Microsoft 365 deployments feel harder than they should? You hit 'next, next, finish' on Click-to-Run, only to discover key apps missing—or worse, users drowning in update notifications.If this sounds familiar, stick around. I’ll show you what really happens behind the scenes of Click-to-Run and how tweaking a single line in your XML can solve headaches you didn’t know you had.Click-to-Run: The Illusion of SimplicityYou click a few buttons, get the spinning wheel, and—just like that—Office is installed across your org. Click-to-Run makes it feel like anyone can deploy Microsoft 365 Apps without breaking a sweat. A lot of admins see the promise: less manual work, no big downloads or ISO hunting, and no more dusty old MSI packages from the days of Windows 7. Everything is fast, everything is supposedly modern. But if you’ve run these installs more than a handful of times at scale, you already know the cracks appear pretty quickly.Let’s say you roll out Click-to-Run for the finance team. They want Excel, Power Query, and some custom add-ins—maybe a connection to a data warehouse. Seems like a straight shot. Yet you get a ticket on Monday morning: Power Query’s missing. Someone else can’t find the Solver add-in. Another user is locked out of Office because of a surprise license prompt. It’s almost routine at this point. Meanwhile, HR’s deployment went through, but instead of the basics, every machine ends up with Publisher and Access—apps they don’t know, never use, and now want you to remove. Multiply these surprises across every department, and that “super simple” setup starts to show its true cost.It gets messier when updates start rolling in. Click-to-Run’s auto-update is supposed to take care of itself, but in practice, users end up in the middle of important work with prompts demanding they close apps—or worse, Office starts updating right before a crucial meeting. Even basic security fixes can land at the worst possible moment if you aren’t watching your update channels. Laptops left on overnight grab new builds, while other users fall out of sync because their machines dodged IT’s update window. If you’re lucky, you get support tickets. If you’re unlucky, deskside support spends the day walking from cubicle to cubicle untangling the aftermath.Microsoft definitely had a reason for moving away from the ancient MSI installers. Those old deployments were rigid, hard to patch, and didn’t play well with modern device management. With Click-to-Run, companies get faster installs, small footprint downloads, and a relatively painless way to keep pace with Microsoft’s monthly feature engine. But what most admins miss is how generic those “out-of-the-box” settings actually are. Click-to-Run doesn’t know who you are, what your teams do, or what features matter in your business. It gives everyone the same bundle with all the defaults turned on, like a hotel breakfast buffet where you can’t actually choose what’s being served.The problem isn’t that Click-to-Run is broken. It’s that it’s too broad. Most organizations leave the defaults untouched, trusting that Microsoft’s “recommended” configuration is good enough. In reality, these settings are one-size-fits-none. When you push out the standard install, Publisher and Access sneak onto endpoints. Teams gets installed on every workstation, even those that run Citrix or VDI, where you might want it left out. Everyone ends up with the same base language, even in multilingual offices. Default update channels get pushed everywhere, no matter how stable your users need their apps to be—or how eager you are for new features.It’s not just anecdote, either. Recent industry data says that about 70% of SMBs run Click-to-Run straight out of the box, never customizing the deployment file or even realizing there’s anything to tweak. Admins trust the process, thinking it should just work, and only crack open documentation when things go sideways. Ask around, and you’ll find most IT leads couldn’t tell you what their current update channel even is—let alone why some teams are getting Outlook features two months late or seeing UI changes pop up out of nowhere.All that supposed convenience masks a lack of real control. You get a single installer, but no visibility into the details until something goes wrong. That means you spend less time deploying and way more hours cleaning up. The reality is, business units get frustrated, users get confused, and IT gets stuck playing referee. Even little things—a missing shortcut or a surprise language pack—turn into unwelcome distractions.But here’s the kicker: most of these pain points are avoidable. There’s a way to turn that mass deployment into something almost custom-fit, without adding layers of manual work. Picture what would happen if you could block Publisher automatically for HR, always deploy Excel with all the finance features, and make sure marketing gets the templates and add-ons they actually use. Instead of digging through support tickets, you’d be orchestrating deployments that actually match each team’s needs.Understanding when Click-to-Run works, and—more importantly—where it falls flat, is the first step to getting ahead of these issues. Once you spot where the default settings trip you up, you’re halfway to solving the problem. Now, let’s see what actually happens when you don’t settle for that generic install and try to take real control with customization.Unlocking XML: Your Secret Weapon for Smarter DeploymentsWhen someone on the IT team finally pulls up the Office Deployment Tool and texts, “Has anyone actually looked at this XML file?” you can pretty much see the panic dots pop up in the group chat. It’s familiar—an XML config full of angle brackets, install options, and language codes. At first glance, it feels like you’re peeking under the hood of something you were never meant to touch. If Click-to-Run was designed to keep things simple, XML looks like the opposite: technical, detailed, and a little intimidating. The truth? Most admins take one look, close the window, and vow never to touch it again unless there’s a fire.But here’s the thing—XML configuration is not half as scary as it looks. If you’re used to PowerShell scripts or tweaking Group Policies, XML is nothing you can’t handle. One line sets the install location. Another line keeps Access off every computer in the building. If you want Office to go to the D: drive because your C: drive is filling up, there’s a quick copy-paste for that. Suddenly, all those headaches when HR or Finance gets the wrong apps start to disappear. For an IT pro, it’s like finding out your favorite coffee spot has a secret menu. The basics are fine, but once you know what to order, your day gets ten times better.Admins love to joke that Microsoft’s defaults are nobody’s defaults, and the stats back this up. Over half of large organizations now use XML to cut out apps their staff never open. This isn’t just about saving disk space—though that helps. Cutting Publisher or Access means fewer updates to patch, less confusion for end users, and support teams who don’t have to learn the ins and outs of niche software. It turns a sprawling, catch-all Office deployment into something that feels purpose-built for your organization. Suddenly, users aren’t asking why there’s a new icon in their Start menu every month, or how to uninstall something they didn’t request.Let’s put this side by side. The default Click-to-Run install drops every Office app onto a machine. You get Word, Excel, PowerPoint, Publisher, Access, Teams—the full lineup—whether you wanted them or not. When you walk through the floor after a rollout, you notice unopened apps wasting space and update cycles. Now flip the switch: a simple XML config skips Publisher for HR, leaves Visio off legal’s systems, and makes sure only the folks that actually need Access even see it. You end up with machines that boot faster, less bloat on SSDs, and users who don’t call about random shortcut icons after patch day. Feedback trends up. Support tickets drop.It’s amazing how quickly you see wins. Maybe you need to ensure everyone’s running Office in French, and the helpdesk is tired of walking folks through language pack installs. XML lets you bake the right language in from the very start. Want OneDrive missing from your Citrix boxes? One tweak. Need to move installs off the system drive because your imaging script is running low on space? That’s two lines in the config. Most of the “customization” feels more like copy-pasting a template than deep coding. One admin I know keeps an archive of past XML files by department—messy, maybe, but it keeps repeat requests down to a five-minute job.Some of the best quick wins come from just being able to say no—to the apps, add-ins, and even languages your users never needed. Each exclusion is less drag on the network and fewer endpoints at risk when Microsoft pushes out the next security bulletin. It all adds up to a smoother, lighter M365 experience that actually feels tailored.Of course, once you’ve squashed the big annoyances—like unneeded apps and wrong installs—you start to wonder how far you can take it. There’s a real appetite for going deeper, especially in hybrid environments or organizations with more than a couple of regional offices. Need to ship Office with Japanese language packs for Tokyo, Spanish for Miami, and English everywhere else? XML can handle that. Want to ensure only specific machines in your pilot program get the bleeding-edge features while everyone else stays safe on the stable track? There’s a config line for channel assignments, too.Even complex asks—like automating rollouts to shared devices in a call center, or fine-tuning deployments across dozens of business units—are within reach. With XML, what looks like black magic becomes dead simple. You stop firefighting and start orchestrating. It’s not just the domain of power users or scripting p

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.