| Another point... NONE of these errors are logged in the boot hosts
lpslog.nodename files.
With so many machines affected it seems clear that this is caused
by something as yet not determined that is outside the printservers.
Either a) envioromental b) something from the network.
My guess is the network, With .o on another continent it would strech
the imagination just a bit to blame power/atmospheric conditions.
The network: From the groundwork I have covered I can only find 2
changes that seem posibly related. A) the widespread introduction of NT
on my site with recent addition of NT servers doing QUEUE serving to
the PC envioroment. B) We have on our site a Vendor whose task is to
install new PC's to users desks pre-configured. This is done by using a
pre-built CD and copying its contents wholesale to the new m/ch's C
drive and then booting. When this build boots for the very first time
the network on site is polled and a TCPip address is obtained for the
PC. and so on. Why do I say all this, well this build disk was
modified only a few weeks ago to allow for the use on IBM thinkpad
laptops. Since then a series of problems occurred on several Kycera
(sorry about the spelling) printservers. These where found to fail
after they somehow inherited the build disks IP address, all of them at
the same time!!
Watching the build event in progress we find that one of the LPS20/32
m/ch's here on site somewhere (50% of the time) fails as described. I
plan to put a network sniffer in the path of the next few m/ch's being
built to see i we can find anything. We may be lucky, but its by no
means certain.
If anybody has any ideas / pointers I would be glad to hear, so I am
sure would .0
Alan Brodie
|