stuffy

Möglicherweise ist die Schuld bei der Hardware zu suchen - die alte W2k Installation hat wahrscheinlich deshalb Probleme gemacht. Ich hatte auch so einen Fall (zwar ohne mehreren OS auf dem Rechner) aber da war das Memory schuld und das setup ist auch hängen geblieben (W2K ist da sehr "sensibel").

Geh' sicher dass das Profil nicht im Netzwerk abgelegt wird. AD - User account - properties - profile - profile path - Eintrag löschen. Dann wird das Profil lokal gespeichert und nicht im Netz. Brauchst dann deine lokale ID nicht mehr und kannst mit der Netzkennung (obwohl kein Netz vorhanden) auch lokal einsteigen. Und stell' in Outlook noch den Offline - modus ein (send/receive settings - Make this folder available offline - dann wird ein sync auf den lokalen pc gemacht. Kannst dann mit einem Login alles machen, und mit allen accounts die du eingestellt hast ....

Der Sinn eines Poxies ist ein ganz anderer als die Funktonen einer Firewall. Ein Proxy soll cachen, damit beim Internetzugriff ein und die selbe Seite nicht x-mal abgerufen wird, sondern wenn bereits einmal vorhanden vom Proxy kommen. Wenn du mit einem Rechner durch einen Proxy willst müssen die dafür notwendigen Ports direkt freigeschalten sein, d.h. direkt durch den Proxy durch, ohne in der cache zu landen. lg

Hallo Götzi Werd' mal unseren Admin kontakten was der dazu meint, wird aber ein wenig dauern ... lg

@zuschauer War nur eine Idee, unser TM Admin sitzt in NL, aber wenn Götzi sich eine Testversion holt braucht man sich vielleicht auch nicht wundern dass nicht alles so funkt wie im "Handbuch" beschrieben. Vielleicht hat er eine Version erwischt die unter W2K3 eben nicht funktioniert (möglicherweise ist was im IIS anders als unter W2K), und so wie's aussieht wird's das wohl sein, da es bei dir ja problemlos geht. Hab unter W2K selbst einen IIS mit allen möglichen "Schnonkeles" aufgesetzt und betreibe damit eine Intranetseite mit allen möglichen server scripts und Datenbanken. Das Ding kann verflucht viel, und man kann sich auch ganz schön in die Nesseln setzen wenn man eine Kleinigkeit übersieht.

sag' rennt da überhaupt CGI auf deinem IIS - der IIS kann doch nur ASP als serverscript - auf meinem W2K IIS musste ich mir alle möglichen Sachen nachinstallieren, damit der PHP o.ä. überhaupt kapiert hat - sonst kann er doch nur ASP und die üblichen HTM, HTML Geschichten. Und glaub' mit am TM wirst du auch keine rechte Freude haben, da ist NAV oder McAfee noch das kleinere Übel. Mein lokaler NAV findet immer noch Sachen die der TM (obwohl immer aktuell) übergelassen hat .... lg

Meiner Erfahrung nach hat jeder der einen Poxy einsetzt auch ein bestimmtes Regelwerk dahinter - oft sind nur die http https und ftp ports freigegeben - mehr braucht man auch im Normalfall beim Surfen auch nicht. Nur schlampig programmierte Webauftritte und bestimmte Applikationen (ich denk' da mal an Telebanking Software o.ä.) verwenden andere ports. Ich würde nur wegen einer Person meinen Proxy auch nicht aufmachen. Sicherheit geht vor ...

Wenn du diese Registry Einträge machst, erzeugt er dir nie wieder eine *.pwl Datei, auf dem lokalen Rechner ;) Registry Settings User Key: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Network] System Key: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Network] Value Name: DisablePwdCaching Data Type: REG_DWORD (DWORD Value) Value Data: (0 = disabled, 1=enabled) Funktioniert übrigens mit allen Windows Versionen :D

Hallo datasearch Wenn ich die batch Datei vom netlogon share händisch starte dann funktioniert sie und auch das KIX script wird richtig ausgeführt - nur automatisch beim login startet sie nicht. Hab' das script mit dem KIX editor im debug modus laufen lassen, und es macht was es soll (werden nur Netzwerklaufwerke nach Gruppenrechten gemappt, und die Uhrzeit der WS gesetzt also eigentlich eh' nichts Aufregendes) Ich glaub nicht dass ich da irgendwo einen Fehler d'rinnen stehen habe, da es sonst auch beim manuellen Start nicht funktionieren würde. User rechte bei kix32 sind es leider auch nicht - hab' sogar die vollen Rechte vergeben, und trotzdem geht's nicht. Ich glaub' ich stell in einer Nacht und Nebel Aktion alle WS auf XP um - Tja mit den bat dateien hab' ich so meine Probleme - es gibt noch 2, 3 alte Rechner im Netz mit kritischen Programmen, die unter 98 bzw ME laufen - die kommen wieder mit den %-Variablen nicht zurecht - sonst hätt' ich's eh' schon so gemacht. Danke trotzdem

Hallo datasearch Hat leider auch nicht geholfen - selber Effekt - XP macht's, W2K nicht. Danke trotzdem für den Tipp

Der Anmeldeserver steht im WAN und ist via Standleitung nur erreichbar (war nicht meine Idee !!!) - möchte den Verkehr so niedrig wie möglich halten, und einen Teil der "Arbeit" vom Client erledigen lassen. Danke für den Tip (bin ein KIX Newbie), ich werd's mal versuchen ob's so funktioniert - gebe Bescheid wenn's geklappt hat.

