UNiversal printers are not showing in AVD but I see OAUTH token issues in the universal print application event logs

Question

We have issues with Universal Print printers not showing up in AVD. I see OATH errors in the application event log. I was able to get one host to work by going to accounts and issuing a SYNC to Intune. This only worked on one host. I have 4 more that it did not work on. At this point we are trying to redeploy new machines to the host pool to see if that fixes the issue. We have been running AVD for a couple years, Universal print for almost the same time frame and haven't seen this before.

Any ideas or suggestions???

Answer 1

Hi Ron Downey,

Your reluctance to make a global FSLogix change immediately is exactly the right instinct. You have hit on one of the most notorious architectural trade-offs in Azure Virtual Desktop (AVD) environments.

You are absolutely correct that many older Microsoft and community references suggest roaming the Microsoft.AAD.BrokerPlugin directory to preserve Office 365 Single Sign-On (SSO) tokens. The goal of roaming that folder is to prevent users from being prompted for credentials every time they land on a new session host.

However, here is the technical catch: The Primary Refresh Token (PRT) cached inside that broker plugin is cryptographically bound to the specific hardware ID of the VM where it was originally generated. When FSLogix roams that exact cache to a different session host in the pool, the hardware mismatch instantly invalidates the token payload. While robust applications like Outlook or Teams can sometimes gracefully recover by silently requesting a new token, background system services like Universal Print fail hard, resulting in the exact 0x8001012d OAuth deadlock you experienced.

For your upcoming testing phase, here is the modern best practice to evaluate:

Instead of using FSLogix to brute-force roam the broker plugin, ensure your AVD host pool is properly configured for Entra ID Seamless SSO (or that the hosts are Entra ID Joined with Azure AD PRT functioning at the machine level). When Seamless SSO is fully functional, you can safely exclude the Microsoft.AAD.BrokerPlugin directory in your redirections.xml. Windows will simply negotiate a fresh, healthy, hardware-accurate PRT during the user's initial logon process on whatever host they land on. This satisfies both Office 365 activation and Universal Print authentication without causing cross-host corruption.

I am glad we were able to pinpoint the root cause of the missing printers! If the targeted cache cleanup successfully unblocked your deployment and proved where the fault lies, please consider clicking "Accept Answer" on the previous response so other AVD administrators wrestling with Universal Print token issues can find this exact solution. Let me know how your SSO testing goes!

Answer 2

Hi Ron Downey,

The OAuth errors you are observing in the event logs, specifically the SetChannelOAuth failed. hr: 0x8001012d alongside the AadTokenBrokerPlugin warnings stating "The file exists," are classic indicators of a corrupted Primary Refresh Token (PRT) or a locked Web Account Manager (WAM) cache. Universal Print relies entirely on seamless Microsoft Entra ID (formerly Azure AD) user authentication to discover and map assigned print queues. In Azure Virtual Desktop (AVD) environments, especially multi-session hosts utilizing profile management solutions like FSLogix, the localized token broker cache can frequently become desynchronized, orphaned, or locked by stale session data. When the Universal Print client attempts to silently request an OAuth token in the background to enumerate the printers, it collides with this corrupted local cache, fails the authentication handshake, and aborts the mapping process. The fact that manually forcing an Intune sync resolved the issue on one host perfectly aligns with this diagnosis, as the sync forcefully refreshed the device's Entra ID token state and temporarily bypassed the cache lock.

Before you invest the significant time and effort required to completely tear down and redeploy your entire AVD host pool, I highly recommend performing a targeted cleanup of the authentication architecture on the remaining affected hosts. In practice, you can usually resolve these authentication deadlocks without a full rebuild.

First, log into one of the broken session hosts as an administrator, open a Command Prompt, and run the command dsregcmd /status. You must verify that the device is still properly reporting AzureAdJoined : YES and, more importantly, that the AzureAdPrt state is healthy. If the PRT is missing or broken at the system level, Universal Print will never function.

If the join state appears healthy but the OAuth errors persist, you need to forcefully clear the system's WAM cache. You can accomplish this by navigating to C:\Windows\System32\config\systemprofile\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy and clearing out the local state/cache folders, followed by a system reboot. This forces Windows to completely rebuild the token broker database upon the next user login, which directly resolves the "file exists" read/write lock errors you are seeing in the AAD operational logs. As a best practice for the future, if your host pool relies on FSLogix, you should review your redirections.xml configuration to ensure you are not improperly roaming the Microsoft.AAD.BrokerPlugin package data across different VMs, as dragging stale token data between hosts is the primary root cause of sudden Universal Print OAuth failures in mature AVD environments.

