Windows Server, RDSH but printer are screwing up

Funck, Henrik 0 Reputation points
2026-09-15T15:26:21.3633333+00:00

Hello,

I am looking for an official Microsoft statement, supported workaround, or confirmation of a possible regression affecting shared printers on Windows Server 2025 RDS.

This is now the second time in 2026 that a cumulative Windows Server 2025 update has broken printer connections in our RDS environment.

Environment

  • Windows Server 2025 RDS Session Hosts
  • Central Windows Print Server
  • FSLogix profiles
  • Shared printers connected from the RDS hosts
  • Lexmark and Konica Minolta printers
  • Both Type 3 and Type 4 Universal Print Drivers are in use

Drivers include:

  • Lexmark Universal v2 XL – Type 3
  • KONICA MINOLTA Universal PCL – Type 3
  • Lexmark Universal v4 XL – Type 4
  • KONICA MINOLTA Universal V4 PCL – Type 4

The print server, printer shares and driver configuration were not changed between the working and failing Windows builds.

First occurrence – February 2026

After installing KB5075899 / Windows Server 2025 build 26100.32370, Type 4 printer connections on our RDS servers stopped working correctly.

Existing Type 4 connections disappeared and reconnecting them failed with Windows reporting that no appropriate Type 4 driver could be installed/found.

Uninstalling KB5075899 restored printing.

At the time I documented the issue here:

Reddit: “PSA: Windows Server 2025, RDS and Printer - TYPE 4 might break through latest security update”

Current occurrence – September 2026

We later built a completely new RDS/FSLogix farm.

On:

Windows Server 2025 build 26100.33296

printer connections worked correctly.

After updating the same servers to:

KB5122871 / build 26100.33438

printer connections immediately became problematic again.

Current behavior:

Type 3

  • First manual connection attempt as Administrator fails with: 0x00000057
  • A second connection attempt immediately afterwards usually succeeds.

Type 4

  • Connection consistently fails.
  • Windows reports that the required driver cannot be found / driver files are missing or invalid.
  • The visible printer connection error is: 0x00004005
  • This affects both Lexmark and Konica Minolta Type 4 drivers.

Rolling the affected RDS systems back from 26100.33438 to 26100.33296 restores the previous working behavior.

Type 4 / Enhanced Point and Print diagnostics

The Type 4 connection uses Microsoft's expected Enhanced Point and Print mechanism. Microsoft documents that a client connecting to a shared Type 4 printer can use Enhanced Point and Print without downloading the manufacturer's complete driver package from the print server.

On a working Server 2025 system running 26100.33296, SetupAPI shows Microsoft's:


and:


followed successfully by:


The printer connection completes successfully.

On an affected Server 2025 system running 26100.33438, the same Enhanced Point and Print path selects:


but then fails locally in the Microsoft print class installer:


0x00000490 corresponds to ERROR_NOT_FOUND.

The GUI eventually reports:


Things already excluded/tested

We have tested the following without resolving the Type 4 problem:

  • Windows Defender Firewall completely disabled for testing
  • Windows Protected Print Mode explicitly disabled
  • Printer spool directory permissions checked
  • Print server configuration unchanged
  • Same printer shares and same vendor drivers
  • Both Lexmark and Konica Minolta affected
  • Local staging of the matching Konica Type 4 package
  • Matching Type 4 PrinterDriverID confirmed between the package and print server

This therefore does not currently look like a vendor-specific Lexmark or Konica issue.

The most significant difference in our reproducible test is:


versus:


KB5122871 is the cumulative update that brings Windows Server 2025 to build 26100.33438. The currently published Known Issues for KB5122871 do not mention this printing behavior.

What I am asking Microsoft

Could Microsoft please clarify:

  1. Is this a known regression in KB5122871 / build 26100.33438 affecting Enhanced Point and Print or Type 4 shared printers?
  2. Were prnms004.inf, ntprint.dll, or the Type 4 / Enhanced Point and Print installation path intentionally changed or hardened in this update?
  3. Is there a supported workaround that does not require disabling Point and Print security protections?
  4. Is there a newer servicing update or hotfix planned for this behavior?
  5. Considering that this is now the second cumulative-update-related Type 4 printing failure we have encountered on Windows Server 2025 in 2026, what is Microsoft's currently supported strategy for shared enterprise printing from RDS Session Hosts?

I am specifically looking for a Microsoft-supported solution or statement, rather than suggestions to disable security controls globally.

For our ERP environment, shared printer queues are still required because multiple logical printer shares are used for different physical paper trays. Replacing the entire workflow with a single generic IPP queue is therefore not currently an equivalent solution.

