NilsK

Moin, die allgemeine Best-Practice-Empfehlung für SQL Server ist eine Disk-Clustergröße von 64 KB, sowohl für Daten als auch für Logs. Was das für die Stripes in deinem RAID heißt, kann ich so nicht beantworten, da geben die allgemeinen Empfehlungen auch nichts her, weil es da wohl auch Unterschiede in den Implementierungen gibt. Aus dem Bauch würde ich sagen, wenn da auch 64 KB möglich sind, dann das. Aber ganz ernsthaft: Das sind Konfigurationsdetails, die sich in einer mittelständischen Umgebung ganz sicher nicht bemerkbar machen werden. Wenn du wirklich Bedarf hättest, auch diese Schräubchen zu optimieren, dann sähe dein ganzer Planungsprozess anders aus. Gruß, Nils

Moin, dass mehrere oder alle Netze bei der Auswahl der Cluster-IP angezeigt werden, ist normal. Die Adresse gehört dann aber ausschließlich in das Management-Netz, denn du brauchst sie, um den Cluster zu verwalten. Und es ist die Adresse, über die der Cluster das AD usw. erreicht. Das Cluster-Netzwerk ist ein IP-Netzwerk. Über FC kann man es also nicht einrichten. Außerdem will man im FC auf keinen Fall Traffic haben, der kein Storage-Traffic ist (bei iSCSI-Anbindung gilt das analog für den iSCSI-Traffic). Gruß, Nils

Moin, wow, das ist interessant. Danke für das Ergebnis! Gruß, Nils

Moin, ernsthafte Vorteile gibt es nicht, wenn ein Server den DHCP-Dienst ausführt. Kann man also in der Umgebung den Router machen lassen, das reduziert Abhängigkeiten. Gruß, Nils

Moin, die Konfiguration der VMware-Adapter hat mit der Bindungsreihenfolge nichts zu tun. Und die Netzwerkkarten der VMs haben nichts mit der Konfiguration des "Hosts" zu tun. Um der Frage auf die Spur zu kommen, ob etwas anderes als die Bindungsreihenfolge zu den Timeouts führt, könnte man testweise mal die VMware-Adapter im "Host" deaktivieren. Wenn die Timeouts dann weg sind, liegt es (mit) an der Bindung. Treten sie immer noch auf, dann ist etwas anderes daran Schuld. Gruß, Nils

Moin, ich kann das Phänomen in Windows 10 (RTM-Build mit aktuellen Updates) zumindest bestätigen. Man kann die Reihenfolge zwar ändern, aber sie bleibt dann nicht so. Timeouts oder so habe ich aber trotzdem nicht, obwohl auch bei mir ein VM-Adapter oben steht (was er nicht sollte). Hier ist eih Blogartikel, der ein Kommandozeilentool beschreibt, aber der Link dorthin funktioniert nicht. http://www.chrisleblanc.org/modify-network-card-bindings-script-command-line/ EDIT: Hier ist der Link, das Tool ist umgezogen. Ich habe gerade keine Gelegenheit, es zu testen .- wer es ausprobiert, möge doch bitte die Lösung hier posten. Danke! https://gallery.technet.microsoft.com/Hyper-V-Network-VSP-Bind-cf937850 Gruß, Nils

Moin, sehr löblich. ;) In 5-Mann-Umgebungen darf man durchaus von einigem abweichen. Einen Printserver mit dem DC zu kombinieren, finde ich in solchen Netzen meist machbar. DC und File ist aber weniger günstig, weil beide im Fall eines Recovery ziemlich viel Aufwand machen können. Gruß, Nils

Moin, bin ja schon ruhig. ;) Also noch mal deutlich: Hyper-V Replica ist keine Lösung für alles. Sie ist geeignet für bestimmte Workloads (also VMs mit bestimmten Applikationen) in sorgfältig entworfenen Aufbauten. Gruß, Nils

Moin, ich stimme dir in der Aussage zu, aber rein technisch ist das nicht ganz korrekt. Hyper-V Replica ist für DCs und für SQL Server supported. Bei DCs rate ich aber entschieden davon ab, beim SQL Server hängt es stark vom Szenario ab. Bei allen Replica-Szenarien muss man aber genau planen, sonst geht das in die Hose. Gruß, Nils

Moin, das ist ja auch völlig okay. Dann war das bei dir die spezielle Situation. Genau das meinte ich ja zu Beginn dieses Threads: Es gibt durchaus zahlreiche Konfigurationen der hier diskutierten Art, die in konkreten Situationen sinnvoll sein können. Es gibt aber heute nur noch wenig, was man pauschal und immer in der Art konfigurieren "sollte". Nimmt man die verschiedenen Dinge, die hir so diskutiert werden, als Standard-Schablone, dann kann das in anders gelagerten Situationen durchaus Probleme verursachen. Das hängt eben immer von den Anforderungen ab, und die sind vorab zu klären. (Ich verweise da auch auf meine Signatur ... ;)) Gruß, Nils

