Forum Discussion
Procedure for diagnosing failure to print?
NetFire, you mentioned that you are using Brother Universal PCL driver on the client device. Universal Print only supports using the OS built-in class driver, which is automatically set when installing a Universal Print printer. Depending on the version of Windows 10 the device is running, the exact name may be a little bit different.
If after changing the driver back to the OS built-in class driver, you are still having problems, please file a support ticket.
If you would like to perform some troubleshooting, one option is to use Fiddler to capture a network trace. This will allow you to capture the error message from the service when you submit the print job to see what may be happening to decide the next step of the troubleshooting.
If you meant to state that the Universal Print Connector is running on a PC using the Brother Universal PCL driver, please reply and let us know that is the case. With the breadth of printers and printer drivers available in the market, the Universal Print Connector package has only been tested with select set of printers. We are actively looking for customer feedback regarding printer drivers used on the PC running the Connector software that is causing compatibility issues.
HTH,
Jimmy
- NetFireMay 28, 2020Copper Contributor
Hi Jimmy,
I meant that the connector is running on a traditional windows print server, where I have switched all the printers to use the brother universal driver, just to remove some variables from this equation. I'm not sure why some users/computers can print to the printers and some cannot. I'm still working on figuring out which conditions lead to one outcome vs the other.
- Jimmy_WuMay 28, 2020Microsoft
NetFire, since print failures can happen at any one of the 3 stages
- Client to cloud service
- Cloud service to Connector
- Connector to physical printer
If I'm starting to troubleshoot from scratch, I will typically capture a network trace (I use Fiddler) to confirm whether the issue is at stage 1 or not.
Assuming it is not stage 1, then I would move to troubleshoot stage 2 by reviewing the Windows Event Viewer logs on the Connector host PC to see what the Connector is seeing. For example, did the Connector retrieve a notification that a new print job is ready for it? Was the Connector able to download the print job from the cloud service? etc.
If the Connector event log doesn't show issues, then I would move to troubleshoot stage 3, which is the Windows spooler. This would be the same troubleshooting as standard Windows Print Server spooler without Universal Print in the picture.
HTH,
Jimmy
- Jimmy_WuMay 28, 2020Microsoft
NetFire, sorry forgot to mention that if you changed the printer driver on the Connector host PC after the clients have already installed the printer, you will need to reinstall the printer on the client machine. At this moment, the printer capabilities and options are retrieved from the cloud service only at install time.
Thanks,
Jimmy
- NetFireMay 28, 2020Copper Contributor
Jimmy_Wu I checked logs on both sides. Here's what I've observed:
- I'm a global admin. I can print just fine. Other regular users cannot. I added standard users to local admins, and that did not help. I did not test printing from another global admin account yet.
- On the client PC, the printservice logs look okay and don't report any errors. The issue appears on them as a toast and error in the print queue.
- On the print server, the PrintConnector log shows an error:
PrintJob failed System.Security.SecurityException: The user name or password is incorrect. at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeAccessTokenHandle& safeTokenHandle) at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type) at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName) at ProxyLibrary.Printer.<PrintJob>d__58.MoveNext() The Zone of the assembly that failed was: MyComputer​
That being said, note the following:
- Client PCs are azure-ad-joined. The accounts I'm testing with are all azure ad accounts.
- Print server is local ADDS-joined. The ADDS and AAD are not setup with dirsync or federation (although they were once dirsync'd). Users usually exist on both, but credentials may differ, as we are currently in the middle of a transition to azure ad/intune. These new laptops are on the new system, whereas the onsite servers and some pcs are on the traditional AD network still.
Given the above facts, how would I be able to resolve this? Do I need to spin up a VM, join it to azure ad, and install the connector on there? I did not see any sort of requirement for that, as I still signed into the connector itself with my global azure ad admin creds. Thanks for the tips.