• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    File System Recovery and Fault Tolerance

    The file system is the single most critical element of the operating system. If the file system gets corrupted, not only can data be lost entirely, it can be scrambled in ways that aren't immediately apparent. This can happen for a variety of reasons. A disk can crash or get large numbers of sector errors. You might lose power to the system thanks to a failed UPS (or no UPS at all) causing a total loss of cached data. A misbehaved driver might lock the system or run rampant over the file system metadata files. Or it might just be your time in the pit.

    Recovering a consistent file system has the same urgency for a system administrator as recovering a stable pulse and vital signs has for an emergency care physician. This section covers several checks you should perform to ensure stable operations, discusses fault-tolerance features designed to save the day in case of catastrophe, and covers the operation of the Windows File Protection service. Let's start with periodic maintenance and a familiar face, CHKDSK.


    The first line of defense for preventing file system crashes is regular maintenance. The maintenance tool in Windows Server 2003 has a venerable name, CHKDSK. This utility analyzes the file system for corruption and consistency and repairs anything it finds that is broken.

    The code that actually does the analysis associated with CHKDSK is contained in the file system drivers themselvesUfat.dll for FAT and FAT32, and Untfs.dll for NTFS. This code can be initiated in several ways other than running CHKDSK. You can use Explorer by right-clicking a drive, selecting PROPERTIES from the flyout menu, selecting the Tools tab, and then clicking Check Now under Error-Checking. Or, you can initiate a consistency check at boot time using AUTOCHK.

    Comparison of AUTOCHK and CHKDSK

    AUTOCHK is designed to run in real mode during system startup to prevent locked files from blocking the consistency checks. AUTOCHK cannot be run after the operating system loads. The Registry entry that controls AUTOCHK is as follows:

    Key:     HKLM | System | CurrentControlSet | Control | SessionManager
    Value:   BootExecute
    Data:    Autocheck AUTOCHK *

    Under normal circumstances, AUTOCHK runs only if the so-called "dirty" flag is set in the $Volume record, indicating that that the system shut down abnormally. If AUTOCHK runs every time your server restarts, you have a very bad problem. Look for a caching RAID controller that is not Windows Server 2003 compatible or some other explanation, and do so in a hurry. Many administrators have watched perfectly good file systems turn into something that looks like the aftermath of a Chinese New Year celebration by ignoring consistent AUTOCHK initiations.

    When AUTOCHK runs, it checks the disk in read-only mode and reports any problems to the Application log. Check the Event Viewer for details. If you get errors, you should restart again and run AUTOCHK in fixup mode (equivalent to CHKDSK /f) to correct the errors. This is covered in the next section.

    Using CHKNTFS to Configure AUTOCHK

    You can force AUTOCHK to run in fixup mode with the CHKNTFS utility. Here are the CHKNTFS settings and the syntax for setting AUTOCHK functions. In each case, <volume> can be a drive letter or a volume name:

    • chkntfs <volume> /c. Sets AUTOCHK to run in fixup mode for the specified volume or drive letter. This switch adds /m to the AUTOCHK entry in the Registry.

    • chkntfs <volume> /d. Returns the system to its default behavior of running AUTOCHK in read-only mode when the dirty flag is set.

    • chkntfs <volume> /t:time. AUTOCHK can take a long time to finish. It runs in real mode, so very little memory exists to help it progress quickly. On a system with a big RAID array containing thousands of megabytes of files, AUTOCHK can take several hours to finish. By using this CHKNTFS option, you add a countdown to AUTOCHK so that you can bypass the check if you are reasonably certain that no file system corruption is present. For example, if you are going to down a server to install a new network card, you can use the /t:time option to bypass AUTOCHK, thereby avoiding the lengthy delay. This option adds an AUTOCHKTimeOut value to HKLM | System | CurrentControlSet| Control |Session Manager.

    • chkntfs <volume> /x. Excludes a disk from AUTOCHK. Use this option with caution. If you forget you set this switch, the system does not do its necessary housekeeping checks at boot time. This option adds /k:<volume> to the AUTOCHK entry in the Registry.

    Functional Description of CHKDSK (AUTOCHK)

    When CHKDSK (or AUTOCHK) runs, it performs a series of consistency checks. The NTFS checks are as follows:

    Pass 1
    • Scans the MFT looking for active file and directory records and builds bitmaps of active MFT records and active clusters using the LCN information in the records.

    • Uses the bitmaps to validate the $Bitmap file in metadata. If a record is unreadable or has an incorrect format, it is identified as a problem.

    Pass 2
    • Scans directory records to make sure that each file entry references an actual file record and agrees with the directory reference in the file record.

    • Checks for circular references for subdirectories. A circular reference is a directory that thinks it is under itself as a subdirectory. Circular references are very rare but can result in the loss of a great deal of data by orphaning large chunks of the file system, so do not take them lightly.

    • Checks for consistency between filename attributes in the file records and the filename entries in the associated directory index. This pass can take many minutes, even hours, depending on the number of entries in the MFT and the complexity of the directory structure. The speed has nothing to do with volume size. A 32GB volume with 1000 files finishes in the blink of an eye. A 3GB volume with 100,000 files takes a long time.

    Pass 3
    • Scans security descriptors to ensure that every record references a security descriptor and that the entry agrees with the reference in the security descriptor itself.

    • If a Change Journal (also called a USN Journal) is associated with the volume, the system scans the log and verifies the index entries.

    Pass 4
    • Performs a disk scan and tries to read every sector that contains a file. Bad clusters are added to the $BadClus list. Data in the bad clusters is copied to a new cluster.

    Pass 5
    • Performs a disk scan of free space in the volume. Bad clusters are added to the $BadClus list.

    CHKDSK Switches

    Several CHKDSK switches affect how the scans are run. Two switches, /i and /c, were added in NT4 SP4 to speed up consistency checks by bypassing Passes 4 and 5. These switches also work for AUTOCHK:

    • /f. Runs CHKDSK in fixup mode. (AUTOCHK uses /p.)

    • /v. Displays cleanup messages.

    • /r. Performs a full disk scan looking for bad clusters. Any that it finds are added to the $BadClus file.

    • /l. Displays the size of the $Logfile. When paired with a :size parameter, such as /L:4096, changes the size of the $Logfile to the new value.

    • /x. Forces a volume dismount. Any users with open files lose their data. Using this option also runs CHKDSK in fixup mode.

    • /i. Skips internal consistency checks between the filename attributes in the file records and the associated filename listings in the directory index.

    • /c. Skips the directory loop (cycle) checks.

    An additional CHKDSK switch, /p, can only be used from the Recovery Console. This switch forces CHKDSK to run an exhaustive check.

    Recommendations for Running CHKDSK

    You should run CHKDSK periodically to find file system anomalies. You cannot run CHKDSK on a volume with active files, such as the system volume or a volume containing a database, because the files are locked. Use CHKNTFS to schedule AUTOCHK to run in fixup mode at boot time.

    If you have users who keep getting corrupted files on their XP systems, you can break them of the habit of simply turning their machine off by configuring AUTOCHK to run in fixup mode at every boot. Make it clear that the extra boot time in the morning is necessary because they didn't down their machines correctly the night before. They'll take the hint eventually.

    File System Logging

    Under most circumstances, CHKDSK or AUTOCHK running in fixup mode can correct all file system anomalies. But what happens if the file system is in an unknown state caused by a system crash or a loss of power? NTFS keeps a great deal of data in cache to improve lookup times and to time disk writes for maximum effectiveness. This so-called lazy write caching dramatically improves system performance, but at the cost of a somewhat lessened file system reliability.

    If the file system is put into an unknown state following a crash or lockup, AUTOCHK can rebuild the file system, but it goes about its work with painful slowness. This costs production time, not to mention the wear on the stomach linings and tempers of system administrators waiting to get their machines back online.

    Servers crash on occasion. This is a fact of life, so it makes sense to plan for that eventuality by putting in place a way to recover a consistent file system more quickly. NTFS does this with the help of a kernel-mode service called the Log File Service, or LFS. The LFS is a general-purpose logging service. NTFS is currently its only client.

    LFS Structure

    The LFS keeps a record of all disk writes that affect the core file system. It stores these records in a file called $Logfile, one of the MFT metadata files. The $Logfile consists of a long run starting at a position on the disk chosen to get the maximum performance from the file system.

    Most user data is not protected by the LFS. If you hit the big red switch on a server, data in the cache is lost. LFS will help get the critical files back to a consistent state, but you may need to wait for AUTOCHK to fix the user files.

    LFS Functional Overview

    The $Logfile consists of two parts: the restart area and the infinite logging area. The restart area (contained in buffers prefixed by RSTR) contains location information for data in the infinite logging area. A key component of the restart area is the checkpoint information. This tells the logging system those log entries that were flushed to the MFT and those that were not. The infinite logging area (contained in buffers prefixed by RCRD) works like an 8-track tape. When the log gets full, the log service starts at the beginning again, overwriting the oldest entries.

    When an update to the core file system occurs, the disk write is handed to the LFS for recording in the $Logfile. These critical updates include changes to attribute headers, security attributes, directory locations, and modifications to the MFT metadata files.

    Periodically, the log entries are flushed to the MFT and the checkpoint is moved. If the system crashes during this flushing operation, the LFS can recover a consistent file system very quickly, simply by finding the checkpoint and then walking through the last $Logfile entries. The LFS then works with the file system to purge any transactions that are not completely committed and recommit them again. The final condition of the MFT reflects the status of the file system at the time of the crash, excluding any commits that are in the lazy write cache waiting to go to the log file itself.

    System recovery using the log file can take a while on large volumes but not nearly as long as a full file system rebuild using AUTOCHK. If the log recovery fails, the file system performs a full rebuild. If this fails, the only alternative is recovery from tape. No controls and no Registry hacks are available for the Log File Service.

    The only index that is recovered by the LFS is the filename index in the directory records. Windows Server 2003 has several features that require special indexing of the MFT. Recovering these indexes with a full table scan is a tedious process. To help speed things up, the system has a new feature called the Change Journal, discussed in the next section.

    Change Journal

    Nobody likes to do a chore that doesn't need doing. For example, when the time comes to wash the dishes, do you unload your entire cupboard and scour everything you find? No. You only wash what's dirty, right? In our household, the definition of "dirty" is a dish that is in the sink. (Christine, my significant other, categorizes after-dinner dishes still on the table not as "dirty" but as "Bill's mess.")

    When it comes to file system chores, you have to do backups and virus scans and quota evaluations and content indexing and on and on. Most of these chores don't need to be done for every single file in a volume. They involve opening files and scanning their contents, an expensive proposition both in terms of CPU cycles and I/O. If you can skip files that don't need work, you'll free resources for other, more useful chores.

    This is the function of the Change Journal. It keeps track of changes to MFT records. Applications can use API calls to determine which records have been touched since the application last ran and only perform work on those files.

    The applications in Windows Server 2003 that make use of the Change Journal are as follows:

    • Content Indexing Service (CISVC). This service keeps a catalog of the contents of text files so they can be searched and retrieved quickly.

    • File Replication Service (FRS). The FRS takes data from one server and copies it to another server automatically. By referring to the Change Journal, FRS only copies those items that have been modified since the last transfer.

    • Volume Shadow Copy Service (VSS). This new service in Windows Server 2003 takes a snapshot of a volume for use in backups and in providing differential views of a shared folder.

    • Remote Storage Services (RSS). This service moves files from disk to tape but makes them available as near-online storage when users select the files from disk. The Change log improves recovery time and substantially reduces the risk of data loss by simplifying consistency checks.

    The Change Journal is a metadata record called $UsnJrnl stored under the $Extend metadata folder. Table 15.2 lists the events that trigger an entry in the Change Journal for indexed records.

    Table 15.2. Events That Trigger a Change Journal Entry























    The system keeps track of changes in the Change Journal using an Update Sequence Number, or USN. When an entry is made or updated in the journal, it gets the next available USN. This is similar to the way that the Active Directory tracks changes. The USN is a 64-bit number, so you have enough numbers to last billions of years.

    No troubleshooting tips are involved with operating the Change Journal. Rather, the Change Journal is completely transparent, just like the Log File System. No UI settings or Registry hacks are available. If the journal becomes corrupted or is accidentally deleted, the applications that rely on it are forced to do a full scan of the MFT to reindex. This might take a while. Look in the Event log if you think restarts are taking inordinately long.

    Windows File Protection

    One insidious form of file corruption comes when an application overwrites a critical system file with its own copy of that file. The copy comes from the master platform used to compile the application, and there is no guarantee that this platform was running the same binaries as your server.

    Nearly every system administrator has had a bad experience with applications that play games with core system services. You have a server that operated flawlessly for months and months. One day, you install a seemingly innocuous application and suddenly you enter Blue Screen purgatory.

    It is the job of the Windows File Protection service, or WFP, to stop this rampant trampling of system files. It does so by comparing the digital signatures in the critical system files with a catalog of their signatures that was included in the original setup files.

    If an application replaces one of the protected files, WFP checks the digital signature against the catalog. If the replacement file has the approved signature, WFP permits the file to remain. (This would happen if the developer built the installation package using a machine running the same operating system at the same service pack level as your system.)

    If the digital signature does not matchthat is, it is not in the catalogor the replacement has no signature at all, WFP retrieves a copy of the original file from a cache folder and overwrites the intruder. It writes an information record to the Event log to notify you of its actions.

    The following applications distribute executables signed by Microsoft:

    • Service Pack installation using Update.exe

    • Hotfix installation using Hotfix.exe

    • Operating system upgrades using Winnt32.exe

    • Windows Update service

    • Device Manager/Class Installer

    When you install a service pack, a new catalog file is added to those already on the system. The catalogs are stored in \Windows\System32\Catroot. The new catalog is given the name SP#.CAT, where # corresponds to the service pack number.

    The WFP system keeps a copy of controlled files in a compressed folder under \WINNT\System32\ DllCache. This folder contains a copy of every file installed from the Windows Server 2003 CD during Setup. When one of these files is updated using one of the four approved methods, the cached file is replaced with the updated file.

    Operational Description of WFP

    You can test the operation of WFP as shown in Procedure 15.3.

    Procedure 15.3 Verifying WFP Operation

    1. Open Explorer and navigate to the \WINNT\System32 directory. If Explorer is web-enabled, you are prompted to verify that you have business in \WINNT and in \WINNT\System32. This is your clue that the directories are on the list of "protected" directories in WFP.

    2. Scroll down to one of the system files installed during Setup.

    3. Right-click the icon for the file select DELETE from the flyout menu. Click Yes when asked to verify the deletion.

    4. Don't do anything for a while. Just wait and watch. In a few seconds, the icon reappears. This is WFP at work.

    WFP Elements

    The WFP does not run as a separate service. Instead, it is a core feature of the operating system. The controls are kept in the Registry under HKLM | Software | Microsoft | Windows NT | Current Version | Winlogon. The values are as follows:

    • SFCQuota. The amount of disk space allocated for the DllCache directory. The default value is FFFFFFFF, giving the DllCache folder a virtually limitless size of 4GB. You can get the same effect by entering 1.

    • SFCDisable. If you set the value to 1, System File Protection is disabled for the next restart. It is enabled automatically on subsequent restarts. Use this switch to replace files with vendor-authorized versions or to use checked versions for debugging.

    • SFCBugCheck. Under normal circumstances, if you attempt to replace or delete a protected file, the system warns you with a console message. If you set this value to 1, the system stops with a blue screen. This can be set on a desktop with a user who has a history of trying to change system files.

    • SFCScan. Configures the WFP to scan the DllCache for missing files at boot time. A setting of 1 scans files at every boot. A setting of 2 scans files once.

    Using the System File Checker, SFC

    You do not need to hack the Registry to change the WFP settings. A command-line utility comes with Windows Server 2003 to set these values. Called the System File Checker, or SFC, the utility can also rebuild the DllCache directory if files are accidentally deleted. The switches for SFC are outlined in the following sections.

    sfc /scanonce

    This option scans the contents of the DllCache to verify that they match the signatures in the catalog and then scans the files in the protected directories. This scan does not commence until you log in.

    While the scan is running, a message appears on the console asking you to wait. You can perform other tasks and run applications, but this slows the scan. If the system encounters a file that is missing in the cache or a system file that is the wrong version, it prompts you to insert the Windows Server 2003 CD so that the proper file can be restored.

    If you installed Windows Server 2003 across the network or from an I386 directory on the local hard drive, you must still have the CD to do the file protection restore. If the machine does not have a CD-ROM drive, your only workaround is to compare the contents of the DllCache with that of another machine and copy the missing files manually.

    sfc /scanboot

    This option performs a protected file scan at every boot. On servers administered by professionals, this is seldom necessary. Desktops, on the other hand, might need more diligent care.

    Use the /scanboot option if you have consistent problems with users who delete cached files and you want to make sure they go through the tedious process of correcting their own blunders. You can also use the /SFCBugCheck switch in the Registry to blue-screen the machine if the same users insist on playing with the protected files.

    sfc /quiet

    This option replaces missing files without asking for permission.

    sfc /cancel

    Use this option if you have the system to scan at the next boot, but then you change your mind.

    WFP Highlights

    The key points to remember about WFP are as follows:

    • WFP protects system files loaded during setup.

    • WFP only enables a few authorized executables to change system files.

    • Deleted or corrupt system files are replaced from an on-disk cache.

    • The SFC utility can manually scan system files and repair them.

      Previous Section Next Section