Despool Services for Print Wizard

Introduction

A "service", as defined for Print Wizard, is Print Wizard waiting for a print job to appear, running in the background and processing print requests. Print Wizard supports several types of services that can be ran by two different methods.

Types of services

Despool	Despool print jobs from a local or network shared directory. This may also include despooling files by wildcard or exact file name.
FtpDespool	Despool print jobs from a remote FTP directory (this normally will require a login and password and remote access to the FTP server. Also wildcard or exact file names maybe used.
Listen	Listen on a specific network port for a remote application to send a print job (by default this is port 9100 and the protocol is similar to the HP Jetdirect protocol.
LPD	Utilize the LPD / LPR protocol common to most Windows and Linux/UNIX systems to receive and manage print jobs.

Methods for running services

Print Wizard Service	Print Wizard Services are controlled by the user and or in the user's Startup folder. In this case a user must be logged into the Windows machine for the service to run.
Windows Service for Print Wizard	Whenever Windows starts up, so do Windows services. A standard Windows service runs regardless of if a user is logged in and runs under a specific, restricted user called "Local System".

This document is a discussion of the "despool" service, how it works and what to watch out for. If you are interested in services in general, please see the knowledgebase article on Windows Services for Print Wizard.

Setting up a despool service

Through the User Interface program for Print Wizard, you can set up a Service for Print Wizard under the Tools menu. Select Setup services.

You first "add" a service and then you edit its properties to determine the settings and parameters to be used when the service runs.

Services should not have a name with embedded spaces or special characters in order to work correctly under most versions of Windows Services.

Add a service

Add a service by name through the Setup Services menu option under the Tools menu. The name cannot contain any special characters or spaces and must not duplicate any Windows service name already in use.

Edit service properties

Select the "despool" service type. If you plan on running this as a Windows service, you can select the Windows startup type (to have your service start every time Windows does, set this to "automatic" and then use the Windows Service Wizard to install and start your service).

Set the Options and the Printing necessary for your specific service.

Only select a print profile if you are using print profiles to provide additional printer control for specific job types.

 

For Print Wizard to despool correctly, you need to select the directory / folder for Print Wizard to watch. This folder is where print files will be dropped and can be a full directory name or a directory name with a wildcard file parameter. This can also list multiple file names and locations in the same line, separate them with commas. Some examples are:

c:\temp\despool\

c:\temp\despool\*.txt

c:\temp\despool\inv-files\*.txt,c:\temp\despool\po-files\*.pwml

"c:\My Despool\",c:\temp\testfiles\*.pwml

How it works

You either start the despool service as a Print Wizard Service or as a Windows Service. When you run as a Print Wizard Service, you are running under the current user and with the current user's rights and permissions. But in order to run this way, you have to be logged into the Windows machine, even if the Print Wizard Service is setup to run from your Startup folder.

As a Windows Service, the service can be set to always be running (as long as Windows is up). In this case, you are not logged in, no group and user policies may be in affect and the service is usually run under a limited or restricted user.

We recommend making sure the service works first as a Print Wizard Service. If that works, then test it fully under the Windows Services before going live. There are many more security issues to worry about with Windows Services than there are for non-Windows Services (especially on Windows 2008 or Windows Vista).

When Print Wizard despool service is running, it is notified of any file dropped into that directory (or if a file exists when the service is started), and if that file matches the "Directory" or wildcard settings, the despool service starts processing that file. It first copies that file immediately to another location and removes it from the default despool location (so no other despool process may pick it up again).

The "Temporary Directory" found in the Properties is where these temporary files are copied to. If left blank, the user's temporary Windows directory will be used.

Once the file is moved, the Print Wizard engine is given the file to print, email, fax, generate a PDF of, or to pass on to another script or application.

If the process is one that Print Wizard handles, the file is processed and then deleted from this temporary location as well. If the file is handed off to a script or another application, removal of this temporary file becomes the responsibility of the handler.

The file dropped into this directory can be any file which Print Wizard can handle. If the file cannot be handled directly through Print Wizard or the Print Wizard Smart Print options, then the file can only be passed to another script or application and is left behind for that process to handle.

Determining what to do with the file is controlled by the Service settings and the Print Profile selected in the Properties. If no profile is selected, the job is assumed to need to be printed. Otherwise you can specify, for this service, the action to perform through Print Profiles (faxing, emailing, PDF generation, or even run through your own custom script).

Some Gotcha's and Hints

There are several items with despooling to be aware of, both when running as a Print Wizard Service and when running as a Windows Service. The hints below should be reviewed before running your service.

Printers

If no printer name is selected for the service, the Windows default printer will be used. You can select a specific printer for the service or let it default to the user's default printer through the Properties dialog.

If you are planning on running this service as a Windows Service, be sure to select a printer. Letting it "Default" may cause problems as the default printer for the user "Local System" could be different than the default printer for the user you are currently logged in as. Also make sure that the particular printer you select is available to ALL users of this PC so that "Local System" can see this printer.

Windows Services security

When working with Windows Services, it is important to keep in mind whether the despool service is running with the default user (usually "Local System") or if you have assigned it to a specific user. Depending on this setting and the version of Windows you are running on, access to email, faxing, specific directories and even specific printers may be very limited and cause problems.

Always test the service first as a Print Wizard Service to make sure it is set up correctly and then re-test it as a Windows Service to make sure you have not overlooked some security issue.

Directory names

The directory or wildcard name you are watching with the despool service is where most of the differences lie between Windows Services and Print Wizard Services.

It is not uncommon for a Print Wizard Service for despool to work, but the Windows Service to fail, especially if you have not considered the security and user in which you are logged in as when the service runs.

As a Print Wizard Service, you may want to despool from a network drive or SMB ("samba") share. However, if these are "mapped" drives (mapped to a drive letter rather than being a local drive), that drive may not be available when running as a Windows Service. Here is an example:

A customer setup includes a directory of z:\pwdespool\ to despool from. However, z:\ actually resides on a different machine, a Linux shared network drive running SMB. Print Wizard Despool works fine as a Print Wizard Service.

However, when she runs the despool service as a Windows Service, it fails. This is because no login script runs that maps the drive properly to z:\.

For a Windows Service, she needs to set the despool service to point to the share or network name, also known as the UNC, for that drive, i.e. \\MYLINUX\pwdespool\.

Knowing when a file is available to process

Print Wizard's despool service is notified by Windows whenever a new file exists in the despool directory. Print Wizard can then grab that file and start processing it.

A problem can exist if the application dropping the file into a directory, or some copy statement, creates the file first by doing an open and close and re-open. When this happens, Print Wizard can receive a notification that a new file exists even when the application or the copy is not done writing to it.

Likewise, if an application writes some data to a file, closes it and the re-opens it later to append data to it, we can get a notification before the file is completed.

We do attempt to make sure we have full rights to the file before we process it, but this is not always something that works. To do this, we first make sure the file is greater than zero in size. We then make sure we can open the file exclusively. We then process the file.

A good practice if you do have problems with missing data or with files being pulled before complete, is to generate the file elsewhere and then, once complete, copy that file into the despool directory.

User names, group policies, user policies

Of course, the one recourse the user above could have tried was running the Windows Service under the same user name she was logged into before for the Print Wizard Service. However, even this will probably fail to work - when a Windows Service runs under a specified user, the running application does not go through a full log in sequence and hence the drive is still not available.

If you are running in a corporate domain environment, much of this can be controlled by the corporate policies. Both group and user policies can control how services run, can control what drives are available to users and even whether a specific share is available to users. If in doubt, always consult your system or network administrator.

One exception to the above, if a user's group or user policies does not allow access to a share name, then the user policies may prevent a Print Wizard Service from calling a share name. It is possible through policies to set up a user such that when running as a Print Wizard Service, the service may need to be set for a mapped drive, but when running as a Windows Service, the share name has to be used.

Other targets

Email

If your target is to email, you need to think through the process and see if a Windows Service will have access to the correct program and/or protocol. If you are running email through Outlook, the user a Windows Service runs as may not be able to access the Outlook object. If Outlook or Office was installed as a specific user and not as Administrator, Outlook and its email objects, may not be available to the "Local System" user.

If you have firewall policies in place or you are running a local, personal firewall, emails also may be prevented from being accessed. A user policy or user setting may allow Print Wizard to email, but the firewall settings for "Local System" that the service runs as may not have outbound access for the email port.

Fax

Faxing has many of the same issues as printing (such as whether a printer or fax is even available to a Windows Service). Add to this that the Windows Service may also not have permissions to fax even if it sees the fax printer, and things can quickly get more complicated.

Microsoft Small Business Servers set up their fax printer and driver as a true Fax Server. In this case, a Windows Service will most likely NOT have permissions to control or fax directly. In the case of running on an SBS server, you will probably have to always include the UNC name of the shared fax server in your fax setup inside Print Wizard, even if Print Wizard is running locally, and regardless of if you are running as a Windows Service or a Print Wizard Service.

Email, fax, PDF, TIFF and other outputs to file

Emailing data, faxing data, generating a PDF or TIF or printing to a file may all be headaches if you do not know the limitations or the accessibility of the user you are running under. In the case of the default for a Windows Service, the user "Local System" may not have write access to anything but Windows "temp". Know where files are going and what the likelihood of running into permissions means.

Even fax and email generate temporary files and they need to go somewhere accessible to the user that Print Wizard runs as. Fax cover page files or email include files, all have to be accessible to the user.

When emailing or faxing attachments, the same holds true - be sure that the user running Print Wizard has access to all files necessary. However, there is one other consideration here. If you are faxing attachments, not only do you need access to the files you are attaching, but you need access to the fax driver, the applications that render the attachment to a TIFF for faxing and then to the despool area for the fax server or fax printer driver.

SMB and network shares

SMB (aka "samba") and network shares are a bit harder to understand and debug in many cases.

• First, you should always use the network share or UNC name.
• Second, if files already exist in the directory when the despool service starts, the files need to be readable and writeable by the user that Print Wizard is running as in order to be picked up when the service starts.
• Lastly, files dropped into a despool directory may not have permissions for read/write or may not even be exposed to the share (due to an application's ownership). In order for Print Wizard to pick them up, they must be available to the user Print Wizard is running as and have read/write permissions for that user.

As with any file, knowing when a file can be despooled can be difficult. If your application is not done writing to the file, yet the file exists, this can be a problem. In most cases, this is a problem on network shares. When a file is created by Linux or UNIX, the file exists immediately and may or may not have a size. Unfortunately if it has a size, we pick it up.

A good practice for any network share is to generate the file outside the share and then drop the file into the share or despool directory with a copy statement of some type. In this manner, you should be guaranteed writing to the file is complete.

What to do next

If you do run into problems, always consider what your access is like and the service method you are running as. Talk it over with your PC and domain administrators, they will most likely know exactly what the problem is.

If all else fails, give us a call. We have probably come across most everything with despool services.