Daim

OK. Klar, da hat auch keiner das Gegenteil behauptet. Sicherlich nicht mehr ganz zu 100%. Jedoch kann ich mich mit dem Auto auf der Straße "sicher" bewegen, kenne ich gut mit der STVO aus und fahre nun seit über 16 Jahren Unfallfrei! Immer locker bleiben. Nichts für ungut!

Na und, dass kann doch so bleiben? Man kann auf JEDEM DC den GC aktivieren, auch in einer SBS-Domäne! Und mit dieser einen Prüfung sollte man trotzdem "erfahrener" im Umgang mit einem SBS sein.

Servus, es können sehr wohl in einer SBS-Domäne weitere DCs neben dem SBS existieren. Der SBS muss dabei zwingend der FSMO-Rolleninhaber sein und der GC muss auf dem SBS aktiviert sein. Was jedoch der SBS nicht kann, sind Vertrauensstellungen! LDAP://Yusufs.Directory.Blog/ - Die Besonderheiten eines Small Business Server`s (SBS)

Nicht dafür. ;) Danke für die Blumen.

Salut, och... ganz gut. ;) Ja, der Bridgeheadserver (BHS) repliziert die Daten --> seines AD-Standorts <-- an den BHS des anderen AD-Standorts. Genauer: Für jeden AD-Standort wählt der Knowledge Consistency Checker (KCC) bzw. der ISTG, einen Domänencontroller (DC) als so genannten Bridgeheadserver aus, der im Hinblick auf die AD-Replikation mit Domänencontrollern anderer AD-Standorte als "Brückenkopf" und somit Anlaufstelle dient, über den Replizierungsinformationen mit anderen AD-Standorten ausgetauscht werden. Über den BHS läuft die standortübergreifende (Inter-Site) AD-Replikation und somit wickeln die BHS die AD-Replikation zwischen AD-Standoten ab. Dazu sammeln die BHS alle getätigten Änderungen, die auf einem DC eines AD-Standortes stattgefunden haben, um diese dann an andere BHS zu replizieren. Die Auswahl welcher DC in einem Standort als BHS dient, wird vom KCC getroffen. Der Administrator kann aber mehrere DCs als bevorzugte BHS deklarieren, sodass der KCC gezielt einen dieser DCs auswählen kann. Aber auch hier ist es ratsam, die Auswahl dem AD zu überlassen. Ja, dass ist korrekt. Den genauen Vorgang habe ich ja oben bereits geschildert. Nicht pro Domäne, sondern pro AD-Standort. Exakto Mundo. Aber das "benötige" hört sich so an, als ob du damit einen gewaltigen "Mehraufwand" hättest. Wenn du alles standardmäßig belässt, regelt das AD alles von alleine. Du kannst die standardmäßig erstellten Site-Links löschen. Das stellt kein Problem dar. Du kannst diese aber auch einfach nach deinen Vorgaben umbenennen und weiterhin nutzen.

Aha.. also zwei Gesamtstrukturen. Nein, dein Problem ist nicht die Inter-Site AD-Replikation (zu deutsch: standortübergreifende AD-Replikation) die ausschließlich innerhalb einer Gesamtstruktur stattfindet und nicht zwischen zwei Gesamtstrukturen. So so... dann erläutere doch mal was genau du konfiguriert hast und wie die Fehlermeldung exakt lautet. ... oder etwas nicht richtig verstanden zu haben. ;) Das funktioniert nicht. Eine AD-Replikation zwischen Gesamtstrukturen ist nicht möglich.

Salut, das eine hat doch mit dem anderen nichts zu tun. In den Eigenschaften des Benutzerkontos kannst du lediglich definieren, an welchen Clients sich eben dieser Benutzer anmelden darf. Aber natürlich darf dieser Benutzer sich mit Netzlaufwerken verbinden, auf die der Benutzer die entsprechenden Rechte besitzt.

Salut, erläutere das genauer. Was möchtest du wohin replizieren? Aha... und warum?