Moin, das Surface 3 ist ein Intel-Gerät, das kurz vor Marktstart von Windows 10 veröffentlicht wurde. Natürlich kann das auf Windows 10 upgraden, Auf dieser Seite ist es sogar mit Windows 10 abgebildet: http://www.microsoftstore.com/store/msde/de_DE/pdp/productID.314918200 Und unten ist als Betriebssystem angegeben ... naja, du weißt schon. Gruß, Nils

Moin, ich halte es für aussichtslos, das Begehren nach Auskunft zu verfolgen. Dafür gibt es keinen Prozess, daher kannst du dir die Mühe gleich sparen. Gruß, Nils

Moin, womit wir einen Klassiker hätten: Den Serverdienst zu deaktivieren, führt zu einem System, das nicht mehr richtig aus der Ferne zu warten ist. Gruß, Nils

Moin, wer wollte die denn sehen?! Gruß, Nils

Moin, da du netterweise alle wichtigen Kommentare schon selbst gegeben hast ... ;) [Wie kann ich Active Directory von einem DC gewaltsam entfernen? | faq-o-matic.net] http://www.faq-o-matic.net/2003/01/19/wie-kann-ich-active-directory-von-einem-dc-gewaltsam-entfernen/ Wäre einen Versuch wert. Gruß, Nils

