Schlagwort-Archive: Windows Server 2012R2

Windows Server 2012R2 Fileserver – Kein Zugriff auf Shares möglich

In einer Umgebung mit vielen Fileservern bin ich bei einem speziellen Fileserver über ein Problem gestolpert: In unregelmässigen Abständen konnte man von Windows 7 Clients nicht mehr auf die Fileshares eines Windows Server 2012R2 Servers zugreifen.

Gemappte Laufwerke funktionierten nicht mehr und auch der direkte Zugriff auf den UNC Pfad funktionierte weder über den Namen, noch über die IP Adresse.
Ein Restart des Serverdienstes auf dem Server blieb beim Stoppen des Dienstes hängen.
Nur ein Neustart des Servers hilft. Danach funktionierte der Zugriff wieder einwandfrei.

Mir fiel dann auf, dass der Zugriff über Server 2003 und von XP aus immer noch funktionierte wenn das Problem auftrat.
Das engte die mögliche Ursache auf ein Problem mit SMB2 ein. Tatsächlich konnte ich einen Thread finden, in dem viele User im Technet ein gleich geartetes Problem beschreiben:

Technet Forum Link

In meinem Fall funktionierte die Umstellung des Filesystemdriver Dienstes von Manuell auf Autostart. Dieser Dienst ist nicht in der Services MMC zu finden. Stattdessen muss man die Kommandozeile öffnen und das sc Kommando verwenden.

sc qc srv2 zeigt die Eigenschaften des Dienstes an:
Service Information

Wie man bei START_TYPE sieht steht der Dienst auf Manuell. Damit wird er erst gestartet, wenn benötigt. Und das scheint auszubleiben auf den Servern auf denen das Problem auftritt.

Mit sc config srv2 start=auto konfiguriert man den Dienst um:
reconfigure service

Wenn man sich jetzt die Eigenschaften noch mal anschaut, sieht man dass der Dienst auf Autostart steht:
new service configuration

Anschließend muss der Server noch rebooted werden.

Seit dieser Änderung ist das Problem nicht wieder aufgetreten.

McAfee und Windows Server 2012R2 Deduplication

Es gibt ein bekanntes Problem bei der Zusammenarbeit von McAfee VirusScan Enterprise (VSE) 8.8 und höher mit der Datendeduplizierung von Windows Server 2012R2.

XP Clients die auf File Shares zugreifen, die auf einem deduplizierten Windows Server 2012R2 Volume liegen laufen in Fehlermeldungen. Die häufigste Meldung dabei lautet:

The Request is not supported.

Ich habe diesen Fehler gesehen bei PDFs, Worddateien, Exceldateien und auch bei Executables. Der genaue Wortlaut variiert dabei leicht.

Ursache für dieses Problem ist ein Registry Eintrag der von der Installation von McAfee VirusScan Enterprise gesetzt wird. Eine Deinstallation von McAfee entfernt diesen Registry Key nicht!

Man muss ihn daher selbst deaktivieren.

Dabei muss man den Key enableecp unter HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\ auf 0x0 setzen. Anschließend ist ein Reboot des Servers oder ein Restart des Server Service notwendig mit Hilfe von NET STOP SERVER && NET START SERVER.

Danach ist der Fehler weg.

Es gibt einen KB Artikel von Microsoft dazu und auch von McAfee:

http://support.microsoft.com/kb/2817216

https://kc.mcafee.com/corporate/index?page=content&id=KB77623

Nach Umstieg auf 2012R2 Domänencontroller gibt es sporadische Logonprobleme der Computerkonten (Kerberos)

Momentan wird ja fleissig migriert von Windows Server 2003 auf Windows Server 2012R2, da ja der Support in einem Jahr ausläuft.  Leider gibt es in Server 2012R2 einen Bug, der sich in einem Mixed Environment nach dem Hochstufen eines 2012R2 zum Domänencontroller oder in einem reinem 2012R2 Environment der vorher 2003er Domänencontroller enthielt, zeigt.

Dabei wird das Event 4 auf dem Domänencontroller geloggt:

Event ID: 4
Source: Kerberos
Type: Error
„The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server servername/domänenname. This indicates that the password used to encrypt the Kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (domänenname), and the client realm. Please contact your system administrator.“

Das Ganze passiert sowohl mit Clientmaschinen als auch mit Servern. Meist findet sich im Eventlog des betroffenen Computers eine enstprechende Meldung dass das Passwort für das Computerkonto geändert wurde. Das ist auch gleichzeitig die Ursache warum die Logons failen.

Die Ursache dafür liegt in den verwendeten Verschlüsselungsalgorithmen. Wenn man ein Passwort im AD setzt, dann wird dieses verschlüsselt und der dabei entstehende Hash im AD gespeichert. Da Windows Server verschiedene Algorithmen unterstützt wird dabei für jeden Algorithmus der entsprechende Hash gespeichert. Windows Server 2003 unterstützt DES und RC4. Also wird in einem reinen 2003er Environment für ein Computerkontopasswort zwei Hashs gespeichert. Wenn sich der Computer nun authentifizieren will, dann verhandeln Computer und DC einen Verschlüsselungsalgorithmus aus und vergleichen dann den Hash gegen die im AD gespeicherte Version. Stimmen beide überein, ist die Authentifizierung erfolgreich. Das ist jetzt natürlich ein bisschen vereinfacht dargestellt. Es passiert schon noch ein bisschen mehr drum herum, aber die vereinfachte Darstellung reicht um das Problem zu verstehen.

Mit Windows Server 2008 wurde zusätzlich AES als Algorithmus eingeführt. Ab diesem Zeitpunkt konnte dann – sofern ein 2008er DC natürlich im Environment steht – für jedes Passwort 3 Hashs gespeichert werden: DES, RC4 & AES. So konnte gegen einen 2008er DC mit einem „besseren“ Algorithmus authentifiziert werden als gegen einen 2003er. Der 2008er erkannte auch automatisch wenn noch kein AES Hash gespeichert war, dass er dann DES benutzen musste.

Und genau das ist das Problem im 2012R2. Aus irgendeinem Grund erkennt der 2012R2 DC sporadisch nicht wenn für einen Account kein AES Hash gespeichert ist und versucht trotzdem die Authentifizierung damit. Dabei wird dann ein generierter AES Hash gegen einen nicht im AD vorhandenen verglichen und natürlich schlägt die Authentifizierung fehl.

Glücklicherweise hat Microsoft einen Hotfix dafür bereit gestellt und Ende August auch für die Öffentlichkeit bereitgestellt:
http://support.microsoft.com/kb/2989971/en-us

KB2919355 wird wie so oft in letzter Zeit als installiert vorausgesetzt bevor man den Hotfix installieren kann.