Microsoft security essentials and Windows XP

[submix8c]

Can't "deirectly" Update. Turn off AutoUpdate and don't do ManualUpdate via the GUI. Won't work. You HAVE to use one of the previous two methods to circumvent and need to ALWAYS manually download Full Defs and Install. The Interface downlodas the "raw" Installer and it will NOT allow it (since it's flagged for 5.2 which is Server/XPx64). XPx32 is v5.1 so you have to live with it until MS totally clobbers it.

Slightly O/T - using Symantec for older products can still be updated to latest definitions IF you swap out the program that "installs" the Defs for an older version that works. Pretty much the same concept as above.

HTH

[JorgeA]

3 hours ago, submix8c said:

[...]You HAVE to use one of the previous two methods to circumvent and need to ALWAYS manually download Full Defs and Install. The Interface downlodas the "raw" Installer and it will NOT allow it (since it's flagged for 5.2 which is Server/XPx64). XPx32 is v5.1 so you have to live with it until MS totally clobbers it.

As I was out driving today, I thought about the prospect of doing this by hand over and over and over again for a tertiary PC, and I felt an overpowering wave of laziness slowly coming over me. Life is too short.

Maybe some kind of CMD.EXE or PowerShell script could be written to automate one of the solutions proposed in this thread? Then it could be added to the Task Scheduler.

--JorgeA

[Bersaglio]

@JorgeA

There are at least 2 automatic solutions posted here.

1. heinoganda's automatic script (see readme file included with it).

2. Kernel modification by blackwingcat allowing using automatic updates again (but correcting system kernel with adding necessary dll's from Vista).

[DrWho3000]

This is what I have

Antimalware Client Version: 4.4.304.0
Engine Version: 1.1.12603.0
Antivirus definition: 1.217.1827.0
Antispyware definition: 1.217.1827.0

Looks  like its the hard manual way  using PE_Patch to change from 5.2 to 5.1

until "IF" there is a fix or M$ fixes it ( if they do )

surely this shouldbe fixed for thosethat have 32bit than 64 bit PC's

I'm sure it is intentional with XP rather than a stuff up

[submix8c]

The "bitness" isn't the problem. Server2k3 (5.2) comes in both 32 and 64.

It's strictly the XP 32-bit (5.1), which has had support dropped. Both Server2k3 and XPx64 just recently had support dropped (both being 5.2).

You'll have to use the method(s) suggested above to circumvent the "made for 5.2" installer. MS isn't going to back up now.

[Jody Thornton]

I wonder when the shoe drops for Windows Server 2003.  I use the Vista/7 installer on it, and it's still works thankfully, but with the 4.4.304.0 build too.

[NeauCloux]

My automatic updates for MS Security Essentials are working again thanks to WindowsXP-KB2584577-v0.4-x86-ENU.exe from blackwingcat.  All I had to do was download WindowsXP-KB2584577-v0.4-x86-ENU.exe from http://blog.livedoor.jp/blackwingcat/archives/1706829.html and run it.

The solutions from Bersaglio and heinoganda work well for people who prefer to update MSE definitions manually, but blackwingcat's solution is the only one I found that got my definition updates to work again automatically.  For several years, my definitions have been updated automatically every night.  Task schedule wakes my computer from sleep state in the wee hours, which runs a script to do automatic updates, then puts the computer to sleep again.  The MSE signature update section of the script is below -

REM Begin SigUp subroutine
:SigUp
REM Enable Automatic updates, wuauserv, so MSE can update definitions.
REM Change wuauserv from disabled to auto.
sc config wuauserv start= auto
REM The following command starts the automatic updates service
sc start wuauserv
REM Automatic updates should now be running.
REM Run MSSE sig update
"c:\Program Files\Microsoft Security Client\MpCmdRun.exe" -SignatureUpdate
REM Update complete, turn off Automatic updates to lessen computer burden
sc stop wuauserv
REM Disable Automatic Updates
sc config wuauserv start= disabled
REM Automatic updates should now be disabled
REM Background Intelligent Transfer Svcs BITS is enabled by Automatic
REM  Updates, wuauserv, IF wuauserv runs more than a minute or 2, or,
REM if an update is actually performed.  Stop and disable BITS.
sc stop BITS
sc config BITS start= disabled
goto :EOF
REM End SigUp subroutine

My system is XP-SP3. The MSE version is 4.4.304.0.  It was about April 19 when I first noticed the automatic definition updates were failing.  Just before I installed blackwingcat's solution, I tested MSE automatic definitions update again and it failed again with ERROR: Signature Update failed with hr=0x800700C1.  A few minutes later, after applying blackwingcat's solution, I tested MSE automatic definitions update again, and this time the definitions update worked.   The fix from blackwingcat is what got the auto updates working again.  That was the only change, so that was what fixed it.  Thanks to everyone who helped with this, especially blackwingcat.

Edited April 22, 2016 by NeauCloux

[Raupinator]

I have about 5-10 customers who (for different reasons) still use XP, all in combination with MSE (4.4.304.0). Personally I have 2 machines which run on that combination. While all of them ran into the same problem as discussed here I just "woke up" the one exception that has not been used for 49 days. It immediately updated the MSE without problems(!) to the definitions of April 22. Then the system found the update KB890830 that has been released on April 12. I assume that this update is making the MSE update fail after it has been installed?

1.) Am I right with my suggestion?
2.) What if I keep denying installation of KB890830 from now on? Does it make using XP+MSE significantly MORE insecure?
3.) If Answer to 2 is "No" While I am aware about the risk of using WinXP - there really ARE good reasons for the above mentioned machines to keep them alive. What might be the best solution to get the other systems back to the state of updating the MSE? Does it make sense to system restore to a point before last KB890830 and set them to "Ask before installing updates" so the user may deny this one in future?

Thanks to all of you for spending your efforts and time in trying to solve this issue!

[Jody Thornton]

14 hours ago, NeauCloux said:

My automatic updates for MS Security Essentials are working again thanks to WindowsXP-KB2584577-v0.4-x86-ENU.exe from blackwingcat.  All I had to do was download WindowsXP-KB2584577-v0.4-x86-ENU.exe from http://blog.livedoor.jp/blackwingcat/archives/1706829.html and run it.

So what does this "update" actually do?  What does it change?  Is there some comprehensive documentation somewhere?  I didn't see any on the original site.

[Bersaglio]

@Raupinator

MSE update is working again. KB890830 has no relation to this issue.

@JodyT

WindowsXP-KB2584577-v0.4-x86-ENU.exe is an unofficial update done by blackwingcat. It replaces system kernel and adds few dll files from Vista and thereby allowing execution of *.exe files designed for NT 5.2 and later on XP.

[Jody Thornton]

Whoah, are we saying that MSE is now working again?

[heinoganda]

With the current MSE virus definitions (1.217.2046.0) are again direct updates possible under Windows XP! Why this change of heart? Well a guess, maybe through the many manually transacted Downloads MSE virus definition file and any resulting increase in demand for bandwidth. Whatever the reason, should continue to be monitored.

[JorgeA]

^^ My XP systems are currently being offered only version 1958, which of course keeps failing. Maybe it's better to wait for Windows Updates to catch up to the latest version, 2046 ?

--JorgeA

[heinoganda]

@JorgeA

If at MSE is an error in upgrade, then again run the updater or download and run the current virus definitions. At the latest after that it should again function correctly with the direct upgrade, probably because an older Delta Update can not be performed.

Meanwhile, the version of the latest virus definition 1.217.2054.0

Edited April 22, 2016 by heinoganda

[Raupinator]

Yeah! Great! I can confirm that everything works fine again on at least 6 machines!