Windows 7 SP1 seems to break Acrobat X LUP

  • Anonymous - 2011-02-24

    We've successfully deployed Adobe Acrobat X Pro to over 100 Windows 7, Vista,
    and XP computers here. It works great and has saved countless hours. Now with
    Windows 7 SP1 the LUP/Windows Update install of Acrobat no longer works,
    claiming there's an issue with digital certificates. We tried re-signing the
    package but the song remains the same. A clean Windows 7 install, patched
    except for SP1 still installs fine, do the same thing with SP1 and it fails.

    More notes: Adobe Flash (plugin and activex), Java Runtime Engine rev 23, and
    Firefox 3.6.13 are all installing as well and still install fine after SP1.
    The Acrobat X installer is set to install 10.0, then apply the 10.0.1 patch
    the second time through. If you manually install 10.0 on Windows 7 SP1, the
    10.0.1 patch will also fail (as published with LUP and consumed through
    Windows Update).

    Any clues or similar/conflicting experiences?

    Will post specific error messages when I can get them, but basically it's the
    big red X that usually means you have a bad cert setup (which seems unlikely
    considering all the other facts, including the re-signing).

    Thanks in advance,


  • Bryan Dam

    Bryan Dam - 2011-02-24

    A few questions/suggestions although the precise error messages will be
    crucial to have. Have you tried recreating the Reader X package from scratch?
    Where are you seeing this error; I'm not aware of any big red X in LUP. Are
    you saying that SP1 broke existing installations of Reader or just that
    machines running SP1 it can no longer perform new installs. Lastly, I take it
    manual installation works. If so, refer to the windows update log to get the
    actual command the the update agent ran and try that manually.

  • Anonymous - 2011-02-24

    Hi Bryan, thanks for responding so quickly. The "red x" in question is in
    Windows Update on the SP1 clients, the typical "updates have failed" marker.
    The package is Adobe Acrobat X Pro, not Adobe Reader X. Existing installations
    of Acrobat work fine, LUP has allowed me to install it on over 100 computers,
    and subsequently push out the 10.0.1 to that same batch of computers when it
    was released.

    The problem is that it seems that any computer with Windows 7 SP1 on it won't
    take either of those packages for any reason. The package still works fine on
    any and all versions of Windows up to Windows 7 (without SP1).

    I could re-create the whole thing but it seems pointless as it works fine for
    everything but SP1. The certs and signatures are correct and distributed by
    Group Policy to all the machines, which also have the registry setting to
    allow 3rd party signed updates.

    More info: On a Windows 7 (non SP1) client laptop I uninstalled Acrobat,
    install SP1, then ran Windows Update and successfully installed Acrobat, then
    subsequently successfully installed the 10.0.1 patch. Two things here, 1) it
    wasn't a clean run-through since Acrobat had been installed previously, and 2)
    the main difference is that SP1 was installed on the non-SP1 version of
    Windows 7, instead of the slipstreamed ISO version of Windows 7 with SP1
    included. We're running another test to see if that result is replicable
    (Windows 7 clean install, then adding SP1 after the fact).

    Next post is the errors from Windows Update.

  • Anonymous - 2011-02-24

    2011-02-24 10:39:13:224 868 924 Misc Validating signature for C:\Windows\Softw

    2011-02-24 10:39:13:224 868 924 Misc WARNING: Digital Signatures on file C:\Wi
    ndows\SoftwareDistribution\Download\5862899cce67d1ebc09b1779acda2350\a72b34be- are not trusted: Error 0x80070570

    2011-02-24 10:39:13:287 868 924 DnldMgr WARNING: File failed postprocessing,
    error = 80070570

    2011-02-24 10:39:13:287 868 924 DnldMgr Failed file: URL = 'http://wsus.caes.
    Local path = 'C:\Windows\SoftwareDistribution\Download\5862899cce67d1ebc09b177

    2011-02-24 10:39:13:847 868 924 Misc Validating signature for C:\Windows\Softw

    2011-02-24 10:39:14:066 868 924 Misc WARNING: Digital Signatures on file C:\Wi
    ndows\SoftwareDistribution\Download\5862899cce67d1ebc09b1779acda2350\a72b34be- are not trusted: Error 0x80070570

    2011-02-24 10:39:14:190 868 924 DnldMgr WARNING: File failed postprocessing,
    error = 80070570

    2011-02-24 10:39:14:190 868 924 DnldMgr Failed file: URL = 'http://wsus.caes.
    Local path = 'C:\Windows\SoftwareDistribution\Download\5862899cce67d1ebc09b177

    2011-02-24 10:39:14:190 868 924 DnldMgr Error 0x80070570 occurred while
    downloading update; notifying dependent calls.

    2011-02-24 10:39:14:206 868 8f0 AU >>## RESUMED ## AU: Download update

    2011-02-24 10:39:14:206 868 8f0 AU # WARNING: Download failed, error =

  • Bryan Dam

    Bryan Dam - 2011-02-24

    To be clear, like you, I'm sort of at a loss to explain this. Anything I think
    of is disproved by the fact that other clients and other updates on these SP1
    clients work. The only unique thing I notice about the log portion above is
    that this update is apparently large enough to require being split into two
    CAB files. I'm not sure it's relevant, but I haven't actually seen that happen

    The only thing I can think of is to look at the CAB files in question both in
    the remote content folder and the local softwaredistribution folder and
    manually verify that the digital signatures match each other and the cert you
    have distributed. You might also try getting a hash for each file and see if
    something is going wrong on the download.

  • Anonymous - 2011-02-25

    Thanks for the ideas, I'll post more info as I get it.

  • Bryan Dam

    Bryan Dam - 2011-02-25

    A few other thoughts although they aren't specific to Win 7 they might be
    worth testing:

    For what it's worth the 0x80070570 error code
    equates to ERROR_FILE_CORRUPT.
    You might try disabling any antivirus software you have and see if that's
    somehow interfering.

    Barring any of the above working I would make sure the update in question is
    the only one needed, disable the windows update on the client, clean out the
    SoftwareDistribution folder, delete/backup the windows update log, start
    windows update, kick off a detection, wait 20 minutes or so, and post the log.
    If it's too large to paste on the forum just place it somewhere I can grab it

  • Anonymous - 2011-02-26

    So I tried Windows 7 clean install again, then adding SP1, then running the
    updates, and it worked. Turned my findings over to my coworker and he tried
    the same thing with his BDD build and it still fails.

    I can't really do all the steps to clean out Software Distribution, etc. and
    have a valid deployment method. Needless to say the package appears on the
    first run of WU after a fresh 7 install and fresh SP1 install, so I don't
    think it's some kind of download cache corruption.

    That last link you sent certainly looks to be on target, but the WSUS/LUP
    server is Windows Server 2008, so no patch available. Maybe the WSUS server
    needs to be on R2 SP1? It's currently on W2k8 SP2.

  • snarfle

    snarfle - 2011-02-26

    The kb article talks about downloads > ~500 meg. My reader 10.0 patch isn't
    nearly that big. Is yours?

    While clearly the best approach here is to figure out why this isn't working
    and getting it resolved, if you need an immediate work-around, there may be a

    In the download area there is a tool named RunIt. Using this, you could make
    an update that launches MSIExec against a network copy of the msi file (thus
    avoiding the large package size issue). Or perhaps invoke a batch file that
    copies the .msi file locally (checking the exit code from the copy) and then
    runs msiexec against the local copy. You would need to make sure that the
    LocalSystem account has access to the network share.

    Be aware: Launching updates from WUAPP may NOT run the update under the local
    system account, but may instead use the the credentials of the logged in user
    (if the logged in user is an administrator). Something to be aware of during

    Clearly this approach is a hack. Running MSI files is definitely the better
    solution. But if time becomes a constraint, it might be worth investigating.

  • Bryan Dam

    Bryan Dam - 2011-02-26

    My reader 10.0 patch isn't nearly that big.

    He's not distributing Adobe Reader, he's distributing Acrobat Pro.

  • snarfle

    snarfle - 2011-02-26

    Doh! It's right there in the title.

    Still, the RunIt approach might be a solution.

  • Anonymous - 2011-02-28

    For those interested I'm following the breadcrumbs I can find regarding this
    security issue/fix:

    My current theory is that my WSUS server on W2008 SP2 might not have the
    WinVerifyTrust patch level compatible with Windows 7 SP1. I'm upgrading it to
    W2008 R2 SP1 and then we'll re-run all our tests. I have a sneaking suspicion
    that the "fix" for W2003 that made large signed CAB files work was undone or
    perhaps altered by the later "security patch" for later versions.

  • Anonymous - 2011-02-28

    Oh, all that to say I'm hoping the latest service pack applied to both client
    and server solves the problem (which I currently believe to be a large CAB
    signing issue).

  • Anonymous - 2011-03-11

    There is a post on the TechNet managed newsgroups you may be interested in
    about an issue with System Center Essentials deployments (which use WSUS).
    Almost certainly the same issue from the looks of the error numbers:

    I think you can only post there if you have a TechNet subscription, but a
    Microsoft rep has recently posted that they have reproduced the problem
    internally, so hopefully a fix will be forthcoming.


Log in to post a comment.