Despite our best efforts, sometimes new network configurations can become confusing to users and, yes, techs alike -- though we don't like to admit it.
We recently upgraded our systems and last week had a problem involving printing from a remote site that the user had connected to through a terminal server. A system like this functions by a local user logging onto a server in their building that then is granted access to another network at a remote location. Once the user is connected they can run applications installed at that site.
Generally, running the application isn't enough and the users wish to print reports generated at the remote site to a printer in their location. It's not a complicated task, but there are a few factors to keep in mind when working remotely. This is where the problem arose.
So many choices
One of our users logged into a remote site and generated a massive report (more than 3,200 pages) that she needed to turn in to a third party. She had intended to send the report to a PDF file to save paper, but somehow the report directed itself to her printer on her desk all by itself! (Of course, it's a common complaint when a user doesn't notice the printer location setting.)
Needless to say, the printer soon displayed an error alert on her PC and stopped printing. She was tired, and it was the end of the day, so she decided to leave it alone and left for the night.
Morning arrived, and the user told a tech only part of the problem -- the report had stopped printing. The tech started with the basics: The printer was out of paper, so they reloaded it, and voila, it commenced printing again. At that time -- and only then -- did the user inform the tech that the report is no longer necessary, so stop the printer from printing.
The tech logs onto the local file and print server and deletes the job, then unplugs the printer to clear anything left in memory. Reloading the paper into the printer he then turns it back on and starts to walk away. Amazingly, the printer resumes printing. We are now approaching 300 pages!
The job is again deleted and verified it is gone. Print spooler on the server is restarted to clear it and the printer unplugged, reloaded with paper, and restarted again. Here we go again with the job resuming! Is this thing possessed?
Oh, that setting
The tech powers the printer off and commences further investigation. It is then revealed that the print job is coming from the remote site and not a local application. Of course! It all makes sense now.
A report is generated at a remote site, and when it is told to print locally, it first gets queued to the remote file and print server. Once it has the job in its memory it passes it to the local file and print server. Thus every time it was killed locally, the remote site could see it was not completed and passed another copy to reprint. The system was working perfectly; we had missed an important point.
It was a good lesson to get all the facts before attempting to solve a problem -- a lesson that will not soon be forgotten. By the way, there is now a stack of more than 500 pages of scratch paper in the print room.