Files
ImpTune/.planning/research/FEATURES.md
T
2026-04-15 17:57:12 +02:00

16 KiB

Feature Research

Domain: Printer deployment package generator for IT admins / MSPs (Intune + NinjaRMM) Researched: 2026-04-10 Confidence: HIGH (core features verified against multiple official and community sources)


Feature Landscape

Table Stakes (Users Expect These)

Features IT admins and MSPs assume exist in any printer deployment tool. Missing these = product feels incomplete or unusable for the target workflow.

Feature Why Expected Complexity Notes
Printer name configuration Every deployment script requires a display name LOW Maps directly to Add-Printer -Name parameter; must match detection registry key exactly
IP address / hostname input TCP/IP port creation requires the printer's network address LOW Used for Add-PrinterPort -PrinterHostAddress; accepts both IP and DNS name
Driver file upload (ZIP/INF) Drivers must be bundled in the package — no external downloads at deploy time MEDIUM Entire extracted driver folder needed (INF + CAT + dependent files, up to 4 folders deep); partial upload breaks deployment silently
Driver name selection from INF Must exactly match the driver string in the INF file MEDIUM Wrong driver name = silent install failure; tool should parse INF to offer a dropdown instead of free text
PowerShell install script generation Core deliverable for both Intune and NinjaRMM MEDIUM Must call pnputil /add-driver, Add-PrinterPort, Add-PrinterDriver, Add-Printer in correct order
PowerShell uninstall script generation Intune Win32 apps require an uninstall command LOW Remove-Printer + Remove-PrinterDriver + Remove-PrinterPort
Intune detection rule / detection script Win32 apps require detection to know if install succeeded MEDIUM Registry check at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\[Name]; tool generates this script
.intunewin package export End deliverable for Intune Win32 app deployment HIGH AES-256 + HMAC-SHA256 encrypted ZIP-in-ZIP format; can be implemented without IntuneWinAppUtil.exe using the documented format (C# library: volodymyrsmirnov/IntuneWin or svrooij ContentPrep)
NinjaRMM ZIP package export End deliverable for RMM script-based deployment LOW ZIP containing PS install script + driver folder; no encryption required
Duplex mode setting IT admins universally configure this at deployment time LOW `Set-PrintConfiguration -DuplexingMode [OneSided
Color vs. grayscale default Standard printer policy setting LOW Set-PrintConfiguration -Color $true/$false
Paper size default Required for most environments (A4 vs Letter conflict is a common complaint) LOW `Set-PrintConfiguration -PaperSize [A4
Printer persistence across sessions MSPs configure many printers; losing config between sessions is unacceptable MEDIUM SQLite or flat-file storage on Docker volume; drivers stored in volume, config in DB
Client/tenant organization MSPs manage dozens of clients; printers must be grouped MEDIUM Simple client label/folder — no RBAC needed since no auth; flat list with client filter

Differentiators (Competitive Advantage)

Features that justify building ImpTune instead of manually scripting. Not expected from raw scripts, but high value for the target user.

Feature Value Proposition Complexity Notes
INF file parsing for driver name auto-detection Eliminates the #1 source of silent install failures (wrong driver name string) MEDIUM Parse INF [Strings] and [Manufacturer] sections to extract valid driver names; present as dropdown
SYSTEM vs. user context self-elevation in generated script Intune runs as SYSTEM, user-invoked scripts need elevation — single script handles both MEDIUM Detect [System.Security.Principal.WindowsIdentity]::GetCurrent() + UAC re-launch; this is the most-cited pain point in community guides
Custom app icon embedding for Intune Company Portal shows the icon; admins want printer-specific icons, not generic app icon LOW Accept PNG upload (256x256, max 750KB per Intune spec); embed in package metadata
Driver file size optimization hint Manufacturer ZIPs are often 500MB+; only a fraction is needed MEDIUM After INF parse, flag which files are referenced vs. unused; suggest cleanup to reduce .intunewin size
One-click package re-generation When IP or settings change, regenerate without re-uploading drivers LOW Decouple printer config (IP, name, settings) from driver storage; re-run generation against stored drivers
Collate default setting Less common but occasionally required for multifunction devices LOW Set-PrintConfiguration -Collate $true/$false
Package naming convention enforcement Generated filenames should be consistent (client_printer_vN.intunewin) LOW Prevents file management confusion on the MSP side
Intune install/uninstall command preview Show the exact command strings before export, copyable LOW Saves the Intune portal upload step where commands must be typed manually

Anti-Features (Commonly Requested, Often Problematic)

Feature Why Requested Why Problematic Alternative
Direct Intune API push (auto-upload to tenant) Saves the manual upload step Requires per-tenant OAuth tokens, multi-tenant app registration, and ongoing credential management — turns a stateless tool into an identity-aware service; scope and security surface explode Export package + show exact Intune portal steps; keep the tool stateless
Real-time printer status / monitoring "See if the printer is online" seems useful Requires network access to each client site, SNMP polling, ongoing agent or VPN — far outside the deployment packaging scope Out of scope; use RMM or dedicated monitoring tools
User authentication / per-technician logins Seems professional Adds session management, password reset flow, and auth complexity; the tool runs on a private network where single-user access is the reality Document that the tool is internal-only, recommend network-level access control (VPN, firewall)
Print server migration / export (Printbrm) Some clients have print servers to migrate Printbrm.exe output format is entirely different from the per-printer Win32 package workflow; supporting both creates a confusing dual-path UI Separate future feature if validated; not v1
Universal Print integration Microsoft's cloud print service is growing Requires Azure subscription, different deployment model (no drivers, CSP), different target persona — not the MSP TCP/IP printer workflow Document as out-of-scope; Universal Print has its own provisioning tool
Mobile / tablet UI Nice to have Target users are at a workstation doing IT work; responsive design adds cost for zero validated demand Desktop browser only; CSS can be clean without being mobile-optimized
Multi-language / localization International MSPs might want this Zero demand signal yet; adds ongoing maintenance overhead for every string in the UI English only for v1
Full audit log / deployment history Compliance-minded requests State management complexity; printers are reconfigured infrequently; MSPs already have Intune/RMM logs Out of scope for v1 per PROJECT.md

Feature Dependencies

[Driver File Upload]
    └──requires──> [INF Parsing]
                       └──enables──> [Driver Name Dropdown]
                       └──enables──> [Driver File Optimization Hint]

[Printer Config Form]
    ├──requires──> [Driver Name Dropdown]  (needs driver to be uploaded first)
    ├──requires──> [IP / Hostname Input]
    └──requires──> [Print Settings] (duplex, color, paper size)

[PowerShell Script Generation]
    └──requires──> [Printer Config Form]  (all fields must be valid)
    └──requires──> [Driver File Upload]   (driver files embedded in package)

[Intune Package Export (.intunewin)]
    └──requires──> [PowerShell Script Generation]
    └──requires──> [Detection Script Generation]
    └──optionally-uses──> [Custom Icon Upload]

[NinjaRMM Package Export (ZIP)]
    └──requires──> [PowerShell Script Generation]
    └──independent-of──> [Detection Script Generation]  (NinjaRMM doesn't need Intune detection logic)

[Client/Tenant Organization]
    └──enhances──> [Printer Persistence]  (printers stored per client label)
    └──independent-of──> [Package Export]

[One-Click Regeneration]
    └──requires──> [Printer Persistence]
    └──requires──> [PowerShell Script Generation]

Dependency Notes

  • Driver Name Dropdown requires INF Parsing: Free-text driver name is the most common cause of silent deployment failure; parsing the INF to offer valid options is a prerequisite to a reliable tool, not a nice-to-have.
  • Detection Script requires exact Printer Name match: The registry key checked at HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers\[Name] must exactly match the -Name parameter in Add-Printer. The tool must use the same value in both generated scripts.
  • .intunewin export requires both install and detection scripts: Intune Win32 apps require install command, uninstall command, and detection method — all three must be generated together.
  • NinjaRMM export is independent of detection logic: NinjaRMM script execution does not use Intune detection rules; the ZIP just needs the install script and driver folder.

MVP Definition

Launch With (v1)

Minimum to validate the core value proposition: "generate a working deployment package in minutes."

  • Driver file upload (ZIP containing INF + supporting files)
  • INF parsing with driver name dropdown selection
  • Printer config form: name, IP/hostname, port name (auto-suggested from IP)
  • Print settings: duplex mode, color/mono, paper size (A4/Letter/Legal at minimum)
  • PowerShell install script generation (pnputil staging + Add-PrinterPort + Add-PrinterDriver + Add-Printer + Set-PrintConfiguration)
  • PowerShell uninstall script generation (Remove-Printer + Remove-PrinterDriver + Remove-PrinterPort)
  • Detection script generation (registry-based, printer name match)
  • Self-elevation logic in install script (SYSTEM detection + UAC re-launch for user context)
  • .intunewin package export (AES-256 encrypted ZIP-in-ZIP, no IntuneWinAppUtil.exe dependency)
  • NinjaRMM ZIP export (script + driver folder)
  • Client/tenant label for printer organization
  • Printer config persistence (SQLite on Docker volume)
  • Single Docker container runtime

Add After Validation (v1.x)

Add once the packaging workflow is validated by real MSP use:

  • Custom icon upload for Intune package (256x256 PNG, 750KB max) — trigger: MSPs ask for it after using v1
  • Driver file size optimization hints (unused file flagging) — trigger: users complain about large package sizes
  • One-click package regeneration from saved config — trigger: users report re-uploading drivers repeatedly
  • Intune command string preview panel — trigger: friction reported during Intune portal upload step
  • Collate setting — trigger: user request

Future Consideration (v2+)

Defer until product-market fit and real usage patterns emerge:

  • Bulk printer import (CSV) — defer: unknown if MSPs manage dozens at once or one at a time
  • Package version history per printer — defer: adds state complexity, low signal demand
  • Print server migration path (Printbrm) — defer: different workflow, validate separately
  • API / CLI mode for CI/CD integration — defer: advanced use case, no demand signal yet

Feature Prioritization Matrix

Feature User Value Implementation Cost Priority
INF parsing + driver name dropdown HIGH MEDIUM P1
PowerShell script generation (install/uninstall/detection) HIGH MEDIUM P1
Self-elevation logic in generated script HIGH LOW P1
.intunewin package export HIGH HIGH P1
NinjaRMM ZIP export HIGH LOW P1
Driver file upload + storage HIGH MEDIUM P1
Printer config form (name, IP, settings) HIGH LOW P1
Client/tenant organization MEDIUM LOW P1
Printer persistence (SQLite) MEDIUM LOW P1
Custom icon upload MEDIUM LOW P2
Driver size optimization hints MEDIUM MEDIUM P2
One-click regeneration MEDIUM LOW P2
Intune command preview panel LOW LOW P2
Collate setting LOW LOW P3
Bulk CSV import LOW MEDIUM P3

Competitor Feature Analysis

Feature Manual scripting (status quo) PrinterLogic / Vasion ImpTune approach
Driver packaging Manual — IT admin extracts files, writes pnputil commands Serverless SaaS, no local driver packaging needed Automated — upload ZIP, parse INF, bundle
Script generation Manual — written per printer, error-prone Not applicable (agent-based) Generated from form inputs
Intune integration Manual .intunewin wrapping + portal upload Native Intune app provisioning Export .intunewin; admin uploads to portal
NinjaRMM integration Manual — custom script per RMM job Not targeted Export ZIP; admin pastes into NinjaRMM script
Multi-client support Ad-hoc folder structure Tenant-level in SaaS portal Client label per printer, no auth overhead
Self-hosted / air-gapped Possible but no tooling support Cloud SaaS only Single Docker container, fully self-hosted
Cost Free (time is the cost) Per-printer SaaS licensing (~$1-3/printer/month) Self-hosted, no per-seat cost
Detection rules Written manually, often wrong N/A Auto-generated, guaranteed consistent with install script

Sources


Feature research for: Printer deployment package generator (Intune + NinjaRMM) Researched: 2026-04-10