iPrint at Novell
Novell Cool Solutions: Feature
By Jared Jensen
Digg This -
Posted: 24 Aug 2004
Some of Novell's coolest products and technologies have been created in direct response to problems faced by Novell's IS&T (Information Services and Technology) department. These IT professionals are an invaluable source of inspiration for Novell's development teams, since they grapple every day with the same issues faced by Novell's customers around the world.
One great example is Novell iPrint, a printing solution based on the industry-standard Internet Printing Protocol (IPP) that eliminates the complexities of printing over the Internet and makes location-based printing a reality. The need for something like iPrint, specifically the web-browser based discovery and installation, seemed natural for the building techs who grew weary of answering help desk calls (at 2:00 in the morning) from people who couldn't set up their printers. They continued to meet with the developers who sat near them, and the end result was a killer technology that is now part of Novell NetWare, Novell Nterprise Linux Services, and the upcoming Novell Open Enterprise Server. We recently sat down with Jared Jensen of Novell IS&T who was there in the beginning, and he shared his memories of how it used to be, and explained how iPrint has transformed the way Novell's employees do business.
Jared: When I started at Novell I was a building tech in IS&T working on queue-based printing. I worked in the building where the core developers for NetWare were located, so we worked a lot with rolling Novell products out internally for Novell employees to test and use. I began managing print, and that is when I started on NDPS (Novell Distributed Print Services), right at its earliest stages of development. I've managed it from then to this day.
Back in those days (around the NetWare 5.1 time period) we started by putting an NDPS manager on each server, or on a number of servers, so by the time we were done we probably had 20-25 desk managers throughout our two complexes in Orem and Provo. It became quite the management task to manage all of those managers and the various versions of NDPS code that were being tested. Granted, that is not the usual customer story. Most customers (I would say all customers besides us) don't roll out a new product in its beta stage like we do. But that's part of the job at a software development company. It was my responsibility to make sure all of these managers worked all the time. It was quite the management headache.
"One of the top help desk calls, or building tech calls, was 'Come set up my printer.'"
We realized Novell needed a better printer solution, because print problems were one of our top help desk calls. We still had some old queue-based printers because we had some old apps that couldn't print in NDPS, so we had to support the queue-based model. One of the top help desk calls, or building tech calls, was "Come set up my printer." Unless the person knew what they were doing and could go and discover the printer that they wanted to print to, you would have to have the building tech help each person and walk them through it. So we kept going to the developers and bugging them to look at our problem and figure out a way to simplify things.
During this time Novell had launched a special secure website called iLogin, to push services and software out to employees. So we kept pushing and requesting, "Look, this is what we want: we want users to be able to go to a web page to set up their printers, because that is where we are pushing everything else to them." Every desktop comes with a browser, so we knew every user would know how to use a browser, and we wanted users to be able to go there to discover the printers. We wanted them to go to a map or something and easily find the printer nearest them. That is where we really started pushing the idea. We kept going back to the development team and saying "This is what we want, how close is the web interface now?"
The solution they came up with was iPrint.
Cool Guys: So the network print team wasn't really thinking seriously about creating a web interface for printing until you guys suggested it?
"We wanted them to go to a map or something and easily find the printer nearest them. That is where we really started pushing the idea. We kept going back to the development team and saying 'Look this is what we want, how can you help us?'"
Jared: Well, I don't know if we were the first ones to suggest it, or if they had already thought of it. All I know is, we were feeling the pain, we could imagine the benefits of this solution for us and for our users, and we knew that team could make it happen, so we gave strong support to the development effort.
It's kind of like the BOMA project (now known as Nterprise Branch Office). We came to the development team and said "Look, we need an appliance that can sit at an office, but is not part of the corporate eDirectory tree, because we don't want to replicate it out there, but we want it to consume directory information." So we worked with a couple of developers that were working on it after hours, and they gave us something that works like a champ.
Cool Guys: So what was so problematic about printing that made it the number one help desk call?
"Employees would have to understand our eDirectory structure and Novell's internal organization in order to use the printer that was sitting two feet from their office."
Jared: Well, everybody needs a printer, and the problem was searching for the right one, and having the right printer driver and everything. They'd call and say, "I need to print something." And as the building tech, my response was, "Okay, I'm coming." Because I would know the tree and where their printer object was, and you couldn't set it up without that knowledge.
It really got confusing because you would have a bunch of different teams sitting in the same area. So, say just within this one quadrant of the floor you would have part of the marketing team and part of HR (Human Resources) and they would each have their own printer. But HR may have purchased a better printer, and said, "Yeah, you guys can use our printer, it is not going to cost us much to let Marketing use it." But in order for a marketing person to install the HR printer, they would have to go figure out which container that printer was in. So they would have to figure out how to browse the eDirectory tree to find that printer. That was a big problem. They would have to understand our eDirectory structure and Novell's internal organization in order to use the printer that was sitting two feet from their office.
Once we started down the iLogin road, and began trying to make it easy for people to access services via the web, we realized that the Novell_Inc tree that we had was really an administrator's tree, it wasn't a user's tree. And administrators don't think of things with the same logic a user does.
For example, an administrator understands things like: I need to segregate my tree for very specific reasons. I need to clarify geos, so in order to replicate this directory I need to create America, AsiaPac, EMEA, maybe India, and maybe one more container, and then from there I am going to start separating my groups. I may even need to go two levels of GEO's (geographic regions), then Americas all go to cities, and then after cities, then I'll go groups, etc.
Then, say in Chicago, I may have some HR, some marketing, some IT, some development. So I may have four or five containers in Chicago alone. For an administrator that is great, because it allows me to partition it out and replicate things around if I need to. But for a user, it makes it incredibly hard because it just doesn't make sense.
It makes more sense for a user to see the bottom part of the tree where it may just say users, printers, servers, and stuff like that. So that is what we did with iLogin -- we created another tree that was user based, that was more understandable to the user. That way we could start at the root and just put Novell, and that one has all the users, and then we put printers and that one has all the printers, and that way all we would have to come up with is a naming scheme to identify the printers.
This made it easier to move everything to a web interface where the user could go browse and install a printer. As soon as we did that, we were able to consolidate all of those 25 NDPS managers down to one. Now iLogin as a separate site is gone, and everything is consolidated in the Novell Innerweb (the company intranet), making it even easier to find.
Then as we implemented iPrint, we started to realize how many printers Novell had that were being under-utilized. In fact in our San Jose offices, we realized we had a 1-to-4 ratio, we had one printer for every four employees. And these were high-end business printers that were capable of supporting 40 to 50 users easily.
Cool Guys: How did iPrint help with that?
Then as we implemented iPrint, we started to realize how many printers Novell had that were being under-utilized...When we went to set it up, we saw that we had way too many printers out there, and were spending a lot of money on stuff like toner that didn't really need to be there.
Jared: Well, iPrint didn't change that but it helped us identify the problem. When we went to set it up, we saw that we had way too many printers out there, and were spending a lot of money on stuff like toner that didn't really need to be there. We were also spending a lot of money on maintaining them because the building techs would have to visit them to replace the toner or work on anything in them that needed to be fixed. A lot of them were old but still worked, so they just stuck around and once in awhile people would find them and print to them.
So we started consolidating and collecting all these old printers by saying "You give us two or three of your old ones and we will buy you a new one that is better and bigger and faster." (We kind of had to tease them into giving all those old ones up.) It allowed us to consolidate a bunch of printers down to the point we are at right now. At the Provo campus alone, we are at 279 printers, putting us at about a 1-to-7 ratio. These 279 printers are housed on on two NetWare 6.5 servers. They average anywhere between 3-5,000 jobs a day.
"At the Provo campus alone, we are at 279 printers, putting us at about a 1-to-7 ratio. These 279 printers are housed on two NetWare 6.5 servers. They average anywhere between 3-5,000 jobs a day."
We were also able to reduce the amount of servers that housed printers or printer objects, because we went from the 25 servers that were housing a bunch of printers to two servers (well, actually one server because they are in a cluster), housing 279 printers. With this model, honestly, I believe we have reached 99.999% uptime. Print used to be a daily/nightly support call for me. It used to be my number one problem most of the time. (Of course we used it in beta form and so a lot of the times we were testing stuff that we knew was broken and we were trying to work through problems.) But after we got on NetWare 6.5 and got it into a cluster, it honestly has not been an issue for me. I used to get called two or three times a night, we're talking 1, 2, 3:00 in the morning because of some printing problem somewhere.
Cool Guys: What about employees outside Provo?
Jared: Well, it took us another two or three months to get the regions upgraded (Europe, Australia, etc.). Since then I have not had any issues. They do not call me for print anymore, because they just don't have issues -- it just works for them now.
A number of field office engineers and systems engineers out in the field have told me that they will set up a meeting with a customer, and find they don't have time to get to the office and print the stuff they want to hand out to them, so they will kick the print job off at their house. They just get on Novell's Innerweb and install the printer on one of their machines at home, send off the print job, and if it takes them a half hour to 45 minutes to drive into work, by the time they get there it is sitting at the printer ready to go. It has been a great thing. Those who use it out in the field just love iPrint.
"It's easy for Novell salespeople to show people, because they can just say, 'Let me show you how we do it at Novell.' They can go straight to the Innerweb from anywhere and log in, and say, 'Look here is the printer at my office.'"
Plus it's easy for Novell salespeople to show people, because they can just say, "Let me show you how we do it at Novell." They can go straight to the Innerweb from anywhere and log in, and say, "Look here is the printer at my office. Here's how I used it to print off today's presentation for you." I have been to a number of sales conferences and every time I go they just say that iPrint is great.
Cool Guys: Best of all, iPrint ties right into the whole new Linux world. An iPrint Client for Linux is actually part of the Open Enterprise Services (OES) product.
Jared: Exactly, it has worked right into it. When we started the Linux desktop initiative, all I had to do on the Innerweb was modify the maps and URLs just a little bit and then provide some instructions on how to install an iPrint printer to a Linux machine. So it was really easy to make that transition from Windows desktop to Linux desktop. When we get to OES, it'll be a no-brainer to administer on Linux.
iPrint lets mobile employees, business partners, and customers access printers from a variety of remote locations using existing Internet connections. Whether users are working in an office building, telecommuting from home, or attending a sales meeting in another country, iPrint ensures that they can print documents quickly, easily, and reliably.
Using a Web browser, users point to a Web page that displays the available printers. By clicking a printer, the iPrint Client is installed (if not installed previously), the printer's driver is downloaded, and a printer is created in the user's Windows Printers folder, enabling the user to send documents to the printer from any application on the desktop.
Using iPrint, mobile users no longer need to contact a busy network administrator to find out a printer's name, context, and the required printer driver. Instead, mobile users work within a Web browser to locate nearby printers using iPrint's default printer list or maps created by the administrator. Companies can also lower communication costs by reducing the need to fax documents between offices; instead, companies can use their existing Internet connections to print documents to remote printers.
iPrint uses the Internet Printing Protocol (IPP), an industry standard, to eliminate the complexities of printing over the Internet and to make location-based printing a reality.
For example, at Novell's Provo campus, employees can access this map on the Innerweb to select the building and floor where they want to print.
Clicking the appropriate floor brings up a schematic map of the offices on that floor, and highlights the location of all the available printers. Click on a printer, and the drivers are automatically downloaded and the printer is installed.
Cool Guys: Just for fun we timed the whole process from our offices in Provo, Utah. In 58 seconds we logged into the Innerweb, found and installed a printer in the corporate headquarters in Waltham, Massachusetts, and were ready to send a print job to that printer. Nothing short of miraculous when you remember the old days when you had to find a likely printer, write the ID number on a sticky note, come back to your office, and call the help desk for assistance. It's like cell phones and microwave ovens: one of those things that you never want to do without again.
- Configuring Your iPrint Maps
- Ideas for iPrint Maps
- Novell iPrint Administration Guide for Novell Nterprise Linux Services
Question: Interesting article which has raised the following in my mind.
The majority of building floor plans are usually in Autocad dwg format. Is there a utility that can convert from dwg to gif or jpeg for iPrint map display? What do you guys use? Surely you do not create your own floor plans from scratch.
Jared: This is a good question.
The way we did it was we asked the Facilities group that has the Autocad program to print the floorplans to a PDF file using Acrobat Writer. Once I had the PDF file I was able to open it with Adobe Photoshop and manipulate it from there.
There is probably a better way to do it but that is the way we did it.
Cool Guys: We found a few tools that you can purchase that will help with this task.
ABViewer is a professional image viewer for industry and home using. ABViewer is a multi-purpose viewer and converter, ideal for using with Total Commander or Far manager. ABViewer supports *.DWG, *.DXF, *.HGL, *.PLT, *.HG, *.HPG, *.PLO, *.PCX, *.BMP, *.JPG, *.JPEG, *.WMF, *.EMF, *.GIF, *.ICO files. ABViewer converts all supported files to BMP, EMF, JPEG, GIF formats.
- Bluebeam Pushbutton Plus
Bluebeam Pushbutton Plus will effortlessly convert CAD drawings and Windows documents to .pdf, .tif, .jpg, .bmp, .psd, .png, and .pxl files. Convert from CAD applications without the need to adjust settings. Batch convert an unlimited number of AutoCAD files to .pdf, .tif, .jpg, .bmp, .psd, .png, and .pxl
- AutoDWG DWG2Image Converter
A batch converter which converts DWG or DXF files to BMP, JPG, TIF,GIF, PNG without need of AutoCAD. With AutoDWG DWG2Image Converter you can generate qualified bitmaps for: Publishing your drawings to the Internet, CD-ROM to store and manage your drawings, and desktop publishing software.
- Acme CADConverter
Acme CADConverter is a format conversion software for batch and vector files. It can conveniently convert DXF,DWF and DWG files into BMP, GIF,JPEG, DXF, DWG, SVG,PDF, HPGL(PLT,HGL),PDF etc., and also enable the conversion between DXF and DWG file versions (AutoCAD R2.5-R2005).
Anyone out there got another option to share? Any experiences/gotchas about any of these tools? Let us know.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com