Adobe Acrobat Reader DC - MSP don't work

Topics: Configuration Issue, Publishing Issue
Sep 13, 2015 at 12:48 PM
Edited Sep 13, 2015 at 12:49 PM
Hi Guys,
for a new weeks i imported the installation files from the setup Version 15.007.20033.
Yesterday i added the AcroRdrDCUpd1500820082.msp and approved it to the same Group as the full installation. The Windows 7 Client don't find the update on Windows update service. I already deleted the Folder C:\Windows\SoftwareDistribution. So, have any one get worked this Szenario?

WPP Version: v1.3.1508.08
Oct 9, 2015 at 6:03 PM
I am actually wrestling with this very issue. When I tried to use 15.008.20082 from the Adobe catalog, it failed and when I checked the metadata, I noticed it was validating the 15.007.20033 install against a different product code. I've managed to get the clients to download the MSP update but when the clients try to perform the install, it completes saying the update was not applicable. I'm still trying a few things, mainly modifying the resulting metadata, as I'm guessing one of the validation steps is failing for some reason (version mismatch or something). The package I created for 15.007.20033 installs perfectly but the 15.008.20082 update reports 'not applicable'.
Coordinator
Oct 9, 2015 at 8:42 PM
I didn't use Adobe Catalog. At work, I have downloaded the MSP from the FTP site, and didn't have any problem with it.
It's possible that Adobe have made a mistake when creating this catalog.
You can post a question on Adobe's forum if you wish.
Oct 10, 2015 at 1:45 AM
DCourtel, thanks for the response. Hmm ... I just expired both packages and started over. I downloaded 15.007.20033 from the ftp site and the MSP file for 15.008.20082. I built 15.007.20033, uninstalled it from a desktop, and performed a check for updates. Like normal, it found 15.007.20033 and began the installation. I, next, in WPP I right clicked on Adobe Reader and selected Create An Update. I loaded the MSP file for 15.008.20082. I skipped through all the rules (using your Update Reader documentation) and published the update. Next, I right clicked on 15.008.20082, selected Revise, and selected 15.007.20033 for Supercedes and revised the update. Like before, when I do a Send Detect Now and then Send Report Now, for the desktop, it reports Not Applicable. I even set the Application Type to Application (versus Update) which didn't make a difference. When I Revise 15.008.20082 to get to the metadata, it does have the 15.007.20033 product code listed so at least that part is correct. I've also searched the registry on the desktop for the 15.007.20033 product code and I find it.
Oct 10, 2015 at 12:33 PM
DCourtel:
I don't use the catalog. I try it on the same way as you in your enviroment.
But the Update isn't Show im Windows update Dialog. :-(
Oct 10, 2015 at 1:06 PM
It won't show, at least from what preliminary troubleshooting I've done. The WindowsUpdate log never records downloading the update, which tells me something on WSUS is stopping it. One thing I am going to try is to install the MUI base version and then try the update. I noticed the 15.008.20082 MSP update, in the metadata, list a slew of languages for 15.007.20033 but my base is only US English. It honestly shouldn't matter but something in 15.008.20082 update's metadata is validating false but is needing to be true which is why I'm seeing Not Applicable. Using Adobe's ftp site to download the update fixed the product code mismatch I was having when I was using the catalog. I am using the catalog for updating Adobe Flash, which seems to be working.
Coordinator
Oct 10, 2015 at 4:02 PM
What happen if you manually launch the MSP fîle on the computer ?
Oct 10, 2015 at 4:05 PM
Edited Oct 10, 2015 at 4:06 PM
DCourtel wrote:
What happen if you manually launch the MSP fîle on the computer ?
Upgrade runs without any problems.
Oct 10, 2015 at 8:01 PM
badwurzach wrote:
DCourtel wrote:
What happen if you manually launch the MSP fîle on the computer ?
Upgrade runs without any problems.
Agree with that. I took the same MSP file I created the update package in WPP and ran it on the desktop. The GUI loaded and I navigated through the update. It finished, noting the update was successful. I launched Reader DC and verified 15.008.20082 was the current version. Hmm ... now I'm really confused. Could the way I'm building the package be the problem? I know the documentation, for Acrobat updates, say to bypass the rules, as the MSP file contains its own but could that be causing the problem? Even after I manually performed the update, WPP is still showing 'not applicable' for 15.008.20082 for the same computer. I thought it would have updated the status to Installed. Last Report was updated.
Oct 13, 2015 at 8:37 PM
Edited Oct 13, 2015 at 8:46 PM
Not sure if this is progress or not but I have managed to get the client to download the MSP file. I used the Update Creation Wizard in WPP, set the package type to UPDATE (Update Classification doesn't seem to mean much but I tried with Updates and Security Updates). On the first Rule page, I used product code

a6eade66-0000-0000-484e-7e8a45000000

which I found in the metadata for the 15.009.20069 update and assumed it was the product code for the US English version of 15.009.20069. This first rule will see if the update has already been applied so having that product there makes sense. Next Rule, I used product code

ac76ba86-7ad7-1033-7b44-ac0f074e4100

which is the product code for 15.007.20033. Since the patch is for 15.007.2003, I choose to install only if it finds that product code already installed.

With this, if I remove Adobe Reader DC from a client, run Windows Update, I will get the 15.007.20033 Adobe Reader. It installs successfully. I run Windows Update a second time and, ayep, it finds 15.009.20069. I try to install and get a Windows Error Code 80242006. It downloaded the cab file to the client computer. When I open the cab file, it contains the MSP update. If I extract the MSP from the cab file, I can run it on the client and it will install the update. Using Windows Update fails with the 80242006 error code, though, which I assume really doesn't tell me anything.

Also, forgot to mention, before I published the package, I deleted the metadata that was contained within 15.009.20069.
Oct 13, 2015 at 9:14 PM
Edited Oct 14, 2015 at 12:07 PM
badwurzach, here is what I finally figured out to get it to work.
  1. Created Update for Adobe Acrobat Reader DC 15.007.20033 (seems to be the base for Reader 2015)
  2. Created another Update for Adobe Acrobat Reader DC 15.009.20069 using the MSP with the following:
Package Type: Update
Update Classification: SecurityUpdates
Prerequisites: 15.007.20033

NEXT

Rule Type: Msi Patch Installed For Product
Add Rule
Patch Code: ac76ba86-7ad7-0000-2550-ac0f094e6500
Product Code: ac76ba86-7ad7-1033-7b44-ac0f074e4100
Click OK
Check Delete Rules at Package Level

NEXT

Rule Type: Msi Patch Installed For Product
Add Rule
Patch Code: ac76ba86-7ad7-0000-2550-ac0f094e6500
Product Code: ac76ba86-7ad7-1033-7b44-ac0f074e4100
Check Reverse Rule
Click OK
Check Delete Rules at Package Level

Click Publish

I got "Patch Code" from the registry where I manually installed the 15.009.20069 patch. I got "Product Code" from viewing the MSI. I could probably have used the Max/Min Version to accomplish the same task but this works so why re-invent the wheel?

To test, I removed Adobe Acrobat Reader DC from the client. I reset Windows Update on the client (just to make a clean start). I checked for Windows Updates. As expected, I get the update for Adobe Acrobat Reader DC 15.007.20033. I install. It installs successfully. I do another check for Windows Updates. As expected, I get the update for Adobe Acrobat Reader DC 15.009.20069. I install. It installs successfully. I do a final check for Windows Updates and, this time, I am told I have all updates!

I'm going to test this on several more clients with some doing a fresh install of Reader and others testing just the 15.009.20069 update. If you get a chance, please try and see if it works for you too.
Oct 14, 2015 at 2:17 PM
Yeah, I also have some Problems with users that can't open Adobe because It started two times after the Update. Maybe I did it wrong, because I added the MSI and only the new MSP and didn't see the, that the adobe updates AREN'T cumulative.

So question for the right way to do it:
  1. Add the .MSI AcroRdrDC1500720033_de_DE.msi
  2. Approve said MSI
  3. Add Update AcroRdrDCUpd1500820082.msp
  4. Approve Update
  5. Add newest Update AcroRdrDCUpd1500920069.msp
  6. Approve Update and select 1500820082.msp as "Superseed"
Is this right? That Way at least I read it out of the PDF under Documentation for Adobe 11
Oct 14, 2015 at 5:30 PM
Edited Oct 15, 2015 at 3:15 AM
I no longer have it showing up multiple times now. I think it was doing it because I was using the wrong Product Code. It kept showing up in Windows Update because the Product Code would never be found so it would always show up. The install would still work because the MSP file was smart enough to know the update was already installed.

To build the initial Adobe Acrobat Reader base, I followed the instructions in the Adobe Reader XI Deployment with Custom Settings (skipping the custom settings section). In other words, I extracted the Adobe Reader EXE (7zip), and uploaded the SETUP.EXE file in the Update Creation Wizard. I added the 5 additional files minus the MSP update file. If you view the PDF I note above, you'll start with Page 9.

Once you've published that (don't forget to use the MSI tool to get the product code), create another Update for Adobe Reader and add just the MSP file (use my instructions in the previous post to get it published). You'll create multiple of these as Adobe releases.