Any confirmation from Microsoft engineering or other administrators who can reproduce this on 26100.33438 would be appreciated.Hello,

I am looking for an official Microsoft statement, supported workaround, or confirmation of a possible regression affecting shared printers on Windows Server 2025 RDS.

This is now the second time in 2026 that a cumulative Windows Server 2025 update has broken printer connections in our RDS environment.

Environment

  • Windows Server 2025 RDS Session Hosts
  • Central Windows Print Server
  • FSLogix profiles
  • Shared printers connected from the RDS hosts
  • Lexmark and Konica Minolta printers
  • Both Type 3 and Type 4 Universal Print Drivers are in use

Drivers include:

  • Lexmark Universal v2 XL – Type 3
  • KONICA MINOLTA Universal PCL – Type 3
  • Lexmark Universal v4 XL – Type 4
  • KONICA MINOLTA Universal V4 PCL – Type 4

The print server, printer shares and driver configuration were not changed between the working and failing Windows builds.

First occurrence – February 2026

After installing KB5075899 / Windows Server 2025 build 26100.32370, Type 4 printer connections on our RDS servers stopped working correctly.

Existing Type 4 connections disappeared and reconnecting them failed with Windows reporting that no appropriate Type 4 driver could be installed/found.

Uninstalling KB5075899 restored printing.

At the time I documented the issue here:

Reddit:
“PSA: Windows Server 2025, RDS and Printer - TYPE 4 might break through latest security update”

Current occurrence – September 2026

We later built a completely new RDS/FSLogix farm.

On:

Windows Server 2025 build 26100.33296

printer connections worked correctly.

After updating the same servers to:

KB5122871 / build 26100.33438

printer connections immediately became problematic again.

Current behavior:

Type 3

  • First manual connection attempt as Administrator fails with:
    0x00000057
  • A second connection attempt immediately afterwards usually succeeds.

Type 4

  • Connection consistently fails.
  • Windows reports that the required driver cannot be found / driver files are missing or invalid.
  • The visible printer connection error is:
    0x00004005
  • This affects both Lexmark and Konica Minolta Type 4 drivers.

Rolling the affected RDS systems back from 26100.33438 to 26100.33296 restores the previous working behavior.

Type 4 / Enhanced Point and Print diagnostics

The Type 4 connection uses Microsoft's expected Enhanced Point and Print mechanism. Microsoft documents that a client connecting to a shared Type 4 printer can use Enhanced Point and Print without downloading the manufacturer's complete driver package from the print server.

On a working Server 2025 system running 26100.33296, SetupAPI shows Microsoft's:


and:


followed successfully by:


The printer connection completes successfully.

On an affected Server 2025 system running 26100.33438, the same Enhanced Point and Print path selects:


but then fails locally in the Microsoft print class installer:


0x00000490 corresponds to ERROR_NOT_FOUND.

The GUI eventually reports:


Things already excluded/tested

We have tested the following without resolving the Type 4 problem:

  • Windows Defender Firewall completely disabled for testing
  • Windows Protected Print Mode explicitly disabled
  • Printer spool directory permissions checked
  • Print server configuration unchanged
  • Same printer shares and same vendor drivers
  • Both Lexmark and Konica Minolta affected
  • Local staging of the matching Konica Type 4 package
  • Matching Type 4 PrinterDriverID confirmed between the package and print server

This therefore does not currently look like a vendor-specific Lexmark or Konica issue.

The most significant difference in our reproducible test is:


versus:


KB5122871 is the cumulative update that brings Windows Server 2025 to build 26100.33438. The currently published Known Issues for KB5122871 do not mention this printing behavior.

What I am asking Microsoft

Could Microsoft please clarify:

  1. Is this a known regression in KB5122871 / build 26100.33438 affecting Enhanced Point and Print or Type 4 shared printers?
  2. Were prnms004.inf, ntprint.dll, or the Type 4 / Enhanced Point and Print installation path intentionally changed or hardened in this update?
  3. Is there a supported workaround that does not require disabling Point and Print security protections?
  4. Is there a newer servicing update or hotfix planned for this behavior?
  5. Considering that this is now the second cumulative-update-related Type 4 printing failure we have encountered on Windows Server 2025 in 2026, what is Microsoft's currently supported strategy for shared enterprise printing from RDS Session Hosts?

I am specifically looking for a Microsoft-supported solution or statement, rather than suggestions to disable security controls globally.

