Outlook 2013/2016 „Ein unbekannter Fehler ist aufgetreten, Error-Code 0x80090345“

Unter Windows 8.1 oder höher mag sich ein nagelneu eingerichtetes Outlook nicht mit dem Exchange-Server verbinden. Das passiert gleichermaßen bei lokalen Exchange-Servern und auch unter Office 365. Statt sich zu verbinden erscheint nach dem Autodiscover, also nach dem „Exchange-Servereinstellungen suchen“.

Lösung

Dieser Fehler tritt nur auf, wenn die Domäne unter Windows NT4 oder Samba betrieben wird. Die Lösung lautet, auf den neuen Credential-Manager-Schutz aus KB3000850 zu verzichten:

Einfach dazu im Schlüssel HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb den DWORD-Wert „ProtectionPolicy“ auf 1 setzen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001

Die Samba-Leute sind mit ihren Credentials noch nicht so weit (siehe Wiki).

Auerswald TSA-a/b an Audiocodes MP-112 FXS

Der Auerswald TSA-a/b Adapter erkennt an einer VoIP-Telefonalage (z.B. Swyx) die Programmierung (durch Tonsequenzen) nicht zuverlässig. Zumindest nicht mit ienem SwitIt-Softwareclient am Notebook.

In diesem Fall lag es daran, das die Umgebungsgeräusche (und die Auodio-Feedbackschleife) zu lau waren und offensichtlich die Programmiertöne übertönt hatten. Zuverlässige Abhilfe schaffte das herunterregeln des Mikrofons am Notebook.

Tonabfolge zur Programmierung

