himbidas

Irgendwann müssen wir doch mal in Stand-By. Wann soll denn sonst der letzte das Licht ausmachen?

Aber nochmal zu meiner Frage. Kann man diese beiden Schlüsselinhalte gefahrlos löschen?? Damit könnte ich das permanente Aufblähen der Registry mindern. Oder?? Thomas

@ThaWild du hast, wenn ich das richtig sehe, 549 Postings. Woher soll ich dann wissen, was dein 2. posting ist Neeee, im Ernst, hast ja Recht. Ist alles relativ. Selbst bei anderen OS'en, selbst Open-Source, weiss doch kein Aas mehr, was die alles machen. Und selbst wenn es rauskommt, scheint sich keiner soooo groß daran zu stoßen. Da gab's (gibt's) z.B. eine große Datenbank-Softwareschmiede, Bor-so-und-so. Die haben, nach verläßlichen Fachpresseberichten, über Jahre in jede Datenbank ein Hintertürchen eingebaut, über welches sie auf jede DB weltweit, soweit im Netz verfügbar, zugreifen konnten. Irgendwann kam es raus, Türchen wurde geschlossen (in neuen Produkten), Firma lebt immer noch. Und dieses ganze M$-Geschnüffel, mit User-Assistanz bemäntelt, wird auch der Firma nicht das Genick brechen. Irgendwann müssen wir uns wohl alle daran gewöhnen "gläsern" zu werden. Irgendwann leben wir alle in der Matrix. Thomas

clever der Azubi, echt cleeeever ;) ;) ;) [edit] clever der Praktikant, echt cleeeeever :D :D :D [/edit]

hier noch ein kleines FOR-Script. z.B. um zu sehen, wie man die FOR-%%-Variablen mit normalen Variablen zusammen verarbeitet. Das Script benutzt das Ressourcekit-Tool isadmin.exe. Damit kann man prüfen, ob ein angemeldeter Benutzer Adminrechte hat, oder eben nicht. Da ich gerne Bescheid weiss, wer in meinem System wo und wann mit Adminrechten rumgeistert, schreibt das Script für jeden Adminaccount eine eigene Datei auf einer versteckten Freigabe eines Servers fort. Darin steht dann, auf welchem PC und wann sich der User angemeldet hat. So kann man leicht nachvollziehen, ob Adminpasswörter korrumpiert wurden. Bist du als einziger Admin nachts nicht da, das Log zeigt aber 23:40 uhr einen Adminzugriff auf PC xy, müsste man mal nachhaken. setlocal FOR /F "tokens=*" %%i IN ('date /t') do set a=%%i FOR /F "tokens=*" %%i IN ('time /t') do set b=%%i FOR /F "tokens=2" %%i IN ('isadmin') DO if "%%i"=="is" (echo %COMPUTERNAME%, %a%, %b%) >> \\server\freigabe$\admin_%USERNAME%.txt 2>nul endlocal Thomas

wenn die Weiterverarbeitung nicht in einer Zeile reicht, rufe doch einfach mit call batch.cmd eine weitere Unterroutine auf. Die wird abgearbeitet und nach deren Schluss kehrt sie zurück (wegen call). Müsste eigentlich funzen. Ist nur ein bissel schwierig, Variablen an den Call zu übergeben. Habe auch mal irgendwo gesehen, dass in CMD's quasi eigene Subroutinen möglich sind FOR /F %%a IN (server.txt) DO call:sub1 goto:end :sub1 ping -w 1000 -n 1 %%a | find "Antwort" 1>nul 2>nul if %ERRORLEVEL%==0{ rem hier wäre alles i.O. rem mache hier was ok macht} else { rem das wäre der Fehlerfall net send zumir %%a ist nicht erreichbar } :end Unterschied | und || einfacher Pipe | - verbindet zwei Befehle: ping server | find "string" Befehl 1 pingt server an. Die Ausgabe des 1. Befehls wird vom 2. Befehl "find" als Eingabe gewertet und entsprechend bearbeitet. Doppel-Pipe || - ist das Gegenstück zu && && Befehl wird abgearbeitet, wenn vorhergehender Befehl erfolgreich war net use x: \\server\freigabe && echo Netzlaufwerk verbunden... Gibt "Netzlaufwerk verbunden..." aus, wenn es verbunden wurde, ansonsten nix. || Befehl wird abgearbeitet, wenn vorhergehender Befehl NICHT erfolgreich war net use x: \\server\freigabe || echo Geht nicht, Laufwerksbuchstabe bereits in Benutzung... Gibt im Fehlerfall was aus, ansonsten nix. Dabei ist aber anzumerken, dass der Zustand, wann ein Befehl erfolgreich oder nicht war, recht unterschiedlich ist. Man muss da immer ein bissel experimentieren und für die Entwicklung mindestens beide Zustände simulieren, damit man auch weiss dass alles so eintritt, wie man will. Thomas