Servus, so wie es aussieht, stellt Netometer das Tool leider nicht mehr zur Verfügung. Du kannst aber noch zwei andere Tools für die Erstkonfiguration des Server Core verwenden: LDAP://Yusufs.Directory.Blog/ - Tools zum konfigurieren des Server Core Ab Windows Server 2008 R2 befindet sich nun auch ein Tool oder besser gesagt ein Skript, mit dem man auch die Erstkonfiguration des Server Core vornehmen kann "on Bord": LDAP://Yusufs.Directory.Blog/ - Die Konfiguration des Windows Server 2008 R2 Core

Ja, du kannst die FSMO-Rollen alle auf einem DC lassen. Auch wenn dieser DC ausfallen sollte, kann man immer noch "mit Gewalt" die FSMO-Rollen auf einem anderen DC zügig zur Verfügung stellen. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Da könnte durchaus etwas dran sein. ;) Null problemo, dafür sind wir doch hier. :)

Du musst nicht unbedingt auf jedem DC den GC aktivieren. Du kannst auch in "Standorte und Dienste" im jeweiligen AD-Standort auf dem "NTDS Site Settings-Objekt" die Option "Zwischenspeichern der universellen Gruppenmitgliedschaften" aktivieren. Doch bei deiner Bandbreite kannst du ruhig auf jedem DC den GC aktivieren.

Servus, Merke dir einfach: L - S - D - OU. Lokal - Standort - Domäne - Organisationseinheit.

Ich dachte da in Richtung RID-Master, zugegeben auch nicht unbedingt Applikationsbezogen.

Wenn die Erstreplikation abgeschlossen ist, also auf den GC alle Domänenpartition repliziert wurden, hält sich die tagtägliche standortübergreifende AD-Replikation in Grenzen. Zumindest wenn nicht permanent an AD-Objekten etwas geändert wird. Aber auch wenn, über eine 2 MBit Leitung und Dank der LVR-Replikation fällt das kaum ins Gewicht. LDAP://Yusufs.Directory.Blog/ - Die Linked Value Replikation (LVR) Das Design ist soweit korrekt. Wann und warum man AD-Standorte erstellen sollte, habe ich hier erläutert: http://www.mcseboard.de/windows-forum-ms-backoffice-31/ad-standorte-dienste-festverbindung-154964.html#post952878 Und im zweiten Schritt folgt dann eine Domäne "weltweit", oder nicht? Das ist verständlich. OK. Genau. Von Haus aus normal ist das nicht. Es kommt auf die Umgebung an und wie sie konfiguriert ist. Was zu empfehlen wäre ist, dass auf jedem DC das DNS installiert ist, sich die Forward Lookup Zone im AD befindet und zusätzlich auf jedem DC der GC aktiviert ist. An die Clients verteilt man dann statisch oder per DHCP mehrere DNS-Server. Ja, früher hatte auch Microsoft (mit weniger Erfahrung) andere Ansichten und gab dementsprechende Empfehlungen aus. Heute aber, mit den zur Verfügung stehenden Bandbreiten und mit mehr Erfahrung kann man die Empfehlung ausgeben, auf jedem DC den GC zu aktivieren.

Servus, es kommt darauf an, wie AD-lastig in eurem Unternehmen gearbeitet wird. Wird das AD lediglich wie in vielen Umgebungen zur Anmeldung genutzt, können sich alle FSMO-Rollen auf einem DC befinden. Existieren aber in eurer Umgebung Applikationen die AD-lastig arbeiten und so evtl. die ein oder andere FSMO-Rolle mehr beansprucht wird, muss man das natürlich genauer verifizieren. Was du in jedemfall tun kannst ist, auf ALLEN DCs den GC zu aktivieren und das DNS auf jedem DC zu installieren. Nein, dabei spielt es auch keine Rolle, welcher DC die Rolle des Infrastrukturmasters inne hat. Siehe dazu: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

