himbidas

Oder nimm Netmeeting (gehört ja bekanntlich zu M$-OS kostenlos dazu), installier das Teil auf dem "schnellen" Rechner und aktiviere die Remote-Desktop-Freigabe. Lass es dort "schlummern". Installiere es ebenfalls auf dem "lahmen" Rechner, ohne Remote-Desktop-Freigabe, stelle die ausgehenden Verbindungen über Extras-Sicherheit auf "sicher". Starte Netmeeting, "schnellen" PC per Name bzw. IP anwählen, Adminkonto-Namen und Passwort (u.U. noch Domäne o. Arbeitsgruppe) eintragen und steure den "schnellen" fern. VNC tut das selbe, hatte bei mir aber den Nachteil, dass der Bildschirmaufbau ziemlich lahm war. Netmeeting war da um Größenordnungen schneller. Vielleicht sind neuere VNC-Versionen fixer, k/A. Hab mal mit Netmeeting Deutschland-Kanada-Verbindung ferngesteuert, hier DSL, dort Modem. Und hatte mit Netmeeting verflucht kurze Antwortzeiten < 3 sec Verzögerung, mit Sound! Nur mal so nebenbei :) Thomas

Danke :) Wenn ich das dann richtig interpretiere, kann ich ge-x-te Einträge mit überschrittenem Ablaufdatum löschen. mal-kurz-dazwischen-frag--ende- Thomas

na gut ;) hab ja gesagt, dass das aufgrund des genannten Links nur eine Lösung wäre, aber nicht die Ursache erklärt. Und ein zweites Admin-Konto einzurichten, kann man niiiiee zu oft erwähnen :) Dann eben das "defekte" Adminkonto nicht löschen, sondern umbenennen und danach deaktivieren. Was eigentlich viel interessanter ist, ist die Frage: Was ist die Uersache dieses komischen "bak"-Verhaltens? Wenn ich so nach administrator.bak google, scheint dieses Verhalten nicht allzu wenig aufzutreten. Hab nur noch keine saubere Lösung dazu gefunden. Und Erklärungen, warum dieses Profil ensteht, gleich garnicht. Thomas

stehe auch ein bissel mit WINS-Manager auf Kriegsfuss :mad: (auch wenns total popelig ist). Hat vielleicht jemand einen guten Link für 'ne Erklärung, wie ich das Fenster (siehe: http://www.mcseboard.de/showthread.php?postid=85924#post85924 ) interpretieren kann? Besonders die Spalten "A" und "S" interessieren mich da. Einige Clients haben da ein Totenkreuz drinne. Und ich habe noch nirgendwo was gefunden, was Haken, Strich oder Kreuz bedeuten. Kann ich z.B. die Kreuzerl-Einträge einfach löschen? Wüsste es nur mal der Vollständigkeit halber. Danke, Thomas

Ich tippe auch stark auf QHost. Hab eben erst 'ne News von "Trend Micro" (leider schon wechgeworfen) gelesen. U.a. blockt dieser Trojaner Google-Seiten. Oder nutzt du DSL? Dann könnte das helfen: http://www.mcseboard.de/showthread.php?postid=86048#post86048 Thomas

Das hört sich soweit plausibel an. Doch so recht kann ich das nicht glauben. Bei mir starten die User z.b. je nach Abteilung ein anderes "Initial-Script", dieses "called" ein "Zentral-Script" im NETLOGON und darin gibt's je nach Gruppenzugehörigkeiten noch ein paar Calls auf weitere CMD's. Diese Aufrufe funzen und nix versucht das Aktuelle (DOS)-Laufwerk zu ermitteln. Was könnte also noch faul sein?? @killinspree Kommt der Fehler nur auf Clients, die die if-Klausel nicht erfüllen? Oder ist das eher "zufällig"? Trifft es nur bei allen Nicht-ePo-Agent-Kisten zu, dann ist zuschauer's Erklärung die Wahrscheinlichste. Gibt es aber welche, die es installieren und welche, die nicht -> dann muss es einen anderen Grund geben. Der Einfachheit halber würde ich auch dazu raten, im Export-NETLOGON-Verzeichnis ein Unterverzeichnis epo-inst zu erstellen, dort die framepkg.exe reinpacken und das ganze zu replizieren. Vorher noch das Anmeldescript so umschreiben, dass es auf die neue exe zur Installation losgeht. Und sollte es überhaupt nicht wollen, versuche deine agent-inst.cmd so zu rufen: call %LOGONSERVER%\NETLOGON\agent-inst.cmd Am Rande noch zwei Tipps a) benutze ich seit neuestem auch die ePo von NAI. Habe dabei u.a. festgestellt, dass einige Clients sich nicht sauber updaten konnten, da sie keine Verbindung zum Repository-Server bekamen. Ursache: DNS-Auflösung für WINDOWS war bei einigen nicht aktiviert. Dadurch keine Namensauflösung, keine Verbindung zum Server. U.U. wäre das auch ein Grund für Dein Problem. b) Kommt nach deinem ePo-Check in Deinem Anmeldescript noch irgendwas für das Login? Wenn ja, würde ich dazu raten, "Unter-Batches" mit einem CALL zu rufen. Ansonsten wird z.B. nur dein agent-inst.cmd gerufen, abgearbeitet und danach ist das LOGIN beendet, da nicht zum "rufenden" Loginscript zurückgekehrt wird. Thomas

