NilsK

Moin, mir ist jetzt nicht ganz klar, woher die Vermutung jetzt kommt, dass IPv6 was damit zu tun haben könnte. Das Protokoll wird ja gern als Generalverdächtiger genommen, ist aber fast nie an irgendwas "Schuld". Gruß, Nils

Moin, ja. Gruß, Nils

Moin, die cim ist schon seit einiger Zeit ausgebucht. Wer schnell ist, kann aber noch einen von drei Plätzen "gewinnen": [cim 2015: Wir verlosen noch drei Plätze! | faq-o-matic.net] http://www.faq-o-matic.net/2015/09/02/cim-2015-wir-verlosen-noch-drei-pltze/ Gruß, Nils

Moin, nein, verkehrt ist es natürlich nicht. Ich würde das Augenmerk aber eher auf Faktoren legen, die in einer solchen Umgebung tatsächlich relevant sind. Gruß, Nils

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