[English]Ein Blog-Leser hat auf fiese Fehler in der Release 2301 von Microsoft Word aus Office 365 bzw. Microsoft 365 hingewiesen. Schreibgeschützte Dateien lassen sich erst nach Abspeichern unter einem anderen Namen ändern. Und VBA-Addins können nicht mehr ausgeführt werden. Wäre interessant, ob andere Leser diese Fehler nachvollziehen können.
Blog-Leser Ingo W. hat mich gestern per E-Mail kontaktiert, weil er bzw. seine Kunden von den Bugs ziemlich genervt ist. Ingo ist wohl Entwickler von VBA-Addins und läuft in Probleme mit Microsoft 365. In einer Mail mit dem Titel Bug in Release 2301 Word 365 schrieb er:
Hallo Herr Born,
ich wende mich an Sie, da ich hoffe, dass Sie bessere Kontakte zu Microsoft haben oder eher Druck auf Microsoft ausüben können.
In der letzten Woche habe ich von zwei Kunden mit Microsoft 365, die eine Software von mir benutzen, Probleme gemeldet bekommen.
Mit dem „Druck aufbauen“ oder mit Kontakten ist das so eine Sache: Ich habe keine Kontakte zu Microsoft und bau mal Druck auf einen Gummiball auf – das klappt nicht. Ich verweise in diesem Zusammenhang auf meinen Nachtrag zu diesem Beitrag, wo ich Microsoft einen Link auf eine Bug-Beschreibung übermittelt habe. Die Antwort habe ich unter „bescheuert, dann eben nicht“ einsortiert.
Aber ich stelle die Bug-Beschreibung des Lesers mal hier im Blog ein, vielleicht haben weitere Leser das Problem und jemand macht ein Ticket bei Microsoft auf – denn dieses Microsoft 365 soll ja alternativlos sein, höre ich immer wieder.
Die Version 2301 (Build 16026.20146) von Microsoft 365 wurde im Current Channel zum 26. Januar 2023 veröffentlicht, wie ich hier gesehen habe. Zu Word gibt es aber in den Release Notes keine Hinweise.
Ändern schreibgeschützter Dateien
Der erste unschöne Effekt wird über schreibgeschützte Dateien berichtet. Die Natur einer schreibgeschützten Datei ist natürlich, dass man diese nicht ändern kann. Wenn ich es richtig mitbekommen habe, war es bisher aber so, dass man ein solches Dokument öffnen und korrigieren konnte. Erst beim Speichern verlangte Word dann einen anderen Namen für das Dokument. Dazu schreibt Ingo:
Zunächst ist es offensichtlich in der aktuellen Version so, dass bei schreibgeschützten Dateien keine Änderung mehr gemacht werden kann, bis man diese Dateien unter einem neuen Namen abgespeichert hat.
Dies nervt mich und meine Kunden, da wir bisher die Änderungen gemacht haben und dann entschieden haben, ob die geänderte Fassung überhaupt gespeichert werden soll.
Aber dies ist nur nervig: Wenn Microsoft das so lässt, kann man damit leben.
Gut, hier kann man nachvollziehen, dass Microsoft den Workflow ändert und postuliert, dass Änderungen am Word-Dokument nur möglich sind, wenn die Datei nicht schreibgeschützt ist. Ob das sinnvoll ist, steht auf einem anderen Blatt.
VBA Addins gesperrt
Ingo beschreibt aber noch einen anderen Effekt, der echte Probleme bringt, falls AddIns, die in VBA erstellt wurden, mit schreibgeschützten Dateien verwendet werden sollen. Dazu schrieb er:
Nun aber zu einem echten riesigen Problem:
Spätestens seit Release 2301 gibt es einen massiven Bug, der in VBA programmierte Addins verhindert.
Wenn per VBA neue Dateien mit schreibgeschützten Vorlagen erzeugt werden oder per VBA schreibgeschützte Dateien geöffnet werden oder per VBA Word-Dateien in andere Word-Dateien eingefügt werden, kommt es zum Abbruch.
z.B. bei Documents. Open Pfad & Dateiname
Bei einem meiner Kunden mit der Fehlermeldung: „Ein Problem wurde von Word festgestellt“, bei einem anderen Kunden mit ewiger Sanduhr ohne Fehlermeldung und bei mir mit der Fehlermeldung 5792 „Die Datei ist möglicherweise beschädigt“.
Der gleiche VBA-Befehl funktioniert einwandfrei, wenn die Datei nicht schreibgeschützt ist.
Ich kann dies mit einem kleinen Testdokument und einem Makro mit einer Zeile Code reproduzieren.
Ähnlich sieht es bei dem Befehl „Documents. Add Vorlage“ aus. Ist die Vorlage nicht schreibgeschützt, funktioniert alles wie gewohnt.
Ist die Vorlage schreibgeschützt, gibt es einen Fehler.
Noch wichtig: Dieser Effekt tritt nicht mit leeren, frisch erzeugten Dateien [auf]. Kopiert man allerdings Texte mit eigenen Formatvorlagen in diese Dokumente, kommt der Fehler.
Ingo hatte mir noch angeboten, eine Testdatei bereitzustellen, um das selbst zu testen. Macht aber keinen Sinn, da ich kein Microsoft 365 verwende und das auch nicht installiert habe (obwohl Microsoft mir den Test wie Sauerbier andienen will). Die Frage an die Leserschaft: Kann jemand dies nachvollziehen? Ist das erst ab Release 2301 so, oder trat es schon früher auf?
Weiß nicht, ob man das als Bugs bezeichnen sollte? Wie sagt Mark Heitbrink gerne, wenn man irgendetwas bei Microsoft nicht versteht: „Think Big“. Will sagen: Macht diese Änderung in irgendeiner weiße Sinn und ist damit für andere Nutzer/Kunden – große, sehr große Kunden – wichtig?
Da müsste man schon den Grund für diese Verhaltensänderung wissen – das wäre natürlich schon Aufgabe von Microsoft das zu erläutern.
Fehler-Kultur sieht anders aus. Der gesamte Trend macht mich nachdenklich.
Wenn ich wie Olli big thinke : Ist vielleicht gar nicht mehr gewünscht, dass KMU + Entwickler eigene Addons für MS-Produkte entwickeln und es weniger Zugriff auf Fehlermeldewege gibt? Alle Addons lizensiert und signiert als Abo in der Cloud wäre ja auch möglich *grusel*.
Spannend für einen excellenten Fachbuchautor finde ich auch etwas Anderes: Seit einiger Zeit fallen mir in Beiträgen von Hrn Born bei Microsoft immer häufiger Begriffe wie „unschön“, fies oder „Sauerbier“ auf. Ob in og Artikel Terminal Server, der
Produktbündelung, schon in 2016 oder meinem Favoriten-Begriff Murks.
Bei zweifelsohne langer + fundierter Kompetenz + Beurteilungsfähigkeit des Autors muss an der Wortwahl etwas Wahrheit sein…
Ich nehme mal nur zum „Sauerbier“ Stellung – zum Murks habe ich noch einiges in Petto. Wenn ich mich bei irgend einem Dienst bei Microsoft anmelde (z.B. im Microsoft Answers Forumm, gerade beim Schreiben noch getestet), wird mir seit Monaten permanent im Kopf der Webseite ein Banner „ich möge doch bitte Microsoft 365 testen“ vor den Latz geklatscht.
Ein Banner für x einen Tag oder 3 mal gesehen, nicht angenommen, und gut ist, wäre ja ok. Aber so? Egal, ob ich das Banner schließe, es kommt immer wieder – Cookies lasse ich grundsätzlich zu (alleine wegen der An- und Abmeldung bei MS-Diensten) – daran liegt es also nicht. Ich hatte vor unendlichen Zeiten sogar mal einen Test-Account für Office 365, habe es aber auslaufen lassen, da uninteressant bis nervig.
Trotzdem kommt das Zeugs als Banner immer wieder – genau mein Humor – und das ist für mich „anpreisen wie Sauberbier„.
Komisch, bei mir fehlt es seit kurzem … Bisher dachte ich immer, dass es am fehlenden Download der Installationsroutine über mein Microsoftkonto.
„Ich kann dies mit einem kleinen Testdokument und einem Makro mit einer Zeile Code reproduzieren.“‚
Wenn man das schon so weit gebracht hat könnte man ja vielleicht noch etwas Zeit für Debugging aufwenden?
Manchmal hat man ja Glück und kann mittels Systernals Event Monitor sehen, ob wer die Datei unbedingt r/w öffnen will. Das gab schon mal überraschendes.
Das könnte vielleicht helfen zu unterscheiden ob das an der unbestreitbar mangelhaften Testkultur von MS liegt und ein Bug ist(newbee macht alles mit rw auf) , oder ob das ein (Marketing) gewolltes Feature ist.
(Wer vi kennt, weiß auch, daß der auch meckert, wenn man eine geschütze Datei (versehentlich…) ändern will.)
That’s the Way..
Ja, das Problem mit dem nicht Ändern schreibgeschützter Dateien ist auch bei uns vorhanden, aber nur bei jenen Office-Dateien die „nicht“ in der Cloud liegen / lokaler Datenspeicher. Sofern die Datei bereits von dem ersten Anwender geöffnet wird, können die nachfolgenden Anwender das Dokument zwar schreibgeschützt öffnen, aber auch nicht mehr „in der Schwebe“ bearbeiten.
Ich konnte bei uns beobachten, dass jenes Problem bereits seit letztem Jahr, im Q4 mit + – Build 2211 aufgetreten ist.
Ja war auch schon ende letzten Jahres, konnte dazu aber nichts im MS Change log finden. Mich würde nur Interessieren ob es nun der Standard bleiben soll, oder nur ein versehen ist. Dann muss man halt die Vorlagen auch als Vorlage bereitstellen und nicht als Schreibgeschütztes Dokument :)
Viel schlimmer, hat kaum einer auf dem Radar: Macros in MS-Publisher und OneNote-Dateien werden neuerdings per Emailanhang als Türöffner zum Phishing und Ransomware-Verteilen verwendet, das kann man bei Bleeping nachlesen. Man kann aber Makros in beiden Applikationen problemlos per GPO sperren. Man kann auch das Ausführen von Exe-Dateien in Visio per GPO sperren und in OneNote-Dateien kann man Exe-Dateien reinlegen und per Doppelklick starten – hier hilft nur Applocker oder EDR/XDR. Diese Härtungsempfehlungen z.B. als GPO findet man bisher nirgends als Empfehlung, auch nicht beim BSI, da findet man immer nur Macro sperren für Word+Excel.
…dann schau(t) mal hier:
Microsoft Office Macro Security
Neuerdings? Das ist in Word und Excel schon seit Jahrzehnten Usus. Dem kann nur durch vorsichtigen Umgang mit Mailanhängen begegnet werden und durch Nutzen der Option, Dateien aus dem Netz erst mal im Kesemodus zu öffnen.
Zu „Ändern schreibgeschützter Dateien“:
Dass das möglich war, hatte mich schon vor Jahrzehnten mit Office 97 verwundert und manchmal sogar geärgert. Besonders lustig war das, wenn ich erst nach diversen Rechtschreib-Korrekturen an einer im Netzwerk gespeicherten Datei den Hinweis bekam in der Art ’sorry, aber deine gemachten Änderungen sind wertlos, wenn du jetzt nicht eine neue Datei erstellst.‘ Gedankliche Antwort darauf: ‚Super! Hättest du mir das nicht gleich sagen können? … Dann hätte ich mir die Korrekturen sparen können.‘
Abgesehen von diesem rein logischen Argument, kann ich mir vorstellen, dass mit dem neuen Verhalten potenzielle Fehler und/oder Datenverlust vermieden werden sollen. Bekanntlich werden mit Microsoft 365 die in Onedrive/Sharepoint gespeicherten Dateien standardmässig vorzu automatisch gespeichert. Da das bei einer schreibgeschützten Datei nicht geht, könnte ein User schlimmstenfalls zahlreichen Änderungen verlieren.
Zu „VBA Addins gesperrt“:
Dies ist offensichtlich eine indirekte Folge des neuen Verhaltens. Vermutlich – wie so oft – haben die Microsoft Entwickler diesen Fall nicht ausreichend getestet.
Allerdings kann ich mir denken, dass es in der Vergangenheit mitunter Fehler/Probleme gab, wenn im Zusammenhang mit einem Makro ein schreibgeschütztes Dokument involviert war und es dabei nicht nur um das Öffnen oder Kopieren des Inhalts ging. Das neue Verhalten bezüglich Schreibschutz kann insofern bei entsprechender Berücksichtigung die möglichen Problemursachen minimieren/ausschliessen. Aber ja, hier muss sicher nachgebessert werden.
Word Ole-Automatisierung seit ca. Ende November 2022 kaputt.
Wenn man nur einen Automatisierungsschritt macht, dann funktioniert es.
Verkettet man aber mehrere Schritte hintereinander, so kommt bei uns dann die Meldung:
„Beim letzten Öffnen von ‚Dokumentname.doc‘ führte dies zu einem schwerwiegenden Fehler. Möchten sie mit dem Öffnen fortfahren?“
Eine Verkettung von mehreren Schritten ist:
-Einfügen einer Tabelle in ein Word-Dokument über Ole-Automatisierung
-Speichern des Dokuments
-Erstellen einer PDF-Datei von diesem Dokument
Es hängt nicht direkt mit einem Word-Update zusammen, da wir jetzt auch den Fall mit Office 2010 hatten und dieses Office hat schon länger kein Update mehr erhalten.
Es scheint mit der Funktion „Add to Recent Documents“ im Datei-Explorer zu tun zu haben – also ein Windows-Komfort-Feature (aber auch das Abschalten bringt keine Erleichterung).
Bei Documents.OpenNoRepairDialog
https://learn.microsoft.com/de-de/office/vba/api/word.documents.opennorepairdialog
gibt es den Übergabeparameter AddToRecentFiles
Das kann ich bei manchen Funktionen nutzen und das lindert auch ein bisschen.
Aber die PDF-Konvertierfunktion haben wir uns über eine andere Bibliothek zugekauft und dort kann ich es nicht direkt setzen und Zack promp habe ich wieder den Fehler.
Wisst ihr noch ein Registry-Flag?
Hallo Zusammen,
ich kann diese „Bugs“ nur bestätigen. Ich quäle mich nun seit ca. 2 Wohen mit der MS Hotline rum (Hab einen Servicerequest über unser Officeportal eröffnet). Bei den Versionen 2208 aus dem Halbjahrekanal und den Versionen 2211 und 2212 aus dem Monatskanal treten diese Problem nicht auf. Bei Excel in der neusten Version auch nicht. Unser Problem ist das wir unsere Formulare (Worddokumenten mit Eingabefunktionen aus dem Entwicklermenü, z.B. Texteinabe oder Datum) auf eine schreibgeschützten Windowsfreigabe (Windows Server 20xx) ablegen. Einmal natürlich um Änderungen an den Formularen zu vehindern und zum zweiten um deren Löschung zu verhindern. Bisher konnte er Benutzer das Formular ausfüllen und es dann auf einer Freigabe mit Schreibrechten ablegen. Das ist nun nicht mehr möglich. Selbst die Eingabe in den Formularfeldern ist gesperrt. Zudem lässt sich entgegen der vom MS-Support propagierten Lösung „aktivieren sie die Bearbeitung über den Menüpunkt Beratbeitung vornehmen“ nicht.
Viele unserer Kunden nutzen diesen Ablauf so und werdn wenn die Version 2301 oder 2302 in den Monats- oder Halbjahreskanal wanderen Problem bekommen.
Leider kam vom MS-Support auch keine Aussage ob dies ab der Version 2301 so beabsichtigt ist.
Dem Vernehmen nach will MS mittelfristig VBA stillegen. Erste Schritte dazu wurden schon durch die Einstellung der Eigenzertifizierung durchgezogen. Für die Zertifizierungsstellen ist das eine Gelddruckmaschine und vermiest Hobbycodern einiges. (Der Verlag, für den ich schreibe, hat aus formalen Gründen keine Verifizierung für seine Verlagsvorlage erhalten.)
Ich habe auch bei einem Grosskunden das Problem mit dem Öffnen der schrebgeschützten Word Dateien.
Früher war dies viel besser. Man konnte es zumindest öffnen, etwas eintragen.
Ich hoffe Microsoft lässt sich hier noch was einfallen.