1 / 24

Optimizing Printing Architecture at CERN: Transitioning to Direct TCP/IP Solutions

This document outlines the significant issues and challenges faced with the existing printing architecture at CERN. It highlights unreliable connections, conflicts arising from multiple server access, and the complexity of job paths leading to poor user support. The proposal suggests a shift to a direct LPR-based architecture eliminating intermediate NT servers and creating a single server type environment. This would enhance job visibility, simplify queue management, and ultimately improve reliability and user experience in print services for UNIX, Mac, and PC clients.

eliza
Download Presentation

Optimizing Printing Architecture at CERN: Transitioning to Direct TCP/IP Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Printing at CERN Novell TCPIP UNIX Appletalk Mac PC IPX Ivan DELOOSE CERN PS Division HEP-NT 4/12/98

  2. Situation before 6/98 Novell Appletalk Appletalk TCP/IP IPX Appletalk TCP/IP Springer IPX TCP/IP Mac PC

  3. Major problems • Reliability poor due to some users being disconnected from the print server. • Multiple servers accessing the same printer creates conflicts. (Novell, UNIX, Mac) • Multiple queues for the same printer (UNIX, PC) makes for unpredictable time estimation. • Complex job paths make problem determination difficult and therefore user support complexity.

  4. Single architecture withintermediate NT servers

  5. Single architectureDirect LPR

  6. Why direct LPR from PC clients ? • Single server type environment (UNIX) • maintenance issues • no intermediate NT servers required • Single printer queues • better job visibility for the user • no simultaneous printer access • No permanent attachments required

  7. Printing Architecture Components

  8. Printing architecture blocks • Printer Database • Printer Manager • PC Client Utilities • Printer Wizard • LPR Service • Print Server Environment

  9. Printer Database • MSAccess : availability & easiness • Table of available printer models (drivers) • Standard MS W95/NT drivers (NTPRINT.INF for NT) • Third party added with the Printer Manager (OEM…) • Automatically generated from the .inf files

  10. Printer Database • Defines all CERN supported network printers • Printer name = Queue name • Win95 & NT Driver name + default settings (bin file) • Printer & Queue Server name

  11. Printer Database • Server table • system supports following server types : • NETWARE (phasing out) • Queue server only, Printer object on client • NT (not used at CERN) • Queue & Printer object servers • UNIX • Queue server only, Printer object on client • Queue server name resolved via DNS

  12. DNS host resolution

  13. Printer Database • PrinterTypes table • Used for client filtering facilities

  14. Printer Manager • Add third party printer drivers • Automated procedure

  15. Printer Manager (add driver) • Result & driver repository

  16. Printer Manager • Printer object & queue management • Database entry

  17. Printer Manager • Printer object & queue management (cont’d) • Automated queue management • Netware • Queue creation or deletion in NDS • NT • ‘PrintSync’ tool running permanently on NT printer server • Checks printer objects with database • Printer object & queue creation • Third party drivers must be beforehand installed with Printer Manager • UNIX (not yet implemented) • Remote printcap & filter configuration from MSAccess database

  18. NICE Printer Wizard • Standard W95 & WNT application for client printer installation, configuration and monitoring

  19. NICE Printer Wizard • User interface developed under Visual Basic • Printer & queue access written in C++ (DLL) • Polling mechanism replaced by multi threaded printer data enumeration & job information • Overwrites printer ACL (NT only) to public using the Impersonate mechanism • Supports ports redirected to Novell, UNIX & NT printer servers • Dynamic driver & port update from database at startup

  20. NICE Printer Wizard • LPQ & LPRM integrated in JobInfo window • Common W95 & NT version (VB EXE & DLL)

  21. PC Client Utilities • LPRSERV (LPR client Service) • Gateway between local jobs and UNIX print servers • Apps jobs to local file • filename = queuename • Job detected & renamed • queuename -> hostnameusing DNS • Job sent to UNIX serverusing LPR protocol • Started at logon • Common W95 & NT version

  22. UNIX Printer Servers • Current status • 600/1100 queues on PRINT1 (120/month) • Pbms with old printers to find UNIX filters • PRINT2 spare server, identical to PRINT1 • Planning for 1999 • All queues spread on 2 servers (PRINT 1-2), except IPX only printers • 1 new spare machine • Automated server setup procedure from data stored in the Access Printer Database ? • All servers identical -> clustering via DNS

  23. Future Client Plans ? • Standard Printer Wizard package for non-NICE users (e.g. visitors) • Improve Printer Wizard performances • LPRSERVice merged with PW DLL • Unique service (PWSERV) for all printing interactions • PW just simple front end • Separated JobInfo applications (VB or Java ?) • LPQ via data subscription in UNIX server • Driver update of installed printers at logon • New service (PWSERV) will include a server module for remote printer control (diagonistics, installation) -> Remote Printer Wizard

  24. Printer Manager & Wizard Demo

More Related