Why I Avoid Changing the Default Printer in Excel VBA (And What I Use Instead)

Contents

Why I Avoid Changing the Default Printer in Excel VBA (And What I Use Instead)

In one of my earlier automation projects, Excel was responsible for generating and printing hundreds of invoices every month. Different branches required different printers, paper sizes, and orientations. At first glance, it felt natural to simply “set the printer in VBA” before printing and move on.

The common assumption was straightforward: “Just change the active printer, print, then change it back.”

That assumption worked—until it didn’t. And when it failed, it failed in ways that were subtle, disruptive, and surprisingly hard to diagnose.

Section 1: The Common Advice

Most Excel VBA resources suggest a similar approach when dealing with printers:

Use Application.ActivePrinter to specify the target printer.
Change printer settings (orientation, paper size) via PageSetup.
Print using PrintOut, then restore the original printer.

A typical example looks like this:

Dim originalPrinter As String
originalPrinter = Application.ActivePrinter
Application.ActivePrinter = "HP LaserJet on Ne01:"
ActiveSheet.PrintOut
Application.ActivePrinter = originalPrinter

On paper, this seems reasonable. Excel exposes ActivePrinter, printing works, and the macro finishes without errors. For small, controlled environments, this advice appears sufficient.

Section 2: What Actually Went Wrong

The first real problem showed up after deployment to multiple user PCs.

Printer names were different across machines.
Some users had the same printer installed via different ports.
Network printers occasionally went offline.

The macro didn’t always crash. Instead, printing would silently go to the wrong printer or fail without raising a clear error. Worse, in some cases Excel would keep the wrong printer selected after the macro finished, affecting unrelated user work.

Debugging this was painful:

Application.ActivePrinter requires an exact string match, including port names.
The port portion (on Ne01:) differed per machine and even changed over time.
When the assignment failed, Excel didn’t always raise a meaningful runtime error.

What started as “just set the printer” turned into a fragile dependency on each user’s local environment.

Section 3: The Turning Point

The breaking point came from a user complaint, not a crash:

“After running the macro, all my other documents started printing to the wrong printer.”

At that moment, it became clear that changing the global printer state inside Excel was not an isolated action—it was a side effect with user-wide impact. The macro wasn’t just printing; it was mutating the user’s environment.

From a maintenance and trust perspective, that was unacceptable. Even if the macro usually restored the printer, “usually” wasn’t good enough.

Section 4: The Alternative Approach

What I rely on now is printer-aware design, not aggressive printer switching.

1. Prefer PageSetup over printer switching

Many print requirements don’t actually require changing the printer:

With ActiveSheet.PageSetup
.Orientation = xlLandscape
.PaperSize = xlPaperA4
.Zoom = False
.FitToPagesWide = 1
End With

This keeps printing behavior predictable while avoiding global side effects.

2. Validate the printer before touching it

If switching printers is unavoidable, I first verify that the target printer exists on that machine and fail fast if it doesn’t. I treat printer selection as a configuration problem, not a runtime convenience.

3. Isolate printer logic

Printer selection is handled in one small, well-defined procedure, never scattered across business logic. If printing fails, the macro stops and reports the reason—no partial success.

Why this works better in real projects

Reduced side effects: Users don’t inherit unexpected printer settings.
Clear failure modes: Missing or misconfigured printers are detected early.
Easier support: Printer-related issues are isolated instead of mixed with data logic.

Trade-offs and downsides

Less flexibility: You can’t dynamically route prints everywhere without preparation.
More upfront coordination: Printer names and environments must be documented.
Not suitable for “print to any available printer” scenarios.

This approach prioritizes stability and predictability over cleverness.

Section 5: When I Still Use the Old Way

I still change Application.ActivePrinter in limited, controlled situations:

Dedicated kiosk PCs with fixed printer configurations
Batch printing systems where Excel is the only application in use
One-off internal tools used by a single trained operator

In these cases, the environment is stable enough that global changes are acceptable—and expected.

If you still rely on this approach, one way to reduce risk is to let users confirm the output before anything is sent to the printer.
In those cases, showing a print preview can be a safer alternative—see
How to Display Print Preview in Excel VBA: Step-by-Step Guide with Practical Use Cases.

Conclusion

The key lesson is simple: printing in Excel VBA is not just about output—it’s about side effects.

If your macro runs on real users’ machines, changing the default printer can impact far more than your code intends. In business automation, reliability often means doing less, not more.

This advice is for:

Developers building shared Excel tools
Automation that runs on end-user PCs
Any scenario where trust in output matters

You can safely ignore it if:

Excel runs in a tightly controlled environment
The macro is short-lived and disposable
Printer configuration is guaranteed and centralized

In practice, the most reliable Excel VBA printing code is the one that respects the user’s environment—and interferes with it as little as possible.