NilsK

Moin, mir sind solche Probleme auch nicht bekannt. Lässt sich im Taskmanager der VMs eine Auslastung erkennen? Gruß, Nils

Moin, bitte keine fremden Threads kapern, schon gar keine uralten. Das Board warnt doch extra! Inhaltlich: LIZA von Philipp Föckeler. [Liza: Berechtigungen in Active Directory analysieren | faq-o-matic.net] https://www.faq-o-matic.net/2010/04/06/liza-berechtigungen-in-active-directory-analysieren/ Gruß, Nils

Moin, fragen wir doch mal andersrum: Was ist denn der Fall, den du klären musst? Die MSDN-Lizenzen darf man für Test, Evaluation und Entwicklung einsetzen. Für nichts Produktives. Mehr muss man i.d.R. nicht wissen, und mehr gibt es eigentlich auch nie zu klären. Wenn du eine konkrete Frage hast, dann stell sie gern. Gruß, Nils

Moin, das schon, es sollte aber nicht zu Problemen führen. Ex- und Import, Failover sowie Backup/Restore sollten darüber nicht stolpern. Bei der Live Migration kann es erforderlich sein, das Häkchen für die CPU-Kompatibilität zu setzen, das war es dann aber auch. Gruß, Nils

Moin, und das heißt genau? Selbe Architektur oder nicht? Gruß, Nils

Moin, die Frage ist, was ihr mit dem Teaming erreichen wollt. Wenn nur ein Switch dahintersteht, ist es weitgehend witzlos - dass eine Netzwerkkarte ausfällt, wäre eher exotisch (zumal bei einer 4-Port-Karte, was es ja wahrscheinlich ist). Ein Switch fällt eher mal aus, oder man will ihn neu starten (Firmware-Upgrade). Eine Durchsatzverbesserung ist nur dann zu erwarten, wenn es mehrere "Streams" gibt, die parallel laufen können - es bleibt ja dabei, dass jede Karte nur 1 Gbit kann, das Teaming ändert daran nichts. Derselbe Datenstrom wird nicht auf zwei Karten aufgeteilt. Genau wie bei einer Bahnstrecke: Auf einem Gleis kann immer nur ein Zug mit seiner Maximalgeschwindigkeit fahren. Ein zweites Gleis erhöht nicht die Geschwindigkeit des einen Zugs, aber es kann ein zweiter gleichzeitig mit Maximalgeschwindigkeit fahren. Bei dem Konstrukt würde ich über Virtualisierung nachdenken und die Dienste auf zwei VMs verteilen, das geht mit der einen Lizenz. Dann ergibt auch das Teaming ein wenig Sinn, weil dann - vereinfacht gesagt - jede VM eine NIC ausnutzen kann. Bei 20 Clients ist ein einzelner DC zu wenig, mit weniger als zwei sollte man nicht arbeiten. Da kämen dann weitere VMs (und damit weitere Lizenzen) ins Spiel. Zusätzlich ist Dosos Hinweis relevant, allerdings etwas anders, als es dort steht. Um euer AD zu aktualisieren, muss der neue DC zunächst parallel zum alten laufen, um das AD übernehmen und aktualisieren zu können. Einen Zwischenschritt über eine ältere Version braucht es nicht, weil es ja kein Inplace-Upgrade ist. Gruß, Nils

Moin, sofern die CPUs (vereinfacht gesagt) denselben Hersteller haben, sollte es gehen, auch per Live Migration. Für dein Vorhaben wäre Live Migration ohnehin die bessere Variante, das geht auch ohne gemeinsames Storage, sofern beide Hosts derselben Domäne angehören. Eine neue VM zu erzeugen, führt zu "neuer" Hardware, was eine Hardwareerkennung auslöst. Die sollte allerdings trotzdem nur wenige Minuten brauchen. Wie unterscheiden sich denn die Hosts? Ist der Patchlevel auf beiden gleich? Gruß, Nils

Moin, Hyper-V konnte in VMs noch nie auf USB zugreifen und wird das auch nie können. Wenn man aus einer VM auf USB zugreifen muss, benötigt man einen der Device-Server, die du genannt hast. Gruß, Nils

Moin, Da es ein Lab ist: neu machen. Gruß, Nils

Moin, ich fürchte, so kommen wir nicht weiter. Sorry, aber aus der Ferne kann ich hier nichts für dich tun. Naja, halt über den vSwitch. Ohne vSwitch kann eine VM nicht kommunizieren. Der Switch selbst stellt eine Verbindung für alle vNICs her, die daran angebunden sind. Normalerweise sind das nur die VMs. Dazu braucht der Host (= das Management OS) aber keine vNIC, denn er kommuniziert ja normalerweise über eine eigene physische Netzwerkkarte. In deinem Szenario könnte man dafür die nicht verbundene nehmen. Mit der Kommunikation der VMs hat der Host (= das Management OS) nichts zu tun, genau wie ServerA nichts mit der Kommunikation von ServerB zu tun hat. Best-Practice-Design für einen "herkömmlich" angebundenen Host: 1 oder mehrere NICs (Teaming), über die die VMs ins LAN kommen. Hier (und nur hier) definiert man den vSwitch, Haken "Gemeinsame Verwendung" abschalten. Hierüber kommunizieren dann ausschließlich die VMs. optional: 1 oder mehrere NICs (MPIO), um das Storage anzubinden. Kein vSwitch, nur Storage-Traffic. optional: 1 oder mehrere NICs (separate Karten) für die Clusterkommunikation. Kein vSwitch. 1 NIC, mit der der Host (= das Management OS) selbst ans LAN angebunden wird. Kein vSwtich. Hierüber spricht der Host mit dem AD, mit WSUS usw. Gruß, Nils

Moin, sorry, aber aus den Angaben werde ich nicht schlau. Führ mal dieses Skript aus und poste den wesentlichen Teil des Ergebnisses hier. Vielleicht wird es dann klarer. https://gallery.technet.microsoft.com/Get-HyperVNetworkReport-e7acf854 Gruß, Nils

Moin, es ist nicht ganz einfach nachzuvollziehen, was du meinst. Ich vermute aber, dass es ein Verständnisproblem bei der Zuordnung ist. Ein vSwitch hat keine IP-Adresse (genau wie ein echer Switch auch keine hat). Vermutlich meinst du also die virtuelle Netzwerkkarte im Host, die entstanden ist, weil der Haken "Gemeinsames Verwenden ... im Management OS zulassen" (so ähnlich) aktiviert ist. Wenn der Host allerdings auf diesem vSwitch gar keine Verbindung braucht (was der Normalfall ist - er braucht keine), dann sollte man den Haken lieber abschalten. Gruß, Nils

Moin, eine vernünftige Intranetlösung hat fertige Funktionen für sowas, die nach aktuellen Sicherheitsrichtlinien aufgebaut sind. Sowas baut man als Hobbyist nicht selbst. Das ist doch genau das, was wir hier die ganze Zeit predigen. Gruß, Nils

Moin, die Frage habe ich nicht verstanden. Was ist daran "unterschiedlich" in deinem Sinne? Gruß, Nils

Moin, ja, in der Regel reicht das, sofern wir bei "alle Elemente" von den AD-Objekten sprechen (nicht etwa von Dateien oder Applikationsdaten) und "ansehen" sich auf den lesenden Zugriff bezieht, den AD-User typischerweise haben. Gruß, Nils

Moin, versuch mal: foreach ($ExportUser in $MailExportUser.AcceptMessagesOnlyFrom) Du hast es ja mit einer Eigenschaft des ursprünglichen Objektes zu tun, die ihrerseits Objekte enthält. Gruß, Nils

Moin, versuch doch mal bitte, $MailExportUser mit einer ForEach-Schleife zu durchlaufen. Ich gehe davon aus, dass das funktioniert. Deine vorherige Ausgabe deutet darauf hin, dass du eine Sammlung von Objekten zurückbekommst, auch wenn PowerShell die formal nicht als Array deklariert. Mangels Umgebung kann ich das nicht testen. Gruß, Nils

Moin, wenn du wie hier ein Array zurückbekommst, dann würde ich es mir einfach machen und mit einer ForEach-Schleife prüfen, ob mein gesuchtes Objekt darin vorkommt. Da kannst du mit Stolperstellen wie Datenformaten usw. leichter umgehen. Gruß, Nils

Moin, naja, organisatorisch mag der Wunsch klein sein, technisch hat er aber schon eine gewisse Größe. Das ist manchmal so. Treckerreifen an einem Golf mögen einem auch wie ein kleiner Wunsch vorkommen. Aber ganz ehrlich: Es gibt fertige Lösungen für das, was du vorhast. Wenn Skripte reichen, bin ich sicher, dass du auch kostenlose findest. Dann bleibt "nur noch" der Aufwand zum Testen. Gruß, Nils

Moin, enthält $MailExportUser denn überhaupt die Daten, die du brauchst? Gruß, Nils

Moin, nein, so einfach ist es nicht. Mit so simplem Ex- und Imports bekommst du die Objekte nicht als mailaktivierte Objekte in die Exchange-Umgebungen eingebunden. Gruß, Nils

Moin, eine Forest-Integration bedeutet, dass eine der Dömänen komplett in die andere migriert werden muss. Aufwand = sehr hoch. Zu den anderen Ansätzen haben wir dir mittlerweile mehrfach Hinweise gegeben. Ohne Aufwand geht es nicht, wie hoch der ist, hängt von den konkreten Anforderungen ab. Eine einfache Skriptlösung wäre u.U. schnell implementiert, eignet sich aber faktisch nur, wenn es wenig Dynamik in der Userbasis gibt. Gibt es viel Fluktuation und viele Änderungen, braucht man ein intelligenteres Tool, das typischerweise mehr Aufwand bei der Einrichtung und Pflege erzeugt. Gruß, Nils

Moin, den GC gibt es nur innerhalb eines Forests. Das ist in deinem Szenario, wenn ich es richtig verstehe, ja gar nicht gegeben, weil du zwei getrennte Forests hast. Zur Umsetzung gibt es eine ganze Reihe von Varianten, such mal nach "sync Global Address Lists". Typische Ansätze: Skriptlösungen, die per Taskplaner die relevanten Objekte aus einer Domäne exportieren und sie als Mailkontakte in die andere importieren. Hier ist dann etwas Logik nötig, damit bereits vorhandene Objekte nicht neu importiert, sondern nur bei Bedarf aktualisiert werden. Sync-Tools wie Microsoft Identity Manager, für den es zumindest früher eine "kleine Version" für das GAL-Sync gab. Gruß, Nils EDIT: Ich heiße natürlich Nils, nicht Niös. :D

Moin, das kann so nicht sein. Im Schema kann man keine Löschungen vornehmen. Hier wäre also wichtig zu wissen, was ihr tatsächlich wo gemacht habt. Hier wird es interessant. Dass diese Objekte durch eine Replikation ins System kommen, kann man ausschließen. Zwei spekulative Theorien: Theorie 1: Es gab nach eurer Bereinigung doch noch Berechtigungseinträge für diese verwaisten Objekte im AD. Bei der Neuinstallation erkennt Exchange diese und wendet sie auf die neuen AD-Objekte an. Theorie 2: Exchange versucht, die zugehörigen Objekte (User und/oder Gruppen) neu zu erzeugen und die passenden Berechtigungen zu setzen. Aus irgendeinem Grund geschieht hierbei ein Fehler, und Exchange setzt die falschen Berechtigungen. Kern des Problems dürfte sein, dass ihr hier einen nicht supporteten manuellen Weg zur "Bereinigung" beschritten habt. Ich vermute, dass ihr von Microsoft hier keinen Support kriegen werdet - einen Versuch wäre es aber vielleicht wert. Alternativ würde ich jetzt sehen, ob ich einen Exchange-Spezi finde, der sich die Sache mal ansieht. Je nach Ergebnis würde ich dann, wenn eine Reparatur nicht möglich erscheint, einen Neuaufbau erwägen. Gruß, Nils

Moin, auch dem stimme ich ohne Vorbehalte zu. :D Gruß, Nils