It started off when I saw the options under Printer driver synchronization in the Adavanced Options tab of the Spooler settings (see below) and I got curious.
I've always had problems keeping printer drivers up to date, and more importantly, keeping them all the same on a larger OS/2 network. This option looked like it might provide what I wanted. As it happens, it doesn't actually do what I thought it meant - synchronise (sorry for the spelling, but I'm English) the printer drivers in use on the workstation with those in use on a server. It actually copies over and automatically installs newer drivers for those in use on the workstation, if newer ones exist on the server.
I will explain more.
I got digging further because the help obtained by pressing F1 on the above screen was really no help at all. After wandering through various help files, I came across an intriguing mention of a program in the OS/2 Warp Desktop Guide (x:\OS2\BOOK\OS2UG.INF) - search for SETUPDRV and you will get two hits. The first tells you (roughly) how to set up the appropriate shares on a remote location that can be used as a single source to distribute printer drivers from, and the second how to use the SETUPDRV program (which if you've got interested and taken a look at the help file yourself, you will see is a REXX program). So, I looked for SETUPDRV.CMD on my Warp 4 PC. Not there. OK - maybe I didn't install it. I looked on another OS/2 PC. Not there either. And another - not there. Time to start from scratch. I dug around on a Warp Server Advanced CD - not there. What I didn't do is look on the Warp 4 CD - duh. Still - I managed to find some interesting places on the Internet whilst I was looking.
After days of looking, I couldn't even find it there, nor mention of it in Deja news or anywhere else. Are we Warp 4 users not curious enough I wonder? I started going back to basics on the Internet now. I can remember setting up a Lexmark print server in the past and looking through a README (yeah I know - I was bored) which told me how to set up the appropriate shares for printer driver installation only. So I went to the Lexmark web site and downloaded the latest MarkVision for OS/2 (a DOS .EXE self extracting file - nice one Lexmark, not) and the README.1ST has the following section:-
6.0 ENABLING OS/2 PRINTER DRIVER DOWNLOAD
FOR OS/2 CLIENTS
----------------------------------------------------------
The LAN administrator can set up a shared
print queue to allow OS/2
clients running Warp Server to automatically
download required printer
drivers from a common place. This is
useful when the print server is
using a printer driver that is not yet installed
on the client. When
the client creates a network printer object
referencing the print
servers shared print queue, the printer object
will first check to see
if the required printer driver has already
been installed on the client.
If the driver is not installed on the client,
the printer object will
look in the following places for a path to
the printer driver:
1. The spooler looks in the OS/2
system INI file for application
name PM_SPOOLER_DRVSHARE.
The keynames for this application name
are print server
names; the keyvalue is the path to the
printer drivers
that can be downloaded to clients.
If the application
name is found, the spooler uses the
keyvalue for the
print server requested or the first keyvalue if
the print server
requested is not a keyname.
The following is
an example entry for print server PRINTSRV on a
LanServer Domain.
This assumes all clients have a "net use" in
place for a drive
that contains the printer drivers.
App Name
Key Name
Key Value
---------
---------
---------
PM_SPOOLER_DRVSHARE
LS:\\PRINTSRV
X:\DRVS
2. If no PM_SPOOLER_DRVSHARE entry
exists, the print server is
checked for a directory
share named PRINTDRV.
3. If neither of the above finds
a path to the printer drivers, the
user's logon domain
"LS:\\*ALIAS" is checked for the alias name
PRINTDRV.
The path returned by one of the above methods
is used by the OS/2
printer object as follows:
1. Search the root of the path
for packed files (*.DR_).
2. Search the root of the path
for unpacked files (*.DRV).
3. Search the subdirectory OS2DRV
of the path for packed or unpacked
files.
4. Search the subdirectory PMDD_n
of the path, where n is the OS/2
printer driver diskette
number and the subdirectory contains the
OS/2 printer driver
diskette contents
For example, to share all OS/2 printer drivers,
the administrator can
create the following directories:
a) D:\DRVS
b) D:\DRVS\PMDD_1 - contains
OS2 print driver diskette 1
c) D:\DRVS\PMDD_2 - contains
OS2 print driver diskette 2
d) D:\DRVS\PMDD_3 - contains
OS2 print driver diskette 3
e) D:\DRVS\PMDD_4 - contains
OS2 print driver diskette 4
f) D:\DRVS\PMDD_5 - contains
OS2 print driver diskette 5
The administrator can then set up a shared
print queue
for users to the D:\DRVS directories.
In summary, if you copy the supplied Warp 4 printer drivers to the locations mentioned above, share it as alias PRINTDRV on your logon domain, you need never get out your Warp 4 CD again to install new printer drivers - the installation process from either a Printer template or a Network Printer template will automatically use the drivers from the PRINTDRV share. You can also create an entry in the workstation INI file to point to another location if you want. This comes in handy if you're using Peer Services only as you don't have a logon domain.
Back to the plot - reading this reminded me of the SETUPDRV.CMD program - it talks about the exact same process as above. But where was it?
Having looked at the Lexmark software, I looked for the HP Jet Direct software on the HP site and downloaded that. Lo and behold, the SETUPDRV.CMD was in there. And to save you an 8 Meg download, here's the SETUPDRV.CMD file (6113 bytes) that went 'missing'. Further investigation of this tells us that we can create multiple entries in the INI file of the workstation to prevent a Single Point of Failure for printer driver downloads.
So - to put it into practice.
SETUPDRV /? gives me this:-
Invalid Option, use the following syntax;
Usage: [drive:][path]SETUPDRV /options:parm1
parm2
/l (List PM_SPOOLER_DRVSHARE
entries on this work station)
/a:server_name driver_path
(Add entry)
/f:[drive:][path]filename
(File input of server names)
/d (Delete print_server
name(s))
I set up a share on my Warp Server box called PRINTDRV. I logged onto the Warp Server from my Warp 4 PC and didn't use the SETUPDRV.CMD at all. I created a new printer from the Printer template and the driver was automatically installed from \\servername\PRINTDRV. That's neat I thought. So I then got a newer version of the driver and copied it into the directory structure of the PRINTDRV alias, logged off my Warp 4 client and logged back on again. In about 2 minutes, my Warp 4 client had copied the new drivers down and installed them for me without me having to do anything - I even have the entries from the audit log to prove it if you want. Brilliant. I don't know how it knows that the driver is a newer one - I guess the version number is pulled from the .DRV file, but I don't know.
Will this work with an NT server? You bet it will. I tried this by using the SETUPDRV.CMD as follows:-
SETUPDRV /a:LS:\\servername X:\directoryname
This requires a drive X: to be mapped at logon, and the PMDD_x structure to be created below the directoryname above. I created a new printer again from a template and the drivers were obtained from the X:\directoryname structure. I logged off and copied newer drivers into the structure, logged on again, a couple of minutes after logon, the new files were automatically downloaded and installed for me.
And what this means is that you don't actually have to have a 'server' as such - any drive letter that is NET USEd as the same letter will do fine in a peer to peer environment for example.
The only downside I can see to all of this is that if a driver goes horribly wrong for you, it'll go horribly wrong for all your users. I tried copying the older driver back into the structure, but it wasn't downloaded. I guess this lends weight to my theory that the version number out of the .DRV is compared, but if anyone knows better, I'll be happy to correct my assumption. Moral - test the printer driver first.
Email me if you want some more information.
Version 1.0
Date 08/11/1999