Guten Morgen Zusammen,
Die Download.cmd. die im Paket durch den Office Packager erstellt wird ist ja super.
Aber wir kämpfen momentanmit dem Update der Office Versionen.
Könnte ich die Download.cmd ausführen und anschließend die Revision des Paketes erhöhen um so meine Installationen Upzudaten?
Bei uns läuft leider die noop.exe des PM nicht wirklich 
Office 2024 LTSC und Patchmanagement - User Forum
Ergänzende Frage:
Ich habe mehrere XML Dateien für unterschiedliche Konfigurationen somit auch unterschiedliche Pakete: Office Std. Office Pro. Visio etc.
Nun ist mir aufgefallen, dass wenn ich auf meinem Rechner Visio installiere, mein Office sozusagen ein Downgrade macht auf die Version von Visio.
Handle ich das falsch?
Muss man nur einmal das Office Downloaden und kann dann mehrere Pakete auf die gleiche Paketquelle machen oder wie ist das optimal gedacht?
Vielen Dank
Hallo @rolandBB ,
anbei ein Link zu einer Beschreibung:
neo42 Office Packager - Handbuch
Eventuell kann dieses die Frage mit den Updates beantworten.
Mit freundlichem Gruß
Holger Sundermann
Hallo Herr Sundermann,
jain.
Wir haben es ja so gemacht.
Office getrennt von Zusatzprodukten
Update CDN
Somit habe ich jetzt 3 Pakete mit der Update Quelle CDN:
Office Standard Stand X
Office Pro Stand X
Visio Stand X
Führe ich nun ein Update von Hand durch, von Office Standard, erhalte ich dort die aktuelle Version.
Weise ich nun das Paket Visio dem Rechner zu der bereits ein Office installiert hatte und ein Update auf Stand Z erhalten hatte, wird auch das Office auf die Version Stand X aus dem Paket zurück gesetzt.
Daher die Frage ob ich eigentlich nur ein Download benötige und anhand der XML einfach mehrere Pakete erstelle, die aber auf die gleichen Daten zugreift?
Wie gesagt unser Patchmanagement läuft ja aktuell nicht mit der noop.exe warum auch immer.
Somit stellt sich mir die Frage wie ich mit den Updates verfahre?
Führe ich für jedes Paket die Download.cmd aus und tausche somit die Qellen aus und erhöhe pro Produkt die Revision?
Wie gehe ich hier am besten vor um diese Office 365 zeugs korrekt zu aktualisieren?
Hallo rolandBB:
Das Problem hatten wir auch und ich habe es über eine angepasste Download.cmd gelöst, die per Scheduled task ausgeführt wird.
in der wird ein Powershell-Skript ausgeführt dass je nach übergebenem Wert dann den Hash neu schreibt und ein eigenes Script dass die Revision erhöht.
Ich kann Dir die gerne zukommen lassen (bitte PN) bzw. hier veröffentlichen wenn das gewünscht wird.
Das mit der Noop.exe haben wir auch 
Ich versuche entweder in Empirum den Patch zu finden und sofort zu sperren aber mittelfristig steigen wir auf WSUS um; da tritt dieses Problem nicht auf.
i AReinel,
vielen Dank für deine Antwort.
Verstehe ich also richtig:
Du hast die Download.cmd pro Pordukt angepasst, die dir die aktuelle Software herunterlädt und dann die Revision in Empirum erhöht. Sprich du verteilst das komplette Paket immer neu?
Ich frage daher weil wir z.B. 4 Office Pakete haben:
Office Standard KMS
Office Standard MAK ( Geräte die keine Domänmitglieder sind )
Office Pro KMS
Office Pro MAK
dann kommen ja noch VISIO etc. als Pakete hinzu.
Alles brav unterschiedliche XML Dateien die über den Office Packager zu einem Paket gemacht wurden.
Somit muss ich ja bei jeder Software die Download.cmd anpassen und entsprechend verteilen.
das ist ja schon enorm, da die Pakete ja nicht gerade kleiner geworden sind :-(.
Oder gibt es eine Möglichkeit nur eine Datenquelle zu haben, auf die dann die unterschiedlichen XML Dateien zugreifen? Sprich habe nur eine Download.cmd etc. Oder brauche ich zwingend die mehrfache Datenhaltung. Das habe ich noch nicht ganz verstanden.
Zur Noop.exe, also habt ihr aktuell keine Möglichkeit dies über Matrix PM3 zu aktualisieren gefunden?
Danke Vorab.
PN ist raus 
Hallo rolandBB,
ja, im Prinzip ist das so richtig. Wir setzen aktuell M365 Apps for Enterprise ein, da ist die Lage etwas einfacher (kommt unten ).
Ich paketiere über die neo42 Tools mit einer configuration.xml das Office. Dann importiere ich es in Empirum und gebe den Ordner unter "…\Empirum\Configurator\Packages\Microsoft\Office365 EEA (no Teams) x64\16.0\neoSource" zusätzlich frei (z.B. als Office365ProPlusx64$). Diesen Pfad gebe ich in der configuration.xml bei der Installation mit.
das sorgt dafür dass die Rechner bei der Installation immer die aktuellste Version aus dem Packages-Ordner bekommen und die Rechner, die im Einsatz sind diesen als Update-Pfad (an Stelle des Microsoft CDN) nutzen.
Das erfolgt nicht über eine Reinstallation (mit Revisions-Erhöhung) sondern direkt von den Clients sobald eine Office-App (Word, Excel, Powerpoint, usw.) gestartet wird. Dann überprüft das Office auf dem Client ob im Updatepfad (hier \EmpirumServer\Office365ProPlusx64$) eine neue Version vorhanden ist und „slipstreamt“ diese dann in die lokale Installation. Bei Bedarf wird der Anwender gebeten die Office-App zu schließen sonst macht Microsoft das nach 20 Minuten für ihn :-).
Um im Update-/Installations-Ordner immer die neueste Version zu haben nutze ich eine erweiterte Download.cmd die die alte Version sichert (damit wir bei Problemen schnell zurück können), die neue Version herunterlädt und im Ordner "…\Empirum\Configurator\Packages\Microsoft\Office365 EEA (no Teams) x64\16.0\neoSource" bereitstellt und danach die Hashes und die Revision aktualisiert.
Das klappt nur bei M365 stabil weil hier alle Office-Produkte in der „DVD“ enthalten sind; es genügt also ein Updatepfad für die 64-bit und ein Update-Pfad für die 32-bit-Verison.
Bei Office 2019/2021/2024 bin ich mir noch nicht sicher, hier teste ich noch. Ich fürchte hier ist immer nur das einzelne Produkt (also Office Standard 64-bit) in den heruntergeladenen Dateien enthalten, man bräuchte also einen getrennte Update-Pfad für jede Version die man einsetzt.
btw: wir nutzen auch GPOs um den Updatepfad flexibel steuern und ein Patch-System zu nutzen, aber das verkompliziert das alles noch weiter.
Nein, leider nicht. Das ist einer der Hauptgründe warum wir vom Matrix42 Patch-Management auf WSUS umsteigen.
Ich muss immer versuchen sofort nach Erscheinen des Patches den aus der Verteilung herauszunehmen da sonst immer das Patch-Management abbricht. Schade nur dass es jeden Monat eine neue KB-Nummer gibt 
.
Die Noop.exe scheint genau das zu machen (No-Operations) und dient wohl nur dazu die Anwender auf eine neu erschienene Office-Version hinzuweisen. Das ist kein echter Patch und führt dazu dass das Patch-Management abbricht solange der Client keine aktuelle Office-Version aufweist.
Wenn Du die Updatepfade wie oben beschrieben bei der Installation einrichtest und die Clients sich sofort (ohne vorgeschaltete Tests) die neue Version ziehen hast Du auch nur ein kleines Zeitfenster in dem das Patch-Management scheitert. Aber das ist bei uns keine Option.
nochmal kurz:
beim M365 scheint es so zu sein dass alle Office-Produkte im Download enthalten sind. Das bedeutet dass alle Office-Produkte (inkl. Visio und Project) sich aus dem gleichen Ordner aktualisieren können daher gibt es nur eine Freigabe für 64-bit und eine extra Freigabe für 32-bit. Diese Pfade werden dann in den Paketen in der configuration.xml mitgegeben.
Bei den Office 2019/2021/2024-Versionen scheint das anders zu sein da muss wohl für jedes Produkt eine eigene Freigabe eingerichtet und bei der Installation mitgegeben werden.
Ich freue mich über eine Korrektur oder Hinweise wie das anders zu lösen wäre. So scheint es eine Struktur zu geben die man in den Update-Pfaden einrichten könnte die dann alle Produkte in einem Pfad anbieten könnte aber da bin ich noch nicht weitergekommen.
Hi,
vielen Dank für deine wirklich ausführliche Lösung bzw Beschreibung.
Also was mir bei Office 2024 aufgefallen ist.
Ausgangssituation
2 Pakete am gleichen Tag erstellt
Office 2024 Pro KMS Build X
Visio 2024 Build X
Somit haben beide Pakete die gleichen Build in den Sources vom Empirumpaket.
Nun Office 2024 installiert. Build X
Dann von Hand nach Updates suchen lassen, geht, also Office aktualisiert sich auf Build Y
Nun Installiere ich über Empirum Visio 2024 Build X
Visio installiert mit Build X aber Word ( also Office ) ist jetzt nicht mehr Build Y sondern wieder Build X
Somit vermute ich hier irgendwo Gemeinsamkeiten, kann Sie aber noch nicht greifen.
Daher Frage ich ja mangels besserem Wissen ob ich nur eine NeoSource für die Verschiedenen Pakete brauche. Die Frage ist nur, woher weiß dann das Paket welche Inhalte er gerade jetzt installieren muss.
Hier stehe ich also noch auf einem Schlauch oder gar einer Pipeline sorry
Grüße
Nun habe ich Office Vision
Hi so mit der Unterstützung AReinel, habe ich jetzt mal eine aktualisierung vom Netzwerkshare machen können aber:
Wenn ich via Configuration.xml und dem Download.cmd eine bestimmte Version herunterlade, fehlt dort die Datei v64.cab unter Office\Data:
ich kann zwar am Ende dann von Hand die v64_Version.cab in v64.cab kopieren aber das würde ja den Automatismus aushebeln.
So sieht es aus wenn ich das Paket mit dem Office Packager erstelle:
Idee wo mein Fehler liegt oder mir ein Baustein fehlt?
Danke
Hallo @rolandBB - früher waren in der Download.cmd Pausen einkommentiert, ich weiß gerade nicht, ob das in der aktuellen Version so auch ist. Könntest du das mal überprüfen und die Pausen entfernen?
Hi,
soweit ich das sehe ist nur eine Pause am Ende.
Da ich ja die Download.cmd erstmal zum test von Hand ausführe stört diese ja erstmal nicht.
Aber er macht mir im prinzip nicht die v64.cab.
Danke
Hallo, @AReinel,
wird der WSUS nicht bald eingestellt? Meines Wissens nach erhalten die Office Versionen 2021 und 2024 gar keine Updates über den WSUS oder funktioniert das bei euch?
Gruß Silvio
Guten Morgen Silvio,
nach meinen Informationen ist es so dass beim MS Windows Server 2025 das letzte Mal die Rolle „WSUS“ enthalten ist (https://techcommunity.microsoft.com/blog/windows-itpro-blog/windows-server-update-services-wsus-deprecation/4250436).
Damit wird der noch 10. Oktober 2034 unterstützt (siehe Windows Server 2025 - Microsoft Lifecycle).
Bis dahin sollten wir eine neue Lösung haben
das ist richtig, Patches gibt es nur für MSI-Installationen und meines Wissens nach gibt es die für die neuen Office-Versionen nicht (mehr).
Daher nutzen wir die C2R-Methode (Click-to-Run) und laden mit einer angepassten Download-Batch immer die neueste Office-Version in unseren Installations-Share. Der wird bei der Installation (bzw. per GPO) als Update-Pfad mitgegeben und dann suchen sich die Clients von hier die neue Version und ziehen sich die im laufendem Betrieb. Das ist wohl die „normale“ Office-Update-Methode, nur dass die Updates nicht aus der Cloud sondern von einem lokalen Share kommen.
Hi, mal eine Frage an die Neo.
Ich habe jetzt mehrere Pakete mit dem Office Packager gemacht.
Office Std
Office Pro
Visio
nun habe ich ja auf dem FileSystem im Package 3 Vollständige Pakete liegen die unter Files „Office“ die Quelldaten in der jeweiligen Version vorhalten.
Jetzt habe ich einen Share für das Office Update, dies habe ich in meinem Rechner in der Registry hinterlegt ( da ich ja über GPO oder Reg nur einen Pfad auswählen kann):
Dort habe ich einmal den Inhalt des Office Pro hineinkopiert:
Anschließend habe ich Visio nach Updates suchen lassen. Der findet auch ein Update und lädt sich dieses herunter.
Das er es vom Share und nicht aus dem Netz holt sehe ich an der Version. Da 20222 und das ist die Version auf dem Share.
Nach dem von Visio Update gewünschten Programneustart ist Visio sowie auch Office Word auf der Version 20222 vom Share.
Für mich stellt sich daher die Frage warum der Office Packager jedes mal ein volles Paket erstellt mit allen Daten.
Wäre es nicht möglich wie beim PM Scan und FIX mit unterschiedlichen setup.inf oder PSADT Ordner zu arbeiten?
Dann hätte man entsprechend unterschiedliche setup.inf`s für die Einbindung in Empirum:
die dann auf unterschiedliche Configuration.xml verwaisen:
Das wäre dann der Vorteil, nur einmal die Datenbasis zu haben. Diese gebe ich als Share für alle Office Click2Run Versionen frei und halte diese über die Download.cmd aktuell.
Da ich über die GPO bzw in der Registry natürlich nur einen Pfad angeben kann von dem Updates geholt werden.
Oder habe ich hier einen Denkfehler?
Vielen Dank für die Rückmeldung.
Zur Info:
Das Thema von rolandBB wurde nun als Supportanfrage bei uns weiter bearbeitet. Derzeit ist der genannte Wunsch technisch nicht umsetzbar.
