Printing

Printing is where zero-touch provisioning traditionally goes to die. This section covers the three deployment paths real fleets actually use — Universal Print, scripted direct-IP, and third-party print management — as planned, reversible catalogue items.

Why this matters

A device can enrol cleanly, pass every compliance check and land on the user's desk in perfect shape — and the first ticket is still "I can't print". Printing sits awkwardly across every boundary modern management draws: drivers are system-level, defaults are per-user, queues are per-site, and since the post-PrintNightmare hardening of Point and Print, standard users can no longer install printer drivers themselves. If your provisioning build doesn't deliver printers, your helpdesk delivers them — by hand, one desk at a time, indefinitely.

It is also one of the most fragmented areas in the stack: some organisations have adopted Universal Print, some still script direct-IP queues against staged driver packages, and some have bought their way out with a print-management platform. In the community discussions that shaped this catalogue, printing is one of the few topics with dedicated pain threads of its own.

What a good build does

Decolla treats all three real-world paths as first-class rather than pretending one is canonical:

• Universal Print — connections provisioned per device, with a per-department deployment parameter, so a warehouse plotter is scoped to the warehouse rather than the whole tenant.
• Scripted direct-IP install — stages the driver, creates the port and queue, and sets the user's default; the path for estates without Universal Print licensing or a connector they trust.
• Existing print management — where the customer already runs Printix, PaperCut or PrinterLogic, the build deploys that platform's client into the tenant rather than substituting anything of Decolla's own.

Every item appears in the written plan before anything runs, with its delivery method and reversibility class stated. Printing items are reversible: Decolla can remove the queues, ports, drivers and connections it created — per item, not as an all-or-nothing wipe. The honest scope: this is deployment into your own Intune/Autopilot tenant. Decolla does not operate your printers, your connector host or your print server.

Where it bites people

Two failure modes come up repeatedly. First, the default printer. It is a per-user setting, and Windows' own "let Windows manage my default printer" behaviour will quietly override whatever you configure. A printer script that runs in device context as SYSTEM sets a default for an account no human ever logs in as — everything reports success, and the user still prints to the wrong device. This is exactly why add printer and set default exists in the catalogue as a distinct item rather than a one-line Add-Printer.

Second, ordering. Applying Point and Print hardening without a managed printer-deployment path in the same build means the baseline lands, users lose the ability to add drivers themselves, and printing tickets arrive in bulk. Because Decolla's plan is itemised and approved up front, the hardening and the printer path are visible side by side before either runs.

What's in this section (4 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.