DATEV Fehler „EXC244795483“ in den DATEV-Rechnungswesen-Programmen („HookCairo.Connect … Der Adapter (IOfficeApplication) konnte nicht ermittelt werden“)

Seit Juli 2023 plagt dieser Fehler einen Großteil der DATEV „Rechnungswesen“ Anwender. Während andere Hersteller das Problem längst behoben haben, verweist DATEV nur immer wieder auf „Microsoft“ 🤦

Die Fehlermeldung lautet:

Die Datei oder Assembly "office, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" oder eine Abhängigkeit davon wurde nicht gefunden. Zugriff verweigert

Natürlich kann Microsoft nichts dafür, wenn Softwarehersteller sich nicht an die vorgesehene Vorgehensweise halten, Office-Tools zu referenzieren.

Lösung (Workaround)

Diese Lösung ist nur ein Workaround, aber schnell und einfach. Das Vorgehen setzt administrative Rechte voraus. Die DATEV-Software (bzw. deren Dienste) laufen zwar mit passenden Rechten, aber die Behebung des Fehlers bleibt dem Benutzer überlassen.

  1. DATEV vollständig beenden
  2. .NET Framework reparieren via https://aka.ms/DotnetRepairTool

Das Tool setzt die Dateiberechtigungen zur Maximierung der Kompatibilität auf den Stand von .NET4 zurück, den DATEV benötigt.

Nachdem das Tool durchgelaufen ist, funktioniert Rechnungswesen wider, bis ein Update oder eine .NET FrameWork Erweiterung die Rechte wieder korrigiert. WQenn das der Fall sein sollte, einfach die Schritte wieder und wieder wiederholen. Bis DATEV den Fehler endgültig behebt.

Richtige Lösung (falls das hier jemand von DATEV ließt)

Die referenzierte office.dll (15.x) war lange für Abwärtskompatibilität von Add-Ins zu Office 2007/2010/2013 da. Alle diese Office-Versionen sind EOL – wenn aber der Support noch wichtig ist, sollte man einfach die korrekte COM-Referenz anstelle der „harten“ Datei-Referenz auf ein .NET4-Assembly (EOL 2022) verwenden.

Die „richtige“ Lösung (ironischerweise geliefert vom Microsoft Support, auf den DATEV verweist) ist einschliesslich Beispiel hier zu finden: https://github.com/dotnet/project-system/issues/5735

VLC Player Explorer Kontextmenü entfernen

