Click-to-Run vs XML: You’re Doing M365 Deployment Wrong

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 Simplicity


You 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 Deployments


When 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 pros. Any admin with a little
patience finds XML is the fastest way to move from generic
installs to actual business value.So, if you’ve been hoping for a
middle ground between hands-off and completely bespoke, it’s
right here—in black and white config. And if you’re starting to
picture an entire enterprise steered by a few clever configs,
don’t worry, we’re about to step into exactly that space. Because
XML’s real power shows up when you hit enterprise scale and the
requests get messy. Now, let’s look at how you keep control when
every department wants something different.


Scaling Up: Advanced XML Tricks for Real-World Complexity


It always sounds great in the meeting: “Let’s standardize our
Office deployment, but tailor it for each department.” Anyone
who’s actually tried pushing M365 Apps across more than a handful
of teams knows what comes next—twenty competing requirements and
a tidal wave of requests. Finance wants only Excel and Word,
along with a handful of add-ins. Marketing wants every publishing
tool under the sun. The regional branch in Tokyo needs PowerPoint
in Japanese, while a remote call center wants shared device
activation because fifteen people use the same machine. IT ends
up with a spreadsheet longer than their last hardware budget and,
eventually, the same catch-all deployment rolls out to everyone.
Most teams compromise and wind up with machines full of software
that half their users never open.Not long ago, I worked with a
global firm that finally broke out of that cycle. They didn’t
start with some giant automation tool—the team just dug into what
XML could actually handle. Marketing got their own XML config:
Publisher and Visio included, Access out. Developers received a
neatly trimmed install—Word, Excel, PowerPoint, OneNote—delivered
in English and French, no extra apps cluttering up the system.
HR, meanwhile, got a clean, basic install with no Power Query and
no distractions. The tech team set up configs for shared device
activation at several remote offices, which had always dragged
down helpdesk time with weird licensing prompts. That same
rollout used XML to control where files installed—not just the
drive letter, but the actual subdirectory on each
workstation—because imaging scripts clashed during Windows
upgrades. They started with about a dozen configs and grew from
there, adapting by department and region instead of sticking
everyone with the same one-size-fits-no-one package.Language
packs sound simple at first, but nothing wastes time like
fielding calls from users struggling to change the UI back to
their native tongue. The XML configuration lets you pin languages
from the start and even add fallback languages. In the Tokyo
office, every install included Japanese and English, while sites
in Quebec got French and English pre-baked, so macros and
proofing tools actually worked out of the box. All of this
without sending anyone to retrain users on managing language
options from within Office itself. Once you get comfortable with
the syntax, it’s faster to adjust an XML file than to remote into
a laptop and fix mistakes post-install.Shared computer activation
is another spot where XML comes through. Think about education
labs or hospitals with rotating staff. One tweak and Office
switches modes, so each user activates only during their session
and isn’t fighting licensing errors a week later. The generic
deployment can’t do that—you end up stuck with tickets about
“unlicensed product” errors. Even with Microsoft’s regular
tweaks, this XML option makes all the difference for environments
that cycle through users quickly.Telemetry catches a lot of
admins off guard. Microsoft pushes telemetry for a reason—usage
stats and error trends help you track rollout health and
troubleshoot more effectively. The XML lets you point installs to
a specific telemetry share or server. If you want to use the
Office Telemetry Dashboard (still supported, though more features
are moving to the cloud), this is where you lay the groundwork.
Switching it on means you’re not just guessing how people use
Office or why certain add-ins keep failing. You can spot trends
before tickets come flooding in.Update channels can also be
handled directly in XML. Pilot teams that love new features can
be put on Current Channel for rapid feedback. Sensitive
departments—like accounting, or frontline legal—stick with
Monthly Enterprise or Semi-Annual channels. You can map all this
in a single configuration, so the right people get feature
previews while everyone else has proven, stable builds. It’s
practical in the real world, where one department can’t afford
surprise UI changes but another is happy to test out Copilot
integrations before anyone else.Picture those XML configs as a
family tree. At the top, there’s a base template—no bloat, just
the core apps. Branches handle language, app mix, or activation
mode by department or region. Over time, you add leaves for
special cases—a team in the UK with dual language needs, or an
R&D group always on the edge channel. The structure keeps
things tidy and scalable.If you’re worried about complexity, it’s
all about the rollout process. Start with a small pilot. Maybe a
handful of test users from each department. Run the config,
gather feedback, and look for misses—extra apps, missing add-ins,
or silent install failures. Tweak the XML, retest, and only then
push to the broad group. When you’re happy, automate the process
with your device management tool of choice—Intune, MECM, or even
a Swiss army knife script.You stop firefighting and start
actually shaping the M365 experience. Instead of answering the
same fix-my-install ticket over and over, IT gets to focus on the
projects that move your business forward. It’s a shift from chaos
to clarity, and the responses from users always confirm the
payoff. You’ve solved the biggest customization headaches, and
the last step is managing how and when new features reach your
users. Update channels actually become strategic—so how do you
pick the right pace for your rollout while keeping everyone
happy?