wenn sich M$ nicht dafür interessiert, wozu dann der Schlüssel bzw. die gesammelten Informationen? Und ausserdem ist das auch egal, ob Interesse oder nicht. Es geht um "Privatsphäre" und deren Schutz.Out-Boundfirewall, ha ha ha... solange du nur einen Port offen hast, wer sagt dir dann, was da durch geht? Wenn M$ solcherlei Daten (unbemerkt für die breite Masse) sammelt, werden die sehrwohl in der Lage sein, diese auch einzusammeln. Oder weisst du, was jede DLL, jedes "Sicherheits"-Update oder sonstwas anstellt? Nix gegen DEINE Meinung, aber dieses Vorgehen von M$ ist doch wenigstens, Thread-konform suspekt Thomas

nee nee, geht schon klar. Hab's verstanden ;) Thomas

na ja :shock: nur mal so, um's ins Hinterstübchen zu schieben. Ich hatte mal einen Exchangeserver, der hat innerhalb von knapp drei Monaten 14 GB Transaktionsprotokolle erzeugt. Auf der Kiste war aber Mail-mässig nix gross los. Das ist alles noch am Werden. Irgendwie hatte sich da keiner drum gekümmert, irgendein bloeder Backupfehler löschte die Protokolle nicht und -schwupps- liefen die Partitionen voll. SO fix kann das gehen... Thomas

Du scheinst den Sinn der Frage missverstanden zu haben. Die PC's sollen nur bessere Schreibmaschinen sein/werden. Wozu dann in teure neue Hardware investieren. Bei EDO-Preisen von 1-5 EUR pro 64MB (kommt auf das Schnäppchen an ;) ), kann man auch mal einen Ausfaller verschmerzen. Auf jeden Fall, wenn die Teile NT bekommen sollen, gehört Speicher rein. 64 MB ist mindestens notwendig. Auch wenn "nur" Word läuft (Word ist speicher- und ressourcenhungrig). Läuft darauf noch ne Antivirensoftware, oder andere Hintergrundsoftware, könnens gerne auch nochmal 64 MB sein. Aber wie gesagt, EDO kostet (fast) nix mehr. Also rein damit... Thomas

Das wäre meine zweite Alternativantwort gewesen ;) Alles dem Azubi erzählen, ihm das Kabel in die Hand drücken und auszählen lassen. Wenn's dann schief geht, kann ich die Schuld prima auf den Azubi abwälzen :D ;) :D Ich dachte nur, Whissler hatte Bedarf daran, das selber zu können und zu machen. Natürlich kann man auch unliebsame Arbeiten auf andere abdrücken. Daaaaaaaaas geht auch... :suspect: Thomas

