Quantcast
Channel: Wsus Package Publisher
Viewing all 3825 articles
Browse latest View live

New Post: Package Publisher Update von 1.3.1411.9 auf 1.3.1508.08

$
0
0
Hi,

einfach nur in das bisher genutzte Verzeichnis entpacken. Irgendwelche Einstellungen werden nicht überschrieben.

New Post: Package Publisher Update von 1.3.1411.9 auf 1.3.1508.08

$
0
0
Guten Morgen,

danke für die schnelle Antwort! Konnte es wie beschrieben mit copy & paste (alles ersetzen) durchführen.

Danke!

New Post: Adobe Acrobat Reader DC - MSP don't work

$
0
0
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

New Post: Adobe Acrobat Reader DC - MSP don't work

$
0
0
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 )

New Post: [Solved] "Not applicable" issue

$
0
0
DCourtel wrote:
That's right. The bug affect only updates made from a MSP file, and that don't have any rules in the "Is Installable" tab.
Putting rules in the "Is installable" tab can help to work around the bug.
I think this bug is back in release v1.3.1508.08. No package level rules for the last reader msp update.
I tried to create the package with release V1.3.1504.15 and package level rules are presents with the same msp.

New Post: 32bit JRE 8u65 on 64bit Win7/8.1

$
0
0
First attempt at using WPP, and I'm using the PDF from the web site (Installing Java 7u21 without Java Auto Updater) as a guide.

WPP is installed on our Server 2012R2 (WSUS 6.3) server.

Attempting per subject line, because it works better with the ADP payroll app.

Publishing works, but seeing error codes on clients of 80131700 (mostly) and 6BA and one or two others.

I'm using jre-8u65-windows-i586.exe from http://java.com.

Have tried varying the product code from 32bit to 64bit, and also processor arch, with very poor results - it's only worked once or twice on my test machines, out of about 10 attempts.

I also tried the MSI file using a standard package insted of a custom package with even worse results.

I'll be happy to provide any settings/configurations required to help troubleshoot this, as I'm sure I'm missing something, but just can't figure it out.

Thanks,

Kurt

New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Hallo,

ich richte gerade ein, das Clients mit Java 8 Update 65 ausgestatte werden, wenn mindestens Java 8 installiert ist. Clients die kein Java besitzen oder Version 7 sollen ausgeschlossen sein.
Ich bin wie in der Anleitung http://www.wsus.de/uninstall2install vorgegangen. Lediglich mit den neuen MSI Produktcodes für Java 8 Update 65 und allen Java 8 Update-ProduktCodes.

Zusätzlich habe ich natürlich in den Regeln vorgegeben das der Registry-Schlüssel:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment\1.8
existiert.

In meiner Testumgebung mit einem Client auf dem Java 8 Update 60 installiert war wurde Java 8 Update 60 deinstalliert und Java 8 Update 65 installiert.
Ein weiterer Client ausgestattet mit Java 7 Update 75 und zusätzlich mit Java 8 Update 5, 11, 51 wurde mit Java 8 Update 65 installiert. Jedoch wurde nur Java 8 Update 51 deinstalliert. Java 7 Update 75 sollte auch drauf bleiben so weit so gut, warum jedoch wurden Java Update 5, 11 nicht deinstalliert?

Im Anwendungslog steht:
Uninstallaufruf efolgreich ausgeführt: 26A24AE4-039D-4CA4-87B4-2F83218005FF
was bedeuten würde Java 8 Update 5 wurde deinstalliert.

Danke für eure Hilfe.

New Post: 32bit JRE 8u65 on 64bit Win7/8.1

$
0
0
kurtbuff wrote:
First attempt at using WPP, and I'm using the PDF from the web site (Installing Java 7u21 without Java Auto Updater) as a guide.
Yes, its al little bit outdated, but the basics are the same.
WPP is installed on our Server 2012R2 (WSUS 6.3) server.

Attempting per subject line, because it works better with the ADP payroll app.
hm
Publishing works, but seeing error codes on clients of 80131700 (mostly) and 6BA and one or two others.


I'm using jre-8u65-windows-i586.exe from http://java.com.
correct.
Have tried varying the product code from 32bit to 64bit, and also processor arch, with very poor results - it's only worked once or twice on my test machines, out of about 10 attempts.
Dont make modifications. I have the same configuration ( Server + WSUS ) , and it is not nessasary to manipulate or creating rules if you use the extracted .msi
I also tried the MSI file using a standard package insted of a custom package with even worse results.
Ok. You get the the same result with the simpe .msi and the custom .msi + .mst . So, it is a more basis installation problem
What is happen if you start the msi manual on the client. Runs correct without interaction?
I'll be happy to provide any settings/configurations required to help troubleshoot this, as I'm sure I'm missing something, but just can't figure it out.

