We Wrote Eleven Findings Against Code We Never Opened

We tried three times to fetch the script. A raw file URL returned 404. A directory listing returned 404. The GitHub API returned a refusal. The decision taken at that point was the right one, and it is written down: critique only the method as the article describes it, and do not make claims about code we have not read.

Then we wrote eleven findings about the code.

Three of them were false. This is the first entry in a series about how MDEG's IT department works, and it opens on a correction rather than a result, because the correction is the more useful artifact.

What we said

The job was ordinary. Deploy a network printer to managed Windows endpoints through Intune, no print server, driver staged to the device. We started where most people start, with a well written and widely circulated guide by Jatin Makhija at cloudinfra.net.¹ We concluded that the accompanying script had structural problems, wrote them into an internal standard operating procedure, and moved on to building a replacement.

Three of the findings, quoted from that document:

• Exit codes are never set. powershell.exe -File returns zero for non terminating errors, so a script that fails halfway through still tells Intune it succeeded.
• The install command runs 32 bit, so pnputil.exe is not where the script looks for it and the print cmdlets operate against a redirected view.
• The script is not idempotent, so any retry or repair install fails on a device where the printer is partially present.

What the script actually does

Read directly from the repository at master.

It sets exit codes. The body is wrapped in a single try/catch that ends in an explicit success, with an explicit failure on any caught exception, and every mutating cmdlet carries -ErrorAction Stop:

try {
  # main body
  exit 0
}
catch {
  Add-LogEntry ("ERROR: {0}" -f $_.Exception.Message) 'ERROR'
  exit 1
}

It finds pnputil. It probes both locations and takes the first that exists, which on a 32 bit host is the second:

$pnputilPathCandidates = @(
  (Join-Path $env:windir 'System32\pnputil.exe'),
  (Join-Path $env:windir 'sysnative\pnputil.exe')
)
$pnputil = $pnputilPathCandidates | Where-Object { Test-Path $_ } | Select-Object -First 1

It is idempotent. Get-PrinterPort, Get-PrinterDriver and Get-Printer are each checked before the corresponding Add runs. An existing port is reused, an existing driver is not re-registered, an existing queue is skipped.

One part of the second finding survives and is worth separating out, because it is the part that is genuinely true. The install command does launch a 32 bit PowerShell instance. Microsoft states it in the Win32 app documentation and gives the fix, which is to call the 64 bit host through the Sysnative alias.² What does not follow is the consequence we attached to it. The print cmdlets reach the spooler through RPC rather than through a redirected filesystem view. The detection key the article recommends does sit under a hive that is redirected in general, but Microsoft lists that particular Print key as shared, so it reads the same from either host.⁷ The redirection problem is real. It applies to a script's own marker key written elsewhere, not to the printer.

Why one set of findings held and the other did not

We also audited a hardened build of the same scripts, supplied to us as a replacement. That audit produced eleven findings and they survived review intact, including two that would have put an Intune app into a permanent reinstall loop: a script that detected it was running 32 bit, logged a warning about it, and continued anyway; and a print configuration step that threw before the install marker was written, so a printer that installed correctly reported as failed forever.

Those findings held. The findings against the original did not. The difference is not attention or skill. We had the second file and we did not have the first.

That is an uncomfortable thing to write down, because it is not a subtle failure. It is the oldest one there is. We knew we had not read the source, we said so to ourselves, and the claims went out anyway with nothing marking them as inference.

What the original does well

This should have been in the first document and was not.

A single enclosing try/catch with honest exit codes. Existence checks before every mutating call. A pnputil probe that handles the 32 bit host correctly. A three tier fallback for port creation, through WMI and then through prnport.vbs, for the cases where the modern cmdlet fails. Structured logging throughout.

Several of those are things we praised in the hardened build without noticing they had been inherited rather than invented. The build we called a serious piece of work was standing on a foundation we had just finished describing as broken.

The rule that came out of it

One line, now in the repository's instructions for anyone working in it:

A finding names the ref it was checked against. Not "this does not exist" but "this does not exist at this commit on this branch." Claims about the trunk are checked against a fetched origin, not a working tree that may be weeks behind. Anything carried over from a description, a memory, or a previous revision is marked unverified until someone checks it, rather than restated as fact.

It is a small rule and it would have caught all three.

The part nobody was arguing about

While we were arguing about exit codes, Microsoft was removing the ground the argument stands on.

There is a published end of servicing schedule for third party printer drivers, and two of its dates have passed.³ Since 15 January 2026, no new third party printer drivers are published to Windows Update for Windows 11 or Windows Server 2025. Since 1 July 2026, the driver ranking order prefers the Windows IPP inbox class driver over a vendor driver. On 1 July 2027, third party printer driver updates stop except for security fixes.

Windows protected print mode is the enforcement mechanism.⁴ Where it is enabled, it uninstalls third party printer drivers from the driver store, blocks installation of new ones, removes XPS and fax, and routes printing through the inbox class driver. It is configured through a single policy.⁵

So the correct answer to "how do I deploy this printer driver" is increasingly "do not." The driverless path needs no package:

Add-Printer -IppURL "http://10.0.0.3:631/ipp/print"

Windows selects the class driver itself. Under protected print, the traditional call with -DriverName and -PortName does not work and this form does, which is established in a community answer on Microsoft Q&A rather than in product documentation.⁶ We are treating that as verified by pilot rather than settled, and saying so, which is the distinction this entire entry is about.

What this was really about

MD Electric Group has been doing Department of Defense electrical work for 26 years. Somewhere in there the job acquired a second half, which is proving that the environment holding the drawings, the submittals and the correspondence is run by people who are paying attention.

That half does not show up in a past performance sheet. It shows up in whether a finding published against someone else's work was actually checked, and in what happens when it turns out it was not.

The internal document has been reissued with the three findings withdrawn, three more marked unverified or not read, and the count of eleven retracted. The author of the original script has been written to.

Next in this series is the thing we built to read our own documents.

References

1. Jatin Makhija, "Install Printer Drivers And Printers With Intune," cloudinfra.net, 5 November 2025, updated 7 November 2025. https://cloudinfra.net/install-printer-drivers-and-printers-with-intune/
2. Microsoft, "Add and assign Win32 apps to Microsoft Intune," Microsoft Learn. https://learn.microsoft.com/en-us/intune/app-management/deployment/add-win32
3. Microsoft, "End of servicing plan for third-party printer drivers on Windows," Windows Drivers documentation. https://learn.microsoft.com/en-us/windows-hardware/drivers/print/end-of-servicing-plan-for-third-party-printer-drivers-on-windows
4. Microsoft, "Windows protected print mode," Modern Print documentation. https://learn.microsoft.com/en-us/windows/modern-print/windows-protected-print-mode/windows-protected-print-mode
5. Microsoft, "Policy CSP - Printers," Windows Client Management documentation. https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-printers
6. Community answer, "Add a local IPP printer queue programmatically or with Powershell when Windows protected print mode is enabled," Microsoft Q&A. https://learn.microsoft.com/en-us/answers/questions/2114382/add-a-local-ipp-printer-queue-programmatically-or
7. Microsoft, "Registry Keys Affected by WOW64," Windows Win32 documentation. https://learn.microsoft.com/en-us/windows/win32/winprog64/shared-registry-keys