NilsK

Moin, nee, so nicht ganz. Das wäre nur bei SMB 3.0 und gerade nicht per Teaming, sondern mit zwei unabhängigen IP-Verbindungen. Von dem Team weiß das Betriebssystem an der Stelle ja nix. Darum bau ich es ja. ;) Gruß, Nils EDIT: 3.0, nicht 2.0

Moin, beim Teaming fasst du mehrere Leitungen zu einer logischen Einheit zusammen. Es bleiben aber einzelne Leitungen. Man fasst das gern in eine Analogie: Wenn du eine einspurige Straße hast und dort ist nichts los, kannst du mit deinem Auto z.B. 100 km/h fahren. Ist ein Laster vor dir, dann muss du auf den warten. Hast du nun eine zweispurige Straße, dann kannst du an dem Laster vorbeifahren. Es gehen also mehr Fahrzeuge zur selben Zeit durch. Wenn nichts los ist, kannst du mit deinem PKW aber trotzdem nur 100 km/h fahren. Du kannst dich nicht in zwei PKWs aufteilen, die jeweils 100 km/h fahren. Der Traffic einer einzelnen Applikation, VM usw. wird also nicht schneller, nur weil das Team nominell "doppelt so schnell" ist. Hast du aber zwei Applikationen, VMs usw., dann müssen diese nicht aufeinander warten, sondern können parallel Daten raussenden. Gruß, Nils

Moin, ... und dass auch der ausgehende Datenverkehr nur dann auf die Teammitglieder verteilt wird, wenn es unterschiedliche Streams sind. Gruß, Nils

Moin, wenn ich es richtig verstehe, hat dein "alter" Server mehrere Rollen, die man nicht gemeinsam betreiben sollte. Auf keinen Fall sollten Hyper-V und die Domänencontroller-Rolle "parallel" laufen. Auch ein Groupware-System wie David sollte man nicht direkt auf einem DC betreiben, auch wenn es dort weniger direkte Abhängigkeiten gibt als bei Exchange. Aber du stehst ja gerade vor einem der Probleme solcher "Rollen-Konzentration": Eine Migration wird sehr komplex. Und wenn mal was mit dem Server ist, stehen gleich alle Funktionen nicht mehr zur Verfügung. Ohne jetzt im Einzelnen verstanden zu haben, wie die Umgebung aussieht, und ohne (notwendige) nähere Analyse würde ich folgende Idee mal untersuchen: Eine neue Server-Hardware, eingerichtet mit Windows Server 2012 R2 als Hyper-V Host Keine (!) weiteren Rollen in dieser Installation Innerhalb von Hyper-V eine VM als Domänencontroller Innerhalb von Hyper-V eine weitere VM als David-Server Dazu ein passendes Backup- und Recovery-Konzept Mit so einem Konstrukt ist dann auch die Migration (vom Prinzip her) überschaubar: Die DC-VM als zusätzlichen DC in die vorhandene Domäne bringen, Replikation abwarten, FSMO-Rollen übertragen David auf die neue VM migrieren Weitere Dienste am besten in weitere VMs migrieren - je nachdem, wie groß die Gesamtumgebung ist, können bestimmte Kombinationen in derselben VM machbar sein Wenn der "alte" DC nicht mehr benötigt wird, diesen ordentlich herunterstufen und dann abschalten und entfernen Die weiteren Details sollte man separat betrachten. Gruß, Nils

Moin, 10 GB pro Tag macht 300 GB im Monat. Nur für den Upload deines Backups. Sei nur mal so angemerkt. Ich kann mir gut vorstellen, dass dein Provider das auf Dauer nicht so gut findet. Gruß, Nils

Moin, meine Erfahrung mit Experimenten in der Hinsicht ist, dass man von so einer Lösung nicht zu viel erwarten darf. Sie dürfte nur für relativ kleine Datenmengen geeignet sein und benötigt eine hohe Fehlertoleranz. Hast du wirklich eine Internetverbindung, die jede Nacht 120 GB im Upload verarbeitet bekommt? Hast du auch das nötige Inklusivvolumen dafür? Gruß, Nils

Moin, allgemein sind USB-Platten für den Serverbetrieb nicht geeignet. Aus dem beobachteten und aus anderen Gründen fehlt ihnen die Zuverlässigkeit dafür. Gruß, Nils

Moin, ich verstehe das immer noch nicht. Normalerweise geht es so (wenn der Host/PC nur eine physische Netzwerkkarte hat): Du richtest einen virtuellen Switch vom Typ "extern" an, den du auf die physische Netzwerkkarte des Hosts (also deines PCs) verbindest Du aktivierst dabei das Häkchen "Gemeinsame Verwendung ... zulassen"Dadurch ist der vSwitch sowohl für die VMs als auch für den Host (= den PC) nutzbar, um über das LAN zu kommunizieren Du richtest deine VMs so ein, dass deren Netzwerkkarte mit dem virtuellen Switch verbunden ist Auf dem Host (= PC) siehst du in der Systemsteuerung nun eine neue virtuelle Netzwerkkarte. Hier konfigurierst du die IP-Adresse so, dass die Kommunikation möglich ist Die physische Netzwerkkarte in derselben Übersicht lässt du unangetastet. Dort ist nur noch ein Häkchen bei "Hyper-V erweiterbarer virtueller Switch" gesetzt - nichts ändern! Innerhalb der VMs konfigurierst du die IP-Adressen dann so, dass sie kommunizieren können Gruß, Nils

