Reader to Reader - June 2000

[Editor's Note: Share your Windows 2000 and Windows NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows 2000 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.]

Carefully Manage Desktop Shortcuts
In Reader to Reader: "Managing Desktop Shortcuts," August 1999, Jim Holt is partially correct when he describes the behavior Windows NT displays when creating shortcuts. However, NT uses the Uniform Naming Convention (UNC) path internally to create shortcuts only when the user who is creating the shortcut has administrator privileges. NT uses three types of shortcuts: stable machine-independent, unstable machine-independent, and machine-dependent (UNC-based).

When you first install NT, the links to the accessories that the Start menu lists are stable machine-independent shortcuts. These shortcuts have no reference to the machine on which you created them, and they won't revert to a machine-dependent state.

When a user who doesn't have local administrator privileges creates a shortcut to a location on the local hard disk, the shortcut is machine-independent and unstable. By unstable, I mean that if a user with administrative privileges attempts to modify the shortcut (e.g., double-clicks the shortcut), the shortcut will revert to a machine-dependent state. However, the system on which the user with administrative privileges modifies the shortcut doesn't change the DOS attributes on the file, so you can make shortcuts read-only by using attrib +r at a command line.

To avoid shortcut problems, create a NetApps folder on your server, assign permissions that let only a user with special permissions access the folder, use that special user ID to create and manipulate shortcuts, and carefully guard the folder's security. If you want to copy shortcuts from the desktop to another machine, copy the shortcuts from the command line and run attrib +r on the .lnk files.

—Toby Everett
[email protected]

MCSE Progression Track
Microsoft doesn't have a clear progression track for the company's IT certifications. I suggest that the company develop a Master MCSE and an Enterprise MCSE certification program to help distinguish an engineer's capabilities. To earn a Master MCSE, an engineer would have to pass the following exams: 70-019, 70-028, 70-029, 70-056, 70-058, 70-059, 70-067, 70-068, 70-073, 70-079, 70-081, 70-085, 70-087, 70-088, and 70-098. An Enterprise MCSE-certified engineer would have to be a Master MCSE as well as hold at least one of the following certifications: Master Certified NetWare Engineer (MCNE), Cisco Certified Internetwork Expert (CCIE), or Certified Network Expert (CNX). In addition, to earn these certifications, engineers would have to provide proof of real-world experience similar to the proof required to earn a doctorate degree.

—Frank Lyon
[email protected]

An NT Security Loophole
I have two domains, DOMAIN_A and DOMAIN_B, on Windows NT PDCs PDC_A and PDC_B, respectively. I set the Administrator password as admin on both PDCs, and I haven't created any trust relationships between the two domains. When I connect the two domains in the same subnet on the network, I can use Network Neighborhood to see one domain from the other domain's PDC, and vice versa. When I log on as Administrator, I can administer DOMAIN_B from the PDC of DOMAIN_A, and vice versa. All domain-administration utilities (e.g., Server Manager, User Manager for Domains) work perfectly.

This setup highlights two important points: First, anyone who cracks your Administrator password can administer your domain from another domain. You could never trace this activity because an intruder needn't physically log on to your domain. In fact, an intruder could cause problems at the same time that the true administrator is logged on, and the blame would fall on the administrator. The only way to discover such an intruder is to constantly run Network Monitor, then figure out from the log who is remotely accessing the PDC.

Second, NT offers a good level of network security. However, the previous scenario provides evidence that NT grants unrecognized workstations that have the same account name and password on the two domains access to both PDCs and domains.

I've read documents that state that NT grants access tokens only at logon, and that you must log on again to access a newly granted resource. For example, suppose test network share on DOMAIN_A has access permissions for test_user on only this domain. Suppose you connect to DOMAIN_B as test_user and try to access the test share. Although the access tokens that NT granted to test_user at DOMAIN_B don't reflect access to any test share (this share resides on DOMAIN_A), NT will provide the user (i.e., test_user at DOMAIN_B) free access to the shared resource.

Are these security loopholes in NT? How do you secure your network in this situation?

—Priyank Pashine
[email protected]

UNIX Whence Command vs. NT For Command
I love the UNIX ksh whence command. This command searches a path for a specified filename and tells me where the command first finds the file so that I know exactly which copy (of the multiple copies of that file in the path) the system is running.

When you enable command extensions, you can use the Windows NT 4.0 For command to emulate the whence command in a batch file. The For command is helpful when you're dealing with multiple installations or versions of common DLLs.

In Listing 1, set pathold=%path% preserves the current path environment variable in a new variable called pathold. Set path=.;%path% inserts the current working directory in front of the path variable to ensure that the system searches the current working directory first. (NT and DOS always search the current directory first, whereas UNIX searches only the path.) The for %%i in (%1) do set first=%%~$PATH:i statement uses the For command and the ~$path: variable substitution to find the first occurrence of the specified filename in the path and assign the filename to a new variable called first. The rest of Listing 1 cleans up and displays the appropriate results.

Unfortunately, this batch file doesn't work predictably when you use wildcards (i.e., filename.*). If you're searching for an executable file, you need to specify whether the file has a .com, .bat, or .exe extension.

—Terry Snyder
[email protected]

Regback Quirk Workaround
To work around the Regback quirks that Sean Daily describes in the sidebar "The Regback Profile Quirk" in "Recovering from NT Startup Failures, Part 2," November 1999, I wrote two small Windows NT batch files. The batch file that Listing 2 shows begins by remembering the current directory, then moving to the directory to which the batch file will store backups. Backreg.cmd then calls setdate.cmd, which Listing 3, page 34, shows. Setdate.cmd generates a variable called TODAY, which backreg.cmd uses to create a variable called DIRNAME (TODAY sets the date format to, for example, 23-12-99 if the current date is December 23, 1999). Backreg.cmd uses DIRNAME to name the directory in which the file will store Registry files. Next, the file uses the For command to run Microsoft Windows NT Server 4.0 Resource Kit's regback.exe. The For syntax parses regback.exe's output, skipping 9 lines (i.e., reading line 10 of the output) and assigning field 6 to the REGKEY variable. You can substitute the REGKEY variable in regback.exe and rerun the executable file to store the elusive user profile portion of the Registry to the same directory. If you don't have PKZIP, you don't need to include the code at callout A in Listing 2.

—Kevin O'Sullivan
[email protected]

Simplified Dynamic Filename Script
The script in Listing 1 in Reader to Reader: "Dynamic Date/Time Stamped Files in NT DOS," Winter 1999/2000, is clever. However, as Listing 4 shows, you can use JP Software's 4NT (http://www
.jpsoft.com) to simplify the script.

