Schlagwort: Server

Fehlercode 9C47 auf einem Windows Server 2008 R2 x64 beim Update auf den IE 11

Bei einer Routinekontrolle stellten wir fest, dass einer unserer virtuellen Windows Server 2008 R2 keine Windows Updates mehr einspielte.
In der Anzeige des Windows Updates standen zwei Fehlercodes:

Fehlercode 9C47
- und -
Fehlercode 80072ee2

Auch das Wiederholen der Updates brachte nichts. Löschen der Download Verzeichnisse brache auch nichts. Auch das Ausblenden des Updates für IE 11 nützte nichts.
Teilweise konnte man manuell eines der ausstehenden Updates einspielen. Beim zweiten Update kamen aber meistens wieder entsprechend gleiche Fehler.

Als Ursache würde ich jetzt das Update für den Internet Explorer 11 ausmachen. Meistens wurden diese Fehlercodes auch in anderen Artikeln im Netz bei genau diesem Update gemeldet.  Also habe ich versucht das Update manuell durchzuführen.

Dazu habe ich zuerst das IE 11 Installationspaket manuell heruntergeladen.
http://windows.microsoft.com/de-de/internet-explorer/ie-11-worldwide-languages

Der Installationsversuch meldete dann fast wie zu erwarten, dass Windows Updates ausstehen würden, die für die Installation des IE 11  Voraussetzung sind. Dazu ein Link auf diese Seite: http://support.microsoft.com/kb/2847882

Ich habe dann manuell jedes dieser Updates ausgeführt. Die ersten waren alle bereits installiert. Nur die letzten beiden fehlten, ließen sich aber problemlos installieren. Danach erfolgte ein Neustart und dann lies sich auch der IE 11 mit dem heruntergeladenen Installationsprogramm installieren und danach funktionierte auch Windows Update wieder korrekt und installierte die verbleibenden ausstehenden Updates.

 

Auch bei haben nun die virtuellen Zeiten angefangen…

Unsere Firmeninfrastruktur ist bisher auf 3 Server verteilt. Die Server selbst sind noch so richtige Siemens Hardware, oder vielleicht sollte man sagen Heavyware. Wenn die einem auf den Fuß fallen, dann schade um den Fuß ;-):

  • Ein Siemens Primergy E200 Tower mit 2x 1Ghz PIII Prozessor (2 Kerne), 2GB RAM, mit RAID5 SCSI Subssystem.
    Mit SBS-2003 (32bit). In Betrieb seit 2004 ❗
  • Ein Siemens Primergy TX200 Rack-Server mit 2×2.4 Ghz Xeon-HT Prozessor (2 Kerne, 4 Threads), 3GB RAM, mit RAID5 SCSI Subssystem
    Mit Windows Server 2008 (32bit). In Betrieb seit 2007.
  • Ein Siemens Primergy TX200 Rack-Server mit 1×2.4 Ghz Xeon-HT Prozessor (1 Kern, 2 Theeads), 3GB RAM, mit RAID5 SCSI Subssystem
    Mit Windows Server 2003 R2 (32bit). In Betrieb seit 2007.

Im Winter kann man die drei auch locker als Heizung missbrauchen. Im Sommer muss eine Klimanlage den Serverraum auf maximal 23 Grad halten.

Die drei werden nun durch virtualisierte Server ersetzt. Der neue Host ist ein Dell T310, mit einem Xeon X3470 Prozessor 2,93GHz (4, Kerne, 8 Threads), dazu 24GB RAM und ein RAID5-SATA Subsystem.

Das Host und die Guest Systems sind einheitlich Windows Server 2008 R2 mit 64bit. Das Ganze läuft auf Hyper-V.
Umziehen bzw. ersetzt werden müssen nun Exchange, 3 SQL-Server, TFS-2010, ein Sharepoint Server, Sage-Office-Line, ein zusätzlicher Mailserver, ein Antivirensystem, ein File- und Druckerserver, der PDC und ein ganzer Haufen anderer kleiner andere Dienste.

… und da stecke ich nun mitten drin, bzw. bin schon ziemlich weit durch.

Eventlog Einträge mit der Ereigniskennung 675 im Sicherheit Ereignisprotokoll

Auf meinem Windows Server 2003 R2 haben sich in der letzten Zeit Fehlereinträge im Eventlog für die Sicherheit angehäuft. Und das bis zu 200 Einträge und mehr täglich.

