Bei der Installation des Service Pack 1 (SP1) auf einem Windows Server 2008 R2 habe ich die Fehlermeldung “Installation war nicht erfolgreich- Unbekannter Fehler: Fehler 0×80041002″ erhalten.

Warum diese Fehlermeldung allerdings erscheint war mir völlig unklar, weil es sich bei der Maschine um einen virtuellen Server handelt und völlig identisch mit einem weiteren Server ist, bei dem die Installation des Service Pack 1 ohne Probleme durchlief.

Nach einiger Recherche im Internet war klar, dass dieses Problem schon mehrere User hatten. Eine wirklich Ursache bzw. Lösung konnte ich aber nicht finden. Auch das Herunterladen diverser Microsoft Updates (KB2617858, KB2465990, KB2492536, KB982293, KB974930) brachte keine Besserung.

Allerdings wurde mir beim Lesen eigentlich immer klarer, dass es sich um ein WMI (Windows Management Instrumentation) Problem handelt. Nach ungefähr 8 Stunden, die ich mit Versuchen, Test´s und Internet Recherche verbracht habe, konnte ich die Lösung finden.

Scheinbar ist die WMI Repository defekt, warum auch immer. Aber ich konnte auf einer Website die Lösung gefunden, um die WMI Repository (How Do i Rebuild a Corrupt WMI Repository) neu zu erstellen.

Zur Sicherheit poste ich hier nachfolgend nochmals den Inhalt des Batch-Files, welches Ihr ausführen müsst, wenn Ihr das gleiche Problem habt. Ich möchte allerdings darauf hinweisen dass ich keine Garantie dafür übernehme, falls es durch das Script zu weiteren bzw. anderen Problemen kommt.

net stop winmgmt
c:
cd %systemroot%\system32\wbem
rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in (‘dir /b /s *.dll’) do regsvr32 /s %%s
for /f %%s in (‘dir /b *.mof’) do mofcomp %%s
for /f %%s in (‘dir /b *.mfl’) do mofcomp %%s
echo DONE reboot
pause

Nachdem das Script durchgelaufen ist müsst Ihr auf jeden Fall den PC oder Server neu starten und anschließend sollte die Installation des Service Pack 1 auf jeden Fall funktionieren. Dieser Trick funktioniert übrigens bei Windows 7 ebenso.

Ähnliche Beiträge:

1. Windows 7 Service Pack 1 (SP1) Installation (KB976932)
2. Windows 8 – Fehler bei der Installation – HAL_INITIALIZATION_FAILED
3. Stop-Fehler “0x0000007F” Update für Windows 7 Service Pack 1 (KB2502285)

Microsoft hat ein Update für Windows 7 und den Windows Server 2008 R2 veröffentlicht. Dieses Update behebt den Fehler STOP: 0x0000003B beim Herunterfahren der angegebenen Systeme.

Zu dem Fehler kann es kommen wenn unter diesen Betriebssystemen virtuelle WiFi Adapter erzeugt werden und diese mit dem Netzwerk verbunden werden.

Das Update trägt die Nummer KB2624668 und Ihr müsst Euren PC oder Server nach der Installation neu starten, damit das Update aktiv wird.

Ihr könnt Euch das Update hier nachfolgend downloaden:
-  Windows Update für Fehler STOP: 0x0000003B (KB2624668)

Ähnliche Beiträge:

1. Stop-Fehler “0x0000007F” Update für Windows 7 Service Pack 1 (KB2502285)
2. Fehler in Registrierungswerten bei 64-Bit Versionen von Windows 7 (KB2603229)
3. Fehler Code 8024402C beim Windows Update

Microsoft hat soeben diverse Windows Updates und Sicherheitsupdates für den Januar 2012 veröffentlicht. Es handelt sich hierbei um folgende Updates:

• KB905866 - Update für den Junk E-Mail Filter für Windows Mail
• KB2631813 – Sicherheitsupdate für Windows Vista, Windows 7, Server 2003 und 2008 und 2008 R2.
• KB2598479 - Sicherheitsupdate für Windows Vista, Windows 7, Server 2003 und 2008 und 2008 R2.
• KB2603381 - Sicherheitsupdate für Windows XP und Server 2003
• KB2585542 - Sicherheitsupdate für Windows XP, Vista, Windows 7, Server 2003, 2008 und 2008 R2.
• KB2584146 - Sicherheitsupdate für Windows XP, Vista, Windows 7, Server 2003, 2008 und 2008 R2.

 Sobald Microsoft weiterführende Informationen veröffentlich hat werden wir diese nachreichen!