Hi Nick22 mit welchem OS arbeitest du denn? Ab NT4 würde ich dir empfehlen, anstatt BAT-Batches alles in CMD's zu verarbeiten. Der 32Bit-Kommandointerpreter CMD.EXE, der beim Aufruf von z.B. test.cmd bemüht wird, ist mächtiger und kann mehr. net send ist (wenn ich mich nicht täusche) in der Lage, Variablen zu verarbeiten. Teste doch mal folgendes: @echo off set nn=Nick22 net send meinpc Mein Name ist %nn%. meinpc wäre dabei der Name deines PC's ;) Für dein Problem mit der Anzahl zu prüfender Server wäre eine FOR-Schleife anzuwenden. Alle zu prüfenden Server trägst du in eine Textdatei (z.B. server.txt) ein. Für jeden Servernamen ein eigene Zeile. In der "Check-CMD" werden die dann alle nacheinander abgefragt: FOR /F %%a IN (server.txt) DO ping -w 1000 -n 1 %%a | find "Antwort" || net send meinpc Server %%a ist nicht erreichbar. Was macht das Teil? Die For-Schleife holt aus der server.txt zeilenweise jeden Servernamen raus und packt ihn in die Variable %%a (jaja, zwei %-Zeichen müssen sein in Batches), pingt diesen dann jeweils an und sucht in der Ping-Antwort den String "Antwort". Ist alles okay, passiert nix. Wird der String nicht gefunden, erfolgt weitere Verarbeitung nach dem Doppel-Pipe (||). Musst halt mal die Hilfe zu FOR, sowie die Hilfe zu Verkettungssymbolen lesen (&& = Weiterverabeitung, wenn vorangegangener Befehl erfolgreich; || = Weiterverarbeitung, wenn vorangegangener Befehl Fehler lieferte). Man muss da ein bissel testen, da das Verhalten von FOR-Schleifen mit gepipten Befehlen (hier: find) tlw. eine eigenartige Verarbeitung mit sich bringt. Kann das hier leider nur theoretisch aufzeigen. Hab hier kein NT oder XP zur Hand und bin bis Ende des Jahres im Urlaub. Vielleicht kann ja ein anderes Forenmitglied dazu noch was Brauchbares beitragen Thomas

na, das ist klar, dass nach einen Restore die gleiche Anzahl an Objekten wieder in diesem Postfach auftauchen. Kannst du nicht über die Datensicherungssoftware, wenigsten mal interessenhalber, rausbekommen, was das für 1000 Objekte sind? Vielleicht kommst dadurch auf des Rätsels Lösung. Ich hatte mal ein ähnliches Erscheinungsbild. Ursache könnte folgendes gewesen sein: Wir hatten zuerst Outlook98 laufen, mit Microsoft-Postoffice, jeder User hatte ne eigene PST-Datei auf einem UNIX-Netzlaufwerk. Ein User hatte ne Menge Terminserien (ohne Endedefinition)(Geburtstage der Belegschaft) eingetragen. Nach Umstieg auf Outlook2000 und Exchange 5.5 wurden die PST's abgeschafft (zuviel Netzlast usw.). Durch das Importieren der Termine aus der PST-Datei und (wahrscheinlich) gleichzeitiger "Konvertierung" ins Outlook2000-Format kam es auch zur Anzeige im Exchange-Postfach von 1200 Objekten bei einer Postfach-Verbrauchsgrösse von 100kB (oder so). Erst, nachdem der User die Termine alle rausgeballert hatte, bzw. für die Terminserien ein Ende eingetragen hatte, ging die Anzahl drastisch runter. Thomas

Na gut, jetzt weisst du wenigstens so ungefähr, woran es liegt. Bei knappen Plattenplatz eine grössere Platte reinzuhängen, ist eine Möglichkeit. Das wird aber auf Dauer dein Problem nicht lösen. Wenn du, wie du sagst Exchange im Verdacht hast, dann würde ich da mal so langsam ansetzen. Unter Umständen werden deine Transaktionsprotokolle nicht sauber nach einer Datensicherung gelöscht o.ä.. Auf jeden Fall solltest du mal die Log- und Datenbankeinstellungen checken und mal der Sache auf den Grund gehen, warum da immer weniger Platz zur Verfügung steht.Ansonsten schreibt du spätestens in 14 Tagen den nächsten Thread, weil dein Exchange nicht mehr läuft ;) Thomas

na toll, da wird ja aaaalles mitgeloggt. wie ist das jetzt? kann man die Einträge unter den jeweiligen Count-Schlüsseln löschen? Habe übrigens Win-ME und da funzt der NoEncrypt-Eintrag auch, alles schön im Klartext :mad: Thomas

nach dem Löschen und Neuanlegen wieder 1000 Objekte?

EDO's bekommst du doch an jeder Ecke nachgeworfen. Lass deinen Chef mal 100 EUR locker machen, dann kannst du deine Clients fürstlich upgraden. Schau doch mal bei dem bekannten Auktionshaus vorbei. Da wirst du bestimmt günstig fündig. Thomas

Hilfe, da guckt mich ein Viecht aus dem Kuchen an ...

naja, wie sieht denn deine "server.bat" aus? möglich wäre z.B. folgendes: zu testenden Rechner kurz anpingen, das Ergebnis auswerten und entsprechend reagieren, z.B.: ping -w 1000 -n 1 192.168.1.1 | find "Antwort" 1>nul 2>nul goto:SPRUNG1%ERRORLEVEL% :SPRUNG10 rem hier wäre alles i.O. goto:SPRUNG1 :SPRUNG11 rem das wäre der Fehlerfall net send zumir "192.168.1.1 ist nicht erreichbar" :SPRUNG1 Deine "net send"-Geschichte hat aber den Nachteil, dass du entweder angemeldet sein musst (wenn "zumir" dein LOGIN ist), oder wenigstens dein PC laufen muss (wenn "zumir" dein Rechnername ist). Um, je nach Fall, das netsend nicht zu "verlieren", müsste dieser Zweig u.U. auch noch verfeinert werden. Also checken, ob net send erfolgreich war, wenn nicht, andere Möglichkeit realisieren (z.B. ein Textpaket auf eine versteckte Freigabe eines Servers legen lassen. Diese Freigabe prüfst du als Admin zyklisch , ob da was aufgelaufen ist). Thomas

Versuche, deinen Bildschirmtreiber auf Standart-VGA zu bringen und danach wieder auf deinen orginalen (oder einen neueren). Spätestens danach müsste des sture OS anfangen, die Fenster neu zu berechnen. Thomas

Quatsch, wozu nen Praktikanten oder Azubi? Wenn der mit seiner Nicht-Ahnung und seinen ungelenken Fingern dazwischen rumfingert, geht's definitiv daneben! Also, der Link von Damian zur Zählweise der Paare ist schonmal Gold wert. Ausserdem sind die beschriebenen Hinweise dazu fast die halbe Miete. 50 Paare sind auch nicht sooo viel, ist machbar. Wie geht man am besten vor: #1 Kabel min. 20 cm abisolieren (nur den PVC-Mantel) Geht am besten, wenn man ein bissel am Anfang mit nem Messer abisoliert, bis man den Perlonfaden erwischt. Diesen dann fassen (mit Zange wickeln) und dann den Rest des Kabels in der gewünschten Länge aufreissen - #2 an der "Spitze" die Folie (Metall und Plaste) abzwusseln und die Spitze mit einem Restdrätchen fixieren (umwickeln) - #3 den Rest der Metall- und Plastikfolie abfummeln - #4 den Massedraht am Ende um den Stamm wickeln - #5 in der Hälfte des abisolierten Stammes nochmal eine Fixierung mit Restdraht vornehmen - #6 hat man lang genug abisoliert, fällt auf, dass die Paare immer schon miteinander verdrallt sind - #7 sollte man mal ein Drallpaar verlieren, findest du es spätestens nach der "Halbfixierung" wieder - #8 Stamm in rechte Hand nehmen, Spitzenfixierung entfernen - #9 mit linkem Zeigefinger das 1. Paar rt/bl zur Seite biegen und am Anfang nochmals fester verdrallen (damit's nicht verloren geht) -#10 je nach dem, welches Ende vom Kabel du erwischt hast, gehts dann links oder eben rechts rum #11 nächstes Paar ge/ws mit li. Zeigefinger wechbiegen, weiter wie 9 - #12 bist du bei sw/ws angekommen, sollten es 5 Paare sein, diese mit dem rt/bl-Paar umwickeln und ganz zur Seite legen. Damit hast du die erste Lage ausgezählt - #13 jetzt Paar bl/ws, ge/ws usw. bis wieder fünf beisammen. Die mit dem dem ge/ws-Paar umwickeln. Ist dann Lage zwei. - #14 sollte wirklich mal ein Paar aufdrallen, dann vorsichtig bis zur Halbfixierung verfolgen und nachsehen, ob es das richtige Paar ist; notfalls korrigieren. Auf jeden Fall sollten die paar Paare nicht so kompliziert werden. Sieht nur am Anfang ein bissel verwirrend aus. Nie zu geizig abisolieren, zählt sich leichter aus, wenn man mehr "fassen" kann und genug "zum sehen" hat. Thomas

