Sunday, October 7, 2012

Microsoft: Essentially Secure From Its Own Self

Digging Myself Into a Hole

On 26 September 2012, Microsoft released an update to its own Security Essentials anti-virus software under the moniker KB2754296. It was classified as an "Important" update. In the past, almost all "Important" updates are checked by default, so I was a bit surprised when this update did not have the usual check mark. Little did I know that this was only a harbinger of trouble to come.

I tried to implement the update several times, but all attempts failed. I then began trying various solutions I read about when I Googled problems associated with KB2754296. Unfortunately, I did not keep a record of my various attempted fixes because I did not expect to get so wrapped around the axle as I eventually did.

In the course of my failed experimentations, I did notice that the shortcuts on my daughter's machine for the Security Essentials executable file "msseces.exe" pointed to the parent folder
"C:\Program Files (x86)\Microsoft Security Client\"
which as we will see shortly is not correct for a computer with a Windows 7 64-bit operating system. I must have erroneously installed the 32-bit version of Security Essentials at one time, an error which might have contributed to my initial downfall.

Probably the worst thing I did was follow a recommendation to delete any and all registry entries associated with Security Essentials. Big mistake. One of my machines degenerated to such a state that not only was I unable to update Security Essentials, I also could not uninstall the software with the ultimate goal of re-installing it anew for a fresh start. In fact, I could not even open Security Essentials to access any settings. In short, I became totally distraught because I had a machine whose "security" system was in such disarray that it rendered the machine next to useless.

Perhaps worst of all, my daughter needed to download some images of the American flag for a school project, and while we found many pictures she liked, we could not successfully download or save any of them anywhere: not onto the laptop's hard drive or onto her external USB thumb drive. Stymied at every turn.

Climbing Out of the Hole

In sheer frustration, I tried using the most recent restore point to restore my system to the state it was in three days before. Whew: that seemed to help. I lost three days of file and system updates, but at least I had a functioning security system back, outdated though it might still be.

In the course of Googling the KB2754296 update problem, I stumbled upon one particular web site that contained the following paragraph:
There are quite a few updates that seem to get blocked by security S/W. There are times disabling a security app will allow the update to take place. The better alternative in these cases may be to download the update in question from MS and save it to your PC, disconnect from the internet, then disable your security apps prior to running the update. Once the update has completed you can enable any security apps you disabled, then re-connect to the internet.
With no other options remaining, I decided to give this approach a try out of sheer desperation.

I first visited the Microsoft Security Essentials download site and downloaded the file applicable to me: the Vista/Windows 7 64-bit option. There were also files for Windows XP 32-bit and Vista/Windows 7 32-bit.

Download whichever file applies to your situation, double-click the downloaded file, and let the fun begin. You should soon encounter a window that says:
The feature you are trying to use is on a network resource that is unavailable.

Click OK to try again, or enter an alternate path to a folder containing the installation package 'epp.msi' in the box below.
After many failed attempts and much time and effort to research the proper location, I was able to use the "Browse" button in that same window to navigate to the following folder:
C:\Program Files\Microsoft Security Client\Backup\amd64     (64-bit)
For 32 bit systems, the applicable folder reportedly is
C:\Program Files\Microsoft Security Client\Backup\x86     (32-bit)
And in 20-20 hindsight, for my apparent misguided installation of the 32-bit version of Security Essentials on a 64-bit machine, the epp.msi file of interest was probably in folder
C:\Program Files (x86)\Microsoft Security Client\Backup\x86     (32-bit)
In any case, armed with the correct location of the troublesome epp.msi file, I had a eureka moment: the process now ran to completion! The new version installed successfully.

I felt an immediate surge of relief. My almost inoperable machine was back to what passes for normal. Both machines were now able to perform Security Essentials and other Windows Updates, including the laptop that could not even open Security Essentials before I started.

Fittingly enough, after my installations were complete, the first Security Essentials definition update was number 666. How spooky is that???

Lessons Learned (Maybe)

In summary, here are a few lessons learned from this bitter experience:

First, be wary of updates marked as "Important" but that are not checked by default. That appears to be an indication that something might be amiss. Some bloggers claimed that this was an early release and not a mature, fully-tested, stable update.

Second, before attempting to install such updates, create a manual restore point and assign a recognizable name (e.g. "My manual update") to distinguish it from the many system created restore points, most of which carry the same generic "Windows Update" name. In addition, the default type for a system-generated restore point is "Critical Update" whereas the type will read "Manual" when you initiate your own restore point.

To manually create a restore point in Windows 7:
  • Click on the Windows Orb icon in the lower left corner
  • Click on "Control Panel | System and Security | System" if "Category" mode is set;
    Click "Control Panel | System" if "Large Icons" or "Small Icons" mode is set
  • From the menu links to the left, select "Advanced System Settings"
  • In the resulting "System Properties" window, select the "System Protection" tab
  • Click the "Create..." button
  • In "System Protection" window, type the customized name of your choice
  • Finally, click the "Create" button to generate the restore point
Last but not least, if the update involves Microsoft Security Essentials, learn the correct functional location for the "epp.msi" file on your computer. There might be a version of that file in one or more temporary folders, but the relevant folder locations are those listed above, depending on the version of your operating system.

Postscript

All of this begs the question: why did Windows Update work more or less satisfactorily on my laptop but not on the laptops belonging to my two children? They are all made by Toshiba, and they all have Microsoft's Windows 7 64-bit Professional operating system. The only significant difference I can think of is that my laptop has an Intel Core i3-350M processor while theirs has an AMD Quad-Core A6 processor. Can a processor make so much difference in how the Windows Update function works? If so, yikes!

Most exasperating, however, are the continuing problems with Microsoft's updates to its own software. I previously reported on difficulties involving both Silverlight and .NET Framework 4. Now we must wrestle with yet another troublesome update, this time to Security Essentials. Microsoft's repeated failures are rapidly becoming strong arguments for adopting Linux.

1 comment:

  1. Thanks for this helpful post. I am experiencing the same problem. How did you disable MSE prior to running the upgrade? I just turned off the real-time protection, since I couldn't figure out how to close the program completely. Then I got the error "The feature you are trying to use is on a network resource that is unavailable." So I put in the path you suggested, but then I got another error about it not being a valid installation package. Not sure if I did not shut down MSE well enough, or have the wrong path, or what?

    ReplyDelete