Das script wird mit der batch datei (login.bat) bei der Netzwerkanmeldung des Benutzers aus dem Profil gestartet: Eintrag in der login.bat sieht so aus: c:\kix\kix32.exe %logonserver%\netlogon\script.kix (vorher werden noch die notwendigen KIX-files - exe + dll's auf die WS kopiert, wenn sie nicht vorhanden sind - das klappt auch problemlos) Geb ich das ganze auf der W2K WS im cmd-prompt händisch ein funktioniert's. Nur automatisch beim login des Benutzers im Netzwerk geht's unter Windows 2000 nicht. Komischerweise geht's daber wenn ich am W2K Server einsteige, oder auf einer XP Workstation.

Die Batchdatei und das Kix-Script wird aus dem NETLOGON share vom Loginserver gestartet - und von der "lokalen" kix32.exe mit den notwendigen dll's ausgeführt. Das witzige daran ist, wenn ich die bat manuell ausführe - funktioniert es - nur vom Benutzerprofil (loginscript) funkt sie nicht wenn der PC W2K als OS hat - mit XP pro klappt es.

Leider steht gar nicht's d'rinnen - es startet einfach nicht

Hallo Beisammen Wenn ich bei einer XP pro WS einsteige läuft das Loginscript (bat) + einem KIX script problemlos - steige ich auf einer W2K WS ein, wird das Login Script (batch Datei die das Script aufruft) nicht ausgeführt. Starte ich die batch Datei vom netlogon (W2K) share manuell funktioniert das Ganze auch - nur automatisch beim Einloggen klappts nur nicht. Bei XP pro auf der WS klappt das Ganze problemlos. Hat jemand eine Ahnung woran das liegen könnte, mir gehen nämlich die Ideen aus ... Vielen Dank im Voraus

Bloss nicht TM - erkennt nur die Hälfte und wenn du Logs auswerten willst umständlich - ich weiss wovon ich rede - Symantec, McAffeee und TM verwendet - TM mit Abstand der Schlechteste von den 3en. Symantec AV CE ist meiner Meinung nach die beste Wahl - easy für den Admin, mit hoher Trefferquote punkto Erkennung. Ist auch gemeinsam mit McAffee Testsieger in diversen Fachzeitschriften - TM rangiert meist nur im oberen Mittelfeld.

Wurde nicht nach einem PW gefragt beim Verbinden, da ich scheinbar zu den Authenticated Usern vom Server gehöre, und eigentlich read und execute Berechtigungen habe - sonst leider nix (mein script'l hat mit die "Mutter" dort hingestellt). Kann das Script auch über den Explorer problemlos ausführen, nur beim Login klappt's einfach nicht. Vielleicht ist es wirklich der NT BDC (was ich mir rein logisch aber nicht vorstellen kann - aber ich habe bei M$ schon soviele Kuriositäten erlebt - es wäre nur eine mehr).

Wenn ich das Script über den Explorer \\logonserver\netlogon ausführe dann funktioniert's problemlos :eek: - hab' ich gerade ausprobiert ...

Danke für den Tip Das ist das Resultat auf meine "net use" mappings das ich zurückbekomme: H:\>\\server\netlogon\test.cmd The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. The current directory is invalid. Ich versteh's nur nicht ganz , denn wenn ich das script bei meiner WS lokal ausführe werden die mappings anstandslos gemacht -sind lauter Shares auf anderen NT Servern (die ich in Kürze umstellen werde - ich möchte damit nur im Vorfeld schon alles mögliche vorbereiten) Am Script selber kann es wohl nicht liegen :suspect: Wenn ich mir die Permissions \\logonserverneu\netlogon ansehe dann darf ich das Script ausführen (authenticated user = r + x) Der alte NT Hobel hängt noch immer im Netz und war früher BDC (kann es sein dass das möglicherweise das Problem ist).

Könnte dir eine Komplettlösung für Kleinbetriebe empfehlen: http://www.securebox.at/ Kostet allerdings etwas ....

Hallo Habe folgendes Problem habe ein (W2k AD) Logon script erstellt, im NETLOGON Ordner vom Anmeldeserver (W2K) deponiert, beim User das script angegeben) und das Ding startet beim einloggen nicht. Bin mittlereweile d'raufgekommen dass die env. variable auf der WS (W2K oder XP pro) %LOGONSERVER% auf einen alten NT Hobel (wird nun durch den W2K Server ersetzt) verweist, und dort natürlich kein Script liegt. Das Problem ist, dass ich kein Serveradmin für beide bin (da hat die "Mutter" die Hand d'rauf - darf nur ein bisserl was im AD). Egal was ich auf der WS beim Logonserver ändere (registry)beim nächsten Reboot hab' ich wieder den alten Server d'rinnen stehen. Die "Mutter" zuckt nur mit den Achseln (hat auch keine Ahnung) und ich kann nirgends nachsehen woher das kommt (ich vermute eine Policy). Wäre für eure Tipps dankbar.

So wie ich das verstehe hast du mit dem "Sparefroh" Problem zu kämpfen. Einerseits soll das Ding ein Applikationsserver, andererseits ein "Arbeitstier" werden, das Netzwerk- und Fileserverfunktionen übernimmt . Die Zugiffsmodi sind komplett unterschiedlich - bei den Applikationen "glüht" die CPU und der Speicher, und bei den File- Printserver Geschichten hebt die Harddisk ab, und die NIC (sofern sie keine Gigabit ist) wird auch ein bisserl "warm" werden. Nicht umsonst gibt es 2 verschiedene Modi in den Servereigenschaften (Performance Settings: Foreground - Background) Das Ding ist ohnedies zum Absturz verdammt - das funktioniert nie (ich kann aus Erfahrung reden - hatte die selbe Situation wie du - nach 3 Crashes haben sie es endlich eingesehen, dass das so nicht gehen kann) :p .

Super :) , danke für die Info - mach' mich gleich auf die Suche lg Stuffy

Danke für die Info - nur den Lieferanten gibt's leider nicht mehr (hat vor 1 Jahr die "Segel" gestrichen) und ich hab' das Ding vor 3 Jahren gekauft, jetzt sitz ich nun da mit meinem "Rolls Royce" :p , und steig täglich durchs "Fenster" :mad: ein anstatt die Tür zu benutzen .... Naja, werd' mal schauen was ich bei Cisco erreichen kann....

Danke für die Tips :D - werd' alle mal durchprobieren lg Stuffy