Bei der Analyse stieß ich hauptsächlich auf die Ereigniskennung 675 mit dem Fehlercode 0x19. Meistens traten diese Eventlog Einträge im Viererpack auf, immer wenn ein Benutzer sich mit seinem PC im Netz angemeldet hat. Jeweils erschienen dann Einträge für den PC und den Benutzer, wie die nachfolgenden Beispiele beiden Beispiele aus dem Ereignisprotokoll meines Servers zeigen:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:33
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: COMPUTER$
  Benutzerkennung: DOMAIN\COMPUTER$
  Dienstname: krbtgt/domain.loc
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

sowie:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:52
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: Martin
  Benutzerkennung: DOMAIN\Martin
  Dienstname: krbtgt/DOMAIN
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

Nach einiger Recherche kam ich dahinter, dass dies nur Arbeitsplätze betraf, die Windows Vista oder Windows 7 einsetzten. Rechner mit Windows XP oder Windows 2003 Server tauchten hier nie auf.

Ein wenig weiteres Forschen brachte mich dann auf die Ursache:

Diese Event Id wird ausgegeben wenn, der Domänencontroller den Kerberos-Authentifizierungsversuch eines Rechners nicht versteht. Das nur Windows Vista und Windows 7 Rechner als Verursacher auftauchen liegt daran, dass mit Windows Vista AES (Advanced Encryption Standard) als Verschlüsselungsverfahren von den Clients bevorzugt wird.
Leider kennt aber der Windows 2003 Domänen-Controller dieses Verfahren noch nicht. Weil es aber einen Fallback auf das RC4-HMAC Verfahren gibt merkt der Anwender nichts davon.

Windows Systeme unterstützen die folgenden Verschlüsselungsverfahren für Kerberos:

  • DES-CBC-CRC (Registrycode 0x1)
  • DES-CBC-MD5 (Registrycode 0x3)
  • RC4-HMAC (Registrycode 0x17)
  • AES (Registrycode 0x12) Wird seit Windows Server 2008 unterstützt (d.h. auch Vista und Windows 7)

Die Standard Preauthentifizierung erfolgt bei Windows 2000, Windows Server 2003, Windows XP immer RC4-HMAC.

Die Lösung ist ein kleiner Workaround in dem man einfach dem Vista oder Windows 7 Rechner mitteilt er soll doch einfach auch die RC4-HMAC Verschlüsselung wählen. Das verhindert dann die Nutzung von AES  und die Fehler sind weg, die durch den vergeblichen AES Anmeldeversuch entstehen.
Das erreicht man in dem man den Code 0x17 (siehe Aufzählung oben) für den DefaultEncryptionType einträgt. Nachfolgend der entsprechende Auszug aus der REG-Datei, die ich auf die Clients verteilt habe.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"DefaultEncryptionType"=dword:00000017

Oder in anderen Worten gesagt:

  • Man startet Regedit an den betroffenen Clients
  • Man wählt den Ast HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Parameters
  • Dort erzeugt man einen DWORD Wert mit Namen DefaultEncryptionType
  • In diesen Wert setzt man 0x17 (bzw. 23 dezimal) ein

Nun ist Ruhe mit diesem Fehler 🙂

Weitere Links zum Thema Kerberos hier:
http://technet.microsoft.com/en-us/library/cc738673(WS.10).aspx
http://tools.ietf.org/html/rfc4757

Wie bekommt man den Servernamen auf den Anmeldeschirm eines Windows Servers?

Ich habe in unserem Serverraum 4 Server herumstehen. Natürlich nur einen Bildschirm mit einer elektronischen Maus-, Tastatur- und Bildschirmumschaltung. Leider liegt das alles so, dass ich den Umschalter nie im Blick habe und so rätsele ich jedesmal, auf welchen der 4 Server meldest Du Dich eigentlich jetzt an (wenn es mal direkt sein muss und nicht über einen Remotedesktop). Oft genug erwische ich den falschen Server.

Wie bekommt man nun also am Besten den Anmeldenamen des Servers in den Logonscreen?

Die Gina haken, habe ich keine Lust… und irgendwas muss ja auch mit den Bordmitteln gehen.
Etwas googlen und die direkte Suche nach allen Registry Einträgen die es für WinLogon gibt, brachten die erwünschte Info:

Unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon wird einfach ein neuer Texteintrag mit dem Namen Welcome erzeugt. Dort nun den Servernamen eingetragen z.b. als * SVR-02 * und schon steht in der Überschrift des Anmeldebildschirmes die Info, die ich manchmal so sehr vermisst habe.