vmWare vSphere 5.1/5.5 Client installiert auf Windows Server 2012R2 nicht

Veröffentlicht am von — 2 Kommentare ↓

Problem

Der vSphere Client 5.1 lässt sich auf Windows Server 2012R2 nicht installieren. Es gibt keine Fehlermeldung, sondern das Setup verschwindet beim start der eigentlichen Installation einfach vom Desktop. Im Taskmanager ist der Installationsprozess aber noch zu sehen.

vmware-viclient-server2012r2

Lösung

Schuld ist das Fehlen des .NET Frameworks 2.0, was im .NET Framework 3.0 enthalten ist, was wiederum im Windows-Feature .NET Framework 3.5.1 versteckt wurde. Es hilft die Installation des .NET Framework 3.5 Features über den Servermanager -> Rollen und Features hinzufügen -> Weiter -> Weiter -> .NET Framework 3.5\.NET Framework 3.5.

 

 

Howto: vmware vSphere vCenter 5.5 mit Active Directory einrichten

Veröffentlicht am von — Keine Kommentare ↓

Die Einrichtung des vCenter Servers mit dem Active Directory als Identitätsquelle ist etwas umständlich zu erledigen als unter 4.x/5, aber der Aufwand lohnt sich. Das SSO-Backend unter vSphere 5.5 ist praktisch komplett neu geschrieben und daher deutlich gradliniger als das SSO-Gebastel von früher. Leider ist dabei einiges an Adminfreundlichkeit auf der Strecke geblieben.

Ziel dieses Artikels: Ein vCenter Server soll gegen ein Active Directory („Windows Sitzungs-Anmeldedaten verwenden“) authentifizieren. Netzwerkdaten, DNS, Hostnamen und so weiter sind korrekt eingerichtet und der vCenter Server läuft soweit.

1. vCenter zum Active Directory hinzufügen

