\[Editor's Note: Share your NT discoveries, comments, experiences with products, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to [email protected]. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.\]
Windows NT Magazine has frequently suggested that you need an alternative NT system in case the main system fails. (For more information about NT backups, see Reader to Reader, "Restore Your NT OS," January 1998, and Bob Chronister, "Tricks & Traps," July 1998.) You can then boot the alternative system and use it to access NTFS files or run NT Backup.
To establish an emergency system, you can place the alternative system on a different disk from the main system or on the same disk as the main system but on another partition. However, these setups are susceptible to disk corruption and unavailability. Another method for creating an emergency system is to use a SCSI Zip drive such as the Iomega Zip 100.
You can boot SCSI Zip drives, and they are large enough to hold compact installations of NT Workstation 4.0. A SCSI Zip drive will not give you a fast system, but you don't need a fast system if you will use it only as an emergency backup. The main advantage of using a Zip drive for the emergency system is that you can remove Zip drives. You can create an emergency system on a Zip drive and then remove the drive for safekeeping.
The NT setup procedure does not let you directly install files on a Zip drive. You must perform the installation manually. First, use NT to format the Zip drive as NTFS. You must use NT to format the drive so that it will boot NT. You can format the drive as various file systems, but formatting it as NTFS lets you conserve disk space when you have many small files.
Next, install an alternative NT system on a separate disk or partition, and boot the system. After you boot the new system, move its paging file off the system disk. (The Zip drive will have about 13MB free after the NT installation, so you could set the maximum paging file size at 12MB and hope for the best, but you'll want to move the paging file to another disk if you can.)
To change the paging file's location or maximum size, open the System applet in Control Panel, and select Performance. Then, click Change in the Virtual Memory section to change the paging file's options. Reboot the system after you change the options. Then, reboot the original system and use it to move the alternative system to the Zip drive. (You cannot use the alternative system to transfer itself, because NT locks certain files for exclusive access and does not let you copy them while the system is running.)
If you created your alternative system on the same disk as the original system but on another partition, adding the partition might affect the way NT counts partition numbers. You might need to edit the boot.ini file before you can boot the original system. You typically install NT on the first partition. In this case, the number 1, enclosed in parentheses, occurs after the keyword partition in the boot.ini file, as Listing 1, page 52, shows. If you want NT to boot into the system on the second partition, you need to edit the boot.ini file and change the (1)s to (2)s.
To transfer the alternative system to the Zip drive, you can use Explorer to move the files. Unlike DOS, NT does not expect the files to be in a particular order on the disk. After you transfer the alternative system, you must check its boot.ini file and edit the file if necessary.
When you boot the Zip drive, ntldr regards the drive as disk zero, regardless of its SCSI ID. Only after the drive starts booting does ntldr assign a drive letter. After the drive starts booting, NT assigns the Zip drive the same drive letter it would have assigned during a typical boot.
—Ahlan Marriott
[email protected]
Monitor SMS Sender Progress
While monitoring Microsoft's Systems Management Server (SMS) sender logs and viewing information about how many bytes had transferred, I thought
it might be useful to examine SMS's sender progress. I discovered that using dumpsend.exe (on the SMS 1.2 CD-ROM in the support\debug\x86 directory) to view the .srs files in the sender outbox provided this information. I wrote two batch files, sendmon.bat and sendmon2.bat, that call the dumpsend utility and quickly give you progress information about sender transfers.
Listing 2 shows sendmon.bat, which requires a parameter to identify the location of the SMS server you want to monitor. Sendmon.bat steps through each .srs file in the sender outbox and calls sendmon2.bat, passing the .srs filename as a parameter.
Listing 3 shows sendmon2.bat, which performs a dumpsend command against the .srs file and pipes it to an output file. Sendmon2.bat then uses the Windows NT utility findstr.exe against the output file to find the line that contains the sender status, file size, and number of bytes sent.
Place sendmon.bat and sendmon2.bat in a directory with dumpsend.exe. You can easily modify these batch files to identify other information in the sender status files or to accommodate other sender outboxes. (For information about optimizing SMS, see Stephen Garwood and Andrew DuFour, "7 Tips to Optimize SMS," May 1998.)
—Morris Nuchowicz
[email protected]
NDS on NT Server
I wanted to simplify my network logon (i.e., require only one logon rather than a NetWare and a Windows NT logon) and make managing network services (e.g., user management, group management) easier. Thus, I wanted to incorporate users (objects) from my NT domain (mydomain.org) into Novell Directory Services (NDS) running on a Novell server. I installed the Novell client for NT from the NDS for NT 1.0 CD-ROM and rebooted my NT server. The Novell client then used the Domain Management tool to incorporate users. When NDS tried to incorporate users from mydomain.org, the program generated the following error message: Error Creating the domain Object in NDS. Error: c00000df. Error looking up SID: Server Name\\ ACME1 DOMAIN Name: MYDOMAIN_ORG.
NDS for NT 1.0 inserts an underscore in your NT domain name. For example, NDS reads mydomain.org as mydomain_org. This underscore creates problems if you use standard naming conventions. Domain names and host names typically have naming restrictions. (RFCs 974, 1034, and 1035 describe the syntax and conventions.) For example, NDS domain names can contain the characters a-z, A-Z, 0-9, and - (i.e., hyphen). NDS does not allow the period. When NDS reads the domain name mydomain.org as mydomain_org, it cannot find the domain because the domain name does not exist on the NT domain controller.
As a workaround solution, you can rename your NT domain from mydomain.org to mydomain_org and then reinstall NDS for NT. Otherwise, you might not want to install NDS until Novell releases a fix.
—Roman Vichr
[email protected]
Managing Control Panel Applets
I enjoyed John Savill's "Troubleshooting Windows NT System Configuration" (May 1998), and I got some useful new information from the article. Regarding his tip about removing applets from Control Panel, you can also use System Policy Editor (SPE) to selectively and remotely enable and disable user access to Control Panel applets. You need a new template (ADM-File), such as the one that Listing 4, page 52, shows. The template in Listing 4 lets you manage access to the Add/Remove Programs applet.
—Thomas Schuy
[email protected]
The US Government vs. Microsoft
I'm growing rather weary of the battle between Microsoft and the US government. At issue is whether Microsoft used monopolistic tactics to force people to use its Web browser software, Internet Explorer (IE). The government accuses Microsoft of using Windows 95's near-monopoly of the Intel platform to force consumers to use IE by installing the Web browser on Win95 computers. I think the government has blown this situation out of proportion.
Microsoft has a history of incorporating into its operating systems (OSs) features that third-party vendors previously provided. By not taking action against the company in the past 6 years, the government has implicitly sanctioned this practice. The following are examples of Microsoft replacing third-party features with its products:
- Microsoft included Adobe Type Manager in Windows 3.0. This program let you achieve scalable vector fonts without using the system's native raster font capability. Windows 3.1 and Win95 included the native TrueType vector font system. But this font engine hasn't killed the font market. People still use Type Manager-style products for their extra features.
- Stac and several other vendors made products that compressed your hard disk on the fly, effectively doubling your hard disk capacity. Microsoft then built this functionality into MS-DOS 6.0, and none of the third-party vendors complained (although Stac alleged that Microsoft stole its compression algorithm). Despite Win95's built-in compression capabilities, third parties still sell disk compression software.
- Quarterdeck's QEMM memory-management utility was a market leader until Microsoft added memory management to DOS, with MemMaker in MS-DOS 6.0. Win95 further expanded MemMaker's memory-management capabilities, reducing QEMM to a minor niche market. No complaints from Uncle Sam. Quarterdeck still makes QEMM for Win95, and many users think it does a better job of managing memory than MemMaker does.
- Windows for Workgroups (WFW) didn't include a TCP/IP stack, but users expected Microsoft to include native TCP/IP in NT and Win95. Companies such as Chameleon lost business after third-party stacks became unnecessary. However, Chameleon still sells its TCP/IP stack for NT and Win95, and I know plenty of network engineers who think Chameleon's stack works better than Microsoft's native stack.
- DOS didn't provide an easy way to manage files, so several third-party products offered file-management tools to help you manage the files on your computer. No one objected when Microsoft added Windows File Manager and Win95 Explorer.
- In the past, you had to add a third-party product to give your system the ability to read and render HTML documents. All your applications used the product to display HTML documents (e.g., Word, Excel, PowerPoint, your email client). When Microsoft released Windows 95B, the company included HTML functionality with IE. But somehow, the US government thinks this add-on product is different from any previous integration of new technology.
Microsoft's long and accepted history of bundling in technology that was previously a third-party add-on hasn't killed the competition, and it hasn't eliminated product categories. The company has simply added functionality that everyone, including other vendors, agrees is necessary for running a computer.
No one can argue that a Web browser isn't required functionality. With intranets and Web interfaces to corporate applications becoming increasingly popular, every computer my company installs must have a Web browser. If the OS included a Web browser, the user or systems administrator wouldn't need to add one. Of course some users might prefer to use a Web browser other than IE. Plenty of people would rather use Netscape simply because they hate Microsoft. Microsoft isn't forcing people to use IE; the company simply provides the Web browser for users' convenience.
Microsoft might have used its size and success in the past to push issues that weren't totally ethical (although perhaps not illegal). But on the Web browser issue, our government is off base--and you need to be worried. If the government wins the IE battle, you might need to give up native vector fonts, memory management, network protocols, and file management. After all, we can't let Microsoft's monopoly force other companies out of business, can we? The entire computer industry--including Netscape--needs to consider whether we want the government to make decisions about the permissible future of our technologies.
—Don Jones
[email protected]
Microsoft Drops the Ball
I encountered a Windows NT printing performance problem that I thought
others might be interested in. My enterprise environment consists of about 700 NT 4.0 workstations and about 15 NT servers. Out of the blue one day, we started seeing 100 percent processor utilization on the 233MHz Pentium II print server. High processor utilization prevented us from rebooting. Thus, we had to power off the server (which you know isn't good).
At first, I thought we might have too many print queues on the server (more than 80). However, I read a couple of TechNet articles that referred to 300 queues on a print server in the 486 and early Pentium days, so I was confident that we were not exceeding our print server's capacity.
We made several fruitless calls to Microsoft. The support people we talked to were determined to blame our problem on third-party print drivers. But we were using only NT's default print drivers. Microsoft also tried to blame the applications generating the print jobs (e.g., Word, Excel, Access--you know, nonstandard stuff). I was livid by this time, and I insisted that Microsoft credit us for several incidents.
We continued to struggle with the print server problem for the next year, and I resigned myself to defeat. I started planning for a second print server, keeping our original problem in mind.
Then I came across a newsgroup post that knocked me out of my chair. A user posted that when NT workstations print to NT print servers, they use the Enhanced Metafile (EMF) print processor to return control to the application more quickly. When NT sends the job to the printer, it must perform an EMF to RAW conversion before it can send data to the printer.
I wondered how much of a performance increase EMF gives you on the workstation end. I investigated a bit and found that if I changed all my printers to Always spool RAW datatype at the print server, the performance hit was nonexistent on the workstation side but we saw a dramatic improvement on the server end. The system had to handle only half as many files. In addition, memory utilization dropped 50 percent, and processor utilization dropped to around 30 percent on a consistent basis. The file conversions from EMF to RAW were drilling the server into the ground.
Microsoft has a TechNet article stating that printing EMF jobs sometimes causes a corrupt EMF spool file, followed by 100 percent processor utilization. The only solution is to power off (sound familiar?). The lesson we learned was not to use EMF except when necessary.
Since we found and solved the problem, we have rebooted our print server only once, to move it to a new location. It is now 2 months later, and nary a hitch.
So where was Microsoft during our struggle? I guess Bill was busy counting his money. We spent over a year dealing with a problem that Microsoft should have caught immediately. If Microsoft provided experienced, trained support personnel to its Priority Comprehensive contract holders, we could have avoided the frustration of having to drop our print server as many as four times a day.
—Randall S. Nieland
[email protected]
Escape the Blue Screen of Death
You can take a few preliminary steps to make sure new applications don't cause problems on your system. Before you install a new application on your production servers, you'll want to install the application in a lab environment. Even if your lab servers don't mirror your production servers, a test installation can help you understand an application's setup (i.e., drivers and information needed) and lead to a successful installation. You also need to ensure that new applications are compatible with the Windows NT services your production server is running. An application might run on NT but have hidden bugs or gotchas, such as a blue screen of death feature. (For information about the blue screen of death, see Mark T. Edmead, "The Blue Screen of Death," June 1997, and Mark Russinovich, "Inside the Blue Screen," December 1997.) Finally, make note of any services a new application installs, and identify their names in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Registry key.
I once installed an NT-compatible application for a client on a healthy NT system, rebooted the system, and was surprised to see the blue screen of death about 15 seconds after logon. My first reaction was to open the Services applet in Control Panel and set the service to Manual, so the service wouldn't start the next time I rebooted. However, trying to open the Services applet in Control Panel before all the services start gives you the message Service database locked. When the new service started, I again faced the blue screen of death. By this time, my client and I were getting nervous.
I had installed the application in a lab environment, so I knew which services the application installed. The next time the system booted, I logged on, started a Registry editor, and opened the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Registry key. I found the service that the new application installed, and I set the start value to 4 (i.e., disabled). After the system rebooted, the client and I were happy to not see the blue screen.
—Mike Morales
[email protected]
