NilsK

Moin, eine herkömmliche GP-Einstellung gibt es dafür nicht, aber per GPP solltest du das lösen können. Gruß, Nils

Moin, ich meine: Das ganze Verfahren ist "error-prone", d.h. es kann sehr leicht was schiefgehen. Wenn es keinen zwingenden Grund gibt, würde ich das in einer produktiven Umgebung immer vermeiden. Und "es ist so aufwändig, meine Applikationen neu einzurichten" würde ich zumindest nicht direkt auf der Liste zwingender Gründe sehen. Du kannst ja mal nach "rendom problem" oder ähnlich googeln. Ja, Domain Rename kann klappen. Aber es muss nicht. Gruß, Nils

Moin, ganz falsche Baustelle. Da geht es um die Verwaltung von Konten im AD, nicht um das Zuweisen von Rechten an AD-Konten auf einem lokalen Rechner. Und selbst wenn: Die Konten-Operatoren verwendet man bitte nicht. Schon seit NT nicht mehr. Die vorgeschlagenen Wege, den Account in die lokale Admin-Gruppe aufzunehmen, sind die Lösung dazu. Also hat Microsoft sehr wohl was dafür ... man muss eben nur von Anfang an sagen, was man eigentlich will. Sonst doktorn alle an den Problemen der Lösung herum, statt eine Lösung für das Problem zu finden (wie ich oft und gern sage). Gruß, Nils

Moin, fragen wir erst mal anders: Warum soll der Remote-User überhaupt per vmconnect zugreifen? Reicht eine RDP-Verbindung nicht aus? Ich habe leider gerade keine Zeit, die Schritte zu verifizieren, die ggf. noch nötig sind. Gruß, Nils

Moin, genau: 1. Anforderungen definieren ;) Deine Frage kann man nicht beantworten. Wenn deine Applikation Daten im AD verändern muss, dann wird sie das wohl müssen. Willst du das nicht, dann setz die Applikation nicht ein. Wenn du wissen willst, was sie denn konkret ändern können muss, dann frag den Hersteller, nur der wird das umfassend beantworten können. Das AD ist ein Verwaltungssystem. Natürlich muss man da auch Daten ändern. Pauschal ist daran nichts Gefährliches. Jeder Clientrechner verändert Daten im AD. Jeder Benutzer hat (begrenzte) Schreibrechte im AD. Gruß, Nils

Moin, und wozu lokale Konten? Da hat Microsoft aus gutem Grund keine Lösung. Lokale Konten haben so viele Nachteile, dass ich gar nicht die Aufzählung beginnen mag. Gruß, Nils

Moin, pauschal würde ich mal sagen: Du bist auf dem Holzweg. Wenn sowieso der Großteil der Umgebung neu gemacht werden soll, wozu dann überhaupt den riskanten (und meines Wissens nur in engem Rahmen supporteten) Weg eines Domain Rename gehen? Gruß, Nils

Moin, so kommen wir hier nicht weiter. Ich klinke mich mal aus. Gruß, Nils

Moin, nein, das geht nicht. Lokale User und Gruppen kann nur ein lokaler Administrator anlegen. Was ist die Anforderung hinter dieser Anfrage? Gruß, Nils

Moin, du musst in vmconnect.exe den Server und die VM ausdrücklich angeben. Dann sollte es gehen. Du kannst dafür auch eine Verknüpfung erzeugen, ruf mal "vmconnect /?" auf. Um eine Liste anzuzeigen, müsste das Konto weitere Berechtigungen auf dem Host haben. Das ist in dem Szenario aber gar nicht nötig. Gruß, Nils

Moin, deine Frage kann man so immer noch nicht beantworten. Höchstens so: Ja, es gibt Software, die derartiges ermöglicht. Es ist aber immer noch die ganze oben skizzierte Bandbreite möglich. Das ist ein klassicher Fall von "Anforderungen definieren". Da es hierbei ziemlich tief in die Prozesse der Organisation gehen dürfte, ist ein Forum kaum ein geeigneter Platz dafür. Gruß, Nils

Moin, und was genau ist jetzt deine Frage? Gruß, Nils

Moin, dass du mit Get-VMConnectAccess keine Antwort bekommst, liegt einfach daran, dass du noch niemandem diese Berechtigung zugewiesen hast. Es könnte allerdings auch sein, dass dir zum Abruf die Rechte fehlen; ruf das PowerShell-Fenster mal ausdrücklich als Administrator auf. Der Zugriff über VMconnect.exe bedeutet, dass man mit eben diesem Programm eine Konsolenverbindung zu der betreffenden VM herstellen kann. Im Hyper-V-Manager wird man sie meines Wissens dann nicht verwalten können. Gruß, Nils

Moin, Performancefragen kann man nicht pauschal beantworten, schon gar nicht bei einem SQL Server. Ohne Analyse des Einzelfalls ist man sonst nur auf der Ebene "viel hilft viel" oder bei Exotika. Gruß, Nils

Moin, oh, keine Bange, das sind keine dummen Fragen. :) Gruß, Nils

Moin, ja, eben. Siehe oben. Gruß, Nils

Moin, was steht denn in $choice_ou tatsächlich drin? EDIT: Ich habe mal mit dem Variablen-Monitor von ISESteroids nachgesehen. Demnach ist $choice_ou ein Objekt mit einer Eigenschaft namens "DistinguishedName". Du musst also diese Eigenschaft abfragen, dann geht es: Get-AdUser -Filter * -SearchBase $choice_ou.DistinguishedName Das ist die Tücke: PowerShell arbeitet mit Objekten, nicht mit Strings. Gruß, Nils

Moin, oh, da wüsste ich Leute ... ;) Deine Überlegungen in Ehren, aber für mich klingt es, als würdest du es dir nur unnötig schwer machen, indem du vorhandene Konzepte auf eine Umgebung zu übertragen versuchst, wo sie nicht funktionieren. Gerade in der IT und insbesondere bei Standarddiensten ist es meistens eine gute Idee, sich daran zu orientieren, wie es gedacht ist (und weniger daran, wie man es so verbiegen kann, dass es irgendwie auch gerade noch funktioniert). Natürlich wird jemand, der sich auskennt, auch mit Konstrukten klarkommen, die "etwas exotisch" sind, aber er wird dafür mehr Zeit brauchen und über das eine oder andere stolpern. Dadurch erhöhen sich dann Supportkosten. Mit Child Domains würdest du die Kosten sogar direkt erhöhen, denn für jede Domäne brauchst du minimal zwei Domänencontroller ... und hast in der Folge erheblich mehr Aufwand. Gruß, Nils

Moin, nein. Wenn IP nicht an die Karte gebunden ist, ist IP dort auch nicht aktiv und fordert auch keine Adresse an und trägt auch beim DNS keine ein. Du hast wahrscheinlich bei deinem vSwitch den Haken "Gemeinsame Verwendung mit dem Verwaltungsbetriebssystem zulassen" aktiviert. Dadurch hat Hyper-V in der Parent Partition eine virtuelle Netzwerkkarte erzeugt, die an den vSwitch gebunden ist. Und die holt sich die Adresse und trägt sie ein. Diesen vNIC brauchst du aber gar nicht, weil dein Host ja über eine eigene physische Karte mit dem LAN verbunden ist. Also schalte den Haken ab, dan verschwindet der vNIC. Danach löschst du dann den DNS-Eintrag. Und jetzt liest du meinen Netzwerk-Artikel noch mal. ;) Gruß, Nils

Moin, na, dann ist es ja wenigstens aufgeklärt. ;) Danke für die Rückmeldung! Gruß, Nils

Moin, <ot> im MausNet hatten wir eine eigene Gruppe für sowas, die nannte sich "Oberlehrer". ;) In der IT ist "Stati" durchaus üblich. Dazu hatte ich auch mal einen halboffiziellen Beleg, den finde ich aber gerade nicht wieder. Eine richtig schön schlaumeierische (wenn auch weit hergeholte) Begründung habe ich aber hier gefunden: http://schreibweise.org/status-stati (dort die "Beste Antwort") Dadurch wird "Stati" nicht "richtig korrekt", aber Sprache ist ja glücklicherweise auch nicht (Achtung, Wortspiel) statisch. </ot> Gruß, Nils

Moin, noch eine Anmerkung, dann klinke ich mich aus: Du erwähntest oben, dass du auch "AD" als VM laufen lassen willst. Wenn das ein Windows-Domänencontroller ist, brauchst du natürlich auch Windows-Lizenzen. In dem Fall also mindestens einmal Windows Server 2012 R2 Standard pro Host (damit kannst du dann in dem Konstrukt insgesamt zwei Windows-VMs betreiben und hin- und herschieben). Egal welche Hypervisor-Plattform. Die Linux-VMs benötigen natürlich keine Windows-Lizenzen. Gruß, Nils

Moin, da wiederum hast du Recht. :) Gruß, Nils

Moin, prima, danke für die Rückmeldung! :) Gruß, Nils

Moin, das ist so nicht richtig. SA ist nicht für alles notwendig, sondern nur für bestimmte Applikationen. Gruß, Nils