NilsK

Moin, aber dem Kunden (und dir) ist schon klar, dass BGInfo hier nur ein Platzhalter ist für "beliebige Software, die im Unternehmen einfach so ohne Prüfung verteilt wird"? Denselben Angriff könnte man auch mit Word oder calc.exe machen. Und natürlich auch mit Backinfo. Gruß, Nils

Moin, es gibt Drittanbieterprodukte, die ein "lokales" oder auch ein Cloud-basiertes Backup von Office-365-Mailboxen anbieten. Man sollte aber immer klären, was denn wirklich benötigt wird. Meiner Erfahrung nach stellen viele Kunden fest, dass sie mit den eingebauten Retention-Methoden durchaus zufrieden sind. Man kann sich hier auch Ansätze überlegen wie eine "unendliche" Retention Time über Legal Hold für VIP-Mailboxen oder sowas. Also ein entschiedenes "kommt drauf an". ;) Zur Frage nach gelöschten Mailboxen hätte eine Webrecherche die Antwort ergeben, aber ich hab das einfach mal für dich erledigt: https://technet.microsoft.com/en-us/library/dn186233(v=exchg.150).aspx Gruß, Nils

Moin, ich hab hier keine Störungen. Gruß, Nils

Moin, nö. Backinfo gab es mal in einem uralten Resource Kit, Microsoft bietet es schon lange nicht mehr an. BGinfo wird laufend weiterentwickelt. Edit: ... und BGInfo lässt sich hervorragend konfigurieren, das Web ist voll von Ideen dazu. Obi auch: https://www.faq-o-matic.net/?s=bginfo Gruß, Nils

Moin, auf Wunsch des TO ist der Thread entfernt worden. Gruß, Nils

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 ...