vCenter Verwaltungs-Weboberfläche (https://vcenter55:5480) öffnen.

  1. Als root anmelden
  2. Tab vCenter Server -> Authentication den Haken bei „Active Directory Enabled“ setzen und passende Domänenanmeldedaten eingeben
  3. „Save Config“
  4. Unter „SSO“ den Usernamen für den SSO-Login merken und ein Kennwort konfigurieren
    vcenter-active-directory-sso-username
  5. vCenter Server neu starten: System -> Reboot

vcenter-active-directory-enable

2. Identitäsquelle hinzufügen

  1. In den vSphere Webclient als der (oben gemerkte) SSO-Administrator einloggen (https://vcenter55.wittgastec.de:9443/vsphere-client)
  2. Verwaltung -> Konfigurationvcenter-active-directory-hinzufuegen
  3. Oben links auf das grüne Plus, die Identitätsquelle hinzufügen und das Fenster ausfüllenvcenter-active-directory-aktivieren
  4. Domäne auswählen und „Als Standarddomäne festlegen“
    vcenter-ad-sso-standart

3. Rechte für Domänen-Benutzer oder Domänen-Gruppen hinzufügen

Der Einfachheit halber nutze ich jetzt den guten alten vSphere (C#-) Client. Flash ist für die Weboberfläche ja ein dermaßen üble Wahl, das ich soweit möglich beim Client leiben werde. Aus Abwärtskompatibilitätsgrünen kann man als Admin darauf ja eh nicht wirklich verzichten. Also Client auf und als root am vCenter anmelden.

  1. Den vCenter Server auswählen -> Berechtigungen -> unten rechte MT und „Berechtigungen hinzufügen“
  2. Einen neuen Benutzer „Hinzufügen“ und in dem Hinzufügen-Fenster oben die Domäne auswählen vcenter-active-directory-benutzer-auswaehlen
  3. Gewünschte Rechte vergeben
    vcenter-active-directory-rechte

Schon fertig 🙂

vSphere Lost connectivity to the device mpx.vmhba32:C0:T0:L0 (HP ProLiant Gen9 Server from SD-Card)

Veröffentlicht am von — 2 Kommentare ↓

Nach „einer Weile“ verliert ein HP ProLiant G9 die Verbindung zu seiner lokal eingesteckten (selbstverständlich „HP Enterprise“) SD-Karte:
Lost connectivity to the device mpx.vmhba32:C0:T0:L0

vmware-esxi-sd-card_lost-connection

Zum Glück läuft der VMware  ESX(i) seit Version 5 aus dem Hauptspeicher, läuft also problemlos weiter, bis er etwas schreiben möchte (Hostprofile zum Beispiel). In der Regel bootet der Server nach einem Herunterfahren (ausschalten) und einem kurzen Stromlosmachen (5-20 Sekunden) wieder.

Das passiert bis ILO Firmware 2.2x, der Fehler ist in Version 2.30 und höher behoben. Aktuell ist ILO Version 2.42.

Programme von Netzlaufwerken crashen nach Upgrade von Windows 7

Veröffentlicht am von — 2 Kommentare ↓

Problem

Nach dem (erfolgreichen) Update von Windows 7 auf Windows 10 stürzen auf einigen Arbeitsstationen auf einmal Programme ab, die „jahrelang“ völlig stabil liefen. Betroffen sind Prgoramme, die von Netzlaufwerken gestartet werden oder von Netzlaufwerken und UNC-Pfaden DLLs (nach)laden. Betroffen sind Windows 8/8.1 und hauptsächlich Windows 10.

Lösung

Seit Windows 8 werden offene SMB-Sitzungen zu Netzlaufwerke und UNC-Pfaden nach einer gewisser Leerlaufzeit (standardmäßig 15 Minuten) getrennt (autodisconnect und keepconn) um den Fileserver zu entlasten. Bei „moderner“ Software und Programmen die alle benötigten Bestandteile nur einmal laden ist das kein Problem – schwierig wird es bei klassischen Programmen die davon ausgehen, das eine SMB-Sitzung „ewig“ offen bleibt.

Die entsprechenden Werte kann man per Registry (oder via GPO) anpassen:

HKLM\System\CurrentControlSet\services\LanmanWorkstation\Parameters

ein DWORD-Wert „KeepConn“ mit dem Wert „FFFF“ (HEX) Anlegen und zudem unter

HKLM\System\CurrentControlSet\services\LanmanServer\Parameters

ein DWORD „autodisconnect“ mit dem Wert „FFFFFFFF“ (HEX) Anlegen.

Ergänzend: Bei Netzlaufwerken, welche per GPO verteilt werden, kann auch das Ändern der Richtlinie von „Ersetzen“ auf „Aktualisieren“ helfen. Die Einstellung „Element entfernen, wenn es nicht mehr angewendet wird“ ist dann leider nicht mehr möglich, aber Windows behält dann über die Anwdung einer GPO hinweg die Laufwerksverbindung bei.

Exchange 2013 internes Relay nach „RCPT TO:“ sehr langsam

Veröffentlicht am von — Keine Kommentare ↓

exchange-delay-after-rcpttoProblem

Ein Exchange 2013 Receive Connector reagiert nach dem RCPT-Kommando extrem langsam. so langsam, das verschiedene SMTP-Clients sogar mit einem timeout reagieren. Die Zustellung klappt aber in den meisten Fällen.

Lösung

Der Empfangsconnector umgeht warscheinlich die Anti-Spam Agents nicht. In der Standardeinstellung hat eine Anonyme Verbindung (wie es bei einem Relay meistens der Fall ist) auf einem Connector nicht das Recht, die lokalen Filter zu umgehen. Daher kommt es zu (RBL und Tarpitting) Wartezeiten.

Umgehen der filter für Anonyme Verbindunge erlauben:

[PS] C:\> Get-ReceiveConnector -Identity "SERVER\Connectorname" | Add-ADPermission -user "NT-Autorität\Anonymous-Anmeldung" -ExtendedRights Ms-Exch-Bypass-Anti-Spam

In der Englischen Version eines Active Directory ist die (in UTF-8 geschriebene) „NT-Autorität\Anonymous-Anmeldung“ durch das entsprechende Prinzipal eines EN Active Directory zu ersetzen: „NT AUTHORITY\ANONYMOUS LOGON“.

In einen sehr guten Artikel zu dem Thema Connectoren“ hat der Zach schon vor einer Weile die wichtigen eigenschaften und das Schema zusammengefasst: http://www.the-little-things.net/blog/2014/07/06/exchange-receive-connector-tango-part-1/