NilsK

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

Moin, dass er es kann, hat Azharu ja nicht gesagt - und dass BR-Leute gern mal auf Ideen kommen, habe ich auch schon erfahren dürfen. ;) Gruß, Nils

Moin, du musst hier mehrere Dinge unterscheiden. Was du offenbar versuchst, ist eine Live Migration: Verschieben einer laufenden VM von einem Host zum anderen. Ein Ex- oder Import ist etwas anderes. EIne Live Migration geht nur, wenn die Prozessorarchitektur und die wesentlichen CPU-Features identisch sind, wie Dunkelmann schon sagt. Siehe dazu auch: [Was die Prozessorkompatibilität in Hyper-V wirklich tut | faq-o-matic.net] http://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/ Gruß, Nils

Moin, kann man natürlich machen. Finde ich aber unnötig und tendenziell zu komplex - neben den vNICs gibt es in dem Fall noch die pNICs, die zu verwalten sind. Wenn man die vNICs mit Bandbreitensteuerung einrichtet, tritt der von dir beschriebene Effekt gerade nicht auf. Man weist jedem Netzwerk ein Minimum zu, unter das es von anderen Netzwerken nicht gedrückt werden kann, sofern es selber Traffic hat. Wenn dann im Netzwerk aber nichts anderes los ist, laufen die Migrationen sehr schnell. Und da man in einem normalen Netzwerk ja nur selten migriert, belegt das LM-Netzwerk im Normalbetrieb gar nichts. Wenn aber mal ein Host evakuiert werden soll, ist es schon von Vorteil, mehr als 1 oder 2 Gbit zur Verfügung zu haben. Zudem: Schon die beiden 10-GbE-Karten belasten die Host-CPUs erheblich. Wenn sie sich dann auch noch um die anderen Karten kümmern müssen, die eigentlich aber keinen Nutzen ergeben, dann ist das eher von Nachteil. Gruß, Nils

Moin, Windows 10. Gruß, Nils PS. :D