Ähnliche Beiträge:

1. ISO-Datei mit allen Updates vom November 2011
2. Januar 2011 ISO-Abbild der Windows Updates (KB913086)
3. Beta Version vom Windows 8 und Office 15 erscheinen im Januar 2012

Teaming von Netzwerkadaptern – was ist das überhaupt. Unter Teaming (Fehlertolerante Einrichtung) versteht man die Zusammenfassung von physikalischen Netzwerkkarten zu einer logischen Netzwerkkarte (NIC).

Dies ist wichtig um eine Redundanz zu schaffen und den Datendurchsatz zu erhöhen. Ich kann 2, 3 oder auch noch weitere Netzwerkkarten per Teaming zu einem Team zusammenschalten. Fällt dann eine Netzwerkkarte aus, so läuft die zweite Netzwerkkarte problemlos weiter. Im schlimmsten Fall wird es zu einer Ausfallzeit von einem Ping kommen, in der Regel läuft es aber ohne Unterbrechung weiter.

Der 2. Vorteil ist die Erhöhung des Datendurchsatzes. Somit erziele ich durch den Zusammenschluss von mehreren Netzwerkkarten mit jeweils 1 GBit das vielfache davon.

Nun stand ich aber vor dem Problem – wie wird das überhaupt eingerichtet. Ich muss doch entweder dem Server oder auch dem Netzwerkswitch irgendwie die entsprechende Konfiguration mitgeben. Nachfolgend möchte ich hier erläutern, wie es bei einem Dell PowerEdge R710 mit 4 internen Broadcom Netzwerkkarten funktioniert, die an einem PowerConnect 6248P angeschlossen werden.

Eigentlich ist es ganz einfach. Zunächst müsst Ihr Euch überlegen wie viele Netzwerkadapter Ihr zu einem Team zusammenschließen wollt. Danach müsst Ihr auf dem Server, in meinem Fall ein Dell R710 mit Windows Server 2008 R2 SP1, das entsprechende Konfigurationsprogramm für Eure Netzwerkadapter installieren.

Da in unserem Dell Server Netzwerkkarten von Typ “Broadcom BCM5709C” verbaut sind habe ich das komplette Installationspaket von Broadcom installiert, inclusive der “Broadcom Advanced Control Suite 3″, kurz “BACS“.

Auf dem Bild könnt Ihr schon sehen dass ich ein neues “Team” angelegt habe mit den Namen “Team1“. Dies geht einfach indem Ihr unten auf “Team Management” klickt und dann oben im Menü auf “Teams” und “Create a Team“.

Ich würde Euch den “Expert Mode” enpfehlen und dann folgende Einstellungen wählen. Zunächst müsst Ihr den Team Namen festlegen, so wird später Eure virtuelle Nezuwerkkarte benannt. Danach den “Team Typ“, in meinem Fall also “Smart Load Balancing and Failover“.

Ihr könnt auch noch “Generic Trunking (FEC/GEC)/802.3ad-Draft Static“, “Link Aggregation (802.3ad)” und “SLD (Auto-Fallback Disable)” als Typ auswählen, auf dieses Arten des Teamings möchte ich hier jetzt aber nicht weiter eingeben.

Mir reicht die normale Redundanz und die Erhöhung des Traffics aus und deswegen habe ich “Smart Load Balancing and Failover” ausgewählt.

Selbstverständlich müsst Ihr dann noch die gewünschten Netzwerkkarten auswählen, die zu dem Team gehören und dann die Einstellungen entsprechend speichern. Nun wird ein neuer, virtueller Netzwerkadapter mit der MAC-Adresse des 1. Netzwerkadapters angelegt, der den gewählten Namen erhält. Dies könnt Ihr hier nachfolgend gut erkennen.

Das Team erhält den Gerätenamen “BASP Virtual Adapter” und Ihr könnt dieser virtuellen Netzwerkkarte nun eine IP-Adresse geben. Da ich in meinem Team 2 Adapter ausgewählt habe, erscheinen nach außen nun beide Adapter unter der einen IP-Adresse.

