none
2 DC's und die Profildaten, Homeverzeichnisse, Ordnerumleitungen RRS feed

  • Frage

  • Hallo,

    würde mir gerne ein paar Ratschläge zu einem bevorstehenden Projekt holen. Wir werden in kürze unsere Serverlandschaft ein wenig verbessern und erweitern. In diesem Projekt stehen uns 2 Hypervisor, die mit Microsoft Hyper-V Gastmaschinen hosten zu Verfügung.

    Wir wollen jeweils 1 DC auf einen Hypervisor installieren und fragen uns wie wir die Profildaten, Homeverzeichnisse, Ordnerumleitungen speichern. Wir hätten auch noch eine Storage aber die können wir nicht benutzen.

    1. Überlegung: DC1 (Gastmaschine, Hypervisor1) Profildaten werden auf DC1 gespeichert und per \\domäne.local\profildaten zur Verfügung gestellt. DC2 (Gastmaschine, Hypervisor2) repliziert sich mit DC1, für die Profildaten gibt es eine DFS Replikation auf DC2 und werden ebenfalls inplace im DC2 gespeichert.

    2. Überlegung: Profildaten werden auf einen Fileserver abgelegt (ebenfalls Gastmaschine) und per \\fileserver\profildaten zur Verfügung gestellt.

    Die 2. Lösung gefaällt mir nicht sehr gut, da der Fileserver auch ausfallen kann und die Profildaten nicht greifbar wären.

    Wie sieht es mit richtigen Snapshots von DC's aus? Wenn man System State berücksichtigt, dann sollte das doch ok sein, oder? Habe mal gelesen, dass man bei virtuellen DC's die Finger von Snapshots lassen sollte! Wäre ja auch sinnlos, wenn wir 2 haben, dann sollte es ganz egal sein, ob ich ein DC wiederherstelle oder einen neuen aufsetze, der sich mit dem ersten wieder abgleicht, sehe ich das richtig?

    Gruß





    • Bearbeitet SADFR Samstag, 29. Dezember 2012 17:55
    Samstag, 29. Dezember 2012 17:53

