NilsK

Moin, einen Blick solltest du auch auf die Forwarder-Konfiguration im DNS werfen. Gruß, Nils

Moin, aus der Beschreibung kann man leider nicht mal raten. Bitte füge mehr Informationen hinzu: IP-Konfiguration des Clients Genaue Fehlermeldungen in der Usersession Genaue Fehlermeldungen im Eventlog Firewallstatus weitere Konfigurationen/Software, die evtl. damit zu tun haben könnten usw. Gruß, Nils

Moin, es ist nicht ganz nachvollziehbar, was deine Situation ist und was du vorhast. Kannst du das bitte noch mal etwas ausführlicher erläutern? Dazu wäre ggf. auch der Scriptcode interessant, den du ausprobiert hast. Gruß, Nils

Moin, die voreingestellten Grenzwerte sind bei GFI Max oft nicht passend. Man sollte bei einer Erstimplementierung nicht davon ausgehen, dass die Leistungswarnungen aussagekräftig sind. Wie bei jedem Monitoring muss man auch bei GFI Max erst mal für jedes einzelne System herausfinden, was "gesund" ist und was nicht. Werte, die bei einem System völlig OK sind, können bei einem anderen ein Anzeichen für Probleme sein. Das kann durchaus ein paar Tage oder sogar Wochen dauern. Allgemein sollte man es aber bei einem "einfachen" Monitoring gerade mit den Leistungsdaten nicht übertreiben. In dem Haus, wo wir GFI Max für Kundensysteme eingesetzt haben, haben wir die Leistungsdaten bei den allermeisten Systemen sehr schnell komplett aus der Überwachung genommen, weil sie bei den Systemen keine ernsthafte Relevanz hatten. Gruß, Nils

Moin, AD würde ich nie per Replica betreiben. Mir fällt kein Szenario ein, in dem das sinnvoll sein könnte. Die anderen Dienste, die du angibst, sollten sich grundsätzlich mit Hyper-V Replica vertragen. Du musst immer im Auge behalten, dass es dort Datenverluste gibt - gering, aber vorhanden. SQL Server ist mit Replica supported, wenn man einige Grenzen einhält. Sharepoint ist ja in Wirklichkeit auch SQL Server, die Web-Komponente ist im Wesentlichen zustandslos. [Hyper-V Replica Support für Active Directory, Exchange oder SQL Server? › Daniel's Tech Blog] http://www.danielstechblog.de/hyper-v-replica-support-fr-active-directory-exchange-oder-sql-server/ Im Cluster setzt Hyper-V Replica auf dem Replica Broker auf, der sich um die Clusterintegration kümmert. So kannst du von einem Cluster vom anderen replizieren. Oder auch zwischen Einzelhost und Cluster. Ganz wichtig aber: Das ganze ist nicht "schnell mal eben". Es gehört ein Konzept dazu, insbesondere für den Failover-Fall. Gruß, Nils

Moin, jaaaaa, genau, das meinte ich! Der Kunde, bei dem wir das gemacht haben, war damit zufrieden. Gruß, Nils

Moin, ja, ich kenne sowas, mir fällt aber partout der Name nicht ein ... vielleicht meldet sich Norbert ja noch, von dem hatte ich damals den Tipp, glaube ich. ;) Ich denke noch mal weiter nach. Gruß, Nils

Moin, in der beschriebenen Konfiguration könnte man einen Hybrid aus zwei Clustern und Hyper-V Replica aufbauen. Standort 1 Cluster 1 aus drei Knoten Anbindung ans SAN von Standort 1 Hyper-V Replica Broker als zusätzliche Clusterrolle Standort 2 Cluster 2 aus drei Knoten Anbindung ans SAN von Standort 2 Hyper-V Replica Broker als zusätzliche Clusterrolle Wichtig: Hyper-V Replica ist asynchron und nicht für jede Server-Applikation geeignet. Ich würde damit also nur die VMs replizieren, deren Applikationen das vertragen. Für AD würde ich auf jedem der Cluster (mindestens) einen virtuellen DC einrichten, der immer läuft. Kein Replica für die DCs. Für Exchange würde ich einen DAG-Cluster als Gastcluster empfehlen, ein Teil der VM-Nodes läuft an Standort 1, der andere an Standort 2. Kein Replica. Alternativ: Exchange nur an einem Standort, Datensicherung erfolgt an Standort 2. So könnte man nach einem Ausfall ein Dialtone Recovery an Standort 2 machen. Mit der nächsten Version von Windows Server könnte Storage Replica für eure Umgebung interessant werden. Das würde ich aber durchaus noch etwas reifen lassen, bevor ich es produktiv nutze. Gruß, Nils

Moin, man wird sowas hinbekommen, aber sinnvoll ist es i.d.R. nicht. Du wirst dann ganz schnell mit Mails bombardiert, die dir überhaupt nichts nützen. Gruß, Nils

Moin, Export-CSV, Export-HTML usw. geben Objekte als CSV oder als HTML aus. Man braucht die Daten in dem Fall also tatsächlich erst als Objekt. Da das für viele Zwecke zu aufwändig ist, gibt man die Daten oft einfach per Out-* aus: String und Komma/Semikolon. Gruß, Nils

Moin, :) Gruß, Nils

Moin, wäre mir nicht bekannt, dass es sowas gibt. Und als Antwort für die Auditoren: Das hat mit Sicherheit herzlich wenig zu tun. Die Execution Policy ist viel sinnvoller, und dazu gibt es in CMD kein Pendant. Gruß, Nils

Moin, VMQ abschalten, egal welcher Hersteller. Bei Intel haben wir solche Probleme auch schon gesehen. Wenn das Problem dann bestehen bleibt, weitersuchen. Wenn es dann was anderes war, kannst du VMQ versuchsweise wieder einschalten. Wobei es längst nicht in allen Umgebungen viel bringt. Ist sonst noch was Spezielles auf den Netzwerkkarten eingestellt? Treiber sind aktuell? Gruß, Nils

Moin, die VSV-Dateien enthalten den "Saved State". Sie haben mit den Snapshots nicht direkt zu tun, sondern werden erzeugt, wenn du eine VM mit dem Befehl "Speichern" anhältst. Den Saved State solltest du per Rechtsklick auf die VM entfernen können. Gruß, Nils

Moin, im Kern stehst du hier vor dem Problem, dass "Ausblenden" kein Sicherheitsfeature ist. Es bezieht sich immer nur auf bestimmte Komponenten des Systems. Kann eine andere Komponente zugreifen, dann geht das eben. Dein eigentliches Problem wirst du also nur über Sicherheitsmechanismen in den Griff kriegen, hier also wohl über Berechtigungen. Willst du verhindern, dass ein User an bestimmte Stellen im Dateisystem kommt, dann musst du die Berechtigungen passend setzen. Sonst bleibt es immer Stückwerk. Was würdest du etwa tun, wenn der User ein anderes Stück Software ausführt, das sich auch nicht um das Ausblenden schert? Gruß, Nils

Moin, Ideen sind dir hier schon mehrere genannt worden. Wenn du mit derart grundlegenden Begriffen nichts anfangen kannst, dann ist das erst mal kein Problem. Du solltest dann aber vielleicht nicht unbedingt dir Konfiguration produktiver Systeme bearbeiten. Bitte stimme dich mit deinen Kollegen dazu ab. Ob ein Cluster in Betríeb ist, wird dort bestimmt jemand wissen. Falls das wider Erwarten doch nicht so ist, wäre es eine sehr gute Idee, einen kompetenten Dienstleister einzuschalten. Gruß, Nils

Moin, klar: cscript C:\Pfad\Dateiname.vbs Du kannst dir auch per Batch etwas basteln, aber da musst du ziemlich mit FOR herumspielen, wenn du den Benutzernamen isolieren willst. Außerdem ist es sprachabhängig. Die Information im Rohformat findest du so: net user %username% /domain | find /i "Full Name" Übrigens: Was du da vorhast, könnte in Richtung Überwachung gehen. Das ist in Deutschland juristisch heikel, das solltest du nicht einfach so machen, ohne dich rechtlich beraten zu lassen. Gruß, Nils

Moin, das dürfte sich nicht oder nicht ohne Weiteres machen lassen. Was ist denn die dahinter stehende Anforderung? Gruß, Nils

Moin, rein mit Batch wird das etwas schwierig. Eine VBS-Lösung wäre diese: [Ein AD-Attribut zu einem Logon-Namen herausfinden | faq-o-matic.net] http://www.faq-o-matic.net/2004/07/28/ein-ad-attribut-zu-einem-logon-namen-herausfinden/ Gruß, Nils

Moin, sowas haben wir hier schon ein paarmal diskutiert. Sowas ist immer sehr stark abhängig von den konkreten Anforderungen. Zwischen "Freigegebener Dateiordner mit Dokumenten" über "Sharepoint" oder "Blogs wie WordPress" ist i.d.R. alles an Vorschlägen dabei und kann sinnvoll sein. Gruß, Nils

Moin, wenn es sich bei dem System um einen Cluster handelt und die VMs als Clusterobjekte eingerichtet sind, ignoriert Hyper-V die "Automatische Startaktion". Dann kümmert sich der Cluster darum. Gruß, Nils

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