NilsK

Moin, aus meiner Sicht ist es ziemlich eindeutig, dass dein Vorhaben lizenzrechtlich nicht gedeckt ist. Für Testzwecke der Art, wie du sie beschreibst, sind die Testversionen da. Da du nicht der Lizenzgeber bist, kannst du auch nicht eine Nicht-Testversion nachträglich zu einer solchen umfunktionieren. Das Entfernen der Lizenz macht aus Windows ein unlizenziertes Windows, keine Testversion. Es ist auch ein Irrtum, dass ein "normales" Windows vor der Aktivierung als Testversion laufe - es ist dann eine nicht aktivierte, aber lizenzpflichtige Installation. Leider sehe ich immer wieder, dass Kunden (und auch Dienstleister) die Karenzzeit vor der Aktivierung als eine Art Shareware-Phase missdeuten. Windows ist aber nun mal keine Shareware. Die Testversionen laufen fast alle für 180 Tage. Das sollte zum Testen nun wirklich ausreichen. Gruß, Nils

Moin, wie Norbert schon richtig sagt, reichen deine Lizenzen im vorhandenen Konstrukt auch nicht: Wenn der physische Host noch was anderes als Hyper-V macht, "belegt" er eine der beiden Lizenzen. In einer 10-User-Umgebung ist es durchaus machbar, dass einer der Anwendungsserver auch Domänencontroller ist. Ist zwar kein richtig schönes Design, aber in solchen Umgebungen muss man immer Abstriche machen. Wichtig ist dann, dass es für das AD eine passende Recovery-Möglichkeit gibt. Dann kommst du vielleicht mit zwei VMs hin. Gruß, Nils

Moin, du kannst die beiden VMs exportieren und nach der Neuinstallation wieder importieren. Was du aber ändern solltest, ist die Konfiguration des Host-Betriebssystems. Neben Hyper-V sollten dort auf keinen Fall weitere Dienste laufen (AD, DNS, IIS oder was auch immer). Die gehören in eine VM. Beachte auch, dass deine zweite VM evtl. unlizenziert läuft: Ein Client-OS darfst du nicht einfach so als VM laufen lassen, dazu braucht es spezielle Lizenzen. [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, naja, dann habt ihr ja jetzt auch ein ganz anderes Sicherheitskonzept. Aus Windows-Sicht war euer bisheriges Vorgehen nicht sicher, denn offenbar konnte derselbe lokale User zu ganz unterschiedlichen Identitäten gehören. Das sind typische Umstellungsschmerzen, wie sie immer auftreten, wenn man von den Novell-Konzepten des letzten Jahrtausends umsteigt. Manche wollen auch ihre alte, durchgelegene Matratze zurück, wenn sie ein neues Bett bekommen. :D Oder weniger flapsig: So riesig lang können die Zeiten ja nun auch nicht sein, die das Anlegen des neuen Profils dauert. In einer üblichen Umgebung passiert das ja auch nur einmalig pro Rechner. Bei euch fällt es nur durch das Zurücksetzen auf. Möglicherweise könntet ihr vor dem Erstellen des Images einmal alle User, die in Betracht kommen, dort anmelden, damit das Profil schon erzeugt ist. Bei kleinen Zahlen wäre das u.U. praktikabel, bei größeren natürlich nicht. Gruß, Nils

Moin, wobei ich gerade den Unterschied zur vorherigen Mimik nicht sehe. Wenn man sich auf einem zurückgesetzten Windows 7 über Novell anmeldet - was ja am Ende eine lokale Anmeldung mit einem neuen User ist -, dann kann das doch nicht schneller gehen? Gruß, Nils

Moin, ich ergänze: Die Builtin-Gruppen sind ein Sonderfall. Sie sind vom Typ her domänenlokal, aber anders als andere DL-Gruppen stehen sie nur auf den DCs zur Verfügung. Dort aber ohne Unterschied: Wer Mitglied in Builtin\Administratoren ist, hat Admirechte auf allen DCs (und nur auf diesen, jedenfalls bezogen auf diese Gruppenmitgliedschaft). Gruß, Nils

Moin, äh - wieso Hyper-V-Manager? Ich denke, du arbeitest mit VMware Workstation? Ich komm hier grad nicht mit. Und wenn es denn Hyper-V sein soll: Nein, du musst den Inhalt der Platte nicht vorher kopieren. Wenn es eine VHDX ist, dann bindest du die einfach als zweite Platte an. Gruß, Nils PS. Wieso markierst du "Lösung", wenn du noch gar nicht fertig bist? Und wieso markierst du deine eigene Antwort und nicht den Beitrag, der die eigentliche Lösung enthielt?

Moin, wenn es nicht gerade um DynDNS (und damit um wechselnde IP-Adressen) ginge, dann ließe sich das lösen, indem du deine "externen" Ressourcen in die interne DNS-Zone einträgst und dort die externe IP-Adresse hinterlegst. Geht hier aber nicht. Als praktikable Ansätze sehe ich nur, entweder die DynDNS-Domain oder aber die AD-Domäne umzubenennen. Im Fall der AD-Domäne wird das darauf hinauslaufen, sie neu zu machen. Möglicherweise gibt es noch andere Ideen, aber ich bezweifle, dass die praktikabel sind. Ich gehe mal davon aus, dass das nur ein Heim- oder Testnetz ist - aber mal ehrlich: WIe kommt man auf die Idee, das AD nach einer DynDNS-Domain zu benennen?! Gruß, Nils

Moin, du kannst ein Windows-Backup problemlos in eine VM wiederherstellen. Mache ich oft, um in Laborumgebungen von einem Hypervisor zu einem anderen zu migrieren. Erzeuge aus dem laufenden System ein Vollbackup, am besten auf eine externe Platte. Bau dir dann eine "leere" VM mit ausreichend Plattenplatz, RAM und CPU. Binde die externe Platte als zweite Disk dort an. Boote die VM von dem Win-10-Medium, wähle aber nicht "Installieren", sondern "Reparaturoptionen" (oder wie das heißt) und dann dort das Backup, das Windows vermutlich sogar schon selbst anbietet. Gruß, Nils

Moin, das ist zunächst mal erklärungsbedürftig. Warum darf auf den Servern kein AD-User verwendet werden? Das würde einiges leichter und sicherer machen. Warum müssen die Server gegenseitig auf ihre administrativen Shares zugreifen? Warum richtet man nicht einen normalen Share ein, dessen Zugriffsrechte man auch verwalten kann? Wer oder was genau muss da auf die Gegenseite zugreifen? Ein Dienst? Ein User? Das Konstrukt, das du beschreibst, ist nicht sinnvoll. Gruß, Nils

Moin, ich spreche da auch gern vom "Texas Chainsaw Massacre". https://youtu.be/mLyTvCSEszw?t=16m30s ab ca. 16:50 Gruß, Nils

Moin, meine Erfahrungen aus der IT-Dienstleisterbranche: Als Frau würde ich mir das nicht antun wollen. Bei IT-Dienstleistern - zumindest im Mittelstand - gibt es bei den "ausführenden" Jobs so gut wie nur Männer. Kolleginnen im Tech-Bereich hatte ich in den vergangenen 20 Jahren vielleicht fünf. Kollegen hatte ich über 200. Bei IT-Dienstleistern machen Frauen de facto fast nur die Verwaltungstätigkeiten, mit 25 Prozent sind sie im Vertrieb vertreten, da aber fast nur Innendienst. Und das liegt keineswegs daran, dass Frauen "sich schlecht darstellen". In der letzten Firma musste ich miterleben, wie sich die Vertriebsmänner mit harten Bandagen dagegen wehrten, dass eine Frau für den Außendienst eingestellt wurde. Dass Frauen, wenn sie es sich denn antun und es schaffen, Sprüche und Vorbehalte der Art zu hören kriegen, wie sie hier im Thread genannt wurden, ist nach meiner Wahrnehmung keine Ausnahme, sondern der Regelfall. Diese Seite der IT finde ich abscheulich. Gruß, Nils

Moin, nun, in deinem Fall sieht es mir so aus, als gäbe es kein Excel auf der Maschine - oder als wäre Excel nicht richtig installiert. Gruß, Nils

Moin, wenn du jetzt noch das Problem beschreibst, das du lösen möchtest, können wir evtl. auch helfen. Gruß, Nils

Moin, habe ich oben schon geschrieben. Da die Rahmendaten nicht OK sind, kann die Lösung auch nicht OK sein. Technisch kann es aus DNS-Sicht funktionieren, wobei die Secondary Zone dem Client exakt gar nichts nutzt, wenn der einzige DC ausgefallen ist. Gruß, Nils

Moin, erstaunlich. Ist ja nicht so, dass das Geheimwissen wäre. Bauen die auch die Reserveräder aus ihren Autos aus? Gruß, Nils

Moin, die Ansprache der Tabelle ist falsch. So funktioniert's bei mir mit einer xlsx-Datei und auch mit einer csv-Datei: $user_Name = $wb.ActiveSheet.Cells.Item($Zeile,$Spalte).Text Gruß, Nils PS. Dukels Hinweis ist richtig - bitte künftig die Fehler konkret mit angeben. Das ist bei der PowerShell ja sehr einfach.

Moin, hm - ich glaube, ihr braucht dringend mal eine Design-Beratung. Ernsthaft. Also, normalerweise würde man mindestens zwei DCs pro Domäne haben, die auch beide/alle DNS machen. Dann bekommt jeder Client der Domäne beide DNS-Server eingetragen. Die DNS-Server kümmern sich um das Forwarding und halten ggf. Stub Zones. Secondaries richtet man für AD-Zonen normalerweise gar nicht ein. Die haben eigentlich nur Nachteile. Gruß, Nils PS. Es gibt seit Windows 2000 keinen PDC mehr.

Moin, gibt es denn in den Domänen nur jeweils einen DC/DNS? Das wäre ein schwerer Designfehler, sofern es dort mehr als, sagen wir, fünf Benutzer gibt. Gruß, Nils

Moin, nein, ich meinte auch nur, dass ich die Einrichtung von Stub Zones "einen Ticken" einfacher finde. ;) Gruß, Nils