Moin, ich kann dir gerade nicht folgen. Die phyische Netzwerkkarte muss deaktiviert sein ...? Das kann so nicht stimmen. Und ein "interner" Switch kann keine Verbindung ins LAN herstellen. Magst du das noch mal genauer beschreiben? Gruß, Nils

Moin, dann schau dir mal 5Nine an. Gruß, Nils

Moin, wenn kein Geld für eine ordentliche Datensicherung da ist, dann sind die Daten offensichtlich nichts wert. Wozu dann ein Cluster?! Ich klink mich dann mal aus. Nicht dass noch jemand denkt, ich hätte was damit zu tun ... Gruß, Nils

Moin, insgesamt klingt das nicht nach einem guten Plan. Allgemein: Wenn für das Backup nicht genügend Budget vorhanden ist, dann ist das Budget falsch geplant. Insbesondere im Zusammenhang mit einem Cluster kommt Knauserigkeit (wenn ich es mal so nennen darf) gar nicht gut - und beißt sich schon konzeptionell. Das geht im Fall des Falles ganz schnell so weit in die Hose, dass der Schaden größer ist als wenn man auf einen Cluster verzichtet und dafür ein ordentliches Recovery-Konzept gehabt hätte. Andersrum kommt oft erst in so einer Situation die Einsicht, dass das Budget, den Cluster und die Umgebung drumrum ordentlich zu bauen, deutlich geringer gewesen wäre als der eingetretene Schaden. Ein NAS kannst du gar nicht in einen Cluster einbinden - wobei das erst mal eine Frage der Begrifflichkeit ist. NAS bedeutet Dateiserver, iSCSI bedeutet Blockzugriff. Die meisten Geräte, die heute als NAS verkauft werden, können auch iSCSI, sind dadurch aber noch lange nicht als Blockspeicher für den Serverbetrieb geeignet. Ich gehe mal davon aus, dass es sich um ein Gerät der SOHO-Klasse handelt (wenn nicht, korrigiere mich), und so eins hat in einem Cluster nichts zu suchen. Zu deiner technischen Frage: Ein CSVFS-Volume ist in Wirklichkeit ein normales NTFS-Volume. CSVFS sorgt nur dafür, dass alle Schreibzugriffe über den Cluster gesteuert werden. Wenn du die zugehörige LUN aus dem Cluster entfernst, kannst du sie - technisch betrachtet - als LUN an einen Windows-Server anhängen, und der sieht dann ein NTFS-Volume und kann darauf zugreifen. Aber wie gesagt: Ich würde das bleiben lassen. Gruß, Nils

Moin, gemeint ist der Enhanced Session Mode. Im Hyper-V-Konsolenfenster unter Ansicht/Erweiterte Sitzung. Gruß, Nils

Moin, naja, so ähnlich. Jedenfalls ist sie keine sekundäre Zone. ;) EIne AD-integrierte Zone wird nach dem Multi-Master-Prinzip repliziert, d.h. es gibt keinen "single master" wie bei einer Primären Zone. Alle DNS-Server können die Daten dann ändern, und es wird auf Attributebene repliziert. Im herkömmlichen System gibt es ja genau eine Primäre Zone, nur dort kann man ändern. Die Sekundären speichern dann Read-only-Replikate. Gruß, Nils

Moin, wenn die Bordmittel nicht ausreichen, verdient der 5Nine Manager einen Blick. Kostet nur schmales Geld und bringt einiges an interessanten Management-Funktionen mit. [5nine Manager for Hyper-V. Microsoft Hyper-V management tool] http://www.5nine.com/5nine-manager-for-hyper-v-product.aspx Ansonsten ist es mit den Funktionen des vSphere-Clients in vielen mittleren Umgebungen so wie früher mit den Spezialfunktiionen von Novell Netware: Wer umsteigt, glaubt, ohne nicht arbeiten zu können. Wer sie nicht kennt, vermisst sie auch nicht. ;) Gruß, Nils

Moin, kann man einen SBS herunterstufen? Weiß ich grad nicht. Falls ja, sollte man das tun. Vor dem Entfernen eines DC ist es immer sinnvoll, ihn ordentlich herunterzustufen. Dadurch versuicht er gleich, ein paar Aufräumvorgänge anzustoßen. Falls das nicht geht, reicht es seit Windows 2008 aber auch aus, das (dann verwaiste) Computerobjekt zu löschen, auch dann räumt AD auf. Nach Abwarten der Replikation sollte man dann aber noch DNS überprüfen und dort ggf. verbliebene Einträge löschen. Gruß, Nils