Thanks,
Yes....
ok, first... If you test your deployment, be sure that clients are clean, without old Java Installations and a clean registry. You dont want to have trouble with old offline / online and modificated installations from Java 7 - today.

Second. Deployment of .msi is recommended, and a little bit more comfortable like .exe deployment, and give you the possibillity to make configurations for your installation and deinstallation.

There is a tutorial and more information on my site based on JAVA 8 and LUP, but its the same in WPP. Im sorry, only in german, but your Name is Kurt, hmmm :-)
for .msi :
http://road-books.jimdo.com/2014/12/01/verteilung-von-java-8-umstieg-von-java-7-mit-local-update-publisher/
for .exe ( not recommended ):
http://road-books.jimdo.com/2014/12/03/exe-verteilung-von-java-8-mit-local-update-publisher/
Kurt
If I understand correctly, it works for 1-2 Clients, so it isnt a WPP problem or publishing problem.


80131700 is ERROR_INSTALL_FAILURE , so Installation start and failed. Why? Hm.

good luck,


New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Hi,

Du hast auch für alle Java Versionen, die deinstalliert werden sollen, den richtigen Deinstall-String angegeben? Nur das was in der REG-Datei angegeben ist, wird auch wirklich deinstalliert.

New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Hallo,

ja ich habe alle eingefügt, wie auch erwähnt werden die im Anwendungslog genannt, aber ausgeführt wurde nur die Deinstallation von Java 8 Update 51

Meine REG-Datei:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Uninstall2Install]
"Uninstallstring"="26A24AE4-039D-4CA4-87B4-2F83218000FF;26A24AE4-039D-4CA4-87B4-2F83218005FF;26A24AE4-039D-4CA4-87B4-2F83218011F0;26A24AE4-039D-4CA4-87B4-2F83218020F0;26A24AE4-039D-4CA4-87B4-2F83218025F0;26A24AE4-039D-4CA4-87B4-2F83218031F0;26A24AE4-039D-4CA4-87B4-2F83218040F0;26A24AE4-039D-4CA4-87B4-2F83218045F0;26A24AE4-039D-4CA4-87B4-2F83218051F0;26A24AE4-039D-4CA4-87B4-2F83218060F0"
"Installstring"="jre1.8.0_65.msi"

Könnte es evtl. sein das nur eine Deinstallation stattfindet? Da nur eine Deinstallation aktiv sein kann? Schließlich werden quasi alle "gleichzeitig" gestartet?

Danke!
MfG

New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Es wird für jeden String vor oder nach einem Semikolon ein msiexec /x{aasdlk} gestartet.

Msiexe.exe /X{Inhalt des Uninstallstring} /qn

Nimm den Client und führe den Befehl mit dem passenden Uninstallstring in einer administrativen Commandline aus, was passiert? Du hast das Fenster Software auch anschließend mit F5 aktualisiert bzw. neu gestartet? Bist Du auch wirklich sicher das sich diese Uninstallstrings noch in der Registry befinden?

Der Eintrag ins Log bedeutet nur das der Aufruf von Msiexe.exe /X{Inhalt des Uninstallstring} /qn ohne Fehler gelaufen ist, d.h. noch lange nicht das auch deinstalliert wurde.

New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Hallo,

ok, ich bin nun hingegangen und habe alle Java 8 Versionen von 0 - 60 auf den Client installiert :-)

Danach habe ich die Installation gestartet mit dem Ergebnis: Java 8 Update 65 ist installiert

Java 8
Java 8 Update 5 und
Java 8 Update 11 wurden nicht deinstalliert. Ergo habe ich mir nochmal genau die Registry Einträge angeschaut und siehe da:

Java 8 26A24AE4-039D-4CA4-87B4-2F83218000FF falsch, korrekt ist 26A24AE4-039D-4CA4-87B4-2F83218000F0
Java 8 Update 5 26A24AE4-039D-4CA4-87B4-2F83218005FF falsch, korrekt ist 26A24AE4-039D-4CA4-87B4-2F83218005F0
Java 8 Update 11 26A24AE4-039D-4CA4-87B4-2F83218011F0 falsch, korrekt ist 26A24AE4-039D-4CA4-87B4-2F83218011FF

Beim auslesen über den WPP des MSI von Java 8 steht aber im ProductCode FF am Ende?!
Wie kann das sein?

Ich werde abschließend mal das Update im WPP anpassen und testen ob dann Java 8 Upate 5 und 11 auch deinstalliert werden und kurze Rückmeldung geben.

Danke!

New Post: Deploying Firefox

New Post: [Solved] Deploying Firefox

New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen


New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Hallo,

nein wir verwenden die 32-bit Version. Diese habe ich auch für die Installation verwendet. Wir installieren kein 64-bit Java, da dann für die Applikationen der 64-bit IE benutzt werden müsste. Dies ist aber kein Standard bei uns.

