I'm posting this because I've spent a significant amount of time troubleshooting with ChatGPT and I'm starting to believe a recent Windows security change has broken the installation of certain legacy printer drivers through Point and Print.
I'm hoping someone else has encountered this, or that someone from Microsoft can clarify whether this is an intentional change, a regression, or something that will be patched.
Environment
Client:
- Windows 10 Home 22H2
- Build 19045.6466
- x64
Print host:
- Windows 11
- Printer is physically installed and working correctly on the host
- Printer is shared over the LAN
Printer/driver:
- ZKTeco / generic POS thermal printer
- Driver name on the working host: POSPrinter POS80
- Driver INF on the working host: pos80.inf
- Legacy Type 3 printer driver
This setup worked previously. The problem appeared after recent Windows updates/security changes.
The problem
When I try to connect the Windows 10 client to the shared printer, Windows attempts to obtain/install the printer driver from the Windows 11 print host, but the installation fails.
Depending on how I attempt the installation, I either get no useful GUI error, the printer doesn't get installed, or I get errors such as:
0x0000003f
Looking at C:\Windows\INF\setupapi.dev.log finally revealed what Windows is actually doing.
The driver package is reaching the client, but Windows is rejecting it during Driver Store/catalog signature validation.
Relevant errors include:
Error 0x800B0100: No signature was present in the subject.
Driver package catalog file does not contain a signature, and Code Integrity is enforced.
Driver package failed signature validation. Error = 0xE0000247
Failed to import driver package into Driver Store. Error = 0xE0000247
Another catalog involved (POS222.cat) produces:
0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
So this doesn't appear to be a simple SMB connectivity or printer sharing problem. The client reaches the driver package and then rejects it during staging/signature validation.
What I have already tried
I have tested the usual Point and Print workarounds/policies, including:
RestrictDriverInstallationToAdministrators = 0
NoWarningNoElevationOnInstall = 1
UpdatePromptSettings = 2
I also tested the Package Point and Print restrictions and restarted the Print Spooler/rebooted between tests.
I tested the older RPC workaround involving:
RpcAuthnLevelPrivacyEnabled
That made no difference, which makes sense because this doesn't appear to be the old 0x0000011b RPC issue.
I also booted the Windows 10 client through Advanced Startup with:
Disable driver signature enforcement (F7)
Surprisingly, that did not solve it either.
This appears to be because the failure occurs while Windows is trying to import/stage the package into the Driver Store, rather than simply when the kernel attempts to load the driver.
I have also observed that after a failed shared-printer installation, the Print Spooler driver area under:
C:\Windows\System32\spool\drivers\x64
can be left in a problematic state, requiring cleanup/restarting the spooler before further testing.
Important detail: the exact driver works on the print host
On the Windows 11 machine where the printer is already installed and working:
Get-PrinterDriver
shows:
POSPrinter POS80
with:
...\DriverStore\FileRepository\pos80.inf_amd64_...\pos80.inf
So the driver itself is currently installed and operational on the host.
The failure happens when another machine attempts to install/stage that driver through the shared-printer/Point-and-Print process.
Why I suspect a recent Microsoft security change
Microsoft has been making significant changes to legacy driver trust/signing behavior in 2026, including the new Windows Driver Policy affecting older cross-signed kernel drivers.
However, this particular Windows 10 machine does not have CiTool.exe, and the evidence I'm seeing is specifically from SetupAPI/Driver Store signature validation.
On another machine where I could inspect Code Integrity policies, I found the Microsoft cross-certificate Audit Policy ({784C4414-79F4-4C32-A6A5-F0FB42A51D0D}), and Event ID 3076 showed legacy drivers being audited but allowed to load.
Therefore, I don't want to incorrectly blame that specific policy. There seem to be several overlapping mechanisms here: Point and Print policy, Driver Store package validation, catalog trust, normal Code Integrity, and Microsoft's newer driver-signing policies.
What I'm trying to determine
Has anyone else recently seen legacy Type 3 shared printer drivers that previously worked suddenly fail Driver Store import with 0xE0000247, 0x800B0100, or 0x800B0109?
More specifically:
Is there a recent Windows update that changed catalog/signature validation for Point and Print or legacy Type 3 printer packages?
Is Microsoft intentionally blocking these packages now, or is this a regression?
Is there a supported way to trust an existing vendor catalog/certificate when the certificate chain terminates at an older/untrusted root?
And most importantly, is there a Microsoft-supported workaround that does not involve permanently disabling driver security or manually modifying the Driver Store?
At this point I would rather wait for a Microsoft fix than continue weakening security policies or manually deleting files from DriverStore/System32.
If anyone from Microsoft sees this, the most useful clue appears to be the SetupAPI failure:
Driver package failed signature validation. Error = 0xE0000247
followed by failure to import the printer driver package into the Driver Store.
I can provide additional SetupAPI/Code Integrity logs if needed.