NilsK

Moin, das ist sogar üblich. Viele VDI-Umgebungen laufen aufgrund der Lizenzbedingungen in Wirklichkeit mit einem Server-OS. Da es hier noch nicht mal um die Desktop-Nutzung geht, würde ich mir den Umstand mit der Client-Lizenzierung (und den möglichen Implikationen, dass das vielleicht nicht mal ein zulässiges Szenario ist) gar nicht erst antun. Gruß, Nils

Moin, ja, mit den GPO-Berechtigungen hast du Recht, das geht nur lokal. Da hatte ich Tomaten auf den Augen. Gruß, Nils

Moin, warum schaltest du die DNS-Suffix-Suchliste ab? Dein eigentliches Problem habe ich noch nicht verstanden. Kannst du das bitte noch mal genauer erklären? Gruß, Nils

Moin, ob du das per Berechtigungsvererbung in einem Schritt hinbekommst, weiß ich nicht und habe auch keine Zeit, das auszuprobieren. Aber zwei Anregungen: man kann per GPO auch Berechtigungen setzen man könnte den Prozess nicht über GPP, sondern über ein Skript laufen lassen, das dann z.B. mit SetACL die Rechte so setzt, wie es erforderlich ist Gruß, Nils

Moin, wenn die VMs quasi wie Server verwendet werden, ist es evtl. günstiger, sie gleich als Server-VMs zu installieren und auf dem Host eine Datacenter Edition einzusetzen. Gruß, Nils

Moin, als Workaround könntest du statt eines Links ein Batch bauen, das das gewünschte Programm startet. Ich meine, dass das mit runas geht. Gruß, Nils

Moin, was willst du denn am Ende erreichen? Vielleicht gibt es andere Wege, das zu tun. Gruß, Nils

Moin, das Microsoft-Tool gibt es nicht mehr. Eine ebenfalls kostenlose Alternative kommt von Starwind. Die muss nicht zweimal kopieren. Dafür legt sie aber auch die VM nicht selbst an. Gruß, Nils

Moin, mit runas startest du .exe-Dateien, manche anderen indirekt ausführbaren Dateien gehen auch. Links anscheinend nicht. Gruß, Nils

Moin, für sowas gibt es Gruppenrichtlinien. Üblicherweise lassen sich all solche Dinge damit erledigen, ohne auf Startskripte zurückgreifen zu müssen. Fast immer geht es in deinen Beispielen um Registry-Settings. Gruß, Nils

Moin, wenn du das Batch in "Senden an" einbindest (Kopieren in den SendTo-Ordner), dann erhält es automatisch den Dateinamen als erstes Argument. Genau das ist dann der Inhalt von %1. Inhalt des Batches ist im Wesentlichen runas /user:DOMAIN\USER %1 Damit du das wie gwünscht nutzen kannst, rufst du ein beliebiges Programm manuell mit runas und demselben Useraccount auf und fügst dann einmalig den Schalter /savecred ein. Damit speichert Windows die Anmeldedaten für dieses Konto. Danach sollte das Batch dann nicht mehr nach einem Kennwort fragen. Gruß, Nils

Moin, du willst jetzt aber nicht sagen, dass du in den vergangenen sechs Wochen noch nicht weiter gekommen bist, oder? Ich denke schon, dass man nach ein, zwei Tagen Webrecherche zumindest ein paar grundlegende Quellen gefunden haben kann, aus denen sich auch für einen Laien ablesen lässt, wozu Active Directory eigentlich da ist. Relevant ist vor allem die Frage, die lefg stellt: Solche Basisfragen solltest du in jeder Seminararbeit beantwortet haben, bevor du dich überhaupt an die Arbeit machst. Es ist durchaus eine Herausforderung, sich ein Thema selbst zu suchen und es als Arbeitsgrundlage zu definieren. Aber genau das macht einen zentralen Wert eines Studiums aus, dass man dies erlernt. Gruß, Nils

Moin, ja, deshalb sind vertriebliche Termine bei solchen Kunden ja auch begehrt. :D Gruß, Nils

Moin, würde ich so nicht machen. Schau dir den 5Nine V2V Easy Converter Free Edition an. Der steuert den Vorgang und sorgt dafür, dass die VM während der Konversion heruntergefahren ist. Dadurch musst du sie in ihrer Konfig nicht ändern. Außerdem erzeugt der Converter auch gleich die passende VM in Hyper-V. Vor der Konversion solltest du allerdings die VMware Tools deinstallieren - oder, wenn du eine vollständige Fallback-Möglichkeit haben willst, nach der Konversion in der Hyper-V-VM. Dazu musst du dann allerdings den Uninstaller bei VMware herunterladen. Den Download (ISO in der passenden Version) findest du unter diesen Kurzlink: http://qccq.de/s/v911 Gruß, Nils