Manchmal möchte („muss“) man das Windows Explorer Kontext-Menü von VLC („Zur VLC Media player Wiedergabeliste hinzufügen“ und („Mit VLC Media player wiedergeben“) nach der Installation entfernen.

Die „Offizielle“ Möglichkeit dazu ist, den VLC einfach komplett zu deinstallieren und bei der Neuinstallation das Häkchen „Kontext Menüs“ im Setup-Assistenten zu entfernen. Das ist umständlich und langwierig.

Lösung

An der PowerShell tut es stattdessen auch dieser Dreizeiler:

New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT
Remove-Item HKCR:\Directory\shell\AddToPlaylistVLC\ -Recurse
Remove-Item HKCR:\Directory\shell\PlayWithVLC\ -Recurse

Windows CA: SAN (oder DN) fehlt in Zertifikaten aus dem Template „Webserver“

Google unterstützt in Chrome seit Version 58 (von 2017!) Feld „Common Name“ in SSL/TLS-Zertifikaten nicht mehr. Gleiche gilt für Firefox seit Version 98 und mittlerweile auch alle anderen Browser.

Firefox und Chrome melden: SSL_ERROR_BAD_CERT_DOMAIN

Die Windows Zertifizierungsstelle (Windows CA) mit dem Template „Webserver“ füllt dieses Feld allerdings nicht automatisch. Daher muss man bei Zertifikatsanforderungen das Attribut manuell hinzufügen und die CA dafür konfiguriert haben.

Warum? Das CN-Feld wird verwendet, um den Domänennamen anzuzeigen, für den das Zertifikat gültig ist. Der reine CN als Identifikationsmerkmal wurde allerdings vor fast zwei Jahrzehnten per RFC abgeschafft, das Feld ist viel zu unflexibel (keine Wildcards, keine Multidomains …). Die heute genutzten Felder sind „DN=“ und „SAN=“ (DNS-Domain) – warum die noch immer nicht in Microsoft’s Standard-Templates enthalten sind ist ein Geheimnis.

Lösung

Man muss der CA zuerst beibringen, den „Subject Alternate Name“ (SAN) überhaupt nachträglich zur Anforderung hinzuzufügen. An einer Administrator-CMD-Shell geht das so:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Ab dann kann (=muss) man den Anforderungen den SAN als „san:“ Attribute bei der Beantragung mitgeben.

Lösung (Web Zertifizierungsstelle)

Im Feld „Zusätzliche Attribute“ können einer oder mehrere SANs mit „&“ getrennt angegeben werden:

san:dns=SERVERNAME.EXAMPLE.COM&dns=SERVERNAME2.EXAMPLE.COM

Lösung (Kommandozeile)

An der Kommandozeile sollte im Auftrag (*.inf) das Attribut einfach bereits unter „[RequestAttributes]“ enthalten sein:

[RequestAttributes]
CertificateTemplate = Webserver
SAN="dns=SERVERNAME.EXAMPLE.COM"

Dann kann man das Zertifikat ganz normale Requeste werden:

certreq -submit -attrib "CertificateTemplate:Webserver" CSRDATEINAME.req ZERTIFIKATAUSGABEDATEI.cer

Überprüfung der Active Directory-Replikation und -Integrität mit „Repadmin“

Repadmin ist das zentrale Diagnosetool für die Active Directory-Replikation. Das Tool ist auf allen Domänencontrollern vorinstalliert oder via Remote Server Administration Tools (RSAT) nachinstallierbar.

Das hier sind häufig genutzten Parameter, damit man die nicht immer wieder einzeln googlen muss. Es gibt auch einen ganzen KB-Abschnitt darüber, aber die wichtigen Parameter gibt es dort auch nicht auf einer Seite.

Die wichtigsten Parameter von repadmin

  • repadmin /replsummary Zusammenfassung der ein- und ausgehenden Verbindungen (auch fehlgeschlagene)
  • repadmin /showrepl Status zwischen Domänencontrollern, pro Namenskontext
  • repadmin /queue Listet die eingehende Replikationswarteschlange auf
  • repadmin /syncall DOMAINCONTROLLER dc=EXAMPLE,dc=COM Synchronisiert den angegebenen Domänencontroller sofort
  • repadmin /syncall /AdeP Änderungen nach außen an alle Domänencontroller weiterleiten
    • A = Alle Partitionen
    • e = Enterprise (Meint: Cross Site Replikation eingeschlossen)
    • D = Server nach DN auflösen
    • P = Push (-Replikation)
  • repadmin /replicate Zeigt die eingehende Replikationswarteschlange an

PowerShell Skripts als geplante Tasks in der Aufgabenplanung starten

Es gibt ein Update zu diesem Artikel: https://www.ugg.li/powershell-scripts-starten-in-der-aufgabenplanung-nicht-ergebnis-0x1/

Powershell-Script lassen sich an der (Powershell-) Kommandozeile komfortabel starten, jedoch nicht ohne weiteres in geplanten Tasks.

Das geht schnell, einfach und Fehlertolerant so:
powershell-aufgabenplanung-startenFeld Programm/Script:

%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe

Argumente:

-noninteractive -file "C:\PF AD\SCRIPT.ps1" -ExecutionPolicy Bypass

Mehr Details dazu hat das MSDN in diesem Artikel, aber im Prinzip ist es das schon.