Patch Management Solution

Looks like this patch is installing OK - then it keeps trying ot reinstall then showing as failed. Is it an issue withthe detection rule ?

Thanks

Anyone! Still getting this on machines!

Hi JannasTo,

Was affected machine restarted after initial installation of KB2908783 from MSWU-921?

Some updates require restarting for finishing installation. According to your screenshot exit code 3010 has been returned after initial isntallation of affected update, this exit code actually means that restart is required.

Thanks,

Roman

This Exit Code usually means the update is already installed: http://social.technet.microsoft.com/Forums/windows/en-US/40c02c46-8b78-4d48-9dad-dd3d8156479a/event-log?forum=w7itprogeneral

Please check the Add/Remove programs and confirm. The update may have had some issues upgrading the .dll targeted, yet the update is listed in Add/Remove. Review the update on http://support.microsoft.com/kb/2908783 > More Information > Additional File Information to confirm if the targeted file is at the current level. 

If so; the IsInstalled rule may need to be reviewed by Support / Patch Dev, but if the file is not at current level; try uninstalling the update via Add/Remove, reinstall the update via Patch Management, and see if that corrects the behavior.

Hope this helps,

Joshua

Yep - machines have been restarted. Its in the add remove programs. checked the bulletin link above  and there seems to be some differences with some files and version. I'm not going to worry about it. its not critical so wont waste my time on it. 

To bad, I'm having a similar issue with MSWU-933.

I'm having same issue with 921 - the update is installed but not reporting back correctly and keeps trying to reinstall.

I sent support screenshots including the installlog.csv showing it's installed and it keep trying to reinstall. Seems pretty straight forward it's a rules issue but  got the canned response from Support to go through and report back my results on following tech article.

http://www.symantec.com/docs/TECH167291  

I'm so tired of dealing with 1st tier support where the first response is to make the customer jump through hoops.  There's no reason support shouldn't be attempting to remote in to get the 'results' they need to escalate the issue to the rules team.

Hello Sally5432,

The KM: TECH167291 is in order, for if the update is installed on the client, and the Client's Resource Manager > View > Inventories > Data Class > Software Management > Patch Management; review the IsInstalled Dataclass. If that update is listed, the raw IsInstalled Rule=TRUE and the problem is the Reboot Event is missing for that update.

This process to include the Event Views in the Compliance Reporting is currently under review as it affects those who utilize custom task jobs or manual process to execute the Software Update Cycle, and results in the Compliance Reports appearing inaccurate.

Furthermore, if the IsInstalled Dataclass is not present; review the STPatchAssessment.log file, searching for the bulletin/update, and you should see why the update is returning 'IsApplicable' following installation. The check would log the precise file being targeted, and you can review that file to ensure it is actually on the correct version, and cross reference that to the vendor site (e.g. Microsoft Support).

Lastly, if the update is installed in Add/Remove, and not listed in the IsInstalled Patch Dataclass, and the file is not current per the vendor site; there was a problem that took place during the Software Update Cycle on the OS level, and that update was unable to implement the proper file version. The method detailed above in my early comment is the correct process moving forward.

Hope this helps,

Joshua

I'm going to have to re-read this several times to figure it out. Wow.

Scott

Apologies for any confusion. Basically you are looking at one of the following:

1. Update installed, reboot event missed, and the database shows IsInstalled=TRUE; in which case you will review KM: TECH167291.

2. Update installed, listed in Add/Remove, but the files did not update; in which case you will want to uninstall the update via Add/Remove, reboot the client, and reinstall via Patch Management, and review the Client Logs (preferably on the Log Viewer to see details) to see if any further anomalies arise.

The product has the limitations for Reboot Event to be current as outlined in Step 1, but Step 2 is a limitation of the OS and in that instance; something took place running the executable that caused the file to fail to be updated.

Hope this helps,

Joshua

Hey Josh,

My point is 1st tier support should be working through the troubleshooting steps, either remoting into client environments when tickets come in, or better yet, trying to reproduce in their own test environment.  It's crazy to me the immediate answer from support is to send an email to "check this TECH article, it has a bunch of steps, let me know the results."

If our first level support at my company did that when tickets came in, they'd be getting bad reviews and looking for another job.  It certainly serves the purpose of making customers not want to put in tickets anymore.

But, don't get me wrong, I appreciate you taking the time to try to help here on Connect as always.  To answer your questions

<<The KM: TECH167291 is in order, for if the update is installed on the client, and the Client's Resource Manager > View > Inventories > Data Class > Software Management > Patch Management; review the IsInstalled Dataclass. If that update is listed, the raw IsInstalled Rule=TRUE and the problem is the Reboot Event is missing for that update.>>

KB2908783 is not listed for a computer that got the update from patch.

From STPatchassessment.xml