himbidas Jim di Griz Fällt der "kleine" Unterschied auf? Werd' mich schwer hüten, einen Senior-Member auf die Füsse zu treten. Kann mich aber beim besten Willen nicht erinnern, Jim di Griz unterstellt zu haben, dass er nicht -> siehe oben Ergo :) please Meine Frage war mehr rethorischer Art. @raveman Wieso Excel? das kannst du doch alles in Visio abdecken. Alle Angaben, die du brauchst in die Objekteigenschaften reinschreiben, als HTML exportieren und dann bekommst du ein schickes Frameset, links die Objekteigenschaften bei Mauskontakt der Zeichnungsobjekte im rechten Frame. Gib mal bitte bescheid, wie das Script funzt. Könnt ich auch gebrauchen. Thomas

Ach sooooo.... keine Ahnung, was da der Grund ist Aber folgender Link hat mich auf 'ne Idee gebracht; http://www.nickles.de/c/a/archiv2000-97258.htm [*] neues Adminkonto (z.b. admin1) (mit allen Rechten eben) erstellen. [*] mit Schritt 1. noch einen als admin2 erstellen. [*] sich mit beiden anmelden, um zu checken, dass auch alles klappt [*] sich mit admin2 anmelden und [*] alten administrator in admin-old umbenennen, sowie [*] admin1 in administrator umbenennen. danach [*] admin-old löschen [*] damit müsstest du einen neuen, sauberen administrator haben und zur Sicherheit noch einen admin2.[/list=1] Klärt zwar die Ursache nicht, wäre aber ne Lösung. Thomas

Aber nicht doch, ihr seid sowie-und-überhaupt-die-besten-hier ;) ;) (im Ernst, Indianer-Ehrenwort) so, Check hat geklappt. NETLOGON-Default User-Inhalt geändert. Wird bei nächster Anmeldung übernommen. aber... Werden die Outlookeinstellungen nicht auch in der ntuser.dat gespeichert?? Wenn wir ein Problem mit Outlook haben, killen wir nicht gleich das ganze Profil, sondern nur die ntuser.dat. Danach meldet sich der User neu an, startet Outlook, das merkt, dass noch nix konfiguriert war und los geht's mit Einrichtung. Also speichert doch Outlook irgendwas in der ntuser.dat. Wie soll das mit einer MAN funzen?? Meines Wissens werden nicht mal Änderungen im Profil (Recent, Desktop o.ä.) gespeichert, wenn der User mit einer MAN arbeitet. Bin ich da irgendwie auf dem Holzweg? werd ich jetzt Off-Topic? Thomas

Sollte sich was positives bzgl. Lösung ergeben, bitte mal posten. Vielleicht sucht ja später auch noch jemand anderes eine Lösung zu diesem Problem. Thomas

neben der Angabe eines Exchange-Servers kannst Du ebenso noch weitere Internetdienste einrichten (Extras - Dienste - hinzufügen - InternetMail). Mit zwei eingerichteten Profilen, Startart: zu wählendes Pofil, sollte das funzen. Dem einen Profil verpasst du den Exchange-Server. Dem anderen Profil den InternetMail-Dienst. Je nach dem, wie du die Mail absenden willst, wählst du bei der Outlook-Anmeldung das eine oder das andere Profil. Ist das zu umständlich, dann nur ein Profil benutzen und diesem beide Dienste (Exchange-Server und InternetMail) zuweisen. Vor dem Absenden irgendwo unter Extras - Dienste - Reiterkarte Übermittlung, kannst du die Reihenfolge=Wertigkeit der Transportdienste definieren (hoch-/runterstufen) Steht der Exchange-Dienst oben, gehts über Exchange raus, steht InternetMail oben, eben darüber. Müsste eigenrlich ohne neue Outlookanmeldung funzen. Mal checken... Thomas

