Archive for February, 2016

h1

The way ALL Print Drivers SHOULD be written!

February 18, 2016

Let me start out by saying I don’t write print drivers. I am a Systems Engineer so I set them up, configure them, and sometimes I hack them to make them do what I want them to do. About six weeks ago I was working with a customer that was using a Universal PS driver of a particular Print Management system and ran into an all too common problem.

The customer was getting some Postscript errors on random print jobs and asked to try the Universal PCL driver. I thought sure they “are” two completely different print drivers. They have to be because they use a different print language (PCL vs PS). At least, that is what I thought! But it wasn’t the case. To be fair the Print Management system had been upgraded about six months earlier but the Universal Print Driver that was being used by the client PCs were still the older PS one. I could tell because the older one had 3 tabs in its printing preferences settings, while the new one had only one.

As a best practice I typically pull the the driver from the resource web page of the Print Management Server. When I did this and set up the NEW PCL Universal driver it also unfortunately updated the OLD PS Universal Driver. This caused the OLD PS Universal Driver to become unstable. And caused me and the IT Manager a fair amount of unnecessary and unwanted work. All because of a poorly written Universal Driver.

Universal Drivers are becoming more popular as a way of only having to load a single driver (ideally) or at least fewer drivers on a print server. Why is that important? Because as anyone who has worked in the print industry for any time will tell you; print drivers don’t always place nice with one another.

The reason this happens is the files that make up most print drivers end up in the same folder:

C:\Windows\system32\spool\DRIVERS\x64\3

In and of itself this is not a problem. And generally different manufacturers name their files differently so they don’t over write or get overwritten by another manufacturers print driver. You would think that each Manufacturer would either write backward compatible print drivers (ideally) or at the very least their newer print drivers would not overwrite their own older files if they are not going to be backwards compatible. But sadly this is all to commonly not the case. Once a newer driver has overwritten a file used by and older driver and caused it to become unstable or create new unwanted behavior it can be very difficult to remove the driver, even with some of the cool driver removal tools that many of the manufacturers provide. I speak form the experience of battle.

But I recently was pleasantly surprised when I was working on another Print Management system that had some Samsung Print Drivers already installed. We wanted to test a new Universal Samsung print driver. But this wasn’t the first rodeo for this IT Manager. Just before we loaded the new Universal print driver he turned to me and said “remember, this is a production print server”. Then he asked me will this new Samsung driver interact with any of the Samsung drivers that are already installed? I told him that I honestly did not know, so I would do some testing on my Demo room system and let him know.

I went back to my Demo Room and the first thing I did was print out test pages on all of the current Samsung Printers. then I loaded the new Samsung Universal Print Driver and printed out it’s test page and all the other Samsung Printer test pages again. Why, you ask? Because each test page lists all the files that that Print Driver uses and where they are located. When I did this I got a very pleasant surprise! Samsung wrote their print drivers so that each one of the files had a specific and unique prefix for each of their Print Drivers. A great BEST PRACTICE when writing a driver. This way none of their drivers files would overwrite (or be overwritten) the file of another print driver even though the were all installed in the same “3” Folder.

C:\Windows\system32\spool\DRIVERS\x64\3

This is the way all print drivers should be written! Well done Samsung, well done!

That’s My $0.02
Vince McHugh
VP \ Network Solutions
vince.mchugh@yahoo.com

Advertisements
h1

The Nine Month Trial

February 14, 2016

I am not a big fan of on site trials. Usually when a Sales guy tells me that their Customer wants to do an onsite demo I ask why? What can they see on site that that can’t see in our demo room. Maybe they have some custom application or a Host system that they want to see print correctly. In those cases I ask the Sales person to write up a conditional sale. They negotiate an acceptable price and we set some very well defined conditions. These do not include “if we like the machine” or “If our users are happy with it”. These are two vague and capricious. A conditional like “it must print form our AS400 system and format the pages like our current printer does”. Or maybe “It must be able to scan to email from our Office 365 email server”. These are well defined and achievable conditions that once met we will get the deal. If a customer refuses to sign a conditional sale, be ware, their commitment level is probably not where it needs to be to risk doing that much work.

There are of course exceptions, but it is generally based on the risk reward ratio. If we spend the time to set up an MFD, that’s not that time consuming. But if I have to set up am  UniFLOW, Papercut, or Biscom Server for a trial that takes just as much time to do it for a trial as it would for a real installation. And that’s fine “IF” there is a big enough return on investment. I am very confident in our ability to make our MFDs work with most systems. I like to tell people if your running Windows, Mac, Unix, Linux. AS400, we can and have integrated our devices with these systems. Pretty much anything except Banyan Vines :-). And if you know what that is you’ve been doing networking for a very long time.

About nine months ago one of my top sales woman got me involved in a presale opportunity where the potential customer was currently using Equitrac with Konica Minoilta MFDs to print from a host system processing medical billing. The customer has the need to occasionally reprint jobs for the end users if they didn’t print correctly or at all. The KMBS Branch added some separate software called Phoenix Dispatcher to add this functionality that Equitrac could not accomplish. It did however require the Customer’s IT Dept to do the reprinting of the jobs based on a date and time range.

NECS believes in team selling. Having both a seasoned Sales Parson and a Pre Sales Systems Engineer to better define not only the customer’s needs but what would be the best solution to satisfy that need. You may have heard me say in the past that I believe a true solution is a combination of Hardware, Software, and Know How used to solve a Business Problem. The Pre Sales SE needs to not only understand what the customer is trying to do but why and then consider all the different options available to best meet this need. Sometimes a good SE can help a customer revamp or reinvent how they do a particular process or workflow saving them significant time and money. But that only happens when there is a certain level of trust and a good working relationship between the vendor and the customer.

