none
KB974417 0x80070643 KB976569 RRS feed

  • Question

  • I've been starting to see multiple instances of KB974417 fail during install
    from WSUS. I've found that you need to un-install KB976569 (released
    2/23/10), then install 974417. Then you can re-install 976569.

    This will probably only be an issue on machines that have .NET
    2.0/3.5. 976569 and you are doing a clean new .NET install. KB97659 does not
    supersede 974417, as they address different issues, so both are apparently
    needed.

    Just wondering if anyone else has seen this or is Microsoft aware of this
    issue and will they have have a fix down the road.

    Ciao

    Fabio

     

    Friday, April 2, 2010 11:10 AM

Answers

  • Even when bringing a new machine up to date from an image deployment -- even though you can deploy all 150+ updates in one pass, that doesn't mean it's a "best practice" to do so. :-)
    What's the best way to accomplish this?


    My recommendation is to implement the deployment in phases:

    1. BASELINE the installation at the latest service pack. (Using WSUS to deploy the service pack is an option, but be aware that many service packs do have prerequisites and can no longer be installed to virgin RTM installations. Review the Release Notes and other deployment publications for the service packs to ensure the minimum required updates are installed prior to deploying the service pack.)

    2. Install all required Operating System Security Updates and Critical Updates. (Note: This collection may require mandatory and/or exclusive updates, which will require separate installation sessions due to system restarts required after the installation of any mandatory/exclusive updates.)

    3. Install all desired Operating System non-critical (optional) updates.

    4. Install all required Application Security Updates and Critical Updates.

    5. Install all desired Application non-critical (optional) updates.  (This step is where you will install the Internet Explorer and Media Player upgrades.)

    The WUAgent will (should!) generally handle the installation of the updates in the correct sequence; however, as noted in Step #2, the variable to consider is the presence of mandatory and/or exclusive updates, which will require a system restart before the remainder of the non-exclusive updates in the collection can be installed.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, April 5, 2010 1:55 PM
    Moderator
  • Hi again.

    After all this I opened a case with MS Premier Support.

    The official answer was that they are working for a updated hotfix that resolves this problem for which they gave me about a months time to be released.

    Also they said that the simplest resolution would be for the KB974417 update to be declined  since all the  files signatures are older than the ones applied by  KB976569 (you can see this by your shelves by looking the updates file list versions in the pages regarding these updates). 

    I declined the older update and all are working fine.

    Saturday, April 24, 2010 8:09 PM
  • I see that a wor-around is to unistall KB976569 then install KB974417 and re-install KB976569

    Actually the correct 'workaround', as of yesterday, is to approve the revision to KB974417 which eliminates this issue.

    Alternatively, the previous and correct workaround was to remove the approvals for KB974417 if KB956569 was already installed.

    If you don't have KB976569 installed, and you're having issues installing KB974417 then you have an entirely separate issue from those discussed in this thread. Nonetheless, as of today, though, your next step, still, is to ensure you have the May 11th revision (#105) approved, and that is the revision being installed by your clients.

    If you continue to have this issue with Rev 105, you should start a new thread and provdie complete system and environmental details .. including a WindowsUpdate.log showing the installation and reboot.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, May 12, 2010 8:51 PM
    Moderator

All replies

  • I've been starting to see multiple instances of KB974417 fail during install from WSUS. I've found that you need to un-install KB976569 (released 2/23/10), then install 974417. Then you can re-install 976569.

    Let's get a couple of things in perspective, here, before we invest too much energy in an issue that may really be an isolated issue.

    KB974417 is an October, 2009, security update (MS09-061).

    KB976569 is a February, 2010, non-critical compatibility update.

    KB976569 has every right to expect that a six month old security update is installed, and KB974417 cannot possibly know anything at all about updates that woud be released six months later.

    This will probably only be an issue on machines that have .NET 2.0/3.5. 976569 and you are doing a clean new .NET install. KB97659 does not supersede 974417, as they address different issues, so both are apparently needed.

    So, the fundamental issue here is that updates are being installed out-of-order, and the real issue is that you left a six month old vulnerability unpatched! :-)

    Most likely, this will only be an issue on systems that were not properly patched with MS09-061 in October 2009.

    As a general note: Updates should always be installed in chronological order based on their Release Date, and Security and Critical Updates should be installed before non-critical/optional updates.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, April 2, 2010 2:45 PM
    Moderator
  • Hello Lawrence,

    thanks for your reply. Unfortunately I realized I had not described the problem adequately.

    In fact I have applied the security patch in the correct sequence and at the correct time via WSUS on all clients on my LAN. Then no security problem for my LAN :-)

    The problem is on new PCs for which the pacth KB976569 is applied before the KB974417 by WSUS. The same by Microsoft Update.

    So the problem is the order in which WSUS and Microsoft Update install the patches in a new PC!

    Have you got any idea?

    Thanks a lot

    Ciao

    Fabio

     

    Friday, April 2, 2010 5:57 PM
  • The problem is on new PCs for which the pacth KB976569 is applied before the KB974417 by WSUS. The same by Microsoft Update.

    So the problem is the order in which WSUS and Microsoft Update install the patches in a new PC!


    Okay... so please post (or email) me the log showing the installation of these two updates in the same session and KB976569 being installed first.

    Fundamentally, though, it still boils down to management of patch deployments.

    Patches should be deployed in chronological order, where possible; and security/critical updates should be deployed before non-critical updates. Even when bringing a new machine up to date from an image deployment -- even though you can deploy all 150+ updates in one pass, that doesn't mean it's a "best practice" to do so. :-)

    This problem only exists because you are deploying MS09-061 and KB976569 in the same session. This is not a typical deployment scenario. Nevertheless, the WUAgent should be installing the security update from Oct '09 before the optional update from Feb '10, so if your logs show that not happening, I'll be happy to forward them onto the WUAgent team for further analysis.

    Of course, if the Security Update requires a system restart, and the compatibility update does not, then the security update is not being installed prior to the compatibility update, and therein lies the core issue.

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, April 2, 2010 7:45 PM
    Moderator
  • Even when bringing a new machine up to date from an image deployment -- even though you can deploy all 150+ updates in one pass, that doesn't mean it's a "best practice" to do so. :-)
    What's the best way to accomplish this?
    Saturday, April 3, 2010 1:34 PM
  • Even when bringing a new machine up to date from an image deployment -- even though you can deploy all 150+ updates in one pass, that doesn't mean it's a "best practice" to do so. :-)
    What's the best way to accomplish this?


    My recommendation is to implement the deployment in phases:

    1. BASELINE the installation at the latest service pack. (Using WSUS to deploy the service pack is an option, but be aware that many service packs do have prerequisites and can no longer be installed to virgin RTM installations. Review the Release Notes and other deployment publications for the service packs to ensure the minimum required updates are installed prior to deploying the service pack.)

    2. Install all required Operating System Security Updates and Critical Updates. (Note: This collection may require mandatory and/or exclusive updates, which will require separate installation sessions due to system restarts required after the installation of any mandatory/exclusive updates.)

    3. Install all desired Operating System non-critical (optional) updates.

    4. Install all required Application Security Updates and Critical Updates.

    5. Install all desired Application non-critical (optional) updates.  (This step is where you will install the Internet Explorer and Media Player upgrades.)

    The WUAgent will (should!) generally handle the installation of the updates in the correct sequence; however, as noted in Step #2, the variable to consider is the presence of mandatory and/or exclusive updates, which will require a system restart before the remainder of the non-exclusive updates in the collection can be installed.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, April 5, 2010 1:55 PM
    Moderator
  • Lawrence, I've sent you a private message with link to windowsupdate.log that includes KB976569 installing before KB974417 in same install session.

    Thanks, MS

    Tuesday, April 6, 2010 12:09 PM
  • Lawrence, I've sent you a private message with link to windowsupdate.log that includes KB976569 installing before KB974417 in same install session.

    Thanks, MS


    Has not arrived, plz resend.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, April 6, 2010 10:46 PM
    Moderator
  • I've sent it as private message through link on your blog?

    Wednesday, April 7, 2010 8:30 AM
  • I've seen this issue as well, when setting up XP Mode on Win 7.

    Fabio's workaround (uninstall 976569, install 974417, reinstall 976569) works well.

    Wednesday, April 7, 2010 6:57 PM
  • I've seen this issue as well, when setting up XP Mode on Win 7.

    Fabio's workaround (uninstall 976569, install 974417, reinstall 976569) works well.

    Wednesday, April 7, 2010 6:57 PM
  • I've sent it as private message through link on your blog?


    Oh.. well... I publish remotely to the blog.. guess I'll have to actually log onto the blog site and see what you did (that I wasn't even aware could be done!)
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, April 7, 2010 7:49 PM
    Moderator
  • My recommendation is to implement the deployment in phases:

    1. BASELINE the installation at the latest service pack. (Using WSUS to deploy the service pack is an option, but be aware that many service packs do have prerequisites and can no longer be installed to virgin RTM installations. Review the Release Notes and other deployment publications for the service packs to ensure the minimum required updates are installed prior to deploying the service pack.)

    2. Install all required Operating System Security Updates and Critical Updates. (Note: This collection may require mandatory and/or exclusive updates, which will require separate installation sessions due to system restarts required after the installation of any mandatory/exclusive updates.)

    3. Install all desired Operating System non-critical (optional) updates.

    4. Install all required Application Security Updates and Critical Updates.

    5. Install all desired Application non-critical (optional) updates.  (This step is where you will install the Internet Explorer and Media Player upgrades.)

    I'm experiencing a similar issue to the OP: KB974417 won't install, however I don't seem to have 976569. Is there another update that could be causing this?

    While your list is nice in theory, WSUS doesn't distinguish between the various criticality of updates (on the client side) or between OS and App updates, so all I have to rely on is the update's dependency information to sequence things correctly. Part of the usefulness of WSUS is that updates automatically get applied to the computer without an end-user needing to make a judgement on whether (or when) it is applicable.

    ELS.

     

    Thursday, April 8, 2010 10:51 PM
  • While your list is nice in theory, WSUS doesn't distinguish between the various criticality of updates (on the client side) or between OS and App updates,

    No.. it doesn't .. that's the responsibility of the WSUS Administrator by choosing when to APPROVE the updates.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, April 9, 2010 1:12 PM
    Moderator
  • I've sent it as private message through link on your blog?


    Can you please email to the email address listed in my MVP Profile?
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, April 9, 2010 1:13 PM
    Moderator
  • I have received a logfile adequately demonstrating this issue, and I've forwarded the logfile to the WSUS/WUA team for their review and (hopefully) action.

    In addition, this message is being posted to my blog momentarily:

    ===========================================

    As originally presented in this Technet WSUS Forum thread
    http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/b9ca8109-5e09-4acc-bef0-54658ca83c66

    The WUAgent is improperly handling the installation of KB974417 when KB976569 has already been installed. Essentially this situation occurs in two scenarios:

    1. The systems have not been properly patched with required security updates in a timely manner. KB974417 is MS09-061 (October 2009), so presumably most have already deployed this update; however, evidence shows that some are a bit behind in their security patches. If KB976569 is already installed, and KB974417 is being installed after, KB974417 will fail installation.

    2. New systems being updated from images pre-dating October 2009’s security updates. The WUAgent fails to properly schedule the order of installation of KB974417 and KB976569, causing KB976569 to be installed prior to KB974417 in the same session. Why the WUAgent chooses to install a compatibility update prior to a security update, or why the newer update is installed prior to the older update, are two questions I have posed to the WSUS/WUA team.

    In the meantime, for those customers encountering this issue, the only known remediation is to uninstall KB976569, then install KB974417, and then re-install KB976569.

    For customers that are installing batches of updates, it is suggested to install KB974417 (and other security updates) prior to installing non-security updates, and specifically prior to installing KB976569. The easiest way to achieve this would be to defer the installation of KB976569 until all other deployment activities are completed.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, April 9, 2010 7:38 PM
    Moderator
  • Strangely enough if you try and manually download and install KB974417 it displays a message that the update is not needed in this configuration.

    So the question is why it is not needed when installed manually but WSUS client still insists on trying to install it with an error as a result?

    Monday, April 12, 2010 1:35 PM
  • Has there been any movement toward a resolution?  I also have systems experiencing this issue.
    Thursday, April 15, 2010 12:09 PM
  • Has there been any movement toward a resolution?  I also have systems experiencing this issue.

    Not that's been shared with me. I'll ping the MS folks again and see if they have anything to share.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, April 15, 2010 4:57 PM
    Moderator
  • Not sure if Lawrence has a direct line to Microsoft for something like this, but we are starting to see this issue too with new deployments of Windows XP and Server 2003 R2 SP2 when starting from scratch.     I found this thread very helpful and will be opening a case with Microsoft a bit later today to hopefully get a specific response.    I will post what is found on this forum.   I had not yet seen any reference to a case being opened.    Hopefully we'll get this resolved and the logic for KB976569 will be updated / re-released.

    We will be opening this case on Monday if Lawrence hasn't heard anything by then.

    Brian

    • Edited by Brian Busse Friday, April 16, 2010 7:28 PM Added 'Monday' comment
    Friday, April 16, 2010 4:28 PM
  • Not sure if Lawrence has a direct line to Microsoft for something like this

    I have the ears of a few key people in Redmond... :-)

    A perq of my MVP status.

    They are aware of this issue ("Failure to detect installed rule"), and the specific causes. This is not the first instance of this situation, but it is the first one caught/reported AFTER the update had been expired -- which is complicating the matter. In the previous occurrence, a simple revision to the live update was released and all was copasetic.

    However, lacking any indication that this issue is causing failures to deploy updates, it's down at the bottom of their priority list, I'm sure.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, April 16, 2010 8:56 PM
    Moderator
  • I guess what i'd be interested in knowing is,  based on what you wrote,  should we be be declining KB974417 as its no longer needed?    Or is it still something that needs to be approved/deployed?     If it can/should be declined, that is obviously an easy way to make sure new/fresh installs would not even try to install the older patch.

    Thoughts?

    Brian

    Monday, April 19, 2010 5:29 PM
  • I guess what i'd be interested in knowing is,  based on what you wrote,  should we be be declining KB974417 as its no longer needed?


    Absolutely NOT! KB974417 is an active security update from October, 2009. It should have been installed on your systems MONTHS AGO! It's absolutely required to be installed as of today.

    What I am suggesting is that you do not install KB976569 until after you have installed all required Critical and Security Updates through March, 2010.

    What I'm suggesting, generically, is that optional updates should never be installed on a system that does not already have 100% of the available Security and Critical Updates already applied.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, April 19, 2010 11:37 PM
    Moderator
  • :)  Ok,  I didn't think thats what you meant but wanted to be sure.

    In our environment for our WSUS containers,  we have a 'ServerBuild' container that all of our servers go into which has all currently approved patches,updates,etc.. as well as whatever most recently got released from Microsoft.   We have another container that is for DEV/QA systems which gets all the updates we approved just like 'ServerBuild'

    We then have another set of containers/subcontainers that are 'production' and only have all patches/updates/etc.. that were approved and have gone through Dev/QA testing.

    So we at least have a layer of safety for testing in dev/Q but witih new builds, they get everything (including these 2 KBs that 'fight' eachother).   it sounds like based on what you're recommending that we have a 2-step staging area... Security patches in one container, and updates/etc.. in another.  Moving the computer account from the security patch container to the 'other updates' container once all security patches are applied.  

    Am I misunderstanding?   i get the methodology, its just sad that we'd potentially have to change our procedures based on a mistake made in a single patch instead of Microsoft just fixing the problem by re-releasing the update to supercede, etc... the broken one.

    Been working on another issue so i haven't had time to call Microsoft yet, but that will probably happen tomorrow.

    Brian

     

    Tuesday, April 20, 2010 5:59 PM
  • it sounds like based on what you're recommending that we have a 2-step staging area... Security patches in one container, and updates/etc.. in another.  Moving the computer account from the security patch container to the 'other updates' container once all security patches are applied.  

    To take this even a step farther... the security patches step should occur after the OS is installed but before any server applications are installed.

    Using multiple OUs is one way to implement this process -- if you're doing this through fully automated installations. If an installation admin is interacting with the server console during installation, it's a trivial matter to use Custom mode of the WU tool and install only OS Security and Critical Updates at that stage.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, April 21, 2010 1:45 PM
    Moderator
  • Hi again.

    After all this I opened a case with MS Premier Support.

    The official answer was that they are working for a updated hotfix that resolves this problem for which they gave me about a months time to be released.

    Also they said that the simplest resolution would be for the KB974417 update to be declined  since all the  files signatures are older than the ones applied by  KB976569 (you can see this by your shelves by looking the updates file list versions in the pages regarding these updates). 

    I declined the older update and all are working fine.

    Saturday, April 24, 2010 8:09 PM
  • Also they said that the simplest resolution would be for the KB974417 update to be declined  since all the  files signatures are older than the ones applied by  KB976569 (you can see this by your shelves by looking the updates file list versions in the pages regarding these updates). 

    Interesting . . . I must admit, I hadn't even considered checking the actual files updated by these two udpates, given that one wasn't even a security update!

    So the REAL defect is that KB976569 should supercede KB974417. They don't need an updated hotfix.. they just need to REPUBLISH KB976569 with the correct supercession metadata!

    I agree, declining KB974417 does appear to be the BETTER solution given that KB976569 does contain newer builds of the three files updated by KB974417.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Sunday, April 25, 2010 9:55 PM
    Moderator
  • I didnt consider the posibility of these two updates to have any supercedence between them until I tried running the update manually.

    The message was clear. I didnt need the older update!

    Now why on earth an update that when you run it manually says that you dont need it and when its run by the windows update service gives a cryptic error message I dont really know but thanks to that message I tried checking the file versions.

    I had the same suggestion to the support people. Update the supercedence metadata and all is well.

    In order to do it I needed to go up a level to the WSUS support team and spend a few hours more of our contract which I didnt want so the simplest solution was the one given.

    Now they can publish a new update whenever they want.

     

    Monday, April 26, 2010 9:59 AM
  • Microsoft Forum moderators consider this question answered? We still don't have official solution/workaround for this? ...or do we?

    Tnx, MS

    Wednesday, May 5, 2010 4:46 AM
  • Microsoft Forum moderators consider this question answered? We still don't have official solution/workaround for this? ...or do we?

    Tnx, MS


    The actual *answer* is that the files updated by KB976569 supersede those updated by KB974417, and the metadata (and, arguably, update classification) of KB976569 is defective in failing to identify that supersession status.

    The appropriate step (i.e. workaround, if you prefer) is to remove the approvals for KB974417 and deploy KB976569 (which, likely, is already deployed in this particular scenario).

    Hopefully KB976569 will be revised to reflect the correct metadata configuration.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, May 5, 2010 4:28 PM
    Moderator
  • Hopefully KB976569 will be revised to reflect the correct metadata configuration.

    I just got informed that a revision to KB974417 to suppress it's detection if KB976569 is already installed will be released on Patch Tuesday (5/11).

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, May 6, 2010 12:39 AM
    Moderator
  • Excellent news, thanks for your effort!
    Friday, May 7, 2010 8:55 AM
  • I have read all the way through this series and I find on shut down KB974417 is automatically re-installed but the installation is claimed as succesful but it is not.

    I see that a wor-around is to unistall KB976569 then install KB974417 and re-install KB976569

    My problem is that I cannot find KB976569.  is it, for example .net framework 3.5?

    Wednesday, May 12, 2010 3:54 PM
  • My problem is that I cannot find KB976569.  is it, for example .net framework 3.5?
    Perhaps you do not have KB976569 on your WSUS Server. It is a non-security/non-critical update released into the Updates classification. It's title is "Microsoft .NET Framework 2.0 Service Pack 2 Update ...." and then the title further classifies the update for Itanium, x86 or x64. The non-Itanium updates are also applicable to Windows XP systems with .NET20SP2 installed.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, May 12, 2010 8:48 PM
    Moderator
  • I see that a wor-around is to unistall KB976569 then install KB974417 and re-install KB976569

    Actually the correct 'workaround', as of yesterday, is to approve the revision to KB974417 which eliminates this issue.

    Alternatively, the previous and correct workaround was to remove the approvals for KB974417 if KB956569 was already installed.

    If you don't have KB976569 installed, and you're having issues installing KB974417 then you have an entirely separate issue from those discussed in this thread. Nonetheless, as of today, though, your next step, still, is to ensure you have the May 11th revision (#105) approved, and that is the revision being installed by your clients.

    If you continue to have this issue with Rev 105, you should start a new thread and provdie complete system and environmental details .. including a WindowsUpdate.log showing the installation and reboot.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, May 12, 2010 8:51 PM
    Moderator
  • I have a similar problem, My KB974417 will not install, I get the error code of 0x643.

    I have been on the forums and looked on my computer to see if my Office Source Engine is disabled but I can not find it in my list of services.

    i have deleted the KB974417 file from windows/prefetch once and tried to update again but nothing changed.

     

    I am not a complete technophobe but I am not sure what I am doing. I am now worried that other updates are not getting through, I have been looking through these forums and am now completely lost.

    can you please advise???

    Monday, May 17, 2010 9:32 AM
  • Ok I have reaad through this now..

    I have searched in my search file and add/remove programme for KB976569, It is not on my XP.

    My computer continually wants to install KB974417 and never can for whatever reason.

    I am confused and lost what am I doing wrong here??

    I have installed that diagnostic platform and sent it to microsoft.

    Can anyone please advise??

    Monday, May 17, 2010 9:55 AM
  • You can try to follow these steps

    http://aiscer.spaces.live.com/blog/cns!5280D9CA87E8C0D5!326.entry?sa=447968279

    HTH


    Edoardo Benussi - Microsoft® MVP
    Management Infrastructure - Systems Administration
    https://mvp.support.microsoft.com/Profile/Benussi
    Windows Server Italian Forum Moderator
    edo[at]mvps[dot]org
    Monday, May 17, 2010 1:11 PM
  • You can try to follow these steps

    http://aiscer.spaces.live.com/blog/cns!5280D9CA87E8C0D5!326.entry?sa=447968279


    The correct resolution has been provided in this thread already. Pointing posters to convoluted procedures that are unnecessary, and arguably incorrect, is not helpful. The correct resolution is to either remove the approvals for KB974417 or ensure the May 11th (Rev 105) revision is approved. That is all that is necessary.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, May 17, 2010 2:02 PM
    Moderator
  • Well I'm having no luck with this. When I look in WSUS I see 3 entries for KB974417. All have a revision history of 5/11/2010. The 2 for x64 and Itanium are revision number 105. The one for W2K, W2K3, and XP is rev 104.

    I tried WindowsUpdate on this 32 bit server and that patch failed with "Error Code: 0x645".

    In the eventlog I see this:

    Event Type: Error
    Event Source: HotFixInstaller
    Event Category: None
    Event ID: 5000
    Date:  5/26/2010
    Time:  12:48:13 PM
    User:  N/A
    Computer: WEBSRVR
    Description:
    EventType visualstudio8setup, P1 microsoft .net framework 2.0-kb974417, P2 1033, P3 1605, P4 msi, P5 f, P6 9.0.40302.0, P7 install, P8 x86, P9 w2k3, P10 0.

    Event Type: Error
    Event Source: Windows Update Agent
    Event Category: Installation
    Event ID: 20
    Date:  5/26/2010
    Time:  12:48:24 PM
    User:  N/A
    Computer: WEBSRVR
    Description:
    Installation Failure: Windows failed to install the following update with error 0x80070643: Microsoft .NET Framework 2.0 Service Pack 2 Security Update for Windows 2000, Windows Server 2003, and Windows XP (KB974417).

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    Data:
    0000: 57 69 6e 33 32 48 52 65   Win32HRe
    0008: 73 75 6c 74 3d 30 78 38   sult=0x8
    0010: 30 30 37 30 36 34 33 20   0070643
    0018: 55 70 64 61 74 65 49 44   UpdateID
    0020: 3d 7b 33 39 35 38 36 39   ={395869
    0028: 45 44 2d 42 42 35 44 2d   ED-BB5D-
    0030: 34 30 39 30 2d 42 35 32   4090-B52
    0038: 43 2d 34 38 30 30 36 45   C-48006E
    0040: 31 46 41 36 38 32 7d 20   1FA682}
    0048: 52 65 76 69 73 69 6f 6e   Revision
    0050: 4e 75 6d 62 65 72 3d 31   Number=1
    0058: 30 34 20 00               04 .   

    That says that WindowsUpdate is still delivering the 104 version. Any idea where I can specifically download the 32 bit 105 version?

    From what I can tell, somehow these 3 dll's got backleveled. mscordacwks.dll, mscorlib.dll, mscorwks.dll. The file dates are 11-24-2008. KB974417 was applied last fall so those dll's should have a timestamp of 2009. I would prefer not doing the "Framework cleanup and reinstall" path, so I am considering installing a hotfix like http://support.microsoft.com/?kbid=982318 which should superced those dll's.

     

     

    Wednesday, May 26, 2010 5:15 PM
  • Well I'm having no luck with this. When I look in WSUS I see 3 entries for KB974417. All have a revision history of 5/11/2010. The 2 for x64 and Itanium are revision number 105. The one for W2K, W2K3, and XP is rev 104.

    I tried WindowsUpdate on this 32 bit server and that patch failed with "Error Code: 0x645".

    Yes. Yes. Yes. This is the *expected* behavior.

    You CANNOT INSTALL KB974417 to a machine that already has KB976569 installed. PERIOD.

    Do not try to install KB974417. It is no longer needed; it will not install.

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, May 27, 2010 1:17 PM
    Moderator
  • For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    Data:
    0000: 57 69 6e 33 32 48 52 65   Win32HRe
    0008: 73 75 6c 74 3d 30 78 38   sult=0x8
    0010: 30 30 37 30 36 34 33 20   0070643
    0018: 55 70 64 61 74 65 49 44   UpdateID
    0020: 3d 7b 33 39 35 38 36 39   ={395869
    0028: 45 44 2d 42 42 35 44 2d   ED-BB5D-
    0030: 34 30 39 30 2d 42 35 32   4090-B52
    0038: 43 2d 34 38 30 30 36 45   C-48006E
    0040: 31 46 41 36 38 32 7d 20   1FA682}
    0048: 52 65 76 69 73 69 6f 6e   Revision
    0050: 4e 75 6d 62 65 72 3d 31   Number=1
    0058: 30 34 20 00               04 .   

    That says that WindowsUpdate is still delivering the 104 version. Any idea where I can specifically download the 32 bit 105 version?

    Unless you disabled the default rule -- the newer revision will be automatically approved. Check the Revision History screen for that update and confirm that Rev 105 is APPROVED and Rev 104 is NOT APPROVED, and then force another detection on the client so that the newer revision will be scanned. When it is, the update will be "unscheduled" from the installation.

    But.. truly... if KB976569 is already installed, you should set KB974417 to NOT APPROVED for every group.

    I cannot comment on what WindowsUpdate did, or did not do. This is the WSUS forum. We've thoroughly and sufficiently described the interaction and behavior of these updates, including the cause, and the appropriate resolution. If you follow the given instructions rather than continuing to try to diagnose a non-existent problem we all can go on to more pressing issues.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, May 27, 2010 1:19 PM
    Moderator