NilsK

Moin, war Backinfo nicht sowieso der Vorgänger von BGInfo, ist also von diesem abgelöst worden? Gruß, Nils

Moin, dann wären jetzt Konfigurationsdetails von Interesse. Vor allem natürlich die Unterschiede zwischen beiden Hosts. Gibt es einen "Details"-Button bei der Fehlermeldung? Steht da noch was drin? Gruß, Nils Moin, i5? Also eine Testumgebung? Warum zwei externe Switches? Ist eine Netzwerkverbindung vorhanden, auf die das Management OS die Live Migration binden kann? Gruß, Nils PS. Etwas mehr Informationen müssten schon kommen, sonst werden wir nichts beitragen können.

Moin, zumindest ist mir das so in der Art schon von meinen NetScaler-Kollegen beschrieben worden. Dürfte also ein übliches Vorgehen sein. Gruß, Nils PS. Danke für die Rückmeldung!

Moin, gut, dann dürfte dir nach diesem Thread ja vielleicht auch klar sein, dass der bislang gewählte Ansatz nicht günstig ist. Ihr braucht erst ein Design, das eure Anforderungen abdeckt. Danach kann es an die Implementierung gehen. Und auch wenn das Design für jemanden mit Erfahrung keine unlösbare Aufgabe ist, birgt es ausreichend Komplexität und damit Fehlermöglichkeiten. Ressourcen, um in Ruhe die nötigen Kenntnisse aufzubauen, sind dir genannt worden. Wir haben dich ebenso darauf hingewiesen, dass du an einigen Stellen von falschen Annahmen ausgehst und dass du zu früh mit der Implementierung angefangen hast. Mehr ist im Rahmen eines Forums nicht leistbar. Wir können hier weder komplexe Grundlagen vermitteln (und PKI ist komplex, immer) noch ein fertiges Design liefern. Ein Forum kann den grundlegenden Weg weisen (haben wir getan) oder in vielen Fällen Detailfragen klären (da sind wir in diesem Fall aber nicht). Gruß, Nils

Moin, ohne nähere Informationen keine Aussage möglich. Was sagt denn das Eventlog? Dabei auch in den Anwendungslogs nachsehen, da gibt es einige Hyper-V-Logs, die vielleicht was dazu enthalten. Gruß, Nils

Moin, wie magheinz schon richtig sagt: IPv6 ist völlig anders als IPv4. Du vergibst (im Normalfall) weder Adressen an Rechner noch brauchst du DHCP für eine Autokonfiguration. Folgendes Buch führt ganz gut und praxisnah in die Materie ein: http://www.apress.com/de/book/9781430263708 Gruß, Nils

Moin, gern, danke für die Rückmeldung! Gruß, Nils

Moin, ja, den nutze ich in letzter Zeit auch manchmal. Parallel hab ich noch den hier: http://www.regexr.com/ Gruß, Nils

Moin, na OK, dann wissen wir ja alle Bescheid. In den Newsgroups pflegte man früher zu sagen: Plonk. Gruß, Nils

Moin, prima, dann wäre das ja geklärt. :) Gruß, Nils

Moin, danke, ich habe den Blog gelesen. Und verstanden. Ganz sicher. Du musst mir keine Unwissenheit unterstellen, wenn ich anderer Meinung bin. Irgendwann ist auch mal gut. Dass bei der Abfrage "welche Konten wurden seit 90 Tagen nicht verwendet?" ein paar Konten wegen des beschriebenen Mechanismus durchs Raster fallen, ist unerwünscht - da sind wir uns einig. Und sicher war es beim Design des Attributs auch nicht im Blick, ist also - auch da sind wir uns einig - ein funktionaler Fehler. Trotzdem sehe ich es nicht so, dass das Attribut und der Use Case damit nicht nutzbar wären. In den allermeisten Umgebungen tritt das in dem Blog beschriebene Problem gar nicht auf. Ich habe das bei Kunden sehr oft durch Plausibilitäts-Vergleiche überprüft. Und, wie gesagt: Der Use Case, für den das Ganze entworfen wurde - Aufräumen - funktioniert auch mit der Ungenauigkeit, die das beschriebene Problem erzeugt. Mehr als Ungenauigkeit ist es dann nämlich nicht. Von jeder anderen Verwendung des Attributs und jeder weiter gehenden Interpretation der Werte rate ich ab, schon immer. Gruß, Nils

Moin, nein, das Stichwort heißt: Neuen DC installieren. Kostengründe? Bei einer VM-Umgebung? Selbst wenn man, was ich schon für sehr fragwürdig hielte, die ganzen Funktionen auf einem Server bereistellen würde, würde eine separate VM als DC gar keine Kosten verursachen. Oder, wenn es hochkommt, eine einzelne zusätzliche Standard-Lizenz. Wegen der 700 Euro würde ich kein auch noch so geringes Risiko für das AD akzeptieren. Abgesehen davon, dass Altaro meines Wissens eine DC-VM ordnungsgemäß wiederherstellen kann: Derartige Akrobatik, wie du sie beschreibst, führt eigentlich immer zu einem Fehlschlag. Das funktioniert nicht. Warum es nicht einfach richtig machen? Gruß, Nils

