Skip navigation

Ask Dr. Bob Your NT Questions - 01 Sep 1998

Send us your tips and questions. You can also visit Bob Chronister's online Tricks & Traps at http://www.winntmag.com/forums/index.html.

Last Known Good
A reader recently wrote me and pointed out a critical step in using the Last Known Good configuration. Here's her message:

Bob, I really enjoy reading your column in Windows NT Magazine. You cover a wide range of experience levels. After reading your response in the June issue about the Last Known Good configuration, I realized that you left out one of the most common reasons that the Last Known Good configuration doesn't work: You have to press L, not Enter. After you press the space bar to invoke the Last Known Good menu, you have to press L, not Enter. Even if people have been instructed to press L, they still miss it.

Keeping User Settings While Changing Domain Membership
I recently had a reader write to me asking about copying user profiles to a new domain without messing with roaming profiles. The reader explained that every time he changed the domain membership of Windows NT workstations, the users lost their settings. The reader manually copies the contents of the user's profile folder to the new user profile folder (i.e., the username.000 or username.001 folder). However, this process copies only the desktop icons and Start menu settings.

I've often gone through the same procedure to reconstruct a Primary Domain Controller (PDC) when I didn't have an adequate and up-to-date backup of the PDC. I've followed the exact same steps the reader described and have never found a workaround to bring back the personal settings. If you've found a solution to this problem, write me and let me know.

All in the Family
My son Ian recently encountered an interesting situation. While he was setting up some new systems for a client, Windows NT refused to install on one particular system, even though the system initialized OK. Ian was able to activate the drives and start the NT installation process, but the system stopped short of installing the operating system (OS) and kept corrupting files and displaying a blue screen of death error message c00000221 during NT installation. When Ian ran a SCSI integrity utility, the program showed that the system was functioning properly. Finally, Ian decided to look at the back of the system, where he noticed that one of the power supplies was flickering on and off because of a loose power cord. After he tightened the power cord, Ian was able to boot the system and install NT as usual. Just another situation to give systems administrators gray hair.

Ian also told me of a problem he had with the HP automated installation script that comes with the HP NetServer Navigator CD-ROM. This problem surfaces when you use this script with the first CD-ROM from the BackOffice suite. The installation process copies winnt.exe as a hidden file. When the system reboots, the installation script doesn't work because it can't find the hidden winnt.exe file. To work around this situation, place a copy of the file onto a 3.5" disk, copy the file to the hpi386 directory, and reboot the system. Alternatively, you can run the hpinst.bat file in the hpi386 directory.

Is Windows NT 4.0 safe from the Year 2000 (Y2K) computer problems? I have a bet with my fellow IS managers that NT 4.0 is susceptible. Am I right?

I hope that by the time you read this, Microsoft has released NT 4.0 Service Pack 4 (SP4), which will include a Y2K fix. However, in the meantime, you are correct. Several post-SP3 hotfixes for NT and the Y2K dilemma exist. These fixes are all part of the Y2K hotfix and deal primarily with file find and related property issues. Specific Microsoft Support Online articles that deal with these problems include

  • Q175093: User Manager Does Not Recognize February 2000 As a Leap Year
  • Q180122: After Changing the Time, Windows NT May Skip a Day
  • Q183123: Find Files Displays Garbled Date if Year is 2000 or Greater

For more about Y2K, see Jane Morrill, "Year 2000 Mission Control," page 126.

My Exchange database is working fine, but I'm unable to back it up. What do I need to do to back up this important information?

If you're having a hard time backing up your Exchange database, the database is probably fragmented and most likely contains some erroneous headers. Microsoft provides tools with Exchange that solve such problems.

The ESEUTIL utility that comes with Exchange Server defragments, checks the integrity, and repairs the Exchange Server Information Store and directory. Available switches you can use with ESEUTIL are

  • /ds Directory
  • /ispriv Private Information Store
  • /ispub Public Information Store

Several optional switches help you determine the manner in which ESEUTIL handles the databases. Table 1 shows these optional switches.

