grizzly999

Und wie ist das, wenn du SP2 wieder vom Server entfernst? grizzly999

Hallo und willkomen im Board :) Auf Domain Controllers OU sind in der dortigen Default Doamin Controllers Policy andere Einstellungen standarmäßig gesetzt. Diese überschreiben die Domain-Settings. Entweder die Domänenrichtlinie erzwingen (nicht gut aus meiner Sicht), oder es in der OU Richlinie setzen. grizzly999

Da fehlt dann aber wenn schon denn schon der Doppelpunkt hinter dem scope ;) grizzly999

Nein, da geht das nur manuell. grizzly999

Hallo und willkommen im Board :) Ist da in der Domäne (oder lokal) die Richtlinie in den Sicherheitsoptionen aktiv, die besagt, die Anzahl der Anmeldungen für den Fall, dass der DC nicht verfügbar ist, auf 0 zu setzen? grizzly999

Meinst du DN oder FQDN ? grizzly999

Richtig, das geht jeoch nicht anders. Heißt in dem Fall "Ent" oder "Weder" grizzly999

Genau. Namen dienen der Erkennbarkeit und leichteren Verwaltbarkeit (vor allem bei der Verwendung grafischer Tools). Du sprichst ein wahres Wort und einen ganz wichtigen Satz ganz gelassen aus :thumb1: ;) grizzly999

Also hat doch nicht zu tun mit ABE... Das ist eine reines "NTFS-Problem", du musst dem User /der Gruppe halt in den Speziellen NTFS-Berechtigungen die Berechtigung "Ordner erstellen" auf Deny setzen und dabei aber aufpassen, dass das gitl für "Nur diesen Ordner und Unterordner". Wenn dieses Häkchen auch für Dateien gilt, dann kann er keine Dateien mehr verändern. grizzly999

Die automatische Registrierung (nur XP und höher) braucht eine entsprechende Group Policy, aber die ist in der Default Domain Policy bereits aktiviert. Von daher ist policytechnisch im Standardfall nichts weiter nötig. grizzly999

Ich verstehe jetzt den Zusammenhang mit ABEUI nicht ganz, aber zu verhindern ist das, wenn der User auf dem anderen Ordner (oder allen) keine Berechtigung hat, neue ordner zu erstellen. grizzly999

Indem der entsprechende Client die IP beim DHCP least. grizzly999

Die gibt es meines Wissens nach nur auf englisch. grizzly999

Man beachte: Bei Berechtigungen wird der Displayname angezeigt (und der UPN in Klammern dahinter), nicht der Kontoname und auch nicht der Anmeldename. Wurde der Displayname vom Konto auch abgeändert? grizzly999

Ich bin ein absoulter Freund von Virtualisierung, wo sie geht und sinnvoll ist, das möchte ich hier erwähnen. Ich persönlich bin nicht unbedingt ein Freund davon, DCs mit entsprechenden Tools von Hardware in eine VM zu "verschieben". Warum das nicht unbegründet ist, habe ich wie oben geschrieben, erst erleben dürfen. Ich stehe jedoch auf dem Standpunkt, jedem das seine, und mir meine Arbeit, wenn's schief geht :D :D grizzly999

Dir ist aber klar, dass ein 1:1 Image auf eine andere Hardware.........., da sind Probleme vorprogrammiert, wenn das nicht exakt dieselbe Hardware ist. Klar, kann man die versuchen zu lösen, F6, usw., das würde ich gar nicht erst probieren. grizzly999

Nunja. Wenn CISCO das so in seine Dokumentation schreibt, dann wollen die auch die Antwort so hören. Und dann würde ich das nehmen, was der Ersteller einer Prüfung verlangt. Das Zitat whiggy ist aus dem original Link, dort ist es schriftlich so niedergeschrieben und auch die Grafik sagt es so. Aber weil #9370 anderer Meinung ist als CISCO, würde ich ich nicht IGRP nehmen. Just my 2 cents grizzly999

... und ich habe gerade vorletzte Woche einem Kunden einen nicht sauber operablen Server aus dem AD rausoperiert, der den von einer Hardware weg virtualisiert hatte, und nachher das Log sich vor Fehlern nicht mehr retten konnte. Als man wegen einem Schemaupdate den Schemamaster auf diesen Server verschoben hatte (ohne Fehler und dieser wurde auch als Schemamaster überall angezeigt, war er gar nicht mehr per rpc ansprechbar, und die Rolle auch nicht mehr rücktransferrierbar). Ich gehe da ganz konform mit blub, Server mit solchen Applikationen sollte man sauber aufsetzen. grizzly999

Siehe hier: http://www.mcseboard.de/mcse-forum-pruefungen-33/vue-voucher-15-rabatt-26-35098.html#post669252 grizzly999

Es reicht "Lesen". grizzly999

Nein, verwechsle ich nicht. "Authoritative restore" heißt der Menüpunkt im ntdsutil. Der Befehl um einen "authoritative restore" (als Vorgang) durchzuführen, heißt dann "restore subtree" oder "restore database" oder "restore object" innerhalb dieses Menüpunktes im ntdsutil. Und wenn man vom "Authoritive Restore" als Vorgang spricht, dann meint man genau das damit: Nach einer Wiederherstellung des Systemstatus das Tool ntdsutil öffnen, "authoritative restore" einzugeben um in eben dieses Menü zu wechseln, und dann diejenigen Teile mit restore subtree oder restore database oder restore object als authorisierend für eine spätere Replikation zu markieren, die man nicht wieder durch die Replikation gelöscht haben möchte. grizzly999

Ja, das ist richtig. Das Imaging-Problem besteht dann, wenn man nach dem Ziehen des Images den DC wieder hochfährt (und am besten noch Transaktionen darauf durchgeführt werden), und danach den DC wieder aus dem Image zurückspielt. Wenn der zwischendrin aber nie wieder hochgefahren wurde, ist das wie blub sagte wie Aus- und Einschalten. grizzly999

Das ist richtig. Dazu ist das Tool bzw. der Befehl da, damit der zweite DC nicht die wiederhersgestellten gelöschten Objekte wegen seiner höheren USN für diese Objekte wieder rauslöscht aus dem AD. grizzly999

Nein. Wie gesagt, das restore holt alle gelöschten Objekte zurück, die vor der Sicherung da waren und dnach der Sicherung gelöscht wurden. Die Versionsnummern hochzählen - und was anderes macht der Befehl restore subtree nicht, andert daran nichts. Die Objekte sind nach dem restore alle miteinander wieder da, diejenigen, die ich authorisierend wiederhersgestellt habe, halt mit deutlich höherer USN als vorher. Aber teilweise Objekte mit restore subtree wiederherstellen ist nicht. Hier steht nochmal, was da passiert: Authoritative restore grizzly999

Nein, nein, nein :wink2: Die authorisierende WDH hast einzig zum Zweck, gelöschte Objekte so wiederherzustellen, dass kein anderer DC, der dieses gelöschte Objekt ebenfalls hat, bei der Replikation nach dem Wiederhochfahren des restorten DC, die aus Sicherung wiederhergestellten Objekte wieder löschen kann. Dazu wird beim auth. WDH. die USN für jedes der selektierten Objekte um 100.000 pro Tag, den die Sicherung alt ist, hochgezählt. Damit dürfte kaum ein anderer DC diese Objekte per Replikation wieder weglöschen. Aber was soll ich bei einem einzelnen DC die USNs erhöhen lassen, ist ja eh' niemand da, der die wiederhergestellten Objekte löschen kann. Und was anderes als versionsnummer mächtig hochzählen macht der Vorgang nicht. Daher: die AD DB aus einer Systemstatus-Sicherung auf einem einzelnen DC wiederherstellen, holt unausweichlich und nicht selektierbar ALLE Objekte zurück, die vor der Sicherung (sichtbar) vorhanden waren, und nach der Sicherung gelöscht wurden. grizzly999