- Windows Vista: The Truth about Defragmentation

As long as there have been hard disks, there has been disk fragmentation. If you're concerned about your systems at all, you should be defragging them regularly. This probably reminds you of that flossing conversation your dentist has with you every year—you know the one. Well, defragmentation is just as important.

Unless your computer is sitting in the corner always turned off, it's getting more and more fragmented. In a moment, I'll show you how this happens, but first let's go over a little defragmentation history.

Defragmentation and Windows NT

Windows NT® didn't have a built-in defragmentation utility, and conventional wisdom at the time was that you didn't need one. After all, NTFS was built with optimization in mind, and it did not suffer from fragmentation as dramatically as a comparable FAT volume might have. But over time, even NTFS performance can suffer due to less-than-optimal file placement. This gave birth to a thriving market of third-party defragmentation tools. One of the most popular products among IT pros was the Executive Software (now Diskeeper Corporation) Diskeeper product. When Windows 2000 incorporated defragmentation functionality, Microsoft licensed the technology from Executive Software. The Windows® 2000 defragmentation functionality was available in its own Microsoft® Management Console (MMC) snap-in (dfrg.msc), which could be invoked by clicking on a volume or by manually running defrag.exe from the command line. Though no scheduling and only a constrained command line were available, many IT pros still created functional scripts to automate defragmentation using this built-in version. Defrag.exe in Windows XP and Windows Server® 2003 improved a bit upon the earlier version, but only provided limited automation—you still had to script it.

A number of vendors, including Winternals Software (my previous employer), produced software for the enterprise defragmentation space. Most of these products work the same way, with a centralized console, an agent of some type that lives on client systems (sometimes all the time, sometimes only on demand), and a structure for dictating when and how a defragmentation task runs.

Windows Vista® largely continues the trend of single-system defragmentation, while optimizing the defragmenter and including options such as defragmenting small file fragments (64MB or smaller), which speeds up defragmentation but leaves many larger file fragments across the disk. The defragmentation engine itself is more powerful in Windows Vista and Windows Server 2008 than in earlier versions of Windows. It also runs automatically and does not require any manual scheduling. But if you run a large organization or want to optimize your systems in ways that defrag may not provide by default, you may still need to license third-party software. And as in earlier versions, you may have difficulty defragmenting a volume where NTFS compression is enabled and used extensively. A third-party tool may be helpful in such a scenario as well.

How Does Fragmentation Occur?

Fragmentation occurs because files change over time. Ideally, Windows files themselves don't change. Or at least they don't change very often—really only with service pack and software update installations. Otherwise, the system files remain relatively constant. After performing a large update such as the installation of a service pack, fragmentation will naturally occur since the files being updated usually cannot be overwritten where they are on disk—and may require a reboot to be updated—resulting in further fragmentation.

User files and data (and the Windows registry), on the other hand, are subject to constant change. Reading, writing, editing, copying, and deleting files all the time causes a great deal of fragmentation, especially as the drive capacity is filled.

To visualize this, imagine a perfectly arranged disk, in which files occupy space contiguously with no space between them. Suppose you open a file and edit it, and then you try to save it. If the file has grown, Windows either has to save the file in its entirety somewhere else on the disk (imagine after file N) or save the newest data after file N. This means file 2 is now fragmented. If you now edit file 1, you'll have two fragmented files. Keep repeating this over time and you will end up with a considerably fragmented system where the drive has to look in multiple locations to access an individual file. With large database files, expansive hard disk files for virtual computing technologies, and copious amounts of video and audio stored on the average disk, fragmentation is common. Of course, the ever-larger size of current hard disks makes fragmentation less of a problem, but it doesn't make it go away. And older laptops with smaller hard disks will become less and less responsive, slower to boot, and take longer to open and save files.

The key concern isn't necessarily how fragmented the system is, but how fragmented the individual files are. Ever since the first disk defragmenters arrived on the scene with multicolored visuals, users have looked at them and thought, "I want a solid bar of color." But actually that is the last thing that you want. Some products try to make their disks appear as two blocks—one colored (file data) and one generally white (free space). Unfortunately, this is one of the worst things you can do to a disk if your intention is to minimize the frequency and cost of defragmentation. If you've aggressively compressed all file data to the front of the disk and removed much of the free space when you make additional edits to a file, all those edits will have to be written to the end of the file data, so by defragmenting in that way, you've actually caused fragmentation, beginning with the next file edit. Instead of two blocks of neatly organized file data, a good defragmentation results in an image that is not necessarily perfect. For an example, see Figure 1 for my test system before defragmentation. Then look at Figure 2 to see the same system after Windows had completed defragmentation.

Figure 1 My drive before defragging (Click the image for a larger view)

Figure 2 My drive after defragging (Click the image for a larger view)

Note that Windows focuses not on the fragmentation of the files across the disk, but instead focuses on the individual file fragmentation itself (see Figure 3 for the section of the defrag report on the Most Fragmented Files before I defragmented this system).

Figure 3 Defragmentation report

As a result, even after defragmentation, Windows will not show you a completely compacted set of file data at the front of the disk. Also note the large section of green data in both Figures 1 and 2. That is the Windows pagefile, which I'll discuss shortly. If you have hibernation enabled on your Windows system, it will show up similarly in a defragmentation.

Regular Defragmentation Is Essential

Just as with flossing, the main thing to remember is to defragment on a regular basis. It becomes even more important to defragment frequently on high-use systems such as servers, because if you wait, the process may take too long and leave your server unavailable or unresponsive (because defragmentation can take a considerable amount of time and certain phases of defragmentation can be CPU-intensive as well).

Even the best online defragmenters can't defragment everything. For example, they can't always defragment open or locked files (such as the pagefile or registry files) and must work around the hibernation file if it exists (which is as large as the RAM in use on your system). To optimize locked files, see the upcoming section on defragmentation tricks.

I think it's important to understand the myths and facts associated with defragmentation. Figure 4 and Figure 5 list some common topics I've heard brought up when discussing defragmentation and explain the real chances of these problems occurring.

Figure 5 Myths about defragmenting

