Unlocking Locked-out Accounts; NTBackup Can Alter Network Configurations

If you lock out accounts after a certain number of logon failures, you expect the account to remain locked out until the time period you define in your security policy expires. A bug in how the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in implements account changes causes the snap-in to clear the locked-out flag when you change the Password never expires or the Store password using reversible encryption account attributes. If you modify either of these fields, save the changes, and restart the snap-in, you'll see that the account is unlocked, even though you didn't clear this field. On October 3, Microsoft released a new version of dsprop.dll as a bug fix for this problem. You can obtain the update only from Microsoft Product Support Services (PSS); quote the Microsoft article "Locked User Account Is Unlocked If You Change Account Options".

NTBackup Restores Alter Network Configuration
If you use the NTBackup utility (ntbackup.exe) to restore the system state on a Windows 2000 machine, take note: The restore procedure has a bug that causes NTBackup to restore only part of the Plug and Play (PnP) database. Restoring the system state on a machine that has one or more network adapters can alter system network components: Network adapters might be missing or have the wrong name in Device Manager, or the system might have Layer Two Tunneling Protocol (L2TP) ports that weren't present at the time of the backup. In many cases, you might be unable to restore the system to its previous configuration (i.e., you might not be able to remove the incorrect or misnamed adapters in Device Manager, and you might not be able to configure the existing adapters). You'll encounter this nasty bug every time you try to restore the system state from a backup until you implement the workaround or install the bug fix.

If you manage only a few systems, you can work around these network problems by modifying the registry on the Win2K system that performs the restorations. Start a registry editor and locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\KeysNotToRestore registry subkey. Double-click the PlugandPlay value entry in the right pane to open the Multi-String Editor screen. The value entry should contain two strings: CurrentControlSet\Enum and CurrentControlSet\Control\CriticalDeviceDatabase. Delete the first string, CurrentControlSet\Enum, and reboot. After you make this change, run all the backups that are part of your standard production environment. You should then be able to successfully restore the system state; however, you'll encounter the network adapter restore problem every time you restore a system from a backup you created before making this change.

If you use NTBackup as your primary backup and recovery tool on many systems, call Microsoft Product Support Services (PSS) and ask for the NTBackup bug fix. For more information about this problem and fix, see the Microsoft article "Network Adapters Are Missing or Incorrect in Device Manager After You Run NTBackup to Restore System State Data".

The System File Checker and WFP
Windows File Protection (WFP) provides a built-in mechanism that, in most cases, prevents a hotfix, service pack, or application from replacing key system files with earlier versions of those files. WFP uses the system file catalog to verify that protected system files are valid. When you download and install a hotfix or service pack, the hotfix usually includes a catalog update, and a service pack always includes a catalog update that describes all the files in the service pack. Each file has a catalog entry that contains the current version number and a file signature (i.e., a checksum of the file's contents). Although unusual, catalogs occasionally contain incorrect version numbers or file signatures, which can cause problems immediately after an update or installation, during the next system restart, or when you run an OS utility or application. WFP protects all system files stored in the %systemroot%\system32\dllcache directory. When an upgrade or application attempts to replace a file that appears in the \dllcache directory, WFP permits the replacement only if the new file has the correct version number and signature.

The System File Checker utility (sfc.exe) is a WFP-based command-line tool you can use to verify and correct file version problems. This tool accepts the following command-line arguments:

• /scannow—scans all protected system files immediately
• /scanonce—scans all protected system files at the next boot
• /scanboot—scans all protected system files at every boot
• /cancel—disables any pending scans
• /quiet—replaces all incorrect versions of files without user intervention
• /enable—enables WFP for typical operation
• /purgecache—purges the file cache and scans all protected files immediately
• /cachesize=x—sets the size of the protected files cache in megabytes

Microsoft's documentation states that you can use System File Checker with the /scannow argument to verify that the correct version of system files are loaded. When you run this command, you see a WFP screen that monitors the progress of the protected-files scan. If the utility can't locate the correct version in the OS directory tree, it prompts you for a source location from which to copy the correct version. The documentation also states that the /purgecache argument flushes all cached files from memory and reloads the correct version.

Microsoft omits one important fact from the System File Checker documentation: The tool uses only the original installation catalog to validate and replace system files. I ran this utility on my Windows 2000 Service Pack 3 (SP3) system, and it prompted me five times at the beginning of the scan to provide the CD-ROM containing the original version of my OS. Because I couldn't tell which catalog System File Checker was using as a source, I simply canceled the request for each protected file. System File Checker might work on a system built with an integrated installation, but the tool isn't service pack–aware, which severely limits its value. If you use System File Checker to correct system file problems, you must reapply the current service pack after you restore protected files. Correcting a system file version problem from a backup or by reinstalling the most recent service pack is probably easier and faster than using System File Checker. You can read more about this tool in the Microsoft article "Description of the Windows System File Checker Tool".

When Add/Remove Programs Doesn't Respond
Have you ever clicked Add/Remove Programs, only to see a window appear for a second, then disappear? When you see this behavior, the most likely cause is an out-of-date system file. To confirm that Add/Remove Programs is functioning, start Task Manager and click the Processes tab. If you see mshta.exe in the process list, the Add/Remove Programs utility is broken. Microsoft recommends that you run System File Checker twice—first with the /purgecache argument, then with the /scannow argument—to correct this problem; I recommend that you ignore Microsoft's advice and attempt to correct the problem by reapplying the most recent service pack. If you follow Microsoft's suggestion, you'll replace a bunch of service pack files with their original versions, and all hell will break loose.

End of Article