locked
Declining Updates RRS feed

  • Question

  • I have a few XP workstations that are just not going to install .NET 3.5 updates. These updates are not necessary for these workstations so I would like to decline them because their failure is blocking other updates.

    When I place these workstations in a special WSUS group and try to decline the troublesome updates I have to decline them for all workstations in the domain. I don't want to do that. I just want to decline them for specific workstations.

    How can I decline specific updates for specific workstations?

     

    Wednesday, December 8, 2010 9:51 PM

Answers

  • I have a few XP workstations that are just not going to install .NET 3.5 updates. These updates are not necessary for these workstations so I would like to decline them because their failure is blocking other updates.

    When I place these workstations in a special WSUS group and try to decline the troublesome updates I have to decline them for all workstations in the domain. I don't want to do that. I just want to decline them for specific workstations.

    How can I decline specific updates for specific workstations?

     


    You cannot decline an update for specific workstations or groups; you can only leave them Not Approved.

    If you don't need these updates on these machines, then you should also uninstall the .NET Framework v3.5 (and .NET Framework 3.0 and/or .NET Framework 2.0) from those systems, which will ensure that these updates are not detected as Needed/NotInstalled on those systems.

    Note: If the update are needed because the Framework is installed, and the installations are failing, this may be a manifestation of when you are attempting to install those updates, or what else is being installed simultaneous with those updates. I recommend the following practices:

    • Do not install .NET Framework updates concurrently with any other Security or Critical Updates.
    • Only install .NET Framework updates on fully patched machines.
    • Do not install .NET Framework updates on active systems, i.e. use scheduled installations overnight.
    • And, of course, do not install the .NET Framework unless an application requires the .NET Framework.

    Using those practices over the past couple of years I have not experienced a single .NET Framework installation failure.


    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
    • Marked as answer by Myrt Webb Saturday, December 11, 2010 4:18 PM
    Thursday, December 9, 2010 6:18 PM
  • Can you please explain more the second and third  best practices?

    The .NET Framework is not a core component of the Operating System, it is an application framework that sits on top of the Operating System and provides an application framework for accessing services and features of the Operating System.

    You can be reasonably certain that modifications to the .NET Framework in Microsoft dev groups are built on systems that are FULLY PATCHED. Ergo, having a system that is not fully patched means that underlying Operating System library files may have different code than the current builds of the .NET Framework (or patches) were developed upon. There is an implicit dependency on the patch level of the underlying Operating System by virtue of what the .NET Framework is, and how it implements it's capabilities.

    Not installing .NET Framework updates on active systems is merely a case of ensuring that .NET Framework -based applications are not in use. Unfortunately, many .NET Framework updates are packaged and distributed with a somewhat myopic view that there are no active conflicts on the target system. This is rarely the case on workstation systems during the workday. While the general Best Practice is to not install any update on an active system, this is even more critical when considering .NET Framework updates. Ultimately it's based in empirical data. The installation failure rate for .NET Framework updates installed on systems with NO logged-in user is exponentially lower than the installation failure rate for .NET Framework updates installed during the workday with an active user logged onto the system.


    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
    • Proposed as answer by R.Alikhani Monday, December 13, 2010 7:53 PM
    • Marked as answer by Myrt Webb Wednesday, December 15, 2010 7:42 PM
    Monday, December 13, 2010 6:47 PM

All replies

  • I have a few XP workstations that are just not going to install .NET 3.5 updates. These updates are not necessary for these workstations so I would like to decline them because their failure is blocking other updates.

    When I place these workstations in a special WSUS group and try to decline the troublesome updates I have to decline them for all workstations in the domain. I don't want to do that. I just want to decline them for specific workstations.

    How can I decline specific updates for specific workstations?

     


    You cannot decline an update for specific workstations or groups; you can only leave them Not Approved.

    If you don't need these updates on these machines, then you should also uninstall the .NET Framework v3.5 (and .NET Framework 3.0 and/or .NET Framework 2.0) from those systems, which will ensure that these updates are not detected as Needed/NotInstalled on those systems.

    Note: If the update are needed because the Framework is installed, and the installations are failing, this may be a manifestation of when you are attempting to install those updates, or what else is being installed simultaneous with those updates. I recommend the following practices:

    • Do not install .NET Framework updates concurrently with any other Security or Critical Updates.
    • Only install .NET Framework updates on fully patched machines.
    • Do not install .NET Framework updates on active systems, i.e. use scheduled installations overnight.
    • And, of course, do not install the .NET Framework unless an application requires the .NET Framework.

    Using those practices over the past couple of years I have not experienced a single .NET Framework installation failure.


    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
    • Marked as answer by Myrt Webb Saturday, December 11, 2010 4:18 PM
    Thursday, December 9, 2010 6:18 PM
  •  Can you please explain more the second and third  best practices?

     

    Thanks

    Saturday, December 11, 2010 2:14 PM
  • Can you please explain more the second and third  best practices?

    The .NET Framework is not a core component of the Operating System, it is an application framework that sits on top of the Operating System and provides an application framework for accessing services and features of the Operating System.

    You can be reasonably certain that modifications to the .NET Framework in Microsoft dev groups are built on systems that are FULLY PATCHED. Ergo, having a system that is not fully patched means that underlying Operating System library files may have different code than the current builds of the .NET Framework (or patches) were developed upon. There is an implicit dependency on the patch level of the underlying Operating System by virtue of what the .NET Framework is, and how it implements it's capabilities.

    Not installing .NET Framework updates on active systems is merely a case of ensuring that .NET Framework -based applications are not in use. Unfortunately, many .NET Framework updates are packaged and distributed with a somewhat myopic view that there are no active conflicts on the target system. This is rarely the case on workstation systems during the workday. While the general Best Practice is to not install any update on an active system, this is even more critical when considering .NET Framework updates. Ultimately it's based in empirical data. The installation failure rate for .NET Framework updates installed on systems with NO logged-in user is exponentially lower than the installation failure rate for .NET Framework updates installed during the workday with an active user logged onto the system.


    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
    • Proposed as answer by R.Alikhani Monday, December 13, 2010 7:53 PM
    • Marked as answer by Myrt Webb Wednesday, December 15, 2010 7:42 PM
    Monday, December 13, 2010 6:47 PM