Alle Antworten

  • Deine 1. Überlegung ist nicht supported:

    Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario
    http://support.microsoft.com/kb/2533009/en-us

    Deswegen: Überleg und implementier Dir ein Fast-Recovery-Scenario im Falle, dass Dein Storage ausfällt

    Snapshots sind für produktive Umgebungen nie empfohlen (Dateninkonsistenzen, aber auch volllaufendes Storage wegen unlimitierten Differential-Disks)

    Ledigllich Windows Server 2012 DCs auf Windows Server 2012 Hyper-V mit aktivierter Generation-ID beinhaltet einige Schutzmechanismen für Snapshots, Image-Restores und Cloning - s. hierzu:

    Introduction to Active Directory Domain Services (AD DS) Virtualization
    http://technet.microsoft.com/en-us/library/hh831734.aspx

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Sonntag, 30. Dezember 2012 09:13
  • Na ist ja super. Bedeutet wohl, dass wir all diese Daten nicht replizieren. Wäre kein Problem ein Backup-Job für diese Daten einzurichcten aber für einen transparenten Failover bei einem DC Crash unbrauchbar!! ACHSO: wir nutzen keine Storage für die Gastmaschinen und Daten, diese werden Server inplace gespeichert. Gibt eine extra VD bestehend aus einigen Platten für die VHD's. 2 Platten für den Hypervisor im Raid1, x Platten im Raid 10 für die Gastmaschinen. Wird irgendwann auch mal geändert...

    Gibt es denn eine andere Lösung in Bezug auf die Profildaten?

    Habe schon überlegt, ob wir einfach einen Fileserver und eine offline Replikation einsetzen, wäre zwar auch kein transparenter Failover aber sehr viel schneller eine Gastmaschine zu starten als eine Recovery, oder ist das ebenfalls nicht supported.

    Am Besten wäre dann wohl doch auf die Storage, die repliziert wird und am Besten noch ein SVC vorsetzen für die Sicherheit von Redundanz und Co. Aber dafür ist z.z kein Budget da. Dehalb und ich wiederhole mich in meiner Frage: Gibts eine gescheitere Lösung für unsere Profildaten?

    Gruß


    • Bearbeitet SADFR Sonntag, 30. Dezember 2012 09:28
    Sonntag, 30. Dezember 2012 09:25

  • 1. Überlegung: DC1 (Gastmaschine, Hypervisor1) Profildaten werden auf DC1 gespeichert und per \\domäne.local\profildaten zur Verfügung gestellt. DC2 (Gastmaschine, Hypervisor2) repliziert sich mit DC1, für die Profildaten gibt es eine DFS Replikation auf DC2 und werden ebenfalls inplace im DC2 gespeichert.

    DCs virtualisieren? Naja, aber mindestens 2 brauchst Du auf Blech... DFSR für Profile -> hat Tobias ja schon geschrieben. No Go. DFSN geht allerdings, siehe unten.

    2. Überlegung: Profildaten werden auf einen Fileserver abgelegt (ebenfalls Gastmaschine) und per \\fileserver\profildaten zur Verfügung gestellt.

    Die 2. Lösung gefaällt mir nicht sehr gut, da der Fileserver auch ausfallen kann und die Profildaten nicht greifbar wären.


    3. Überlegung: Profildaten werden per DFSN unter \\domain.local\profile zur Verfügung gestellt. Und nachts kopiert ein Task den Inhalt des Shares auf einen anderen Server. Fällt Server1 aus, kannst Du ganz einfach im DFSN das Target ändern und für die User ändert sich nix. Das gleiche für umgeleitete Ordner. Aber bitte OHNE DFS Replikation!

    Wie sieht es mit richtigen Snapshots von DC's aus? Wenn man System State berücksichtigt, dann sollte das doch ok sein, oder? Habe mal gelesen, dass man bei virtuellen DC's die Finger von Snapshots lassen sollte!


    Wenn man's falsch macht, gibt's USN Rollback.

    Wäre ja auch sinnlos, wenn wir 2 haben, dann sollte es ganz egal sein, ob ich ein DC wiederherstelle oder einen neuen aufsetze, der sich mit dem ersten wieder abgleicht, sehe ich das richtig?


    Du willst keine virtuellen DCs ;-)

    mfg Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 4. Januar 2013 11:10
  • Sind 2 DC's auf 2x Blech, aber jeweils virtualisiert.

    DFSR schon gestrichen.

    DFSN schaue ich mir an und probiere es in einer Testumgebung aus.

    USN ist mir klar. Für die DC's verwenden wir zukünftig Windows Backup (Supported, Stichwort: Rücksetzung der invocationID bei der Wiederherstellung), dann ist USN kein Thema. Hätten es nur gerne mit unserer Backupsw gemacht. Aber so haben wir zumindest eine supportete Backup-Lösung für die DC's. Snapshot gestrichen.

    Warum will ich keine? Zeitsync?, Backup? Oder was bereitet dir Kopfschmerzen? Ich bin davon beinahe überzeugt, dass es viel schöner ist mit VDC's zu arbeiten, wenn man es richtig macht! Das Einzige was mir einfällt ist, dass wir kein Physikalischen Server als DC verwenden, ABER wir haben 2 Hypervisor, in denen 2 VDC's stecken. Wenn man es ganz genau nimmt könnten wir theoretisch noch einen dritten DC auf Blech mit rein nehmen. (Ist glaube ich auch die Empfehlung von MS, wenn man mit 2 VDC's arbeitet, oder? Aber wie siehts aus, wenn man mit 2 VDC's auf 2 Hypervisorn arbeitet?) Falls dir nichts mehr einfällt, Thema durch.

    Freitag, 4. Januar 2013 18:51

  • Du willst keine virtuellen DCs ;-)

    mfg Martin

    Ausschliesslich oder bezieht sich das auch auf einzelne?

    Aus meiner Erfahrung, dem was ich seit 2008 R2 zum Thema lese und dem was ich von anderen Firmen so mitbekomme ist es mittlerweile gängige Praxis. Deshalb wäre ein solch konträrer Punkt wissenswert auf welchen Hintergrund er bezogen ist.


    @ SADFR



    Ich kenne es als gängige Praxis eher so, das DCs lediglich AD Funktion haben plus DNS. Keine weiteren Funktionen. Und dabei sehr wohl virtuell laufen.
    Zeitsync ist m.E. das einzige auf das man ernsthaft achten muss und natürlich das man DCs physisch getrennt virtualisiert.

    Steigt einer aus wird er nicht aus dem Backup geholt sondern neu aufgesetzt. FSMO Rollen übertragen und (wenn nötig) die Metadaten aus dem AD bereinigt.
    Das kommt aber m.E. auch darauf an ob du dich auf die Techniken einlassen willst die DC Restore Probleme vermeiden können oder nicht.
    Ich persönlich bin dabei noch recht konservativ, halte es für sauberer (und einen no-brainer) und verfahre so, würde aber auch umdenken wenn ich mich mit dem Thema tiefergehend auseinandersetzen könnte. ;)





    Freitag, 4. Januar 2013 20:02
  • Ich würde sagen auf Einzelne. Es gibt dort Einiges zu lesen drüber. Hauptthemen sind Zeitsync, Backup (Problem besteht aber auch bei physischen DC's (KLON, IMAGES, SNAPSHOTS, ETC.)), DC auf Parent Partition und Funktionseingrenzung.

    Habe da jetzt aber nochmal eine Frage zu der Zeitsynchronisation. Bin gerade auf einer Testumgebung bei der Konfiguration. Habe auf dem DC folgenden Befehl ausgeführt: w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES<o:p></o:p>  und habe diesen ebenfalls (ausversehen) auf einem Memberserver eingegeben, nun versuche ich gerade den Memberserver wieder beizubringen die Zeit vom DC zu beziehen. Bin mit dem w32time nicht so sehr vertraut. Wie biege ich den Knaben wieder um?

    Freitag, 4. Januar 2013 20:27
  • So nochmal.

    Habe das Problem mit der Zeitsynchronisation hinbekommen. Der Memberserver gleicht jetzt seine Zeit mit dem DC ab.



    • Bearbeitet SADFR Samstag, 5. Januar 2013 16:40
    Freitag, 4. Januar 2013 22:59
  • Moin,

    Am 04.01.2013 12:10, schrieb Martin Binder:

    Du willst keine virtuellen DCs ;-)

    solten wir jetzt noch mal das Buzzword "Server 2012 erlaubt DC Imaging"
    reinwerfen?
    :-)

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Samstag, 5. Januar 2013 11:18
  • Hallo,

    könntest Du bitte auch die Antworten markieren, die Dir geholfen haben?

    So dass auch andere davon profitieren können.

    Gruss,
    Raul


    Raul Talmaciu, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip„IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Ja sicher, das mache ich doch gerne wobei ich bisher noch nicht weiß, ob mir die Lösung hilft, da ich, wie ich weiter oben geschrieben habe, erst testen muss.

    Montag, 7. Januar 2013 20:58

  • Du willst keine virtuellen DCs ;-)

    solten wir jetzt noch mal das Buzzword "Server 2012 erlaubt DC Imaging"
    reinwerfen?


    Aber gerne ;-) Nix dagegen, solange die Virtualisierungsplattform nicht Bestandteil der Domäne ist, deren DCs sie virtualisiert...

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 8. Januar 2013 09:57
  •  
    > habe diesen ebenfalls (ausversehen) auf einem Memberserver eingegeben,
    > nun versuche ich gerade den Memberserver wieder beizubringen die Zeit
    > vom DC zu beziehen. Bin mit dem w32time nicht so sehr vertraut. Wie
    > biege ich den Knaben wieder um?
     
    /syncfromflags:domhier
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 8. Januar 2013 09:58
  • Der Host darf nicht in die Domäne, der gleichzeitig auch einen VDC hostet?? Was aber wenn im Netzwerk noch ein weiterer DC vorhanden ist?

    #

    Danke für den Befehl! Gibt es noch eine Möglichkeit (Abfrage) zu überprüfen, ob der Memberserver sich tatsächlich die Zeit vom DC holt? Wie sieht es mit den Clients aus? Holen die sich automatisch die Uhrzeit vom DC oder muss man noch etwas einstellen?

    Zum Verständnis (habe mich die letzte Zeit intensiv mit der Zeitsynchronisation beschäftigt):

    Mit  dem Befehl "w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES" bringe ich den PDC-Emulator dazu die Zeit aus dem Internet von einem Zeitserver meiner Wahl zu holen, wahlweise kann ich auch Mehrere angeben

    Der DC holt seine Zeit vom PDC Emulator

    PDC Emulator ist eine FSMO Rolle

    DIe Rolle des PDC Emulators bekommt der 1. DC der Domäne

    Alle Memberserver und Clients beziehen jedoch die Zeit vom DC

    Ein 2. DC in der Domäne bezieht seine Zeit ebenfalls vom PDC EMulator

    Wenn man mehrere DCS hat, dann sollte man diese Rolle über beide DCS verteilen

    #

    Zum Grundverständnis: Punkt Integritätsdienste MS Hyper-V Zeitsynchronisation:

    Im Defaultzustand ist nach der Erstellung einer Gastmaschine in den Integritätsdiensten die Zeitsynchronisation aktiv, das bei jeder Maschine, die erstellt wird. Wenn ich nun nur einen einzigen Host habe auf denen ich mehrere Gastmaschinen habe, dann ist der aktivierte Integritätswert kein Problem, selbst dann, wenn ich auf dem Hostsystem eine DC am Laufen habe. Alle Maschinen holen sich ihre Zeit vom Host, daher haben alle Maschinen die gleiche Zeit und nur das ist entscheidend.

    Eine richtige Uhrzeit ist nicht relevant, sondern nur das diese synchron ist.

    #

    Jetzt zum Problem mit der Zeit:

    Habe ich mindestens 2 Hostmaschinen auf denen verteilt Memberserver einer Domäne oder sogar DCS laufen und der Integritätsdienst Zeitsynchronisation aktiviert ist und die Uhrzeit von unterschiedlichen Hardwareuhren bezogen wird, dann besteht die Gefahr, dass wir unterschiedliche Uhrzeiten haben. Und genau das ist wohl das was so gefährlich wird, denn wenn sich die Uhrzeit mehr als 5Min beider Hardwareuhren von beiden Hosts unterscheiden, dann läuft das Kerberos Ticket ab und Memberserver verlieren ihre Vertrauensstellung.

    #

    Habe ich das richtig verstanden und gibts irgendwo noch eine Lücke?

    Gruß

    • Als Antwort vorgeschlagen Enrico Stephan Mittwoch, 9. Januar 2013 20:11
    Mittwoch, 9. Januar 2013 19:31
  • "DIe Rolle des PDC Emulators bekommt der 1. DC der Domäne

    Alle Memberserver und Clients beziehen jedoch die Zeit vom DC

    Ein 2. DC in der Domäne bezieht seine Zeit ebenfalls vom PDC EMulator

    Wenn man mehrere DCS hat, dann sollte man diese Rolle über beide DCS verteilen"

    Da ist mir nicht ganz klar was verteilen bedeutet. PDC Emu ist immer nur einer.

    Ansonsten stimmt das im Kern mit dem was ich weiß und wie ich es handhabe überein.

    Ich habe bisher nur einmal einen Blogeintrag gelesen, der von einem namhaften MVP war, der genau das so nicht handhabt und die Zeit vom Host syncen lässt aber weder finde ich den Beitrag wieder noch erinnere ich mich an Hintergründe und Besonderheiten die es dazu gab.

    Weitere Meinungen wären aber auch interessant. ;)
    Vor allem so konträre wie von Martin.

    Mittwoch, 9. Januar 2013 20:11
  • Am 09.01.2013 21:11, schrieb Enrico Stephan:

    Da ist mir nicht ganz klar was verteilen bedeutet. PDC Emu ist immer nur einer.

    Es geht um die 5 Rollen, die man verteilen kann, was man aber seit Windows 2000 eigentlich nicht mehr macht, da seit 2003 jeder DC idR auch Globaler Catalog Server ist.

    Vorher durfte aus Replikationstopologie der Infrastructure Master nie GC sein.
    Die Ausfallsicherheit beim Verteilen der Rollen ist fraglich, Wenn die Rolle fehlt dann fehlt sie ... ;-)

    Also ist es eher egal, ob sie auf einem Server liegen, oder auf 3en.
    Schema, Infra und Naming Master sind nicht so relevant im Tagesgeschäft, der RID Master wird nur alle 500 Rids vom DC angefragt und der PDC ständig ... spar dir die Verteilung.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 10. Januar 2013 07:42
  •  
    > Der Host darf nicht in die Domäne, der gleichzeitig auch einen VDC
    > hostet?? Was aber wenn im Netzwerk noch ein weiterer DC vorhanden ist?
    >
     
    Wenn Du nur virtuelle DCs hast und Dein Virtualisierungshost neu bootet,
    stehen in dem Moment keine DCs zur Verfügung. Da die DCs üblicherweise
    auch DNS machen, gibt es auch keinen DNS... Und da der PDC auch
    Zeitquelle ist, gibt's keinen Timeserver. Schlecht... Daher "mindestens
    1 DC auf Blech, idealerweise 2. Und die FSMOs auch aufs Blech".
     
    > Danke für den Befehl! Gibt es noch eine Möglichkeit (Abfrage) zu
    > überprüfen, ob der Memberserver sich tatsächlich die Zeit vom DC holt?
    > Wie sieht es mit den Clients aus? Holen die sich automatisch die
    > Uhrzeit vom DC oder muss man noch etwas einstellen?
     
    /query /peers
     > Eine richtige Uhrzeit ist nicht relevant, sondern nur das diese
    > synchron ist.
     
    Genau. Alle Computer einer Domäne benötigen die gleiche Zeit. Und der
    PDC benötigt eine externe Zeitquelle. Aber wenn der PDC virtualisiert
    ist und der Host neu bootet, kann der Host die Zeit nicht
    synchronisieren. Ist dann - warum auch immer - eine falsche Zeit
    eingestellt und der PDC kommt wieder, kanns komisch werden.
     
    @Enrico: Was ist an der Meinung "DCs auf Blech" konträr? (-:
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 10. Januar 2013 10:32
  • > Der Host darf nicht in die Domäne, der gleichzeitig auch einen VDC
    > hostet?? Was aber wenn im Netzwerk noch ein weiterer DC vorhanden ist?
    >
    Wenn Du nur virtuelle DCs hast und Dein Virtualisierungshost neu bootet,
    stehen in dem Moment keine DCs zur Verfügung. Da die DCs üblicherweise
    auch DNS machen, gibt es auch keinen DNS... Und da der PDC auch
    Zeitquelle ist, gibt's keinen Timeserver. Schlecht... Daher "mindestens
    1 DC auf Blech, idealerweise 2. Und die FSMOs auch aufs Blech".
    > Danke für den Befehl! Gibt es noch eine Möglichkeit (Abfrage) zu
    > überprüfen, ob der Memberserver sich tatsächlich die Zeit vom DC holt?
    > Wie sieht es mit den Clients aus? Holen die sich automatisch die
    > Uhrzeit vom DC oder muss man noch etwas einstellen?
    /query /peers
     > Eine richtige Uhrzeit ist nicht relevant, sondern nur das diese
    > synchron ist.
    Genau. Alle Computer einer Domäne benötigen die gleiche Zeit. Und der
    PDC benötigt eine externe Zeitquelle. Aber wenn der PDC virtualisiert
    ist und der Host neu bootet, kann der Host die Zeit nicht
    synchronisieren. Ist dann - warum auch immer - eine falsche Zeit
    eingestellt und der PDC kommt wieder, kanns komisch werden.
    @Enrico: Was ist an der Meinung "DCs auf Blech" konträr? (-:
    mfg Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!

    Na ich glaube du hast mich nicht richtig verstanden. Meine Frage war was dagegen spricht einen Host in die Domäne zu nehmen, der ein VDC hostet, wenn im Netzwerk noch ein weiterer DC steckt. Der Host wäre auch nur Memberserver der Domäne und würde dann seine Zeit von einem anderen DC holen. Somit wäre er synchron. Einziges was mir einfällt wäre folgendes Szenario: Host 1 hostet PDC, PDC wird runtergefahren, Host1 wird neugestartet, Host1 holt Zeit von DC2, DC2 kann die Zeit nicht mit PDC abgleichen, da runtergefahren, und alle Memberserver inkl. DC2 und DC3 haben eine falsche Uhrzeit, die evtl. nicht mit dem PDC synchron wäre.

    Dehalb auch meine Frage, ob man diese Rolle über mehrere Server verteilen kann. Denn wenn DC1 (PDC) down, dann würden die beiden anderen für eine synchrone Zeit sorgen!??

    Ist dies Szenario deine Befürchtung?

    Meine Antwort: Die Synchronisation läuft nicht in Echtzeit, sondern nach einem bestimmten Zeiteinstellung wie z.B. von MS empfohlen 15MIN. Was passiert eigentlich im Falle dieses Szenarion mit der Zeitsynchronisation? Würde der 2. DC jetzt weiter nach der Windows Uhr laufen oder läuft dann gar nichts mehr?

    #

    Danke für den Befehl. Finde ich die alle wie gewohnt in der Konsole? Dann muss ich nicht jedes Mal fragen :)

    #

    Donnerstag, 10. Januar 2013 18:15
  • Ich habe bisher nur einmal einen Blogeintrag gelesen, der von einem namhaften MVP war, der genau das so nicht handhabt und die Zeit vom Host syncen lässt aber weder finde ich den Beitrag wieder noch erinnere ich mich an Hintergründe und Besonderheiten die es dazu gab.

    Weitere Meinungen wären aber auch interessant. ;)
    Vor allem so konträre wie von Martin.

    Ich kann da bsolut das Gegenteil von behaupten. In jedem namenhaften Blog steht genau das Gegenteil von dem was du schreibst. Interessant scheint das Thema evtl. (so wie ich weiter oben auch in einem Szenario geschrieben habe) bei einer einfachen "Stand alone" Lösung. Über mehrere Hardware weg verteilt auf denen Memberserver einer einzigen Domäne laufen ist das nicht besonders ratsam, da mehrere Hosts unterschiedliche Uhrzeithaben könnten und diese an die Gastmaschinen durchreichen. Jetzt können wir alle spekulieren warum die Hosts unterschiedliche Zeit haben können, denn man könnte diese ja ebenfalls mit ein und der gleichen Quelle abgleichen, dann hätte man ebenfalls synchrone Zeiten. Aber, wenn der Dienst mal abschmiert von einem der Hosts oder sonst etwas passiert.. Ist die Synchrnosierung auf dem PDC in irgeneiner Weise fehlerhaft und die Zeit stimmt nicht, dann ist dies nicht tragisch, denn dann ist die Zeit von jedem Server fehlerhaft aber dennoch synchron.

    So zumindest meine Vermutung.

    Donnerstag, 10. Januar 2013 18:28
  • Hallo SADFR,

    Nicht das wir uns falsch verstehen. Ich gehe vollkommen mit deinen Ausführungen da core.
    Ich hatte mal vor ein paar Monaten einen Blogeintrag gelesen der als einziger seit (mittlerweile Jahren) eben genau nicht dem entsprach. Das verwunderte mich. Vielleicht hätte ich eine nicjht nachweisbare Gegenbehauptung einfach nicht bringen dürfen. Egal aus welchen grpnden. ;)

    Schreib also bitte nicht "Ich kann da bsolut das Gegenteil von behaupten. In jedem namenhaften Blog steht genau das Gegenteil von dem was du schreibst." denn das stimmt nicht. ;)

    @ Martin

    Ich wollte mich nur laut wundern weil gegenteilige Positionen vom eigenen Wissen und handeln immer dann von besonderer Bedeutung sind wenn man dadurch vielleicht auf Denkfehler oder Wissenslücken aufmerksam gemacht wird. :)

    Ich kenne es halt nicht mehr so. SADFRs Ausführungen sind genau das was mir bisher vermittelt wurde, was ich in der Hauptsache lese und von "Kollegen" aus der Praxis heraus höre. Ich kenne es aus der Vergangenheit auch noch leidlich wenn der einzige DC vor Ort ausfällt und nichts mehr geht. Aber sobald 2 oder mehr DCs im Spiel sind ist die Lage deutlich entspannter. 


    • Bearbeitet Enrico Stephan Donnerstag, 10. Januar 2013 19:00 korrektur
    Donnerstag, 10. Januar 2013 18:58
  • Am 10.01.2013 19:15, schrieb SADFR:

    Meine Frage war was dagegen spricht einen Host in die Domäne zu nehmen, der ein VDC hostet

    Dann starte/installiere den DC mal, füge deinen Host hinzu, starte den Host neu und schau ob er in der Domäne ist ... ;-)

    Gehen tut das immer, aber man muss eben wissen, wen man neustarten darf und wer dann noch da ist. Du brauchst halt mindestens 2 Hosts und 2 DCs.

    Ich persönlich halte mich gerne an ein Blech. Das ist Physik an die ich mit meinem Schraubenzieher komme und so ein 1HE Pizzablech als DC kostet ja nichts. Mag aber jeder selber machen wie er will.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 10. Januar 2013 19:36
  • Am 10.01.2013 19:15, schrieb SADFR:

    Meine Frage war was dagegen spricht einen Host in die Domäne zu nehmen, der ein VDC hostet

    Dann starte/installiere den DC mal, füge deinen Host hinzu, starte den Host neu und schau ob er in der Domäne ist ... ;-)

    Aber genau das habe ich doch geschrieben!! Zitat: "Meine Frage war was dagegen spricht einen Host in die Domäne zu nehmen, der ein VDC hostet, wenn im Netzwerk noch ein weiterer DC steckt. "

    Demnach ist er in der Domäne, wenn ich ihn neustarte, denn dafür habe ich einen 2. VDC auf einem anderen Host.

    #

    @Enrico:

    Zitat: "schreib also bitte nicht "Ich kann da bsolut das Gegenteil von behaupten. In jedem namenhaften Blog steht genau das Gegenteil von dem was du schreibst." denn das stimmt nicht. ;)"

    #

    Verstehe du mich bitte hier nicht falsch, denn das du weißt wie es gemacht wird, habe ich verstanden. Die Aussage war bezogen auf deinen Blogeintrag, den du selbst anzweifelst oder den Grund dafür nicht verstanden hast.

    #

    Bei meiner Aussage (jeder namenhafter Blog schreibt das Gegenteil) bleibe ich dennoch. (Bezogen auf die Konstellation, dass über mehrere Server hinweg Maschinen in einer Domäne laufen). Ist auch so wie ich oben im Szenario beschrieben habe recht sinnvoll.


    • Bearbeitet SADFR Donnerstag, 10. Januar 2013 19:48
    Donnerstag, 10. Januar 2013 19:47
  • Am 10.01.2013 20:47, schrieb SADFR:

    Aber genau das habe ich doch geschrieben!!

    Ich habe schon "VMWare Terror Cluster" gesehen, die über kreuz den jeweils virtualisierten DNS des DC für ihre eigene Namensauflösung abfragten und sich alle dann wunderten, warum nichts mehr geht, wenn beide durchstarten und sich nicht mal gegenseitig finden ... das ist dann der einzige Moment, bei dem ich von HOSTS einträgen träume.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 10. Januar 2013 20:18
  • Das Thema wollte ich auch nochmal ansprechen. Aber dazu werde ich wohl mal ein neues Theam eröffnen.

    Stichwort: Hyper-V Failover Cluster unter Berücksichtigung von DC und Co.

    Zur Zeit gilt das Thema DC's und die Profildaten. Bin schon soweit darüber nachzudenken den Usern das Speichern von lokalen Daten zu verbieten oder Einstellungen vorzunehmen damit ich darüber nicht mehr nachdenken muss, Homeverzeichnisse dann auch nicht mehr.

    #

    Habe mich mal mit Martins Tip ein wenig vertraut gemacht. Die Idee alle Daten über DFS Namedspace zur Verfügung zu stellen klingt ganz gut, so die Theorie. Ich muss mich in die Thematik erst einmal einarbeiten, das ist bekanntlich nicht in wenigen Stunden zu erledigen ohne Gefahr zu laufen etwas zu konfigurieren was nicht Best Practice ist.

    DIe Idee von Martin war hierbei alle Daten per Script oder Robocopy abends von A nach B zu kopieren, fällt Profildatenserver1 aus, dann ändere ich einfach den Target auf Profildatenserver2.

    Wäre natürlich schön dafür auch einen transparenten Failover und Failback zu haben, ähnlich wie bei SVC und Storages. So etwas ist aber nicht möglich, oder? Kann man das nicht mit dem Rootserver realisieren? Kann man mit diesem nicht prüfen, ob mein Target erreichbar ist?

    #

    Wenn ich es richtig begriffen habe, dann lege ich ein Namedspace an (Daten) in diesen Namedspace lege ich links an, die auf ein Target zeigen (Share), diese Targets können auf unterschiedlichen Server liegen. Für den User ist es nur EIN virtuelles Laufwerk (Daten) deren Inhalt verfügbar ist, ähnlich wie bei einem Netzlaufwerk. Mit dem Unterschied, dass wir nicht auf ein physikalisches Verzeichnis zeigen (wie bei einem Netzlaufwerk), sondern auf ein virtuelles (Daten, Namedspace) was mit den Links auf physikalische Shares verweist (Targets auf unterschiedlichen Servern z.b).

    Liege ich da richtig?

    Das bedeutet in Martins Vorschlag lege ich ein Namedspace an (Daten) und erstelle Links, die z.B. auf Profile, Homeverzeichnisse und Ordnerumleitungen verweisen auf Server1. Im Profil des Domänenusers gebe ich im Profil folgendes an: (Profil) \\Daten\link1\%username%, (Homeverzeichnis) \\Daten\link2\%username%

    Nein, ich merke, dass das nicht richtig sein kann, denn dann müsste ich bei einem Crash des Server1 in jedem Domänenprofil den Pfad ändern. Ich komme noch drauf.. ;) oder einer von euchist wieder schneller...


    • Bearbeitet SADFR Donnerstag, 10. Januar 2013 20:52
    Donnerstag, 10. Januar 2013 20:51
  •  
    > Dehalb auch meine Frage, ob man diese Rolle über mehrere Server
    > verteilen kann. Denn wenn DC1 (PDC) down, dann würden die beiden
    > anderen für eine synchrone Zeit sorgen!??
     
    Ok, ich schränke meine Meinung ein wenig ein: Der PDC gehört auf Blech!
    Der Rest ist nicht so wichtig, aber der PDC ist die Zeitquelle, und er
    ist in der Regel auch Primary DNS für alle anderen... Und derjenige DC,
    den der PDC als DNS hat, gehört auch auf Blech.
     
    Warum das jetzt wieder? Manche sagen, jeder DC hat sich selbst als
    ersten DNS. Ich sage, jeder DC hat einen anderen (!) DC als ersten DNS
    und sich selbst erst als zweiten... Damit hat er auch dann noch einen
    DNS-Server, wenn sein AD ein Problem hat.
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 10. Januar 2013 20:51
  •  
    > Ich habe schon "VMWare Terror Cluster" gesehen, die über kreuz den
    > jeweils virtualisierten DNS des DC für ihre eigene Namensauflösung
    > abfragten und sich alle dann wunderten, warum nichts mehr geht, wenn
    > beide durchstarten und sich nicht mal gegenseitig finden ... das ist
    > dann der einzige Moment, bei dem ich von HOSTS einträgen träume.
     
    Thumbs up! Agree...
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 10. Januar 2013 20:52
  • Am 10.01.2013 21:51, schrieb Martin Binder:

    Ich sage, jeder DC hat einen anderen (!) DC als ersten DNS
    und sich selbst erst als zweiten... Damit hat er auch dann noch einen
    DNS-Server, wenn sein AD ein Problem hat.

    FACK!
    ... und vor allem kann man in dann auch demoten, ohne das er stirbt, denn er weiss dann wem er Bescheid sagen muss!

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 10. Januar 2013 21:19