Moin, grunsätzlich kannst du einen DC als ganze VM vom Host aus sichern. Das ist allerdings aus meiner Sicht nur selten sinnvoll. Da man ein Backup immer vom Restore aus planen muss, solltest du dir die Wiederherstellungsszenarien ansehen. In einer typischen AD-Umgebung gibt es mehr als einen DC, daher ist es unwahrscheinlich, dass man einen "ganzen" DC aus einem Backup rekonstruieren muss: Wenn nur einer ausfällt, hast du ja noch weitere. In dem Fall ist es am schnellsten, den ausgefallenen DC neu zu installieren und replizieren zu lassen. Viel häufiger gibt es logische Datenverluste: Versehentlich eine OU mit -zig Benutzerkonten gelöscht. Hier ist es sinnvoll, den Datenbestand wiederherstellen zu können. Das geht meist am schnellsten mit einem Systemstate-Backup. Also solltest du so eins haben - erzeugt aus der VM mit Windows Server Backup. Meine Empfehlung also: Virtuelle DCs nicht als VM sichern, sondern aus der VM heraus mit Windows Server Backup. Andere Methoden kann man zusätzlich einsetzen, um weitere Szenarien abzudecken, aber die klassische Methode sollte die primäre sein. [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/ Gruß, Nils

Moin, naja, 180 Tage ist ja schon eine ganze Menge für lau. Zu den Büchern gibt es keine Accounts dazu. Dreamspark ist ein Programm für Studierende. Gruß, Nils

Moin, die genannten Prozesse setzen natürlich voraus, dass die Snapshots alle noch vorhanden sind. Wo genau liest du ab, dass die Snapshots auf die USB-Platte zeigen? Mit den bisher genannten Details kann man nicht mal stochern, also müsstest du bitte genauer beschreiben, was los ist. Gruß, Nils

Moin, Variablen (bzw. besser: Parameter), die du an ein Batch übergibst, kannst du im Batch selbst durch ihre Position ansprechen und weiter verwenden. Beispiel: @echo off echo Erster Parameter ist: %1 echo Zweiter Parameter ist: %2 if '%3' == '' echo Dritter Parameter ist leer Das Batch rufst du dann auf, indem du die Parameter mit Leerzeichen getrennt übergibst. Enthält ein Parameter selbst Leerzeichen, dann umgibst du ihn mit doppelten Anführungszeichen. Beispiel: MeinBatch.bat eins zwei MeinBatch.bat eins zwei drei MeinBatch.bat "eins zwei" drei Gruß, Nils

Moin, ein Cluster, der per iSCSI angebunden ist, braucht ohne Redundanz mindestens drei Netzwerkkarten: LAN - Verbindung zu dem LAN, wo auch das AD und WSUS sind Cluster - dediziertes privates Netzwerk ohne Routing, für alle Knoten dasselbe Netz mit eindeutigen IP-Adressen iSCSI - dediziertes Netz nur für iSCSI Die Cluster-IP gehört zu Netz 1 (und nur dorthin). Darüber verwaltest du den Cluster. Dass der Clustername nur in der Forward-Zone liegt dürfte normal sein, den Reverse-Eintrag kannst du dann manuell setzen. Was den Rest anbelangt, stimme ich den Vorrednern zu. Gruß, Nils

Moin, bei der Ordnerumleitung wird nichts kopiert. Die Ordner liegen auf dem Server. Punkt. Auf diesen Serverpfad greift der Windows-Client zu, auch wenn es aussieht, als handle es sich um einen lokalen Pfad. Also: Für die Userin sieht es so aus, als arbeite sie auf C:\Users\Ute\MeinOrdner, in Wirklichkeit arbeitet sie aber auf \\server99\Freigabe\Ute\MeinOrdner. Ob du mit servergespeicherten Profilen arbeitest oder nicht, ist dabei erst mal egal. Ja, das hat Folgen. Die beschreibt Helge Klein kurz und knackig hier; [Ordnerumleitung – Denial of Service in Wartestellung | faq-o-matic.net] http://www.faq-o-matic.net/2011/11/14/ordnerumleitung-denial-of-service-in-wartestellung/ Gruß, Nils

Moin, so wie er das Ziel beschreibt, wird er es aber auch mit GPP nicht hinbekommen. Der sinnvollste Weg, ein brauchbares Backup zu machen, ist ... ein Backup. Gruß, Nils

Moin, das klingt für mich seltsam. Da Snapshots aufeinander basieren, kann ich mir nicht recht vorstellen, dass die VMs noch laufen können, wenn die Dateien dazu nicht mehr verfügbar sind. Also, wie Dunkelmann schon sagt: Bitte näher beschreiben. Gruß, Nils

Moin, du liegst nicht grundsätzlich verkehrt, aber ein paar Dinge sind anders. Und ganz allgemein arbeitest du hier mit Techniken, die leider nicht besonders zuverlässig sind. Ein Basisordner ist zunächst einmal tatsächlich eine Serverfreigabe, auf der ein einzelner User seine Daten ablegen kann. Je nachdem, wo und wie man ihn einbindet, wird er dem User automatisch als Laufwerk gemappt und steht nur ihm zur Verfügung. Sofern du den Basisordner über das Feld im AD-User einträgst, erzeugt Windows ihn in dem Moment, wo du in diesem Dialogfeld auf OK klickst (sofern der Pfad erreichbar ist). Ein servergespeichertes Profil kopiert das gesamte Benutzerprofil (seit Windows Vista: C:\Users\<Benutzername>) auf einen Dateiserver. Es wird in dem Moment erzeugt, in dem ein User sich nach dem Eintragen in die AD-Usereigenschaften das erste Mal abmeldet (!). Meldet der User sich danach wieder an, lädt der Client das Profil von dem Server und kopiert es lokal nach C:\Users\<Benutzername>. Während der laufenden Session werden die Daten dann lokal genutzt. Bei der Abmeldung schreibt Windows das Profil zurück auf den Server. Da dies natürlich viel Traffic verursachen kann - und daneben einen ganzen Sack voller Probleme - hat sich Microsoft irgendwann die Ordnerumleitung einfallen lassen. Dadurch sieht der User einen lokalen Pfad, aber in Wirklichkeit speichert Windows die Daten nur auf dem Server im angegebenen Pfad - nicht als Kopie, sondern nur dort. Hier nur ein Aufriss typischer Probleme: Gibt es Zugriffsprobleme auf ein servergespeichertes Profil, nutzt Windows manchmal ein temporäres Profil - dessen Änderungen sind dann bei der nächsten Anmeldung weg. Arbeitet ein User parallel an mehreren Rechnern, gilt für jede Datei die letzte Speicherung. Inkonsistente Daten können die Folge sein. Gibt es derartige Konflikte mit der Kopie der Registry im Profil (ntuser.dat), so kann das servergespeicherte Profil kaputtgehen. Datenverlust kann die Folge sein. Profile sind nicht versionsübergreifend, daher das .V2 (es gibt auch .V3 und .V4) - siehe auch https://en.wikipedia.org/wiki/Roaming_user_profile#Compatibility Es findet keine Synchronisation der Profil-Kopien statt Die Ordnerumleitung sorgt für eine ganze Menge zusätzlicher Risiken und Probleme Allgemein rate ich von deinem Vorgehen ab. Die Vorteile, die du dir davon versprichst, wirst du so nicht erreichen. Gruß, Nils

Moin, pauschal deaktiviert man schon seit Langem keine Systemkomponenten mehr. Das wurde zu XP-Zeiten zwar noch oft empfohlen, war schon dort aber meist eher unsinnig. Wenn überhaupt, richtet sich so eine Aufgabe nach genauen Anforderungen, die im Einzelfall zu spezifizieren sind - was soll denn genau ein "rudimentäres System" sein? Aber nicht pauschal. Schon die Annahme, dass man Ressourcen "spare", ist eher ein Mythos; moderne Betriebssysteme gehen damit ganz anders um als ein altes DOS-System, das kein Multitasking beherrschte. Gruß, Nils