\[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 [email protected]. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll receive $100.\]
SBS Console Blues
You need an open Internet connection to run Microsoft's Small Business Server (SBS) Manage Server console. I faced a problem related to this requirement at one of my client's sites.
I had installed and configured SBS 4.0 on a new machine. When I attempted to open the Manage Server console, Microsoft Internet Explorer's (IE's) dialog box opened and asked whether I wanted to dial out to my ISP.
This problem occurred because, during installation, SBS installs IE 4.0 on the SBS server, and I had configured the browser's Connection property page to dial out to my ISP on startup (using a phone-book entry I created). The Manage Server console is closely integrated with IE and Internet Information Server (IIS). Thus, the Manage Server console defaulted to the ISP dial-up.
To solve the problem, I reconfigured IE to connect via the network. The Manage Server console then worked without any problems.
—Shailendra Shenoy
[email protected]
NT Security
A colleague recently informed me of a Windows NT security problem. He found this information on a hacker's Web site.
A user with a user-level account can rename the logon.scr file in the \winnt\system32 directory to logon.old and rename usrmgr.exe (or musrmgr.exe on the workstation) to logon.scr. Then, the user logs off and waits for logon.scr to start. When the file starts, User Manager runs instead of the screen saver.
At a minimum, the user can see all the user accounts on the machine. When I tested the hack on my server, I could move the mouse without stopping the screen saver. In addition, I created an administrator-level account without logging on to the server or supplying a username or password. Then, I pressed Ctrl+Alt+Del and logged on to the server with the new administrator-level account. The hack worked even after I installed Service Pack 4 (SP4).
To secure your systems against this hack, ensure that users with user-level accounts can't log on to your PDCs and BDCs. Also, set NTFS permissions on logon.scr and usrmgr.exe to no access for users (the files can still run before logon, but users can't rename them). Finally, make sure your users don't have access to the HKEY_USERS\DEFAULT\Control Panel\Desktop Registry key, where they can also change the logon.scr and usrmgr.exe files. (For more information about NT security, see Sean K. Daily, "NT Server Security Checklist," Parts 1 and 2, July 1998 and October 1998.)
—Bob Bauer
[email protected]
Event Viewer Tip
I recently ran into problems using Windows NT Event Viewer. My Application log became corrupted, and I couldn't figure out how to access it. I decided to delete the log file and start over. Unfortunately, I couldn't delete the Application log, because the event log was running and therefore the system was using the file that contained the log.
To solve the problem, I disabled the event log startup. I started the Services applet in Control Panel, selected EventLog, and clicked Startup. Then, I selected Disabled and clicked OK in the dialog box that opened. After I shut down and restarted my computer, I had full access to the event-log file. Then, I deleted the Application log file (i.e., appevent.evt).
Next, I changed the event-log startup to automatic (via Control Panel, Services, EventLog, Startup, Automatic). I shut down and restarted my computer, and the system created a new Application log that has worked flawlessly ever since. (For more information about Event Viewer, see Michael D. Reilly, "Windows NT Event Viewer," November 1998.)
—Steve Hong
[email protected]
Exchange Server 5.5
If you receive a directory-replication error message when you attempt to add Microsoft Exchange Server 5.5 to your site, you might have a problem with name resolution. Check the Application event log on your primary Exchange Server machine for the following error message:
Event ID: 1171
Source: MSExchangeDS
Type: Error
Category: Internal Processing
Description: Exception 0xe0010002 has occurred with parameters 9 and 0. Please contact Microsoft Product Support Services for assistance.
I contacted Microsoft when I received this error message. However, Microsoft Product Support Services provided no help, insisting that you can have only one server per site with Exchange Server 5.5. Unfortunately, TechNet doesn't cite the problem.
Because TCP/IP is the first protocol in the server binding order, faulty name resolution can prevent you from successfully installing a server and joining a site. TCP/IP resolves names in the following order: through the local HOSTS file, DNS server, NetBIOS cache, WINS server, broadcasts, and local LMHOSTS file.
To confirm a name-resolution problem, use the Ping utility from the command line or the RPC Ping utility from the Exchange Server CD-ROM. From the Windows NT server you tried to install Exchange Server on, ping the primary server in the site, using the server name. If the ping succeeds, note the IP address that the utility returns and compare it with the primary server's IP address. This step is important because your HOSTS or LMHOSTS file might have incorrect entries, or a DNS server might have incorrect information. If the ping fails, ensure that a TCP/IP name-resolution method can resolve the server name.
Then, from the primary server, ping the NT server that will become the additional Exchange Server machine. If the ping succeeds, note the IP address that the utility returns and compare it with the primary server's IP address. The addresses must match.
After you correct the name-resolution problem, you need to remove the following Registry keys and their associated files from the aborted installation on the NT server: HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\Exchange Service, HKEY_LOCAL_MACHINE\ SYSTEM\ Current ControlSet\Services\EventLog\ Application\Exchange Service, HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Services\LicenseInfo\ MSExchangeIS, HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Exchange\Setup, and HKEY_CURRENT_USER\Software\ Microsoft\Exchange\MSExchangeAdmin.
Finally, delete the EXCHSRVR directory and its subdirectories from the hard disk. (If you have multiple hard disks, you must delete the directory from all of them.) Then, rename or delete the Exchange Server file setup.log on the system partition.
—Rene Lariviere
[email protected]
The Foibles of RAS and DHCP
I manage a TCP/IP network that uses DHCP for client IP addressing. I recently used the PDC as a RAS server to configure a modem pool for RAS connectivity. I mistakenly thought that the easiest method of assigning addresses was to tell RAS to use DHCP. RAS claims an IP address for each COM port when you configure it to use DHCP.
My clients soon started having intermittent logon problems. The system would hang for 30 seconds, then send an incorrect password or access denied error message. Repeated logon attempts were eventually successful. I analyzed Network Monitor and discovered that clients were attempting to reach the PDC for verification at an IP address that RAS had reserved for a COM port.
Solving the problem was simple. I reserved a range of IP addresses in DHCP on the desired subnet, then configured RAS to assign only from that static pool. (For more information about RAS and DHCP problems, see Sean Daily, "Windows NT 4.0 Service Pack 4," February 1999.)
—John Hluboky
[email protected]
RE: The US Government vs. Microsoft
I want to commend Don Jones for getting to the heart of the matter in "The US Government vs. Microsoft" (Reader to Reader, December 1998). However, I think he got the point exactly backward. He says, "If the government wins the IE battle, you might need to give up native vector fonts, memory management, network protocols, and file management."
As Don pointed out, other companies already offer these technologies. And Microsoft can continue to make the products even if the company loses the Internet Explorer (IE) battle. I believe the real problem is that Microsoft needs to divorce its additional software from the OS and sell it separately. Bundling applications discourages competition: For example, why should a consumer buy Chameleon's TCP/IP stack if Windows NT already includes one?
If we force Microsoft to sell NT and its related utilities and add-on software separately, we'll introduce fair market competition. The company will have to produce quality products at reasonable prices. Microsoft will have to abide by good programming practices, using properly documented and controlled APIs and giving third-party companies the same environment in which to write their versions of software. Only then will we have true competition, and only then can we determine whose software is best.
You might argue that this scenario results in consumers paying for software that is currently free. However, the software and utilities that Microsoft provides with NT aren't free—the licensing fees and upgrades are expensive. We're paying for software that Microsoft includes. I'd rather have the opportunity to purchase NT as a standalone product and add only the components I want. Microsoft could still offer bundles of products, such as Option Packs or Plus! Packs.
Although I'd probably buy Microsoft's all-in-one product (for the installation convenience if nothing else), I think consumers need a choice. If the Department of Justice wins, we all win. (For another opinion about Microsoft's bundling practices, see Mark Smith, "Everybody's Doin' It," November 1998.)
—David Krider
[email protected]
DHCP and Network Traffic
In an environment that uses IP as the network protocol, you must properly configure each host on the network with an IP address and subnet mask. You can configure these values manually, or you can use DHCP. Using DHCP is the most convenient and secure method of assigning IP addresses to prevent address duplication. (For more information about DHCP, see Michael D. Reilly, "Configuring DHCP," April 1999.)
Some network administrators think DHCP increases network traffic, so they increase the lease duration time to 30 or 40 days. However, DHCP doesn't use significant network bandwidth if you use the default lease duration of 3 days.
The first time a DHCP client comes online and initializes, it must acquire an IP address from the DHCP server. This action initiates a conversation between the client and server that consists of four frames. The first frame is DHCP Discover, which the client generates. The second frame is DHCP Offer, which is the answer to DHCP Request from the server to the client. The third frame is DHCP Request, which the client sends to the server. The fourth frame is DHCP ACK, which the DHCP server sends to the client to acknowledge the lease. DHCP ACK includes the lease time and other TCP/IP parameters. Each of these four frames is 342 bytes, for a total of 1368 bytes. The conversation takes about 300 milliseconds. Some older Microsoft clients use 590-byte DHCP frames.
DHCP clients renew their IP address lease before it expires. The renewal conversation between the DHCP server and client consists of two frames totaling 684 bytes. The conversation takes only about 100 milliseconds to complete. Thus, DHCP doesn't negatively affect your network if you use the default lease duration of 3 days. To change the duration, adjust the Lease Duration in the Scope Properties dialog box.
If the number of clients that will use DHCP is equal to or slightly less than the number of IP addresses that you can assign through DHCP, you'll want to use the default lease duration of 3 days. If the number of IP addresses is much larger than the number of DHCP clients, use a longer lease duration.
—Tommy Gustafsson
[email protected]
DHCP Quirk
On a recent Friday afternoon, just before I left work, I received several calls from users who couldn't log on to the network. I discovered that the Windows NT server I'd been building that afternoon was giving out IP addresses, even though I hadn't yet configured DHCP. The new server was answering all client requests with a broadcast message. This response was strange because it necessitated stopping or disabling the service until I fully configured the new DHCP server. (For more information about DHCP, see Michael D. Reilly, "Configuring DHCP," April 1999.)
—Tahir Ayyub
[email protected]
Symantec Dupes the Public with Inferior "Upgrade"
I recently bought Symantec's WinFax PRO 9.0, thinking the product was an upgrade from version 8.0. I was wrong. Symantec not only stripped out half the program by removing TalkWorks but also screwed up the scanner interface that worked fine in version 8.0. The program used to let you easily scan multiple pages by prompting you with a dialog box; now you must search for this feature. (For a review of version 8.0, see Jonathan Cragle, WinFax PRO 8.0," http://www.winntmag.com, instaNT document number 3525.)
Symantec is also charging customers for support calls that are necessary because of bugs in the software. For example, I had a problem receiving a fax, so I called technical support. The technical support person said the call would cost $29 and asked for my credit card number. He then walked me through a Windows NT Workstation Registry edit in which I changed the data bit in one of the programs to a 0 instead of a 1. He told me the software didn't install properly because it was still looking for TalkWorks, which the software no longer includes. I think it's absurd to pay $29 for a fix that a faulty program installation causes. When I called Symantec's customer service department to complain, they offered me a free copy of TalkWorks or a free technical support call worth $29, but they wouldn't refund my money.
Symantec needs to recall WinFax PRO 9.0. First-time fax software users might be happy with the program, but only because they don't have a past frame of reference. Anyone who has used Symantec's products previously will be as outraged over this "upgrade" as I am. (For more information about this problem, see Ctrl+Alt+Del, "A Bug or a Revenue Stream?" February 1999, and Ctrl+Alt+Del, "Weakly WinFax," page 232.)
—Eric Schueler
[email protected]
Novell Rescues NT Thin-Client Environment
My company has spent hundreds of thousands of dollars deploying PeopleSoft on Citrix's WinFrame running on Compaq 5000s. These machines use Windows NT Server 4.0 to store PeopleSoft's cache files. PeopleSoft has a glitch: The software opens 110 to 500 files per user and won't close the files. In a Citrix or NT Server environment, multiple users might open as many as 500 files each. However, because of a Server Message Block—SMB—limitation using virtual connections, Citrix and NT Server can open only 2048 files at a time per connection. (For more information about this problem, see the Microsoft article "Terminal Server and the 2048 Open File Limitation" at http://support.microsoft.com/ support/kb/articles/q190/1/62.asp.) Thus, you can max out a 25-user Citrix machine at 4 users. Additional users who try to use PeopleSoft on the machine receive an error message (e.g., srv.exe error 2009, SQL Server errors). Microsoft claims it addresses this limitation in Windows 2000 (Win2K). PeopleSoft says the feature enhances performance and the company has no plans to correct it.
My company's temporary solution is to use Novell Directory Services (NDS) for the file services. However, we must use an NDS beta release for the Citrix boxes. We've considered using DFS or NFS, but a DFS cache file location is unpredictable and an NFS solution might not perform well. If anyone has a better solution, I'd love to hear it.
—Ken Mejias
[email protected]
Customize Your Screen Savers Even Further
In "Customize Your Screen Savers" (Reader to Reader, September 1998), Rob Edwards presents a screen saver system policies template. (For the complete file, go to http://www.winntmag.com and enter 3799 in the instaNT Doc text box.)
This template file is missing some important information. For example, the CATEGORY !!SSaver and POLICY !!SSSETUP sections need END statements (i.e., END CATEGORY and END POLICY). Also, you need to add \[string\] tags to the end of the file. These tags are variables that define text within the policy editor.
For security reasons, my company wanted to lock users' computers if no activity occurred for 15 minutes. Thus, I added a section called PART !!Password to the .adm file. Listing 1 shows my modification, which lets you enable password protection on the screen saver.
After you create this policy and save it in the \winnt\inf directory, you need to add the policy to Windows NT. Open the policy editor (poledit.exe), and click Options, Policy Template, Add. Then, open the \winnt\inf directory, which contains several .adm files. Click the file you created (i.e., timeout.adm), and click OK to add the policy to the template.
You can set the policy on a user or group. I chose group because users in the group DOMAIN USER log on to all the computers I wanted to lock. To set the policy on a group, open the policy editor and click File, New policy, Edit, Add Group. Then, select the group (e.g., DOMAIN USER) and click OK. After the policy editor adds the group, double-click the group icon. Under the group menu listing, you'll see the policy you added. Click Screen Saver Mode, and select the Created by check box. You can then select the screen saver and the remaining choices.
To hide the screen saver tab from users, click Control Panel and select the Restrict display check box and the Hide Screen Saver tab check box. Finally, save the file as ntconfig.pol in the \winnt\ system32\repl\import\scripts\ directory.
To activate the policy, open the policy editor and double-click the Default Computer icon. Then, click Network, Remote update. Change the update mode to Automatic (use default path), and click OK. Finally, save the policy.
—Louis A. Goffredo
[email protected]