Änderungen an den Dell PowerConnect 6248P Switchen müssen dann nicht vorgenommen werden, davon habe ich mich persönlich vom Dell Service überzeugen lassen.

Auch unsere Test´s haben gezeigt, dass es so einwandfrei funktioniert. Wenn beide Adapter gleichzeitig arbeiten erreichen wie einen Datendurchsatz beim normalen Kopieren über das Netzwerk von bis zu 160MB/Sekunde. Ziehen wir einen Netzwerkadapter ab so bricht der Kopiervorgang nicht ab, aber die Datendurchsatzrate verringert sich auf ca. 80MB/Sekunde.

Somit ist das Teaming recht einfach einzurichten, wenn man weiß wie es funktioniert!

Ähnliche Beiträge:

1. Windows Server 2008 R2 nach Installation mit 100% CPU Auslastung
2. Lastverteilung auf 2 Netzwerkkarten per Registry Änderung
3. VMWare VMDK umwandeln in Hyper-V VHD-Dateien

Vor einigen Monaten habe ich schon einmal darüber berichtet (Citrix XenApp Probleme mit dem SP1 für Windows Server 2008 R2), dass es scheinbar noch massive Probleme gibt, wenn man auf einem bestehenden Citrix XenApp6 Server das Service Pack 1 für den Windows Server 2008 R2 installiert.

Dieses scheint nun endlich vorbei zu sein. Nachfolgend habe ich Euch mal zusammengeschrieben wie es zumindest mir gelungen ist, das SP1, den Internet Explorer 9  (IE9) und auch alle sonstigen Windows Updates einzuspielen, ohne das der XenApp Server Schaden nimmt.

Wichtig ist natürlich dass Ihr unbedingt vorher eine aktuelle Datensicherung des Servers habt, damit Ihr im Problemfall das System wieder in den Ausgangszustand zurückversetzen könnt. Bei mir war dies kein Problem, da die Server virtuell laufen und ich einfach eine Kopie der virtuelle Maschine angelegt habe.

Zunächst habe ich folgende Windows Updates installiert:

• Windows6.1-KB975777-x64.msu
• Neustart des Servers
• Windows6.1-KB979530-x64.msu
• Windows6.1-KB980663-x64.msu
• Windows6.1-KB2265716-x64.msu
• Windows6.1-KB2383928-x64.msu
• Windows6.1-KB2388142-x64.msu
• Windows6.1-KB2444328-v2-x64.msu
• Windows6.1-KB2465772-x64.msu
• Neustart des Servers

• XA600W2K8R2X64010.msp
• XA600W2K8R2X64012.msp
• XA600W2K8R2X64017.msp
• Neustart des Servers
• XA600W2K8R2X64021.msp
• XA600W2K8R2X64026.msp
• XA600W2K8R2X64029.msp
• Neustart des Servers
• XA600W2K8R2X64046.msp
• XA600W2K8R2X64060.msp
• XA600W2K8R2X64062.msp
• Neustart des Servers
• XA600W2K8R2X64068.msp
• Neustart des Servers

Ähnliche Beiträge:

1. Citrix XenApp Probleme mit dem SP1 für Windows Server 2008 R2
2. Inconsistent server host ID – Citrix XenApp6 Lizenzserver Probleme
3. Citrix Event ID 9017 im Ereignisprotokoll eines XenApp Servers

Microsoft hat heute Abend (29.12.2011), ich habe bereits darüber berichtet (Microsoft bringt außerplanmässiges kritisches Sicherheitsupdate für Windows Systeme), einige kritische Sicherheitsupdates für .Net Framework Komponenten veröffentlicht.

Durch vorhandene Sicherheitslücken könnte ein Angreifer die Kontrolle über Windows Systeme erlangen. Deswegen empfiehlt Microsoft dringend die Installation der folgendes Updates:

• Sicherheitsupdate für Microsoft .NET Framework 1.1 Service Pack 1 unter Windows XP, Windows Server 2003 (64 Bit), Windows Vista, Windows Server 2008 (KB2656353)
• Sicherheitsupdate für Microsoft .NET Framework 3.5.1 unter Windows 7 Service Pack 1, Windows Server 2008 R2 SP1 (KB2656356)
• Sicherheitsupdate für Microsoft .NET Framework 2.0 Service Pack 2 unter Windows Server 2003, Windows XP (KB2656352)
• Sicherheitsupdate für Microsoft .NET Framework 3.5.1 unter Windows 7, Windows Server 2008 R2 (KB2656355)
• Sicherheitsupdate für Microsoft .NET Framework 4 (KB2656351)
• Sicherheitsupdate für Microsoft .NET Framework 2.0 Service Pack 2 unter Windows Vista SP2, Windows Server 2008 SP2 (KB2656362)
• Sicherheitsupdate für Microsoft .NET Framework 1.1 Service Pack 1 unter Windows Server 2003 SP2 (32 Bit) (KB2656358)
• Sicherheitsupdate für Microsoft .NET Framework 3.5 Service Pack 1 unter Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 (KB2657424)

Das .NET Framework von Microsoft ist eine Software-Plattform zur Entwicklung und Ausführung von Anwendungsprogrammen. Das .NET Framework besteht aus einer umfangreichenLaufzeitumgebung und einer Sammlung von Klassenbibliotheken, Programmierschnittstellen und Dienstprogrammen. Somit können Programmierer auf sehr viele vorgefertigte Lösungen zurückgreifen ohne das Rad jedesmal neu erfinden zu müssen.

Ähnliche Beiträge:

1. Vista und Server 2008 Sicherheitsupdate für .NET Framework 3.5 (KB983587)
2. Sicherheitsupdate für .NET Framework 3.5 SP1 und .NET Framework 2.0 SP2 (KB2418241)
3. Sicherheitsupdate für .NET Framework 3.5 SP1 für Vista SP1 und Server 2008 (KB2416474)

Der Zugriff auf Profil-Verzeichnisse ist ja seit Windows Vista und Windows 7 auch für Administratoren eingeschränkt. Was unter Windows XP noch so einfach war, geht nun nicht mehr.

Standardmäßig hat auch der Administrator keine Berechtigung mehr, auf den Inhalt der Profilverzeichnisse Einblick zu nehmen. Das hat allerdings teilweise doch erhebliche Nachteile. Selbstverständlich kann man per Gruppenrichtlinie dem Administrator das Recht einräumen, ich habe bereits in meinem Beitrag “Administrator Zugriff auf .V2 Profile” darüber berichtet.

Das gilt allerdings nur dann, wenn das Profilverzeichnis nach der Einstellung der Gruppenrichtlinie erzeugt wurde. Somit löst es mein Problem nicht unbedingt.

Den Besitz von dem Profil-Verzeichnis und allen untergeordneten Dateien und Verzeichnissen zu übernehmen ist schlecht und kann das Profil des Anwenders komplett zerstören. Davon würde ich dringend abraten.

Wenn man aber doch an die Daten möchte, so gibt es ein Trick. Dieser Trick wird z.B. von allen Backup-Software Programmen genutzt, dass die Dateien in einem sogenannten Backup-Modus kopiert werden. Wir müssen uns lediglich eines Programms bedienen, welches diesen Backup-Modus beherrscht. Und da brauchen wir nicht besonders weit suchen, ROBOCOPY ist die Lösung.

Mit dem Parameter /B kopiert Robocopy die Dateien und Ordner im sogenannten “Sicherungsmodus“. Wenn Ihr nun z.B. mit folgenden Befehl arbeitet, so wird das komplette Profil des Anwenders in den Ordner \TEMP kopiert, obwohl wir eigentlich keinen Zugriff darauf haben.

ROBOCOPY C:\USERS\WINDOWSFAQ C:\TEMP\WFAQ *.* /B /E

Nun steht im Ordner C:\TEMP\WFAQ eine Kopie des gesamten Profils des Users WINDOWSFAQ und Ihr könnt Euch das Profil entsprechend anschauen, ohne dass Ihr Veränderungen am Originalprofil vorgenommen habt.

Wenn Ihr gar keine Kopie benötigt so könnt Ihr noch den Parameter “/L” anhängt, so werden lediglich die Inhalte aufgelistet, aber nicht wirklich kopiert. So erhält man den Einblick in ein Profil, ohne eine Kopie zu erstellen.

Wie ich finde eine sehr nützliche und praktische Möglichkeit mit Profilen zu arbeiten, ohne wirklich Rechte zu besitzen!

Ähnliche Beiträge:

1. Fehler beim Kopieren 0×80070021
2. Robocopy – Fehlende Rechte zum Verwalten von Überwachungsprotokollen
3. Liste der Dateinamen von Ordnern per Explorer-Kontextmenü kopieren