I hope this answer provided you with a clear understanding of the underlying token conflict and a much faster path to resolution than a full host redeployment. If it did, please click "Accept Answer". Should you have any questions or if clearing the cache doesn't bring the printers back on those last four hosts, feel free to leave a comment!

Tracy.

Answer 3

For AVD hosts where Universal Print printers don’t appear and OAuth‑related errors are logged, focus on the client/host connectivity to Microsoft Entra ID and Universal Print, and then on the printer‑installation path.

1. Verify the AVD session hosts are correctly joined and can get tokens
   • On each problematic host, run:

          dsregcmd /status /verbose /debug
     

   • Confirm the device is properly connected to Microsoft Entra ID as described in the Universal Print troubleshooting guide:
     • Device State – AzureAdJoined : YES and SSO State – AzureAdPrt : YES, or
     • User State – WorkplaceJoined : YES.
   • If these conditions aren’t met, fix the device registration/SSO issue first (for example, by re‑joining to Entra ID or re‑enrolling to Intune), then test Universal Print discovery again.
2. Check that the issue is not due to the VDI user‑experience limitations
   • In Windows 10/AVD multi‑session environments, Universal Print has known issues:
     • Printers don’t roam with users across VMs; a printer installed on one host (VM1) won’t automatically appear on another host (VM2).
     • Users may see printers installed by other users on the same VM.
   • If users are being load‑balanced to different session hosts, they must install or be provisioned printers on each host they use. Consider moving to Windows 11 multi‑session 22H2 or later, which provides an improved Universal Print experience for AVD.
3. Validate printer discovery and installation from the client side
   • On an affected host, sign in as an impacted user and try to manually discover/add a Universal Print printer using Add printer.
   • If discovery/installation fails, follow the “Discover and Install printer on Client” troubleshooting steps:
     • Ensure Windows location services are configured if location‑based discovery is used.
     • If printer options or capabilities appear incorrect, delete and reinstall the printer on the client and verify the connector’s printer driver/queue configuration.
4. If using Intune/Endpoint Manager to deploy printers
   • If printers are deployed via the (soon‑to‑be‑deprecated) Universal Print Intune provisioning tool, confirm that on each AVD host:
     • The printers.csv file exists in the correct path for device‑level deployment:
       • On x64: %ProgramFiles(x86)%\UniversalPrintPrinterProvisioning\Configuration
       • On x86: %ProgramFiles%\UniversalPrintPrinterProvisioning\Configuration
     • If a specific printer from printers.csv is missing, check the PrintProvisioning event log under Applications and Services log → Microsoft → UniversalPrint for Event 3:
       • If the description is “The system cannot find the path specified.” then either:
         • The user doesn’t have access to that printer (fix the access list in the Universal Print portal and ensure the user or its Entra security group is granted access), or
         • The printers.csv file uses a PrinterID instead of the ShareID (correct the ID and redeploy).
5. Confirm the connector and printers are healthy
   • On the Universal Print connector host:
     • Print a test page locally to confirm the printer is online.
     • If a printer was taken offline and brought back, but still shows as Stopped in the portal or Attention Required on clients, open the printer queue on the connector host, toggle Pause Printing on and off (elevating to Open as administrator if needed) so the connector updates the printer status.
   • If a printer was deleted from Microsoft Entra ID Devices and now shows as registered but unusable, unshare and unregister it in the Universal Print portal, then re‑register it from the connector app.
6. Use advanced logging if printers still don’t appear
   • On an affected AVD host, use the UPPrinterInstaller.exe logs and tools described in the troubleshooting guide:
     • Capture logs with Print-Collect.ps1 and, if needed, Fiddler tracing.
     • Use the printer Share ID, the user’s OMA DM Account ID, and the Correlation ID from UPPrinterInstaller.exe events in Event Viewer → Windows Logs → Application to trace installation failures.
   • These logs can then be provided to Microsoft support for deeper analysis of the OAuth/token and installation issues.

If, after confirming Entra ID join/SSO, printer access, and connector health, printers still don’t appear only on some AVD hosts, redeploying those hosts (as already being tested) is a reasonable remediation, especially if their Entra ID registration or Intune enrollment is inconsistent.

---

References:

• Universal Print Known Issues
• Universal Print troubleshooting guide
• Enable Hybrid AD/Microsoft Entra ID Environment on Universal Print