Daim

Die bestehenden Vertrauensstellungen bleiben bestehen. Erstmal nicht. Ob der Zugriff von der NT-Domäne auf die 2008 Domäne reibungslos läuft, muss man dann sehen. Das spielt keine Rolle.

Natürlich funktioniert das. Zuerst muss natürlich auf IP-Ebene (samt Routing) alles funktionieren (OSI Modell lässt grüßen ;) ). Dann funktioniert auch der Rest, wenn man es richtig macht.

Servus, du stufst den Server am Standort B als zusätzlichen DC zur Domäne hinzu. Installiere dabei noch das DNS auf dem DC. Die Forward Lookup Zone sollte idealerweise AD-integriert gespeichert sein. Dann regelt die AD-Replikation für dich den Rest. Aktiviere ebenfalls den GC auf dem DC und installiere ggf. noch DHCP. An die Clients an Standort B verteilst du dann den DC vor Ort als bevorzugten DNS-Server und die DCs an Standort A als zusätzliche. LDAP://Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen Nun kannst du noch wenn gewünscht im AD einen weiteren Standort erstellen und weist diesem AD-Standort "sein" Subnetz zu. Somit versucht sich der Clients immer zuerst an dem DC an "seinem" AD-Standort anzumelden. Wenn dieser dann mal nicht verfügbar sein sollte, versucht er einen anderen DC in der Domäne, in deinem Fall aus Standort A zu erreichen. Siehe dazu: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort

Servus, die Vorgehensweise mit NTDSUTIL ist immer gleich. Dabei spielt es keine Rolle ob es der erste, zweite oder xte DC ist. Nur wenn der zu entfernende DC die FSMO-Rollen innehat, müssen die Rollen auf einen anderen DC "geseizet" werden. Aber das meldet dir dann das NTDSUTIL. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Und auf der Freigabe "Hans" definierst du als "Benutzerbegrenzung - Zugelassene Anzahl" das sich nur ein Benutzer mit dieser Freigabe verbinden darf. Aber wenn ich mir dein LoginSkript in deinem OP anschaue scheint es so zu sein, dass du eine Freigabe hast die "Home" lautet und unter dieser vermutlich alle Benutzerverzeichnisse, sprich die eigentlichen Homeverzeichnisse der Benutzer sind. Dann funktioniert das natürlich so nicht. Die Freigabe muss direkt auf dem Benutzerverzeichnis sein und nicht eine Ebene höher. How to Use a Network Share to Limit a User's Concurrent Connections in Windows 2000 Ja, schon, aber scheinbar passt deine Freigabe nicht.

Ja, klar. Das ist schon klar, dafür nimmt man doch das Home-Laufwerk. Denn hoffentlich darf dort jeder Benutzer nur auf sein eigenes Home-Laufwerk zugreifen.

Servus, hast du auch auf der Freigabe definiert, dass sich nur "ein Benutzer" mit dieser Freigabe verbinden darf? Siehe auch: LDAP://Yusufs.Directory.Blog/ - Wie stellt man sicher, dass ein Benutzer sich nur an einem Client anmelden kann?

Salut, mit dem "Windows Server 2008 R2" funktioniert das nun. Du kannst von der englischen DVD das ADPREP auf einem deutschen DC ausführen. Steht alles auch hier: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Klar. Das kannst du easy in der Exchange Management Shell (EMS, auch bekannt als Exchange Powershell) durchführen. Das Internet ist dir dabei behilflich. In der EMS mit dem Befehl: Get-Mailbox -resultsize unlimited | set-CASMailbox -ActiveSyncEnabled:$False [Edit] ... to slow

Du brauchst es nicht testen, sondern nur durchführen. ;) Per se ist die AD-Replikation nach dem deaktivieren deaktiviert. Von alleine wird dann nicht mehr repliziert. Nur wenn man REPADMIN /FORCE ausführt, wird eine AD-Replikation erzwungen, obwohl auf einem DC die Replikation deaktiviert wurde.

Salve, das stimmt nicht. Wenn der Kollege den Haken gesetzt hat, das dies der letzte DC in der Domäne sei, erkennt der DCPROMO-Assistent das doch noch weitere DCs in der Domäne existieren und der Vorgang des herunterstufens bricht ab. Der DC muss mit DCPROMO /FORCEREMOVAL heruntergestuft worden sein. Somit werden lediglich die AD-Informationen lokal auf dem DC gelöscht. Die DC-Informationen im AD bleiben natürlich weiterhin bestehen. Die Metadaten des AD müssen dann noch im Nachgang bereinigt werden. LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Das sollten sie auch. Verantwortungsbewusstes handeln und Administration sieht anders aus. Bereinige zuerst die Metadaten des AD und bereinige das DNS ggf. auch WINS. Danach kannst du den Server als Mitgliedsserver zur Domäne hinzufügen. Bereinige zuerst die Domäne, in dem du die Einträge des DCs entfernst. Genau, der Server hat kein AD mehr. Aber im AD ist der DC noch vorhanden und diese musst du entfernen. Denn ansonsten hast du eine Leiche im AD und die Replikationsparter würden das Eventlog nur so mit Fehlern füllen. Führe das Bereinigen nach dem o.g. Artikel durch. Na sowas aber auch... ;)