Zielt deine Frage darauf ab, ob auf Platte 2=E: die lsass.exe liegt? Dann checke doch einfach die Platte, ob diese Datei dort liegt. Hast du die Profile im Verdacht, sehe auf der 2. Platte nach und checke, ob der angemeldete User ein Profil auf dieser Platte benutzt. Wenn ja, verbiege ihm sein Profil testweise auf (bei dir) D:, bilde alles wieder nach und prüfe, ob der Zustand wieder auftritt. Dann weist du auf jeden Fall, ob es am Profil liegt. Zur eigentlichen Frage: Eigentlich werden keine Systemdateien "ausgelagert". Wozu auch? Die sind doch schon per Installation vorhanden, haben also ihren Platz reserviert. Abgesehen davon -> dein Kundenserver scheint am Rande des Machbaren zu laufen. 30MB freier Platz auf Systempartition ist nah am *ich-stell-mal-gleich-meine-arbeit-ein*. Wenn ich deine Kundenkonfiguration richtig interpretiere (E2K = Exchange2000?), tippe ich mal darauf, dass die Logs überlaufen und die Kiste bald stehenbleibt, inclusive krasser Exchange-Fehler! Thomas

und wenn du dich mit dem Scriptomat vertraut gemacht hast, bist du hier schon ziemlich nah an der Lösung http://www.microsoft.com/technet/scriptcenter/user/default.asp Thomas

vielleicht hilft dieser Link weiter: http://support.microsoft.com/search/default.aspx?Queryc=Datenbank+konnte+nicht+ge%C3%B6ffnet+werden.+F%C3%BCr+die+Datenzugriff+ist+ADO+%282.5+oder+h%C3%B6her%29+erforderlich.&Query=Datenbank+konnte+nicht+ge%C3%B6ffnet+werden.+F%C3%BCr+die+Datenzugriff+ist+ADO+%282.5+oder+h%C3%B6her%29+erforderlich.&srch=sup&catalog=LCID%3D1031%26CDID%3DDE-KB%26PRODLISTSRC%3DON&Product=msall&KeywordType=ALL&Titles=false&numDays=&MaxResults=25&srchstep=1&InCC_hdn=True&querySource=gASr_Query Thomas

Das kopieren nach lokal kann man sich nach meinen Erfahrungen sparen. Habe schon eine Unmenge an Clients mit dem ePo-Agent in dieser Form versorgt:\\server\versteckte-freigabe$\framepkg.exe /install=Agent /s /InstDir=c:\epoagent Ausser bei den Maschinen, die keine DNS-Auflösung eingeschaltet hatten (wurde dann nachgeholt) hat es immer gefunzt. Eine weitere Voraussetzung war, dass die Installation mit Adminrechten erfolgte. NormalUser haben bei uns keine Rechte was zu installieren, wenn es die Registry beschreibt. Thomas