The 4NT environment variable _time doesn't exactly match the output of the NT DOS command time/t. For example, time/t under 4NT displays

9:29:28(with a leading space), and under NT DOS, time/t displays9:29a

If you require an exact match, you can modify Listing 4's third argument of the second @replace statement as follows:

set filename=%_dow%-%@replace[/,_,%_date%]%-%@replace[:,_,%@execstr[time/t]].log

—S. D. Maley
[email protected]

Certification Limitations
In Reader to Reader: "MCSE Paths," December 1999, Robert Ian Clark distinguishes between paper MCSEs, goal-oriented MCSEs, and slow-and-steady MCSEs. In 1999, I obtained my Windows NT Server 4.0 Microsoft Certified Professional (MCP) certification, and I currently fall into the goal-oriented MCSE path. I agree with Robert that instructor-led courses devalue the certification program. Initially, Microsoft might have wanted to provide a quick certification option for people who were already in the industry. For this purpose, classes are probably sufficient. However, the certification I obtained was nothing more than an aptitude test. MCPs who have no network experience but believe that they're qualified for more than an entry-level position are naive. I used my certification to get a foot in the door, but if the goal of certification is to denote a level of competency, Microsoft needs to revise the certification process. Solid and thorough training combined with an individual's dedication is the only way to guarantee that a certified person is a qualified professional.

—Laurie Rusch
[email protected]

Another Method to Recover from an NT Startup Failure
I enjoyed Sean Daily's "Recovering from NT Startup Failures, Part 1," September 1999, and "Recovering from NT Startup Failures, Part 2," November 1999. However, Sean didn't mention a simple recovery technique that bailed me out of a server-recovery problem. That technique is to use a disk to boot NT, and you can use it when one of the initial boot files is missing or corrupted.

Something or someone corrupted the boot.ini file on one of my company's Windows NT servers, and the server wouldn't restart after shutdown. The main boot partition was NTFS, so I couldn't boot from a DOS-formatted disk to repair the partition. I downloaded a copy of Systems Internals' NTFSDOS freeware, which I used to reveal that the boot.ini file was damaged. But I was unable to fix the file.

My solution was to use another server to create an NT-formatted disk, copy the key boot files, and create a customized boot.ini file. I booted the damaged system from this 3.5" disk. This action was sufficient to get NT Server back up and running. Then, I could fix the server's corrupted boot.ini file.

The files that you need on a bootable NT disk are NT Loader (NTLDR), ntdetect.com, and boot.ini. To create the correct boot sector, you must format the recovery disk on an NT system; formatting on a Windows 9x system doesn't work. If the damaged NT server has NT installed on a non-BIOS-accessible SCSI disk, you might need to have a copy of a SCSI driver. The SCSI driver's filename is usually ntbootdd.sys, but the name varies depending on the SCSI adapter.

My custom boot.ini file handles different drives and partitions for the boot partition, and all my systems use a BIOS-accessible SCSI drive as their boot partitions. Thus, I can use the disk I created to boot any of my Intel-based NT Server systems. I keep this disk in a safe place with my Emergency Repair Disks (ERDs).

—Fred D. Brown
[email protected]