Sprich wir verwenden ein Win 7 64-bit System mit 32-bit Java und mein Auslesen von Java 8 Update 5, sei es über ORCA oder über den MSI-Reader von WPP liest mir 100%-ig folgendes aus:

{26A24AE4-039D-4CA4-87B4-2F83218005FF} Java 8 Update 5 32-bit Version
{26A24AE4-039D-4CA4-87B4-2F86418005FF} Java 8 Update 5 64-bit Version

Ich habe nun sowohl die Java 8 Update 5 32-bit und 64-bit auf dem Client installiert und in der Registry werden mir nach der Suche nur Zweige angezeigt mit

{26A24AE4-039D-4CA4-87B4-2F86418005F0} ,
Es findet sich kein einziger Eintrag mit FF am Ende.

Das ich ausschließlich mit der 32-bit Version arbeite sieht man am letzten Abschnitt im Code. Hier ist dieser entweder 832 oder 864 in der Bezeichnung.
Wie in meinem ersten Post habe ich auch nur die 832 herangezogen.

Schade das ich keine Screenshots liefern kann.
Es verhält sich weiterhin so, dass meine verwendeten Java.MSI Dateien für Java 8, Java 8 Update 5 und 11 andere ProductCodes verwenden als letztendlich in der Registry vorhanden sind.

Ich hoffe wir sprechen nicht aneinander vorbei :-)

Wenn ich gleich noch zum Anpassen der Uninstall2Install.reg komme und das Update im WPP angepasst habe kann ich berichten ob die Deinstallation dann funktioniert. Falls ich heute nicht mehr dazu kommen sollte, dann vermutlich am Montag nächste Woche ;-)

MfG

New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Hmm, das ist schon sehr dubios.

Evtl. kannst Du nochmal ein MSI aus der EXE extrahieren, die EXE einmal per Doppelklick starten und jetzt in %APPDATA%... das MSI holen und im mit dem WPP den Code auslesen. Du vewendest die aktuellste Version vom WPP?

Created Unassigned: Windows 8.1 - Update stops at 99% [307]

$
0
0
Hello guys,

I just set up a new WSUS Server (2008R2 Datacenter) and now I am testing the WSUS Package Publisher. During first tests with Windows 7 Prof x64 clients there where nearly no problems. The only problem that occurred was while trying to use the package publisher for a windows 10 client (which isn't that astonishing as windows 10 isn't supported until now ;) ).
Then I tried to test the same on a windows 8.1 (x64) client. At first there were no updates found (got some error message). After a while (maybe the error occurred in terms of the wsus switching so the database had to be "rebuild"?) the client found the published packages (Chrome, Java, 7zip, Flash Player, Adobe Reader). It was possible to install Chrome but all other packages failed. If I now search for updates and restart to install them, the process is hanging up at 99% and doesn't do anything...

Is there anyone who had the same problem or has an idea to fix it?

What I tried until now:
1) Several reboots
2) Waiting 2 days
3) Deleting whole software Distribution folder / rebuilding Windows Update database

New Post: Java 8 Update 65 + Deinstallation alter Java 8 Versionen

$
0
0
Hallo,

es ist und bleibt dubios!

so wie Du es beschreibst geh ich doch die ganze Zeit vor. Ich starte die .exe gehe unter mein Userverzeichnis in %APPDATA%... nehme mir nur die .msi und lese diese aus.
Dabei wird mir dann am Ende FF angezeigt. In der Registry ist nach der Installation über die *.exe F0 vorhanden. Ich habe mir übrigens alle Java Versionen hier:
http://java.techygeekshome.info/downloads geladen.

Ich benutze die aktuellste Version von WPP siehe hier: https://wsuspackagepublisher.codeplex.com/discussions/646933

:-)

Am WPP liegt das ja auch nicht, es sind die ProductCodes die mir den Streich spielen. Es erscheint halt beim auslesen ein anderer als letzten Endes in der Registry existiert.
Für mich ist das Thema eigentlich auch beendet sobald ich meine Uninstall2Install.reg auf die "richtigen" ProductCodes angepasst habe und es in meiner Umgebung funktioniert.
Das eigentliche warum beim Auslesen der ProductCodes etwas anderes angezeigt wird bleibt somit weiterhin offen, aber das soll mir dann auch eigentlich egal sein.

Ich bin und werde aber vermutlich auch heute nicht mehr dazu kommen meine Konfiguration für den WPP (einschließlich die Uninstall2Install.reg) anzupassen und es zu testen.
Ich kann aber wenn Du möchtest Dir meine Erfahrung gerne noch einmal schreiben.

Danke! Ich wünsche schon jetzt ein schönes Wochenende!

New Post: Option "Supprimer le produit" grisée dans l'arborescence

$
0
0
Bonjour,

Je n'arrive pas à supprimer certaines entrées, actuellement vides, dans mon arborescence WPP.

L'option "Supprimer le produit" est grisée :

Image

Une idée ?

Merci
Viewing all 3825 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>