##8   (Programmieren einleiten. Wird NICHT bestätigt)
000000  (PIN. Wenn die PIN 000000 lautet, ist Programmieren NICHT möglich. Kein Bestätigungston.)
* (Sternchen schliesst die PIN ab. Eine Korrekte eingabe wird durch fünf kurze Töne bestätigt *tut*tut*tut*tut*tut*)
50 (Programmier-Funktion auswählen)
8  (Wert setzen)
AUFLEGEN (oder #9 wählen)

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Wenn man unter Windows mit dem MMC Zertifikats-SnapIn einen frischen CSR erstellt („REQ“ im Windows-Jargon), wird standartmäßig der aktuelle „Microsoft Strong Crytographic Provider“ als Kryptoanbieter ausgewählt. Das ist im Prinzip auch gut so, denn das ist der aktuellste und vom Umfang her größte CSP (Certificate Storage Provider) den Windows mitbringt. Die meisten Windows-Features können damit auch problemlos umgehen – der IIS, der SMTP, RDS und so weiter.

Nicht jedoch Exchange (bis einschliesslich 2016 CU3). Exchange FBA unterstütz keine CNG Zertifikate. Nutzt man diese doch, kommt es zu dem berüchtigten Exchange OWA und Exchange EAC Anmeldeloop.

Folgt man dem im Blog angegebenen Anweisungen zum austausch der Zertifikates und erstellt ein neues passendes Zertifikat, kommt es beim Import der neuen Zertifikate (ob CER oder PFX spielt keine Rolle) oftmal zu dem Fehler

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Ursache hierfür ist, das der im CSR angegebene CSP nicht korrekt ist. Wenn man den CSR unter Windows erstellt, versteckt sich das zugehörige Häkchen unter Neue Anforderung erstellen > Eigenschaften > Privater Schlüssel > Kryptografiedienstanbieter. Der für den CSR ausgewählte CSP lässt sich mit certutil an der Kommandozeile selbstverständlich nicht nachschauen …

Windows PKI Fehler „Der angeforderte Antragstellername ist ungültig oder zu lang (0x80094001)“

Problem

Beim ausstellen eines neuen Zertifikates mit einem frisch generierten CSR reagiert die Windows Zertifizierungsstelle (CA) in dem Webinterface mit diesem Fehler:

Der angeforderte Antragstellername ist ungültig oder zu lang (0x80094001)

Das gleiche tut Sie auch auf einem englischen Windows, mit einem englischen Fehler:

Error parsing request the subject name is invalid or too long 0x80094001 (CSR)

Lösung

Wenn die CA unter Windows Server 2008 oder früher erstellt wurde, hat diese warscheinlich das gute alte 64-Zeichen Limit für Domains geerbt. Man kann diese (heute) sinnlose limitierung ganz schnell abschalten:

c:\> certutil -setreg ca\EnforceX500NameLengths 0

Die Einstellung ist ebenfalls notwendig, wenn man Wildcard-Zertifikate mit einer Windows CA unterschreiben möchte.

Windows Defender (MsMpEng.exe) deaktivieren (Windows 10 und Windows Server)

Problem

Wärend eines Setups oder einer größeren Aktion auf einer Windows-Maschine kostet der Windows-Defender „MsMpEng.exe“ (der Diensthost des Windows-Defenders) unnötig viel Leistung und Zeit.Trotz der allgemein recht guten Performance des Virenwächters von Microsoft, lässt sich vor allem beim Zugriff auf große Dateimengen einiges an Zeit sparen wenn der Wächter temporär ausgeschaltet wird.

Lösung

In der Regel reicht es schon, an der PowerShell die Realtime-Engine für die Echtzeitüberwachung aus zu schalten. Dann sinkt die Last des Prozesses auf praktisch Null und man kann sofort eine deutlich bessere Performance beim Dateizugriff beobachten. Die Einstellungen werden sofort aktiv und brauchen keinen Neustart.

Windows Defender Echtzeitüberwachung deaktivieren

PS C:\> Set-MpPreference -DisableRealtimeMonitoring $true

Windows Defender Echtzeitüberwachung aktivieren

PS C:\> Set-MpPreference -DisableRealtimeMonitoring $false

Windows Defender Echtzeitüberwachung-Einstellung prüfen

PS C:\> Get-MpPreference | FL *RealtimeMonitoring

Windows-Defender vollständig deinstallieren

PS C:\> Remove-WindowsFeature Windows-Defender, Windows-Defender-GUI

Exchnage 2007/2010/2013/2016: „Vorangegangener Installationsfehler beim Ausführen der Aktion Install/Uninstall“

Problem

Das Exchange 2016 Setup hakt an so manchen stellen. Ganz besonders häufig treten Fehler bei der Deinstalation einer Rolle auf, oder bei einem CU-Update. Fehler wie dieser:

Vorangegangener Installationsfehler beim Ausführen der Aktion „Install“ [oder auch "uninstall", je nachdem]. Die Installation kann nicht fortgesetzt werden.

Lösung

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15

  1. In  allen Schlüssel hierunter nach der Zeichenfolge „Action“ suchen, welcher den Wert „Install“ (oder Uninstall, je nachdem) beinhaltet.
  2. Den ganzen Eintrag löschen

Danach läuft das Setup wieder. Zwar im Recovery-Modus, aber normalerweise damit auch erfolgreich.

VMware vSphere CLI „Connect to failed. Server SHA-1 thumbprint FF…

Problem

Die neuen VMware vSphere CLI Tools ab Version 6.0+ (Download v6.5) möchten nicht mehr „einfach so“ eine ESXcli Verbindung aufbauen. Wenn man einen Befehl startet, kommt sofort die Fehlermeldung „Server SHA-1 thumbprint <not trusted>“.

C:\>esxcli -s <SERVER> -u root -p <PASSWORT>

Connect to <SERVER> failed. Server SHA-1 thumbprint: F5:CE:AF:AF:D2:13:48:3D:C2:FB
:EE:C9:22:BE:B8:39:20:09:9D:B5 (not trusted).
C:\>

Das passiert, weil vSphere heute ganz spontan noch total viel sicherer ist als früher. Blöderweise laufen alle möglichen Scripts damit nun ins leere. Selbstverständlich gibt ESXCLI trotz des Fehlers den Errorlevel 0 („Erfolg“) zurück *seufz*

Lösung

Die schnellste und einfachste Möglichkeit: Den Fingerabdruck des Server an der Kommandozeile mitgeben.

C:\>esxcli -s <SERVER> -u root -p <PASSWORT> --thumbprint <THUMBPRINT>

Eine ‚permanente‘ Lösung ist dann (zum Beispiel), gar nicht direkt mit dem ESX-Host zu sprechen sondern über den vCenter Server über den Parameter ‚vihost‘ mit dem Host. Das erlaubt es, das vCenter Server Zertifikat vorher in den lokalen Zertifikatsspeicher zu importieren und somit der Maschine zu vertrauen.

  1. Die lokalen vSphere root-Zertifikate herunterladen und in den Stammzertifizierungsstellen-Speicher importierenvmware-root-zertifikat-herunterladen
  2. C:\>esxcli -s <VCENTER-SERVER> -u root -p <PASSWORT> --vihost <ESX-HOST>