Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.565
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von NilsK

  1. Moin, möglich, aber davon redet er hier gar nicht. Ja, das ist die typische NetApp-Argumentation. Habe ich auch jahrelang behauptet. Und die immanenten Nachteile gegenüber einer sauberen Trennung beider Ansätze (Performance, Komplexität, Funktionsverluste) geflissentlich vom Tisch gewischt. Und das ist der wichtigste Satz in deinem Beitrag. Gruß, Nils
  2. Moin, da differieren unsere Ansichten ja nicht. Ziemlich genau das meinte ich. Es geht aber eben nicht mit Bordmitteln, und es besteht ein Unterschied zwischen dem üblichen Verständnis von HA und dem von FT. Gruß, Nils
  3. Moin, jaja, das alte Missverständnis, dass man Live Migration auch dann erwartet, wenn ein Host ausfällt. Kann nicht gehen. In keiner Hypervisor-Welt. Man sollte auch beachten, dass Hochverfügbarkeit (HA) nicht dasselbe ist wie Fault Tolerance (FT). FT kann Hyper-V nicht ohne Zusatztools. In vSphere geht das (abhängig von der Lizenz), wird aber in der Praxis so gut wie nie eingesetzt, weil die Einschränkungen in den meisten Szenarien zu umfassend sind. Gruß, Nils
  4. Moin, Storage Live Migration kann Hyper-V auch nativ, SCVMM braucht man dafür nicht. In 2012 R2 auf jeden Fall, in 2012 glaube ich auch. Das geht dann ohne Downtime für die VMs. Auch cluster-übergreifend (nennt sich dann "Shared-Nothing Live Migration"). Gruß, Nils
  5. Moin, und genau deshalb stellen wir die Nachfragen. Wenn du dazu nichts sagen willst oder kannst, dann bleibt es pauschal bei: Ja, es ist mit gravierenden Problemen zu rechnen, wenn die Namen sich nicht unterscheiden. Da das hier offenbar jetzt ins Fruchtlose übergeht, belasse ich es dabei. Gruß, Nils
  6. Moin, jaja - aber wie wollt ihr die Daten von Alt nach Neu übertragen? Kaum vorstellbar, dass dabei kein Trust ins Spiel kommt. Gruß, Nils
  7. Moin, und Dateiserver, Datenbanken, Mailsystem, Applikationen habt ihr nicht? Gruß, Nils
  8. Moin, einfach gesagt: sofern es eine Migration irgendwelcher Objekte oder Daten von der alten zur neuen Domäne geben soll, müssen die Namen unterschiedlich sein, sowohl DNS als auch NetBIOS. Gruß, Nils
  9. Moin, und um das noch ausdrücklich zu ergänzen: Zwei Domänen mit demselben NetBIOS-Namen sind untereinander nicht migrationsfähig. Die Namen müssen sich unterscheiden. Laufende Probleme mit den gleichen NetBIOS-Namen kommen dann noch hinzu, insbesondere, wenn beide in einem Subnet sind. Gruß, Nils
  10. Moin, naja, sooo abwegig ist das Missverständnis nun auch wieder nicht. Schaut mal in euer Windows-Startmenü, da steht "Neu starten" für einen ordentlichen Reboot, nicht für einen Reset. Nur so zur Ehrenrettung des TO. ;) Gruß, Nils
  11. Moin, eine Alternative wäre, das per GPO zu regeln. Gruß, Nils
  12. Moin, einen solchen "Speicherabzug" kannst du nur als Administrator machen, nicht als normaler User. Und als solcher kommst du ohnehin überall ran. Wenn man weiß, wie es geht, wird man so auch an die Speicherbereiche anderer, gleichzeitig angemeldeter User kommen. Das ist dann aber eher ein generelles Problem als eins der Benutzerumschaltung. Ein Admin bekäme das, wenn er will, auch ohne das Feature hin. Gruß, Nils
  13. Moin, pauschal kann man es nicht als Risiko bezeichnen. Lizenzrechtlich ist es neutral, weil immer nur ein User lokal aktiv arbeiten kann. In früheren Windows-Versionen wr das Feature noch nicht ausreichend stabil, weswegen es auf Domänenrechnern automatisch abgeschaltet war. Ich meine, dass es seit Windows 7 auch in Domänen verfügbar ist. Technisch ist das umgesetzt wie eine RDP-Sitzung. Es wird also die Multi-User-Technik der Terminalserver verwendet. Das kann aus Sicherheitssicht unerwünscht sein, wenn es konkrete Einschränkungen in der Nutzung eines Clientrechners gibt. Pauschal ist es, wie gesagt, nicht zu beanstanden. Gruß .Nils
  14. Moin, was genau meinst du mit "der Domänen-Administrator wird gesperrt"? Das Konto dieses Administrators wird im AD gesperrt? Oder wie? Um was für ein Konto handelt es sich dabei? Das vordefinierte "Administrator"-Konto? Ein anderes? Unterschiedliche? Gibt es nur das eine? Wie viele Domänencontroller hat die Umgebung? Geben die Security-Eventlogs der DCs Auskunft über das Phänomen? Ist auf dem Dateiserver irgendwas installiert, was die Anmeldedaten des betreffenden AD-Kontos verwendet? Bei dem beschriebenen Phänomen fiele mir z.B. ein On-Access-Virenscanner ein. Ist ein Task mit dem Account eingerichtet? Mit was für einem Account bist du angemeldet, wenn das Phänomen auftritt? Gruß, Nils
  15. Moin, Gut, aber dann bleibt meine oben gestellte Frage: Wie würdet ihr das Problem lösen wollen, wenn ihr die Domain selbst kontrolliert? Es bliebe irgendwie dasselbe, oder? Gruß, Nils
  16. Moin, Benötigt wird die Reverse-Zone für das AD überhaupt nicht. Sie ist aus dieser Sicht ein reines Komfort -Feature. Gruß, Nils
  17. Moin, Ja: Die, über die du etwas wissen willst. Gruß, Nils
  18. NilsK

    Netz für Livemigration

    Moin, Nein, DocData, nur deine Frage ist lächerlich. Ganz abgesehen davon, kann man in diesem Thread nicht viel mehr antworten als: Technisch geht vieles, es kommt auf die Anforderungen an. Gruß, Nils
  19. Moin, mir ist gerade nicht klar, wie ihr das beschriebene Problem verhindern würdet, wenn ihr die Domain besitzen würdet. Wollt ihr dann ins Public DNS eure internen Servernamen eintragen? Oder wie es bei zahlreichen anderen Kunden aussähe, deren interne Hosts ja schließlich auch nicht über das Public DNS auflösbar sind, selbst wenn sie keinen Fehler beim Benennen ihrer Domäne gemacht haben. Und irgendwie kommt mir dabei nur in den Sinn: Euer Problem liegt gar nicht im Namen der Domäne, sondern in dem Verbindungskonstrukt, das ihr da nutzt. An das solltet ihr ran. Nicht an den Domänennamen. Gruß, Nils
  20. Moin, LOL! Gruß, Nils
  21. Moin, es war sicher nicht gemeint, dafür kein Backup zu machen. Als Ergänzung kann das für größere Umgebungen sehr interessant sein. Gruß, Nils
  22. Moin, doch, such mal nach "muller". Zauberei. Gruß, Nils
  23. Moin, ich werfe noch mal eben ein, dass die "Rechtestruktur" üblicherweise auf Zugriffsberechtigungen auf einem Dateiserver abzielt, aber nicht auf die administrative Struktur im AD. Informationen über die Abteilungszugehörigkeit sowie die disziplinarische Hierarchie bildet man im AD an anderer Stelle ab. Ich habe bislang selten Unternehmen gesehen, in denen im AD eine stärkere Unterteilung als "Benutzer" und "Admins" auf OU-Ebene überhaupt nötig gewesen wäre. Aber wie Norbert schon sagt: Das ist für ein Forum wenig geeignet. Gruß, Nils
  24. Moin, danke für dein Vertrauen, aber deine Frage hat mit dem Thread nichts zu tun. Bitte eröffne einen neuen Thread dafür. Danke. Gruß, Nils
  25. Moin, jaja, das sind die Gründe, warum man das AD immer doppelt sichern sollte: Einmal mit Bordmitteln und dann (sofern vorhanden) mit der separaten Backup-Lösung. Dann gibt es immer ein Backup, das auch vom Hersteller unterstützt wird. Image-basierte Sicherungen sind immer kritisch zu beurteilen, sofern sie nicht ausdrücklich für AD freigegeben sind (wie es bei Veeam m.W. der Fall ist). [Warum Images nicht als Datensicherung taugen | faq-o-matic.net] http://www.faq-o-matic.net/2006/08/04/warum-images-nicht-als-datensicherung-taugen/ [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] http://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ [AD: Betriebsmaster-Ausfall – was tun? | faq-o-matic.net] http://www.faq-o-matic.net/2010/09/09/ad-betriebsmaster-ausfall-was-tun/ Gruß, Nils
×
×
  • Neu erstellen...