none
SCUP MMC crash when pointing to MSP file

    Question

  • I'm trying to create a SCUP patch entry where the patch in question is an MSP file.  I can successfully enter all of the basic data.  But the moment that I specify the patch and download URL (.msp file) and then click Next, I get an app crash. 

    If I enter an exe patchname and location, it all works fine.  it's only when try and reference an msp file for the patch when it crashes.

    I have the msp file on my c:\ drive, and I'm pointing to the proper Internet URL to download this patch - the exclamation points go away and all looks good.  I'm not even entering any commandline switches yet and I get the crash.

    I'm running an x64 Vista system.  the error i get is below.  Has this been seen before?  am I missing a patch that can fix this?

    Description:

    Stopped working

    Problem signature:

    Problem Event Name: CLR20r3

    Problem Signature 01: mmc.exe

    Problem Signature 02: 6.0.6001.18000

    Problem Signature 03: 47918d09

    Problem Signature 04: Microsoft.UpdateServices.Administration

    Problem Signature 05: 3.1.6001.1

    Problem Signature 06: 4797eee8

    Problem Signature 07: 46d

    Problem Signature 08: 14b

    Problem Signature 09: SBSGNT3I1THQKAH3YXTPIOZMIO314FJD

    OS Version: 6.0.6001.2.1.0.256.1

    Locale ID: 1033

    Tuesday, May 05, 2009 3:13 PM

