5990 views 0

If AutoConnect does not create the desired printers or if printing itself fails to work properly, check the following before contacting ThinPrint support.

To generate configuration reports and to troubleshoot problems, please use the ThinPrint Diagnostic Utility.

For AutoConnect issues, please also use AutoConnect Diagnostics. Select the Detailed Diagnostics option for a selected entry, then you will get infor­mation about the operations carried out by AutoConnect or about possi­ble faults.

AutoConnect Diagnostics

AutoConnect Diagnostics

AutoConnect Diagnostics: information about successfully created printers

AutoConnect Diagnostics: information about successfully created printers

AutoConnect Diagnostics: detailed error description

AutoConnect Diagnostics: detailed error description

  • If .NET Framework 3.5 cannot be installed using Server Manager,
    > try installing .NET Framework 3.5 from the command prompt (Windows CD or Windows ISO image is located in drive D:):
    Dism /online /enable-feature /featurename:NetFX3 /All /Source:D:\sources\sxs /LimitAccess
    > select in Group Policy Editor (gpedit.msc): Computer Configuration→ Administrative Templates→ System→ Specify settings for optional component installation and component repair→ Enable and try again to install .NET Framework 3.5.
  • With ThinPrint Engine installation, the following message appears in the ThinPrint License Server window: “License server could not be found. Please enter the address of your primary ThinPrint License Server. (The RPC server is unavailable. (Exception from HRESULT: 0x800706BA))”.
    • Use the FQDN instead of the hostname for specifying the license server address.
  • With ThinPrint Engine installation on Windows Server 2012, the following mes­sage appears: “The installation of Microsoft .NET Framework 4.6 (x64) has failed. Setup will now exit.”
    • Restart the server. Afterwards perform the installation again.
  • In the server settings of the ThinPrint Engine MMC component the following message appears in the ThinPrint License Server tab: “License server could not be found. Please enter a valid address.”
    • Use the FQDN instead of the hostname for specifying the license server address.
  • The Windows Event Viewer shows the message “No valid license found”.
    • On the license server, verify that the License Manager shows a valid license key. See Entering license keys.
    • In the ThinPrint Management Console, verify that the user who has printed is ThinPrint enabled. See Assigning a license to a user.
    • Verify that the ThinPrint Engine machine can connect to the License Server using the address and TCP port specified there.
    • On the license server, delete the local user group ThinPrint Excluded Users. See Excluding users.
  • If printers aren’t connected automatically from the central print server to the session, make sure that:
    • TP AutoConnect Service is running on the same machine on which the applications run (i. e., each terminal server or desktop)
    • AutoConnect is properly configured (see below)
  • If AutoConnect does not create or connect any printers after an update to Thin­Print version 11.0.2, and the following message appears in the Event Viewer: Event ID 1004 TaskCategory (4) TPAutoConnect Configura­tionFiles: 13 – The data is invalid. (% PATH-TO-DB \ TPACGlobal.db), 1 the AutoConnect database is no longer consistent. To fix this, proceed as fol­lows:
    • Make sure that your mapping database is specified in the AutoConnect con­figuration (MMC) or alternatively in the AutoConnect group policy (GPO).
    • Open the Map Additional Printers table in the AutoConnect configuration. Insert a new line, and enter a dummy printer in the Target Printer / Group column, e. g.: \\localhost\dummy
      Confirm with OK and Publish.
    • Remove the new line and confirm with OK and Publish again.
  • If AutoConnect returns the message No printers to be created in this session were found when using the parameters -a and -v (on the command line), please make sure that the Dynamic Printer Matrix is enabled.
  • If a ThinPrint license is used as soon as a terminal services user logs on for the first time even if AutoConnect did not map printers for that user, perform an update from ThinPrint version 11.0 to 11.0.1 or higher. Afterwards the Thin­Print Diagnostic Utility shows at least the following versions:
    • ThinPrint Engine 11.1.536 (instead of 11.0.496)
    • TPAutoConnect.exe 11.0.1278 (instead of 11.0.1266)
    • TPSvc.dll 11.0.1345 (instead of 11.0.1306)
  • If you can’t print with ThinPrint at all, first make sure that:
    • there are enough valid user licenses available on the license server
    • the Print Spooler service is running on the print server
    • TP VC Gateway Service is running on the same machine on which the appli­cations run (i. e., each terminal server or desktop)
  • If print jobs don’t arrive at the right printer, check whether:
    • the ThinPrint components on the machine where the applications run are out of date. Use the ThinPrint Engine to perform an update of these components (i. e., Output Gateway, AutoConnect, Virtual Channel Gate­way).
  • Is the same protocol selected for the ThinPrint Client, the ThinPrint Port, and AutoConnect? Example for RDP:
    • Is the RDP type of the ThinPrint Client installed on the client machine?
    • To which type of ThinPrint Port is the printer for this ThinPrint Client con­nected? Use Virtual Channel Gateway must be selected in the port configu­ration of the ThinPrint Engine console on the central print server.
    • For AutoConnect, either Virtual Channel (ICA or RDP) or Auto must be set as connection protocol. The respective column in Dynamic Printer Matrix has to be set to enabled (here R for RDP).
  • If the TP AutoConnect Service can’t be started: Check the access permissions on the folder/s in which the configuration databases are stored. See Storage destination for AutoConnect settings.
  • If you configured AutoConnect using Group Policies (GPOs) in the Active Direc­tory (see ThinPrint group policies).
    • Perform a Group Policy update in a session (gpupdate /force).
    • After performing the Group Policy update, check whether the following value exists in the Windows registry, and whether its data matches with the Dynamic Printer Matrix entries:
  • If Use Virtual Channel Gateway is selected in the central print server’s port configuration (see above), please also check the following:
    • Is/are the IP address(es) of the central print server(s) entered in Virtual Chan­nel Gateway configuration on the terminal servers (in the case of failover clusters those of all cluster nodes)?
    • Are the TCP port numbers the same for the ThinPrint Port and the Virtual Channel Gateway?
  • If TCP/IP is the selected protocol:
    • Are the port numbers the same on both the server and client (see Advanced tab)? (see port configuration of the ThinPrint Engine console on the central print server and in ThinPrint Client Manager)?
    • Are you sure that the TCP port number is not being blocked by the firewall or by another program?
    • Is the client machine in a masked network (NAT)? If so, you must either select RDP, ICA or PCoIP (and on the client-side use the respective ThinPrint Client;PCoIP is supported by the ThinPrint Clients embedded in VMware Horizon View Clients), or additionally, install the ThinPrint Connection Service.
  • If a printer was created manually, check the naming convention of the ThinPrint Port (see port configuration of the ThinPrint Engine console on the central print server).
  • If you selected Use encryption on the server, read the sections Encryption of print data and Troubleshooting.
  • If AutoConnect doesn’t install printers, manually establish a once only printer connection (as Administrator) from the terminal server or desktop to a shared Output Gateway printer on the central print server. The resulting printer connec­tion can be deleted afterwards.