The ISINTEG utility lets you test and fix errors in the Information Store. When you run this utility in Patch mode, it repairs Information Stores that won't start after you restore them following an offline backup. Table 2 shows optional switches you can use with ISINTEG.

To defragment your database, perform the following steps:

1. Stop all Exchange services.

2. Copy priv.edb from the \exchsrvr\mdbdata directory to a different location in case something happens to the database in the \mdb directory.

3. Go to \exchsrvr\bin, and type

eseutil /d /ispriv

at the command prompt to defragment the private Information Store (ispriv).

4. Delete or move all log files out of the \mdbdata directory.

5. From the \exchsrvr\bin directory, type

isinteg -pri -test alltests

at the command prompt. (If you don't encounter any errors up to this point in the process, then everything is working properly.)

6. Type

isinteg ­patch

at the command prompt.

7. Start the Exchange Information Store.

Using this procedure, I have seen database sizes shrink considerably.

I can't get my HP 7215 autoloader to work with Seagate Software's Backup Exec 7.0. Can you help?

The default setup that includes autoloader support will not work with this tape drive. Start by installing the autoloader. Next, in the Tapes applet in Control Panel add the oemsetup.inf from the \backup exec\loader directory. Two files (oemsetup.inf and scsichngr.inf) are present for installation. By default, setup uses scsichngr.inf, but this file won't work with the HP 7215. If necessary, drop the transfer rate to 10MB and disable sync negotiation on the SCSI controller. (I suggest you always use the oemsetup.inf file for setup; Seagate's support staff doesn't have much faith in the default setup.)

I'm having problems moving an existing Windows NT installation from an EIDE hard disk to a SCSI hard disk. I've previously moved NT installations from one EIDE disk to another EIDE disk without any problems using PowerQuest's DriveCopy software. Can you shed some light on this situation?

The system drivers that NT uses for EIDE hard disks and SCSI hard disks are different. I suggest you reinstall NT on the new disk.

You can try to fix the system. However, you need to use these methods at your own risk. Start by copying NT from the EIDE disk to the SCSI disk and reinstalling the software to the same directory. If the installation process sees the old directory, a reinstallation will provide the proper drivers in the new directory. I have used this procedure with some success. Alternatively, you can perform a fresh installation of NT on the new disk, back up the old disk to tape, and restore the old disk to the new disk with the exception of the system hive, which contains all the old hardware settings.

I'm having a hard time finding any substantial information about the advanced user right Act as part of the operating system. The only information I can find says this right is given for some subsystems and lets you act as a trusted part of the operating system (OS). As a developer, I've had problems with an application that runs as a .dll on Internet Information Server (IIS). To solve these problems, I've given this user right to the account that logs on to the Web server. What security exposure am I creating by granting this right?

You are correct in stating that little information is available about this specific user right. However, certain aspects relating to subsystems seem germane. I suspect your application is violating C2 security. I'm not sure how an intruder would find the account. However, an intruder that gains access with this account is at the OS level and can wreak havoc on the system.

Can you briefly explain the Windows NT logon process?

The following steps cover the NT interactive logon and validation process:

1. The user presses Ctrl+Alt+Del.

2. After the user enters a username and password, the logon process calls the Local Security Authority (LSA).

3. The LSA runs the appropriate authentication package (usually NT or LANManager based).

4. The authentication package checks the user accounts database to see whether the account is local. If the account is local, the authentication package verifies the username and password against those in the user accounts database, which is typically on a Primary Domain Controller (PDC).

5. After the authentication package validates the username and password, the Security Accounts Manager (SAM--which owns the user accounts database) returns the user's security ID (SID) and the SIDs of any global groups to which the user belongs.

6. The authentication package creates a logon session and passes the logon session and the SIDs associated with the user to the LSA.

7. If the LSA rejects the logon, it disallows the logon session and returns an error to the logon process. If the LSA accepts the logon, it creates an access token that contains the user's SID and the SIDs of Everyone and other groups. The access token also contains the user rights that NT assigns to the collective SIDs. The LSA returns the access token to the logon process with a Success status.

8. The logon session calls the Win32 subsystem to create a process and attach the access token to the process, thereby creating a subject for the user account. For an interactive NT session, the Win32 subsystem starts the user's desktop.

9. After the validation process gives an access token to the user's shell process (i.e., the process in which the desktop starts for the user), the process generates the desktop for that token. (This step explains why different users have different desktops--their SIDs are different.)

I'm trying to convert my company's Windows 95 systems to Windows NT 4.0. Our users rely on PowerPoint. Unfortunately, PowerPoint's autocorrect and spell-checking features don't work properly under NT. How can I solve these problems?

The problem you're describing affects the clipart gallery but can occur with the graphic import filters, the text converters, the autocorrect feature, and the spell-checking feature. Surprisingly, all these problems relate to access permissions to the NT Registry. Systems administrators typically implement security in a serious manner during installation of NT Workstation and don't provide all users with proper access to the Registry. Consequently, users have limited access to the NT Registry, and administrators and owners (i.e., those individuals who install particular programs) have full access to the Registry.

I assume you're experiencing a problem with PowerPoint 7.0 because powerpnt.exe in version 7.0 sends a request to the NT Registry for full access, which many users do not have (PowerPoint 7.0b does not make this request). On multiuser workstations with restricted user rights, the system rejects most requests for full access. Because the request is denied, the features, such as graphic import filters and text filters, I mentioned previously might not work properly.

The Registry access problem can occur in PowerPoint 7.0 under the following circumstances: An administrator performed the software installation and is therefore the owner of the rights for the software, or one user installs PowerPoint (and becomes the owner), and other users attempt to use PowerPoint features. To fix the problem, Microsoft endorses several procedures. You can update the PowerPoint installation to version 7.0b (which is the easiest method); make the User an administrator (this solution is not ideal because of security issues); or grant full permission to Registry keys with your favorite Registry editor, and perform the following steps:

1. Log on as an administrator, and run regedt32.exe.

2. Go to the following Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AutoCorrect.

3. Click Security, Permissions.

4. Click Add, Show Users, and add the appropriate users.

5. Assign each user Full Control to the Registry keys involved.

6. Click OK, and specify that you are changing permission on the subkeys.

7. Click OK, and confirm that you want to replace Permissions. (You can create a new group and add the users to the group and then assign group access to the keys.)

8. Repeat step 2 through step 7 at each of the following Registry locations: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Graphics Filters,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Proofing Tools,
and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Text Converters.

If the problem occurs on a non-multi-user workstation, you probably installed PowerPoint as an administrator but are now running it using a different user account. As the new user, simply run PowerPoint's setup again to register all aspects of PowerPoint to that user.

Can you shed some light on all the new Intel CPUs that have recently surfaced in the news?

Intel has delayed its RISC chip (code-named Merced), which is causing a major change in some other vendors' strategies (e.g., Compaq and Digital are pushing the Alpha). In regard to the Pentium II line, processors running as fast as 450MHz should be available by the time you read this. You can expect price drops in this market about every 6 weeks. I don't recommend using any of the CPUs without cache (i.e., Intel's Celeron) to run NT because the operating system (OS) functions best with cache.

On the server side, Intel had stopped producing the Pentium Pro processor and introduced the Pentium II Slot 2 design. The Pentium II Slot 2 processors will run at 400MHz or 450MHz and have 512KB to 2MB of cache. You can also scale Slot 2 systems to have more than two processors and have faster access to the memory bus. These designs cost more, and I suspect their prices won't fall as quickly as the standard Pentium II processors' price.

So, should you purchase new CPUs now or wait? The argument is never ending. Realize that speed is increasing and cost decreasing, at least for the near future for the Pentium II processors. Buy a machine with the fastest CPU you can afford in the near future. Among other things, NT 5.0 will appreciate it.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish