Citrix Der Konfigurationsmanager kann nicht initialisiert werden

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.

Heute habe ich versucht die aktuelle EPLAN P8 Version 2.1 zu installieren. Scheinbar hat EPLAN das Installationsprogramm ganz neu aufgebaut, es sieht jedenfalls optisch ein wenig verändert aus. Schön ist ehrlich gesagt was anderes.

Aber ob es nun schön aussieht oder nicht ist eigentlich ganz egal, Hauptsache es funktioniert. Es gab aber Probleme bei der Installation, weil er unbedingt das FULL Package Installationsprogramm von .NET Framework 4 installiert haben will, obwohl bereits alle .NET Framework 4 Komponenten installiert waren. Ebenso alle Updates.

Falls Ihr ebenfalls das Problem habt, es liegt an folgendem Download:
- Microsoft .NET Framework 4 (eigenständiger Installer)

Einfach downloaden, installieren, PC neu starten und nochmals Updates installieren und anschließend läuft auch das Installationsprogramme vom EPLAN P8 Version 2.1 einwandfrei durch.

Heute hatten wir mal wieder ein ganz mysteriöses Problem mit unserem Citrix XenDesktop 5 Server. Bei den externen Clients, die sich bei uns in der Firma mit Ihren Desktop´s verbinden kam es immer wieder dazu, dass sich die ICA-Sitzungen nach einigen Minuten komplett eingefroren haben.

Das hat sich so geäußert, dass der virtuelle Desktop zwar für den Anwender noch sichtbar war, aber es ließ sich nicht mehr damit arbeiten bzw. anklicken. Es konnten keine Programme geschlossen werden, aber die Session war immer noch aktiv und sichtbar.

Erst wenn der Anwender das Citrix Fenster geschlossen hat und sich neu verbunden hat, so konnte er an der gleichen Stelle weiterarbeiten. Da passierte allerdings immer nach unterschiedlichen Zeitabständen, mal nach 4 Minuten, nach 10 Minuten, nach 20 Minuten usw.

Es war einfach keine Regelmäßigkeit zu erkennen. Es wurden auch nicht alle Sitzungen gleichzeitig eingefroren sondern immer abwechselnd. Ein Arbeiten war so fast nicht möglich.

Aber warum? Wir hatten am Citrix XenDesktop 5 Server nichts verändert! Weder Windows Updates noch irgendwelche Citrix Hotfixe eingespielt. Daran konnte es nicht liegen!

Dann hatten wir die Internetleitungen im Verdacht, dass diese evtl. kurz wegbrechen. Auch nicht. Dann haben wir die Netzwerkswitche untersucht, ebenfalls nicht. Auch das Neustarten des XenDesktop Servers brachte nichts, auch nicht des vorgeschalteten Citrix Access Gateways. Dort haben wir die Logfiles untersucht, aber auch hier war nichts zu finden.

Als letztes hatten wir dann versucht, die durchgeführte Änderung der Netzwerkmasken im Netzwerk wieder rückgängig zu machen, die wir vor einigen Tagen durchgeführt hatten. Aber warum sollte dies eigentlich den gewünschten Erfolg bringen, wenn es letzte Woche noch einwandfrei lief und die Änderung aber schon länger zurückliegt.

Also haben wir die Netzwerkmaske an die Clients angepaßt und siehe da, das war die Lösung. Warum auch immer muss die Netzwerkmaske des Citrix Access Gateways mit den XenDesktop Clients übereinstimmen, auch wenn die Verbindung mit verschiedenen Netzwerkmasken einwandfrei hergestellt werden konnte.

Ok, Hauptsache es läuft wieder! Solltet Ihr mal das gleiche Problem haben so schaut bitte Eure Netzwerkmasken durch – vielleicht habt Ihr ja das gleiche Problem!

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.

Es kann durchaus vorkommen, dass 2 Microsoft Exchange Server in einem Netzwerk parallel arbeiten. Dies ist z.B. in der Regel immer dann der Fall, wenn eine Migration des Exchange Servers durchgeführt wird. So wie hier in dem Beispiel wird gerade eine Migration vom Microsoft Exchange 2003 auf Microsoft Exchange 2010 durchgeführt.

Während die beiden Server parallel arbeiten müssen die Postfächer vom Exchange 2003 auf den Exchange 2010 verschoben werden. Das funktioniert relativ einfach indem einfach eine “Neue lokale Verschiebungsanforderung” für einzelne Postfach durchgeführt wird.

In der Regel klappt dies Problemlos, aber es kann durchaus auch mal zu Probleme kommen, wie Ihr hier nachfolgend erkennen könnt.

Hier kam es zu einem Fehler beim Verschieben. Die genaue Fehlermeldung lautet:

Fehler:
Fehler bei Active Directory-Vorgang mit …. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Die Zugriffsrechte reichen für diesen Vorgang nicht aus.  
Active Directory-Antwort: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Der Benutzer verfügt nicht über die erforderlichen Zugriffsrechte

Die Lösung des Problems ist relativ einfach und hat etwas mit dem AdminSDHolder zu tun. Der AdminSDHolder ist eine Funktion vom Windows Server bzw. Active Directory um die Administratoren zu schützen. Das bedeutet in Kurzform, dass jeder User, der einmal Administrator-Rechte bzw. Domain-Admin Rechte hatte, speziell geschützt wird.

Es gibt eine wunderbare Dokumentation wo Ihr alles weitere nachlesen könnt.

Um das Problem zu beseitigen müsst Ihr im AD folgenden Haken wieder setzen:

“Vererbbare Berechtigungen des übergeordneten Objektes einschließen”

Wenn dieser Haken gesetzt wird dann werden die Rechte des Benutzers wieder korrekt gesetzt und das Postfach kann Problemlos auf den neuen Exchange Server verschoben werden.

Heute standen wir vor dem Problem, dass der Citrix DataCollector nach einem automatischen Neustart nicht von der vDisk booten konnte. Der Citrix DataCollector ist für die Verteilung der eingehenden Citrix Sessions auf die verschiedenen Citrix XenApp Server notwendig.

Somit ist dieser Citrix Server ein zentrales Instrument, denn ohne diesen Server werden neue Anfragen nicht mehr entgegen genommen und es werden keine neuen Citrix Verbindungen aufgebaut. Dies nur nebenbei zur Info.

Das eigentliche Problem war allerdings, dass der Citrix Provisioning Server die vDisk, die dem DataCollector zugeordnet war, als gelockt gekennzeichnet war. Warum auch immer?!

Die genaue Fehlermeldung lautet:

vDisk is locked. 0xffff8017

Einen erkennbaren Grund dafür gab es allerdings nicht. Der Access Mode stand auf “Standard Image (multi-device, read-only access)” und nicht auf “Private“, also völlig korrekt.

Folgendes haben wir dann unternommen, dass der Citrix DataCollector Server wieder von der vDisk starten konnte.

• Abgleich des vDisk Stores zwischen den beiden Citrix Provisioning-Servern.
• Erneutes kopieren der vDisk von einem Provisioning Server zum anderen
• Abmelden aller User der Citrix-Farm
• Entfernen des Lock´s per “Manage Lock´s” über die Provisioning Console
• Neustart des Citrix Servers

Nun konnte der Citrix Server die vDisk wieder einwandfrei einbinden und von der vDisk starten. Warum der Fehler aufgetreten ist, ist allerdings noch unklar. Laut diverser Berichte anderer User scheint dieses ein generelles Problem des Provisioning-Servers 6.1 sein. Wir hoffen ein ein baldiges Hotfix!

Wer Probleme hat den aktuellen Citrix Receiver zu installieren, für den könnten dieser Beitrag interessant sein. Wir hatten bei der Installation des Citrix Enterprise Receivers 3.2 und 3.3 das Problem, dass wir nachfolgende Fehlermeldung bei der Installation erhielten:

oder auch

Wir haben lange nach einer Lösung gesucht und sind letztendlich darauf gestoßen, dass es an der Installation eines Mozilla Firefox gelegen hat. Aus irgendwelchen Gründen kann es dann dazu kommen, dass sich der aktuelle Citrix Receiver nicht installieren läßt.

Folgendes haben wir durchgeführt:

• Deinstallation Mozilla Firefox (Falls der Firefox nicht installiert ist kann es helfen, diesen in der aktuellen Version erneut zu installieren und danach gleich wieder zu deinstallieren.
• Deinstallation aller Citrix Clients
• Löschung aller Registry Einträge des Firefox und der Citrix Receiver
• Neustart des PC´s
• Erneute Installation des Citrix Receivers

Nun sollte sich der Citrix Receiver einwandfrei installieren lassen.

Beim Test der aktuellen Symantec Backup Exec 2012 Version mit SP2 ergab sich beim Sichern von Dateien, Ordnern oder auch Hyper-V Hosts das Problem, dass es zu Fehlermeldungen kam.

Endgültiger Fehler: 0xe0008526 – Backup Exec konnte keine Microsoft Volume Shadow Copy Services (VSS) Software- oder Hardware-Snapshot-Technologie für diesen Auftrag finden. Wählen Sie eine gültige VSS-Snapshot-Technologie für den Zielcomputer.
Endgültige Fehlerkategorie: Systemfehler

Zusätzliche Informationen zu diesem Fehler finden Sie unter der Verknüpfung V-79-57344-34086
V-79-57344-34086 – Snapshot: Initialisierungsfehler auf: “VRTSRV::\\Server\Hyper-V?Virtual?Machine\Hyper-V-Name”. Snapshot: Microsoft Volume Shadow Copy Service (VSS).

Die Hyper-V Hosts konnten überhaupt nicht gesichert werden, die Dateien und Ordner hingegen wurden gesichert, allerdings stand die Fehlermeldung ebenfalls im Auftragsprotokoll.

Alles deutete laut Internet Rechverse auf den VSS Dienst auf dem Hyper-V Host hin, der nach der Sicherung auch immer eine entsprechende Fehlermeldung brachte. Dieses konnte ich auf dem Hyper-V Server mit dem Befehl

vssadmin list writers

nachvollziehen. Der Status stand auf [9] Fehler. Aber es war überhaupt nicht klar woran es lag. Scheinbar gibt es Probleme mit dem Microsoft Volume Shadow Copy Service. Aber der Hyper-V Host lief einwandfrei, auch ein Neustart brachte keine Besserung, obwohl dies laut Internet Foren Besserung bringen sollte.

Dann habe ich zufällig im Internet gelesen, dass es am VSS Provider liegen kann. Da wir eine Dell Equallogic PS6100 als Storage einsetzen und nicht den Standard iSCSI Treiber von Microsoft sondern das HIT Kit von Dell, könnte es auch daran liegen. Per Befehl

vssadmin list providers

kann man sich anzeigen lassen, welche Volume Shadow Provider auf dem Hyper-V Host aktiv sind. In diesem Fall sah es so aus:

In den Backup-Jobs hatte ich aber im Backup-Exec explizit angegeben, dass der Microsoft Software Shadow Copy Provider” verwendet werden soll und nicht der Dell Equallogic VSS HW Provider.

Dann habe ich gelesen, dass es Besserung bringt, wenn dieser VSS Provider von Dell deinstalliert wird. Er hängt zusammen mit dem Dell Autosnap Manager, der im Hit Kit enthalten ist und standardmäßig mitinstalliert wird. Da ich diesen Autosnap Manager aber gar nicht nutze, habe ich den entsprechend deinstalliert und den Server anschließend einmal neu durchgestartet.

Dann habe ich den Backup Job im Backup Exec 2012 nochmals neu erstellt, damit er sich auch wirklich alle Einstellungen neu der zu sichernden Maschine neu zieht und siehe da, der Job läuft nun einwandfrei und ohne Fehler durch. Sowohl die Hyper-V Hosts als auch Dateien & Ordnersicherungen funktionieren einwandfrei.

Wir haben heute und in den letzten Tagen immer mal wieder Probleme gehabt, dass ein Windows 2003 Small Business Server Nachts den DHCP Server Dienst von alleine beendet hat. Ein Grund war nicht wirklich ersichtlich, denn es hat sich in dem Netzwerk überhaupt nichts verändert. Trotzdem stand im Ereignisprotokoll immer folgende Fehlermeldung:

Die Fehlermeldung lautet:

Unter der IP-Adresse war tatsächlich ein Router zu erreichen, allerdings lief der schon seit 2 Jahren unverändert. Warum der Server 2003 diesen nun anmeckert ist nicht ganz klar. Ich habe danach den Router vom Netz genommen, den Server Dienst und auch den ganzen Server neu gestartet, trotzdem die gleiche Meldung. Obwohl unter der angegebenen IP nun kein Gerät mehr erreichbar war.

Die Lösung sieht dann wie folgt aus. In der Registry muss im Pfad

ein neuer DWord-Schlüssel mit dem Namen

angelegt werden und ihm der Wert 1 zugewiesen werden. Danach sucht der DHCP-Server nicht nach weiteren DHCP-Servern im Netzwerk und startet seinen eigenen DHCP-Serverdienst wieder problemlos. Ob und wie lange dieser Registry Key nun bestehen bleiben soll, muss jeder für sich selber entscheiden. Ich lasse ihn erst einmal bestehen und schaue mir an, wie sich der Server in den nächsten Tagen verhält.

Bei der Durchsicht eines Ereignisprotokolls ist mir folgender Fehler aufgefallen: Dieser Fehler trat in unregelmäßigen Abständen immer wieder auf. Scheinbar hat der Fehler etwas mit der Windows Aktivierung zu tun. In diesem Fall war es ein Windows Server 2012 R2, der aber in den Computereigenschaften als “aktiviert” angezeigt wurde. Mit dem Befehl “slmgr /dlv” konnte ...

Beim Restore eines Microsoft Exchange 2010 Servers bin ich auf das Problem gestoßen, dass sich teilweise die Exchange Datenbanken nicht einbinden ließen bzw. sie wurden nach dem Restore bzw. einem Neustart nicht automatisch eingebunden. Eine manuelle Einbindung brachte dann folgende Fehlermeldung: Zunächst habe ich vermutet, dass die Datenbank durch das Backup Programm “Symantec Backup Exec” ...

Wir haben ja schon einmal über Probleme beim Windows Update beim Windows 10 Pro berichtet und haben heute eine Ergänzung vorzunehmen, da bei vielen Windows 10 Anwendern nicht nur die Windows Update Fehlermeldung 0x80070057 erscheint, sondern auch 0x8024402c. Der Fehler 0x8024402c ist im ReportEvents.log im Verzeichnis C:\Windows\SoftwareDistribution zu erkennen nachdem das Windows Update mit der ...

Wer ein Nokia Lumia 930 oder ein sonstiges Windows Mobile Phone nutzt, steht teilweise bei der Anbindung an einen Microsoft Exchange Server (Exchange 2007, 2010 oder 2013) vor dem Problem, dass er folgende Fehlermeldung nach der Einrichtung des E-Mail Abrufs über Active Sync erhält: Meldung 1: Fehler beim Synchronisieren. Das Sicherheitszertifikat auf dem Server ist ...

Ich habe schon in 2 anderen Beiträgen (Fehlermeldung 0x800F0906 bei Installation vom .NET Framework 3.5 unter Windows 8) (.Net Framework 3.5 Installation unter Windows Server 2012 R2 (0X800F0906) über den NetFx3 (.Net Framework 3) berichtet und möchte heute weitere Informationen hinzufügen, da ich bei der Installation eines Microsoft SQL Servers 2012 SP1 auf einem Windows Server ...

Wir haben aktuell einen WSUS 4.0 (Windows Service Update Server) auf einem Windows Server 2012 R2 im Einsatz, der seine tägliche Arbeit eigentlich einwandfrei verrichtet. Leider zeigt er bei längeren Abfragen immer folgende Fehlermeldung an: Die Ursache dafür war nicht so einfach zu finden. Nachdem ich dann per PowerShell Befehl versucht habe, die WSUS Serverbereinigung ...

Im Ereignisprotokolls eines Windows 7 PC´s trat immer wieder folgender Fehlermeldung auf: Der Grund dafür war auf den ersten Blick nicht ersichtlich. Erst nach einiger Recherche im Internet konnten wir eine Möglichkeit finden, diesen Fehler auszuschalten. Dies haben wir wie folgt durchgeführt: Danach war der Fehler verschwunden.

Heute wollte ich nur mal kurz von meinem ersten Blue Screen unter Windows 10 Pro (Technical Preview) berichten. Wie bei vielen anderen Dingen hat Microsoft auch bei Windows 10 das Aussehen des BlueScreens geändert. Auf jeden Fall sieht es ein wenig freundlicher aus als bisher!

Wir haben heute das Update von einem PC mit der Version “Windows 10 Pro Technical Preview Evaluierungskopie Build 9926” auf die kürzlich offiziell erschienene Vollversion “Windows 10 Professional”. Dazu haben wir uns das 5,9GB große ISO Image von Microsoft heruntergeladen und die SETUP.EXE aus der ISO Datei ausgeführt. Nach einiger Zeit erschien folgendes Fenster   ...

Aktuell hatten wir bei einem Windows Server 2012 R2 Datacenter Hyper-V Server folgende Meldung im Ereignisprotokoll: Tatsächlich war es so, dass wir über die Windows Teaming Funktion 2 Stück 10GBit Intel Netzwerkkarten zu einem Team verbunden haben. Nachdem wir die Netzwerkkarten geteamt und einen Hyper-V virtuellen Switch angelegt hatten, sahen die Daten der Netzwerkkarten wie ...