Shnu 10 Geschrieben 2. Dezember 2016 Melden Teilen Geschrieben 2. Dezember 2016 (bearbeitet) Hallo Zusammen,ich habe in unserer Umgebung aktuell Probleme mit einer langen Bootzeit einiger Server (2012 R2). Es handelt sich dabei um 3 Citrix Terminalserver (Ca. 30 Minuten Boottime), sowie einen Server der für unser ERP System (proAlpha) zuständig ist. Dieser braucht satte 2 Stunden zum hochfahren!Ich schließe ein Hardware Problem eher aus, da bisher nur diese 4 Server betroffen sind (Eventuell noch mehr, ich habe bisher nicht alle Server unserer Umgebung neugestartet). Definitiv sind aber nicht alle Server betroffen, da ich zum Testen mehrere Server neugestartet habe und dort der Fehler bisher nicht auftauchte. Hier startet das System in weniger als 1 Minute neu..Trotzdem sei kurz dazu gesagt, dass alle Server unter einer VMware 5.5 Umgebung auf 3 ESX Maschinen laufen. Darunter eine PowerVault MD3200. Ich hatte auch schon einen Techniker unseres Systemhauses draufgeschaltet und der konnte auch erstmal nichts ungewöhnliches feststellen, so dass wir aktuell eher von einem "Software" Problemen ausgehen. Alle betroffenen Server verhalten sich gleich: DIe Server hängen ewig beim Splash Screen fest. Dann irgendwann kommt das Anmelde fenster und danach läuft alles wie gewohnt.Wenn ich mir die Event Logs anschaue, so habe ich bei allen Servern nach dem Neustart ähnliche InformationsMeldungen die mich etwas Skeptisch machen:"Der Zugriffsverlauf in der Struktur "\SystemRoot\System32\Config\SOFTWARE" wurde gelöscht. Dabei wurden 7904480 Schlüssel aktualisiert und 488236 geänderte Seiten erstellt."Von diesen Meldungen habe ich mehrere. Wobei der Pfad wechselt. Außerdem bei dem ERP Server noch zusätzlich:"Anwendungspopup: Windows - Geringer Registrierungsspeicher: Das System hat die maximal zulässige Größe für den Systemteil der Registrierung erreicht. Weitere Speicheranforderungen werden ignoriert. "Ich habe dann mal unter C:\Windows\System32\config nachgeschaut und festgestellt das alle betroffenen Server eine recht große "Software" Datei haben.ca. 2GBAuf allen anderen Servern oder Clients wo ich nachgeschaut habe und dieses Problem nicht auftaucht, ist die Software File kleiner als 100mb.Könnte hier irgendwo auch die Ursache für die lange Bootdauer liegen? Um den Bootvorgang mal genauer zu betrachten, habe ich mit ProcessMonitor diesen auf einem der Betroffenen Server geloggt. Das Ergebnis seht Ihr im Anhang. Neugestartet habe ich den Server um 11:42 Uhr Der Server war dann ca. 12:10 wieder da. Wie man Sieht arbeitet am Anfang die smss.exe . Dann gibt es eine Riesen lücke bis 12:08 und danach geht es weiter und der Server fängt an zu booten. Was macht die smss.exe in der ganzen Zeit? Wir kommen der Ursache aber anscheinend näher. Könnt ihr mir Tipps geben wie ich nun weitermachen soll?Vielleicht bin ich auch auf den Holzweg und das Problem liegt irgendwo ganz anders.Für jede Anregung oder Vorschlag wäre ich Dankbar.liebe Grüße bearbeitet 2. Dezember 2016 von Shnu Zitieren Link zu diesem Kommentar
Sanches 22 Geschrieben 2. Dezember 2016 Melden Teilen Geschrieben 2. Dezember 2016 Moin, starten die DBs auf dem ERP-System automatisch? Welche Umgebungen werden ggf. auf dem Server autom. gestartet? Nutzt ihr APS? (Abhängig auch vom Release - ggf. die INBW?) Auf welchem RAID liegt der ERP-Server? Generell - hast du mehrere RAID Volumens für die VMs? Gruß Sebastian PS: Das ERP-System ist mir bekannt, war mal Systemtechniker ... :D Zitieren Link zu diesem Kommentar
Shnu 10 Geschrieben 2. Dezember 2016 Autor Melden Teilen Geschrieben 2. Dezember 2016 (bearbeitet) Moin, starten die DBs auf dem ERP-System automatisch? Nein, müssen manuell gestartet werden. Auf den Terminalservern läuft auch keine DB. Da du dich mit Proalpha auskennst, es handelt sich um den APS Server für proAlpha. Welche Umgebungen werden ggf. auf dem Server autom. gestartet? Soweit ich weiß, wird keine Umgebung automatisch gestartet von proAlpha. Wenn ich die Server neustarte muss ich vorher immer die Umgebung stoppen und nach dem Booten wieder starten. Nutzt ihr APS? (Abhängig auch vom Release - ggf. die INBW?) Ich bin was proAlpha angeht eher unwissend, aber wir haben einen APS Server, wenn du das meinst und INBW nutzen wir auch. Konkret, ist es auch der APS Server der so lange zum hochfahren braucht. Auf welchem RAID liegt der ERP-Server? Für die beiden proALpha Server (APS und den Datenbankserver) haben wir extra ein RAID 10 konfiguriert. Für die restlichen Server haben wir ein RAID 5. Am Raid kann es nicht liegen, da die Terminalserver auch diese Probleme haben und auf einem anderem RAID liegen. Generell - hast d u mehrere RAID Volumens für die VMs? Siehe oben. Gruß Sebastian PS: Das ERP-System ist mir bekannt, war mal Systemtechniker ... :D Oh, da hab ich ja genau den richtigen gefunden :p Wobei ich nicht sicher bin ob das Problem mit proAlpha zu tun hat. Wir haben proAlpha auch schon paar Jahre länger im Einsatz und diese Bootprobleme haben wir erst seit einigen Wochen. Zuerst fing es mit den Terminalservern an. Den APS Server startet man auch nicht so häufig neu. Dieser ist mir dann aber um die Ohren geflogen, als ich diesen in der MIttagspause neustarten musste und er dann fast 2 Stunden gebraucht hat zum hochfahren, was sonst vorher nie der fall war. Das war dann etwas supoptimal.. Habe aber natürlich schon überlegt, weshalb nur diese 4 Server betroffen sind, und die Gemeinsamkeit bzw was sie von den anderen Servern unterscheidet ist eben proAlpha. Auf den Terminalservern ist ein proAlpha Client für die User installiert, sowie Fastviewer für den Fernzugriff von proAlpha. Kann aber auch ein Zufall sein. bearbeitet 2. Dezember 2016 von Shnu Zitieren Link zu diesem Kommentar
Doso 77 Geschrieben 2. Dezember 2016 Melden Teilen Geschrieben 2. Dezember 2016 (bearbeitet) Hast du dir mal angeschaut wie die CPU und RAM Auslastung der Server nach dem Booten sich bewegt? Hast du dir mal die Größe der Auslagerungsdatei begutachtet? Wir hatten mal das Problem das ca. 10 Minuten nach dem booten die Speicherplatznutzung ein Stück stieg, dann war wieder ein paar Minuten Ruhe, dann wieder Auslastung nach oben. Das ging dann solange bis auch die Auslagerungsdatei voll war. Das passiert wenn sie Arbeitsspeicher x3 erreicht hat. Ursache bei uns war folgendes: https://blogs.technet.microsoft.com/core/2015/06/26/memory-leak-verursacht-von-dem-remote-registry-dienst-unter-windows-8-8-1-und-server-2012-2012r2/ Das habe ich nur gesehen nachdem ich eine Weile auf den Task Manager gestarrt habe, dann konnte man wirklich dabei zuschauen wie der benutzte Speicher immer weiter gestiegen ist. Muss es bei dir nicht sein, nur so eine Idee zur Fehlersuche. Auch ich hatte nicht gleich gerafft das auch Dienste in Windows Memory Leaks haben können und das man da noch ein paar Sachen mehr im Task Manager nachschauen kann. bearbeitet 2. Dezember 2016 von Doso Zitieren Link zu diesem Kommentar
massaraksch 39 Geschrieben 2. Dezember 2016 Melden Teilen Geschrieben 2. Dezember 2016 Hi, 2 GB Software-Key? Das ist 'ne Hausnummer...Was ist denn da passiert? Die Wartezeit in deinem Log kommt ja wie es aussieht bei Zugriff: RegOpenKey -> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup Schau doch mal in der Registry nach diesem Schlüssel. Vielleicht sieht man da was Ungewöhnliches. Zitieren Link zu diesem Kommentar
Squire 212 Geschrieben 3. Dezember 2016 Melden Teilen Geschrieben 3. Dezember 2016 mal ne Frage ... was wurde vorher gemacht? Wurde irgendwas geändert? DNS Einstellungen passen? Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 3. Dezember 2016 Melden Teilen Geschrieben 3. Dezember 2016 kannst du bitte mal in die lokale GPO schauen: sind die lokalen Admins bzw. der bootende Account im userright "perform volume maintenace tasks" drinnen. Falls nicht, füge diese testweise hinzu. Bei großen Datenbanken kann das Fehlen dieses Rights zu langen Bootzeiten führen. https://msdn.microsoft.com/en-us/library/ms175935.aspx Zumindest auf physikalischen Maschinen hat's bei mir geholfen. Dieses Userright erlaubt tiefgreifende Manipulationen im Filesystem, daher ist es mit Bedacht zu setzen. Steht aber auch untem im Artikel bzw. in der Policy Description. blub Zitieren Link zu diesem Kommentar
massaraksch 39 Geschrieben 4. Dezember 2016 Melden Teilen Geschrieben 4. Dezember 2016 (bearbeitet) Hi, Ergänzung wegen deiner 2 GB-Registry: Hier hatte auch mal jemand ein Problem mit einem riesigen Key: https://social.technet.microsoft.com/Forums/office/en-US/61387f4f-fd39-4b1f-a38f-2b7da230745c/problem-with-huge-registry?forum=winserver8gen Der hatte auch ein 2 GB Regfile und 22 Mio.(!) Einträge in PnpLockdownFiles. Kann natürlich bei dir ein anderer Key sein oder was ganz anderes. Nachschauen sollte man mal... Beispiel Powershell Reg-Werte zählen: Get-Item HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PnpLockdownFiles | select ValueCount (als Admin ausführen, da der PnpLockdownFiles Key sonst gesperrt ist) Nachtrag: Könnte z.B. im Zus.-hang mit einem Bug bei Printer-Mappings stehen... https://community.cortado.com/en/1/Forums/tabid/104/aff/11/aft/217/afv/topic/Default.aspx bearbeitet 4. Dezember 2016 von massaraksch Zitieren Link zu diesem Kommentar
Parkesel 10 Geschrieben 4. Dezember 2016 Melden Teilen Geschrieben 4. Dezember 2016 Ich hatte das bootproblem neulich nach einer V2v Konvertierung... http://panologichelp.blogspot.it/2013/06/windows-server-2012-stuck-in-pre-boot.html?m=1 Nach Eintrag dieses wertes passte alles wieder... Zitieren Link zu diesem Kommentar
Shnu 10 Geschrieben 5. Dezember 2016 Autor Melden Teilen Geschrieben 5. Dezember 2016 (bearbeitet) Hi, Ergänzung wegen deiner 2 GB-Registry: Hier hatte auch mal jemand ein Problem mit einem riesigen Key: https://social.technet.microsoft.com/Forums/office/en-US/61387f4f-fd39-4b1f-a38f-2b7da230745c/problem-with-huge-registry?forum=winserver8gen Der hatte auch ein 2 GB Regfile und 22 Mio.(!) Einträge in PnpLockdownFiles. Kann natürlich bei dir ein anderer Key sein oder was ganz anderes. Nachschauen sollte man mal... Beispiel Powershell Reg-Werte zählen: Get-Item HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PnpLockdownFiles | select ValueCount (als Admin ausführen, da der PnpLockdownFiles Key sonst gesperrt ist) Nachtrag: Könnte z.B. im Zus.-hang mit einem Bug bei Printer-Mappings stehen... https://community.cortado.com/en/1/Forums/tabid/104/aff/11/aft/217/afv/topic/Default.aspx Hey, danke dir (Aber auch allen anderen hier) . Ich glaube das kann es sein. Ich bin mal zu diesem Key gegangen, und wenn ich Ihn öffnen will hängt sich RegEdit auf. Ist für mich ein Indiz dafür, dass dort sehr viele Schlüssel sind. Dein PowerShell Befehl funktioniert bei mir aber irgendwie nicht? ValueCount gibt immer den Wert 0 zurück. Dieses Update soll das Problem angeblich lösen: https://support.microsoft.com/en-us/kb2955164 Habe das Update auch schon Installiert, aber ich denke es verhindert nur, dass Zukünftig keine weiteren Einträge angelegt werden. Was mache ich aber mit den bestehenden? Kann man die einfach löschen? Über den RegEdit Editor komme ich überhaupt nicht weiter, hängt sich jedes mal auf sobald ich in den Schlüssel gehe. Edit: Noch was am Rande. Einer der Server hat zusätzlich noch Probleme mit den Profilen bekommen. Würde jetzt den Rahmen sprengen das zu beschreiben, aber ich vermute jetz das dies mit der 2GB Registry zusammenhängt.. Gibt es ein Limit für die Registry? Habe schon soetwas in der Art gelesen, dass 2GB die grenze sein sollen. Das würde dieses seltsame verhalten erklären. bearbeitet 5. Dezember 2016 von Shnu Zitieren Link zu diesem Kommentar
Shnu 10 Geschrieben 7. Dezember 2016 Autor Melden Teilen Geschrieben 7. Dezember 2016 Ich konnte die Registry nun Exportieren und nachdem ich zich programme ausprobiert habe, konnte ich nun auch eines Finden, welches mir die 2GB XML Datei öffnen konnte. Und es ist wirklich exakt das selbe problem wie hier beschireben: https://community.cortado.com/en/1/Forums/tabid/104/aff/11/aft/217/afv/topic/Default.aspx Es sind Millionen von Einträgen! Wie bekomme ich diese wieder gelöscht/bereinigt? Hier ein Auszug: <regkey name="%SystemRoot%/system32/spool/DRIVERS/x64/{9064E423-27A8-49A6-9B46-E7B35B3F945E}/hpmpw081.dll"> <regval name="Owners" value="oem29.inf\r\n" type="REG_MULTI_SZ"/> </regkey> <regkey name="%SystemRoot%/system32/spool/DRIVERS/x64/{9064E423-27A8-49A6-9B46-E7B35B3F945E}/hpmsl155.dll"> <regval name="Owners" value="oem29.inf\r\n" type="REG_MULTI_SZ"/> </regkey> <regkey name="%SystemRoot%/system32/spool/DRIVERS/x64/{9064E423-27A8-49A6-9B46-E7B35B3F945E}/hpmsn155.dll"> <regval name="Owners" value="oem29.inf\r\n" type="REG_MULTI_SZ"/> </regkey> <regkey name="%SystemRoot%/system32/spool/DRIVERS/x64/{9064E423-27A8-49A6-9B46-E7B35B3F945E}/hpmur155.dll"> <regval name="Owners" value="oem29.inf\r\n" type="REG_MULTI_SZ"/> </regkey> Zitieren Link zu diesem Kommentar
massaraksch 39 Geschrieben 7. Dezember 2016 Melden Teilen Geschrieben 7. Dezember 2016 (bearbeitet) Hi, also blöde Sache. Hier hat jemand das gleiche/ähnliche Problem beschrieben (nur ein anderer Hive\Key). https://blogs.technet.microsoft.com/askperf/2014/10/22/unable-to-restart-server-due-to-registry-bloat-over-2gb/ Am Ende gibt er den Tip, es mal mit der "ru.exe" (Microsoft/Sysinternals) zu versuchen. Mußt natürlich den Reg-Hive irgendwie offline auf ein anderes System kopiert bekommen und dann wieder zurück. Aber da das VMware ist, sollte man die Datei ja irgendwie aus dem Disk-Image ziehen können. Vor dem Einsatz der ru.exe müssen natürlich die Einträge raus. Aber der schreibt ja was dazu... bearbeitet 7. Dezember 2016 von massaraksch Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 8. Dezember 2016 Melden Teilen Geschrieben 8. Dezember 2016 Ich würde mal sagen: Ticket bei Microsoft ziehen und das Problem untersuchen und lösen lassen. Zitieren Link zu diesem Kommentar
MurdocX 904 Geschrieben 8. Dezember 2016 Melden Teilen Geschrieben 8. Dezember 2016 Probiere es mal mit dem folgenden Powershell-Command Get-ChildItem HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PnpLockdownFiles | Measure-Object | Select-Object -ExpandProperty Count Es gibt auch die Möglichkeit die Einträge mit der PowerShell zu entfernen, jedoch möchte ich hierfür kein Skript schreiben, ohne das Wissen, dass das unbedenklich für Dich und Nachahmer ist. Zitieren Link zu diesem Kommentar
Shnu 10 Geschrieben 14. Dezember 2016 Autor Melden Teilen Geschrieben 14. Dezember 2016 Ticket bei Microsoft ist auf. Bin nun mit einem Techniker dabei. Ich werde die Lösung dann hier Posten. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.