Ich habe vor ein paar Tagen bereits kurz darüber berichtet, wir hatten einen schlimmen Serverausfall, weil 2 Festplatten in einem Server mit Raid 5 Verbund auf einmal ausgefallen sind.

Wie die meisten vielleicht wissen, ist dies so ziemlich das schlimmste, was man sich vorstellen kann. Wenn 2 Festplatten beim Raid 5 gleichzeitig ausfallen, dann geht eigentlich gar nichts mehr. So auch bei uns, der Server bootete von alleine neu durch und konnte beim 1. Bootvorgang die Festplatteninhalte nicht mehr korrekt lesen und brach mit einer Fehlermeldung ab, da er bestimmte Bereiche der Windows-Partition nicht mehr lesen konnte.

Nach langen Telefonaten mit dem Hersteller, in diesem Fall Dell, war die Meinung des Technikers, dass alle Daten unwiderruflich verloren sind. Komischerweise waren die 2 Festplatten, die laut Raid Controller Bios ausgefallen sind, optisch nicht als defekt gekennzeichnet. Nur eine der beiden leuchtete “Orange”, was auf einen Defekt hindeutete. Dies haben wir dem Dell Support dann auch so mitgeteilt und diverse Test´s mit dem System gefahren.

Herausgekommen ist letztendlich, dass die Firmware des Dell Raid Perc 5i Controllers zu alt war, dass sinnvolle Logfiles erzeugt wurden. Ok, ich gebe zu, ich habe die Firmware des Raid Controllers in der letzten Zeit nicht upgedatet, aber das war mit bei dem Fileserver einfach zu gefährlich und was soll ich Änderungen an einem System einspielen, was einwandfrei läuft.

Der Dell Support teilte mir ebenfalls mit, dass die Firmware der Festplatten nicht aktuell sind. Das war mir allerdings neu, dass auch die Firmware der Festplatten upzudaten sind. Laut Servicemitarbeiter soll es Timing Probleme bei der 2. Platte gegeben haben, sodass diese ebenfalls aus dem Raid Verbund geflogen ist und es somit zum Datenverlust gekommen ist.

Aber was tun – selbstverständlich hatten wir ein tagesaktuelles Backup und dieses konnte sofort aktiviert werden. Somit war kein Datenverlust entstanden, die Mitarbeiter hatten zwar eine Beeinträchtigung von 2-3 Stunden, aber mehr oder weniger kein größeres Problem. Trotzdem wollte ich mich mit der Aussage, dass die Daten unwiderruflich weg sind, nicht abgeben.

Ein Firmware Update des PERC 5i Controllers sollte ich durchführen. Das habe ich aber nicht gemacht, da die Wahrscheinlichkeit, dass dann hinterher gar nichts mehr funktioniert, sehr hoch war. Somit hab ich versucht, über die Windows Wiederherstellungskonsole an die Daten zu kommen. Aber das war gar nicht so einfach, denn dadurch, dass es ein Raid Controller ist, konnte die normale Windows Server 2003 R2 DVD gar nicht auf die Boot Partition zugreifen, bevor nicht der richtige Raid Controller Treiber geladen wurde. Also beim Bootvorgang F6 gedrückt und dann wollte er den Treiber von Diskette nachladen. Der Treiber ist eigentlich von der Dell Support Homepage herunterzuladen – nur leider dieser nicht. Der Download brach immer wieder mit einem Fehler ab. Danach haben wir den Telefonsupport kontaktiert mit der Bitte, uns den Treiber per E-Mail zuzusenden. Kurz danach kam die Mail, allerdings als .EXE Datei. Diese sperrte natürlich unser Outlook, somit keine Change daran zu kommen.

Ein erneuter Anruf bei Dell, nun leider außerhalb der Geschäftszeiten…. ärgerlich. Aber wir haben dann doch noch jemand ans Telefon bekommen und nach dem 3 oder 4 Telefonat haben wir dann endlich den Treiber erhalten. Das hat allerdings insgesamt ca. 3 Stunden gedauert.

Dann haben wir den Treiber eingebunden und wir konnten dann die Reparaturkonsole mit “R” aufrufen. Danach kam die Abfrage nach dem lokalen Administrator Kennwort. Aber leider nahm das System das korrekte Kennwort nicht mehr an. Wahrscheinlich war auch die Benutzerdatenbank defekt, somit mussten wir das Kennwort irgendwie zurücksetzen.