Update Channels: The Secret Lever for Stability and Innovation


If you’ve ever fielded complaints about a new Office ribbon
redesign dropping in overnight or users asking why a mail merge
feature has suddenly vanished, you already know update channels
aren’t just a checkbox you set and forget. The reality is, most
people outside IT barely notice these settings—until something
breaks or changes without warning. Pick the right channel, and
nothing feels remarkable. Miss the mark, and you’re that admin
everyone is calling after hours, wondering why Outlook suddenly
looks like it’s from a preview build or why Excel’s macros
stopped working before end-of-month reporting.Update channels
always sound pretty straightforward. Current Channel gets updates
fast, every few weeks. Semi-Annual rolls out changes twice a
year, giving more time for testing and stability. Monthly
Enterprise splits the difference, keeping things a bit fresher
but less risky than Current. But the real world is messy. The
wrong update channel leaves you stuck in two bad places: users
getting new features or interface redesigns before training is
ready, or teams stuck with bugs everyone else got patched weeks
ago. Everyone has that story—maybe a salesperson walks into a
client call and finds their PowerPoint layout shifted, or an old
bug lingers in Word while Microsoft’s changelog promises the fix
“coming soon.”Our team once mapped out update releases across
channels on a simple timeline. On the left, Current Channel
stacked feature rollouts like fast food—new icons, AI tools,
snappy additions every few weeks. Move right, and the Semi-Annual
line sat almost still, updates landing more like a slow freight
train. Monthly Enterprise looked more measured, with enough
testing time for departments that value consistency but don’t
want to fall behind on collaboration features. That visual hit
home when we watched a sales team lose hours rebuilding
presentations after an update shifted chart formatting. The next
week, finance realized their report macros failed after an Excel
patch deployed ahead of the quarter close, and we could point
directly to the update channel setting.So, whose advice do you
trust when balancing speed and stability? Microsoft MVPs will
tell you: Current Channel is best for pilot groups and IT teams
who can handle the learning curve and spot bugs early. The rest
of the business should hold steady on Semi-Annual, where big
changes arrive more gently. This way, your IT staff can try out
every new feature, hunt for issues before they become widespread,
and feed back observations to Microsoft—or at least prepare
documentation for everyone else. It’s a strategy that lowers the
blast radius of any new “upgrade” or surprise dependency
break.But you don’t have to juggle different installers or manual
steps for each group anymore. This is where XML, again, becomes
your lever. The same configuration file that lets you skip
Publisher for HR or pre-load French for Montreal can assign
update channels to specific sets of users. You can carve out
groups for pilots, keep your executive team on the most stable
build, and let research or test labs play with features early.
Each deployment gets its own feed, controlling risk and surprise.
If ops gets burned by a broken add-in, you can move them back to
a safer channel without having to rebuild their entire
environment.Making these changes is relatively straightforward,
but testing matters. We always recommend pushing new update
channel assignments first to a few trusted users in each
department. Watch behavior. See who runs into trouble and who
barely notices a difference. Collect early feedback, and tweak
your XML before going wide. Ramp up rollout only after the first
batch goes smoothly—for most organizations, this avoids the “all
hands on deck” scramble when a feature breaks something in the
wild.One underused trick: the Office Deployment Tool reports.
Hidden inside an otherwise unremarkable app, these reporting
features show you exactly what will happen with your deployment
before anyone clicks install. They’ll point out app mismatches,
missing components, or policy conflicts before they hit a user’s
desktop. It’s not flashy, but those previews have saved my team
from mistakes we didn’t spot even after several manual passes
through the config.The payoff is significant. Get update channels
right, and you balance the tension between innovation and
stability instead of swinging wildly between them. Features
appear when you want them, bugs disappear before users notice,
and the IT hotline doesn’t become a complaint desk every time
Office updates. Perhaps best of all, the pressure lifts from
admins to “just make it work”—because you actually have
fine-tuned control over what’s changing, and when.By steadily
refining your rollout strategy—including how and when update
channels get assigned—you materialize real benefits for users.
People stop seeing their workflow disrupted by surprise changes.
Teams grow to trust the updates they receive instead of bracing
for chaos on patch day. Office Apps rollouts move from
firefighting mode to just another smooth, expectable IT
operation.Of course, nailing update channels is just part of the
overall approach to smarter M365 deployments. But it’s often the
most visible step to your end users, since it shapes the pace and
stability of their day-to-day tools. When you line this up
alongside XML customizations, you’re in control—and users
actually notice the difference. For anyone still trying to
wrangle generic, off-the-shelf deployments, here’s what actually
makes the difference for your real-world rollout.


Conclusion


Most admins see M365 Apps deployment as a set-and-forget
process—until the helpdesk starts pinging with user complaints.
The real advantage comes from taking that first step past the
defaults, even if it’s just cutting out one app or finally
setting the right update channel. Each XML tweak brings your
rollout closer to what your users actually need. Over time, those
changes add up, and you notice fewer issues making their way to
your inbox. If you haven’t experimented yet, try a small change
in your next deployment. Your future self—and everyone using
Office—will see the difference in daily work.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe