Probleme mit Office Deployment Tool? Readiness Toolkit für Office VBA AddIns abgekündigt

[English]Ich packe mal zwei Themen rund um Microsoft Office in diesen Blog-Beitrag. Ein Leser fragte mich, ob Probleme mit dem Office Deployment Tool bekannt sind – in seiner Umgebung gibt es plötzlich Abstürze. Zudem schickt Microsoft wohl das Readiness Toolkit für Office VBA AddIns auf das Altenteil.


Anzeige

Probleme mit Office Deployment Tool?

Das Office Deployment Tool (ODT) ist ein Befehlszeilentool, mit dem Administratoren Microsoft 365 Apps herunterladen und auf Ihren Clients bereitstellen können. Das Office-Bereitstellungstool bietet mehr Kontrolle über eine Office-Installation: Administratoren können definieren, welche Produkte und Sprachen installiert werden, wie diese Produkte aktualisiert werden sollen und ob den Benutzern der Installationsvorgang angezeigt werden soll.

Blog-Leser Christian hat mich zum 10. Januar 2024 per Mail kontaktiert, weil er plötzlich vor Problemen steht, die viele seiner Kunden in Bezug auf das Office Deployment Tool tangieren. Dazu schrieb er mir:

Hallo Günter,

da das Internet noch nichts hergibt, aber viele unserer Kunden betroffen sind:

Kam dir schon etwas zu Ohren, ob es mit dem Office Patchday von gestern Probleme an den Clients gibt?

Das "gestern" bezieht sich dabei auf den 9. Januar 2024, an dem Microsoft diverse Updates für Windows ausgerollt hat (für Microsoft Office war meines Wissens aber nichts dabei). Laut Christian gibt es aber seit dem Patchday das Problem, dass Office beim Klick auf Datei abstürzt und das Drucken aus der GUI nicht mehr funktioniert (über STRG+P) allerdings schon.

Versucht ein Administrator dann über die setup.exe aus dem Office Deployment Tool die Office Installation manuell zu aktualisieren, bleibt die setup.exe endlos hängen und schließt sich nicht mehr. Die Frage, die sich stellt, "hat jemand aus der Leserschaft dieses Problem auch schon festgestellt, und ist ggf. eine Ursache bzw. Abhilfe bekannt"?

Ergänzung: Der Blog-Leser hat sich nach Veröffentlichung des Blog-Beitrag nochmals per Mail gemeldet und schrieb folgendes:

Die Ursache konnten wir mittlerweile auf die setup.exe in der aktuellsten Version des Office Deployment Tools zurückführen: Beim Aufruf der setup.exe per Script schließt sich der Prozess nicht mehr.

Das hat in unseren Umgebungen zu massiven Problemen geführt, da wir Office Updates per Script durchführen.

Wir nutzen derzeit eine setup.exe aus einem alten Office Deployment Tool-Paket.

Damit dürfte das Thema vom Tisch sein.

Readiness Toolkit für Office VBA AddIns abgekündigt

Das Readiness Toolkit für Office VBA AddIns ermöglicht Entwicklern VBA-Addins für Office auf ihre Funktionsfähigkeit unter allen Office-Versionen zu überprüfen. Martin Geuß wies bereits zum 10. Januar 2024 in diesem Artikel darauf hin, dass Microsoft dieses Toolkit abgekündigt habe. Im Support-Beitrag Office Readiness Toolkit retirement heißt es, dass das im Jahr 2017 eingeführte Toolkit nicht mehr erforderlich sei. Dann seit dessen Einführung habe sich die Interoperabilität von Makros und Add-Ins zwischen unterstützten Office-Versionen, wie Office 2016, und Microsoft 365 Apps deutlich verbessert. Vor allem gibt es laut Microsoft keine störenden Änderungen im VBA-Objektmodell zwischen Office 2016 und Microsoft 365 Apps.

Daher plant Microsoft, das Toolkit am 31. März 2024 außer Betrieb zu nehmen. Ab diesem Zeitpunkt wird das Toolkit nicht mehr weiter entwickelt und es gibt keine Fixes und Sicherheitsupdates mehr. Details lassen sich dem verlinkten Artikel entnehmen.


Anzeige


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Office abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

