Forum Discussion

NetFire's avatar
NetFire
Copper Contributor
May 21, 2020
Solved

Procedure for diagnosing failure to print?

What is the procedure for diagnosing and/or submitting a report for a client having an issue printing? I'm going to try to test a few more things to narrow it down, but in a nutshell I've got a win 1...
  • Jimmy_Wu's avatar
    Jimmy_Wu
    May 28, 2020

    NetFire, sounds like your printer doesn't need the user account/ID, so yes, just setup a workstation PC that's not domain joined or AADJ to host the Connector.  It can be a VM or a real hardware.

NetFire's avatar
NetFire
Copper Contributor
May 28, 2020

Jimmy_Wu 

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_Wu's avatar
Jimmy_Wu
Former Employee
May 28, 2020

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

  • NetFire's avatar
    NetFire
    Copper Contributor
    May 28, 2020

    Jimmy_Wu I checked logs on both sides. Here's what I've observed:

    1. 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.
    2. 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.
    3. 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:

    1. Client PCs are azure-ad-joined. The accounts I'm testing with are all azure ad accounts.
    2. 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.

    • Jimmy_Wu's avatar
      Jimmy_Wu
      Former Employee
      May 28, 2020

      NetFire, I'll assume that you've already assigned the license to those individual user accounts that isn't working.

       

      You mentioned that the PC running the Connector is on a domain that isn't DirSync'ed with Azure AD.  Based from the error message you provided, that would be the first thing I would look into.  Is there a particular reason for not setting up the DirSync (Azure AD Connect) to keep the user accounts and credentials in sync between Azure AD and on premises domain?

       

      If you are looking for a workaround to do some testing and your printers do not require a badge release mechanism, you can just run the Universal Print Connector software on a non-domain joined workstation.

       

      If your printers require badge release, then your suggestion could work, though I haven't tried it myself.  You would enable Azure AD Domain Services in your tenant.  Spin up a Azure VM and join to the AAD DS.  The Azure VM would need a VPN connection back to your organization's network to have connectivity to the physical printers.  Run a Connector on the Azure VM.  Install your organization's printer on the Azure VM and register them to Universal Print using the Connector.

       

      HTH,

      Jimmy

      • NetFire's avatar
        NetFire
        Copper Contributor
        May 28, 2020

        Hi Jimmy_Wu , how does badge release work? I would imagine that would require a high-end MFC printer with that specific capability? Unless universal print offers something I'm yet unaware of that runs on some other device that can be placed near a generic printer...

         

        The reason for not using dirsync is that it makes many things a pain. With dirsync enabled, I'm unable to change things such as aliases from o365. As we do not use onsite exchange server, there really is no good way to edit those locked attributes with dirsync on. At least that was how things operated since I last used it, which was within the past year I think.

         

        So I guess the solution here is to use an onsite VM running the connector, which isn't joined to AAD nor ADDS?

Resources