Do not use supersede. I was confused on that. Supersede means it replaces a previous update. That would be correct except Adobe doesn't repackage the downloadable executable into one file--i.e. all of their downloadable executables (for this year) will come with the MSI for version 15.007.20033 and an MSP for the update. What we were doing was superseding the full blown Adobe Reader with just the Update (MSP file)--i.e. kinda like trying to install Windows 7 from scratch with just the Windows 7 SP1 disc.

Hope this helps. I've been testing this quite a bit and it works flawlessly. I'm now tackling Java.

UPDATE: Just to clarify, you will always have 15.007.20033 as an approved update as this will take care of getting Adobe Reader installed on new computers. You'll create additional updates as Adobe releases them. If I understand this correctly, you'll expire the old update (15.009.20069, for example) and approve the newest release. I believe I read on Adobe's site each of their updates will be cumulative so you won't need to keep all of the updates approved--i.e. at any given time, Adobe will have 2 files for Adobe Reader, the base and whatever is the latest patch/update. So, at any given time, you'll always have 2 Adobe Reader updates approved. With Java and Flash, though, you'll just have 1 approved update. I guess, with them, you would use Supersede.
Oct 15, 2015 at 9:55 PM
Edited Oct 15, 2015 at 9:56 PM
@triton53
i modified the package rules as in your comment from Tue at 11:14 PM
At first windows update Service found Adobe Reader DC 15.007.20033. After that it found update 15.009.20069 and installed to. But if i search now for updates again, the Adobe update will be displayed for Installation again.
Oct 16, 2015 at 1:37 AM
My apologies for that. I did leave out some things so let's get you going as I've got a fully functional solution that handles Flash, Reader, and Java. You've got the base package done, so we don't need to worry about it. It sounds like you have the update almost correct as you only see it in Windows Update after the base has been installed.

I'm assuming you created the 15.009.20069 Update using the MSP file and did not add any other files when you built the update.
  1. Revise 15.009.20069
  2. Update Classification: SecurityUpdates
  3. Package Type: Update
  4. Prerequisites: 15.007.20033
  5. Next
    Msi Patch Installed For Product
  6. Patch Code: ac76ba86-7ad7-0000-2550-ac0f094e6500
  7. Product Code: ac76ba86-7ad7-1033-7b44-ac0f074e4100
  8. OK
  9. Delete Rules at Package Level
  10. Next
    Msi Patch Installed For Product
  11. Patch Code: ac76ba86-7ad7-0000-2550-ac0f094e6500
  12. Product Code: ac76ba86-7ad7-1033-7b44-ac0f074e4100
  13. Reverse Rule
  14. OK
  15. Delete Rules at Package Level
  16. Next
  17. Revise