Dafür gibt es ja diverse Linux CD´s – wir haben es mal mit “Offline NT Password & Registry Editor” probiert. Wie dies genau funktioniert haben wir ja bereits im Beitrag “Administrator Kennwort zurücksetzen” genau beschrieben.

Was mich allerdings immer wieder ein wenig wundert ist, dass es allen Linux Derivaten problemlos gelingt, auf die NTFS Partitionen zuzugreifen, ohne das spezielle Treiber wie bei Windows geladen werden müssen. Auch das Zurücksetzen des Administrator Kennwortes war kein Problem. Wir haben dann aber auch noch andere Linux Versionen wie “Knoppix” und “Ubuntu” ausprobiert, auch diese konnten zumindest auf einen Teil der Startpartition zugreifen, die Datenpartition war allerdings auch hier nicht einsehbar.

Nachdem wir das Kennwort zurückgesetzt haben konnten wir die Reparaturkonsole aufrufen und haben dann ein “chkdsk /R” durchgeführt. Durch diesen Befehl mit dem Parameter “/R” werden fehlerhafte Sektoren gefunden und es werden lesbare Daten wiederhergestellt. Dieser Vorgang dauerte alleine für die Startpartition, die nur eine Größe von 12GB hatte, ca. 25 Minuten.

Nachdem CHKDSK erfolgreich durchgelaufen ist haben wir versucht erneut von der Windows Partition zu booten. Und siehe da, es funktionierte wieder. Keine Fehlermeldung beim Hochfahren, ich konnte mich als lokaler Administrator am System anmelden und alles schien eigentlich wieder einwandfrei zu funktionieren. Nachdem wir “CHKDSK /R” auch für die Datenpartition D: angewendet haben, welches übrigens gut 1 Stunde benötigte, konnten wir auch wieder auf diese Daten zugreifen.

Es waren zwar nicht mehr alle Dateien verfügbar, aber eine große Anzahl an Dateien konnten so noch gerettet werden. Das zeigt mir mal wieder dass man nicht so schnell aufgeben soll, auch wenn sogenannte “Support Experten” anderer Meinung sind und die Daten eigentlich “unwiederruflich” verloren sind.

Ähnliche Beiträge:

1. Datenrettung – Datenwiederherstellung durch Profis
2. Access based Enumeration beim Windows Server 2008 R2 aktivieren
3. Externe Festplatten günstig kaufen

Wie für Windows XP und Windows Vista gibt es auch für Windows 7 die passenden Remote Server-Verwaltungstools, auch bekannt unter dem Namen RSAT (Remote Server Administration Tools).  Mittlerweile gibt es das RSAT für Windows 7 bereits mit SP1. Den passenden Downloadlink findet Ihr am Ende des Beitrages.

Mit den Remoteserver-Verwaltungstools für Windows 7 mit SP1 können IT-Administratoren Rollen und Funktionen verwalten, die auf Remotecomputern mit Windows Server 2008 R2 mit SP1 oder Windows Server 2008 R2 installiert sind.

Bestimmte Rollen bzw. Funktionen eines Windows Server 2003 können ebenfalls Remote mithilfe der Remoteserver-Verwaltungstools für Windows 7 mit SP1 verwaltet werden, allerdings steht die Server Core-Installation unter Windows Server 2003 nicht zur Verfügung.

Ich persönlich nutze die RSAT Tools in erster Linie zum Bearbeiten des Active Directories, des DNS und DHCP-Server.

Ihr könnt Euch die aktuellen RSAT Tools hier nachfolgend downloaden!
- RSAT Remote Verwaltungstools Download

Ähnliche Beiträge:

1. Remoteserver-Verwaltungstools für Windows 7 mit SP1
2. Windows 7 Remoteserver Verwaltungstool Download
3. Active Directory Sicherheitsupdate für Windows Server 2003 (KB2478953)

Heute möchte ich Euch von einem aktuellen Problem berichten, den ich mit einem Windows Server 2003 R2 hatte. Dieser dient hauptsächlich als Domänen-Controller und es liegen noch einige GB Dateien auf einer Freigabe.

