grizzly999

Von einem zentralen Rechner aus (möglicherweise sogar mit Batch-Datei und "for .... " Befehl) mit netdom /renamecomputer. Näheres sieh Hilfe zu netdom.exe ;) grizzly999

Kurz und knackig: Nein grizzly999

Das hattest du doch in der Domain Policy eingetragen (die auch auf dem DC ziehen sollte, so er nicht was anderes drin haben sollte. Zum Anderen: das Recht wird normalerweise an die Gruppe "Administratoren" vergeben, nicht an DEN Admnistrator und auch nicht an die Domänen-Admins ;) grizzly999

Sysprep ist da der Ansatz. Schaue auch mal hier rein: http://www.mcseboard.de/showthread.php?t=90812 grizzly999

Er müsste die älteren Files irgendwann löschen und dann den freien Platz neu betanken. Allerdings empfiehlt Microsoft (bei nicht R2) max. 64 Gb oder 500.000 Objekte für FRS und drüber hinaus den Einsatz von robocopy. http://support.microsoft.com/kb/264822/en-us grizzly999

Davon kann man nicht unbedingt ausgehen, hatte auch schon defekte Speicher aus der Schachtel. Die RAMs erst mal einzeln testen, evtl. mit Speichercheck-Programm. Dann wie lefg schon sagte, Handbuch des MB lesen, was da zum Thema RAM drin steht. Auf jeden Fall müssen auf den neueren Boards die Paare entsperchend auf den paarigen Sockeln gesteckt sein, meist farblich gekennzeichnet (bzw. auch im Handbuch schauen). Das könne die beiden nebeneinander liegenden Bänke sein, oder jeweils Bank 1+3 und 2+4. Also, Handbuch lesen, und ggf. RAM einzeln testen. grizzly999

130 GB?! Huii. Du schreibst von FRS, das ist also nix R2, ja? Bei 130 GB zu replizieren solltest du aber den Staging Bereich mächtig groß machen (Def. 660MB), sonst geht da nichts mehr mit Replikation. Sollten dann aber auch Einträge im Log zu finden sein. Siehe auch: http://support.microsoft.com/kb/264822/en-us grizzly999

Das muss dein Provider machen grizzly999

Was meinst du damit MIt Sicherheit ist dein Router nicht so eingestellt, dass er den VPN-Verkehr zum Server weiterleitet (dabei ist nicht mal klar, was für ein VPN, naja, sind wir schon gewohnt hier). grizzly999

Aber nur, wenn man die Remoteverwaltung (HTML) wie von workaholic beschrieben installiert hat. Default bietet das der IIS nicht. grizzly999

Der Client holt die Updates irgendwann innerhalb von 22h nach Feststellen dass es welche gibt (s. SUS-Whitepaper). Normalerweise geht das aber innerhalb von 10-30 min. Das entscheidet auch der BITS mit. grizzly999

Rein technisch ist weder C noch D richtig. Egal aus welchem Cache der ISA das Zeugs holt, oder gar aus dem Internet, rüber muss es in die Zweigstelle. Ob Cache weg, oder mehr RAM-Cache oder mehr Plattencache, die Bandbreite zur Zweigstelle wird mit nichts davon optimiert. Da würde nur ein Proxy in der Zweigstelle helfen. Wenn allerdings die Bandbreite des ISA ins Internet aufgrund der Zweigstellensurfer gemeint wäre, dann würde eine Vergrößerung des Caches helfen, dann wäre C richtig. grizzly999

Du bist mit deinem Rechner nicht über RLL-Platten hinausgekommen, oder ?! :D :D grizzly999

Für alle Objekte im Container ..... grizzly999

Ja, ich mache den jetzt zu, denn es scheint Leute zu geben, die nichts besserers zu tun haben, als ****sinnige Antworten zu geben, was anderes kam ja in dem Thread nicht. Wer dazugehört, such e sich einen anderen thread oder besser noch .... Wenn doch jemand die Site kennt, dann PN an mich, ich füge die dann ein grizzly999

Das ist auch nicht der ISA mit seinen Logs dafür zuständig, sondern der Routing und RAS Dienst auf dem ISA. Sofern keine RADIUS-Authentifizeirung, im RRAS unter RAS-Protokollierung in den Eigenschaften der Lokalen Datei die Protokollierung von Kontoführungsanforderungen und Authentifizierungsanforderungen einschalten. Standardordner ist %windir%\system32\logfiles Da Log kann man einigermaßen gut mit dem Tool iasparse.exe -f:<logfilename> auswerten grizzly999

Ja, das ist richtig. Die verschoeben Konten solletn dann auch wieder in der vorigen OU sein, die autorisierend wiederherstellt wurde, wegen jetzt höherer USN. grizzly999

Du hast nur einen DC?! Aber nache iner Wiederherstellung des AD aus einer Sicherung müssten auch die verschobenen Objekte nicht mehr da sein, wo du sie hin verschoben hattest, sondern da, wo sie bei der Sicherung waren :suspect: grizzly999

Schau auch mal hier rein wegen dem Standardgateway, unten im Thread ;) grizzly999

... und da braucht man X.509 Zertifikate und der Empfänger auch. grizzly999

Natürlich wird dir hier geholfen, aber naja, was hast du denn groß verstellt? Kann nichts so wildes sein, das man nicht wieder hinbiegen kann, denke ich. Ein großes Problem scheint das DG zu sein. Pasiert das immer noch, dass das falsch eingetragen wird, und wenn ja, wann passiert das? Hast du die Karte im Gerätemanager mal vollständig deinstalliert und neu installiert? grizzly999

Die Kompelxitätsanforderungen auch schon explizit deaktivert, also nicht einfach auf "nicht konfiguriert"? grizzly999

Welche IP stimmt denn jetzt, die die im DNS drin steht oder die, die tatsächlich angepingt wird? Der DNS gibt keine falsche IP aus, er gibt die IP zurück, die er hat. Es scheint mir mehr, dass dein Client gar nicht den DNS fragt, oder nicht DEN DNS (der die richtige IP hat). Dazu erst einmal mit ipconfig /all überprüfen, ob der Client den korrekten DNS hat. Dann in der lokalen Datei Hosts schauen, ob da ein alter Eintrag drin steht. Die Befehle wie oben von Christoph35 genannt ausführen. Dann ping auf den vollen FQDN des Clients. Was ist das Resultat? grizzly999

Bei einer unattended Installation mit einer Antwortdatei und einer .udb-Datei geht das, aber nicht bei einer unbeaufsichtigten CD-Installation grizzly999

Wenn das AD nicht mehr geht, und die o.a. Reparaturversuche nicht funktionieren, dann dann kannst du entweder eine funktionierende Sicherung des DC zurückspielen (warum klappt das denn nicht?) oder du machst alles neu. grizzly999