Myth	Likelihood
Systems will crash.	Not likely—Crashes are usually due to driver or hardware issues (memory corruption, thermal issues causing reboots, or disk failure due to disk thermal abuse).
Applications will crash.	Not likely—As with an entire system, a properly engineered application should not crash due to fragmentation, so unless it can be constrained to be the cause, you shouldn't assume that fragmentation is causing it.
Registry corruption will occur.	Not likely (see above)—Fragmentation does not cause or lead to registry corruption.
Defragmentation should result in a solid bar in any visual representation of the disk.	Not likely—You should not generally squeeze all files on the system together unless you are specifically planning to image the system with a sector-based imaging tool that doesn't exclude free space or shrink or split the partitions. You need to get the files to the front of the disk; otherwise, aggressive file consolidation leads only to further fragmentation.

Figure 4 Common concerns about defragmenting

Concern	Likelihood
System performance will suffer.	High—Specifically depending on the usage of the system.
Recovering accidentally deleted files may become difficult or impossible.	High—Most file recovery tools depend on heuristics (to determine the data type) and file cluster proximity. Scattered files result in a more complex or impossible recovery operation.
It will be costly to defragment the system.	Medium—There is a direct correlation between how much the system is used and how much files change on the system over time. If users are aggressively editing files but saving them only to server shares, for example, you will not see much degradation over time.
Disk damage will occur.	Low—Not really likely. Again, the more you abuse a system (leave it on with disks powered up all of the time, editing, modifying, or deleting files) the more likely this is. But with today's hardware, you should not see this occur simply due to file editing.

Defragmentation as a Part of Your Infrastructure

You should seriously consider running a defragmenter on a regular basis on all of your systems. Your options are to use the defragmenter built into Windows or to look into third-party options. Basically, it comes down to how much engineering you want to do. Windows XP and later versions let you add defrag.exe as a Scheduled Task—the Knowledge Base article at support.microsoft.com/kb/555098 shows you how. Note that laptop defragmentation comes with some special considerations. You want to defragment a user's system when it is powered on—ideally via AC power—but you also don't want to take CPU or disk cycles when a mobile user is attempting to get work done. Unfortunately, however, when a mobile user isn't working on his system, odds are it's disconnected from AC power and either in standby or hibernate (which is powered off from the perspective of power management and Scheduled Tasks). At Winternals (as likely everywhere), we spent quite a bit of time trying to design an ideal mobile user scenario. If you're using Windows Vista, a solution using the built-in defragmenter and Scheduled Tasks, which has much better power awareness than earlier versions, may well provide enough of a solution. If not, a third-party solution for mobile systems may be necessary. Some of these actually kick off a defragmentation task, let you know that it ran, when it ran (and how often), and how long it took.

In addition to mobile scenarios, you will want to think about fragmentation above the file system. This isn't something you'll generally need to be concerned about with desktop or mobile systems, but servers, Microsoft Exchange, SQL ServerTM, or other data stores may require their own defragmentation. In such cases you'll need to decide whether that should be done before or after you've performed a file system defragmentation.

If you are using a third-party defragmenter, you'll want to ensure that it uses the Windows defragmentation API. Since Windows NT 4.0, Windows has had its own defragmentation API to prevent unexpected data loss. For example, if you're in the middle of moving a file and your system loses power, the last thing you want is an incomplete fragment move, which could result in data loss and even an unbootable system.

Finally, if you are using any virtual computing technology, you may want to consider how you manage the defragmentation of your virtual disks as well. They are just as likely to have fragmentation as a physical spindle, and in many senses may be worse due to size constraints. Plus, if your virtualization solution allows you to shrink disks or partitions, you may need to defragment first in order to free up space (or at a minimum, reduce the amount of time that a shrink operation will take).

Additional Tools

By now, you're surely convinced that defragmentation is an important and valuable function. Even if you do not use a third-party tool for defragmentation itself, you may want to consider a tool by Mark Russinovich called PageDefrag, which you can get from the Microsoft Sysinternals tool site (see microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx). As I mentioned earlier, the Windows page file cannot be defragmented while Windows is online. In fact, the same is true of the Windows registry files and the event logs. PageDefrag allows you to defragment these locked files before Windows has finished booting and locked these files, using a small driver. To use it, simply run PageDefrag and set it to execute either on the next reboot or on every reboot. When the system reboots (at the point in the boot process where you may have seen a disk check run before), it will defragment the files specified in the list (see Figure 6).

Figure 6 Files to defragment in PageDefrag

Once PageDefrag has completed, the system will finish booting normally. If you're looking for more on PageDefrag, Lance Whitney wrote about it in the September installation of Utility Spotlight (see technetmagazine.com/issues/2007/09/UtilitySpotlight). Note that PageDefrag is only supported on Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003—it is not currently supported in Windows Vista.

In addition to PageDefrag, there is another tool available from Sysinternals called Contig, which allows you to defragment a specific file manually (see microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx). This can be useful if a specific file was not able to be defragmented via a normal defragmentation task or if it has become fragmented since (but the remainder of the volume has not become as fragmented).

Contig can also defragment an entire directory or subdirectories by using wildcards. The following will defragment all files under the Windows directory, regardless of where they are located.

Contig –s c:\Windows\*.*

Applying the –v switch will make the operation verbose, and –q will make it run quietly.

- Windows Vista: Managing the Windows Vista Firewall

A while ago I wrote an article in my blog about the Windows Vista firewall. That post simply pointed out some of the nice features but did not offer up much in the way of deployment advice.

In this article, I go into more detail on some of the features in the Windows Vista® firewall that are specifically designed to ease enterprise management. And I will also be giving advice on how you can use them to make your job simpler and ensure your users are more secure.

