Test Center Rx

SAN MATEO (04/24/2000) - My problem has to do with printing. We recently upgraded all of our workstations to new Pentium III systems running Windows NT Workstation. One of our print-queues is on a Novell Inc. NetWare box. Whenever anyone prints to this queue, a banner page prints. Now, I have gone into Client Services for NetWare [CSNW] under Print Options and made sure the box for Print Banner Page is unchecked under every user, but I still get this banner page.

What am I doing wrong? Is there a registry setting somewhere I have to use? Do I have to edit a value? I checked the printer's setting (on our HP LaserJet 4S) at the printer's control panel but without success. Please advise before we run out of trees.

Tony Brooks

Lori:According to Microsoft officials, print banners are set on by default. To turn them off, you will indeed need to change the CSNW setting. This change should fix the problem; however, you may also need to make some additional changes. It sounds as though you have made the appropriate changes on all the clients through CSNW, but you may want to check the NetWare server as well.

By using Novell's Printcon (print configuration) you can set defaults for your printer, including whether to print banners. You should verify that this is set correctly, as this should eliminate the unwanted banner pages. PConsole (print console) can also set the banner settings for printing, but I believe that it is on a per-job basis.

Brooks: This is the infamous "print banner no matter what the client settings are" problem that everyone encounters when printing to a NetWare print server from an NT workstation. The only way I know to be absolutely sure that banners go away is to install NetWare's client software for NT, which seems to offer more reliable control of this setting.

The NetWare client will give you better integration with your Novell network in general -- and especially with NDS -- if you've implemented it. On the downside, the NetWare client seems a bit buggier than the Microsoft client, probably in part because it integrates with more of the NT OS.

Not everyone can install a new network client on a workstation. If that is not an option, I would try the Printcon approach.

NACK attack

Lori: In our April 3 column, "Swapping DHCP servers fools domain controller into telling the clients that no one is home", we dealt with a sticky Dynamic Host Configuration Protocol trouble that caused the server to send the clients a NACK (negative acknowledgement) message. Reader Andrew Tompkins, CTO at the management council of the Ohio Education Computer Network, in Canton, Ohio, offers his experience.

"I ran into a similar situation last summer that drove me absolutely nuts," Tompkins writes. "Like your reader, Ed, I was moving my DHCP server to a new Windows NT Server machine. Being conservative, I created an identical scope on the new server and deactivated the scope on the original. And, just like Ed, my clients were getting a NACK rather than an address. I went through everything I could find, including upgrading to Service Pack 5 and applying any patches I could find, all with no luck. And as you suggested, I plugged in the Sniffer and went to work.

"Note that I did not turn off the DHCP service on the original server; I just deactivated the scope. When this server saw the DHCP request against a deactivated scope, it sent its NACK. Seems a server can send a NACK faster than other servers can send an address -- probably because there isn't any database activity needed for a NACK. So every time the client asked for an address, it would get a NACK from the original server before it got an address from the active server. This would happen in a request/NACK loop until the client reached its limit for asking, then it returned, 'DHCP server unavailable.'

"The solution was quite simple: I just turned off the DHCP service in the services control panel on the original server and, voila -- I started getting addresses from the new server! I hope this helps."

Brooks Talley is senior business and technology architect for InfoWorld.com.

Lori Mitchell is a senior analyst in the Test Center. Send your questions for them to testcenter_rx@infoworld.com.

Join the newsletter!

Error: Please check your email address.

More about MicrosoftNDSNovell

Show Comments