NilsK

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,

Es reicht ggf. schon wenn die CPU Revision unterschiedlich ist, damit es nicht mehr funktioniert. Vor allem der SCVMM ist da sehr genau.

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,

@Nils:

Warum nicht die 1GBit Ports für die LiveMigration nutzen, um diesen Traffic vom normalen zu trennen? Immerhin nutzt die Migration allen Traffic den sie über die Leitung schaufelt und im Extremfall nunmal Max. So reisse ich die laufenden VMs nicht runter.

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,

Was spricht gegen einen Win10-Client und ADAC?

Windows 10.

Gruß, Nils

PS. :D

Moin,

hey - long time no see! :)

Gruß, Nils

Moin,

mir scheint da ein grundsätzliches Missverständnis vorzuliegen.

Der Hyper-V-Host ist nur ein Host, nichts anderes. Auf dem Host läuft kein DHCP, kein DNS und sonst auch nichts. Nur Hyper-V. Vom Host aus öffnet man auch keinen Browser, um ins Internet zu gehen.

Auf dem Host richtet man VMs ein. Dort laufen dann die Dienste, die man braucht. Ins Internet geht man nur von einem Client aus.

Ein alleinstehender Host sollte (mindestens) zwei Netzwerkkarten haben. Eine konfiguriert man "ganz normal" so, dass der Host im LAN erreichbar ist und seinerseits die Domäne und WSUS usw. erreicht. Auf diese Karte bindet man keinen Hyper-V-Switch.

Die andere Karte lässt man auf der Host-Ebene unkonfiguriert. Sie bindet man dann an den Hyper-V-Switch, auf dem man das Kästchen "Gemeinsame Verwendung ... zulassen" abschaltet. An den Switch bindet man dann die virtuellen Netzwerkkarten der VMs, die ihrerseits eine "normale" IP-Konfiguration bekommen, wie es auch bei physischen Rechnern wäre.

Gruß, Nils

Moin,

für solche Zwecke brauchst du das Recovery-Kennwort des DCs.

Gruß, Nils