3 Replies Latest reply on Jan 22, 2018 12:23 PM by Scott Olswold

    SNMP and IPP services at the Server

    Paul LaFollette Guide

      Are there any advantages/uses for adding SNMP and/or IPP services to the Uniprint server?

       

      Microsoft has some scripting and Power Shell abilities that can be useful with automating/configuring printer setups for the Client computers, but these methods do not "inherit" the print queue configuration (# Trays, Paper Sizes, Mono/Color settings, etc.).  Some (but not all) of these settings can be pre-set in the driver if you wish to edit the driver's default config, but with limited success.  Granted, Uniprint has the Packages that can be used, but there are times/places where the packages are not desired (especially in places where the Popup and other components are not wanted/needed).

       

      Can the communication/feedback the client computer can get with the server be enhanced by having the SNMP Services and/or the IPP (Internet Printing Client) active on the server?  By default, the server does not have these services running, but is (of course) able to communicate (as a client) with printers that are SNMP and/or IPP enabled.   What about the end user's computer as a client to the server (with SNMP and/or IPP services)?

       

      For example, A Windows computer typically has Local Port and Standard TCP/IP protocols available for connecting to a printer.  Install additional printer software and more protocols can be available (LPR, HP's protocols, etc.).  Connecting to a print queue (without using a Uniprint package) usually means using either Local Port or LPR, but not Standard TCP/IP even though all three ask for server name and queue (or port).

       

      If SNMP or IPP services are running on the server, can Standard TCP/IP be used to connect to a print queue on the server by specifying the server address and the Queue (as the Port name)?

       

      We're playing around with some possible deployment methods want to increase the level of "feedback" the user's client computer can receive hopefully to provide the queue's configuration (obtained from the server) to apply to locally installed printer object or a printer object in the process of being setup on the user's computer.  We want to try to do this without using the Uniprint packages, and without using the UNC path based shared network printer connection.

       

      Thoughts?

       

      Thanks,

      - Paul L.

        • Re: SNMP and IPP services at the Server
          Scott Olswold Guide

          Paul,

           

          Adding SNMP won't do anything. SNMP is used for providing either information (Make, Model, serial number, configuration, etc.) or/and alert information (online ready, online not ready, offline, etc.) on a network device.

           

          Adding IPP allows an IPP client (which you would have to add to a Windows client) to connect to and print to a shared queue. IPP is a lot like LPR/LPD but over an HTTP connection. This type of connection can be used as an alternate to RCP or LPR to the Pharos print server, but it will require

          1. Valid network credentials on the client side in order to connect, in the same way that RPC does now.
          2. An IPP Client installed on the client side.

           

          In Windows clients, if you connect to the queue using Add Printer, you will inherit the server's current configuration. However, the print queue becomes a totally local object, so the user can change settings that may cause jobs to print out/charge in an unexpected way.

           

          -Scott

            • Re: SNMP and IPP services at the Server
              Paul LaFollette Guide

              Scott,

               

              Thank you, that is what I wanted to know.

               

              To clarify the last thing you said, With IPP, the user's computer would inherit the server's current configuration (of the print connection).  However, the print connection the user's computer ends up with becomes a totally local object, so the user can change settings, unlike how a network shared print connection has settings that the user cannot change (things like default settings, ports, etc.).   Is that correct?

               

              To compare, If I was to make a print object (a "Local" printer with manual settings) and used Local Port, the Local Port creation would require valid network credentials in order to connect, and I would also have to manually specify the driver and configuration.  Whereas, IPP would also require valid network credentials AND would inherit the server's current configuration of the print connection, but the client computer's print connection would become a "Local" object which (after the initial creation) could be completely reconfigured by the client user.   Would that be a valid comparison?

               

              Are there any performance issues to be concerned about with IPP?

               

              Thanks,

              - Paul L.

                • Re: SNMP and IPP services at the Server
                  Scott Olswold Guide

                  Paul,

                   

                  Your comparison is valid; IPP is somewhat of a "hybrid" between local and remote queue attributes.

                   

                  As far as performance is concerned: when the client and server are both on the same LAN, there's not much of a performance differential between IPP v. RPC or IPP v. LPR. However, if the server is remote (and, particularly, on a slow or highly-utilized circuit) there are significantly measurable gains in IPP over RPC...but not much at all versus LPR. This is because when some applications (like MS Office and Adobe Acrobat) print, they require a lot of information from the printer driver. In RPC, most of what they ask for is server side, resulting in a lot of back-and-fro communication just to spawn a dialog box that is "ready" to Print. In both IPP and LPR, that is all local to the client, so generating the Print dialog box is quick. Network transport of the job between RPC, LPR, and IPP is mostly the same (there are subtle variations in throughput speed, but not enough to both an end user).

                   

                  -Scott