stuffy

Hast du im Event log mal nachgesehen, ob du irgendwelche Fehler d'rinnen stehen hast?

Ins blaue geraten - zuviele Netzwerkdienste abgedreht? z.B.: DNS Client, Net Logon, etc. - vergleich mal mit einem Rechner der schon d'rinnen ist in der Domain.

Beim Hochfahren des Rechners einfach nur aufpassen wie die Platte sich meldet - und danach "googeln" ;)

Ich hatte es zwar mit dieser eigenwilligen schreibweise probiert (html link), vielleicht hab' ich mich dabei vertippt ... Danke nochmals

Das war des Rätsels Lösung - das proxy.pac hat lokal nicht richtig funktioniert - das selbe auf meinen Intranet Server gestellt - und es klappt tadellos. Danke nochmal vielmals für deine Hilfe. lg Stuffy

Ich hab' nochmal alles kontrolliert, aber leider nichts gefunden Ich hab' dein Script nochmal aus deinem Posting kopiert (editor) und die Änderungen genauso eingegeben wie's in der Anleitung d'rinnen steht. Vielleicht leg' ich mal das script auf meinen Intranet server, und versuch's nicht lokal aufzurufen ....

Hallo thorgood, Habe leider doch ein Problem .... Scheinbar funktioniert das Script, aber mein lokaler Linux Proxy spielt mir dabei nicht mit. Der lokale proxy verlangt (extra gewünscht) eine Authentifizierung mit einem extra login + passwort (hat nichts mit der Netzwerk ID zu tun), das man bei uns im IE normalerweise eingeben muss um überhaupt Zugang ins WWW über den Proxy zu bekommen. Intranet Seiten lassen sich problemlos aufrufen, aber ich komm' nicht zur Autentifizierung am lokalen Proxy - ergo dessen nicht ins Internet. Hast du eine Idee wie man dem Script das mit der Autentifizierung "verklickern" kann?

Hallo thorgood Herzlichen Dank für deine Hilfe, setz mich gleich hin, und probier's aus Sollte mit der super Anleitung eigentlich kein Problem sein... lg Stuffy

Hallo, Ich habe folgendes Problem ich habe einen lokalen Proxy (Linux) für's "Indernett" surfen, und es gibt einen weiteren Proxy im WAN (MS) über den man auch ins Intranet (Übersee) gelangt (und leider nur über den). Da die Leitung zum WAN-Proxy etwas schwächelt - soll die WWW surferei über den lokalen Proxy gehen. Ich würde das gerne automatisieren. 2 verschiedene intranet.domain.net über den WAN-Proxy - Rest Local-Proxy. Hab' keinen Zugriff auf den DNS. Mit "Automatic detect" geht er immer nur über den WAN-Proxy, und vergisst den lokalen. Und mit registry entries die Benutzer dauernd selber switchen zu lassen wird mühsam ... Ausserdem kann ich damit den "Automatic detect" nicht abschalten (bzw. ich hab den Eintrag in der Registry bisher noch nicht gefunden). Hat jemand ein script - proxy.pac für den Browser - mit das funktionieren könnte. Leider weiss ich nicht wie man so etwas erstellen kann Ich hoff' ich hab's genau genug beschrieben ...

Das merk' ich leider leidlich .... Vor SP2 "kurbelte" mein alter P866 recht fröhlich mit XP herum - nach SP2 ist er eine müde Schnecke geworden (trotz aller abgedrehter unnötiger services und anderer Systemtunings) :(

Schau' dir die Rechte beim lokalen TS Drucker an - dann siehst du wer was machen darf - leg' dann die Benutzergruppe (in der der User ist) der Domain in der lokale Gruppe an die du brauchst oder du vergibst Ihm die Rechte am Drucker...

Eine Vernünftige Lösung ist nur in Verbindung mit einem netzwerkfähigen Kopierer/Scanner möglich. Diese haben meist eine Scanner/Server/Client Software dabei, die "Postfacher" verwaltet - Am Scanner ist das Postfach anzuwählen, am Arbeitsplatz ist ein Client installiert, der die Scans von einem Server (verwaltet die Postfächer und sammelt die Scans) "abholt". Beispiele siehe NRG, Canon, ...

Nicht vergessen KIX ist nicht wie net use oder andere commands handzuhaben hat einen eigenen Terminus ....

Hast du den Server Share in Hochkomma gesetzt? - siehe Beispiel unten If InGroup("GRUPPE") Use m: "\\Server\Share" EndIf Passen die Berechtigungen am Share? lg Stuffy

Veritas war nicht Schuld im Endeffekt. Der Server konnte den HOST (SMTP Server) nicht erreichen - mit der IP Adresse ging's dann - das DNS Suffix hat gefehlt - ging beim Namenswechsel verloren ... :mad: Tja, kleine Ursachen grosse Wirkungen - es ist zum Schreien !!!!!

Tja hochgekommen ist der Server sogar ohne Probleme, Backup lief auch wieder einwandfrei, aber die Mailbenachrichtigung funzte einfach nicht mehr, ganz egal was ich versucht habe - Testmail schaute aus als ob es funktionieren würde, aber angekommen ist "nada". Veritas ist wirklich seeeeehr eigen ....

Nachdem ich das Diagnosetool laufen liess stellt sich heraus das die MSSQL nach wie vor mit dem alten Servernamen herummurkst. Scheinbar ist beim Wechsel des Servernamens einiges doch nicht mitgeändert worden. Ich habe nur die Lösung gefunden - komplett deinstallieren und Neuinstallation. In einer Veritas Newsgroup habe ich dann die Bestätigung erhalten dass dies die einzige Möglichkeit ist :suspect: Ich kann allen nur raten - Finger Weg vom Backup Exec wenn's funktioniert - sonst macht es mit dir was es will ;)

ich hol's mal nach vorne ...

wirklich Niemand ???

Hallo ihr Lieben, Vielleicht kann mir jemand helfen Hab auf einen W2K3 Server (Fileserver) Veritas Backup Exec 9.1. laufen, und musste den Namen des Server ändern (raus aus der Domain - neuer Name eingetippt - wieder rein in die Domain und das AD). Backup funktioniert nach wie vor ( was mich eigentlich gewundert hat, dass das die MSSQL verkraftet hat), aber die Benachrichtigung per SMTP funktioniert nicht mehr . Hab' alle SMTP Einstellungen gelöscht (auch die Empfänger) neu gestartet, wieder neu angelegt - leider keine Benachrichtigung per Mail..... Hat jemand eine Idee?

Hast du im AD vielleicht grouppolicy Einträge gemacht die ein Windows Update verhindern? Dann funktioniert es auch nicht trotz der Einstellungen vom wuau.adm. Auf den Rechnern muss bei den Services der Dienst "Automatic Updates" laufen sonst klappt es auch nicht (GPO Einstellung). lg Stuffy

Trag im AD deinen XP Rechner manuell ein, und versuch' ihn dann anzumelden .... (hat dein verwendetes account überhaupt Rechte den Rechner an die Domain anzumelden?)

:shock: Du brauchst kein analoges Kabel das geht auch über das cat7 - vom Telco Verteiler auf's Patch Panel von den Zimmern. Nur die analogen Telefonkabel / Modemkabel müssen die richtigen sein - das liegt dann an den Endgeräten wie die gekrimpt sein müssen (hatte da mal ein Erlebnis der besonderen Art mit Alcatel/Nextira One Endgeräten - die haben einen "eigenen" Standard).

ja - verwenden wir - kannst im Prinzip alles darüber machen...