Moment. Im ersten Schritt definiert man zuerst auf Papier welche Aufgaben die Mitarbeiter durchführen sollen. Wenn dann alles zu Papier gebracht wurde, delegiert man die entsprechenden Rechte (sofern technisch möglich) an die Mitarbeiter. Schau dir die Links in meiner vorherigen Antwort durch.

Salve, erläutere mal genauer was dein Ziel genau ist. Du kannst Benutzern über die Objektdelegierung im AD gezielt nur die Rechte erteilen, die sie durchführen sollen. Du kannst dich auch mal durch diese Seiten "durchschlagen": LDAP://Yusufs.Directory.Blog/ - Active Directory|Objektverwaltung https://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3&displaylang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=29dbae88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en

Bonjour, versuche es mal mit diesem Befehl: DSACLS "OU=Benutzergruppen,OU=Oben,DC=firma,DC=group" /I:S /G "firma.group\<DeineGruppe>”:WP;member;Group Siehe auch: LDAP://Yusufs.Directory.Blog/ - Objektdelegierungen einrichten

Aloha, was erstellst du denn wo genau? Handelt es sich um einen einzigen AD-Standort? Dann installiere die Windows Support Tools und führe das DCDIAG sowie NetDIAG durch und kontrolliere das Ergebnis nach "Failed" Einträgen.

Genau. PSS steht für Microsoft Produkt Support Service.

Servus, doch, supportet ist es, es wird nur nicht aus Disaster Recovery Gründen empfohlen Exchange auf einem DC zu installieren. Wenn du den PSS anrufst, bekommst du das schnell hin.

Servus, exakt. Entweder neu installieren oder du installierst das R2 auf einer neuen/anderen Maschine. Aha... erzähl mal mehr darüber.

Bonjour, AD-Standorte erstellt man, um 1.) Einfluss auf die AD-Replikation zu nehmen und 2.) die Benutzeranmeldung von dem DC vor Ort durchführen zu lassen. Erstellst du nur ein AD-Standort kann es vorkommen, dass sich die Clients an den DCs aus der Zentrale anmelden und nicht am DC der vor Ort steht. Bei einer Standleitung ist das auch kein Problem, aber je nachdem was alles über die Leitung geht (Dateien, Mails, Internet, CRM etc.) kann es dann zu einem langsamen Anmeldeverhalten führen. Möchtest du sicherstellen das die Clients den lokalen DC für die Benutzeranmeldung nutzen, musst du unter "Active Directory-Standorte und -Dienste" einen entsprechenden AD-Standort samt dem Subnetz konfigurieren. Dabei kann ein AD-Standort mehrere Domänen enthalten und eine einzige Domäne, kann mehreren Standorten angehören. Durch das erstellen von AD-Standorten kannst Du die AD-Replikation bzw. das SYSVOL Verzeichnis "besser" steuern. Standortintern (Intrasite) werden Änderungen wesentlich häufiger repliziert als zwischen den AD-Standorten (Intersite) und vorallem werden die Daten über die Leitung komprimiert repliziert und nicht so wie standortintern - unkomprimiert. Dadurch hast Du nicht nur die Möglichkeit, die effektive Performance im Netzwerk zu optimieren, sondern auch die WAN-Struktur im Hinblick auf Geschwindigkeit und Kosten Rechnung zu tragen. Durch AD-Standorte kannst Du z.B. jeden DC zu einem AD-Standort verschieben und somit klar definieren, welcher DC zu welchem AD-Standort gehört. Damit wissen die Clients schneller, welcher ihr Anmeldeserver ist. LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort

Salut, du möchtest also deine bestehende AD-Umgebung auf "Windows Server 2008" aktualisieren. Dazu erweiterst du das AD-Schema und fügst auf einer weiteren Maschinen einen Windows Server 2008 als zusätzlichen DC zur bestehenden Domäne hinzu. Alle weiteren Details erfährst du aus diesem Artikel: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Servus, wie wäre es mit DSACLS: Dsacls "OU=DeineOU,DC=Domäne,DC=de" > C:\Dsacls.txt LDAP://Yusufs.Directory.Blog/ - Delegierte AD-Berechtigungen anzeigen und entfernen