All replies

  • Hello SCUPWorker,

    Where did you get the MSP from?  Is it on the web somewhere I can download and take a look at?

    Thanks...

    These postings are provided "AS IS" with no warranties, and confer no rights.
    Tuesday, May 05, 2009 5:51 PM
  • Thank you for the link.  I was able to verify the issue.  This happens with some newer MSP files (note, not all MSP files).   We are actively working on a fix, however, due to dependencies it will be a few months before we can release the fix.  I will respond to this thread once we have something to announce.


    These postings are provided "AS IS" with no warranties, and confer no rights.
    Tuesday, May 05, 2009 7:44 PM
  • thanks for looking into it.  Is there something I can do in the meantime?  Can I edit the xml file by hand to add this data?
    Tuesday, May 05, 2009 7:49 PM
  • Unfortunately due to where the issue is, there is no workaround at this time.
    These postings are provided "AS IS" with no warranties, and confer no rights.
    Tuesday, May 05, 2009 8:14 PM
  • I'm running into the same problem trying to add Adobe Reader's patch for 8.1.4 (found here:  http://www.adobe.com/support/downloads/product.jsp?platform=windows&product=10)

    The MMC console crashes at the same time as specified above.  Event Viewer shows the stoppage as a .NET Runtime 2.0 Error Reporting event.  Description is the same as listed above.  Is there a fix for this, or has anyone else seen this?
    Monday, June 08, 2009 7:36 PM
  • I can confirm the same error when trying to add Adobe Reader 9.1.1 patch ( http://www.adobe.com/support/downloads/thankyou.jsp?ftpID=4455&fileID=4147).
    • Proposed as answer by J_Wilk Thursday, June 11, 2009 1:55 PM
    Tuesday, June 09, 2009 10:14 AM
  • I'm having this same issue with the Acrobat msp's. Has anyone found a temporary workaround for this problem?
    Wednesday, June 10, 2009 4:07 PM
  • nope, I am creating normal packages to deploy those updates.
    Kent Agerlund | http://agerlund.spaces.live.com/blog/
    Wednesday, June 10, 2009 4:16 PM
    Moderator
  • Confirmed Adobe Reader 9.1.2 generates same error.
    Thursday, June 11, 2009 1:56 PM
  • I would like to clarify as it seems there may have been some confusion in regards to customers being completely blocked from distributing these updates via ConfigMgr. There is no workaround using SCUP. However, you can deploy these updates using ConfigMgr software distribution.
    These postings are provided "AS IS" with no warranties, and confer no rights.
    Wednesday, June 24, 2009 6:54 AM
  • I would like to clarify as it seems there may have been some confusion in regards to customers being completely blocked from distributing these updates via ConfigMgr. There is no workaround using SCUP. However, you can deploy these updates using ConfigMgr software distribution.
    These postings are provided "AS IS" with no warranties, and confer no rights.

    Here is what I've been doing as a workaround; I've repackaged the .msp file into a compiled AutoIt script. It actually works out quite nicely.
    Wednesday, June 24, 2009 11:06 AM
  • Just curious (as I'm getting pressure from supervisors) - Do you have an ETA for when the fix is released? Any estimated date will do, I just need to give them a hard date other than "in several months". I realize we can deploy using Software Distribution which is what we are doing, but that sort of defeats the purpose of using SCUP for these types of updates.

    Thanks again.
    Monday, June 29, 2009 5:18 PM
  • Same problem here.  Both Adobe Reader 9.1.1 and 9.1.2.
    Tuesday, June 30, 2009 7:44 PM
  • Will there be a fix for the problem in near future? I tried to create a Patch with latest Adobe .MSP and discovered the same error.
    Saturday, August 08, 2009 5:14 PM
  • Can someone please reply, i need an answer. The problem seems to exist since May 2009. So there should be a fix.
    Tuesday, August 11, 2009 8:37 AM
  • Can someone please reply, i need an answer. The problem seems to exist since May 2009. So there should be a fix.

    You should consider calling CSS (IOW open a case at Microsoft) so that they can assist you.
    Thursday, August 13, 2009 10:00 AM
  • Hi Thomas,
    I cant speak to the native SCUP fix timeframe, however the latest WSUS Extension Pack has a publisher that doesnt have this issue.
    We have a catalog too that includes Adobe 9.1 and patches 9.1.2 and 9.1.3.
    See if that helps.
    Monday, August 17, 2009 11:13 PM
  • Is there any update for when this fix will be available?  We recently deployed SCUP for the main purpose of deploying Adobe Reader MSP files.  This bug sort of defeats the entire purpose of our entire deployment.  We really like the SCUP product, it would be really great to get around this problem.  Any information on this would be very useful.  Thanks!
    Wednesday, August 26, 2009 1:59 PM
  • Hi DavidG,

    do you plan on keeping your catalog up to date as Adobe and others release new patches?  or is your catalog just a sample to help people get started on it?
    Wednesday, August 26, 2009 6:53 PM
  • Hi SCUPWorker,
    actually we are planning on keeping up with it, however we will not have any SLAs around that. It will be a best effort.
    Also, we are going to be updating to a new catalog here in the next few that includes adobe reader 7 and 8 updates.
    David
    Wednesday, August 26, 2009 7:49 PM
  • are those catalogs importable into SCUP and usable within SCCM?  or are they pretty specific to use in your product with WSUS?  In other words, can i use your catalog inside of my scup\sccm implementation?

    Wednesday, August 26, 2009 7:51 PM
  • The catalog should be compatible with SCUP.
    We use the same schema.
    David
    Wednesday, August 26, 2009 8:16 PM
  • Is this issue solved with a hotfix? I want to give scup 4.5 a new try to deploy adobe msp files.
    Friday, September 18, 2009 10:56 AM
  • We have just released an updated version of SCUP 4.5 to support WSUS 3.0 SP2.  With this release we also fixed a number of crashing bugs in the import and create update wizards.  This will not fix all the issues reported in this thread as some of them are problems with how the MSP is authored by the vendor.   SCUP will now display the exception when running into invalid schema (in SDP or updates). This will help isolate the issue so that customers can work with the supplying MSP vendor for a fix.

    To read more about the SCUP release read my blog at http://blogs.technet.com/jasonlewis/archive/2009/11/24/system-center-updates-publisher-scup-4-5-now-supports-wsus-3-0-sp2.aspx
    These postings are provided "AS IS" with no warranties, and confer no rights.
    Tuesday, November 24, 2009 6:53 PM