Der Server macht aber seit geraumer Zeit immer wieder Probleme, hat enorm lange Antwortzeiten und zeigt im Ereignisprotokoll die Fehlermeldung (Event ID: 2020) “Der Server konnte keinen ausgelagerten Poolspeicher reservieren, da der Pool leer war.”.

Komischerweise tritt der Fehler bei dem Server immer in dem Morgenstunden auf, das zeigt jedenfalls das Ereignisprotokoll. Immer im Minutenabstand erscheint der Fehler mit der Ereigniskennung 2020.

Aber woran liegt es. Zunächst hatte ich Symantec Backup Exec im Verdacht, da es nach einiger Recherche im Internet das gleiche Problem bei anderen Anwendern auch gibt. Zahlreiche Test´s über mehrere Tage brachten allerdings wenig bis keinen Erfolg. Also kann es daran nicht liegen.

Microsoft bietet ebenfalls zahlreiche Hilfen für das Problem an. Gefunden habe ich folgende:

1.) KB822219:
Dieser Artikel trägt die Bezeichnung “Geringe Dateiserverleistung und Verzögerungen beim Arbeiten mit Dateien auf einem Dateiserver“.  Ich habe den Artikel entsprechend durchgearbeitet, leider ohne Erfolg bei mir.

2.) KB312362:
Dieser Microsoft Artikel heißt “Server is unable to allocate memory from the system paged pool” und durch Veränderungen von 2 Registry Key´s soll sich das Problem bessern. Leider war auch diese Massnahme bei uns ohne Erfolg.

3.) KB886670:
Der dritte und letzte Artikel, den ich zu dem Problem finden konnte heipt “Event 2010 is logged and your Windows Server 2003-based file servers stops responding“.  Hier könnt Ihr einen Hotfix bei Microsoft anfordern der das Problem beseitigen soll, aber auch hier kein Erfolg.

Somit blieb das Problem bestehen und eine Lösung war nicht in Sicht. Danach haben wir einen automatischen Neustart des Servers in der Nacht eingeführt, was eine teilweise Besserung ergab. Trotzdem kam der Fehler täglich immer wieder vor.

Danach haben wir auf Server die Auslagerungsdatei von Laufwerk C:, welches relativ voll war, auf D: verschoben und die Größe erhöht. Anfänglich dachten wir es hilft, aber wieder ohne Erfolg.

Die Lösung des Problems haben wir dann erst sehr viel später entdeckt, als wir uns die geöffneten Dateien des Servers mit dem Sysinternal Tool “psfile” angeschaut haben. Dort wurden immer wieder Dateien aufgelistet, die eigentlich nicht geöffnet sein sollten. Dazu kam, dass es von einem Backup-User geöffnet ist und tagsüber sollten eigentlich keine Backup-Jobs laufen.

Danach haben wir uns alle Backup-Jobs angeschaut, aber keiner lief? Aber warum waren dann die Dateien geöffnet und auch nicht immer die gleichen, sondern immer wieder andere. Irgendwo müssen dann doch Backup-Jobs laufen. Da wir einen Teil der Server mit Robocopy über die Aufgabenplanung sichern, konnten wir sehr schnell herausfinden, dass wirklich keine Jobs aktiv waren. Erst nachdem wir uns den Taskmanager des Servers, auf dem die eigentlichen Robocopy-Jobs laufen, näher angeschaut haben, so haben wie festgestellt, dass zahlreiche Backup-Jobs laut Taskmanager noch liefen, obwohl die Aufgabenplanung dies anders angezeigt.

Nachdem wir die Jobs per Task beenden abgebrochen haben, war der Fehler 2020 beseitigt. Scheinbar haben die hängenden Jobs permanent den Server so ausgelastet, dass kein freier Poolspeicher mehr vorhanden war.

Warum die Jobs hängengeblieben sind ist mir allerdings noch nicht ganz klar, denn die Jobs warem im Aufgabenplaner so eingestellt, dass sie nach maximal 8 Stunden auf jeden Fall beendet werden.

Dies sollte eine hoffentlich hilfreiche Auflistung für Anwender sein, die ebenfalls das Probleme 2020 haben.

Ähnliche Beiträge:

1. Windows Update Error 80070490 beseitigen
2. Robocopy – Fehlende Rechte zum Verwalten von Überwachungsprotokollen
3. Aufgabenplanung Ereignis-ID Kennung Fehler 101