Netzlaufwerke von Gruppenrichtlinien werden nach Windows 10 Upgrade nicht mehr verbunden.

Problem:

Nach dem (erfolgreichen) Update von Windows 7 auf Windows 10 werden „plötzlich“ Netzlaufwerke nicht mehr eingebunden, welche per GPO verteilt werden.
In der Ereignisanzeige findet man i.d.R. folgenden Fehler:

Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\foo.bar\SysVol\foo.bar\Policies\{UID}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.

Ursache ist in diesem Fall meist das UNC-Hardening, welches unter Windows 10 standardmäßig aktiviert ist.

Lösung:

Einfachste Lösung ist eine neue GPO anzulegen, welche das UNC-Hardening für die SYSVOL und ggfs. NETLOGON Freigabe wieder deaktiviert.
Dazu unter „Computerkonfiguration > Administrative Vorlagen > Netzwerk > Netzwerkanbieter “ die Richtlinie für Gehärtete UNC-Pfade aktivieren und folgende Einträge hinzufügen:

Wetname: \\*\SYSVOL
Wert: RequireMutualAuthentication=0, RequireIntegrity=0
(ggfs. für \\*\NETLOGON den selben Wert hinzufügen)
unc-hardening

Bei der nächsten Anwendung der Gruppenrichtlinien an den Clients (spätestens nach einem Neustart) wird dann auch die Netzlaufwerke-GPO wieder angewendet und somit die Netzlaufwerke wieder eingebunden.

WLAN zu langsam

Kunde: „Das WLAN ist zu langsam!!11 Wenn ich eine Datei auf mein Notebook kopiere dauert das ewig und er kopiert nur mit 27mbit/s“

Admin: „Das WLAN ist schnell, die Karte in dem [ur]alten Macbook ist langsam.“

Kunde: „Unsinn, WLAN ist WLAN und das WLAN hat 300Mbit/s“

Admin: „Naja, aber die Karte kann nur 802.11g, das sind 54mbit/s“

Kunde: „Aber das WLAN hat doch 300MBit/s!!!111!“

Admin: „Ja, auch eine Autobahn hat immer 300km/h, trotzdem kann mein Heizölporsche nur 120 fahren“

Kunde: (überlegt … länger … und schaut dann mit großen Augen auf) „Oh … ah … achso! Stimmt.“ *Nimmt sein Notebook und geht*

🙂

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

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

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)

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.