The Mole #32: Technical Answers from Inside Microsoft - Moving Users, Sharing Printers, Two PDCs, Logoff, BackTalk

April 10, 2000

Editors Note The questions and answers below are from the Inside Microsoft column that appears regularly on the TechNet Web site at the following location: https://www.microsoft.com/technet/community/columns/insider/default.mspx. To find out how to submit questions of your own, see the end of this article or go to https://www.microsoft.com/technet/community/columns/insider/default.mspx.

The TechNet Mole provides expert answers from deep within Microsoft to questions from IT professionals. This installment focuses on these issues:

  • Moving a multitude of users

  • Sharing printers: Cross platform, cross OS

  • Two PDCs, or smoke and mirrors?

  • Forcing Logoff, or, Make those teachers behave

  • Backtalk! Revisiting the InterOrg utility

On This Page

Moving a multitude of users

Sharing printers: Cross platform, cross OS

Two PDCs, or smoke and mirrors?

Forcing Logoff, or, Make those teachers behave

Backtalk: Revisiting the InterOrg utility

Credits

Moving a multitude of users

Dear Mole,

On my stand Alone Server Based on Windows NT 4.0 Server I have over 400 users! Now I want copy all users on the stand-alone server to a new PDC Server. It's possible? If Yes, how?

Enrico Iozzi, System Analyst, Telcos SpA

Hi Enrico,

