NilsK

Moin, mein eigentlicher Punkt war, dass du für die beiden betrachteten Fälle nicht mal SSDs brauchst. Wenn du sie übrig hast, nimm sie. Aber für sowas müsste man keine kaufen. Gruß, Nils

Moin, man kann sogar noch weiter gehen. Weder der Host (die Parent Partition) noch ein DC brauchen schnelle Plattensysteme. Und ein DC braucht keine besondere Hardwareredundanz, weil die Applikation die Redundanz bereitstellt. Gruß, Nils

Moin, ich ergänze mal, weil man das wissen sollte: Ich sehe mittlerweile immer öfter, dass Outlook-Benutzer genau wegen dieser Darstellung Termine nicht mehr annehmen. Sie sehen die im Kalender und unterscheiden selbst gar nicht mehr zwischen "unter Vorbehalt" (weil ich nur eingeladen wurde) und "zugesagt" (ich habe auf "Annehmen" geklickt). Dadurch ist es für andere dann nicht mehr nachzuvollziehen, ob derjenige nun an einem Termin teilnimmt oder nicht. Ganz ohne den Benutzer wird es hier also auch nicht gehen. Gruß, Nils PS. oder wie andere sagen würden: Es gibt keine vollständigen technischen Lösungen für organisatorische Probleme.

Moin, ja, so ist das eben. Wir neigen dazu, Fragen ernst zu nehmen und schauen deshalb auch gern mal hinter die Kulissen. Ich verstehe die Dienstleisterzwänge, auf die du verweist, nach 25 Jahren als IT-Dienstleister durchaus. Trotzdem darf man auch als IT-Dienstleister mal auf Zusammenhänge hinweisen und sollte nicht den Eindruck erwecken, durch Technik lasse sich alles lösen. Das Argument, das du hier anführst, ist doch nur vordergründig eins. In dem Szenario würde es innerhalb von Minuten auffallen, dass Mitarbeiter A der Schuldige ist. Und da er bei einem Anwalt arbeitet, würde er das mit großer Sicherheit nicht wiederholen. Exchange hat seine Grenzen. Für spezielle Anforderungen gibt es andere Lösungen. Zu dieser Einsicht gehört aber, wie gesagt, aus meiner Sicht auch, die Dinge einzuordnen. Gruß, Nils

Moin, Unnötiger Aufwand. Ein restore zieht fast immer Sachen nach sich, die man nicht im Blick hatte. Und du hast oben ein paar Dinge erwähnt, die ich nur im Notfall machen würde. Der liegt hier aber nicht vor. Gruß, Nils

Moin, das könnte er natürlich tun, aber warum sollte er? Diese Befürchtung ist doch nicht praxisgerecht. Gruß, Nils

Moin, Norbert hat Recht. Keine Experimente mit einem DC, wenn es noch einen anderen gibt. Gruß, Nils

Moin, Ja, sehe ich auch so. Trotzdem ist es wichtig zu wissen, dass man sich um die Logs kümmern muss, sobald man auf Full stellt. Wenn die Backup-Software das tut, prima, aber man sollte nicht einfach davon ausgehen. Gruß, Nils

Moin, das habe ich auch jahrelang gedacht und behauptet. Das ist aber nicht so. Mindestens das eingebaute Backupsystem lässt bei einem Full Backup die Logs in Ruhe. Man muss sich separat drum kümmern. https://www.sqlservercentral.com/forums/topic/does-a-full-backup-truncate-the-log Gruß, Nils

Moin, Welcher Unterschied der Dateien? Robocopy wird für Migrationen sehr oft eingesetzt. Die Downtime kann man nahe Null halten, indem man vorsynchronisiert und dann am Ende nur noch ein kleines Delta abgleichen muss. Von Stunts mit Spiegeln würde ich Abstand nehmen. Gruß, Nils

Moin, also, wenn du den Aufwand reduzieren willst, dann an sinnvoller Stelle. Da käme für mich nur etwas weiter vorne im Ablauf in Frage. Wenn du bei der CSV-Verarbeitung bleiben willst, dann nimm die Datei, die möglicherweise kaputt ist, entferne die möglicherweise kaputten fünf Zeilen und speichere sie wieder ab. Wenn du nur so sichergehen kannst, dass der CSV-Import über das Cmdlet funktioniert (das nun mal eine ordentliche Datei erwartet, dafür aber auch Vorteile bietet), dann würde ich an der Stelle nicht weiter rummachen. Dein Skript kann dann ja am Ende auch noch aufräumen. Du schreibst hier ja schließlich ein Skript und keine ERP-Anwendung. Gruß, Nils

Moin, was uns zum Anfang zurückführt ... lässt sich der Umweg über CSV, vielleicht sogar der über Excel vermeiden? Falls nicht, dann ist es vielleicht wirklich am einfachsten, die Importdatei erst zu korrigieren und dann zu verarbeiten. Gruß, Nils

Moin, der Grund ist, dass mit Anführungsstrichen der Inhalt eines einzelnen Feldes begonnen wird, falls sich innerhalb des Feldes Trennzeichen befinden. Das Import-Cmdlet sieht nun also das "öffnende" Anführungszeichen, sucht das schließende und behandelt alles dazwischen als ein einziges Feld. Wenn es kein schließendes Zeichen gibt, läuft das Cmdlet vermutlich auf einen Fehler. In beiden Fällen importiert das Cmdlet aber die Datei nicht so, wie es gewünscht ist. Wie Evgenij richtig zusammenfasst, erfüllt deine CSV-Datei damit nicht zuverlässig die Bedingungen für einen erfolgreichen Import. Und nun siehst du, warum wir nach dem Hintergrund fragen ... Gruß, Nils

Moin, gut, zu deinem akuten Punkt hat Olaf dir ja schon Hinweise gegeben. Aber deine Schilderung illustriert schön, was ich meine: Ja, das ist eine typische Anforderung. Als Berater denke ich mir: Wie kommen denn die Daten in das Excel hinein? Wäre es evtl. sinnvoller, diesen Umweg einzusparen und dort, wo bislang das Excel erzeugt wird, gleich direkt das LDAP zu ändern? Vielleicht ist das auch noch nicht der richtige Ansatz, aber du siehst evtl., was ich meine. Gruß, Nils

Moin, aha, es handelt sich also um eine wiederkehrende Aufgabe mit wechselnden Daten? Was geschieht damit, d.h. in welcher Art verarbeitest du das weiter? Bekommst du die CSVs direkt oder erzeugst du die selbst? Falls du die CSVs bekommst, könntest du auch die Excels direkt erhalten? Hintergrund der Fragen: Wenn wir wissen, welche Aufgabe du eigentlich lösen musst, können wir dir vielleicht besser helfen. Wir erleben immer wieder, dass wir ein Detailproblem mit jemandem lösen und hinterher feststellen, dass es viel leichter wäre, die tatsächliche Aufgabe ganz anders anzugehen. Gruß, Nils

Moin, stellen wir das Ganze doch mal auf die Füße: Was hast du denn insgesamt vor? Gruß, Nils

Moin, ein einzelner DC funktioniert so lange gut, wie der einzelne DC gut funktioniert. Wen würdest du denn wohin umleiten wollen? Am DNS ändert sich ja nix. Gruß, Nils

Moin, zwei Dinge: DHCP sollte nicht auf einem DC laufen, das ist sicherheitstechnisch nachteilig solange du keinen anderen zweiten DC installierst, solltest du den 2012 R2 in dieser Rolle belassen Gruß, Nils

Moin, Hier geht es um Export und Import, da läuft die VM während des Imports nicht. Bei einer nicht laufenden VM sind CPU-Unterschiede nicht relevant. https://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/ Gruß, Nils

Moin, Ja. Gruß, Nils

Moin, Pauschal must du nichts beachten, das sollte einfach so funktionieren. Die CPU-Kompatibilität braucht man, wie du vermutest, nur bei der Live-Migration, wenn die Hosts unterschiedliche CPUs haben. Kopiere die VMs gleich in den Zielordner, dann musst du sie nur noch registrieren. Gruß, Nils

Moin, Das ist das Schöne, wenn man Dienstleister ist. Man empfiehlt und weist hin, danach führt man aus. Und wenn sich die Entscheidung des Kunden hinterher als doch nicht so gut herausstellt, kassiert man das zweite Mal für die Korrektur. Dass die oft teurer ist als die ursprüngliche Einrichtung, war hier ja schon Thema, meine ich. Gruß, Nils

Moin, ja, das ist natürlich korrekt. Das ursprüngliche Szenario geht ja aber von "massenweisen" Domains aus, die nach einem technisch sinnvollen Konzept benannt werden sollen. Da wären zwei Namen, die man separat als "eindeutig" entwerfen muss, dann kontraproduktiv. Das wirst du bei einer Technik, die möglichst viel Freiheit für geschäftlich begründeten Bedarf geben soll, immer wieder antreffen. Es gibt dann einfach kein "Richtig" oder "Falsch". Und, da du hier später in den Thread eingestiegen bist: Berücksichtige, dass der ursprüngliche TO ein sehr spezielles Szenario hatte. Das mag deinem ähneln, mag bei dir aber auch ganz anders sein. Gruß, Nils

Moin, Das ist am Ende Geschmackssache, jedenfalls soweit es DNS betrifft. Ich würde dazu neigen, diesen Namen direkt zu verwenden, denn eine Subdomain müsste ja wieder eindeutig sein, weil von ihr der NetBIOS-Name abgeleitet wird. Gruß, Nils

Moin, Oder um die Dinge einfach mal beim Namen zu nennen: ich empfehle kompetente Beratung. Ein Buch kann ich zwar auch empfehlen (das von Rheinwerk), aber leider fehlen da die konkreten Anleitungen, wie man es nach Best Practice wirklich aufbaut. Gruß, Nils