Moin, es sollte ja ohnehin in allen Domänen mehr als einen DNS-Server geben. In den bedingten Weiterleitungen kannst du also auch mehr als ein Ziel angeben. Möglicherweise sind Stub Zones dann aber einfacher in der Wartung, denn die übernehmen gleich die autorisierten Nameserver der "fremden" Zone. Auch die Replikation ist dafür etwas einfacher einzurichten. Gruß, Nils

Moin, nein. Die Einträge unter "Anmelden an" sind eine Positivliste: Wenn da was steht, darf der User sich nur an diesen Rechnern anmelden. Steht nichts dort, dann gibt es keine Einschränkung. Sinnvoller ist es, dies über Gruppenrichtlinien zu regeln. Gruß, Nils

Moin, deine Ideen bezüglich der "Domänen-Benutzer" hauen nicht hin. Die Gruppe lässt du in Ruhe und setzt sie für Berechtigungen nicht ein bzw. ersetzt sie, sofern sie in Berechtigungen schon eingesetzt wurden. "Domänen-Benutzer" ist eine Systemgruppe, die alle Benutzerkonten der Domäne enthält. Da sowas erforderlich ist, solltest du daran nicht rummachen. Gruß, Nils

Moin, sobald die User eine Mailbox haben, müssen sie auch echte AD-Benutzer sein. Das heißt aber noch lange nicht, dass sie dadurch auch innerhalb der Domäne Zugriffsrechte brauchen. Du wirst nur vermutlich noch einiges dazu einschränken müssen. Solange die User nur per OWA und EAS zugreifen, ist die Wahrscheinlichkeit gering, dass sie überhaupt auf interne Ressourcen kommen. Wenn aber eben mal jemand ins Unternehmen kommt, kann er sich grundsäzlich anmelden und hat die Zugriffsrechte, die seine Gruppenmitgliedschaften erlauben. Denkbar wären z.B. folgende Maßnahmen: per GPO die lokale Anmeldung an allen Rechnern verweigern die Konten nicht in Gruppen aufnehmen, die unerwünschte Zugriffe zulassen Berechtigungen nicht für die Gruppe "Domänen-Benutzer" erteilen die betreffenden Konten in eine Deny-Gruppe aufnehmen, der der Zugriff auf kritische Ressourcen ausdrücklich verweigert wird Das alles sind aber nur beschränkende Maßnahmen. Der grundsätzliche Einwand, dass Personen, denen man nicht (ausreichend) vertraut, kein Konto im AD haben sollten, bleibt bestehen. Gruß, Nils

Moin, das hat mit bestimmten Verwaltungsprogrammen rein gar nichts zu tun. Der Bluescreen tritt in dem Moment auf, wo eine VM eine Funktion anspricht, die auf der CPU nicht vorhanden ist. Für "normale" Dienste spricht nichts dagehen, pauschal das Kompatibilitäts-Häkchen zu setzen. Es gibt m.W. auf Servern nur wenige Fälle, in denen erweiterte CPU-Features einen Unterschied machen, z.B. verschlüsselungsintensive Applikationen, die bestimmte Algorithmen verwenden. Gruß, Nils