Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
How do I do a manual import of an update into WSUS?

Answered How do I do a manual import of an update into WSUS?

  • Monday, April 05, 2010 2:54 PM
     
     
    Sign In to Vote
    1

    I need to import KB976244 into WSUS but it does not show up in the Microsoft Update Catalog.  How do I do this? 

    I have downloaded the fix and tried running this command from our WSUS server: wsusutil.exe import F:\temp\974266\Windows6.0-KB974266-x86.msu f:\temp\importx86.log

    But I get this error message:

    Updates are being imported. Please do not stop this program.
    Fatal Error: The export package does not contain a file named metadata.txt
    Parameter name: packagePath

    I have also tried extracting the files from the .msu and importing the extracted .cab file with the same result.

    Please Help!  Thanks.

     

All Replies

  • Monday, April 05, 2010 6:28 PM
    Moderator
     
     
    Sign In to Vote
    0

    If the update is not available in the Microsoft Catalog it cannot be imported into the WSUS environment. You're getting the errors because you are improperly using the wsusutil import command. That import command is designed for importing a previously extracted export catalog from a WSUS server.

    However, the good news is that the update is available in both the catalog, and the WSUS environment.

    Ensure that you have selected the Product Category System Center Virtual Machine Manager

    and the Update Classification Update Rollups

    and if not, enable them and run a manual synchronization to obtain the missing content.

    Searching in the catalog should be as simple as entering the six-digit KB number into the search block

    and this link will get you there directly:

    http://catalog.update.microsoft.com/v7/site/Search.aspx?q=976244

    so I'm somewhat surprised that you could not find it in the catalog -- but it is most definitely present.

    Of course, you should also be aware that KB976244 (rel. 11/10/2009) has been superceded by KB978560 (rel. 2/9/2010), so if you had no systems reporting KB976244 as needed prior to the release of KB978560, it's entirely possible that the Server Cleanup Wizard has declined that update (assuming you've previously selected Update Rollups and the product category for  SCVMM).

    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 05, 2010 8:05 PM
     
     
    Sign In to Vote
    0

    My mistake, I typed the KB number wrong.  The correct one is 974266: http://support.microsoft.com/default.aspx/kb/974266?p=1 

    This one I cannot find in the update catalog.  Any suggestions?

    Thanks for the information about the wsusutil usage.

     
  • Tuesday, April 06, 2010 10:10 PM
    Moderator
     
     
    Sign In to Vote
    0

    My mistake, I typed the KB number wrong.  The correct one is 974266: http://support.microsoft.com/default.aspx/kb/974266?p=1 

    This one I cannot find in the update catalog.  Any suggestions?

    Thanks for the information about the wsusutil usage.

    Ths is a =HOTFIX=.

    Hotfixes are not available in the catalogs; they must be downloaded directly, and some cases, such as this one, you must expressly request a download link from Microsoft. (They track who requests the hotfixes.)

    Note: Unless you are expressly experiencing one of the issues documented in the KB article, you should not apply this hotfix.

    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 08, 2010 2:47 AM
     
     
    Sign In to Vote
    0

    I have the hotfix already and need to apply it to several thousand computers that are experiencing the issue.  The best way for us to do this is to deploy it through WSUS but I do not know how to get it into WSUS to be able to deploy it.  How can I make this hotfix available in WSUS so that it can be deployed? Is it even an option to deploy it through WSUS?  If it isn't directly deployable via WSUS, can it be easily deployed through SCCM 2007?  If so, how?

    Thanks!

     
  • Thursday, April 08, 2010 1:52 PM
    Moderator
     
     Answered
    Sign In to Vote
    0

    I have the hotfix already and need to apply it to several thousand computers that are experiencing the issue.  The best way for us to do this is to deploy it through WSUS but I do not know how to get it into WSUS to be able to deploy it. 


    You cannot. HOTFIXes cannot be deployed via WSUS. Unless the update is published in the Microsoft Catalog you cannot use WSUS.

    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, February 18, 2011 10:54 PM
     
     
    Sign In to Vote
    0
    This is really inconvenient! I though WSUS has been designed to reduce the workload...
     
  • Tuesday, February 22, 2011 4:10 AM
    Moderator
     
     
    Sign In to Vote
    0
    I though WSUS has been designed to reduce the workload...
    WSUS provides a corporate solution for updates published via Windows Update and Microsoft Update. Hotfixes have never been published to Windows Update or Microsoft Update, so there's never been an expectatation -- not in 10 years -- that hotfixes would be available to WSUS environments.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
     
  • Tuesday, February 22, 2011 3:01 PM
     
     
    Sign In to Vote
    0
    Since I originally posted this article, I have implemented Configuration Manager 2007 and it works pretty well for pushing hotfixes.  I understand the challenges if you don't have SCCM in your environment and also it is a bit more reliable to ensure that Windows Update is running on your machines than it is to ensure that the SCCM client is installed.  There are more variables to deal with for SCCM than there is for WSUS which is the exact reason why I will not incorporate our WSUS server into the SCCM environment as a Software Update Point.  Maybe someday if things aren't so cumbersome with the software update point we'll use it, but that won't be anytime soon unless something changes.  WSUS is so easy to use and works so well. 
     
  • Tuesday, February 22, 2011 8:38 PM
     
     
    Sign In to Vote
    0
    You could deliver the hotfix via WSUS local publishing. I know several users of my project (http://www.localupdatepublisher.com) who are doing just that. Other software such as System Center Updates Publisher or Emminentware's 3rd Party Updates Pack should be able to work similarly.
     
  • Tuesday, February 22, 2011 8:51 PM
    Moderator
     
     
    Sign In to Vote
    0

    There's another more practical point that needs to be kept in mind here. Hotfixes are not intended for widespread (i.e. enterprise-wide) deployment. They are supposed to be installed only on those systems exhibiting the exact defect documented in the KB article.

    If an organization has thousands of machines exhibiting that defect, I would encourage them to open an issue with Microsoft, so that Microsoft can benefit from the thousands of such machines exhibiting such a defect.

    Installing a Hotfix on all enterprise machines just because it's available, or just because one or a few machines have the problem, is not a recommended course of action, and may actually cause more problems because a Hotfix is not fully regression tested.

    Ergo, deploying a Hotfix via WSUS is an oxymoron. Hotfixes should not be mass distributed.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
     
  • Friday, April 22, 2011 4:46 AM
     
     
    Sign In to Vote
    0

    If a corporation has thousands of machines, then they will be deployed via a SOE and will almost certainly be identical - and hence all will be suffering the same problem.

    Stick with the Regeression testing argument - it makes more sense.

     
  • Friday, April 22, 2011 4:58 PM
    Moderator
     
     
    Sign In to Vote
    0
    If a corporation has thousands of machines, then they will be deployed via a SOE and will almost certainly be identical - and hence all will be suffering the same problem.


    First, not all organizations with thousands of machines use an SOE, but I'm happy to grant that premise for the sake of discussion.

    Second, you assume, perhaps erroneously so, that a particular 'defect' is in a core component of the system that all thousands of users are actively using.

    As a contrary example, there is a current HOTFIX to a Remote Desktop Client update. While it's arguable whether the Remote Desktop Client update, tself, even needs to be installed on machines that are not using Remote Desktop Client (presumably RDC would be disabled on those machines), the point goes directly to the question of whether the subsequent HOTFIX needs to be applied. That HOTFIX, for example, is only NEEDED on machine that are actually using Remote Desktop Client, had issues installing the GDR update, and are demonstrating very specific behaviors in response to the gDR update. The HOTFIX should not be installed on machines where Remote Desktop is not in use, or where the behaviors are not observed.

    So while every machine might have the MSTSC.EXE tool installed, the issue is not about whether the file is present, but whether the BEHAVIOR is relevant. If MSTSC.EXE is not being used on a client system, then the HOTFIX should *NOT* be installed.

    So, while I do not disagree with the factual nature of your statement (that they all likely derive from one (or a few) master images), the premise that the HOTFIX will apply to all systems all of the time simply because they are image based machines is not correct, because it is *NEED* that such decisions should be based upon.

    Stick with the Regeression testing argument - it makes more sense.

    The regression argument is only one of many reasons; and I only chose to discuss the most relevant and significant of them, and it's not the best reason either. The best reason is simply the fact that you should not install unneeded software. Period.

     

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

     
  • Thursday, September 01, 2011 9:02 PM
     
     
    Sign In to Vote
    0
    Second, you assume, perhaps erroneously so, that a particular 'defect' is in a core component of the system that all thousands of users are actively using.

     

    But that's a real problem. On Windows XP & 2k3 WMI-query for CPU gives wrong CPU back.

    If I use an hardware inventory software I get wrong hardware (Intel Pentium III Xeon instead of Intel Core 2 Duo or instead of Intel Core 2 Quad or instead of ..)

    I' really need accurate CPU type for calculation of need for new computers (huge difference between Pentium III and Intel Core 2 Quad :-))

    So I've to mass distribute this http://support.microsoft.com/kb/953955 to every windows xp machine!

    How should I achieve this without WSUS (we "only" have 200 machines and have no SUS)

     
  • Thursday, September 01, 2011 10:30 PM
    Moderator
     
     
    Sign In to Vote
    0
    So I've to mass distribute this http://support.microsoft.com/kb/953955 to every windows xp machine!

    Well, see, that's part of the point of this discussion. I have a fundamental disagreement with the statement that "I need to deploy [HOTFIX] to every system", and I've already made my arguments for that point earlier in this thread.

    In the instant case, KB953955 only needs to be deployed to machines that have Intel Core 2 Duo machines running Windows XP or Windows Server 2003. Now, I highly doubt that every one of your Windows XP machines are running Intel Core 2 Duo processors (in fact, I would argue that any machine running an Intel Core 2 Duo processor probably should be focused on upgrading to Windows 7, not hotfixing a trival WMI CPU identifier issue on Windows XP).

    While WSUS does not natively support deployment of HOTFIXES, it is possible using the Local Publishing features of the WSUS API to build a package for distribution via WSUS -- as long as you can package the target files into an EXE, MSI, or MSP-based installer package. Distributing non-executable DLLs can be done by wrapping them in a self-extracting archive with a script to place them where they go.

    The complication, though, is that in order to properly target the detection logic of such a package, you would have to execute a WMI query to find out what CPU was installed -- which, of course, won't return the correct value until after the HOTFIX is applied. <Catch-22!>

    So, in fact, regardless of where you stand in this particular discussion about why WSUS does not natively distribute HOTFIXES, or even if it should, the fact is that it is technologically impossible to properly design the metadata to target this HOTFIX -- using any product: WU/MU, WSUS, or even Configuration Manager -- to the specific machines, by CPU, where the HOTFIX is needed. At best, you can only target this update by Operating System, and evaluate the risk of installing the HOTFIX on machines that do not have Intel Core 2 Duo CPUs. (I suspect the risk is minimal, maybe even zilch.)

    Or, you can use some other methodology (something that is not WMI-based; which probably means humans reading the Computer Properties dialog, or a clerical assistant researching procurement records) to identify the machines that do have Intel Core 2 Duo CPUs, and then explicitly place those computers in a WSUS Target Group, and approve such an update for only that Target Group.

    Of course, you'll still have to develop the update package for this HOTFIX... and that's an entirely different discussion!

    How should I achieve this without WSUS (we "only" have 200 machines and have no SUS)

    Answering this question is really beyond the scope of this forum. There are several means available for deploying software other than WSUS. I'm certain you're not the first organization that needs to do a large-scale deployment of a HOTFIX.

    Now the other interesting thing is that this HOTFIX consists of only ONE file: CIMWIN32.DLL -- so maybe approaching the question in simpler terms will help the process -- how would you go about distributing ONE FILE to a collection of machines? (Note that CIMWIN32.DLL is probably locked by the Windows Management Instrumentation service, so you'll probably have to stop that service, copy the file, restart the service to accomplish the update.)

    Btw.. just to complicate the issue, KB946544 applies to Windows XP systems running on Celeron processors... but hopefully you've retired all of them. :-)

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
     
  • Friday, September 02, 2011 10:25 AM
     
     
    Sign In to Vote
    0
    In the instant case, KB953955 only needs to be deployed to machines that have Intel Core 2 Duo machines running Windows XP or Windows Server 2003. Now, I highly doubt that every one of your Windows XP machines are running Intel Core 2 Duo processors (in fact, I would argue that any machine running an Intel Core 2 Duo processor probably should be focused on upgrading to Windows 7, not hotfixing a trival WMI CPU identifier issue on Windows XP).
     While WSUS does not natively support deployment of HOTFIXES, it is possible using the Local Publishing features of the WSUS API to build a package for distribution via WSUS -- as long as you can package the target files into an EXE, MSI, or MSP-based installer package. Distributing non-executable DLLs can be done by wrapping them in a self-extracting archive with a script to place them where they go.to find out what CPU was installed -- which, of course, won't return the correct value until after the HOTFIX is applied. <Catch-22!>

    So, in fact, regardless of where you stand in this particular discussion about why WSUS does not natively distribute HOTFIXES, or even if it should, the fact is that it is technologically impossible to properly design the metadata to target this HOTFIX -- using any product: WU/MU, WSUS, or even Configuration Manager -- to the specific machines, by CPU, where the HOTFIX is needed. At best, you can only target this update by Operating System, and evaluate the risk of installing the HOTFIX on machines that do not have Intel Core 2 Duo CPUs. (I suspect the risk is minimal, maybe even zilch.)

    Now the other interesting thing is that this HOTFIX consists of only ONE file: CIMWIN32.DLL -- so maybe approaching the question in simpler terms will help the process -- how would you go about distributing ONE FILE to a collection of machines? (Note that CIMWIN32.DLL is probably locked by the Windows Management Instrumentation service, so you'll probably have to stop that service, copy the file, restart the service to accomplish the update.)

    Btw.. just to complicate the issue, KB946544 applies to Windows XP systems running on Celeron processors... but hopefully you've retired all of them. :-)

    Wrong, the problem is on every(!) modern cpu not only Intel Core 2. Intel Pentium Exxx, Celeron, etc.
    So I've distribute to every machine with Windows XP but some really old ones, I'd like to find ;-) -> all machines with Windows XP.

    The reason why I'd like to query the machines it to check which machines are capable to run Windows 7 ...

     I think it would be a good idea to allow WSUS distribute ALL hotfixes, but with extra big fat warning.
    Why does MS decide what in my company is a big problem?

    PS: Distributing single files from a hotfix is a really bad idea, because you can't query which machine is patched.
     
  • Friday, September 02, 2011 1:10 PM
    Moderator
     
     
    Sign In to Vote
    0
    Wrong, the problem is on every(!) modern cpu not only Intel Core 2.

    The KB article only defines ONE CPU... ergo, the HOTFIX is only applicable to machines with that CPU.

    The Win32_Processor class returns the incorrect Name property for the processors on a computer that is running Windows XP or Windows Server 2003 and the computer has Intel Core 2 Duo processors installed

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
     
  • Friday, September 02, 2011 1:13 PM
    Moderator
     
     
    Sign In to Vote
    0
    I think it would be a good idea to allow WSUS distribute ALL hotfixes
    Your idea is noted, but I highly doubt that is going to happen. The two patch methodologies are distinctly separate toolsets.
    PS: Distributing single files from a hotfix is a really bad idea, because you can't query which machine is patched.
    Actually, since this patch is, in fact, only ONE file... querying the version of the file installed on the machine is EXACTLY how you would determine whether the machine was patched or not.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
     
  • Friday, May 18, 2012 5:07 PM
     
     
    Sign In to Vote
    0

    Mr Lawrence Garvin,

    I just want to say thank you for the knowledge transfer, all the topic here clarified many doubt i have, i am starting as WSUS admin on the company i work and this clarified a lot of questions i have, i know the topic is a year old, but has been very helpful. thanks again.