Video Screencast Help

Detection rule issue with MS13-057?

Created: 19 Aug 2013 | 24 comments

We have Windows 7 x64 clients that are shown vulnerable for MS13-057.

The installation of "Windows6.1-KB2803821-x64.msu" fails with exit code 2359302.

When we execute the patch manually it shows "already installed".

Altiris Software Update Agent is 7.1.7858

PMImport version is 7.1.452

Is there a detection rule issue with MS13-057?

Operating Systems:

Comments 24 CommentsJump to latest comment

andykn101's picture

Check the BITS Service is OK:

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Frederic SCHROBILTGEN's picture


Did it solve the problem on your side?

I have the same problem on the same bulletin ... and others.

I tried the the solution upper -> same result

I tried the M$ debugging way (almost of the methods) ( -> same result

I have also 17025 errors which are quite the same as 2359302.

Installlog.csv example:

8/28/2013 9:35 mso2010-kb2553260-fullfile-x86-glb.exe {C0F3FD57-FE76-4058-8B9E-FA0739A8B814} MS12-057 Failed mso2010-kb2553260-fullfile-x86-glb.exe /passive /norestart /quiet 17025
8/28/2013 9:35 msconv972010-kb2589322-fullfile-x86-glb.exe {C3A739E6-79CD-40B1-A98F-F614EB7A91B0} MS12-057 Failed msconv972010-kb2589322-fullfile-x86-glb.exe /passive /norestart /quiet 17025
8/28/2013 9:35 csi2010-kb2687509-fullfile-x86-glb.exe {C3F3A366-7170-4A55-BD1F-070DA6ADAE18} MSWU-672 Failed csi2010-kb2687509-fullfile-x86-glb.exe /passive /norestart /quiet 17025
8/28/2013 9:35 Windows6.1-KB2803821-x86.msu {35412AD7-0C32-437B-8F1A-575483F52C04} MS13-057 Failed wusa.exe Windows6.1-KB2803821-x86.msu /quiet /norestart 2359302
8/28/2013 9:36 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/28/2013 9:36 Windows6.1-KB2844286-x86.msu {DD78E61D-9268-43AD-865C-FD557C795247} MS13-052 Failed wusa.exe Windows6.1-KB2844286-x86.msu /quiet /norestart 2359302

NDP40-KB2840628-x86.exe is funny:

7/12/2013 10:47 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 3010
8/26/2013 11:51 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/26/2013 13:12 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/26/2013 14:11 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/26/2013 14:46 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/26/2013 15:00 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/26/2013 15:29 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/26/2013 15:41 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/27/2013 14:27 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/28/2013 9:05 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0
8/28/2013 9:36 NDP40-KB2840628-x86.exe {B58BA274-DD3F-49BC-BB9F-DE991AB79168} MS13-052 Succeeded NDP40-KB2840628-x86.exe /norestart /q 0

Same for MS11-053 (OFV.exe) which is redeploying itself again and again and again ..... (did I already added again?) on a large part of our computers.

There is definitively a detection problem with the patch management....

Our platform : SMP 7.1.2 MP1.1 Pointfix 5

Thanks in advance for any answer.


Morten Granli-Hansen's picture


We still have issues with this bulletin. I suspect that the problem is the detection rule in the policy. The bulletin was released 09.07.2013 and was successfully installed on our computers. Since the bulletin was revised 13.08.2013 it has tried to install itself on computers even though its already installed.

Seems to me we have the same issue as was the case with MS13-047

Symantec needs to fix the detection issue and then we can do a new pmimport.


Frederic SCHROBILTGEN's picture

Hi Morten,

Something is definitively wrong with the detection rules.

For the others:

Just forgot the PMImport version:

Import Patch Data for Windows

Name: Run Import Patch Data for Windows on Schedule
Executed by: ******************
Start time: 8/28/2013 6:30:02 AM
End time: 8/28/2013 6:34:56 AM
Duration: 00:04:53
Version: 7.1.455
Automatically close this window on task success.
Refresh every: 5 seconds15 seconds30 seconds45 seconds1 minute2 minutes5 minutes
  Imported Deleted Failed
Software Bulletins 3 0 0
Software Updates 16 0 0
Overall result: Succeeded

If I'm not wrong, the Patch Management is using the Shavlik detection process, no?

That's normally the one used also by WSUS.

Why so much differences in the detection process?


oi_son's picture

Hi There

I may be having a similar issues. I have not checked the MS logs on the machines yet though. I am only going off the Altiris logs.

Do you have this setting enabled? "Automatically revise software update polices after importing updated patch data"

I posted my query here:

Have you recreated the patch policy since the patch has been revised? If so then there quite possibly is a problem with the patch of the detection..

If not.. My theory is that with my problem. The machines already have the old version of MS13-057 on the machines. Since the new PMimport has updated the patch on the server side (and the detection rule I think) the PCs are running their scans and saying MS13-057 (according to the new detection) is not installed so please install it. Then Altiris looks and realises that the patch is already downloaded on the PC (not realising that it is the old version) and installs it and says it is successful. However it is not because when the scan runs again it picks up that it is the incorrect version. Hence the machines need to get a copy of the new patch data from the server.

Does that make sense?

By enabling the setting I mentioned above and the one listed below that setting i think it will fix my issue.. but I have about 2 years worth of patch policies turned on and I do not want any issues if I tick those boxes now and say 50 of the patches that are turned on in polices want to be updated and start updating on machines. I am in the process of setting up a test environment so I can test this out in 2 weeks or so.



Frederic SCHROBILTGEN's picture

Hi oi_son,

In my case, the option is not set and yes, this version of the bulletin is in a separate policy.

Your explanation makes sense and highlighting a detection rule problem in this case.

From what I understant, if you tick it, the concerned policies are going to be revised and only the old packages are going to be redirected to the new ones.

I can be also interesting to know if it's going to be the same result for policies with one bulletin inside and policies with multi-bulletins inside.

Hi Symantec guys!

Can you confirm?

Thanks in advance


HighTower's picture

I've flagged this thread to draw Support's attention.

Has anyone actually contacted Support to log this issue?

Frederic SCHROBILTGEN's picture

I got already detection problems like that in the past...

That's recurring problems.

I'm sure they have tons of them.

cnemac2's picture

I am experiencing what appears to be a lot of detection rule erros with patches re-running. Here is an example:

Joshua Rasmussen's picture

Hello Morten,

     The problem you outlined appears to be a possible IsInstalled Rule issue. Please review the link for MS13-057; compare the targeted .dll version with that installed on the client.

     If you find the update should display Installed=TRUE; please open a rules case with support, and work through the requested data for resolution found on KM: HOWTO60789.

Hope this helps,


Joshua Rasmussen's picture

Hello cnemac2,

     Your issue appears to be a problem regarding corrupt .NET installation, for all targeted updates appear to be targeting .NET and none of them are able to install. You could try uninstalling / reinstalling .NET on that client, and rerun the Windows System Assessment Scan from the Software Delivery Tab > highlight WSAS > Click task link under 'Application Tasks,' and see if the updates retarget and install.

     This issue is reminiscent of the issue detailed on KM: TECH180083, for this article advises similarly, but in regards to Office updates. This includes, but not limited to, Exit Code: 17028, 17031 and 17035.

One way to test this;
1. Download the package from the Client GUI > Software Update Tab > Double Click the update; select the download URL and save to desktop. Run the update manually and see if it is able to install.

2. Run Windows Update Tool and see if the updates are applicable from a 3rd party perspective; try to run the update installation via this method. 

     Moreover, if you are only targeting with these updates specifically for .NET; it could be something simple like the client needs a reboot. Check the registry key detailed on KM: TECH127365, or view other troubleshooting checks detailed on KM: HOWTO79448. You may also open a Support Case to gain additional assistance troubleshooting this issue.

Hope this helps,


Frederic SCHROBILTGEN's picture

Hi Joshua,

As I said before, I got also this issue.

I just got some trouble with my computer and I got the opportunity to reimage it : same issue.

9-18-2013 8-50-12 AM.jpg

-> I'm also stopping my computer all evenings.

-> I also disabled the incremental update of the vendor import in the patch management 

Then, I'm not convinced by this answer but will check the proposed documentation.  Who knows.

Frederic SCHROBILTGEN's picture

I just repaired .Net 4 and Office 2010, rebooted twice, did the WSA and started an update cycle => failed.

I did this on a brand new installation.

Well, I'm going to check the section 7 of HOWTO79448 : Software Update fails to install on the client.

Frederic SCHROBILTGEN's picture

I'm going to open a case for it.

I just hope this time that the support won't tell me to reinstall the agent...

Joshua Rasmussen's picture

Hello Frederic,

If possible; try uninstall / reinstall the .NET next. That has helped me where repairs failed to resolve the issue. Also perform this on any other .NET installs.

Furthermore, I see one update, MSWU-431; for the Outlook Junk Email Filter also failing to install. If possible; try the process for this update detailed on KM: TECH180083.

Additionally, the reboot checks were a solid direction, for that is a simple fix that is often overlooked. Also check the client versions; ensure the Altiris Agent is current for that client in comparison to the current version available from the SMP, and the sub-agents are also current versions. Patch Management Plug-in versions are detailed on KM: HOWTO30314.

Moreover, where this is spanning across 3 different software types, for  MS13-057 is neither .NET nor Outlook, you could review if the client problems communicating with the SMP. Troubleshooting this is detailed on KM: HOWTO60750.

Lastly, review Andy's response; BIT Services check, for that could also be the contributing factor in this issue. I have also found checking the Client Logs (may be saved and opened on the SMP and opened via the Log Viewer for easier viewing); see if there are any errors thrown when the update cycle runs. Some errors may be indicative as detailed on KM: TECH41678.

This does appear to be extensive, so a case with Patch Support would be in order. You may want to let them know that you have tried these checks as a precursor to calling.

Post here if you have any further questions and I will be happy to help,


Frederic SCHROBILTGEN's picture

Thanks for the answer.

I already did HOWTO60750

. Nothing special...  I sent the data to the support.


is just useless as there is no more diagnotic tools for Office 2010.  The repair tool is doing the job.


 is ok also as we are fully aligned since when applied the pointfix 5





I guess that's answering this question.

 BIT Services check

Just did it but not the way suggested by Andy(it's simply not working). I did it through a command line.


I did a repair... it should correct any problem.  I'll try to uninstall it but it's hard to believe that is related.  I'll if it's solving my problem.

It has exactly the same error code as MS13-057 which is not related.

Will post the result for this one.

Thanks and have a good night.


Frederic SCHROBILTGEN's picture

Hi Joshua,

I uninstalled, rebooted and reinstalled .Net and here is the result :


Now, I'm going to let my computer updating and I'll post the result.

Frederic SCHROBILTGEN's picture

I'm going to reboot and force the others to be executed:


I'm keeping you informed.

Frederic SCHROBILTGEN's picture


Final results:


=> not working

And if we take a look into the Run History section of each failed update:





Then to summary:

0 : OK, no error

2359302 : Perhaps you need to restart to apply it (kidding me?)

17025 : Already installed (M$ error)

=> In general, there is a detection problem and no, it's not only my computer(which have been recently reinstalled).

I tried all the proposed solutions

Frederic SCHROBILTGEN's picture


I just uploaded :

- the client logs

- the SMP logs

- a screenshot of the client agents versions

I sent the full version number of our SMP and a copy of this thread.

The case is 05132189.

Best regards,


Joshua Rasmussen's picture


These types of issues are never quick, easy one-line resolutions. Opening a support case is always the best way to resolve issues, for it allows the TSE to WebEx and gain a full understanding of the environment / issue. Let me know if there are any questions outside of a support case and I will be happy to help.

Good luck,


Frederic SCHROBILTGEN's picture

Yeah, I can confirm... It's taking months and finally you have to apply a pointfix which is only solving the problem for a few weeks...

It's just consuming processes and time.

I am from time to time nostalgic when I think about my old wsus... even if the patch management is bringing us more usefull features.

Thanks for your help Joshua.


Frederic SCHROBILTGEN's picture


We are working hard with the support for more than one week and an half... for nothing.

The Support Crew cannot reproduce the problem and all the tests are just giving negative results.

The best of all: it's happening to all of our computers, even the new ones.

One advice: Don't do like me.

I followed all the KBs, extracted all the data and sent everything... for nothing.

They asked me to redo the tests.

=> Then, complain, wait and execute if you want to be productive in between!

Joshua Rasmussen's picture

My apologies for the delayed response, for there has been no activity regarding this update on the Support Backline Team until today.

This issue has been escalated just this morning to the Dev Team as outlined on KM: TECH214312, and the rule review of the client data and how it is targeting for IsInstalled=TRUE is underway.

Additionally, keep in mind that the data becomes obsolete really quickly, for the PMImport could be updated as often as twice a week with revisions etc. The gathering of the data may even be needed a couple times during the process as these files are continually updated during the review process, but that is on a case by case basis.

Please subscribe to this KM article if you are experiencing this issue and it will be updated with resolution as soon as possible.

Thank you,