| Downloads |
|---|
| 7272.zip |
\[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 edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
Using Rdisk /s
Alessandro Iacopetti's "ERDs and RDISK" (Reader to Reader, April 1999) correctly explained how to use the rdisk /s command to create backups of the Emergency Repair Disk (ERD). However, when you run this command, the current SAM overwrites the existing SAM in the \winnt\repair directory. If the SAM is large (i.e., 20MB or larger), the Repair copy of the SAM won't fit on a 3.5" disk. Thus, you can't create a 3.5" repair disk. Microsoft discusses this problem in the article "RDISK /S and RDISK /S- Options in Windows NT" (http://support.microsoft.com/support/ kb/articles/q122/8/57.asp) and suggests that you make a backup copy of the \%systemroot%\repair directory before you use the /s option.
Browsing Follow-up
I enjoyed Michael D. Reilly's "The Browser Service" (March 1999), which provided an excellent description of how the browser service works. One thing Michael didn't mention in the article was how to break browsing on a network. Two methods exist for breaking browsing on a Windows NT network. One method is to have multiple NICs in the domain master browser (i.e., the PDC). The other way to break browsing is to have multiple NICs in a segment master browser (which the author refers to as a subnet master browser). If NetBIOS over TCP/IP (NetBT) is bound to two segment master browser NICs, the machine maintains two browse lists. However, the two NICs can't exchange the two browse lists in this multihoned configuration. Thus, you'll have an incomplete browse list for the client. To fix the problem, you need to single-hone the machine and edit the Registry. Start regedt32, go to the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ Browser\Parameters\MaintainServerList Registry entry, and change the value to false. Close the Registry Editor, and reboot the machine.
MCSE Cheating
I recently earned my MCSE and was disturbed by another test taker's behavior and Microsoft's response. The last test I took to earn my certification was TCP/IP. Several days before the test, I received a confirmation letter from Sylvan Learning Center (the test administrator) reminding me of the test time and telling me I would be taking an adaptive rather than a standard exam. The day of the test, I noticed that my exam was standard, but I felt comfortable taking the test because I had studied well and knew the material.
The same day I took the TCP/IP test, one of my coworkers took the Networking Essentials exam. His confirmation letter also said he would be taking an adaptive test. He started the exam and got to question 26 (on the 30-question test) before he noticed that the test was standard rather than adaptive. At that point, he told the test proctor that he wanted the proctor to load an adaptive test and let him start over. Of course, the test proctor couldn't reload the exam and thus told my coworker to just finish the test. My acquaintance rushed through the exam, not trying to pass. He failed the test, and the test proctor told him he would need to email Microsoft to complain.
My coworker emailed Microsoft, telling the company that his confirmation letter said he was supposed to take an adaptive test and that when Sylvan administered a standard test, he got confused. Unbelievably, Microsoft sympathized and sent him a voucher to retake the test.
In my opinion, this person wasn't prepared for the exam and is using the type of test as an excuse. After all, you don't prepare to take an adaptive or a standard exam—you study the same material for either test. In addition, my acquaintance should have notified the test proctor that the type of test was wrong before he started taking it rather than when he was almost finished (and knew he was going to fail).
By letting someone retake a test because it was the wrong type, Microsoft is giving MCSE candidates the impression that they don't have to fully prepare for the exams. This situation makes Microsoft and the MCSE program look bad.
NT and Win95 Logon Scripts
I had to carry out a complete migration from Novell NetWare 4.11 to Windows NT 4.0 at my previous employer's office. The desktop environment was a mixture of NT 4.0 and Windows 95 workstations. I needed to use logon scripts to complete the migration, which was difficult because the logon script setups for NetWare and NT are quite different.
In NetWare 4.11, you can use one logon script to serve all the users in a department or location. To accomplish this task, you assign a logon script to the Novell Directory Services (NDS) container the users are in. Then, users get various drive mappings depending on their group membership.
In NT 4.0, you must assign a logon script to each user. You create logon scripts as batch files with .bat or .cmd extensions. Then, you need to place these files in the \winnt\system32\repl\ import\scripts directory on the PDC and use the Directory Replication service to replicate the files to the BDCs. To map various user drives depending on users' group membership, I used the Microsoft Windows NT 4.0 Resource Kit's ifmember.exe utility. This tool is equivalent to NetWare's If member statement. (You can also use the shareware utility KiXtart 95. This utility is more powerful than ifmember.exe.)
I set up user home drives as h in User Manager for Domains, and I experienced several problems. First, home drives weren't mapped on the Win95 PCs. To map user home drives on these machines, I used the following command in the logon script: net use h: /home. (This command doesn't work on Win98 machines.)
Second, some applications didn't work because they required access to the root of users' home drives. To solve this problem, I shared the user home drives (granting Full Access to the user and the Domain Admin group) and changed the Uniform Naming Convention (UNC) path in User Manager for Domains.
Finally, the ifmember.exe utility wouldn't run on the Win95 PCs; I received the error message Bad Command or File Name. Because the Win95 users belonged to various departments that required different drive mappings, I needed to use a set of logon scripts that depended on users' departments. Listing 1 shows this logon script. (Listing 2 shows a similar script that employs ifmember.exe for NT users.)
For my NT drives to map successfully and for the logon script in Listing 2 to run, I needed to create local and global groups. I created a local group called recep and gave the group access to a folder called faxes. Next, I added a global group called recep to the local recep group. Finally, I added all the necessary users to the global group recep.
Another Time Synchronization Tip
In "Time Synchronization" (Reader to Reader, April 1999), Jorge Roque explained how to synchronize your computers' clocks by including the following command in users' logon scripts: net time \\servername /set /yes. I'd like to offer additional tips for controlling time synchronization on your computers.
Because Windows NT systems recognize time zones, an NT workstation can read the net time \\servername /set /yes command and make an adjustment if the server is in a different time zone. Windows 95 clients don't recognize time zones. Thus, if your server is in New York and you have a Win95 client logging on in Chicago at 8:00 a.m. local time, the client will switch its clock to 9:00 a.m. To solve this problem, you can give your Win95 clients a separate logon script to synchronize their times with a local server.
Time synchronization of servers is more difficult than for clients because you might not log on to your servers regularly. You can use the script in Listing 3, page 28, to set the time on your servers. You need to run this script from the NT Scheduler service on all your servers. (Before you run the script, set the Scheduler service to use a domain account that has rights to set the time, rather than using the system account.)
In addition to setting the time, this batch file creates a small text file that tells you whether the batch file ran. The first redirection arrow (>) copies output from the command to a text file called timeset.txt, which is in C:\utils. Example text of a successful run is Current time at \\servername is 11/01/99 12:18 p.m. The command completed successfully. If the batch file fails, the timeset.txt file will be empty. The second redirection arrow (2>) copies error messages to a text file called timebad.txt, which is in C:\utils. If the batch file runs successfully, this file will be empty.
Using text files is helpful because the Scheduler service doesn't let you know the results of a batch file. Text files can also help you determine why a batch file failed.
More About the Date/Time Bug
In "Date/Time Bug" (Reader to Reader, September 1999), Patrick K. Poole wrote about his experience with the Control Panel Date/Time applet in Windows NT 4.0. He encountered a problem because changing the date and time in the applet changes the system date and time even if you don't click OK.
Microsoft discusses this problem in the article "System Date Reflects Changes Immediately" (http://support.microsoft.com/ support/kb/articles/q194/0/78.asp). In addition, Microsoft fixed the problem in NT 4.0 Service Pack 5 (SP5).
More About NumLock
I have some information to add to Mike Mulvey's "NumLock" (Reader to Reader, April 1999). Microsoft documents the NumLock key's underlying problem in the article "NumLock Key State Not Saved When Logging Off" (http://support.microsoft.com/ support/kb/articles/q123/4/98.asp). This article explains that the system doesn't save NumLock's status unless the user belongs to the local administrators group. Although the article suggests a solution, the solution doesn't work. You must edit the Registry as Mike suggests.
This problem was one of the users' main complaints about Windows NT installations in my company. We modified the default Registry on all our NT systems to solve the problem. In the i386 directory is a file called Default._. You need to expand and load this file by opening regedt32; selecting Registry, Load Hive from the menu bar; and entering a key name. You can enter any key name; I used numlock. After you enter the key name, you'll see the name in the tree. You can then edit the Registry hive. Go to the HKEY_CURRENT_ USER\Control Panel\Keyboard Registry entry and add the entry InitialKeyboardIndicators. Then, add a value with a data type of REG_SZ and a string value of 2. This process adds the Registry entry to the .default user profile in the Registry. New users who log on to the machine will have NumLock turned on by default. An easier method if you're using the Microsoft unattended installation process is to export the Registry entry to a .reg file, edit the file to include only the InitialKeyboardIndicators entry, and use the cmdlines.txt file to import the entry during the installation process.
Even More About NumLock
In "NumLock" (Reader to Reader, April 1999), Mike Mulvey stated that changing the HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators Registry entry's value to 2 sets NumLock to stay on continuously. However, NumLock doesn't stay on during the logon phase because Windows NT doesn't know which user is logged on. To turn NumLock on for all NT users, including during the logon phase, change the HKEY_USERS\.DEFAULT\Control Panel\ Keyboard\InitialKeyboardIndicators Registry entry's value to 2. For users who don't want to use the feature, you can change the HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators Registry entry's value back to 1.
Microsoft Cuts Corners on MCSE Certificate
I recently completed my MCSE, and I noticed that the Microsoft Certified Professional (MCP) certificate (which bears the MCP logo) and the MCSE certificate are almost identical. The only difference on the MCSE certificate is the addition of the words Systems Engineer. Because people notice images before text, most people won't see a difference at first glance. I tested this theory with four people in my office; only one noticed that the MCSE certificate is different.
Although this matter seems trivial, it's important to those of us who've worked hard to earn our MCSEs. I don't think I'm unreasonable to want a certificate that bears the MCSE logo. Therefore, I sent the MCP program an email message asking the company to reissue my MCSE certificate with the proper logo. Microsoft's response was, "We do not make up special certificates on demand. All MCSEs receive the same certificate, and very few complain about them. We are sorry you feel the way you do, but that is the MCSE certificate."
I think Microsoft is trying to save money by not issuing distinct MCP and MCSE certificates. MCSEs are Microsoft's best salespeople, and the company is selling us short. If you're an MCSE and you want Microsoft to reissue your certificate with the MCSE logo on it, visit my MCSE Call to Arms Web site (http://www.fms4u.com/mcsecert.htm) to send the company an email message.