Moin, dafür braucht es keine Hyper-V-Experten. Daher antworte ich jetzt als AD-Experte. :D Grundsätzlich sollte man immer mindestens einen DC pro Domäne mit Bordmitteln per Systemstate sichern. Auch dann, wenn man eigentlich das Backup anders macht - im Zweifel hat man dann eben zwei AD-Sicherungen. Grund: Nur das Systemstate-Backup wird von Microsoft voll unterstützt. Sollte das "normale" Backup mal nicht mehr gehen, hat man so immer noch eine Ebene, die vom Hersteller der Applikation (eben AD!) unterstützt wird. Sollte ich mal als FAQ formulieren, glaube ich. :) Von allen Snapshot-, Image- oder Full-VM-basierten Sicherungen von Domänencontrollern rate ich auch weiterhin entschieden ab (ja, auch in Zeiten der VMGenerationID). Gruß, Nils

Moin, vielleicht hilft für deine Aufgabe auch diese Variante. Die nutzt dasselbe Basis-Tool, um die Eventlogs in eine SQL-Datenbank zu schreiben. Da kann man sie dann nach Belieben auswerten. ("Mal eben nebenbei" ist das allerdings auch nicht, wenn auch weniger aufwändig.) [Eventlog-Backup mit Log Parser | faq-o-matic.net] http://www.faq-o-matic.net/2011/03/21/eventlog-backup-mit-log-parser/ Gruß, Nils

Moin, das Caret (^) ist der Escape-Character in Batches. Er sorgt dafür, dass das nachfolgende Zeichen als Literal behandelt wird (also als "Zeichen") und nicht als Operator. Gruß, Nils

Moin, CALs werden einem User oder einem Endgerät zugeordnet, nicht (mehr) einem Server. Dadurch kann ein User (bzw. ein Endgerät: PC, Tablet usw.) auf beliebig viele Server des Unternehmens zugreifen, die die zur CAL passende Windows-Version (oder eine ältere) ausführen. Für deine 10 User brauchst du also 10 CALs, die dann auf beliebig viele Windows-Server in deinem Unternehmen mit Windows Server 2012 R2 oder älter zugreifen dürfen. Gruß, Nils

Moin, wenn man den Masterbrowser neu startet, stellt er die Liste neu zusammen. Das kann durchaus 30 Minuten dauern. Auch länger. Mag Abhilfe schaffen, aber eben nicht sofort. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Die Gruppe Sicherungs-Operatoren ist bei Backup-Herstellern erstaunlich unbekannt. Dass das allerdings auch für Microsoft selbst gilt, stimmt mich ... nachdenklich ... Gruß, Nils

Moin, Windows 10 TP ist unfertige Software. Ich finde nicht, dass man die für einen ernsthaften Einsatz empfehlen sollte. Sie ist nur für Testlabore geeignet. Abgesehen davon, löst der TO damit auch sein Lizenzproblem nicht. Erstens lässt die Lizenz (meines Wissens) keinen produktiven Einsatz zu, zweitens läuft sie nach Release des Produkts aus, drittens gilt das künftige "kostenlose" Angebot nur bei einem Upgrade, was hier ja gerade nicht vorliegt. Gruß, Nils

Moin, es sei noch kurz angemerkt, dass sich hier nur Laien äußern. Da es um juristische Fragen geht, dürfen in Deutschland nur zugelassene Rechsberater konkrete Aussagen dazu treffen. Wir sollten uns mit sowas zurückhalten (schon deshalb, weil die Lage, wie bei jeder juristischen Frage, schnell sehr komplex ist). Gruß, Nils

Moin, die Netzwerkumgebung war schon immer unzuverlässig. In den allermeisten Netzwerken braucht man sie auch nicht. Sie wird meist einfach ignoriert. "Fehler" dieser Liste sind keine wichtigen Fehler. Dein VSS-Fehler hat damit nichts zu tun, da solltest du dich separat drum kümmern. Ich empfehle darüber hinaus dringend, das AD noch separat mit Bordmitteln zu sichern (Systemstate oder Full Backup mit Windows Server Backup, im Zweifel zusätzlich zu Veeam). Nur so hast du im Fall des Falles eine herstellerunterstützte AD-Sicherung. Das Event 2887 kannst du innerhalb des LANs ignorieren. Es wäre zwar besser, nur verschlüsselte oder signierte Bindungen zuzulassen, aber innerhalb eines (kleineren) Netzwerks macht das sicherheitstechnisch "den Kohl nicht fett", weil dort meist noch ganz andere Lücken vorliegen. Sonst hast du ja einen Link dazu. Mit deinem Problem hat die Meldung aber nichts zu tun. Gruß, Nils