With the recent release of SP1 for Windows Vista, you might expect enterprise deployment of Windows Vista to pick up. (It's common for enterprises to wait for the first service pack to be released before migrating to a new OS.) If you're one of the IT pros who are now looking a bit more seriously at Windows Vista for your enterprise environment, you should take a close look at the firewall. Once you realize what the Windows Vista firewall can do, you may want to renegotiate the agreement you have for that third-party security suite to remove the firewall from the package.

Windows Firewalls Then and Now

The firewall in the original release of Windows® XP left a lot to be desired. While it adequately matched the security functionality in commercial host-based firewalls at the time, it didn't add anything new or innovative.

The replacement that came in Windows XP SP2 was completely modified. It was specifically designed to ease enterprise manageability. The Windows XP SP2 firewall is very appealing in that it is lightweight, centrally manageable, effective, and unintrusive. But perhaps most important, it does something very critical: The Windows XP SP2 firewall protects the system at boot.

This last point is crucial. I have seen many systems in the past get infected during boot even with a firewall turned on. In fact, during the height of the Blaster epidemic, attack rates ran as high as one in four minutes. In other words, if you left an unprotected computer on the Internet it could have gotten infected, on average, in four minutes. And if you were relying on a firewall that did not protect the system at boot, 1 system out of 12 would have been infected at reboot. These figures were what drove Microsoft to ensure that the Windows XP SP2 firewall protected the system at boot.

In Windows Vista, the firewall received another complete makeover. The most obvious change, from a management perspective, is that the management interfaces of Internet Protocol Security (IPsec) and the firewall have merged. This is a very logical change. IPsec and the firewall are both designed to block things that are not allowed. The difference is that in the firewall, the parameters that define what is allowed are not very granular, while blocking or allowing large swaths of the address space in IPsec is cumbersome.

With the two features located in a single management interface, admins can make use of both technologies seamlessly, with less worry about whether something requires an IPsec rule or should instead have a firewall filter. In essence, you have a single view of the network attack surface of the system and this helps to minimize the risk of mistakes.

SP1 for Windows Vista adds some reliability enhancements to the firewall features. It also adds new algorithms, notably the Suite B algorithms, for use in IPsec. This is a set of encryption-related algorithms, comprising the Advanced Encryption System (AES), Elliptic Curve Cryptography (ECC), and Secure Hash Algorithm (SHA) 256 and 384.

Most importantly, however, Service Pack 1 adds support for Network Access Protection (NAP). NAP is a policy enforcement tool that ensures that managed and non-compromised clients are up-to-date with the latest security policies, updates, and anti-malware definitions before they are permitted to connect to the network. NAP cannot stop malicious hosts from connecting to the network, but it does ensure that all managed hosts are fully compliant so long as they are not actively compromised.

The Windows Vista firewall, called the Windows Firewall with Advanced Security, is also included in Windows Server® 2008. All the features are also manageable remotely and can be configured across a network using Group Policy.

Rule Types and Scenarios

The combination of firewall and IPsec functionality in the management interface means there are now two different types of rules: directional rules and connection rules. The directional rules are standard firewall rules that define which traffic to allow in the appropriate direction. The connection rules define the protection parameters for connections between computers. To draw an analogy, the directional rules are a bit like the firewall rules you know in previous firewalls while the connection rules are more like the IPsec rules used in conjunction with the firewall in Windows XP SP2.

By combining the firewall and IPsec into the same interface, several very interesting scenarios are enabled. For example, isolating systems from each other on the network is one of the most valuable security concepts available today. Microsoft calls this "Server and Domain Isolation."

Server and Domain Isolation uses both IPsec and firewall functionality. Recognizing this, the new firewall management interface includes specific functionality for isolation rules. These are appropriate if, say, you want to restrict the connection based on attributes of the source or destination systems, such as domain membership.

As you can see in Figure 1, the New Connection Security Rule Wizard starts out by asking what type of rule you want to create. If you select Isolation, the wizard preconfigures certain settings that are appropriate for an isolation rule.

Figure 1 Using the New Connection Security Rule Wizard to create an isolation rule (Click the image for a larger view)

You may also notice in Figure 1 that the isolation rule mentions health status. The rules used for Server and Domain Isolation are actually the same rules you use for NAP.

You can't enforce authentication for some types of traffic. For instance, you probably do not want to require authentication for DNS resolution. For the endpoints of that type of traffic, you need an authentication exemption rule. An authentication exemption rule is exactly what it sounds like—it exempts the traffic from IPsec requirements.

A server-to-server rule is a bit misnamed. While more commonly used with servers, it can also be used with clients. A server-to-server rule simply configures a connection to require authentication. This is different from an isolation rule in that not only does an isolation rule require authentication, it also requires fulfillment of some additional criteria, such as domain membership or health state.

A tunnel rule essentially defines a site-to-site Virtual Private Network (VPN) and the tunnel between the gateways. Tunnel rules are rarely used with Windows Vista, as it is unlikely that you will use Windows Vista in a gateway capacity. You can create fully custom rules. This lets you customize every parameter of the rule.

Rule Ordering

The rule ordering is a bit complicated at first glance. The key to understanding rule ordering is to first forget about ordering. It is not so much about ordering as it is about a matching selection. Consider inbound traffic as an example. Inbound traffic that does not match any rule that allows it is blocked by default. You may consider that as an ordering that says "Allow rules are considered first," but that assumption would be incorrect. If a specific packet is matched by both an allow rule and a block rule, the block rule will win. That means that the matching, in simple terms, is:

1. Block rules. If a packet or connection matches one of these, it is discarded.
2. Allow rules. If a packet or connection matches one of these, it is allowed.
3. Default directional profile behavior. If no block or allow rules match, the traffic will be treated according to the behavior specified as the default for traffic in that direction in that profile. In the inbound direction in all profiles, that means blocking the traffic in a default configuration. In the outbound direction, by default, it means allowing the traffic in the default configuration.

The matching process is moderated by authenticated bypass (IPsec) rules. Using that type of rule, all authenticated traffic that matches the other parameters of the rule is permitted, regardless of whether it matches any other rules or not. Authenticated bypass rules are directional rules that have the Override block rules option selected, as shown in Figure 2. Those are considered first, so as to allow authenticated traffic to always reach the system. This is key to allowing you to easily allow traffic from authenticated hosts but block traffic from everyone else. You can consider that rule as 0 in the ordering. Thus, the complete rule order list looks like this:

Figure 2 Checking the Override block rules option to configure an authenticated bypass rule (Click the image for a larger view)

0. Authenticated bypass rules

1. Block rules

2. Allow rules

3. Default directional profile behavior

It does not really matter if there are multiple rules within each class that match the traffic pattern. As soon as any rule matches the traffic, rule processing stops.

Public, Private, and on the Domain

Networking Resources

• TechNet Security Center
• Using the Netsh Advfirewall Command-Line Tool
• Security Rules for Windows Firewall and for IPsec-Based Connections in Windows Vista and in Windows Server 2008
• Security Watch Using SCW on Windows Server 2008

The new firewall has three profiles: public, private, and domain. The Windows XP SP2 firewall, on the other hand, had two network profiles: standard and domain. The domain profile is automatically invoked when the computer can find the domain controller. In Windows XP, the standard profile was used otherwise. This provided powerful functionality for a security admin who could lock the computer down completely when it was roaming and still allow all the remote management functionality that's necessary when on the organization's network. But this approach presented certain problems for some users—in particular, those with personal networks at home. Because the standard profile was always used if the system was unable to reach the domain controller, the system was locked down from the user's home.

The new private profile included in Windows Vista helps to resolve this issue. Now when you connect the system to a new network, it will ask whether that network is public (this is simply the new name for the former standard profile) or private and configure the system appropriately. The system remembers this each time it connects to that particular network, based on network parameters presented to it by the infrastructure servers on the network. This is not foolproof by any means, but it helps in that it allows more networks to be better locked down.

The detection logic for whether the system is on the domain has also been improved. The result is a faster, more reliable transition and fewer systems that think they should be using the public or private profiles when they are actually on the domain.

You can tie your rules to a particular type of network, preventing the system from volunteering too much information and trying to connect to systems on untrusted networks. This is one area where the integration of the firewall and IPsec starts to pay off.

Using these new rules, you can provide some restrictions that were not previously possible. For instance, for many years attackers have attempted luring attacks to get users to make Server Message Block (SMB)—for Windows networking—connections to untrusted hosts, thereby forcing an authentication sequence giving them a challenge-response pair that can be used to crack passwords. Older versions of this attack were also used to downgrade to clear text authentication or to reflect the user's challenge-response pair back to the originating computer. The former technique was broken years ago. The latter technique was mitigated with Windows XP SP2—but keep in mind that volunteering challenge-response pairs is nevertheless unwise.

To prevent this, you could use another new function in the Windows Vista firewall—outbound filtering. An administrator could decide, for instance, to block all outbound SMB connections (those terminating at ports TCP 135, 139, 445, and UDP 137, 138, 445) in the public profile. This would make it more difficult for a system to be used in a luring attack to gain challenge-response pairs, or prevent it from accessing untrusted Windows File Shares on the Internet.

Again, this is certainly not foolproof. For example, if the system has already been compromised, this rule would not stop the system from communicating out as the attacker could simply disable the rule. However, it can be very useful as a measure to protect well-behaving but potentially exposed systems.

It is important to mention in this context that, just like in Windows XP SP2, only one profile can be active at a time on Windows Vista and Windows Server 2008. If there are two network interfaces live in the system and one of them is on the domain while the other is on a public network, the public firewall profile will be applied to both. The most restrictive profile will always be used. As you might guess, the public profile is more restrictive than the private profile, and the private profile is more restrictive than the domain profile. So beware that the outbound SMB blocking rule can break much traffic over VPN connections.

To enable traffic over a VPN connection when the computer is on a public or private network, you create directional rules that apply only to VPN interfaces. For this to work, the VPN interfaces must be recognized as such by Windows. If you do not use the Microsoft® Routing and Remotes Access Services VPN server, test this functionality before deploying it widely. It is primarily a problem with inbound traffic to the client and any custom outbound rules you create.

Building Firewall Rules

Building a firewall rule is much easier in the new firewall. The New Rule Wizard, shown in Figure 3, allows you to define all the usual types of rules. And it includes predefined rules for particular services.

Figure 3 Predefined rules in the New Rule Wizard (Click the image for a larger view)

The predefined rules are particularly important. Server isolation is essentially about restricting services such that they are only available to those systems that need to use them. On server products, the Windows Security Configuration Wizard (SCW) can be used to make this easier, although still not quite pain free. (I discussed the SCW in the March 2008 issue of TechNet Magazine.)

But the client versions of Windows have not had similar functionality until now. When you use the predefined rule type, much of the hard work is done for you—the task of determining which endpoints a service uses. The firewall is not only application-aware in that it knows which program the "iSCSI Service" represents; it also contains predefined rules that describe certain functionality. This allows you to focus on which computers need to be covered in a rule. That is still a difficult and time-consuming task, but at least one that is unique to your environment.

There is also a custom rule (obscured by the dropdown in Figure 3) that gives you all the flexibility you can expect from an authenticating firewall. For instance, if you want a rule that only allows IPsec encrypted traffic, you would select the option to only allow secure connections on the Action page of the wizard shown in Figure 2.

When you select this, you also have the option to turn on encryption. If you leave this option blank, the traffic will use ESP-NULL (encapsulated security payload with a NULL key). This is the recommended way to use IPsec for authentication. It allows most network management tools to keep working because the traffic is traversing the network in the clear, and if you ever want encryption, you can simply check the box.

In many situations, encryption of network traffic is not nearly as important as not accepting any traffic from malicious hosts. Encrypting traffic on the network blocks a bad guy who has gained access to the network itself from seeing what is in the packet. Requiring authentication may prevent you from sending the packet in the first place and from getting attacked. Granted, there are many situations where network-level encryption is important, but there are also many other situations where you only need authentication.

Building Domain Isolation Rules

In most environments, you want a limited number of computers to be able to send traffic to a workstation. At the very least, all workstations should be configured with domain isolation rules. This was complicated in Windows XP, but it's easy in Windows Vista.

First, open the management tool of your choice and select the Connection Security Rules node. Then right-click on the node and select New Rule and you get the dialog shown in Figure 1. Select Isolation rule and click Next. You now have to select whether you want enforcement of the rule or not. In most cases on workstations, you will want to require authentication for inbound traffic. This prevents any computer that is not domain joined from sending traffic to the workstation. However, in order to request services from infrastructure services, the system must permit some outbound traffic to pass in the clear. The best option, therefore, is to require authentication for inbound connections and request authentication for outbound connections.

Next, pick the authentication method. The default selection is called, well, Default—not a particularly helpful title. You can configure the default authentication method on a per-computer basis in the IPsec properties (accessed by right-clicking on the Windows Firewall With Advanced Security node and selecting properties). The default authentication method is always Kerberos because this is the simplest and most secure. However, for clarity's sake, I recommend that you actually select it when you build your rules. Normally, you want to only authenticate the computer, not the user as well. If you require both, you may be unable to accept certain kinds of management traffic, such as anonymously transmitted SNMP traffic.

After you've selected the authentication method, all you need to do is select which profiles you want this rule to be available in. Because it is a rule that applies to domain joined computers, which can present a Kerberos ticket, it makes no sense to open this particular hole in either the Private or Public profiles. Save the rule, and you are done.

Basic isolation rules are not complicated any longer. However, to take advantage of the power of IPsec for isolation, you need to implement server isolation, even on your workstations. Doing so, you can restrict your workstations from listening to other clients. Instead, they will only respond to the appropriate management stations. Imagine how much less the impact of various malware breakouts would have been had client systems refused to listen to other clients.

Scripting the Firewall

The new firewall comes with a substantial API that allows you to script both deployment and assessment. Ideally, you should use Group Policy for deployment, but since Group Policy is not always available, it is important to have a proper API-set to configure the firewall. The APIs are grouped under the INetFWPolicy2 set of APIs. The Software Development Kit and the MSDN® Library contain more complete details on how to use them, but a few examples help illustrate the point.

One common sample is the need to determine whether a group of rules is turned on. Say, for instance, an application or administrator needs to determine whether file and printer sharing is allowed from a system. This can be accomplished through INetFWPolicy2::IsRuleGroupCurrentlyEnabled. Figure 4 provides a VBScript sample that demonstrates this function.

Figure 4 Using INetFWPolicy2::IsRuleGroupCurrentlyEnabled

' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
   fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if

Now, if file and printer sharing is off and you need to turn it on, you first need to ensure that this can be done and will not be over-ridden by Group Policy. This is done with the INetFWPolicy2::LocalPolicyModifyState API. A skeleton, which can be filled in with actual code, is shown here:

Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
 Case NET_FW_MODIFY_STATE_OK
 Case NET_FW_MODIFY_STATE_GP_OVERRIDE
 Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Command-Line and Interface Types

No firewall would be complete without a proper command-line for management. There is a sub-context under netsh, called advfirewall. The advfirewall context gives you command line access to everything you can do in the graphical UI. For example, if you want to implement the outbound block on port 445, you can run the following command from an elevated command prompt:

netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any

You need to then run the same command, replacing TCP with UDP to complete the block. At that point, you have completed implementation of the rule.

One cool feature in the firewall is the ability to configure rules based on the network interface type. Recall that some rules may impact VPN connections. As long as Windows recognizes the interface as a VPN interface, you can use this type of rule to exempt traffic over that interface:

netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS

You can do this in the GUI as well, but not until after you create the rule. You then have to right-click on the rule, select Properties, and click on the Advanced tab. There you find an Interface types section where you can select the right interface types.

Outbound Filtering

The lack of outbound filtering in the Windows XP SP2 firewall was held out as the primary proof that the built-in firewall was inadequate for security. There must be thousands of articles written about how insecure the Windows XP SP2 firewall is due to its lack of outbound filtering. This is in spite of the fact that no firewall on Windows XP could securely provide outbound filtering.

The fundamental functionality that transforms outbound filtering into a useful security feature from a mere speed bump—or policy enforcement tool, as I used it earlier—simply does not exist in Windows XP. It does exist, however, in Windows Vista. It is only logical, therefore, that the new firewall makes use of this feature. By default, most inbound traffic is blocked and most outbound traffic is allowed.

By default, outbound filtering in the new Windows Vista firewall blocks only unnecessary traffic from services. This is actually all that can be done to provide protection against a compromise on the host that provides the outbound filters, and doing this on Windows XP would have been meaningless.

Services in Windows Vista can run with a highly restricted token. In essence, each service has its own security identifier (SID), which is unique to that service. This Service SID can be used to restrict access to resources, such as network ports. This is the same functionality we saw earlier when we looked at restricting traffic to users. This means that even though two services may run as NetworkService, they cannot manage each other's processes and the firewall can be configured to allow only one of them to communicate out. If the one that is blocked is compromised, it cannot hijack the allowed service and use its allowed port to communicate out because the port is restricted by Service SID.

This functionality is another one of the very cool security features added to Windows Vista, and the new firewall uses it to actually provide real security value by outbound firewall filtering.

In fact, firewall filtering on service SIDs is enabled by default in the new firewall. However, there is no GUI to configure it. The rules are predefined in the HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices registry key. You should be very careful, however, with modifying that key manually, as this is unsupported.

How Much Security Can Outbound Filtering Provide?

A matter of significant misunderstanding in the security community is how much security value is actually offered by outbound filtering. I have mentioned two scenarios so far that provide security through outbound filtering, but both rely on new functionality in Windows Vista that was not previously available. In spite of this, there is a general perception that outbound filtering is generally good and should be a key factor in firewall purchasing decisions.

Ironically, in many organizations, outbound filtering capabilities drove the purchase decision, and then outbound filtering wasn't used once the firewall was implemented. This is misguided and leads to a waste of money and effort from the Information Security group. It seems to be driven more by a desire to feel good about doing something security-related than by actual analysis of a real threat. Far too often, the desire for this type of "security theater" drives decisions that should instead be driven by facts.

There is a very simple fact about outbound filtering that its proponents fail to take into account. The usual argument from the host-based firewall vendors is that if a system is compromised, whether by a worm or by an interactive malicious user, outbound filtering will stop the worm from infecting other systems or will stop the attacker from communicating out. This is not true.

What is true is that, all else being equal, outbound filtering would have stopped some historical malware. However, if Windows XP had come with outbound filtering, the worms we have seen so far would more than likely have been written to turn it off or else to circumvent it.

On Windows XP (and earlier versions of Windows), any worm running as a service (and all the common worms that come up in conversation did run as a service), could have done this. The only reason they did not is that there were virtually no environments using outbound filtering and therefore it was unnecessary to disable it. In an interactive attack, the attacker can circumvent outbound filters at will. If the attacker has the ability to run arbitrary code, this is easy. But if necessary, the attacker can also lure the user into circumventing the filters.

Circumventing outbound host-based firewall filters can be accomplished in several ways, depending on the scenario of the actual attack. The simplest way to go about it is to "ask" an over-privileged user to do it for you. Too many environments still run their users as administrators. Those users have the right to circumvent security policies at will. All the attacker needs to do is present the user with a choice between some intangible and non-immediate security benefit and something the user values more—the proverbial naked dancing pigs.

In many cases, the user has been so inundated with these types of dialogs that they quickly click without actually comprehending what is happening. This is problem number one with outbound filtering. Given the choice between security and sufficiently enticing rewards, like naked dancing pigs, the naked dancing pigs will win every time because the vast majority of dialogs asking users to make security decisions are devoid of any information that would enable them to actually make such a decision.

Presenting dialogs, asking for security decisions, with sufficient information to base that decision on is much harder than it sounds because it would require the security product, such as the firewall, not just to understand ports, protocols, and the application that is making the request, but also to understand what it is the request really is trying to do and what that means to the user. This information is very difficult to obtain programmatically. For instance, the fact that Microsoft Word is attempting to make an outbound connection is not nearly as interesting as what exactly Word is trying to do with that connection.

We need to reduce the number of meaningless dialogs, not increase them, and outbound filtering firewalls do not help with this. To get a feel for the state of the art in providing users with valuable information, I went and looked at the sales documentation for a major host-based firewall vendor. The glossies tout the firewall's outbound filtering capacity and advising capability. The advising capability detects what the user is trying to do and gives appropriate advice. Or so the theory goes. The text in the brochure was accompanied by a screenshot that says: "Advice is not yet available for this program. Choose below or click More Info for assistance." It seems that even in the marketing material, vendors can't produce informative dialogs.

Since users do not possess sufficient information to make the right security decisions, it would then be incumbent on the administrator to configure all outbound filtering because the end user is not able to. This increases the administration burden of the administrator infinitely.

Even if the user does click "No. Bug me again later" when asked by the firewall, the malware can usually step right around the firewall. As long as the user whom the malicious code is executing as can open outbound connections on some port, the evil code can simply use that port. Thus, any process can piggyback on an existing process. That is allowed on down-level operating systems. Starting with Windows Vista, the processes can be suitably restricted, which is why services, which are the ones that are restricted by default, are blocked using the outbound filters by default.

Unfortunately, most people think outbound host-based firewall filtering will keep a compromised asset from attacking other assets. That is not possible. Putting protective measures on a compromised asset and asking it not to compromise any other assets simply does not work. Protection belongs on the asset you are trying to protect, not the one you are trying to protect against! Asking the bad guys not to steal anything after they have already broken into your house is unlikely to be as effective as keeping them from breaking into the house in the first place.

- Windows Vista: Backup Technologies

Too many people don't think about backing up their data until it's too late and the data has already been lost. This shouldn't ever be the case, but, unfortunately, it is. Windows Vista aims to make backing up easier, with a full range of features to seamlessly protect your data. The familiar

System Restore has been redesigned to be more robust and to support more system repair scenarios. File Backup has been improved to make data protection simpler and more thorough, and two new features, Windows® Complete PC Backup and Restore and Shadow Copy, have been added.

All of these features rely on Volume Shadow Copy Service in one way or another. This is a service that creates point-in-time copies (referred to as "shadow copies") of a volume and keeps track of changes made between shadow copies.

While these four features, all of which are available from the new Backup and Restore Center (see Figure 1), all allow you to back up and restore data, each is very different. But together they provide broad protection against various forms of data loss throughout the lifetime of your computer.

Figure 1 Backup and Restore Center in Windows Vista (Click the image for a larger view)


File Backup
Suppose I buy a new laptop. After copying various files—photos, Microsoft® Word documents, and so on—to my system, installing applications, and downloading the latest Windows updates, I decide to do a file backup. So I connect an external hard drive to the laptop and go to the Backup and Restore Center. When I click the Back up files button, I am presented with a wizard that guides me through the setup. It asks me for the backup target (in this case, the external hard drive), categories of files to back up (such as Pictures), and when to perform the backup.

File Backup uses a category-based approach for specifying what files to back up. While the source must be NTFS, the target hard drive can be either NTFS or FAT formatted. The determination of whether a file is associated with a particular category is based on three factors: MIME type, application association, and file extension.

If you want to back up files that do not fit into any other categories, choose the Additional files category. This includes files with extensions that are not recognized by Windows. It does not, however, support executable and system files. Such files are not backed up by this feature because they rarely represent user data. If you really do want to back up system and executable files using this mechanism, you can place them into a .zip file and select the Compressed files category in the wizard.

As this is my first time using the backup features on my new laptop, a full backup—which is a complete backup of all the files from the selected categories—is performed right away. Thereafter, only incremental backups are performed. The term incremental in the context of File Backup refers to keeping track of new or updated files only. For example, if you have an old Word document and then make some changes to it, the File Backup tool would keep complete copies of both the old and updated document. (The collection of a single full backup and the sequence of incremental backups created thereafter are referred to as a backup set.)

Rather than performing incremental backups indefinitely, you should occasionally perform full backups. Prompts to do so are based on factors such as how long since your last full backup, how many files you are backing up, how many CDs or DVDs you have backed up to, and so on. This is to ensure that a full, baseline backup is always available.

Data being backed up is stored as .zip files (with a maximum size of 200MB each). This makes the data more universally accessible. For example, you can restore the data to a machine that is not running Windows Vista by browsing directly through the backup media. The backup data is stored in separate files and can span multiple discs. If one disc was to fail, backup data on the other media is still accessible.

In File Backup, Volume Shadow Copy Service is used to create consistent copies of files that are open or in use by applications. During the backup process, the backup app reads from these consistent copies. This is handy, for example, when backing up a .pst file that is constantly opened by Microsoft Outlook®. Volume Shadow Copy Service ensures the backed-up .pst file is in a consistent state so that it can be accessed upon restore.

File backups aren't deleted automatically. However, you can delete file backups manually if you're low on space. A word of advice: you should always delete an entire backup set as opposed to deleting individual incremental backups.

As an aside, I should point out that you should avoid copying a file backup to a different location. If you must do so, keep in mind that this will only work if you move a single original backup media to another single destination media. For example, you can copy backup data from one CD to one DVD, but you cannot copy backup data from multiple CDs to one DVD. When you move a backup, you must copy the backup folder with your computer's name and the mediaid.bin file, both of which are located in the root of the backup media. Note that if you want to restore a file that has been moved, you must select Advanced restore | Restore files from a backup made on a different computer from the backup control panel to reach those files, since the backup catalog on the computer will not know of this new backup location.

Complete PC Backup

With my new laptop all set up and configured, I want to do a complete backup, protecting everything including the OS, the apps I've installed, configuration settings, and updates. I use the Complete PC Backup feature, which can then be used to recover my machine in case of a hard drive failure or other disaster. I wouldn't have to reinstall all the apps individually and redo all of my configuration settings. On first run, this feature performs a full backup of all blocks across the volumes I've selected, minus any blocks that do not have information stored. Subsequent backups are differential at the block level (more details about this in a moment).

After performing the backups, the control panel of the Backup and Restore Center is updated (see Figure 2). It now provides such information as when the backup was performed and where it was stored.

Figure 2 Backup and Restore Center provides details about previous backups (Click the image for a larger view)

While both perform backups, Complete PC Backup works totally differently from File Backup. Complete PC Backup creates a block level image backup of the entire computer in a virtual hard drive (.vhd) format. During the first full backup, the engine scans the source disk and copies blocks that contain data into a .vhd file stored on the destination disk. Although the backed-up data is not compressed, it is compact.

The next time a Complete PC Backup is performed, only new and changed data is written to the .vhd file, and old data on the same block is moved to the shadow copy storage area. Volume Shadow Copy Service is used to compute the differences between snapshots taken as well as to handle the process of moving the old data out to the shadow copy area on the destination disk (see Figure 3). This approach makes the backup fast (since only changed blocks are backed up) and efficient (since data is stored in a compact manner). Note that the backup application defines the maximum amount of shadow copy storage space available on the destination disk. For a step-by-step procedure on using the Complete PC Backup system regularly or automatically, see the sidebar "Scheduling Complete PC Backup."

Figure 3 How data moves in a Complete PC Backup and Restore (Click the image for a larger view)

When restoring data, blocks are restored to their original location. If you want to restore from an older backup, the engine reads from the shadow copy area and restores the appropriate blocks.

Note that Complete PC Backup can only back up NTFS-formatted disks. If the backup destination is a hard drive, it too needs to be NTFS-formatted.

System Restore

System Restore is enabled by default. I access the System Restore wizard by choosing Repair Windows using System Restore, available on the upper-left part of the Backup and Restore Center (it can also be accessed in the Accessories\System Tools folder in the All Programs portion of your Start menu). If I select "choose a different restore point" and click Next, I can see that restore points have already been created at various points while I was setting up my laptop, installing applications, and performing backups.

Restore points are turned on by default only on the boot volume, even on a system where the hard disk has multiple volumes. Restore points are automatically created during application and driver installations and daily across the selected volumes (if a restore point has not already been taken on that day). Restore points can also be created manually by choosing the System Protection option in the System control panel applet. Shadow copies created during File Backup and Complete PC Backup can also be used as restore points.

In Windows XP, System Restore uses a file system filter to keep track of system file changes. In Windows Vista, System Restore uses Volume Shadow Copy Service to keep track of block-level changes over the selected volumes. This makes System Restore more robust and allows it to support a broader range of repair scenarios.

Also new, System Restore can now run while your regular Windows installation is offline. This is done using Windows Recovery Environment, allowing you to repair your system even if Windows is unbootable.

Shadow Copy

Shadow Copy is nearly invisible. It is enabled by default and requires no input on the user's part. If a user ever needs to restore a file, that's when she is likely to first take notice of this feature. It essentially exposes the point-in-time copies of files that are created by Volume Shadow Copy Service.

Shadow Copy Space Management

There are storage spaces set aside for shadow copies both on the live volumes and on the backup disk for Complete PC Backup. You can check the used, allocated, and maximum shadow copy storage space values by running the following command from an elevated command prompt:

VSSAdmin list ShadowStorage

Used indicates how much space is currently taken up by shadow copies; allocated indicates the amount of space reserved for shadow copies (and so cannot be used for other purposes); maximum is the size limit that shadow copies are guaranteed to stay under.

Space allocation for shadow copies is automatic, meaning it cannot be set by the user. New space is allocated in fixed increments whenever the space previously allocated is used up. This is why the value shown for used space is always less than the value you see for allocated space.

For the live volume, the maximum shadow storage space allowed is determined when the first shadow copy is created—typically when System Restore is first enabled and a restore point is created during setup. The value is set to 30 percent of free space or 15 percent of the overall size of the volume—whichever is less. This maximum size is static. It will not change when more or less free space is available, nor will it change after the size of the volume has been adjusted.

However, you actually can manually adjust the size of this storage area by using the VSSAdmin tool from an elevated command prompt. For example, the command to increase the maximum storage size to 15GB on C:\ would be:

VSSAdmin Resize ShadowStorage /For=C: /On=C: /MaxSize=15GB

This tool originated on Windows Server®, where shadow copies for a particular volume could be maintained on another volume. In Windows Vista, shadow copies for a volume are kept on the same volume. Hence, the "for" and "on" volume has to be the same.

The backup destination disk for Complete PC Backup, on the other hand, has a fixed maximum shadow copy storage size of 30 percent of the disk space. This value is controlled by Complete PC Backup and cannot be changed manually. This shadow copy storage space is used for storing incrementals for Complete PC Backup.

Up to 64 shadow copies can be kept on a volume at any one time, provided there is enough space in the shadow copies storage area. Once the maximum space limit is reached, older shadow copies are deleted to make room for the new ones. Therefore, old restore points for System Restore are deleted when the shadow storage limit on the live volume is reached and old Complete PC Backups are deleted when the limit is reached on the backup disk. In addition, storing and editing other data on the backup disk may interfere with the normal process of aging old backups, causing old backups to be deleted at an accelerated rate.

Restore a File with Shadow Copy

Now, imagine I've had my laptop for a while and I've been using it to create some presentations. I've finished the presentations and passed them along to my clients. A month has passed, I'm onto new projects, and I've since deleted these files. Then my manager asks me for a copy of the old presentations. This is where Shadow Copy really comes in handy.

There are two ways to look for copies of deleted files. First, if I know where the file had been stored, I can simply right-click the folder that contained the deleted file and select "Restore previous versions." From there, I choose a date that contains the desired version of the deleted file (see Figure 4), click open, and then copy the target file to another location on the live volume. This copy operation is as fast as a regular file copy.

Figure 4 Restoring a file that was deleted (Click the image for a larger view)

If I have forgotten where the file was stored, I can open up the previous version of the closest parent folder in the file tree and do a search from there. For example, if I have forgotten the specific folder but do know it was in some subfolder located within Documents, I can search the previous version of Documents by typing the file name (full or partial) in the search box located at the top right-hand corner of the Windows Explorer window, as shown in Figure 5. Note that the search functionality for shadow copies does not work at the root folder. And since shadow copies are not indexed, the search time can be longer than searching on a live volume.

Figure 5 Searching for the previous version of a document by typing a partial file name (Click the image for a larger view)

Restore a File from a File Backup

Shadow copies are not available forever since they get pruned from time to time to manage the available space. If I need a file that is no longer available using this method, I can resort to my scheduled file backups. I simply select Restore files from the Backup and Restore Center, and choose a backup date that contains the deleted presentation. When I click the Add files button, I get an open file dialog that lets me navigate through the backup. After I select the file I'm looking for, I am given the option to restore the file to the same or a different location.

It's worth noting that the Restore files option only shows backups contained in the latest backup set. To view backups from an older backup set, select Advanced restore and then the Files from an older backup made on this computer option. On the rare occasion that you can't find an old backup set using that option, select Advanced restore and then the Restore files from a backup made on a different computer option. This can happen because the computer backup catalog is trimmed when it gets too big.

Restore a File from Complete PC Backup

I should mention, for thoroughness, that a Complete PC Backup can be used to restore individual files. While intended for restoration at the volume level, Complete PC Backup stores data in a .vhd format, and this means you can use the offline VHD mounting tool to access and restore individual files. (At the time of writing this article, the VHD mounting tool is only available as part of Microsoft Virtual Server 2005 R2 SP1, which you can download from microsoft.com/technet/prodtechnol/eval/virtualserver.) To mount the backup, open a command prompt with elevated privileges and navigate to Microsoft Virtual Server\Vhdmount. The command is:

vhdmount /m [path of the .vhd file] [drive letter to assign to the virtual hard drive]

When doing this for the first time, the system may not pick up the required driver since it is unsigned. This will cause an error message that says the device driver could not be loaded. To solve this problem, after plugging in the .vhd file using the command above, go to the Device Manager, right-click on the new device that shows up, and select Properties. From there, go to the Driver tab, select Update Driver, click Browse my computer for driver software, and select Let me pick from a list of device drivers on my computer. The correct driver file will be located at Microsoft Virtual Server\Vhdmount\vhdstor.inf. After installation, the new drive will appear and you'll be able to browse the latest Complete PC Backup and copy the files you want to an alternate location.

Complete PC Restore

Now imagine that one sunny afternoon, I decide to use my laptop while sitting by the pool. I slip on some wet tiles and my laptop dives into the pool. It's beyond repair and I have no choice but to buy a new one. Since I used the Complete PC Backup tool, I can restore my system to the new laptop—I don't have to spend a lot of time manually reinstalling each application and reconfiguring them with my personal settings. Performing a Complete PC Restore is straightforward. At startup, I use the Windows Vista installation disk to boot into the Windows Recovery Environment. Here, I am prompted to attach the device that contains the system image. I choose the appropriate image, and then the restore process begins.

After the restore is finished, I perform a file restore from my latest file backup. This is because I do file backups more frequently so the data contained in my file backup is more current. Since the computer is reverted to a time prior to the chosen file backup, it does not contain a record of this backup in the catalog. Therefore, I select Advanced restore | Restore files from a backup made on a different computer | Restore everything from this backup. I also start a new full backup to protect my newly restored data.

Windows Recovery Environment is often installed by the OEM on the hard drive as a hidden partition. This can be used for restoring a Complete PC Backup image to the same hardware. But if you need to restore an image created from one computer to another, you need to run Windows Recovery Environment from external media, such as your Windows installation disk.

There are some caveats worth considering. Complete PC Restore works simply when restoring to the same hardware the backup was taken from. (Provided, of course, that hardware failure wasn't part of your problem.)

Since Complete PC Backup includes an image of the entire computer, some restrictions apply when restoring to different hardware. First, the backup image contains drivers that are used to boot to the machine after the restore completes. In rare cases, the drivers needed to boot on the new machine might not be present. This might happen when restoring an image backup taken on one type of disk controller (IDE, SATA, or SCSI) to another type of disk controller. Even in this case, there is still a good chance you can complete the restore successfully, because the common Windows drivers included in the image backup would likely be compatible.

Second, the restore can only be performed if the new computer has at least the same number of hard drives and each hard drive is at least as big as the original it replaced. Keep these restrictions in mind if you intend to use Complete PC Backup for migrating to new hardware.

Since backup and restore are performed at the block level for entire volumes, Complete PC Restore requires a volume to be either fully restored or skipped. Therefore, you might want to create multiple volumes for backup (for instance, partitioning the system files from the data files). Then when restoring, you can choose whether to restore only the system volume (identified as critical) or all volumes.

Putting These Features into Practice

Windows Vista has made significant improvements over Windows XP in protecting your data and system by introducing new backup technologies and improving existing options. The four main backup features—File Backup and Restore, Windows Complete PC Backup and Restore, System Restore, and Shadow Copy—deliver different yet complementary capabilities, casting a broad net of data protection. It's important to understand how these features work together, to make sure your system is configured to utilize all four methods, and to apply the appropriate protection and remedy according to the situation.

As a rule of thumb, always try Shadow Copy restore first in a data loss situation since this method is likely to have the most up-to-date copy of your data. For system instability and repair, use System Restore. Complete PC Restore should generally be used as a last resort for a full system repair, and it should be used with caution. Nonetheless, Complete PC Repair can be a real lifesaver. Most importantly, take action before it is too late: backup now!