Bonjour, nein, dem ist nicht so. Das wäre ja auch noch schöner und würde eines der Empfehlungen bei einer bevorstehenden Schemaänderung, nämlich die AD-Replikation zu stoppen, widersprechen. Das kannst du aber auch leicht selber testen. Stoppe die AD-Replikation und aktiviere z.B. auf einem Attribut (von mir aus Audio) das es in den GC repliziert werden soll. Abgesehen davon hast du in deiner Aufzählung noch die Anwendungsverzeichnispartitionen, wie z.B. die beiden DNS-Partitionen DomainDNSZones und ForestDNSZones vergessen.

Mittlerweile kann man Exchange 2010 auch auf TechNet und MSDN herunterladen. Oder hier: Download details: Microsoft Exchange Server 2010

Salve, denke doch bitte auch an die Leser, die nicht gerade diese Übung durchführen und erkläre genau das was du tust auch den anderen, wie mir z.B..

Du brauchst es nicht versuchen, sondern musst es nur durchführen. ;) Wie du es ja selbst gemerkt hast, ist es nicht das was du benötigst. Die "dringende Replikation" (Urgent Replication) bewirkt nichts anderes, als das der DC der die Kennwortänderung des Benutzers durchgeführt hat, direkt diese Änderung mit einer RPC-Verbindung durch den "sicheren Kanal" dem PDC-Emulator repliziert. Der DC repliziert das aber nur sofort, wenn ihm das nicht durch den Registry-Key "AvoidPDCOnWan" untersagt wurde. Kommen wir nun zu deinem Szenario: BenutzerA ändert am AD-StandortA sein Kennwort. Der DC der die Kennwortänderung durchgeführt hat, repliziert diese Änderung umgehend zu dem DC der die Rolle des PDC-Emulators innehat. Nun versucht der BenutzerA eine Terminalserververbindung zu einem Server der aber im AD-StandortB steht. Die Authentisierung des Benutzers wird in deiner Umgebung von einem DC aus dem AD-StandortB durchgeführt. Vorausgesetzt es existieren mehrere AD-Standorte. Der DC im AD-StandortB weiß aber noch nichts von dieser Kennwortänderung und verweigert vorerst die Anmeldung des Benutzers. Doch bevor der DC dem Benutzer die Anmeldung verweigert, fragt er sicherheitshalber beim PDC-Emulator nach. Denn jeder DC weiß, dass der PDC-Emulator der einzigste DC in der Domäne ist, der alle Kennwörter direkt nach einer Kennwortänderung eines Benutzers kennt. Wenn nun die Anfrage des DCs aus dem AD-StandortB aus welchem Grund auch immer den PDC-Emulator nicht erreicht (PDC-Emulator ist überlastet, VPN-Leitung zwischen den AD-Standorten ist down etc.), verweigert er die Anmeldung des Benutzers. Der DC im AD-StandortB erfährt erst nach der "normalen" standortübergreifenden AD-Replikation von dem neuen Kennwort. Aktivierst du jedoch die standortübergreifende Änderungsbenachrichtigung, erfährt der DC im AD-StandortB bereits nach wenigen Sekunden von der Änderung. @ Marin Fachwissen? Wer? Wenn du einen triffst der so "etwas" hat, sag mir bescheid. ;)

So oder umgekehrt. Das ist "Jacke wie Hose".

Servus, nein, der DNS-Dienst wird nicht durch den DCPROMO-Assistenten mit deinstalliert. Diesen musst du gesondert deinstallieren. Achte aber darauf, dass der DC den du entfernen möchtest, aus den TCP/IP-Einstellungen der anderen DCs und auf den Clients entfernt wird. Sofern die IP des DCs auf den Maschinen als DNS-Server (statisch oder per DHCP) eingetragen ist.

Hola, na klar. Mindestens zwei! LDAP://Yusufs.Directory.Blog/ - Wie viele DCs pro Domäne werden benötigt? Ist durchaus möglich und ist je nach Umgebung auch sinnvoll. Nein, nicht zwischen Client und DC, sondern vielmehr zwischen Client und Dateiserver.

Salut, du möchtest eher einen Windows Server 2008 DC zur Windows 2000 Domäne hinzufügen und so eine Domänenaktualisierung und keine Migration durchführen. Warum nur auf "Windows Server 2003"? Ja, dass funktioniert. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Salve, ja, die gibt es. Du könntest die standortübergreifende Änderungsbenachrichtigung auf der Standortverknüpfung konfigurieren. Dann nimmt eben die standortübergreifende AD-Replikation zu. Wenn aber die VPN-Leitung zwischen den Standorten Flat ist, fällt das nicht so sehr ins Gewicht. Siehe: LDAP://Yusufs.Directory.Blog/ - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

Was auch in dem Link beschrieben ist.

Servus, LDAP://Yusufs.Directory.Blog/ - Wie finde ich heraus wo sich ein Objekt befindet?

Ja, versuche es auf diese Variante. Lass den Server in der Arbeitsgruppe und führe DCPROMO aus. Der Server muss nicht vorher Mitglied der Domäne sein.

Liest du auch was man dir schreibt? Du sollst den Server zuerst aus der Domäne nehmen, dann das Computerkonto im AD löschen und anschließend erneut das DCPROMO durchführen.

Servus, so ganz schlau werde ich aus deinen Schilderungen nicht. In deinem OP schreibst du "PDC" und "BDC". Also sind diese beiden Server doch schon DCs, oder etwa doch nicht? Erkläre bitte klar und deutlich was du vor hast. Wie sehen denn die Eventlogs, insbesondere das Verzeichnisdienst- und DNS-Protokoll auf den DCs aus?