Moin, und der NetBIOS-Name der Domänen? Aber vielleicht vom selben Image, das nicht gesysprept war? Das ist immer ein Kandidat. Gruß, Nils

Moin, erneut: Wenn du eine neue Frage hast, mach bitte einen neuen Thread auf. Die Threads sind im allgemeinen, so auch hier, nach Themen organisiert, nicht nach Fragesteller. :) Gruß, Nils

Moin, erfahrungsgemäß sollte man die Lizenzbedingungen nicht zu kreativ lesen und mit solchen Interpretationen "Lösungen" bauen. Das sind genau die Fälle, wo fast immer Nachzahlungen entstehen. Gruß, Nils

Moin, also, ehrlich gesagt, scheinen mir da ein paar Missverständnisse und Wissenslücken vorzuliegen. Wie wäre es, wenn du dir punktuell mal jemanden ins Haus holst, mit dem du das gemeinsam konzipieren kannst? Ein ordentliches Konzept ist gar nicht so aufwändig, wie du das zu befürchten scheinst. Gruß, Nils

Hallo. :D Und deine Frage? ;)

Moin, wenn du noch einen laufenden DC hast, dann machst du überhaupt kein Recovery. Dann installierst du einen neuen DC und entfernst den nicht mehr laufenden aus dem AD (löschen in ADUC, ggf. in Sites and Services und in DNS). [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ [ist Active Directory in Windows Server 2012 wirklich virtualisierungsfest? | faq-o-matic.net] https://www.faq-o-matic.net/2013/09/11/ist-active-directory-in-windows-server-2012-wirklich-virtualisierungsfest/ Gruß, Nils

Moin, das haben wir seinerzeit ja schon diskutiert. LastLogonTimestamp wurde für "unscharfe" Abfragen entworfen, vor allem für die typische Frage "welche User- bzw. welche Computerkonten werden nicht mehr verwendet?". Dafür reicht die Genauigkeit in praktisch allen Fällen aus. Als Sicherheitselement war es nie gedacht, daher ist die Kritik daran zwar sachlich richtig, aber eben doch meist unpassend. Gruß, Nils

Moin, naja, was sollen wir in dem Fall darauf antworten? Gruß, Nils ... siehe auch meine Signatur ...

Moin, ob eine solche Einschränkung akzeptiert wird, hängt immer sehr vom Auditor ab. Es gibt Kunden, die mit sowas durchkommen und damit Lizenzkosten sparen. Andere müssen nachzahlen. Die betreffende VM nur aus der HA zu nehmen, reicht i.d.R. nicht aus. Man muss diese Konfiguration auch über die Laufzeit des Systems belegen können. Daraus sollte auch hervorgehen, auf welchem Host die VM wann lief. Mindestens ein solches zusätzliches Logging ist erforderlich, ohne wird es i.d.R. nicht akzeptiert. Vielleicht können andere noch weitere Erfahrungen beisteuern. Gruß, Nils

Moin, nein. Deine Vorbehalte sind nachvollziehbar, aber für die meisten Szenarien gar nicht zutreffend - unter anderem für das hier diskutierte. Wenn man lastLogonTimestamp für das nutzt, wofür es entworfen wurde, ist es die beste Variante. Gruß, Nils

Moin, sehe ich das richtig, dass ihr die Netze rein logisch trennen wollt, ohne VLANs usw.? Wenn ja: Warum? Gruß, Nils

Moin, wenn der Rechner offline ist, könntest du versuchen, dem Phänomen mit dem Process Monitor auf die Spur zu kommen. Vielleicht ist es nur eine Applikation, die fehlerhaft läuft. Gruß, Nils

Moin, genau aus dem Grund gilt die Empfehlung, dass man (mindestens) einen DC pro Domäne unabhängig von der Virtualisierung hält. Aber ihr habt doch hoffentlich nicht nur einen DC, oder? [Darf man einen Domänencontroller virtualisieren? | faq-o-matic.net] https://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/ Sofern der Cluster und die VMs laufen, ist mit keinen Einschränkungen zu rechnen, wenn der DC kurz nicht erreichbar ist. Sollte tatsächlich kein DC/DNS erreichbar sein, wird es natürlich mit der Namensauflösung schwierig, wenn die Adressen nicht mehr im Client-Cache liegen. Die AD-Anmeldung selbst ist aber längere Zeit gültig. Der Cluster sollte auf jeden Fall AD-integriert sein. Rein DNS-integrierte Cluster haben zahlreiche Nachteile. Gruß, Nils