Fully disabling System Protection on Win 7

Question

I have a requirement from management that my application needs to disable System Restore on the system after install. I have found and implemented the code below to accomplish this. The code works just fine on XP and Vista, but doesn't seem to be working the same on Win7.

public void disableSystemRestore(string drive)
{
    try
    {
        ManagementScope scope = new ManagementScope("\\\\localhost\\root\\default");
        ManagementPath path = new ManagementPath("SystemRestore");
        ObjectGetOptions options = new ObjectGetOptions();
        ManagementClass process = new ManagementClass(scope, path, options);
        ManagementBaseObject inParams = process.GetMethodParameters("Disable");
        inParams["Drive"] =  drive;
        ManagementBaseObject outParams = process.InvokeMethod("Disable", inParams, null);
    }
    catch(ManagementException err)
    {
        MessageBox.Show("An error occurred while trying to execute the WMI method: " + err.Message);
    }
}

The problem is that on Win7 System Restore is wrapped up into System Protection. System Protection has 3 options for each hard drive.

1) System Restore and File Version

2) File Version only

3) None

So long as no one has ever manually changed this setting the code works just fine. However, if a user has changed this setting before then the code sets Option2 instead of Option3. How can I correct this?

Furthermore, I can't find a good description of what exactly Option2 does. I've seen different descriptions of what files are actually covered by this, but just comments on threads here and there. No real 'good' description of what it does or how it works.

EDIT: There has been a lot of concern over 'why' I need to do this and believe me I fully understand and fought to find another way. But it wasn't feasible. Some more info to hopefully set your minds at ease.

This product is not intended for personal use. It will be used at the corporate level on locked down systems. This requirement comes out of industry regulations and standards. Think medical or credit cards. It's not just 'our' logs that are being guarded, system access logs, system use logs, file audit logs. So while even with System Restore deactivated they could use other means to restore old version of our logs, the system level logging records the file access and who accessed it so we at least know the log tampering occurred. Essentially using the OS to audit log the logging. The restore point would reset all that as well in one easy step.

It is a requirement placed on the user to install this app with Admin rights. Currently the users actually have to manually perform this step so the site can maintain its industry certification. We are simply trying to simplify the install process. Site admins are aware of this requirement. There are a dozen other 'System Admin' change like this that I am also implementing to simplify the install process.

Answer 1

This isn't a direct answer to your question, but it was too long for a comment.

While this is not an entirely unreasonable request for internal software, it is a horrible idea for commercial software.

There are at least six things wrong with this plan that I can see off the top of my head. Feel free to kick this list back up to management and see if you can get a different directive.

1. This sounds like corporate software rather than user/personal software. Many corporations have Active Directory policies in place which make it impossible to disable system restore or which will automatically re-enable it.

2. Only a system administrator will be able to install this, because a regular corporate user won't have permissions. Given that, nothing will stop the system administrator doing the installation from re-enabling system restore after install. (If the regular user can install it themselves, then they'll also have permission to reenable it)

3. Anything which attempts to disable system protection during an install may be flagged as malicious software by virus protection. This may prevent this from working and/or disable your software entirely. It also may cause system administrators to recommend against it.

4. Nothing about disabling system restore will prevent someone from manually removing the logs.

5. Nothing about this plan will prevent other backup solutions (such as SecondCopy or another network backup) from being able to restore "old" logs. In fact, nothing will prevent the malicious user from simply copying the old log, doing his thing, then replacing the old log.

6. It may make your company liable for any lost data on systems which it is installed on. (IANAL. Make sure your lawyers are aware of this and the potential repercussions when writing the terms of use.)

---

In short, it won't do what you want, it's easy to get around, and is a very hostile thing to do.