"Item Status="Missing" PatchName="Windows6.1-Windows7-SP1-KB2908783-x86.msu" Superseded="false" SQNumber="Q2908783" BulletinID="MSWU-921" Class="Patch" Reason="File version is less than expected. [C:\Windows\SYSTEM32\DRIVERS\MSISCSI.SYS 6.1.7601.17514 < 6.1.7601.22589]"

I looked http://support.microsoft.com/kb/2908783 and http://www.microsoft.com/en-us/download/details.aspx?id=42348 and cannot find what the expected/correct version of that file should be under file details, i must be missing it.  I assume it should be .22589, but it's not.

<<Lastly, if the update is installed in Add/Remove, and not listed in the IsInstalled Patch Dataclass, and the file is not current per the vendor site>>

This seems to all be true.

<<The method detailed above in my early comment is the correct process moving forward.>>

I uninstalled the update from add/remove programs and let patch reinstall. It was successful, but the MSISCSI file version didn't change.  Rebooted, ran assessment scan again and STP has same message.

The failed update is happening on all of our workstations, not just a few .

Thank you for your insight, for I was unaware that was the troubleshooting you have experienced from our Frontline Team. Working with the customer is the definition of Customer Care and I know that is what makes software successful. I am taking this to all of Symantec Management, for this is without a doubt; unacceptable. 

Upon reviewing your answers:

1. Update is not listed in the Client's Resource Manager - IsInstalled Dataclass for Patch Management.

2. STPatchAssessment.xml displays the update is 'Missing'

3. Checked Microsoft Site: Please expand the section 'More Information' found on http://support.microsoft.com/kb/2908783 and find the OS Type of the Client, and there you should see the file being updated:

4. The update is listed in Add/Remove Programs; uninstalled and allowed for the update to reinstall. Found this process was successful and returned a Windows System Assessment Scan, yet the update still shows 'Not Installed'

5. Confirmed the failed update is happening on all clients workstations.

Moving forward; this appears to be a rules issue. The update's IsInstalled=TRUE appears to be failing to target appropriately and the returning data shows 'Missing.' 

I hate to dump more articles on you, but these checks / data are needed for Backline & Development review. Please review the steps outlined on KM: HOWTO95427 (confirms all communications are in order), and then work through KM: HOWTO60789 to gather the client data needed for rule review (this data is critical and must be complete for BL & Dev review). Attach the HOWTO60789 data to the case and request the FL TSE to escalate the case as a suspect rules issue. 

Thank you,

Joshua

Josh,

When I click on that "Additional file info" I'm just getting a bunch of manifest info, nothing about individual files like I was expecting..?

Did the howto.  That ruleEvaluator sure is handy.  Hopefully ticket goes somewhere helpful :) thanks again, josh

Thank you for your understanding. The MS Support site may be generic in showing the update targets if the Microsoft OS type is installed (e.g. Windows 7).

I informed the FL TSE working your case to review HOWTO95427 (confirms all communications are in order), and then work through KM: HOWTO60789 to gather that data. 

It is most excellent if you already have that attached to the case.I will take ownership of this case as soon as it is escalated, contact you if anything more is needed for review, and research the client data for how the IsInstalled Rule is targeting.

Thank you again for your patience,

Joshua

Unfortunately, I have some other stuff broken right now in our Mac environment I need to devote all of my time to.  Support won't escalate till we have a call so they can gather whatever else they need.  Maybe next week...

Hello Sally5432,

Please follow up with Support Team as soon as you are able to devote the time needed to review this issue further. That data from the SMP/Client is pertinent to a complete review of the targeting rules.

We will be happy to follow up, gather current Client Data, and review for possible targeting rules issues, as soon as you are able.

Thank you again,

Joshua

We have this similar issue with MSWU-933 (Description of the cumulative update for Lync 2010: April 2014),

Please advise.

Hello Jack999,

I have recently reviewed issues pertaining to MSWU-933; found that the Client's package properties for MSWU-933-KB2953593 were not for the current update package, but rather the previous Superseded Software Update from MSWU-877-KB2912208. 

Cause: performance issues took place during the PMImport, specifically during the Revise Software Update Task, caused package corruption. This in conjunction with the Package Resources for old / new versions of the Lync updates having the same name, which did not pertain to the problem, but masked the issue; making this appear to be a rules issue. The older update is targeting, but fails to install via Patch Management's Software Update Cycle.

Resolution: refresh the package for MSWU-933 on the Client and the SMP. This process was confirmed in a small test group and outlined in KM: TECH217851.

Please review this article and let me know if you have any questions. 

Thank you,

Joshua

My issue has been resolved by using the document  posted by Joshua Rasmussen.

Have been given 2 KB's to work through before its escalated. Frankly, I am now going to ignore issues I have that are not critical in CMS due to the amount of time I am spending on troubleshootting.

yea.. feel your pain.

Thank you very much Joshua, the steps mentionned in the article TECH217851 works like a charm !