naja, so differenziert kenne ich das nicht. Sind es definitiv ÖO's auf deinem Server? Oder kommen die von einem anderen Server in der Organisation (falls mehrere benutzt werden)? IIS und SSL in Benutzung? Kannst du wenigsten über die Eigenschaften des ÖO rausbekommen, wer der Benutzer war? mmhhh, denke denke... bringt aber auch nicht viel, wenn du den User neu anlegst und dann den ÖO killen willst. Falsche UID und SID o.ä. tippe ich. Auf jeden Fall würde ich als erste Maßnahme Dein ÖO-Root-Verzeichnis so berechtigen, dass nur der Exchange-Admin berechtigt ist, ÖO's anzulegen. Wenn das jeder User kann, könnte dir irgendwann der Server überlaufen! Kannst du andere ÖO deines Servers vorhandener User administrieren, oder kommt da der selbe Fehler? Mal mit den Fehlernummern ein bissel "googeln". Von doppelten, ausgetauschten Netzwerkkarten usw. bis LDAP oder SSL-problemen kommt da alles. tzz tzz (hilft wohl nicht weiter) Vielleicht hilft der Link: http://support.microsoft.com/default.aspx?scid=kb;en-us;324345 Thomas

so ein ähnliches Verhalten kenne ich von NT-Client's. Kommt meisst vor, wenn der PC einen harten Absturz hatte. Dadurch wird ja das lokale Profil nicht gelöscht. I.d.R. sollten nach einem Neustart alle File-Looks abgebrochen sein. Aber ab und zu (nur M$ weiss warum) hält das OS noch Dateien des Profils als "in Benutzung". Da es das neue Profil nicht neu anlegen kann, da noch "blockiert", zählt es einfach die Profile hoch (.001, 002 usw). Oder es legt ein "bak"-Profil an (hatte auch schonmal ein "sic"-Profil gesehen!?). Welches das aktuelle Profil ist, kannst Du am besten mit den Datei/Verzeichnis-Datumsen (ich weiss, Daten ;) ) checken. Bringt aber nicht viel. Das BAK wird das Neuere sein. Zur Sicherheit auf jeden Fall (!!) ein zweites Konto mit Adminrechten anlegen, bevor du irgendwas experimentierst. Und sich auch mit dem Konto mal anmelden, um zu checken, dass auch alles Admin-mässig funktioniert! Übrigens hatte ich auch mal ein solchen Verhalten (hochzählen) mit einem WIN95-OS. Ursache. Die win.ini hatte ein bestimmte Zeilenzahl erreicht. Irgendwie konnte W95 da nix mehr reinschreiben (lokale Profile, irgendwas mit den Passwörtern der User) und hat einfach ein Profil permanent hochgezählt. Bevor ich das mitbekam, war das Profil auf knapp 300 hochgezählt. Witzig, nicht?? Zu 99% liegt dein Problem darin, dass eine neue Adminanmeldung nicht in das Orginalprofil schreiben konnte. Thomas

Wer so einen Patch-Schrank mal gesehen hat, weiss wohl eher, was raveman sucht. ipconfig ist ja nicht übel, auch tracert o.ä. Damit weiss ich er aber immer noch nicht, an welchen Switch-Port das Endgerät hängt. @raveman - wenn ich mich nicht sehr täusche, liegt den meissten Cisco-Switchen eine/mehrer CD's bei. z.B., um die Switche zu konfigurieren, Ports zu sperren, Gruppen zu definieren usw. Auf diesen CD's sollte sich doch irgendwas finden lassen zum Monitoring. Ansonsten mal direkt bei Cisco auf die WEB-Site gehen. Kann mir nicht vorstellen, dass die sowas nicht anbieten. (Hatte mal ne pimpige HUB von Cisco, selbst da war sowas dabei) Thomas

