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

Veröffentlicht am von — Keine Kommentare ↓

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.

Tobit David.fx Client alle Ordner (Posteingang, Infocenter etc.) plötzlich leer

Veröffentlicht am von — Keine Kommentare ↓

Problem

Im Tobit David.fx Client Version 11 sind  alle Ordner für einen einzelnen Benutzer plötzlich leer oder die Elemente werden zumindest nicht mehr angezeigt. Das kann vorkommen wenn Benutzer bei einem Mitarbeiterwechsel umbenannt, anstatt neu angelegt werden.

Lösung

Der  AD-Benutzer, der dem fehlerhaften Tobit Konto zugeordnet ist muss Vollzugriff auf sein Archiv bekommen: C:\david\Archive\USER\Benutzer ID
Die Benutzer ID findet sich in der David Administrator Konsole.

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

Veröffentlicht am von — Keine Kommentare ↓

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).

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*. Naja, mittelfristig geht es eh in Richtung Powershell. Ach nein, die hat das Problem ja auch.

Lösung

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

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

Beispiel:

C:\> esxcli -s 128core-esx01.farm.local -u root -p <PASSWORT> --thumbprint <THUMBPRINT> storage vmfs unmap -l iscsivol36tb-a

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>

 

Sie sind zu oft hier

Veröffentlicht am von — Keine Kommentare ↓

Die IT-Serviceverträge unseres Arbeitsgebers beinhalten meistens pauschale Vor-Ort oder Remote-Consultingkontingente. Das bedeutet, das einer der Admins aus unserem Team den IT-Staff der Kunden „vollzeit“ Vor-Ort verstärkt. Je nach Aufgabengebiet und Schwerpunkten fallen für uns dann in der Regel Tätigkeiten an, die sonst niemand machen kann (oder möchte). Das beinhaltet die unbeliebten Server-Reboots („Es geht *foo* nicht“), performancedegradierende Patchinstallationen, fiese Geräteneustarts, Systrem- und Stresstest, Sicherheitsprüfungen und so weiter.

Daher sind Admins in aller Regel zu 50% beliebt und zu 50% gehasst. Ein Unternehmen brachte das soeben ziemlich genau auf den Punkt:

Sie sind viel zu selten hier. Und viel zu oft.

🙂