For our ERP environment, shared printer queues are still required because multiple logical printer shares are used for different physical paper trays. Replacing the entire workflow with a single generic IPP queue is therefore not currently an equivalent solution.

Any confirmation from Microsoft engineering or other administrators who can reproduce this on 26100.33438 would be appreciated.

... Help :(

Windows for business | Windows Server | User experience | Print jobs
0 comments No comments

1 answer

Sort by: Oldest
  1. Daphne Huynh (WICLOUD CORPORATION) 1,385 Reputation points Microsoft External Staff Moderator
    2026-09-16T05:27:49.11+00:00

    Welcome to Microsoft Q&A!

    Thank you for taking the time to provide such a thorough analysis of the issue. The level of detail you've included, especially the build comparisons, SetupAPI findings, rollback testing, and cross-vendor validation, is extremely helpful.

    Based on the currently published Microsoft documentation, there is no public confirmation of a known regression affecting Type 4 shared printers or Enhanced Point and Print in KB5122871 (OS Build 26100.33438).

    Microsoft has acknowledged a separate Remote Desktop Services reliability issue introduced by KB5122871 and indicates that it was addressed by KB5129235. However, the published information for those updates does not currently reference:

    • Type 4 shared printer connection failures
    • Enhanced Point and Print behavior
    • prnms004.inf or ntprint.dll changes
    • Error 0x00004005
    • Error 0x00000490
    • The Type 3 connection issue returning 0x00000057

    For that reason, it would be reasonable to test KB5129235 on an isolated, non-production RDS Session Host. However, at this time it should not be considered a confirmed fix for the printing behavior you have described.

    The evidence you've gathered suggests that this may be a reproducible build-dependent issue. The fact below that does make the scenario worthy of further investigation:

    • The same printer infrastructure works on build 26100.33296
    • The issue appears immediately after installing KB5122871
    • Rolling back restores functionality
    • The behavior affects multiple vendors and both Lexmark and Konica Minolta Type 4 drivers

    That said, because you are specifically requesting:

    • Official confirmation of a regression
    • Clarification on whether components such as prnms004.inf, ntprint.dll, or the Enhanced Point and Print installation path were intentionally changed
    • A Microsoft-supported workaround
    • Information regarding a potential hotfix or servicing update
    • Review and validation by Microsoft engineering

    The next recommended step that I highly suggest would be to open a support case with Microsoft.

    While Microsoft Q&A is a valuable technical community, forum contributors do not have visibility into internal engineering investigations and cannot officially confirm product regressions, future fixes, or undocumented design changes. A support case enables Microsoft Support to collect diagnostic data, reproduce the issue, and, if necessary, engage the Windows printing or servicing teams for deeper analysis. If you open a case, it may be helpful to include:

    • Working build: 26100.33296
    • Affected build: 26100.33438 (KB5122871)
    • Confirmation that rollback restores functionality
    • Type 3 error 0x00000057
    • Type 4 error 0x00004005
    • SetupAPI class-installer failure 0x00000490
    • SetupAPI.dev.log from both working and affected systems
    • Microsoft-Windows-PrintService Admin and Operational logs
    • A minimal reproduction using a single Type 4 shared printer
    • Driver package versions and matching PrinterDriverID information
    • Version comparisons for prnms004.inf, ntprint.dll, and related print components
    • Confirmation that the issue reproduces across multiple printer vendors

    A case title such as the following would clearly summarize the scenario:

    Possible regression in KB5122871: Type 4 Enhanced Point and Print connections fail on Windows Server 2025 RDS

    At this point, the available evidence supports treating this as a potential regression associated with build 26100.33438. However, only Microsoft Support and the product engineering team can determine whether the behavior is the result of an unintended regression, a security-related change, or another underlying issue.

    Finally, while Microsoft continues to invest in the modern IPP-based printing platform, that guidance does not necessarily address environments such as yours where multiple shared queues and tray-specific ERP workflows remain operational requirements. In those scenarios, traditional shared printer queues continue to be a valid enterprise use case and therefore warrant investigation through Microsoft Support when update-related changes affect functionality.

    I hope this information helps point you in the right direction.

    References: Windows Server 2025 known issues and notifications | Microsoft Learn

    Resolved issues in Windows Server 2025 | Microsoft Learn

    September 8, 2026—KB5122871 (OS Build 26100.33438) | Microsoft Support

    Work with Enhanced Point and Print - Windows drivers | Microsoft Learn

    8. September 2026 – KB5122871 (Betriebssystembuild 26100.33438) | Microsoft Support

    If you find this information helpful, please click Accept Answer

    Thank you for using Microsoft Q&A.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.