Tricks & Traps: Ask Dr. Bob Your Windows NT Questions
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
By Bob Chronister, Windows NT Magazine, May 1999
Q: What are the major Y2K concerns for Windows NT administrators?
A: Windows NT 4.0 offers only a partial solution to this problem. The Netlogon service tries to optimize domain controller synchronization by considering factors such as the amount of network traffic and choosing a replication interval that it deems best to optimize domain controller synchronization; however, you can change a default Registry value to reduce the frequency of replication. Go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Registry key, and change the value of the ReplicationGovernor entry (type REG_DWORD). The default value is 100, and lowering the value to 50, for example, reduces the replication interval by half. Lowering this value reduces the amount of replication traffic over the network but also compromises domain controller synchronization.
Y2K compliance requires machine BIOS and firmware compliance, OS compliance, and program compliance. A system is machine-compliant if its firmware and BIOS can handle the Y2K problem. Some old BIOSs won't automatically roll over to 2000. On systems with this problem, you will be able to manually change the date to 2000 at the command line, and the system will function as usual. However, this change will make the BIOS essentially compliant but not Y2K-compliant. Ideally, systems with noncompliant BIOSs need a firmware update, or you need to upgrade the entire system. Most new Pentium systems support automatic rollover to 2000. If you have any questions about your computers' compliance, call the vendor or check out the vendor's Web site.
OS compliance is a complex topic. Older software, such as DOS 5.0, isn't Y2K-compliant. Later versions, such as DOS 6.22, will run after 2000 with minimal problems but aren't Y2K-compliant. NT and Windows 95 are essentially compliant. You can make NT Y2K-compliant by applying Service Pack 4 (SP4), which adds the following functionality:
The Find Files or Folders tool supports only numeric character recognition in the decade field.
The Date/Time Control Panel applet can update the system clock.
User Manager and User Manager for Domains recognize 2000 as a leap year.
The DHCP administration program supports displaying the years 2000 through 2009 with a minimum of two digits.
Most programs will work after 2000 with only a few minor abnormalities. For example, Microsoft Word document properties have trouble with the 2000 date stamp, but SP4 fixes this problem. I have found that most programs, including old stalwarts such as WordPerfect 5.1, will run after 2000. I don't know whether these programs will be stable or how many problems they will have. Again, I recommend calling your software vendors or checking out the vendors' Web sites for more information.
Several available programs can scan your system's hardware (i.e., your BIOS) and software for Y2K compliance. If you need to update a system's BIOS, the vendor probably offers the appropriate fixed BIOS chips or software downloads.
Y2K is a major problem for old COBOL programs. Unfortunately, programmers used COBOL to create banking, financial, and government mainframe programs. If Y2K causes chaos, it will be in these mainframe arenas. However, the organizations that use these programs are expending great effort to make the programs Y2K-compliant. From the standpoint of the PC, the media are overhyping Y2K.
Q: How do I disable the pop-up messages that appear when I boot my notebook?
A: You can use a simple Registry modification to disable these messages. However, after you make this change, you must routinely check Windows NT Event Viewer for potentially lethal messages.
Remember that modifying the Registry is dangerous. Use your favorite Registry editor and go to the HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \WindowsNT \CurrentVersion \Winlogon Registry key. Add the entry NoPopupsOnBoot of type REG_SZ, as Screen 2 shows, and give it a value of 1.
Q: How can I set up Microsoft Exchange Server to interact with my ISP?
A: I assume you have a dedicated line to the Internet and connect through an appropriate router. For Exchange Server to interact with your ISP, you need to configure DNS, rather than modify your Exchange Server system's settings. You need to create a DNS mail exchanger (MX) record that points mail programs to the appropriate mail servers. Perform the following steps to create a MX record:
Right-click your forward lookup zone file (i.e., domain.com), then click New Record.
Select MX Record from the Record Type box in the New Resource Record dialog box.
Usually, you fill in the Optional Host Name field with the host name of the appropriate mail server. However, if you want users to be able to use the user@domain.com format to send mail to your domain, leave the Host Name field blank.
Enter the Fully Qualified Domain Name (FQDN) of the mail server in the Mail Exchange Server DNS Name text box (e.g., mail.domain.com.). Your Exchange Server mail system should be on a different computer than the DNS Server system. The Mail Exchange Server DNS Name has an extra period at the end, so the Mail Exchange Server FQDN you use must have a corresponding A record for that domain. The corresponding A record for that domain tells the DNS Server where to redirect the mail traffic.
The Preference Number given is any number from 0 to 65535. In a multiple mail server environment, a low preference number means a high priority.
Click OK.
Q: Is NetBIOS out of the picture in Windows 2000 (Win2K)?
A: Although Microsoft wants NetBIOS to vanish, Win2K will include the protocol for legacy connections to OSs such as Windows NT 4.0 and earlier. However, if everyone upgraded to Win2K, NetBIOS problems would be history!
Q: What are the arguments in the mainframe environment vs. the client/server model debate?
A: In my opinion, whether the mainframe or client/server model is better depends on how a business uses computers. For example, a mainframe environment is optimal for a hospital running numerous transactions on one database. In this case, the systems administrator develops applications that take full advantage of the mainframe's power, and most input devices are terminals. Mainframe users' business is completely automated and they have no need for Microsoft PowerPoint or Microsoft Word. Yearly support of a mainframe environment is minimal.
When you add PCs to this environment without mandatory control (e.g., mandatory profiles), my mainframe friends tell me that you need to add one support person for every 35 to 50 PCs that you add. The mainframe folks also argue that the constant need to upgrade offsets the low cost of PCs: DOS to Windows NT 3.1, NT 3.1 to NT 3.5, NT 3.5 to NT 3.51, NT 3.51 to NT 4.0, and NT 4.0 to Windows 2000 (Win2K).
The argument for the client/server model is that pools of inexpensive servers can do everything that a mainframe can do but cost much less. In the client/server model, you place multiple servers in an environment and let the clients participate in the workload. For example, if users are developing PowerPoint presentations, you can set up PowerPoint on their machines. Users can then save their presentations on the server, using it as a file server. Thus, users in a client/server environment are an integrated part of the computing system. This setup works fine and is easy to maintain.
So, the real question is which model is better for your business? Client/server model advocates arguing that the mainframe is disappearing are out of touch with reality—IBM is selling more mainframes than ever. A mainframe is better in the hospital setting that I previously described; however, the client/server model is ideal for a more dynamic business.
For example, I created UDF.txt, which Listing 1 shows. UDF.txt is a UDF with two unique IDs: Bob1 and Bob2. Bob1 and Bob2 have three sections?Userdata, GuiUnattended, and Network?that will merge into or replace the corresponding sections in unattended.txt. First, UDF.txt defines the unique IDs and unattended.txt sections that it will provide replacement data for. Next, UDF.txt provides the replacement data. Each UDF.txt section begins with the unique ID, followed by a colon and the unattended.txt section name that the UDF.txt section's data refers to. The UDF merges these parameters into unattended.txt, rather than replacing unattended.txt data, because these parameters aren't in the unattended.txt file. If the parameters already existed in the unattended.txt file, which Listing 2 shows, the UDF parameters would replace the unattended.txt's existing parameters.
Q: I've heard horror stories about Service Pack 4 (SP4). Can you list compelling reasons to upgrade?
**A:**The list of fixes in SP4 is impressive. Table 1 shows Microsoft articles about DNS and WINS problems that SP4 fixes. Go to the Microsoft Web site (https://www.microsoft.com) to find a complete list of problems that SP4 fixes. If your system has these problems, you should upgrade. However, if you're installing SP4 on a critical system, carefully consider whether you need SP4. (For more information about whether you should install SP4, see Tricks and Traps, April 1999.)
Table 1 Microsoft Articles About DNS and WINS Problems that SP4 Fixes
Q: The Registry editor grays out the HKEY_LOCAL_MACHINE/SAM and HKEY_LOCAL_MACHINE/SECURITY Registry hives on my Windows NT system. How can I look at the content of these hives without resetting their ACLs?
A: You can use the At command or the Microsoft Windows NT Server 4.0 Resource Kit Winat utility to force NT to expose these usually protected Registry hives. Use At and Winat to schedule an instance of a Registry editor at a specified time. By default, your system runs the scheduled session in the security context of the System account. The System account has access to the HKEY_LOCAL_MACHINE/SAM and HKEY_LOCAL_MACHINE/SECURITY Registry keys; thus, you can view the contents of these hives when your scheduled session pops up. Be sure to use the /interactive switch or, if you're using Winat, select the interactive option so that the scheduled Registry editor session is visible on the desktop.
For example, to schedule a regedt32 session to pop up on the local machine at 11:00 a.m., type the following command at an NT command prompt:
at 11:00 /interactive regedt32
Q: I installed Microsoft Windows NT Server 4.0, Terminal Server Edition on a computer that is not attached to my network. The drivers for my Xircom network card are on the hard disk. Later, when I added network support from Control Panel, I pointed to the drivers' location. However, I received the error message Can't copy CE3.DLL in library . If I skip the file, I get another error message for the next .dll and I can't install the driver. Pointing the installation program to the drive containing the Xircom drivers doesn't help, and the system won't copy a generic Xircom driver from the CD-ROM or the local /i386 directory. Do you have any suggestions?
A: When you add network support to a Terminal Server system after the main installation and your Terminal Server system is using Xircom network drivers, you must first point the installation program to the \i386 directory. When the system prompts you again, point it to the drivers' .inf file. You shouldn't receive any cryptic error messages.
Q: How do I set up a Dynamic RAS (DRAS) connector in Microsoft Exchange Server that uses a PPTP (i.e., VPN) connection?
A: The only difference between a normal RAS Point-to-Point Protocol (PPP) session and a PPTP session is that PPTP requires that you already have TCP/IP connectivity to the PPTP-based RAS host that you're dialing into. Assuming you have an over-the-Internet connection, you just need to define a DUN phone book entry for the PPTP connection and reference that entry and the credentials in the DRAS configuration in Exchange Server.
About the Author
Bob Chronister is a contributing editor for Windows NT Magazine and president of Chronister Consultants in Mobile, Alabama. He is coauthor of Windows NT Backup and Recovery (Osborne/McGraw-Hill). You can reach him at bob@winntmag.com.
Send your tips and questions to Windows NT Magazine. You can also visit Bob Chronister's online Tricks & Traps at https://www.winntmag.com/forums/index.html.
The above article is courtesy of Windows NT Magazine.
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.