NilsK

Moin, und nur zur Ergänzung: Das ist keine Migration, sondern eine Aktualisierung. Gruß, Nils

Moin, sorry, aber meine Kollegen kann ich hier nicht einbinden. Dazu bräuchte ich einen kaufmännischen Auftrag. Gruß, Nils

Moin, da Invoke-Command per PSRemoting ein Kommando auf dem entfernten Server ausführt, muss die Funktion dort erreichbar sein. Du musst sie also auf dem entfernten Server oder auf einem Dateiserver ablegen und dann mit ihrem Pfad aufrufen, damit sie verfügbar wird. Gruß, Nils

Moin, naja, dass die neuen Funktionen fehlen, ist ja logisch. Woher sollen die alten RSAT die auch kennen? Ich hätte jetzt sogar vermutet, dass man damit gar nicht rankommt. In der Vergangenheit war es auch meist so, dass nur genau eine OS-/RSAT-Kombination wirklich funktionierte. Gruß, Nils

Moin, ja, das kann sein. Ich habe es jetzt nicht überprüft, würde aber davon ausgehen. Es hat sich am API einiges geändert, das die RSAT für Windows 8.1 sicher nicht können. Manche Dinge sollten per PowerShell gehen, aber auch da wäre ich vorsichtig, weil sich da auch einiges getan hat. Gruß, Nils

Moin, ich denke, die Boardregeln sind da eindeutig. Dieser Thread sollte geschlossen werden. Gruß, Nils

Moin, vor allem ist wichtig, dass die Clients zwei DNS-Server haben ... ... und falls der erste DC zufällig auch noch der einzige DHCP-Server ist und es eine kurze Lease-Dauer gibt, dann führt das auch zu dem beschriebenen Problem. Hatte ich vor ein paar Wochen gerade bei einem Kunden. Gruß, Nils

Moin, welches OS? Gruß, Nils

Moin, bei der Namensauflösung ist das normal, dort greift Round Robin. Der DC-Locator-Prozess, der die tatsächliche Anmeldung steuert, führt danach noch weitere Schritte durch, um den (laut AD-Konfig) "tatsächlich" günstigsten DC herauszufinden. Das muss dann nicht der sein, den DNS als ersten zurückgegeben hat - den fragt der Client nur nach den SRV-Records, was kein nennenswerter Traffic ist. Du kannst im DNS noch das Subnet-Mask-Ordering einschalten, wobei das aber, wenn ich nicht irre, nur auf das letzte Oktett der IP-Adresse schaut. Details kann man irgendwo nachlesen, hab ich grad nicht zur Hand. Gruß, Nils

Moin, sofern du vorher keinen anderen User eingerichtet hattest: Schlechte Karten. Da wir das Einbrechen in Systeme hier nicht supporten, werden wir dir dann nicht helfen können. Gruß, Nils

Moin, ja, wie jetzt? Soll dein eigenes Setup interaktiv laufen, oder soll das einmal vorgegeben sein? Ein Repackaging einer Software ist nicht immer möglich, und wenn, dann kann es sehr aufwändig sein. Auch MSI-Generatoren können da nicht zaubern, zumal die meisten gar nicht auf das Repackaging orientiert sind, sondern sich eigentlich an den Entwickler der Software wenden, der eine Installationsroutine bauen will. Hast du denn schon mal geprüft, ob deine Software auch Silent-Schalter zur Automatisierung hat? Gruß, Nils

Moin, behalte dabei im Blick, dass die "erste" Migration in deinem Szenario erst vollständig abgeschlossen sein muss, bevor die "zweite" beginnt. Da Quell- und Zieldomäne gleiche NetBIOS-Namen haben, kann die Transfer-Domäne nicht zu beiden gleichzeitig einen Trust haben. Das bedeutet, dass mit hoher Wahrscheinlichkeit auch die Transferdomäne zeitweise produktiv genutzt werden muss. Das wiederum bedeutet, dass nicht nur User dorthin migriert werden müssen, sondern auch Ressourcen. Nicht ohne. Wenn ihr aber FIM zur Steuerung nutzt, lässt sich evtl. ein Verfahren entwickeln, das ohne eine Domänen-Migration auskommt. Das erfordert natürlich einiges an Analyse und Design. Gruß, Nils

Moin, und wie weit ist diese neue Domäne? Vielleicht wäre es sinnvoller, die einzureißen und mit einem eindeutigen NetBIOS-Namen neu zu installieren. Selbst wenn das zwei Tage oder so dauern würde, wäre das vermutlich erheblich weniger Aufwand als eine doppelte Migration. Gruß, Nils

Moin, du kannst mit ADMT auch zweimal migrieren, dann haben die User hinterher zwei SID-History-Einträge. Ob das sinnvoll ist, steht auf einem anderen Blatt. Was ist denn der Grund für die Migration? Nur das Suffix .local? Dann würde ich das, ehrlich gesagt, bleiben lassen. Der Aufwand einer Migration ist groß bis sehr groß, das steht in keinen sinnvollen Verhältnis. Gruß, Nils

Moin, die Fragen sind alle völlig berechtigt. Ich teile die Ansicht. Angesichts der Ausgangsfrage ("kostenlos") und der sonstigen Aussagen des TO wage ich aber zu bezweifeln, dass er versteht, was wir meinen. Wenn man für das Backup seiner Produktionssysteme kein Geld ausgeben will, dann kann die Produktion ja nicht wichtig sein. Ansonsten: Bevor ich irgendwas Externes "Kostenloses" nehme, würde ich mit Windows Server Backup arbeiten. Insgesamt sehe ich das aber eher als Übergangslösung an, bis etwas beschafft ist, mit dem man ein ernsthaftes Recovery-Konzept umsetzen kann. Gruß, Nils

Moin, könntest du auch, ist aber viel mehr Aufwand. Gruß, Nils

Moin, guck mal in dem verlinkten Artikel recht weit am Anfang ... Gruß, Nils

Moin, $em aktualisiert sich nicht, weil es nur den Rückgabewert des Cmdlets New-MailboxExportRequest enthält. Das Cmdlet erzeugt einen neuen Request, mehr nicht. Also gibt es auch nur einen Rückgabewert. Dass du den Status periodisch abfragen musst, liegt in der Natur der Sache. Stell dir eine große Umgebung vor, in der du zahlreiche Requests hast. Wenn Exchange von sich aus überall, wo jemand lauscht, den Status aktualisieren müsste, hätte es ganz schön zu tun. Gruß, Nils

Moin, nutzt der Client, von dem aus du pingst, denselben DNS-Server? Hat er dasselbe DNS-Suchsuffix? Hast du den DNS-Clientcache gelöscht (ipconfig /flushdns)? VMware emphiehlt, auch einen Reverse Pointer im DNS einzutragen. Hast du das getan? Nutzt der vCenter denselben DNS-Server? Nutzt der ESXi denselben DNS-Server? Wenn du den Host per IP-Adresse ins vCenter aufnimmst, geht es dann? Falls nicht, ist DNS nicht das Problem. Hast du die anderen Vorschläge aus dem VMware-KB-Artikel schon durch? Gruß, Nils

Moin, das "Neu laden" bedeutet nichts weiter, als dass der DNS-Server seine Datenbank neu lädt. Das ist manchmal nötig, wenn es Replikationsverzögerungen gibt oder so. Nachteilig wird sich das nicht auswirken. Es wird allerdings an deinem Problem auch nichts ändern. Was ist denn genau der Stand? Du hast einen Host-Eintrag (A) für deinen ESXi gemacht, in dem der Name der IP-Adresse zugeordnet wird? Wenn du dann von einem Client aus diesen Namen anpingst, passiert was? Nutzt dein vCenter-Server den betreffenden DNS-Server? Geh mal dies hier durch, dann sehen wir weiter: [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] http://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Gruß, Nils

Moin, die Aussagen sind richtig. Ein Host ist ein Host und nur ein Host. Niemals etwas dazu laufen lassen, schon gar keinen DC. Wenn der Host nur als Host läuft, darf man mit einer Standard-Lizenz zwei Windows-Server-VMs darauf betreiben. Wenn der Host nicht nur Host wäre, sondern noch für etwas anderes genutzt würde, dann dürfte man nur noch eine VM darauf betreiben. Das ist aber uninteressant, weil man das nicht tut. Dukels Hinweis beschreibt gut, wie du das machen solltest. Aufwand etwa eine halbe Stunde. [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Gruß, Nils

Moin, ich muss mich auch korrigieren. Offenbar kann man einen vSphere-/ESXi-Server tatsächlich ins AD aufnehmen. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2075361 Gruß, Nils

Moin, wie soll er denn? Manuell eintragen. Von selbst tragen sich (fast) nur Windows-Clients ein, die der Domäne angehören. Alle anderen Einträge nimmt man manuell vor. Veraltete Einträge manuell zu löschen, ist auch völlig normal. DNS aktualisiert sich nicht von selbst - abgesehen von neuen Einträgen für Windows-Domänenclients. Die automatische Bereinigung, die Sunny61 vorschlägt, ist prinzipiell eine gute Sache, hat aber ihre Ecken und Kanten. So wirkt sie nur bei dynamischen Einträgen, nicht aber bei statischen. Außerdem kann sie durchaus zu Problemen führen, weil sich Server manchmal dynamisch eintragen, ihre Daten danach aber nicht wieder aktualisieren. Wenn dann die Bereinigung zuschlägt, ist der Eintrag des Servers weg. Das habe ich auch schon bei Domänencontroller-Einträgen gesehen, obwohl es da nicht vorkommen sollte. Bei automatischen Bereinigungen also immer genau beobachten, was passiert! (Und: Nur auf einem DNS-Server pro Domäne aktivieren, nicht auf mehreren.) Gruß, Nils

Moin, mit einer Web-Recherche wirst du sicher Software finden, die dir diese Funktion ermöglicht. Eine denkbare Alternative wären USB-Device-Server, mit denen du einen einfachen USB-Scanner über das Netzwerk von verschiedenen Clients erreichbar machen kannst. Dabei läuft auf dem Client eine spezielle Software, die über das LAN eine USB-Verbindung herstellt. Produkte von Silex oder SEH werden da oft genommen. Gruß, Nils

Moin, huiuiui - nehmt es mir nicht übel, aber jetzt bekommt es doch einen esoterischen Touch. Der TO ist offenbar mit Architektur und Einrichtung der Storage-Anbindung sowie des Netzwerkdesigns stark überfordert. Jetzt noch mit Befindlichkeiten in Bezug auf Verschlüsselung zu kommen, wenn in dem Thread offenbar geworden ist, dass die bisherigen Entscheidungen überhaupt nicht auf geschäftlichen Anforderungen beruhen, ist dann doch etwas weit hergeholt. Ebenso weit hergeholt ist es, eine grundsätzliche Überlegenheit von SMB 3.x gegenüber iSCSI oder FC in Bezug auf Sicherheit konstruieren zu wollen. Gruß, Nils