fusselchen

Danke, probier ich mal aus. Aber merkwürdigerweise sind die Laufwerke über den Explorer ja ansprechbar, nur halt nicht über die Desktopverknüpfung. Und auch nur manchmal.

Hallo Experten, ich habe in einem kleinen Netz folgendes Problem: Die Clients (Win7 EP) melden sich in der Domain (W2K8R2) an und starten ein Batchfile, was je nach Username die entsprechenden Laufwerke mappt. Auf dem Desktop der Benutzer liegen Verknüpfungen zu diesen Laufwerken (S:, T:, U: etc.) Alles läuft soweit, nur urplötzlich und nicht nachvollziehbar funktionieren diese Verknüpfungen manchmal nicht. Mal nur eine, mal mehrere. Wenn ich den Explorer öffne, sind die Laufwerke jedoch alle vorhanden und ich kann auch drauf zugreifen. Nur halt nicht über die Verknüpfung auf dem Desktop. Starte ich den Batchjob manuell über den Explorer (\\server\netlogon\start.cmd), funktionieren die Verknüpfungen wieder. Hat jemand ne Idee, woran das liegen könnte?

Ganz großes Kino: http://support.microsoft.com/kb/2646852 Da hat jemand echt mitgedacht. Ein Powermanagement, welches im Akkubetrieb den Server ausschaltet oder in Standby versetzt, bis der Akku der USV ganz leer ist (Ruhezustand lässt sich übrigens nicht auswählen). Nach dem Motto "Sch...egal, sind ja nicht unsere Daten, die in die Grütze gehen". Mannomann, wer denkt sich diesen Schwachfug bloß aus? Danke, Microsoft! :thumb2: @Dukel: hatte ich alles schon ausprobiert, aber Danke für den Tip. Des Rätsels Lösung hab ich gerade gepostet - ich geh jetzt Schnee schippen, um mich abzureagieren.. ;)

@Knorkator: tja, das ist schwer zu beantworten. siehe oben, Posting #6 Bei einem "normalen" Herunterfahren passieren ja folgende Schritte: 1. der Desktop wird ausgeblendet und wird schwarz 2. es erscheint ein grauer Hintergrund mit den Meldungen - Abmeldung... - Der Dienst "Gruppenrichtlinienclient" wird beendet... - Windows-Dienste werden beendet... - Herunterfahren... 3. Server wird ausgeschaltet Bei mir ist es so, daß, wenn der kritische Akkustand erreicht wird, Punkt 2 "fehlt". Das heißt, der Desktop wird ausgeblendet und der Rechner geht aus.

@Knorkator: Danke für deinen Einsatz, ich weiß es wirklich zu schätzen. Nimm´s nicht persönlich und bitte nicht falsch verstehen: falls es wirklich absolut nicht anders geht, werde ich evtl. auf das Script zurückkommen. Ist auch nicht meine alleinige Entscheidung, davon mal abgesehen. Aber ich will auch nicht mit Kanonen auf Spatzen schießen. Benachrichtigung per Mail und das ganze Trallalla brauche ich nicht. Die Kiste soll nur sauber herunterfahren und gut ist. Ziel ist, die mitgebrachten Bordmittel zu nutzen. Die USV wird erkannt, die Akku-Kapazität wird korrekt an das System übermittelt und beim Erreichen der eingestellten Grenze wird ja auch eine Aktion ausgelöst. Nur dummerweise wird der Server ausgeschaltet, bevor er sauber herunterfahren kann.

@Dukel: FullACK!

Java

@Knorkator: Danke, aber das löst das eigentliche Problem nicht. Es würde dann halt noch ein zusätzlicher Dienst bzw. Script laufen, was ich gern vermeiden möchte. Außerdem macht das eine evtl. Fremdwartung noch komplizierter. @Dukel: Jain. Im Moment ist das noch ein Testlauf. Aber er soll im Produktivbetrieb gleich herunterfahren, sobald der Strom ausfällt, damit Exchange & Co. noch genügend Zeit haben, die Datenbanken zu schließen usw. Habe schon mit unterschiedlichen Vorgaben (%) zum Herunterfahren herumgespielt, immer das selbe Ergebnis. Die USV selber bleibt an, hat ja auch noch reichlich Akku-Kapazität und liefert weiterhin Strom. Nur der Server schaltet sich halt einfach ab, anstatt herunterzufahren. Er leitet nicht mal ansatzweise eine Herunterfahr-Sequenz ein (grauer Bildschirm mit "Dienste werden beendet", "Herunterfahren" etc.). Die Kiste geht einfach aus. :(

Sorry, aber irgendwie hab ich dich nicht verstanden. Wieso abschalten schneller als herunterfahren? Hä? Er soll ja eben nicht abschalten. Macht er aber. Der Schlingel. :)

Hallo Experten, ich habe einen frisch installierten und voll gepatchten Win2008 R2 Std. Server mit einer neuen APC-USV ausgestattet. Leider fährt der Server im "Ernstfall", d.h. nach dem Ziehen des Netzsteckers der USV beim Erreichen der niedrigen (99%) Akkukapazität nicht sauber herunter, sondern schaltet sich einfach ab! Beim Hochfahren kommt dann die obligatorische Frage, warum der Server unerwartet heruntergefahren wurde. Im Syslog ist außer "Das System wurde zuvor ... unerwartet heruntergefahren" nichts weiter zu finden, nicht einmal, daß der Server auf Akku läuft / lief. Powerchute ist nicht installiert, es sollen die Windows-eigenen Energieeinstellungen benutzt werden. Diese sind wie gesagt so eingestellt, daß sich der Server bei 99% herunterfahren soll. Ich habe das jetzt mal mit 2 unterschiedlichen USV-Typen an 2 unterschiedlichen Servern ausprobiert, der Fehler ist identisch. Bitte um Hilfestellung.. Gruß Fusselchen

Danke, Doso. OK, hat sich gerade erledigt, er ist fertig :D

Grüße Euch! Weiß nicht, ob ich hier mit meinem Anliegen richtig bin, aber ich versuch´s mal: Ich musste bei einem Fileserver* ein 6TB Datenraid mittels Checkdisk (mit /f /r) überprüfen. Nach dem Reboot erhielt ich im Anschluss an die Dateiprüfung (Phase 1 von 5) dann folgende Meldung: "Es sind 85 MB zusätzlicher physikalischer Speicher erforderlich, um den Datenträger bei voller Geschwindigkeit überprüfen zu können" :( Jetzt hängt die Kiste schon seit 2 Tagen bei "CHKDSK überprüft Dateidaten (Phase 4 von 5)" und prüft und prüft und prüft... Dass das Ganze viel Zeit in Anspruch nehmen würde war mir schon klar, aber mit so viel habe ich nun nicht gerechnet. OK, war vielleicht ein bisschen dumm oder blauäugig von mir, gebe ich zu. Mittlerweile bekomme ich jedoch echt Muffe, dass das noch Tage oder Wochen dauert. Dann hätte ich nämlich ein wirklich fettes Problem... Hat jemand Erfahrungswerte mit so großen Arrays und so lahmer Hard-/Software? Oder irgend einen Tip für mich? Gruß, Fusselchen * grobe Eckdaten des Servers: Athlon64 ~2GHz 1GB RAM W2K3R2 1 SSD als System"platte" 4 HDs à 2 TB im RAID5 (über Dawicontrol-Schnittstellenkarte, kein aktiver RAID-Controller, Software-RAID über Treiber)

Mahlzeit! Wie ich bereits geschrieben habe, stürzt der Server lt. Protokoll 5 Sekunden nach dem Hochfahren des Clients ab. Nicht nach dem Anmelden. Alles ist absolut virenfrei. Kommt ja auch nur sehr sporadisch vor, werde deswegen nicht den Client komplett neu installieren, das wäre wohl mit Kanonen auf Spatzen geschossen..

Mahlzeit! Ich habe hier ein ganz merkwürdiges Phänomen. Und zwar schon mindestens das zweite Mal (d.h. zum 2. Mal nachweisbar, vielleicht auch schon öfter vorgekommen). Es passiert glücklicherweise recht selten, aber ist trotzdem ein Fall für die Twilight Zone :suspect:: Wenn ein ganz bestimmer PC (XP) im Netzwerk hochgefahren wird, schmiert nahezu zeitgleich der Server (2k3) ab. Ping geht noch, mehr allerdings nicht. Kein Bild, kein Ton, keine Reaktion auf Maus/Tastatur, Monitor geht nach dem Einschalten auf Standby. Hab mal die USV stromlos gemacht, damit der Server runterfährt, funktioniert aber auch nicht. Der hängt wie ne Glocke. Die einzige Möglichkeit, ihn zu reanimieren, ist dann der Resettaster. :shock: Hier mal die Screenshots von Server (8:19:32) und Client (8:19:27): http://www.abload.de/img/server20.02.201208.19whude.jpg http://www.abload.de/img/kro20.02.201208.19t9udb.jpg Laut Protokoll schmiert der Server exakt 5 Sekunden ab, nachdem der Client hochgefahren wurde und den ersten Eintrag im Systemprotokoll vorgenommen hat. Könnte natürlich auch durchaus sein, daß die Uhren nicht synchron laufen (war ja auch das Wochenende dazwischen, sowas passiert natürlich immer am Montagmorgen) und alleine das bloße Einschalten des Clients den Server zum Herzstillstand gebracht hat. Die Elektrik in der Hütte ist gefühlt noch aus der Zeit von Edison.. Es kommt hinzu, daß ausgerechnet dieser Client sporadisch (ca 2-3 Mal im Jahr) Probleme beim Starten hat (angeblich kein Bootmedium vorhanden). Komplettes Ausschalten des Netzteils hinten, 1 Min. warten und wieder Einschalten behebt das Problem. Netzteile (Server + Client) wurden bereits getauscht. Hat irgend jemand eine halbwegs logische Erklärung für diese Geschichte? Oder nen Tip, wonach ich suchen könnte? Ratlose Grüße Fusselchen

Hallo Christoph, danke für die Antwort. Selbstverständlich! Alles auf dem neuesten Stand. Als der Fehler zum ersten mal auftrat (bereits vor dem letzten MS-Patchday), hatten sie beide den selben Stand. Gruß Tommy