Moin, mir erschließt sich das gerade nicht. Wenn du den Server V2V konvertierst, dann ist er während der Zeit doch sowieso nicht erreichbar. Und die Daten selbst verschiebst du auch nicht an eine logisch andere Stelle. Also VM offline nehmen bzw. herunterfahren. Konvertieren, Ziel-VM prüfen und online nehmen. Quell-VM nicht wieder online schalten. Gruß, Nils

Moin, hm, also, wenn wirklich bestätigt ist, dass der Ablauf wie im ersten Post beschrieben ist, dann bleibe ich dabei, dass der Client der Hauptverdächtige für die Fehlfunktion ist. In dem Fall wäre es interessant, was ein MS-Call dazu ergibt. Das mit VMware und den physischen Interfaces habe ich jetzt noch nicht ganz verstanden. Kannst du das noch mal erläutern? Gruß, Nils

Moin, ja, das fiel mir beim nochmaligen Lesen auch auf. Daher müssen wir mal warten, was der TO sagt - vermutet oder wirklich beobachtet. Gruß, Nils

Moin, wenn der Ablauf, den der TO angibt, bestätigt so stattgefunden hat, scheidet der Relay Agent aus dem Kreis der Verdächtigen eher aus. Wäre also abzuwarten, ob der Vorgang so "on the wire" beobachtet wurde oder nur vermutet ist. Gruß, Nils

Moin, gegen diese Vermutung spricht, dass der TO als Schritt 6 ja ausdrücklich ein DHCP ACK angibt. Wenn das stimmt, gibt der Server ja kein NACK aus. Gruß, Nils

Moin, du kannst Testversionen zum Testen verwenden. Ob sich die jeweils verlängern lassen, hängt vom jeweiligen Produkt ab - einplanen sollte man es nicht. Für den Echtbetrieb darfst du solche Versionen natürlich nicht verwenden, auch nicht übergangsweise. Die SQL-CALs dürfen wie (fast) alle anderen Microsoft-CALs serverübergreifend verwendet werden. Ein Client, der eine CAL hat, darf also auf beliebig viele Server der passenden Version im eigenen Unternehmen zugreifen. Deren Edition (Standard, Enterprise ...) ist dabei nicht von Interesse. Gruß, Nils

Moin, wow, das ist ein interessantes Ergebnis. Das war mir in der Tat unbekannt. Ist das bei den Clients unabhängig von der Windows-Version? Für mich sieht das nach einem Fehler auf der Clientseite aus. Ich würde dazu einen Case bei Microsoft aufmachen, um das zu klären. Gruß, Nils

Moin, dann solltet ihr darüber noch mal nachdenken. Exchange mit Netapp-DP oder gar TP ist Perlen vor die Säue. Den teuren Speicherplatz kann man besser für Systeme verwenden, die das brauchen, weil sie nicht wie Exchange selbst bessere Mechanismen für "Verfügbarkeit und Geschwindigkeit" haben. Wenn Geld keine Rolle spielt, kann man das natürlich machen. Dann hätte ich gern mal einen Termin bei euch. :D Gruß, Nils

Moin, schau dir Branch Cache an. Das ist genau für dein Szenario gemacht. Wenn es doch DFS sein soll: Ja, da brauchst du AD-Standorte, aber ein RODC ist nicht nötig. Lass den weg, der erzeugt nur Umstände. Die Standortinformationen erhält der Client auch vom Remote-DC, sofern die Standorte und Subnets richtig gepflegt sind. Gruß, Nils

Moin, die XBox-Dienste stehen auf Manuell. Der Maps Broker ist zwar automatisch, beendet sich aber bei Inaktivität selbst. Der Gewinn der Maßnahmen dürfte sich nahe Null befinden. Optimierungen macht man fallbezogen, nicht pauschal. Gruß, Nils

Moin, für dein Szenario könnte Branch Cache interessanter sein - wenn denn an Standort B wirklich nur gelesen werden soll. (Mir fallen kaum Szenarien ein, in denen das Sinn ergeben könnte.) Der Sinn des RODC erschließt sich mir gerade nicht. Gruß, Nils