First of all, Enrico, run to the nearest vending machine and buy yourself your favorite workplace treat. (For Mole, that's Raisinets. But suit yourself.) Think of it as your reward for remembering to tell Mole which version of NT you're running.

As to your project, it couldn't be more possible.

The Group Copy ("Grpcpy") utility from the Windows NT Server 4.0 Resource Kit is a graphical program that runs only under Windows NT. It allows users to copy user names from an existing group to another group, within the same domain or in another domain, or on a computer running Windows NT. To use Grpcpy, you must have account operator privileges (or higher) in the affected domains.

Copy On,

Mole

Sharing printers: Cross platform, cross OS

Salutations Mole,

Could you help me on the following two points please?

  1. I have a file/print server (NT4.0 server SP4) upon which I have 7 printers shared to the network using NetPorts. The printers are primarily HP Laser Jets. I have a problem with Win95 clients printing to the LJ4000's. The printer test page from a Win95 client has no graphic in the top-left corner and the text prints off at 1 word per page! NT printing to these printers is fine. The properties page for these printers states that the printer is shared with the drivers for Win95 installed as well as the NT x86 drivers. The Win95 drivers are not installed on any other type of printer, which all are printing fine. Could you tell me how I can remove these Win95 drivers from the LJ4000's?

  2. I believe I need to install a service called Lpdsvc to be able to allow UNIX clients to print to these LJ4000's via this print server, but I can find no details about this service. I have installed TCP/IP printing and created the share-name etc. and can print from a remote client using the \\IP_address\Printer_Name notation successfully, but still cannot print from the UNIX client. The file does not leave the queue. The NT help file details this service as a requirement for UNIX printing.

Many thanks in anticipation, Oh Great One!!!!

Gary Wells, Assistant IT Manager

Gary,

Mole thanks you for providing the version of NT as well as the service pack you're dealing with. Makes all the difference.

Check out the Knowledge Base article **154291:**Installing Cross Platform Print Drivers in Windows NT 4.0. You'll find a description of how to add or change the printer driver for a print device, including drivers for Win95 clients. Then, locate a Win95 machine that has drivers that you know print well. If you don't have any of those drivers, go to HP's printer support Web site (https://www.microsoft.com/technet/archive/community/columns/inside/techan32.mspx?mfr=true) and download the appropriate drivers for your specific HP printer model and use those.

Your second question gives Mole the opportunity to fill in a little background on printing to an NT print server from Unix clients for those of you who don't live and breathe the subject. If Unix clients expect to print to an NT print server they have to have TCP/IP installed on the print server. Then the TCP/IP Printing service can be activated through the Services tab of the Network Control Panel applet (details below.)

And that brings Mole to LPDSVC. No, that's not Mole clearing his throat. LPDSVC stands for Line Printer Daemon Service, and you'll find it listed as "TCP/IP Print Server" in Control Panel Services. It is the Windows NT server side of TCP/IP printing for UNIX clients. This service must be running on the NT print server computer or print jobs from Unix clients will not be accepted. LPDSVC supports any print format, including plain text. It does not perform any additional processing. "LPD", in and of itself, is a protocol widely used on UNIX networks and the Internet for communicating between line printer daemons.

In addition to LPDSVC, other print programs defined in **124734:**Text of RFC1179 Standard for Windows NT TCP/IP Printing are "LPR" and "LPQ". They are both supported in Windows 3.5 and up.

LPR and LPQ Overview:

LPR (line printer remote) is used to print a file to a host running an LPD server.

Although LPR clients are often UNIX-based, LPR software exists for most operating systems, including Windows NT. The Windows NT TCP/IP Print Server (LPD) receives jobs from LPR clients and submits them to the spooler. LPR clients always send a control file containing administrative information with each print job. The Windows NT LPD service assigns a datatype based on the control file commands. If the client sends the "f", "o", or "p" control command, LPD assigns the job the TEXT datatype. Otherwise, LPD assigns the print job the RAW datatype.

The control commands are documented in the LPR specification, RFC1179, in sections 7.17 through 7.29. (The text of RFC1179 is available in the Windows NT Knowledgebase.)

Because the LPD service assigns a datatype explicitly, the Print Manager default datatype has no effect on print jobs that arrive via LPD. To change the LPD service behavior, reconfigure the LPR client to send a different control command.

LPQ (line printer queue) is used to obtain the status of a print queue on a host running the LPD server.

So much for the background info—now on to the earthworms, err meat.

How to set up an NT print server so Unix clients can to print:

  • From Control Panel, open the Network applet and click on the Services tab. Click the "Add…" button and then click on "Microsoft TCP/IP Printing" in the Network Service window. Then click OK:

    Dd316464.netserv(en-us,TechNet.10).gif

  • Click OK all the way out of the Control Panel Network applet.

  • Next, add the Printer. Open up the Printers applet by selecting Start, then Printers. Double-click the "Add Printer" icon and then click the "Add Port…" button. This is what you'll see:

printpor

Either double-click on "LPR Port" or click the "New Port…" button, which brings up the following dialog box:

Dd316464.addlpr(en-us,TechNet.10).gif

The "Name or address of server providing lpd:" text box specifies the unique IP identifier of the host where the printer is connected. Type a DNS name or IP address. A direct-connect printer has its own IP identifier.

In the "Name of printer or print queue on that server" dialog box, enter the printer queue name and then click the OK button.

Once you have added the TCP/IP Printing service and added the printer device, go to Starting and Stopping the LPDSVC service.

To start/stop or configure the startup options for the LPDSVC service on a computer running Windows NT:

  1. Double-click Services in Control Panel.

  2. Under Service, click TCP/IP Print Server.

  3. Click the "Startup…" button to configure how the service starts (Manual or Automatic) or

  4. Click Start to start the service

Printing from Unix Client to NT Print Server

To have a UNIX system send a print job to the NT TCP/IP Print Server, enter the following command:

lpr –S <NTServerName> -P <PrinterNameonNTServer> myfile.txt 

Note that the switches used on lpr and lpq are case sensitive – they must always be in upper case.

Some Problems that can be encountered when printing to an NT printer server from a Unix client:

Taken from Knowledge Base article **132460:**Troubleshooting Windows NT Print Server Alteration of Print Jobs.

When you send a job from a line printer remote (LPR) client, one of the following happens:

  • Printer-language code (Printer Control Language [PCL] or PostScript code) is printed.

  • Extended characters in text print jobs print incorrectly.

  • Text jobs print in the print device factory-default font, even if you change the print device default font.

This problem occurs when the LPR client sends commands to the Windows NT TCP/IP Print Server (usually called LPD, after the UNIX term Line Printer Daemon) that responds by assigning the print job the TEXT datatype.

To work around this problem, reconfigure the LPR client to send different commands so that Windows NT assigns the job the RAW datatype.

If you still encounter difficulties printing, don't forget to look in NT's System Log in Event Viewer for LPDSVC related errors. Also, Mole suggests that you don't forget to consult the Knowledge Base and use a query like:

LPD printing

Finally, in case of acute frustration at any point in the troubleshooting process, Mole recommends the virtues of deep breathing. IT professionals who master this relaxation technique live longer, with more hair, than those who let the daemons get them down.

In a philosophical mode,

Yours, Mole

More Sources:

  • 154291: Installing Cross Platform Print Drivers in Windows NT 4.0

  • 132460: Troubleshooting Windows NT Print Server Alteration of Print Jobs

Two PDCs, or smoke and mirrors?

Dear Mole,

I am a LAN Administrator at BigCompany, Inc. and we have three Windows NT 4.0 Servers. My predecessor configured two of the servers as PDCs (yeah, both of them). However, our future setup will require only one PDC. I tried to convert one of them to BDC but it is disabled in the menu. Is it possible to convert it without reformatting the hard disks (Raid 5)? Otherwise, our operation will be disrupted for a great deal of time and change my hero image to villain.

Lito Barcena

Lito,

It's a good thing that this "predecessor" is just that because guess what? You just can't have two servers configured as Primary Domain Controllers in the same domain. There's something else going on, some sort of smoke and mirrors thing that gives the illusion of two PDCs. Very similar domain names come to mind. Here's the step by step.

You install NT on Server 1, specify that its role is PDC, and name the domain something like "MyDomain". Once the PDC is up and running, you create a computer account for the next machine (which will normally be a BDC). Then, you plug the network cable of the second machine's network card into the network and install Windows NT. During the setup process, you specify the role this second machine will assume, its computer name (the same as the computer account you created on the PDC), and also what domain it joins.

Had you selected PDC as the role for this second machine and specified the same domain name as the first computer, you'd get a pretty serious error message telling you that there's already a PDC out there. Then you'd have to click each and every one of those Back buttons to return to square one and choose a different role. Heroes can't spend their time doing stuff like that that, Lito.

In all NT networks, there is only one PDC per domain – one rooster in the henhouse, as it were. You're going to have to deal with this "second PDC". And here's another rule: You can't "convert" a PDC to a BDC without re-installing Windows NT. Mole thinks you should create a new computer account for your new BDC on the "real" PDC, and then re-install NT on that new BDC. Not to worry about reformatting the drives – you don't have to do that if you don't want to. During setup, you should probably select "Install a fresh copy of Windows NT", and then after specifying which drive to install NT on to, choose the "Leave the current file system intact (no changes)" option.

Please note that if you reinstall NT, you'll also have to reinstall any applications you've been running on the machine newly anointed BDC.

Please take this bit of Mole's advice to heart: Before reinstalling NT on the second machine, run a backup. Then, test the backup by doing a test restore. This way, you'll still be a hero, even if something nasty happens during the reinstallation.

One last thing, there's a lot of Windows NT 4.0 foundation and training information to look at. Go to the IT Training & Certification Web site (https://www.microsoft.com/learning/). Also, there's all that content under the "Index" tab on the TechNet home page.

Best regards,

Mole

Forcing Logoff, or, Make those teachers behave

Dear Mole

I work for an educational institution where teacher's access shared NT workstations. Our parent organization has requested that we implement a password protected corporate screensaver. This is causing us headaches because teachers go off to class without logging off. As a consequence, their colleagues cannot access the shared workstations unless an administrator is available to log off the previous user - losing any unsaved work in the process. We would like to be able to grant this "log off" right to certain staff without giving them full admin privileges. Any ideas on how we can solve our problem??

Bob Claridge , Regional IT Support, The British Council, Dubai

Bob,

Mole suggests assigning detention for naughty teachers who fail to log off, which might help them mend their ways, but probably won't help you. So how about trying some third-party administration tools? Check out Beverly Hills Software (https://www.bhs.com/). The BHS web page has a download center with an extensive list of 3rd party utilities, some shareware, some free. Click on Downloads, Administrator Tools, Remote Administration links.

Another good site to check out is Sunbelt Software (https://www.sunbelt-software.com/index.asp). They've got a ton of tools.

Closer to home, there's a screensaver utility called WINEXIT in the Windows NT 4.0 Server Resource Kit.

WINEXIT is a screen saver that logs the current user off after the specified time has elapsed. Like all other screen savers, it can be configured through the Control Panel by selecting Desktop. Set the Delay value to a desired time to activate the screen saver. When the Delay time elapses WinExit pops up a dialog box displaying the countdown timer and a user-defined message. The logoff process is initiated when the countdown timer reaches zero. During the countdown, you can abort the logoff process by either moving the mouse over the dialog box or pressing any key on the keyboard.

But there is a problem with the WINEXIT screen saver... It's documented in Knowledge Base article **156677:**Logoff Screen Saver Does Not Function in Windows NT.

In order for non-administrators to be able to use WINEXIT, you must add Set Value and Create Subkey permissions for the group Everyone on the following registry key:

HKEY_Local_Machine \Software \Microsoft \Windows NT\CurrentVersion 

Mole suggests you consider how big an impact this would be to modify the registries. Think hard about whether you want to modify the registries. You may decide it's not worth it. Hope this helps.

Regards,

Mole

Backtalk: Revisiting the InterOrg utility

Mole,

I had the same problem with the InterOrg utility under Exchange Server 5.5 SP3 (documented in the November 22nd Mole column).

The solution was simple enough (and odd):

I had to remove the Exchange Server service account 'User' permissions from the requestor mailbox. It seems that if you associate the requestor mailbox with the service account under the 'General' tab in Admin.exe, the service account can't logon to the mailbox. Removing it poses no problem as it has the 'Service Account Admin' permissions that include 'Mailbox Owner' - so it can actually logon to it without the extra 'User' permission, but it can't do so when it is set! After doing these modifications, it works beautifully!

Alexander Fichman

Credits

Mole thanks Lon Collins and Greg Roberts.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.