That should do it. Let me know if it doesn't. When you approve both, if a client doesn't have the base (15.007.20033), WSPP will report the status for 15.009.20069 as Not Applicable since the client needs the base first.
Oct 16, 2015 at 11:36 AM
I created (step for step) the Packages as described by you.
Both packages Adobe Acrobat Reader DC - 15.007.20033 and Adobe Acrobat Reader DC - 15.009.20069 was installed sucessfully on the lab pc:
http://www.bilder-upload.eu/show.php?file=45052f-1444995716.png

After that Windows update search again and found the packges Adobe Acrobat Reader DC - 15.009.20069:
http://www.bilder-upload.eu/show.php?file=ab9a68-1444995852.png

In the package is only the msp file:
http://www.bilder-upload.eu/show.php?file=24a969-1444996129.png

Here the Details of my package for 15.009.20069:
http://www.bilder-upload.eu/show.php?file=acabed-1444996165.png
http://www.bilder-upload.eu/show.php?file=e2d374-1444996185.png
http://www.bilder-upload.eu/show.php?file=38a3da-1444996207.png
http://www.bilder-upload.eu/show.php?file=dd9601-1444996226.png

No idea where the error should be?!
Oct 16, 2015 at 3:58 PM
Edited Oct 18, 2015 at 7:46 PM
I bet Patch Code is the problem. Verify the patch code. Install patch on client, scan registry. There will be a registry entry for it. This update is checking for only 2 conditions. If it finds both conditions on the client, the update is already Installed. If not, it shows it in windows update. Sorry about missing that.

UPDATE: As luck would have it, Adobe snuck out an update on the 14th (15.009.20071)

http://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotes/DC/dccontinuousoctober2015ooc.html

So, this was a good opportunity to test things. I thought I'd expire 15.009.20069 but I noticed the size of 20071 was small and figured it needed 15.009.20069 installed.
  1. Downloaded AcroRdrDCUpd1500920071_incr.msp from ftp site
  2. Created a new Update
  3. Selected MSP file
  4. Package Type: Update
  5. Update Classification: SecurityUpdates
  6. Prerequisites: 15.009.20069
  7. NEXT
    Msi Patch Installed For Product
  8. Patch Code: ac76ba86-7ad7-0000-2550-ac0f094e6700
  9. Product Code: ac76ba86-7ad7-1033-7b44-ac0f074e4100
    *NOTE: Installed 15.009.20069 on client, search registry for "20071". Patch Code will equal PatchGUID value
  10. OK
  11. Check "Delete Rules at Package Level"
  12. NEXT
    Msi Patch Installed For Product
  13. Patch Code: ac76ba86-7ad7-0000-2550-ac0f094e6700
  14. Product Code: ac76ba86-7ad7-1033-7b44-ac0f074e4100
  15. Check "Reverse Rule"
  16. OK
  17. Check "Delete Rules at Package Level"
  18. NEXT
  19. PUBLISH
It looks like the Prerequisites option will do the work for us--i.e. by selecting 15.009.20069 for Prerequisites will ensure this update only shows up after that has been installed so this can be treated like any other update.

I've already tested this with Windows 10 and Windows 7. On a machine with 15.009.20069, I run Windows Update and I am presented with 15.009.20071. I install and run Windows Update again. No new (or repeat) updates. Next, I uninstall Adobe Reader DC from a client. I run Windows Update. Yes, I am presented with 15.007.20033. It installs and I run Windows Update again. Yes, only 15.009.20069 shows up. I install it and run Windows Update again. Yes, 15.009.20071 shows up. I install it and run Windows Update one last time. Yes, no new (or repeat) updates.

My problem with going this route is Adobe installs its update checker so I may have to use a Custom Update like I did with Java to remove the update checker.

UPDATE: To disable Adobe Reader DC's check for updates, I created a GPO and set the registry entry from https://www.adobe.com/devnet-docs/acrobatetk/tools/Wizard/WizardDC/online.html.

Hope this helps.
Oct 19, 2015 at 1:50 PM
In business inviroment, I recommend NOT to use the "Adobe Reader DC Continuous ( Base DC)". This product is for consumer enviroment.
Use the Adobe Reader Classic ( Base 2015). (Base installation: 15.006.30033 , MUI Updates: 15.006.30060 / 15.006.30094 ). This product is for business enviroment.
Why: only security updates, no feature updates, no "pay-features", GPO administation possible. No automatic updates.

I roll out the master installation manual with special config via WPP/WSUS, and all updates via WPP/ Adobe Update-Katalog. Its a 2-click rollout.

If you can read german ( with this nickname - i think so ) you can take a look in my documentation on:

http://road-books.jimdo.com/2015/07/09/howto-adobe-acrobat-reader-dc-2015-classic-track-angepasstes-software-deployment-mit-wsus-package-publisher/


maybe you see helpfull ideas.

enjoy it!
Oct 22, 2015 at 8:22 AM
Edited Oct 22, 2015 at 8:25 AM
Hi GMBU,
it didn't work for me. Which Version of wpp do you use?
I use the newest one, 1.3.1508.8. So it's possible, that there a bug with msp?

German:
Es funktioniert einfach bei mir nicht. Welche Version von WPP nutzt du?
Ich nutze die aktuelle Version 1.3.1508.8. Ies es möglich, dass es ein Bug mit MSP gibt?

Ich habe gestern versucht auf einem neuen Notebook den Adobe Acrobat XI 11.0.0 + 11.0.12 zu installieren. Beide Pakete sind seit 21.05.2014 bzw. 16.07.2015 in WPP eingepflegt. Beide Pakete konnten vor 3 Monaten noch auf einem Server Problem gefunden und installiert werden. In diesem Fall wurde nur das Programm installiert und das Update wird nicht gefunden.
Oct 23, 2015 at 5:53 AM
Hallo,
ich denke es gibt da einen Fehler in der Version 1.3.1508.8 - bei der Erstellung vom MSP-basierten Updates wurden bei mir die "Package level Rules" - Einträge
  • <msiar:MsiPatchInstalled/>
    und
  • <msiar:MsiPatchInstallable/>
NICHT automatisch angelegt.

Mit der Version 1.3.1504.15 funktioniert das noch problemlos.
Oct 27, 2015 at 10:19 AM
Edited Oct 27, 2015 at 11:40 AM
ok, ähm da der Fragesteller deutsch spricht denke ich wir können hier so weitermachen :-))

Ich verwende 1.3.1508.8 , und rolle damit aus, aktuell seit dem 19.10. das Update 15.006.30094 . Überhaupt keine Probleme.
Ich würde es im Rahmen der Fehlersuche eigentlich begrüßen wenn alle von der gleichen Softwareversion reden und nicht die XI und die DC Versionen wild durcheinander diskutieren, aber es muss auch so gehen :-)).

Ich prüfe mal den Hinweis von SGK1.....

Es ist korrekt, das Update 15.006.30094 enthält bei mir auch keine Einträge bei den "Package Level Rules" . Es wird aber trotzdem korrekt installiert.
Im übrigen: das Update 15.006.30060 enthält da auch keine Einträge und funktionierte auch, was mir sagt das das ein Holzweg ist, ich glaube da nicht an einen Bug.

Meine Updates sind über den Katalog erstellt, womöglich ist das anderes wenn man sie manuell erstellt, oder "ersetzendes Update" verwendet.

Adobe arbeitet, zumindest bis XI mit Updates unterschiedlichen Types, ich glaube die Quater Updates sind kummulativ und der Rest nicht, müßte ich nachlesen. Sprich es werden teilsweise die neuen nicht installiert wenn die vorhergehenden nicht da sind. Soweit ich gesehen habe steht in der Installationszusammenfassung des 11.0.12 zwar überall das Vorraussetzung 11.0 reicht, aber naja.... Da ich zu faul bin mir zu merken welche welche sind, verfahre ich so das ich ALLE seit dem Hauptprogramm erschienenen Updates auf "genehmigt" setze, Adobe sucht sich dann selbst raus was es braucht. Jaja, bei 10000 Clients sollte man es dann nicht mehr so machen aber in kleineren Netzwerken geht das schon. Ich würde also mal in die Richtung anregen.



Ich denke nicht das dein Update nicht "gefunden" wird. Wenn es veröffentlicht ist ist es draußen und wird gefunden. Welchen Status hat es denn im WPP auf dem Rechner für den es freigegeben wurde? (Installiert/Neustart/gedownloaded/nicht verfügbar/nicht installiert/unbekannt/fehler)

Gib doch mal die alten Reader Updates wieder frei, schadet doch nicht, die müßten ja noch in der Verwaltung stehen, nimmt er die denn an ? Und außerdem.... 11.0.13 wäre als aktuellestes Update auch ein guter Test. Und probier mal parallel via Katalog die Updates, um irgendwelche Felhler im Laden und publizieren auszuschließen.


Pro forma weise ich auch immer gerne wieder darauf hin das man nicht auf verschiedene Wege installierte Adobe mischen und updaten sollte, und aufpassen das man nicht die MUI Versionen mit normalen zusammenwürfelt.......... aber das scheint hier ja nicht der Fall.

Man kann davon ausgehen das die Freigaben der Updates für die entsprechende Computer(Verteilungs)gruppe alle richtig gesetzt sind und sich die Computer auch darin befinden.......? Das wäre wahrhaftig ein Grund das sie die Updates nicht finden :-)
Oct 28, 2015 at 3:05 AM
Edited Oct 28, 2015 at 3:10 AM
badwurzach wrote:
Hi GMBU,
it didn't work for me. Which Version of wpp do you use?
I use the newest one, 1.3.1508.8. So it's possible, that there a bug with msp?

German:
Es funktioniert einfach bei mir nicht. Welche Version von WPP nutzt du?
Ich nutze die aktuelle Version 1.3.1508.8. Ies es möglich, dass es ein Bug mit MSP gibt?

Ich habe gestern versucht auf einem neuen Notebook den Adobe Acrobat XI 11.0.0 + 11.0.12 zu installieren. Beide Pakete sind seit 21.05.2014 bzw. 16.07.2015 in WPP eingepflegt. Beide Pakete konnten vor 3 Monaten noch auf einem Server Problem gefunden und installiert werden. In diesem Fall wurde nur das Programm installiert und das Update wird nicht gefunden.
badwurzach, this is really, really weird. With the way I'm doing it, I am having no problems and have updated and done fresh installs of Adobe Reader across several hundred computers. My version of WPP is the same as yours. Using the Prerequisite option cuts down on any special rules I need to create, outside of the standard rule covered in the documentation--i.e. is it there and is it installable. For both rules, I use the "Msi Patch Installed For Product" (which I get once I install the patch/update on a single computer via the registry). Once it installs the update the first time, do you find that Patch Code ID from searching the registry? The fact that you keep getting it over and over again tells me it isn't. If you're using Prerequisite, the condition is testing true but, when it checks to see if it is already installed, it is testing false. Search your registry, after it installs the update the first time, for that patch code. Also, make sure you don't have any extra characters in the rules where you enter the patch code. Maybe there's a non-printable character at the beginning or end of the string. I know how frustrating this must be. You've followed my steps exactly so something is up with the patch code id, not WPP. Another thing, can you take the MSP file itself and install it on a computer? If so, the MSP is valid.
Oct 30, 2015 at 7:57 AM
Hello,
i had the same problems iwth Reader DC (2015)

Base-Version 15.006.30033 installs without problems.
Update (via adobe catalog) 15.006.30096 installs also, but wsus is sending this update again and again.