Connection to an Output Gateway share on the central print server (example)

Connection to an Output Gateway share on the central print server (example)

  • From the time when the option Printer Self Service is enabled, the printers of users who log on to a session for the first time aren’t mapped automatically any­more. The tables Map Additional Printers and Dynamic Printer Matrix then pro­vide the input for printers to be selected.
  • Changes of the default printer or of printer properties in a session are only available in a second session after logoff/logon or disconnect/reconnect. However, if you want them to be available immediately, change the AutoConnect registry value StoreUserSessionSettings from 7 to 15 (decimal) or F (hex).
  • When AutoConnect starts (on a terminal server or virtual desktop), are the cor­rect shares on the central print server connected? The entries in Dynamic Printer Matrix and Map Additional Printers table must refer to the printer shares. Check that AutoConnect is working by starting it manually: open the command prompt in a session and enter – in C:\Program Files\Common Files\ThinPrint\ – the following to create the session printers:
    tpautoconnect -v [-i VMware -a COM1]

    • If the session printers are able to be created manually, by entering TPAuto­Connect in the command line, but are not automatically created when the session is started, check all AutoConnect settings.
  • VMware Horizon View: If tpautoconnect -v returns the message No suitable client protocol found:
    • check whether the session was started using a View Client or using a Win­dows RDP Client (in the case of the Remote Desktop Connection, the RDP type of ThinPrint Client Windows must have been installed beforehand)
    • if you are using VMware Tools, update to version 9.2.2 (or later) or, if using a View Agent, update to version 5.1.2 (or later).
  • Testing the TCP/IP connection: For printing via TCP/IP, there must exist, between server and client, a TCP/IP connection which allows direct communi­cation between the ThinPrint Client and its TCP port (a TCP/IP type ThinPrint Client is necessary on the relevant client machine). Firewalls or masked client networks (NAT) can often cause difficulties in this situation. Test to see if the connection exists by trying a telnet from the server to the client’s TCP port. To do this, enter the following at the server’s command prompt
    telnet IP_address tcp_port
    (See also Advanced tab.)
    Example: telnet 4000
    After executing this command, a telnet window should open, without error message. If so, the connection is OK.

    • Perform the same test from the print server to the terminal server or virtual desktop, if the print jobs are to be delivered to the ThinPrint Client via ICA, RDP or PCoIP (actual Virtual Channel Gateway) instead of TCP/IP.
    • Additionally, check that the name resolution works properly (both lookup and reverse lookup) and translates the names into IPv4 addresses. If the DNS returns an IPv6 address, you may disable IPv6 on the target machine.
  • If you used variables in the Target Printer column of Dynamic Printer Matrix (e. g. \\cps05\%LCPRN%), check that the printer names on the client machine and the share names on the central print server are identical.
  • When the V-Layer is activated, the name addition _n_ appears in the wrong position of the native printer object.
    Lexmark T655#client5:4_n_ instead of Lexmark T655_n_#cli­ent5:4

    • Verify that the printer in question is connected to a ThinPrint Port (instead of a Standard TCP/IP Port, for example).
  • V-Layer print jobs disappear on the central print server. To perform a test, pause both printer objects of a V-Layer. Then print from a session to the Output Gate­way object. Select Resume Printing for the Output Gateway object. If the print job arrives at the Output Gateway object and then disappears, perform the fol­lowing steps:
    • Ensure that the Windows service TP V-Layer is running on the central print server.
    • Share the respective native printer object. Alternatively, you can assign the permission Manage Printers to the group Everyone.
    • For Windows Server 2008 SP1 (x86 and x64): install SP2 or, the Microsoft hotfixes KB958741 (Print Job Owner) and KB958656 (Client Side Render­ing) both on terminal servers and on the central print server (see ThinPrint Engine on print servers: Technical requirements).
    • Check that the Output Gateway driver version (at least on the central print server) is up to date.
    • For VMware Horizon View environments: update the ThinPrint components provided with View Agent, using ThinPrint Engine installer software.
  • Incorrect characters or fonts in print output:
  • Although you enabled ThinShare your print jobs aren’t compressed on the way to the central print server:
    • One of the messages “ThinShare is in active state, but print job is not com­pressed. Check Group Policy” or “ThinShare On, CSR On, Job is not com­pressed” can be found in the central print server’s Event Viewer.
    • Check whether the version of ThinPrint’s print processor TPWinPrn.dll is at least 9.4.538 (in C:\Windows\System32\spool\prtprocs\x64).
    • To update the print processor see Updating Output Gateway to ThinPrint ver­sion 11.
  • If the printer list of ThinPrint Client Service Windows is empty after booting the operating system, it may be because the client started up more quickly than the Print Spooler. In this case, you can delay the TP Client Service Windows start up, using either the start type Automatic (Delayed Start) start type or using a script (start type: Manual):

ping -n 30 >NUL
net start Thn32svc

  • From Windows 2012 R2 type-4 drivers can’t be connected to third-party printer ports. That’s why use type-3 drivers with ThinPrint Ports. You can check the driver type in Print Server Properties→ Drivers→ Properties:


Previous Page
Next Page

Was this helpful?