13 Antworten zu Probleme mit Office Deployment Tool? Readiness Toolkit für Office VBA AddIns abgekündigt

  1. Marcel sagt:

    Wir hatten gestern den Fall das sich Software nicht installieren lassen hat. Mit schon länger bereits gedownloadeten Quellen.

    Installation ist immer mit Fehler 30204-44 abgebrochen.

  2. Thomas sagt:

    Ich habe gestern auch sehr viel Zeit mit dem Problem verbracht, dass Marcel hat. Ließ sich nicht verteilen (CurrentChannel) zum Test. Ich schaue gleich mal ob es heute anders ist und ob es die selbe Fehlermeldung ist.

  3. Martin Uebersax sagt:

    Hallo zusammen

    Welche Version vom ODT nutzt ihr? Liegt es somit am ODT oder an den Office Updates?

    https://learn.microsoft.com/en-us/officeupdates/odt-release-history

  4. ReFe sagt:

    Wir hatten bei Office 2019 nach dem Patchday komische Effekte in Word mit Bildern.
    Ein Bild wurde reproduzierbar beim Speichern verzerrt.
    Ein Bild wurde reproduzierbar beim kopieren innerhalb eines Dokumentes um 180° verkehrt eingefügt.
    Hoffentlich bleiben dies Einzelfälle oder werden bald von Microsoft korrigiert.

  5. Dennis sagt:

    Moin ihr Lieben,

    gute Gelegenheit nach Schwarmwissen zu fragen.
    Wir befinden uns mit unserem Firmennetzwerk in einem geschützen Bereich, wo die Clients keine Möglichkeit haben Office Updates direkt aus dem Internet zu ziehen.

    Bisher nutzen wir noch Office 2016 (via WSUS kein Problem).
    Wie macht ihr das aber bei 2019 aufwärts?

    Lasst ihr echt nen System regelmäßig per geplanten Task die Setup Sources neu von MS laden, in NwShare ablegen und per geplanten Task bei den Clients die setup.exe /configure nwsharepath laufen!?

    Bin für jeden on-prem Hinweis dankbar! :D

    • Khappa sagt:

      Das ist die beste Möglichkeit wenn du die Kontrolle darüber behalten willst. Wir handeln das so:
      Nach Update-Release auf einem Laborsystem pro Edition die Updates installieren & schauen was MS angestellt hat- > wenn nachher immer noch alles sauber läuft die betreffenden Dateien pro Version ( also z. B. hier Beispiel für Office LTSC 2021: v64.cab, v64_16.0.XXXXXX.cab & den kompletten Datenordner 16.0.XXXXXXX) auf dein NW Share kopieren.
      Vorsicht: Ab DIESEM Moment ziehen deine Clients die Updates im Zyklus, welcher in der Aufgabenplanung bei den Clients angegeben ist. Man kann dies natürlich auch manuell forcen, dann werden alle Updates sofort deployed -> wir haben uns für die Force-Variante entschieden.
      Wichtig wäre noch, dass bei deinen Clients diese beiden RegistryKeys richtig auf deinen (absoluten) Pfad des NW Share zeigen:

      Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate -> „UpdatePath"

      Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration -> „UpdateChannel"

      Also \\deinServer\HierLiegenMeineDateien

      Geht analog auch mit Office 2019, dann brauchst du ( bei Paralellbetrieb) eben 2 NWShares.

      Hoffe das hilft dir weiter

      • Glückskeks sagt:

        In dem Schritt bitte beachten das es für Office die 32Bit und 64Bit Variante gibt. Je nachdem wie man installiert hat wird im Default die 64Bit Variante installiert. Wenn man aus irgendeinem Grund die 32Bit Variante gebraucht hat muss im Downloadverzeichnis also für die 32Bit und für 64Bit Version ein Download erfolgen.

        Was aber ein Rückschritt im Vergleich mit dem WSUS ist:
        Beim WSUS konnte man relativ einfach prüfen ob der Patch auf die Clients ausgerollt wurde, spätestens wenn man direkt in der WSUS Datenbank die einzelnen Rechner geprüft hat.

        Mit dem neuen Updateverfahren muss man hoffen das es geht.
        Der neue Build steht nur in der Registry. Ohne Drittsoftware ist also nicht nachvollziehbar ob der neue Build überall ausgerollt wurde.

        Falls also jemand eine Lösung für diese Aufgabe ohne Drittsoftware hat, immer her damit :-)

        Remote Registry überall aktiveren um den Key auszulesen muss jetzt nicht unbedingt sein. Das ist ja absichtlich aus Sicherheitsgründen aus.

        • ReFe sagt:

          Ich schreibe im Startup Script die Dateiversion von Winword, Excel, Powerpoint, … in einen Log Ordner.
          Darin kann ich mit einfachen Scripts auswerten ob auf allen Client die aktuelle Version vorhanden ist.
          Es kommt schon mal vor, das ein Client auf einer alten Version fest hängt.

        • Knusper sagt:

          " Wenn man aus irgendeinem Grund die 32Bit Variante gebraucht hat…"
          Der Grung ist simpel. Sobald man eine 32Bit VBA Anwendung hat, müsste man diese auf 64Bit umschreiben. Das ist je nach Umfang recht viel Arbeit. Eigentlich nur Kleinkram, aber meist unnötig. Denn wer braucht schon z.B. ein Doppel-Long.

    • Foego sagt:

      So mache ich es zumindest.
      Ist ganz gut erklärt unter
      https://learn.microsoft.com/de-de/deployoffice/office2019/update

      GPO Einstellung:
      https://gpsearch.azurewebsites.net/#12197

      PS: Gelegentlich die Versionsordner bereinigen ;)

    • Anonymous sagt:

      Office 2016 CR2, 2019, 2021 und 365 Updates lassen sich per WSUS verteilen aber nur wenn dieser zusammen mit SCCM genutzt wird.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.