i had to create the following rule (section: <msiar:MsiPatchInstalled/> ):
<msiar:MsiPatchInstalledForProduct PatchCode="{ac76ba86-7ad7-ffff-2550-ae0f06759000}" ProductCode="{ac76ba86-7ad7-ffff-7b44-ae0f06755100}"/>

Afer that everything went fine.
Oct 30, 2015 at 10:06 AM
ok... what is with the other, older updates ? 30060 and 30094 works correctly ?

WSUS NOT sending updates !!, Clients load updates !

I public 30096 today, from Adobe Catalog, and check it, ......in the moment, there are no problem (two W7 + W10 Clients ). WPP Status of 30096 is "installed". No manual manipualtion of rules nessasary.

The rule you set, looks like the same check included in the original update. You can check it in the last WWP assistent rule window ( Metadaten ).

I found this in WPP assistent metadata section:

<msiar:MsiPatchMetadata><MsiPatch xmlns="http://www.microsoft.com/msi/patch_applicability.xsd" SchemaVersion="1.0.0.0" PatchGUID="{AC76BA86-7AD7-FFFF-2550-AE0F06759000}" MinMsiVersion="4" TargetsRTM="true"><TargetProduct MinMsiVersion="300"><TargetProductCode Validate="true">{AC76BA86-7AD7-FFFF-7B44-AE0F06755100}</TargetProductCode><TargetVersion Validate="true" ComparisonType="Equal" ComparisonFilter="MajorMinorUpdate">15.006.30033</TargetVersion><UpdatedVersion>15.006.30096</UpdatedVersion><TargetLanguage Validate="false">0</TargetLanguage><UpdatedLanguages>1027</UpdatedLanguages><UpgradeCode Validate="true">{A6EADE66-0000-0000-484E-7E8A45000000}</UpgradeCode></TargetProduct><TargetProductCode>{AC76BA86-7AD7-FFFF-7B44-AE0F06755100}</TargetProductCode><ObsoletedPatch>{AC76BA86-7AD7-FFFF-2550-AE0F06756C00}</ObsoletedPatch><ObsoletedPatch>{AC76BA86-7AD7-FFFF-2550-AE0F06758E00}</ObsoletedPatch><SequenceData><PatchFamily>AC76BA867AD7FFFF7B44AE0F06755100</PatchFamily><Sequence>15.006.30096.10000</Sequence><Attributes>1</Attributes></SequenceData></MsiPatch></msiar:MsiPatchMetadata>


Maybee:

remove the update from WPP, and import and publish it again.
Oct 30, 2015 at 10:25 AM
ok... what is with the other, older updates ? 30060 and 30094 works correctly ?
my understanding is: i only need base and last update from catalog.
I public 30096 today, from Adobe Catalog, and check it, ......in the moment, there are no problem (two W7 + W10 Clients ). WPP Status of 30096 is "installed". No manual manipualtion of rules nessasary.
interesting...
The rule you set, looks like the same check included in the original update. You can check it in the last WWP assistent rule window ( Metadaten ).
yes, i've looked in the metadata to get the PatchID for the rule.
remove the update from WPP, and import and publish it again.
same problem again, on my 3 win10 test clients, he tries to install the update again...

wir können das aber auch auf deutsch besprechen.. :-)
Oct 30, 2015 at 11:01 AM
molkanisonal wrote:
my understanding is: i only need base and last update from catalog.
I only ask because I want to know if this is a generally problem since beginnig of deployment DC 2015 Classic, or a new specific update problem.
I public 30096 today, from Adobe Catalog, and check it, ......in the moment, there are no problem (two W7 + W10 Clients ). WPP Status of 30096 is "installed". No manual manipualtion of rules nessasary.
interesting...

no. normal :-)
The rule you set, looks like the same check included in the original update. You can check it in the last WWP assistent rule window ( Metadaten ).
yes, i've looked in the metadata to get the PatchID for the rule.
remove the update from WPP, and import and publish it again.
same problem again, on my 3 win10 test clients, he tries to install the update again...

wir können das aber auch auf deutsch besprechen.. :-)
Ja das könnte hilfeich sein. :-)

Hm. Ich würde zur Eingrenzung trotzdem mal vorschlagen du lädst die verflossenen Updates und gibst die ebenso frei. Alle. Ich sehe auch das er laut Metadaten als Installationsvorrausetzung nur das Hauptprogramm verlangt, aber naja.....

Wie wurde das Hauptprogramm installiert? Eventuell liegt das Problem schon da . Die DC 2015 Classic gibts ja idiotischer Weise nur als exe. Wenn du es verteilt hast musst du die .msi extrahiert haben. Und hast du die dann noch angepasst? ( Ich hab das gemacht )
Sind da womöglich kritische Konfigurationen entstanden die zu Fehlern führen?
Greifen GPOs aus den Adobe templates auf die Installation die das Update steuern ?




Dann wäre noch interessant zu wissen welchen Status WPP anzeigt. Was sagt er über die Updates die sich immer wieder installieren? Stehen die auf erforderlich, fehlgeschlagen, installiert oder was ?
Oct 30, 2015 at 11:38 AM
I public 30096 today, from Adobe Catalog, and check it, ......in the moment, there are no problem (two W7 + W10 Clients ). WPP Status of 30096 is "installed". No manual manipualtion of rules nessasary.
interesting...

no. normal :-)
Das ist mir auch klar. Klappte bisher ja auch problemlos mit Reader 11 \ Win 8.1.
Hm. Ich würde zur Eingrenzung trotzdem mal vorschlagen du lädst die verflossenen Updates und gibst die ebenso frei. Alle. Ich sehe auch das er laut
Metadaten als Installationsvorrausetzung nur das Hauptprogramm verlangt, aber naja.....
Ich hatte dasselber Problem vorher schon mit Update 15.006.30060
Wie wurde das Hauptprogramm installiert? Eventuell liegt das Problem schon da . Die DC 2015 Classic gibts ja idiotischer Weise nur als exe. Wenn du es verteilt
hast musst du die .msi extrahiert haben. Und hast du die dann noch angepasst? ( Ich hab das gemacht )
Habe ich auch (Adobe Customization Wizard)
Greifen GPOs aus den Adobe templates auf die Installation die das Update steuern ?
Nein
Dann wäre noch interessant zu wissen welchen Status WPP anzeigt. Was sagt er über die Updates die sich immer wieder installieren? Stehen die auf erforderlich, fehlgeschlagen, installiert oder was ?
Weiss ich nicht mehr, kann ich erst nächste Woche prüfen.
Mit der manuellen Regel läuft es ja zumindest.
Oct 30, 2015 at 1:29 PM
Ich hatte dasselber Problem vorher schon mit Update 15.006.30060
Also von Anfang an. Hm.

Wenn du sie nicht aus dem Katalog holst, sondern downloadest und dann das Update manuell erstellst und publizierst funktioniert es auch nicht ohne den zusätzlichen Eintrag?

ja, schönes WE erst mal.
Nov 4, 2015 at 11:57 AM
Edited Nov 4, 2015 at 11:59 AM
Hallo zusammen,
erstmals möchte ich mich für die späte Rückmeldung entschuldigen. Urlaub und Krankheit kamen dazwischen.

GMBU wrote:
Meine Updates sind über den Katalog erstellt, womöglich ist das anderes wenn man sie manuell erstellt, oder "ersetzendes Update" verwendet.
Ich habe beides (Katalog und manuell) ausprobiert - beides Mal das selbe Ergebnis wie bisher. Ich habe bisher nie bei Reader XI mit "ersetzen Updates" gearbeitet.

GMBU wrote:
Welchen Status hat es denn im WPP auf dem Rechner für den es freigegeben wurde?
Der Status beim Update lautet "Unbekannt".

GMBU wrote:
Gib doch mal die alten Reader Updates wieder frei, schadet doch nicht, die müßten ja noch in der Verwaltung stehen, nimmt er die denn an ?
Gebe ich diese Pakete in der Testgruppe wieder frei, wird das Programm (Basis) installiert, aber auch keine Updates gefunden. Das hat aber auf jeden Fall schon einmal funktioniert!

GMBU wrote:
Pro forma weise ich auch immer gerne wieder darauf hin das man nicht auf verschiedene Wege installierte Adobe mischen und updaten sollte, und aufpassen das man nicht die MUI Versionen mit normalen zusammenwürfelt.......... aber das scheint hier ja nicht der Fall.
Schaden tut es nie... ich habe inzwischen auch alle Pakete vom Reader nochmals gelöscht und neu eingerichtet.

GMBU wrote:
Man kann davon ausgehen das die Freigaben der Updates für die entsprechende Computer(Verteilungs)gruppe alle richtig gesetzt sind und sich die Computer auch darin befinden.......?
Habe ich schon mehrmals geprüft. Gebe ich z.B. 7Zip auf die Testgruppe frei, wird diese auch auf dem Testclient gefunden.

triton53 wrote:
Another thing, can you take the MSP file itself and install it on a computer? If so, the MSP is valid.
I can install the msp file manually on the test Client without any Problems.

molkanisonal wrote:
i had to create the following rule (section: <msiar:MsiPatchInstalled/> ):
<msiar:MsiPatchInstalledForProduct PatchCode="{ac76ba86-7ad7-ffff-2550-ae0f06759000}" ProductCode="{ac76ba86-7ad7-ffff-7b44-ae0f06755100}"/>
I configure the rule on the msp package. But it don't help me.

:::::::::::::::::::::::::::::::::::::::
Kann ich eigentlich ohne Problem auf eine ältere Version zurückgehen?


Grüße,
Daniel
Nov 4, 2015 at 1:30 PM
Ok, jetzt wirs unübersichtlich, mehrere Leute mit ähnlichem Problem hier :-) , ein paar Ideen hab ich noch:

Bist du eigentlich immer noch auf dem Continous Track ? Deinen Versionsnummer aus dem ersten Posting nach war das so. Wie ich bereits erwähnte ist das nicht so die beste Idee.
Meine Vermutung ist das dein Problem genau da liegen könnte:

http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/whatsnewdc.html#reader-dc-tracks

Da steht sinngemäß ( unter anderem ) auch drin das NUR der Classic Track es ermöglicht Updates wie bei der XI durchzuführen und zu managen.
"Want to manage updates like previous 10-11.x releases."

Das der Eintrag von Molkanisol da auch nichts bringt wäre auch verständlich, denn der ist wohl auf dem Classic Track, und hat daher andere Nummern.
Lösung wäre (hoffentlich) auf den Classic Track zu wechseln, und es mit der neuen Classic Grundinstallation und den Updates aus der Linie zu versuchen.

Das der Eintrag von Molkanisol da auch nichts bringt wäre auch verständlich, denn der ist wohl auf dem Classic Track, und hat daher andere IDs.

Ich weiß es nervt aber du bist sicher das alles zusammenpasst, das du immer im richtigen Track ( Continuous / Classic) bist ? Basisinstallation, die manuell heruntergeladenen und die über den Katalog, denn es gibt da ja verschiedene Kataloge für..
http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/sccm.html
Auf der anderen Seite sagst du das die Updates in der XI Version auch nicht mehr funktionieren, was darauf hindeutet das das Problem tatsächlich wo ganz anders liegt.

zurück? beim WPP?
Da das Update bei WPP normalerweise nur durch drüberkopieren erfolgt - im Prinzip ja :-)

Du hattest mal ein Serverproblem erwähnt. Mit dem Zertifikat ist aber alles in Ordnung?

Das der Status "unbekannt" ist....... hm......das ist er ja normalerweise nur wenn sich der Client noch nicht wieder am WSUS gemeldet hat seit das Update erstellt wurde. Hm ...Was könnte noch zu Status "Unbekannt" führen? Das die Prüfung aus irgendeinem Grund nicht möglich ist ( ich spekuliere nur )
Aber ich denke genau das ist der Ansatz, wieso ist der Status "unbekannt".

Funktioniert eigentlich die Verteilung und Updates vom FLASH ( falls ihr das auch verteilt )
Nov 6, 2015 at 2:59 PM
GMBU wrote:
Bist du eigentlich immer noch auf dem Continous Track ? Deinen Versionsnummer aus dem ersten Posting nach war das so. Wie ich bereits erwähnte ist das nicht so die beste Idee.
Nein. Ich bin inzwischen auf Classic umgestiegen.

GMBU wrote:
Ich weiß es nervt aber du bist sicher das alles zusammenpasst, das du immer im richtigen Track ( Continuous / Classic) bist ? Basisinstallation, die manuell heruntergeladenen und die über den Katalog, denn es gibt da ja verschiedene Kataloge für..
http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/sccm.html
Ich habe über WPP bzw. Windows Update die Vollinstallation (AcroRdr20151500630033_MUI.exe) auf dem Testclient installieren lassen. Danach habe ich das Update (AcroRdr2015Upd1500630096_MUI.msp) manuell problemlos installieren können. Daher gehe ich davon aus, dass Vollversion und Update in der richtigen Version vorliegen. Nach dem Update steht auch unter Programme und Features bei Version 15.006.30096.
GMBU wrote:
Auf der anderen Seite sagst du das die Updates in der XI Version auch nicht mehr funktionieren, was darauf hindeutet das das Problem tatsächlich wo ganz anders liegt.
Inzwischen funktioniert die XI-Version wieder. Ich habe zuerst ein Downgrade die Version 1.3.1504.15 durchgeführt. Dort die beiden Pakete für die Testgruppe genehmigt. Danach wurden auf dem Windows 7 Testclient nacheinander beide Pakete gefunden und problemlos installiert. Beide Pakete wieder für die Testgruppe auf "Nicht genehmigt" gesetzt und WPP wieder auf die neuste Version aktualisiert.

GMBU wrote:
Du hattest mal ein Serverproblem erwähnt. Mit dem Zertifikat ist aber alles in Ordnung?
Jup. Andere Updates im WPP werden problemlos verteilt.

GMBU wrote:
Das der Status "unbekannt" ist....... hm......das ist er ja normalerweise nur wenn sich der Client noch nicht wieder am WSUS gemeldet hat seit das Update erstellt wurde. Hm ...Was könnte noch zu Status "Unbekannt" führen? Das die Prüfung aus irgendeinem Grund nicht möglich ist ( ich spekuliere nur )
Ich habe folgendes gemacht:
Beide Pakete (Vollversion und Update) genehmigt. Über Windows Update die Vollversion installiert. Danach steht bei Status im WPP Installiert. Danach nochmals nach Updates gesucht und natürlich keines gefunden. In der Spalte Status im WPP steht dort "nicht verfügbar". Sowohl mit WPP Version 1.3.1504.15 als auch 1.3.1508.8 getestet.

GMBU wrote:
Funktioniert eigentlich die Verteilung und Updates vom FLASH ( falls ihr das auch verteilt )
Ja
Nov 10, 2015 at 5:49 AM
Edited Nov 10, 2015 at 5:50 AM
Ich hatte (bzw. habe) das gleiche Problem mit der aktuellen Version von WPP, nach Downgrade auf die Version von April funktioniert alles wie es soll. Also das ist definitiv ein Problem mit der aktuellen WPP-Version... Das Problem trat sowohl bei selbst erstellten Updates als auch bei Katalog-Updates auf.

Hatte das Problem im mcseboard gepostet: http://www.mcseboard.de/topic/205065-wpp-adobe-reader-11-update-13-wird-immer-wieder-als-benötigt-angezeigt/
Nov 10, 2015 at 6:50 AM
Edited Nov 10, 2015 at 7:33 AM
Ok, ich versuch mal zusammenzufassen.

XI läuft. erledigt.

Reader DC Classic 15.006.30033 , nicht zu verwechseln mit 15.007.20033, installiert ordnungsgemäß das Hauptprogramm, via WPP/WSUS/WUpdate . Dieses wurde aus der .exe extrahiert und per ACW angepasst, im WPP entsprechend die .msi sowie die transformierte .mst zur Updateerstellung eingebunden.

Hier ist die Downloadquelle, mit ausführlichen Hinweisen zur Aktivierung von Installations Logs, womöglich helfen die ja auch beim Reader und den Update mit Infos weiter.
http://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotes/DC/dcclassic15.006.html
ftp://ftp.adobe.com/pub/adobe/reader/win/Acrobat2015/

Es gibt übrigens auch INCREMENTALE Updates, für alle wo Bestandinstallationen mit geringer Netzwerklast geupdatet werden sollen. ( Cool...) Die sind aber nicht über den Katalog verfügbar soviel ich weiß.


Freigegeben für Testgruppe, Testgruppe installiert über WSUS Update den vorkonfigurierten Reader.

Alles gut.

Update ....96 aus Katalog automatisch erstellen lassen.
Freigeben für Testgruppe.
Clientstatus neu ermitteln lassen.
Status wechselt von "unbekannt" auf " nicht verfügbar" ( Problem )

hm. Ich habe mal bei mir nachgesehen. "Nicht verfügbar" habe ich zB stehen wenn es sich zB noch um einen XP Client handelt. Macht Sinn.
Du hast keine manuellen Regeln gesetzt deren Auswertung zu einem "nicht Verfügbar" führen könnten?
Zwischenzeitlich eigentlich vorsichtshalber mal die Software Distribution gelöscht?
Möglicherweise Reste alter Installationen in der Registry? Man könnte vermuten das die Basisinstallation nicht ordnungsgemäß in der Reg eingetragen ist, und das Update deswegen der Meinung ist es hat dort nichts verloren. GGf Reiniger drüberlaufen lassen.

Also ansonsten gehen mir da jetzt langsam die Ideen aus.....

Das es am WPP direkt liegt wiederspricht etwas der Punkt das es bei mir zB nicht passiert. Habt ihr nochmal die Metadaten verglichen dich ich oben gepostet habe?
Wenn das Update auf nicht verfügbar steht, und es an einem Regelabgleich liegt müsste man es da ja sehen.
Ihr rollt auf die üblichen Systeme aus? W 7 Prof 32/64 bit bis W10 Prof 32/64bit ?

Irgendwas war noch letztens mit Katalog und Updates in der letzten Version...hm... versuch das mal zu finden.
Wenn nicht müsst ihr das doch mal als Bug melden, der Programmierer ist normalerweise dran an Problemen.
Ah ja. Ich hatte damals gemeldet das unter bestimmten Bedingungen WPP abstürzt beim Zugriff auf den Katalog, das war ein wesentlicher Grund für das letzte Update was euch jetzt Ärger macht. Sorry Jungs :-)

Ich kann anbieten das bei mir erzeugte Update, was bei mir ja läuft, direkt zu Testzwecken zur Verfügung zu stellen. Kann man ja im WPP importieren. Müßtet ihr nur neu zertifizieren denk ich.
I
Nov 10, 2015 at 11:50 AM
Moin, Moin,
also wir haben nochmals mit dem 6-Augen-Prinzip alles durchgearbeitet. Mit der letzten Version aus dem April 2015 getestet und nun funktioniert es wie gewohnt.
Wichtig ist, dass man vor dem Downgrade die betroffenen Adobe Reader Pakete ablehnt, aus WPP und dem Dateibaum löscht. Sonst haut es wohl nicht hin.

Vielen Dank an alle für die Unterstützung!
Nov 10, 2015 at 11:56 AM
Nachtrag:

Ich hatte heute ebenfalls einen Problemfall.
W7 Rechner neu aufgesetzt und Upgrade auf W10 gemacht, Adobe installiert den Reader und das 96er Update. Und dann immer wieder. Es wird nicht erkannt das das Update erfolgreich installiert wurde.
Alles versucht, Softwareverteilung gelöscht, aden Adobe Cleaner drüberlaufen lassen, immer das Gleiche. Nachdem ich dann mal wieder alles entfernt hatte, habe ich:
Basisinstallation freigegeben - alles gut.
60er Update freigegebem - alles gut, wird 1x installiert
94er Update freigegeben - alles gut. wird 1x installiert
96er Update freigegeben - wird erfolgreich installiert, installiert sich aber immer wieder und wieder und wieder.......

Also irgendwas ist mit dem Update auch faul. Vermutlich liegt es am Zusammenspiel des WPP und des Updates :-)
Ich durchforste mal die msi Metadaten, ob die strukturell anders sind als bei den bisherigen Updates.
Editor
Nov 11, 2015 at 5:01 AM
badwurzach wrote:
also wir haben nochmals mit dem 6-Augen-Prinzip alles durchgearbeitet. Mit der letzten Version aus dem April 2015 getestet und nun funktioniert es wie gewohnt.
Wichtig ist, dass man vor dem Downgrade die betroffenen Adobe Reader Pakete ablehnt, aus WPP und dem Dateibaum löscht. Sonst haut es wohl nicht hin.
Mit welcher Version genau funktioniert es denn jetzt? Im April gab es zwei Builds. Ich versuch dann mal den Entwickler zu kontaktieren und ihm das Problem schildern.
Nov 11, 2015 at 6:35 AM
Ich dachte mit "letzter Version" wäre es deutlich. ;-)
Es ist Version 1.3.1504.15.
Nov 11, 2015 at 6:44 AM
Bei mir funktioniert auch die 1.3.1504.15
Nov 11, 2015 at 7:38 AM
Ich konnte mein Problem der sich immer wiederholenden Updates ( gleichen Fall hatte jemand vor ein paar Tagen in einem parallelen Thread gepostet ) gestern noch lösen. Habe das Update gelöscht und komplett neu aus dem Katalog geladen, dann gings. Wohlgemerkt war das bisherige aber auch schon seit Tagen erfolgreich in Betrieb. Keine logische Erklärung.
Es gibt von Adobe das "Adobe CC Cleaner Tool" , das sollte man in solchen Fällen sicherheitshalber auch immer griffbereit haben. Insbesondere wenn es nicht läuft wie es sollte :-)

Mit den sich NICHT instalierenden Updates bin ich nicht weiter gekommen. Habe mal die im WPP angezeigten .msi Metadaten der drei bisherigen Updates verglichen, als da gibt es ein paar strukturelle Unterschiede , Stichwort <Obsolated Patch> , aber mir fehlt da das Wissen um zu sehen was da welche Bedeutung hat.

Tja, bei mir funktioniert die Release v1.3.1508.08 . Vor den April Release hatte ich WPP Abstürze bei Verwendung des Adobe Katalog.

Von Bedeutung ist Möglicherweise das das Handling von .msi Regeln mit den April Releases geändert wurde !
" Now automatic Rules based on MSI Product code are not generated anymore. Instead, WPP use MetaData integrated by the Publisher. In the "Package Level", you will found a rule like "<msiar:MsiPatchInstalled/>" and "<msiar:MsiPatchInstallable/>"

Diese Einträge finde ich bei mir NICHT wenn ich ein Reader Update aus dem Katalog erstelle ( aber es funktioniert ), von anderen wurde die Einträge jeodch gesichtet. Das es an den "WPP integrated MetaData" würde für mich Sinn machen.
Coordinator
Nov 15, 2015 at 4:22 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.