Episode Details

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 fi