“Komm in die Cloud!” haben sie gesagt … “Da arbeiten Vollprofis, die wissen, was sie tun.”

Aktuell zeigt ein Ausfall bei Microsoft daß die Abhängigkeit kompletter Geschäftsprozesse, Unternehmen, Behörden oder gar Regierungen von einem Cloud-Anbieter keine gute Idee ist.

Die Liste der gestörten Dienste wurde zwischenzeitlich lang: Exchange Online, Microsoft 365 Admin Center, Microsoft 365 Apps, Microsoft 365 Apps Admin Center, Microsoft 365 Education, Microsoft Copilot 365, Microsoft Defender for Office 365, Microsoft Defender XDR, Microsoft Fabric, Microsoft Graph, Microsoft Intune, Microsoft Planner, Microsoft Power Apps, Microsoft Purview, Microsoft Teams, Microsoft To Do, Power BI, SharePoint Online, Universal Print und Windows 365 nennt Microsoft als betroffen. [Quelle]

Ein lokaler Admin hätte es nie geschafft, mit einem einzigen Update mal eben Millionen Büros von Tokio bis London gleichzeitig in den Zwangsurlaub zu schicken oder eine simple Konfigurationsänderung in ein globales geopolitisches Ereignis zu verwandeln.

Die genauen Umstände des auf den 17. Dezember 2002 datierenden Screenshots lassen sich leider nicht mehr rekonstruieren.

Offensichtlich kam es beim Ausführen der Funktion “Ändern/Entfernen” von Microsoft Office 97 zu einem Systemfehler. Die Wahlmöglichkeit zwischen “Abbrechen” und “Abbrechen” ist allerdings nicht wirklich hilfreich.

Nach dem Umzug eines Perl-Skripts auf einen neuen Host lief das Skript auf den Fehler

obwohl alle benötigten Module installiert waren.

Die befragte Suchmaschine lieferte als erstes Ergebnis meinen eigenen Blogbeitrag “No type library matching “Microsoft Outlook” found”. Offensichtlich hatte ich den Fehler vor rund 4 1/2 Jahren schon einmal.

Funktioniert in der Kombination mit einer 32-bit Microsoft Office-2013-Version die Zeile

problemlos, so wird sie bei einem installierten 64-bit Office mit folgendem Fehler quittiert:

Eine längere Suche führte schließlich zum entscheidenen Hinweis: bei der 64-bit Installation wird der Schlüssel für die Typelib vom Office-Installer nur als “win64” gesetzt, Perl aber sucht nach einem “win32” Eintrag.

Ein Workaround ist somit recht einfach: unterhalb des Registrierungspfads

nach dem Eintrag für die “MSOUTL.OLB” suchen und passend zum “win64” Key händisch einen “win32” Key mit gleichem Inhalt erzeugen.

Sicherheit und Bequemlichkeit schließen sich oft gegenseitig aus - während man für ein Mehr an Sicherheit einen Teil Bequemlichkeit opfert, muß meist an der Sicherheit gespart werden, damit’s bequem wird.

Spürbar wird dies zum Beispiel bei der Verwendung von VBA-Makros: Ist in Excel die Makro-Sicherheit auf “Hoch” eingestellt, können Makros in der Regel keinen Schaden anrichten, da sie nicht ausgeführt werden dürfen. In der Einstellung “Mittel” muß bei jedem Öffnen einer Arbeitsmappe mit Makros entschieden werden, ob die Makros ausgeführt werden dürfen oder nicht. In der Einstellung “Niedrig” wird jedes Makro ohne lästige Nachfrage ausgeführt, inklusive eventuell darin enthaltenem Schadcode.

Eine elegangte Lösung dieses Szenarios stellt das Signieren selbst erstellter Makros dar - einmal als vertrauenswürdig eingestuft, werden diese auch auf Sicherheitsstufe “Hoch” ausgeführt und die Nachfrage auf Sicherheitsstufe “Mittel” entfällt.

Hierzu muß nicht unbedingt ein kostenpflichtiges Zerfitikat einer offiziellen Certificate Authority erworben werden, für den internen Einsatz reicht auch die Verwendung eines selbstsignierten Zertifikats, das mit frei verfügbaren Mitteln erstellt werden kann.

Vollständigen Beitrag lesen