NilsK

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

Moin, mag ja sein, aber Veeam braucht nun mal das API. Das ist doch hier jetzt auch eine Scheindiskussion, hinter der sich am Ende persönliche Vorlieben verbergen. Wer VMware einsetzen will, muss halt die Lizenzkosten dafür einrechnen. Ob das ein relevanter Punkt ist, ergibt sich nur aus der Gesamtbetrachtung. Und bei so einer kann eben durchaus rauskommen, dass VMware das Geld wert ist. Ist doch gut. Gruß, Nils

Moin, In dem Fall eben das fehlende API fürs Backup ... Gruß, Nils

Moin, da wäre jetzt relevant, worin denn der Bedarf besteht bzw. welches Problem daraus entsteht. Aus meinem Wirkungsbereich kenne ich keine Probleme, weswegen es gar nicht "gehandhabt" wird. Gruß, Nils

Moin, dass das Volumen sich beim Umstieg von einem System auf ein anderes verändert, ist nicht überraschend. Andere Formate, andere Optimierungen usw. lassen eine Größenprognose bei solchen Migrationen nur sehr grob zu. Von dem Anwachsen beim Verschieben von Exchange 2010 nach 2016 in dem Umfang war mir jetzt nichts aktiv bekannt. Beim Umstieg von älteren Versionen lag sowas u.a. am wegfallenden Single-Instancing. Ich würde in beiden Fällen aber nicht von Fehlern ausgehen, soweit es keine anderen Indikatoren dafür gibt. Gruß, Nils

Moin, ja, da hast du natürlich Recht. Das war ursprünglich auch mein Gedanke - die VMs müssen sowieso neu, da ist die Plattform dann egal. Hatte ich nur eben aus dem Blick verloren. :D Gruß, Nils