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)

Active Directoryx Zertifikatdienste („certsvc“) starten nach Upgrade nicht 0X422 (WIN32: 1058 ERROR_SERVICE_DISABLED)

Problem

Nach einem In-Place Upgrade von Windows Server 2012/2012R2 auf Windows Server 2016 werden die „Active Directory-Zertifikatdienste“ (certsvc) nicht mehr gestartet. Versucht man das in der Zertifizierungsstellenkonsole manuell nachzuholen, erhält man diesen fiesen (und zudem falsch übersetzen) Fehler:

Windows konnte Active Directory-Zertifikatdienste-Dienst auf dem lokalen Computer nicht gestartet werden.
Fehler 1058: Der Dienst kann nicht gestartet werden deaktiviert ist oder weil keine Geräte zugeordnet aktiviert hat.
Versucht man es in der Diensteverwaltun heisst es:
Der Dienst kann nicht gestartet werden, weil er deaktiviert wurde oder nicht zugeordneten Geräte aktiviert ist.
0X422 (WIN32: 1058 ERROR_SERVICE_DISABLED)

Um es für den Admin noch spannender zu machen, gibt es auch keine Einträge im System- oder Anwendungsprotokoll. Es passiert einfach nichts.

Lösung

Jetzt wird es peinlich: Ein Systemneustart hilft. Boot toot goot.

Die Dienstregistrierung der Zertifizierungsstelle passiert erst, wenn die CERTCONFIG wieder ausgepackt ist. Das passiert beim ersten erfolgreichen Systemstart. Danach starten auch die Dienste wieder …

Update: Ab genau jetzt ist dieses Verhalten sogar offiziell 🙂 Schön wenn man Microsoft auch mal helfen kann …

Windows Batch: Uhrzeit und Datum verwenden (UPDATE: mit führender „0“ bei einstelligen Stunden)

Ich benötige im Alltag ab und an das aktuelle Datum und die Uhrzeit „zerlegt“ in einzelne Variablen, um zum Beispiel Dateien nach Zeit oder Datum abzuspeichern oder Logeinträge korrekt formatiert auszugeben. Das ist seit Windows XP zum Glück recht einfach, aber weil ich faul bin lege ich hier meine zu diesem Zweck erzeugten Substring-Scriptschnipsel ab – dann muss ich die paar Zeilen nicht immer neu tippen (und korrigieren).

Es gibt da auch ein Problem mit den führenden Nullen: Windows setzt die Zeitvariable %time% nicht mit führenden Nullen, sondern in „Menschlich lesbar“.

Beispiel:

C:\>echo %time%        Ergibt ab 10Uhr: 11:02:18,04

C:\>echo %time%        Ergibt ab 24Uhr: _9:02:18,04 Hier ist ein Leerzeichen eingefügt, denn das Padding des Strings ist immer gleich breit.

Lösung

set YYYY=%date:~-4%
set MM=%date:~-7,2%
set DD=%date:~-10,2%
set hr=%time:~0,2%
if "%hr:~0,1%" == " " SET hr=0%hr:~1,1%
set min=%time:~3,2%
set sek=%time:~6,2%

Mit diesen Variablen würde eine Ausgabezeile zum Beispiel so aussehen:

echo Es ist heute der %DD%.%MM%.%YYYY% und wir haben die wundervolle Uhrzeit %hr%:%min%:%sek%

Mit führenden Nullen sieht das Ergebnis dann, korrekterweise, so aus:

Es ist heute der 24.12.2016 und wir haben die wundervolle Uhrzeit 01:04:37

Nicht das diese Zeile viel Sinn hätte, in der Praxis benötige ich beispielsweise eher so etwas:

zip –m -9 idslogs-%YYYY%%MM%%DD%.zip %1*.log

… das mir Dateien mit einem sinnvollen Namen (z.B. idslogs-20121203.zip) erstellt.

Wichtig zu wissen: Diese Zeilen legen die wichtigen Werte direkt in eigenen Variablen ab; die Zuordnung ist im Moment der Zuordnung statisch, was bedeutet das ein Wert sobald zugewiesen immer so bleibt und sich nicht mit fortschreitender Zeit ändert. Wenn die Werte aktualisiert werden sollen (beispielsweise zu beginn/ende eines Script) muss dieser Block wieder aufgerufen werden, etwa mit einer call: Anweisung dorthin.

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 …