\[Editor's Note: Share your NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to r2r@winntmag.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.\]
After my company migrated from Novell 3.12 to Windows NT 4.0, my boss asked me to make sure users couldn't log on to more than two computers simultaneously. If you've used Novell, you know how easy it is for an administrator to open SYSCON and select the number of simultaneous workstations an employee can access. The NT process is more complicated.
NT administrators can restrict user access to specific workstations. However, users aren't restricted to only one or two logons--they can log on to as many as eight workstations at once. As a workaround solution, I created a simple batch file (Listing 1) to let administrators control the number of simultaneous logons for a user. I used logon scripts to incorporate the Microsoft Windows NT Server 4.0 Resource Kit's logout.exe program.
To use this batch file, you must ensure that users have a shared home directory on which their share names are the same as their usernames. After you create the home directory, you must restrict the number of connections to the directory. Then, you can implement a logon batch file such as the one that Listing 1, page 24, shows.
If a user's home directory share is accepting connections, NT maps a drive (e.g., p:), and the user can log on. If the home directory share is not accepting connections, NT disconnects the user. Administrators can set the number of connections that each user's home directory permits and thus set different restrictions for each employee.
—Stephen Scharf
Sscharf1@aol.com
MORE ABOUT UPGRADING TO NT SERVER OVER SP3
In Reader to Reader, "Upgrading to NT Server over SP3" (June
1998), Tamara Dudley wrote about installing Windows NT Server over NT
Workstation 4.0 Service Pack 3 (SP3). She received the blue screen of death and had to copy the entire system32\drivers directory.
This problem commonly occurs when you install NT 4.0 over an existing NT 4.0 installation with SP3 and Remote Access Service (RAS), or when you install RAS for the first time. The NT 4.0 CD-ROM does not replace the SP3 tcpip.sys driver with the original tcpip.sys file during the reinstallation or upgrade. The Stop message that appears during the crash lists this filename.
The obvious solution is to replace the tcpip.sys file from the original NT 4.0 CD-ROM and then reapply SP3. I had some problems because I had installed NT Server on an NTFS partition. I tried upgrading the installation by installing a fresh copy in the same directory--to no avail. I also tried using the Emergency Repair Disk (ERD) to repair my NT installation, and I selected the Verify Windows NT system files and Inspect startup environment options. The repair process detected that the rasphone.hlp file was corrupt and offered to replace it. I let the system replace this file, but it didn't try to replace the tcpip.sys file. When the machine rebooted, I again saw the blue screen of death. The tcpip.sys file in my NT installation was a newer version (SP3) than the one installed, but it wasn't corrupt. Thus, the repair process failed to replace the file. I had to install a fresh copy of NT and copy the tcpip.sys file into the original installation to resolve the problem.
If your NT installation is on a FAT partition, you can copy the tcpip.sys file from another computer running NT 4.0 without Service Pack 2 (SP2) or SP3 (using DOS or Windows 95). Alternatively, you can use the Expand command (which requires Win95) to copy the file directly from the NT 4.0 CD-ROM. For more information about this problem, see the Microsoft article "'Stop 0x1E' Message Reinstalling Windows NT with SP3 and RAS" at http://support.microsoft.com/support/kb/articles/q162/2/05.asp?fr=0.
—Shailendra Shenoy
shailendra.shenoy@tatainfotech.com
As you probably know, Netscape can't print certain pages. When you try to print, you receive the message There are no pages to print. I found the following trick useful: Right-click the page, select Send Page, send the page to yourself, and use Netscape Messenger to print the page.
—Vladimir Tankhimovich
vtankhim@tdc.com
My users often have trouble figuring out Novell NetWare's Client32 logon screen. After reading Lenny Zeltser's "Modify Windows NT Script to Work with NetWare Clients" (Reader to Reader, March 1998), I was anxious to try the batch file. However, the file didn't work properly.
The Registry key name in the fifth line should have been enclosed in brackets and should have been followed by >> %tmpfile% rather than by DefaultNetWareUserName. The sixth line should have read: echo "DefaultNetWareUserName"="%1" >> %tmpfile%. Listing 2 contains the corrected batch file.
In addition, NetWare's Client32 has two fields, so you must input your logon name twice (once for NetWare and once for NT). Thus, Lenny could have added the fifth and sixth lines from his script to Steve Hong's original script (Reader to Reader, "Tip for NT Administrators," October 1997) to change both fields rather than only the NetWare logon (assuming that the user has the same logon name on both systems).
—Tom Anderson
tanderson@team-psc.com
If you've ever tried to rename a domain (not the Primary Domain Controller--PDC--or Backup Domain Controller-- BDC), you've probably searched the Microsoft Knowledge Base for help. Microsoft has only one article on this topic ("Renaming a Domain: Process and Side Effects," http://support.microsoft.com/support/kb/articles/q178/0/09 .asp?fr=0).
According to this article, you must change the domain name at the PDC, reboot, and then rename the domain at the BDC. However, the BDC refuses to change the domain name because it can't find the PDC for the new domain controller. You receive an error message (e.g., You already have a connection to the domain. You must disconnect before joining the domain).
I found a workaround solution to this problem. To demonstrate, let's assume you have a PDC called SERVER and a BDC called BACKUP. First, open the Network applet in Control Panel, and rename the domain at the PDC. Then, shut down the PDC. After you shut down the PDC, promote the BDC to PDC. (The new PDC is now called BACKUP.) Next, change the domain name on the new PDC, and shut down the PDC. Restart the old PDC (i.e., SERVER). Then, restart the new PDC (i.e., BACKUP).
When you open Server Manager, you'll see two PDCs. You must choose one of them to be the BDC. Select one of the PDCs (e.g., BACKUP), and select Demote to backup domain controller from the Computer menu.
You can also use this method to add a PDC from one domain to another domain. Be aware that renaming the domain requires you to modify BackOffice applications' service properties. For example, you must modify the Import and Export Servers at Replication services and reestablish the trust relationships. In addition, you must re-create all NT Workstation accounts. Utilities exist to help you change the domain name on NT workstations.
—Haluk Yildirim
haluk@graduate.org
I discovered a Windows NT Backup glitch that other users might benefit from knowing about. I'm responsible for several NT Server and NT Workstation machines at my office, and I automate as many daily administrative tasks as possible.
I configured NT's Scheduler to generate a full system backup every day. I used the NT Backup command
ntbackup backup c: d: /b /l c:\temp\backup_errors.txt /e
This command instructs NT Backup to back up both hard drives (C and D), back up the Registry (/b), and log only exceptions (/e) to a nonstandard log file. NT Backup also records start and stop times for the backup in the system's Application log.
Sometimes I rely too heavily on the automatic backup. I occasionally forget to change tapes because I know the current backup will overwrite the tape's previous contents. One of my systems recently went almost a week without a backup occurring before I realized that the Application log wasn't registering NT Backup's actions. Task Manager showed that NT Backup was resident in memory, but the tape drive was idle.
I soon discovered that the write-protect slide on the Travan TR-4 tape was so weak that it had slid halfway between write-enable and write-protect. Thus, the tape drive registered the tape as protected. If I were running NT Backup interactively, I would have received the error message Tape in Drive 1 is write-protected. However, NT Backup was running automatically and was unable to send the error message.
—Jim Moore
MooreJF@ncsc.navy.mil
Automation is important for successful network administration. My company automates as much of the computing environment as possible to let network administrators focus on strategic issues rather than on recurring operations.
I recently needed to clean up some Windows NT and Windows 95 workstations at a client site. The client had used policies to secure most of the NT workstations and had used a third-party security application to secure the Win95 machines. I needed to remove document artifacts left over from previous users.
The Microsoft add-on TweakUI lets you remove these document pointers at logon. However, the client's third-party security application prevented TweakUI from working efficiently.
I decided to write a template file to perform the administrative task. To download this file (Listing 3), go to the Windows NT Magazine Web site at http://www.winntmag.com and enter 4680 in the instaNT Doc text box. When you create policy files, you must create Win95 policies on a Win95 machine as config.pol files and NT policies on an NT machine as ntconfig.pol files. Always back up your Registry before you make changes to it.
The Microsoft Windows 95 Resource Kit provided little documentation about authoring template (.adm) files. I addressed the following areas: The Start/Run drop-down retains the 26 most recently typed commands, the Start/Documents drop-down retains the 15 most recently used documents, and the Internet Explorer (IE) Address drop-down retains the 25 most recently typed URLs.
Listing 3 shows the system policy that removes these recently used document entries. Although you can use the Win95 version of the System Policy Editor (SPE), you'll want to use the latest version of poledit.exe, which lets you use multiple templates in one policy file.
The system policy in Listing 3 affects three portions of the Registry. The names of the most recently executed files are in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU Registry key. The names of the most recently used files in Explorer are in the KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs Registry key. The most recently typed IE URLs are in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\TypedURLs Registry key.
You need to be careful about deleting the Registry entries. You can't delete them by using the Delete command. Instead, you must reset the value name to Default and then re-create the value.
—Mark Norton
mnorton@colltech.com
In Reader to Reader, "Three Suggestions for Microsoft" (July 1998), Paul Gracy wrote about a problem installing Internet Explorer (IE) 4.0 on an Alpha server. I encountered the same problem at a customer's site, and I discovered that the problem occurs because IE 4.0's setup program ignores the value of the temp system variable and instead uses the C:\temp directory to copy the .cab files. This problem commonly occurs on systems with small boot partitions.
The workaround solution to the problem is simple. Create a shortcut called temp in the C drive, pointing to a directory on another partition. The temp shortcut needs at least 40MB of RAM available. Windows NT will implement this shortcut as a file called temp.lnk. Then, open a command prompt (NT doesn't let you use the GUI) and rename the file from temp.lnk to temp. The IE 4.0 installation process should proceed smoothly.
—Bernard Freund
bef@ecpweb.com.br
I enjoyed reading Stephen Garwood and Andrew DuFour's "7 Tips to Optimize SMS" (May 1998) about Microsoft's Systems Management Server (SMS) optimization. In certain situations, you can further optimize software distribution by disabling the package compression that SMS automatically performs when it distributes packages between SMS sites.
Many tools that generate packages for SMS to distribute already perform compression or are capable of doing so. For example, SMS Installer compresses packages automatically, and WinINSTALL 6.0 lets you compress packages. If you use a compression-capable tool for the majority of your distributions, letting the package-creation tool compress the package can be more efficient than using SMS's compression feature: The package developer's workstation, rather than the busy SMS site server, performs the compression.
When you recompress a file that is already compressed, you rarely get a significant reduction in size. In addition, compression algorithms sometimes kick into overdrive when they attempt to compress a file that is already compressed. Turning off SMS compression will save a lot of CPU-intensive work at the distribution-source site server that compresses the package and at the sites that receive and decompress the package.
In a large SMS installation, disabling compression can save valuable SMS site-server resources. Even in an enterprise with only one SMS site server, disabling compression might be beneficial. If the server is undersized, turning off compression can create performance benefits for package distribution.
To disable compression, edit the Registry key HKEY_LOCAL_MACHINESOFTWARE\Microsoft\SMS\Compression\Compression Enable. Change the value of Compression Enable to No. If this Registry key doesn't exist on a new SMS site server, you can manually create the key or send a package to create it.
—Darwin J. Sanoy
DSanoy@coretech.com
My company has two small networks. Each network has six or seven PCs, all running Windows NT Workstation 4.0 or NT Server 4.0.
Many years ago, we installed Microsoft Office on most of the PCs, and we used Schedule to organize our lives. We soon upgraded to Schedule+, then Office Service Release 1 (SR1) and Microsoft Outlook 97. In time, we installed Outlook's Internet Mail Enhancement Patch, then the Rules Wizard, then the Outlook 3-Pane Extension, then Outlook 98. We did not install all the upgrades on every PC, but we installed Outlook 98 on all the machines. I was surprised to find that after we installed Outlook 98, many of the computers looked and functioned differently than before the upgrade.
As we made various upgrades in the office, I made the same upgrades on my home system. After I installed Outlook 98 at home, my PC suddenly quit receiving email. I was stumped, because I had not made any recent changes or upgrades before installing Outlook 98. Outlook Express worked, but Outlook 98 did not. The Messaging API 32 (MAPI32) and MAPI Service Provider (SP) processes would open, but they wouldn't start. They'd consume over 95 percent of system resources until I used Task Manager to disable them.
I deleted and re-created profiles, reapplied Service Pack 3 (SP3), updated Outlook, and deleted and re-created my personal folders. Nothing helped. Finally, I found the solution. I noticed that each time I reinstalled Outlook, I received the same error message: MAPI32.DLL file is the wrong version--please reinstall Outlook. I decided to rename mapi32.dll to mapi32.dll.bak and reinstall Outlook, thus installing a fresh mapi32.dll file. I exported the contents of all Outlook folders to a .pst file. Next, I uninstalled Outlook but kept the personalized settings, and I deleted the mapi32.dll file. Then, I installed Outlook 98 from scratch, and I imported the contents of the .pst file.
My home system now receives email with no problems. I'm also going through my company's computers and repeating the process to clean up Outlook at work.
—Mike Mulvey
mike@kornberg.com
Visiting Windows NT servers for simple tasks is time-consuming and frustrating. I enjoyed Michael P. Deignan's review of the NetOp remote-management tool ("NetOp 5.4 for Windows," August 1998). My company evaluated NetOp but could not justify another administration tool.
We discovered a good alternative to NetOp. The Olivetti Research Laboratory's (ORL's) Virtual Network Computing (VNC) tool runs on NT, Windows 95, and UNIX and provides many of the functions that NetOp provides. Best of all, VNC is free. To download a copy, visit ORL's Web site at http://www.orl.co.uk.
VNC is easy to use. Setting up servers is simple: You must manually set the option to run the server as a service, but the documentation is clear. You can use the VNC viewer to view a remote system. This component is only 15KB and doesn't require separate installation. Alternatively, you can view a remote system with any Java-compatible Web browser. VNC's built-in Web server lets you connect from any machine via the Web. (You must still authenticate connections to verify that a user has permission to connect.)
VNC provides cross-platform support. You can use a VNC X server to display a Linux desktop on a PC or Mac. In my mixed environment, I appreciate the ability to use only one interface.
—Barbara Wiseman
bw@dcs.gla.ac.uk