When we first met with this customer they told us the basic functionality they had was working “OK” but they were unhappy with the reliability of the Konica Minolta MFDs and even more so with the lack of support from the KMBS Branch. They were interested in replacing the KMs with Canons but not all at once. And here is where it gets complicated. After understanding what they were doing now, what they liked and didn’t like, and what they were hoping to accomplish we gave them a couple of options:

  1. Keep using your current Equitrac System with your Phoenix Dispatcher System and we will simply add Canon MFDs with embedded Equitrac MEAP apps to replace the Konica Minoltas that are failing. We would need to order RFIDead Card Readers and do some testing to match the current HID OmniKey Card readers on the KM MFDs. But a number of our vendors (Nuance, Cranel, RFIDeas) said “no problem” we will be able to match the card numbers read by the OmniKey Reader.
  2. . We also proposed replacing the Equitrac System in three  possible ways:
    1. Add a UniFLOW System to run alongside their current Equitrac System and it would eventually be replaced as we replaced more and more KMs with Canons.
    2.   Completely replace the  Equitrac System with the UniFLOW system and use the UniFLOW Universal Release Stations (URS) to release the print jobs on the KMs and the Canons would use their built in UniFOW MEAP app.
    3. The third option we considered was Papercut but we dismissed it early because while it has a nice Archiving feature, there is no mechanism currently in place for mass reprinting or even reprinting a batch of print jobs.

When the KMBS Branch found out that the customer was talking to us and that they were considering replacing some of their Konica Minolta MFDs with Canons they said “You know that you wil need to have two separate input queues for secure printing. One for the KMs and one for  the Canons”. They asked us if this was true and we confirmed that Yes, this is how Equitrac does it. We did tell them that with the Canon UniFLOW System you could have a single secure input queue for BOTH the Canon & the KM if they used the UniFLOW Universal Print Driver.

The first option failed to be satisfactory when we could not get the new RFIDeas Card Readers to read their HID cards exactly the same. We worked with RFIDeas, Cranel, and Nuance and the only solution that they came up with was to dumb down the readers to read a 5 digit card number. This was unacceptable to the Customer. So we moved on to a UniFLOW System.

When we installed the UniFLOW system we loaded UniFLOW MEAP apps on the Canon MFDs and set up UniFLOW URS (Uninflow Release Stations) near each of the Konica Minolta MFDs. While we recommended that NECS take over the service on all of the KMs as well as the Canons the fact that we didn’t actually have to load any software on them or modify them in anyway to use the UniFLOW Release Stations they could if they want to still have the Branch continue to service them until we replaced them with Canons. Two of the things that the Customer REALLY liked about the UniFLOW System were that you could not only use a single Secure Input Queue for multiple MFD manufacturers BUT the End Users could reprint there own documents WITHOUT any third party software (like KM’s Phoenix Dispatcher) on either the Canons or the Konica Minoltas becasue they both show a new print job queue and a previously printed job queue (if activated). This was a big deal for the IT Department because it meant they no longer had to reprint users documents.

So we worked hard, and worked through the different challenges to deliver the perfect solution to this customer, right? Well, not so fast. All that I described above with the UniFLOW System worked as advertised BUT this particular user had two more requirements. The first requirement is  all documents had to be printed in the exact order that they were sent to the Secure Print Queue. And the Second requirement is they all had to print at the rated speed of the Engine (Canon or KM). These two requirements were BOTH do able but NOT with the Universal Print Driver. Technically that’s not true, The Universal Print Driver can print in order and at rated speed unless you print a very large number of single page jobs, which, you guessed it, that is what this customer does. We have never seen a slow down before because we had not dealt with a customer that would print 200 – 500 single page jobs and then release them all at once.

We worked with NTware & Canon for over a month to try to get this resolved and finally had to tell the customer that the only way we could get them to print at rated speed and in order for 200 – 500 single page jobs we would need to use the actual Manufacturer’s Print Driver, which would mean in this case UniFLOW, like Equitrac, would need to use a separate secure input queue for the KMs and the Canons respectfully. The customer was not happy and asked us to keep working on the Universal driver to accomplish all three functions:

1. Print at rated speed

2. Release all the Print Jobs in the same order that the user sent them

3. Use one secure input Print queue for both the Canon and the Konica Minolta MFDs.

We exhausted all of our technical resources and ultimately had them have to pick two. They chose the first two and after all the work we did decided to keep the KMs  on the Equitrac System until they got to the point that they wanted to replace them with Canons. At that point we would move them over to UniFLOW. And when the last KM MFD was replaced they would decommission their Equitrac Server. I know that we proposed this months and months ago but Customers want it all, and to tell you the truth I want to give them it all, whenever possible. But sometimes technology has limitations. I am not sure why this customer didn’t kick us out, except to say I think they were REALLY unhappy with their current Vendor. It took us finally saying “no” we can only do two of the three requirements to get them to say OK. We can live with that. So we did a nine month trial and we won the deal. This felt like a bare knuckle 15 round fight. When we hit the road blocks that we were not able to completely overcome my very Seasons Sales Person was beside herself, and not happy with me because it had never happened before. But when all was said and done and we won the deal she understood just how difficult the technical requirements were to meet. I think the Customer stayed with us because we demonstrated a commitment to keep working with them to give them the best possible solution that was available.  And that is what they got!

It was a tough, challenging nine month trial, but we won the deal. And somehow that makes it as I look back on all the effort it took, worth it!

That’s My $0.02

Vince McHugh

vince.mchugh@yahoo.com