tjwat

Wie gesagt, die Scripte sind uralt, die liefen schon genauso auf W2K-Server und W2K3-Server ( ohne Probleme ). Die Netzwerkporblematik war ja auch fix gelöst, was mich halt nur ärgerte / wunderte, das man halt nichts sah, wenn das Script ausgeführt wurde. Wenn ich es manuell starte läuft es normal, also weiß ich ja, das es funktioniert und wenn es über den Taskplaner läuft sieht man nichts, das erleichtert im Zweifel die Fehlersuche ja nicht unbedingt...bin halt nen alter DosBox-Fetischist, kann da auch nichts für :p Ist nun einmal so, das ich manchmal denke, das weniger mehr ist - also lieber weniger bunte Oberfläche und "Meldungsflut", sondern klare, präzise Ansagen und das von mir aus in weißer Schrift auf schwarzem Hintergrund - da weiß man wenigstens woran man ist. Aber nun läuft es seit Wochen stabil und so wie ich will, also kann ich auch damit leben :cool:

Hi Olc, für wen war deine Antwort nun gedacht ? Für uranus oder für mich ? Zu deiner Vermutung : Die Kontexte passen und die Scripte laufen seit Jahren sowohl auf Server 2K als auch auf Server 2K3 ohne Probleme über die jeweiligen Taskplaner. Diese Phänomene gibt es erst ( bei uns ) seit Server2k8. Frust abladen brauche ich auch keinen, funktioniert ja alles wie es sollte, nur halt teilweise umständlicher als es müßte :p

Hmm, also nach diversen Phasen der Verzweiflung habe ich nun einige Sachen über den neuen Aufgabenplaner herausgefunden - alles in Bezug auf die Ausführung von Batch-Dateien. Dabei ist vorausgesetzt, das die Batchdateien auf Server 2003 automatisch und problemlos liefen bzw überhaupt funktionieren ( auch auf Server 2008 ), wenn man sie manuell laufen läßt. Angemeldet bin ich als Administrator mit den entsprechenden Berechtigungen. 1. Ich erzeuge per Script einen Oracle Dump - lasse ich den Dump auf ein Netzlaufwerk schreiben ( an der Netzwerkgeschwindigkeit liegt es DEFINITIV NICHT ! , alles gestestet ) braucht die Aufgabe lockere 10 Stunden, lasse ich den Dump auf ein lokales Laufwerk schreiben dauert es 2 Stunden ! Wenn die "alten" 2003er Server mit dem selben Script über dasselbe Netz denselben Dump schreiben, sind sie nach ca. 5 Stunden fertig. 2. Alle Aufgaben innerhalb von Scripten ( können auch alle in einem stehen oder einzelne Skripte, vollkommen egal ) , die auf dem lokalem Rechner ausgeführt werden ( zB Dump-Export, Dump fixen, archivieren, umbennen etc etc ) laufen ohne Probleme, wenn man im Aufgabenplaner "unabhängig von der Benutzeranmeldung ausführen" auswählt - ABER zB ein Kopierjob für eine Datei, der zB die die lokale Datei C:\Dump.dmp kopieren soll auf ein lokal gemapptes Netzlaufwerk x:\sicherung, das wird nicht ausgeführt ! Das kopieren ( oder verschieben ) funktioniert nur, wenn man in der Aufgabenplanung auswählt, das die Aufgabe bei angemeldetem Benutzer ausgeführt wird ! ( Schwachsinn hoch drei bei nem Server ). Dabei ist dann auch egal, ob man tatsächlich bei der Ausführung zuschaut oder den Rechner sperrt - nur abmelden darf man den Benutzer halt nicht. 3. Es nutzt nichts, wenn man ein Script durch ein anderes Script aufrufen lassen will, um obiges Problem unter 2. zu umgehen. Er ( der Aufgabenplaner ) meldet dann brav Vollzug - aber passiert ist trotzdem nix. Es ist auch vollkommen egal ob man die normale cmd-shell benutzt oder die power-shell, kommt bei beiden dasselbe raus - nix Fazit : Die "neue" Aufgabenplanung ist zwar mal wieder schöner, größer, bunter und vermag einen mit Informationen totzuschlagen ( wobei man mit den meisten wieso nix anfangen kann ) , aber so ganz durchdacht ist sie irgendwie noch nicht....

Kann auch schlicht daran liegen, das die Offline Dateien ( bzw deren Originale logischerweise ) auf einem Netzlaufwerk liegen und das bei einer zeitweisen Nichtbenutzung freundlicherweise einfach von Windows getrennt wird - wenn der User sich dann ab und wieder anmeldet wird das Laufwerk wieder gemapped und gut ist .... bis zur nächsten automatischen Trennung ;-)

Habe es sowohl im aktiven wie auch im passivem Modus probiert. Komme zum selben Ergebnis

Mahlzeit, ich habe folgendes Problem. Ich habe bei 1 & 1 einen Webserver gemietet. Auf den greife ich normal mit FTP zu um meine Programme hochzuschaufeln ( funktioniert per IIS ). Jetzt habe ich allerdings zusätzlich auf diesem Server noch das FTP Serverprogramm ServU installiert. Dieses soll auf Port 990 SSL FTP Anfragen übernehmen. Habe in den IP-Sicherheitsrichtlinien in W2K dafür den Port 990 geöffnet. Nun passiert folgendes, ich komme mit dem FTP Voyager ( der Client ) mit SSL am Server an, kann mich auch einloggen und es wird auch das richtige Zielverzeichnis gesetzt ( sehe ich ja alles im FTP-Client-Log ). Dann schickt der Client den Befehl LIST -T um den Verzeichnisinhalt auf dem Server aufzulisten - und genau da ist das Problem. Der Befehl wird übergeben und dann passiert NICHTS mehr. Im Clientfenster steht die Sanduhr und der Inhalt des Verzeichnisses wird nicht aufgelistet und das wars ( also auch keine Fehlermeldung ). Wenn ich in dem FTP Serverprog auf dem W2K Server nachschaue ist der User dort angemeldet, aber nicht aktiv. Habe dann mit dem Prog Active Ports nachgeschaut, welche Ports am Server aktiv sind oder sein wollen. Port 990 hat eine stehende Verbindung ( der eingewählte Client ) und es wird kurz Port 989 geöffnet um ein Sync zu schicken ( habe ich dann auch freigeschaltet - keine Änderung ). Auf Clientseite ist keine Firewall o.ä. aktiv Da es sehr wichtig ist, das ich die Sache schnell ans Laufen bekomme, bin ich für jeden Tipp dankbar, bin langsam am Ende mit meinem Latein.