@Wildi - damit würde ich vorsichtig umgehen! z.B. wird in folgendem Konstrukt FOR %%x IN (1,2,3,4) DO echo %%x das doppelte % zwingend benötigt. Würde man ausserdem Deiner Logik folgen, müsste ich zur Darstellung des Zeichens > dafür ein >> notieren. REM hier soll als Text [b][i]Drei "ist groesser als" Zwei[/i][/b] dargestellt werden echo Drei > Zwei :: ergibt den Text [i]Drei[/i] umgeleitet in eine Datei namens [b]Zwei[/b]. Eine bestehende Datei [b]Zwei[/b] wird gelöscht und neue angelegt. :: naechster Versuch nach o.g. Logik echo Drei >> Zwei :: schreibt den Text [i]Drei[/i] eine Datei namens [b]Zwei[/b]. :: eine bestehende Datei wird erweitert. Falls sie nicht existiert, neu angelegt. Wie du leicht feststellen kannst, geht deine Lösung meisst nicht auf :( Zum "maskieren" von Zeichen mit besonderer Bedeutung (z.B. | [Pipe-Symbol], &, >, % ) in Batch-Dateien (bat und cmd) ist die Variante von real_tarantoga sicherer. Als "Maskierungs"-Symbol wird das ^ (Zirkumflex oder zu deutsch: Dachsymbol) benutzt. Man muss dabei nur beachten, dass man dieses Symbol nicht einfach so eingeben kann. Das Zirkumflex wird einmal eingegeben, gefolgt von dem zu maskierenden Zeichen. Also ^ tippen, danach > eingeben. echo Drei ^> Zwei gibt auf dem Screen Drei > Zwei aus. Und als Tipp nebenbei: Im obigen Codeschnippsel siehst Du nur einmal das REM. Damit werden ja bekanntlich Kommentare in Batchen notiert. In längeren Batches ist statt REM der doppelte Doppelpunkt :: günstiger. Hintergrund: Der Batchinterpreter "liest" eine Kommentarzeile bei REM bis zu Ende, um sie dann als Kommentar zu interpretieren (benötigt Zeit). Bei :: wird die Zeile sofort als Kommentar "erkannt" und übergangen. Bei gut kommentierten Batches mit vielleicht 2.000 Zeilen Quellcode und mehr (hab ich schon gesehen!) machen sich die eingesparten Lesezeiten der Kommentar schon bemerkbar. Thomas

tzz, tzz, immer diese Witze über meinen Namen :( (was kostet ein Vornamen-Wechsel??) Im Ernst, Ungläugibkeit ist doch eine gute Eigenschaft. Solange mich keiner mit stichhaltigen Argumenten vom Gegenteil überzeugt, zählt meine Meinung. Sind die Argumente okay, bin ich der Letzte, der nicht eine neue Meinung annimmt. (...bisher war es hier im Board ziemlich "stichhaltig"!) Zu klausk's Zitat: Wenn ich das richtig übersetze, ist es so, dass NT die NETLOGON und die lokale Version nach bestimmten Kriterien überprüft und nur runterlädt, wenn es Differenzen gibt. Ansonsten wird das lokal vorhandene Default User (Network) verwendet. Ist eigentlich logisch, verhindert Traffic. Damit dürfte sich der Test eigentlich erledigt haben. Kanns ja trotzdem nochmal checken. Danke für die Tipps, weiter so... Thomas

CAN TAAAAA LE O O das ist ja der Hammer :D Thomas

wie bzw. auf welche freigabe greifst du zu?

Für alle, die hier mal drauf stossen! Es funktioniert echt. (jedenfalls unter NT4) Habe einfach auf einem Client ein "Default User"-Profil sauber zurechtgestutzt (Startmenü, SendTo, usw.). Den Ordner in das Export-Replikationsverzeichnis auf dem PDC kopiert. Von hier aus repliziert. Meldet sich ein neuer User in der Domäne an, welcher vorher noch kein servergespeichertes Profil hatte, zieht der aus dem NETLOGON die Einstellungen des dortigen Default User. Wird diese "Neuanmeldung" auf einem Client durchgeführt, auf dem vorher dieses Verfahren noch nicht angewandt wurde, liegt hier ein neues Profil unter %SYSTEMROOT%\Profiles. Dieses heisst dann Default User (Network). Dass es geklappt hat, kann man ganz easy damit checken, indem man mal fix die Inhalte der drei Profile Default User, Default User (Network) und das des angemeldeten "Neu-Users" vergleicht. "Neu-Users" und Default User (Network) sollten in wesentlichen Teilen den gleichen Inhalt haben (z.B. Favoriten, oder ein angepasstes Startmenü). Frage: gem. obigen Beispiel - wird das jetzt auf dem Client liegende Default User (Network) bei einer Änderung des Default User auf dem Quell-NETLOGON bei der nächsten Anmeldungen eines neues Accounts angepasst, oder zieht der neue Account das auf dem Client, jetzt lokal vorhandene, Default User (Network)? Ansonsten, Danke für den Tipp Thomas

na, wasser-auf-tastatur-schütt oder -kühlung-einbau- ;) aber eeeehrlich, bin ich nur manchmal so b***d? ich verbieg mich tlw. mit for-schleifen und if-else-anweisungen in cmd-dateien. und dabei ist das mit excel echt easy. manchmal sieht man doch den wald vor lauter bäumen nicht. also, klares bienchen für den excel-exkurs! Thomas

dankeee! dann bleibt mir nur, betreffende servergespeicherte Profile zu löschen. dann müssten ja die neuen Default Users gezogen werden.

lade dir mal die Free-Version von Hyena, genannt "Exporter". Die kann das alles in eine Datei exportieren. Link: http://www.systemtools.com/free.htm Thomas

:rolleyes: wenn dein problem gelöst ist, auch gut. Aber nochmal zur Fehlervermeidung: Unter NT gibt es beide Parameter! /COMMENT ist der Eintrag, den du im Benutzermanager im Feld "Beschreibung" wiederfindest. /USERCOMMENT wird nicht im Benutzermanager wiedergegeben, wohl aber auf der Kommandozeile. Somit kann der Admin z.B. recht einfach im NT "versteckte" Eintragungen zum Benutzer (z.B. Personalnummer o.ä.) tätigen, die nicht jeder gleich sieht. bei deinen bisher beschrieben Befehlen vermisse ich immer was! Wenn ich das bisher richtig interpretiert habe, gehts dir um die Umstellung deiner Domänen-SAM. Wenn du die Befehle so absetzt, wie oben, dann wird das nur auf dem lokalem PC in der lokalen Benutzerverwaltung erledigt. Richtigerweise müssten deine Befehle immer um die Option "/domain" erweitert werden, damit die Änderungen in der Domänenbenutzerverwaltung durchgeführt werden, z.B.: net user mueller /COMMENT:"Blabla" /USERCOMMENT:"bloblo" /domain führt dazu, daß beim Benutzer der Kommentar "Blabla", sowie der "DOS-verfügbare" "bloblo" eingetragen wird. Kontrolle per net user mueller /domain | more Dann müsstest du beide Eintragungen sehen. Und jetzt mal für mich. Wie bringst du Excel dazu, zu scripten? so mit Spalten dazu, neue Befehle und Script erstellt? Irgendwie stehe ich da jetzt auf dem Schlauch Thomas

so einen ähnlichen Effekt gab es mal nach der Installation von Corel 10. Da ging immer die SYSTEMROOT als DOS-Fenster auf. War ein falscher Eintrag im RUN-Schlüssel. Suche doch einfach mal in der Registry nach dem angegeben Pfad. Sollte der als Wert im RUN-Key auftauchen, könnte man ihn einfach löschen. Notfalls einfach mit F3 weitersuchen, ob der pfad noch irgendwo auftaucht, wo die Schlüssel was mit dem Start zu tun haben. Die dann auch killen. Aber Obicht! Nicht die Eintragungen, die direkt auf den ATI-Treiber verweisen, löschen. Ansonsten könnte deine ATI nicht mehr funzen ;) Ich tippe aber auf irgendeinen RUN oder RUNONCE-Eintrag. Thomas p.s. und mal auf der ATI-Website nachschauen, vielleicht gibts da ja schon einen neuen gefixten Treiber oder ein Bugfix.

jetzt arbeite ich schon seit zig Jahren mit NT4-Domänen und ärgere mich über die DefaultUser auf den unterschiedlichen Kisten ab, und dann sowas. Wer lesen kann ist also doch klar im Vorteil ;) @grizzly999 - welche Rechte muss der Ordner "Default User" im NETLOGON haben? Reicht da "Lesen", damit sich die User den ziehen? Ich will verhindern, dass irgendein Schelm da nochwas reinschreibt. Quatsch Kommando zurück - NETLOGON sollte ja per default sowieso nicht änderbar für normale User sein, gelle!? Aber wie ist das bei Usern, die wohl bereits ein Server-gespeichertes Profil (mit allen mistigen DefaultUser-Einstellungen), aber auf den Clients kein lokales haben? Ziehen die auch die neuen "Default User"-Ordner? Und... kann man das selbe Verfahren auch für W2k bzw. XP-Domänen anwenden? Thomas