\[Editor's Note: Share your Windows 2000 and Windows NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows 2000 Magazine readers (including Microsoft). Email your contributions (400 words or less) to firstname.lastname@example.org. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
Blat is a public-domain tool that you can use to send a file as SMTP email from the command line through TCP/IP (e.g., to Microsoft Exchange Server). The utility is useful for creating scripts to automatically send email to users to notify the users about successful or unsuccessful execution (e.g., backups). For more information about Blat and to download a copy for Intel- or Alpha-based Windows NT computers, go to http://www.interlog.com/~tcharron/blat.html. The tool is simple to use and comes with good documentation, including examples. Blat's syntax is
blat <filename> -t <recipient></recipient></filename>
The README file includes optional switches.
Windows NT administrators usually need to log on from their machines under another account to check accounts' rights and permissions if users are having problems accessing resources. In addition, some administrators must log on with limited administrative permissions to send email messages and create documents but log on with full administrative permissions to create users and set permissions. I discovered a useful Microsoft Windows NT Server 4.0 Resource Kit tool called su.exe that lets an administrator start a new process from an NT workstation under a different account without logging off and logging on again with new account credentials.
To use su.exe, you must first install the SU service. On the workstation, enter the command
You can then run su.exe to start a new process under another account context. For example, I use this utility while I'm logged on under my name to start Microsoft Exchange Administrator or User Manager for Domains under an administrator context to perform administration tasks without closing my applications and logging off.
If you run the command without a parameter, you'll see a GUI for all the required parameters (i.e., username, command, and domain name). To start an application under an administrator context, enter
su.exe Administrator <command><domain name></domain></command>
I've modified the Exchange Administrator, User Manager, and Server Manager shortcuts on my desktop to include this command, replacing the command parameter with the application's executable file. When I click one of those shortcuts, I receive a prompt for my administrator password. Then, the application starts under an administrator context.
In answer to Kevin Zhou's question in the May 1999 Letters to the Editor about sending messages to Windows NT and Windows 95 users, an inexpensive shareware program called Awesome Popup (Apopup) lets you accomplish this task. Because the program doesn't run in an open window, users can't see the program except when they receive messages. Thus, users won't close the program as they do Winpopup. You can download Apopup at http://www.andtechnologies.com/apopupFeatures.html.
Forwarding Print Jobs
Setting up a Windows NT server to forward print jobs from its shared printer to another printer doesn't work. After the client submits the print job, the job stalls at the first server because the first server uses a null session to pass the job to the second server. By default, NT doesn't accept null session print requests.
To solve this problem, edit the Registry on the second NT server and add the share name of the printer you want to accept null session print requests. Start regedt32, and go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\LanmanServer\Parameters Registry entry. Then, add a line with the printer's share name. After the spooler service starts and stops, the server will accept null session print jobs.
I have two modem tips that I've used on my servers and want to share. First, to configure your modem to answer after several rings, edit the modem.inf file in the \%systemroot%\system32\ras directory and change the parameter COMMAND_LISTEN=ATS0=1 to COMMAND_LISTEN=ATS0=number of rings (e.g., COMMAND_LISTEN=ATS0=4 for four rings). For Telephony API (TAPI)- or unimodem-based units, start regedit and go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\RasMan\Parameters Registry entry. Select Edit, New, DWORD Value to create a new parameter. Name the parameter NumberOfRings. Then, double-click the parameter and enter the number of rings you want. Finally, click OK and close the Registry editor.
Second, to enhance the performance of your modem dial-up connection to the Internet, eliminate fragmentation on the Maximum Transmission Unit (MTU) to the remote host. To accomplish this task, you must force Windows NT to discover the MTU's maximum packet value. Then, you can eliminate fragmentation if the value is small. Start regedit, and go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetServices\Tcpip\Parameters Registry entry. Select Edit, New, DWORD Value to create a new parameter. Name the parameter EnablePMTUDiscovery. Then, double-click the parameter and enter a value of 1. This value forces your modem to use 576 bytes for the MTU for all connections that aren't in the local subnet. Finally, close the Registry editor and restart the computer.
Manage Services Remotely
I use a simple script, which Listing 1 shows an example of, to manage services on a remote machine. You can use this script to restart a service, as in my example, or to use the other options that Netsvc provides.
To start the script, type
where username is a user whose account can manage services (e.g., an administrator), IPaddress is the address of the machine that you want to manage remotely, password is the user's password, and service is the service's name.
Hiding a Workstation
The sidebar "Optimizing Your Browser Service" in Sean Daily's article "NT Workstation Tune-Up" (July 1999) documented the net config server /hidden:yes command for hiding your Windows NT workstation from the browse lists. I discovered a situation in which the workstation still shows up when you use this method. If your workstation is a member of a domain that doesn't exist on the network you're connected to (which might occur if you consult at multiple customer sites), your workstation and the workstation's domain will show up in the browse list. To solve this problem, put your workstation in a workgroup and make the workgroup name the same as the name of an existing domain on the network you're connected to. However, this solution won't work if you must retain your domain's security settings.
Security is an important topic for systems administrators, and the number of quality security applications is steadily increasing. But before you invest in expensive security tools, you need to take full advantage of the security configurations on your Windows NT servers and workstations. In my past 2 years of experience with NT implementations, I've discovered that many companies make considerable investments in security tools and utilities but leave their NT security configurations open to users who can easily abuse the system. Security administrators and managers must ensure that their NT systems' base settings provide hardened security before they commit financial resources to additional tools. Then, administrators can use security tools and utilities to enhance, configure, and confirm the status of their NT implementations.
Users in my company recently reported trouble logging on. One user had experienced several failed logon attempts to her Windows NT 4.0 Service Pack 3 (SP3) machine. Other users were unable to load their profiles and had to use the default system profile.
The application event log showed the well-known event ID 1000 (userenv error). The system event log recorded an event ID 12288 from the SAM, saying the SAM was unable to write changes to its database.
I ensured that enough disk space existed and that the Registry and pagefile maximum sizes were adequate, but the SP3 user still couldn't log on. I consulted the Microsoft article "Restoring a User Profile On a Windows NT Workstation or Server" (http://support.microsoft.com/support/kb/articles/q171/7/69.asp). According to the article, overwritten SAM and security information causes the problem. I removed the user's machine and added it to the domain again. The user was finally able to log on to her machine.
Use KiXtart to Write Logon Scripts
As a Windows NT consultant, I often must write logon scripts. The best tool I've found for writing these scripts is the Microsoft Windows NT Server 4.0 Resource Kit's kix32.exe tool (KiXtart). This tool isn't well known, and few articles about it exist. Perl is a more powerful tool than KiXtart, but most network administrators don't have experience programming or writing scripts. KiXtart is easy to use and powerful enough for most scripts.
I'm working on a migration project in which I'm regularly decommissioning servers and migrating users. I've found that using KiXtart to centralize and implement changes to the user environment is simple. Listing 2 shows a script that I've used to remove drives D to Z. Listing 3 shows a script that removes access to a drive and paths. Listing 4 shows a script that removes access to a drive and paths but changes the drive mapping based on the condition of the old mapping. Listing 5 shows a script that assigns drive mapping and printers by department. Finally, Listing 6, page 44, shows a script that changes the default printer location. I've used these scripts on NT 4.0 and NT 3.51. To use the scripts in your environment, you must replace the server names (i.e., FSxx).
Use KiXtart to Display a Logon Server
In Letters to the Editor: "Pick Users' Domain Controller" (July 1999), Jim McAllister told a reader that he could edit the Registry (directly or with poledit.exe) to display a user's logon server. In my position as a consultant, I'm using the Microsoft Windows NT Server 4.0 Resource Kit's KiXtart tool to display logon servers.
KiXtart can display a host of information, which the tool stores in variables. To display a logon server, I used the script in Listing 7, page 44.
You can also use KiXtart for other tasks. For example, the tool lets you load-balance the use of software on the network, which is handy in remote locations. To read about all the utility's variations, see the kix32.doc file in the resource kit's \kix32 folder.
Fault Tolerance on Compaq Servers
If you have a Compaq server and want to use Windows NT's Disk Administrator for fault tolerance rather than spend money on a RAID array controller, you need to be aware that Compaq puts the setup software on servers' hard disks. Having the setup software on the hard disk doesn't cause a problem if you have a RAID controller for mirroring. But in a typical installation, in which NT places the system partition on the boot drive and then establishes mirroring, you can't mirror the Compaq setup partition because NT doesn't recognize it. In addition, if the boot drive fails, you can't simply swap it with the other hard disk or use a boot disk because the second hard disk doesn't contain the setup information and the server doesn't recognize the hardware. To fix this problem, install the system partition on both hard disks before you install the OS. In the event of a failed boot drive, you can swap the good hard disk to get your system running again.
Logon Script Synchronization
Windows NT 4.0 lets you synchronize logon script and shell loading so that Windows Explorer doesn't start until the logon script finishes. To delay Windows Explorer's startup, open a Registry editor and go to the HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon Registry entry. Select RunLogonScriptSync, and change the value from 0 (the default) to 1. Close the Registry editor, log off, and log on again.
This procedure works for one user, but synchronizing logon scripts for all your users is more complicated. I recently set up a terminal server for multiple single-program users and needed to prevent the initial program from starting until the user's logon script finished mapping the data directory that the initial program used. Under HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\WindowsNT\CurrentVersion\Winlogon, I created the DWORD value RunLogonScriptSync and assigned it a value of 1. Now, when a user logs on to the server, no applications run until the logon script finishes mapping all the necessary drives.
Foolproof Service Pack Installation
I do technical support over the phone, and I have a foolproof method for installing service packs that I share with users each day. My instructions also include information about installing Compaq support software (i.e., Support Software Diskette—SSD) on a Compaq machine.
First, download the latest SSD from Compaq's Web site (http://www.compaq.com) and the latest service pack from Microsoft's Web site (http://www.microsoft.com). Then, generate a WinMSD report, which you'll use to compare services. To generate this report, click Start, Run, and enter
Select the All and Complete tabs, then select the option to print the report to a file. Open the Control Panel Services applet, turn off all the services except the six that Windows NT requires to run—i.e., Net Logon, Plug and Play, Remote Procedure Call (RPC) Locator, Remote Procedure Call (RPC) Service, Server, and Workstation. You might not be able to turn off EventLog or TCP/IP NetBIOS Helper, which is OK. Next, run the service pack with the z switch (e.g., NT40_SP4.exe z, update.exe z), which stops the automatic reboot after installation. After you install the service pack but before you reboot, run the SSD to update your Compaq drivers, such as your hal.dll. Then, reboot. Finally, use the WinMSD report to compare the services that you turned off previously and to ensure that all the services started as the report indicates.
UNC Tracking on Shortcuts
In "Managing Desktop Shortcuts" (Reader to Reader, August 1999), Jim Holt offered a solution to John Fitzpatrick's problem with a failed shortcut. I've also encountered the problem of Windows NT 4.0 Service Pack 3 (SP3) requesting a username and password with shortcuts that NT creates that contain the Uniform Naming Convention (UNC) path to the machine you originally created the shortcut on.
To solve this problem without using the Microsoft Windows 95 Resource Kit's shortcut.exe utility, simply remove the shares, including administrative shares, from the machine on which you create the shortcuts. You need to remove the share on the NT install directory (i.e., ADMIN$) and the shares on the drives where your applications reside (e.g., C$ and D$). Removing the shares prevents NT from including the UNC path to the program when you create a new shortcut.
After you remove the shares, copy the shortcuts that you create to populate the desktop and Start menu folders for mandatory user profiles. Be careful not to subsequently open or edit the shortcut properties from another machine, or you might reintroduce the UNC path into the shortcut. Finally, recreate the administrative shares if you need them.
Stopping a Shutdown in Progress
How many times have you accidentally shut down Windows NT 4.0 when you only meant to log off? This mistake is common because the radio button on the confirmation dialog box that NT displays defaults to your previous selection (i.e., to shut down, restart, or log off). If you use the keyboard instead of the mouse, pressing Enter too quickly can easily result in the wrong action. However, you can stop the action if you're quick enough.
To stop a shutdown in progress, press Ctrl+Alt+Del. The computer will then log off rather than reboot. To ensure that the shutdown stops, press Ctrl+Alt+Del three or four times, with a 0.5-second delay in between each action.
To prevent unwanted shutdowns, you can use NT's System Policy Editor (SPE) to remove the shutdown command from the Start menu. You can still press Ctrl+Alt+Del to shut down the machine. However, you'll need to use Ctrl+Alt+Del, log off, log on as Administrator, then shut down.