NilsK

Moin,
 
mit Bordmitteln (ohne "a" übrigens) geht das nicht. Es gibt kommerzielle Software für sowas, mittlerweile auch ein paar Community-Projekte*. Falls ihr eine Anbindung an Azure AD und die passenden Subscriptions habt, lassen sich auch AAD-Bordmittel einsetzen.
 
Gruß, Nils
* das ist das, was Norbert mit seiner Anspielung meinte. An solche Software hat sich lange in der Community niemand rangetraut. Welche Qualität die vorhandenen Projekte haben, kann ich aber nicht sagen.
* PS. vielleicht meint Norbert auch, dass die sog. "Komplexität" viel weniger wichtig ist als die Länge von Kennwörtern. Mindestens für Admins und andere hochprivilegierte Accounts würde ich daher vor allem lange Kennwörter vorschreiben, die Komplexität kann man sich dann eher sparen.
 

Moin,
 
Dass versucht wird, sich an einen öffentlich erreichbaren Server anzumelden, ist ja nicht verwunderlich. Es ist auch völlig egal, von oder auf welchen Ports das versucht wird. Wichtig ist, dass es nicht klappt.
 
"Ports" werden oft völlig missverstanden. Ein "offener Port" ist per se überhaupt kein Problem. Das wird es erst, wenn auf dem Port etwas ungesichert reagiert und Dinge ausführt, die nicht erwünscht sind. Das wiederum kann man ja durchaus als Betreiber im Griff haben.
 
Gruß, Nils
 

Moin,
 
ja, das war das, was ich meine. Und es ist auch gleichzeitig die Erklärung und der Fehler.
 
Eine primäre DNS-Zone wird nicht repliziert, wie Norbert ja auch sagt. Der sinnvollste Weg ist, dass du über den Button "Ändern" die Zone in eine AD-integrierte Zone umwandelst. Danach funktioniert es dann wie gewünscht.
 
Gruß, Nils
 

Mon,
 
Der Punkt ist doch einfach, dass der TO bei dieser Nebensache etwas verwechselt. Was er wahrscheinlich meint: es gab man einen Verteiler mit einer bestimmten Adresse. Diese Adresse ist dann später einer Mailbox zugewiesen worden.
 
Da das aber mit den Regeln nichts zu tun hat und wir das wissen, können wir uns ja auch wieder auf das Problem konzentrieren.
 
Gruß, Nils
 

Moin,
 
das ist "works as expected". Ein Zertifikat bestätigt, dass der Inhaber eines Public-Key-Paares derjenige ist, für den er sich ausgibt. Die Logik dahinter ist, dass nur dieser Inhaber Zugriff auf seinen Private Key hat. 
 
Der Private Key wird standardmäßig lokal in einem geschützten Bereich des Benutzerprofils gespeichert (vereinfacht gesagt). Auf einem "neuen" Rechner hat der User keine Kopie seines Private Keys (der soll ja schließlich privat sein und nicht wild durch die Gegend kopiert werden, schon gar nicht irgendwie automatisch). Also erzeugt Windows bei der Aufforderung, für den User ein Zertifikat zu erzeugen, ein neues Schlüsselpaar.
 
Ja, das wirft organisatorische Probleme auf, wenn Anwender an unterschiedlichen Rechnern arbeiten. Denn natürlich handelt es sich hierbei um unterschiedliche Zertifikate. Was der User in diesem Szenario also etwa mit seinem Private Key auf Rechner A verschlüsselt, kann er mit dem Public Key auf Rechner B nicht entschlüsseln.
 
Gruß, Nils
 

Moin,
 
wenn es tatsächlich um die Gruppe Konten-Operatoren geht und das nicht nur ein unglückliches Beispiel war - dann wäre es weit besser, die Gruppe Konten-Operatiren zu leeren und zu überwachen, dass sie immer leer ist. Diese Gruppe braucht seit Windows NT niemand mehr, dafür erzeugt sie erhebliche Risiken. Da sie durch die Vererbung aber immer wieder auftaucht, geht man das Problem besser an einer geeigneten Stelle an - nämlich indem man die Gruppe nicht verwendet und leer lässt (Letzteres kann man auch periodisch per Skript oder GPO erzwingen).
 
Gruß, Nils
 

Moin,
 
du lizenzierst keine Windows-VMs, sondern den Hardware-Host, auf dem die VMs laufen. Möchtest du auf dem Host also eine 2022-VM betreiben, dann muss der Host ausreichend Lizenzen für Windows Server 2022 haben. Da man Lizenzversionen nicht mischen kann, heißt das: Auf dem Host genügend 2022-Lizenzen, damit alle Windows-Server-VMs abgedeckt sind, egal, was dort tatsächlich ausgeführt wird.
 
Gruß, Nils
 

Moin,
 
"wie immer"? Bei mir war das noch nie der Fall. Winamp - das war in den Neunzigern, oder?
 
Die Dateiverknüpfung ist hier nicht der Punkt, sondern eine Erweiterung, die sich vermutlich in den Explorer eingeklinkt hat und anscheinend beim Öffnen eines Ordners irgendeinen Vorgang anstößt. Was das bei dir sein könnte, kann ich dir nicht sagen. Es muss auch nicht so sein, aber das beschriebene Verhalten klingt danach.
 
Gruß, Nils
 

Moin,
 
gut, dann ist mit der Anleitung oben und der RSAT-Installation das Nötige gesagt.
 
Irgendwelche Sonderfunktionen wie Weblinks, Mailadressen oder so müsstest du separat regeln.
Vorsichtshalber weise ich noch darauf hin, dass du das in einem separaten Labor genau testen solltest.
 
Gruß, Nils
 

Moin,
 
ein "Profil" ist in dem Zusammenhang in Windows ein Satz von Einstellungen, die steuern, wie der Windows-Desktop sich für den jeweiligen Benutzer verhält und wie die Benutzeroberfläche aussieht. Das wird oft missverstanden, weil außerhalb von Windows der Begriff "Profil" anders verwendet wird. Mit Berechtigungen hat ein Windows-Profil nichts zu tun.
 
Dein Gedanke ist aber so verkehrt nicht, nur benutzt man da andere Begriffe. In Windows und AD nimmt man User (also Benutzerkonten) in Gruppen auf. Diese Gruppen erhalten dann Berechtigungen auf Dateipfade oder andere Ressourcen. Jeder User, der Mitglied einer solchen Gruppe ist, hat dann alle Berechtigungen, die der Gruppe zugewiesen wurden. Dabei kann ein User gleichzeitig in (nahezu) beliebig vielen Gruppen Mitglied sein und so seinen eigenen Satz an Berechtigungen erhalten.
 
Der Frage von Norbert schließe ich mich an: Was willst du denn erreichen?
 
Gruß, Nils
 

Moin,
 
unterschätze nicht den CPU-Bedarf solcher Aktionen. Es ist ja nicht nur das Netzwerk. Die VMs sollen während der Zeit ja auch noch arbeiten. Eine Live Migration ist kein zeitkritischer Vorgang. Falls doch, ist das eher ein Hinweis, dass das Betriebskonzept an anderer Stelle nicht passt.
 
Zu der eigentlichen Frage: Sieh es doch mal logisch. Wenn du "immer" aktivierst, ist es dann noch von Belang, "bei Zustimmung" zu aktivieren - insbesondere wenn du weißt, dass diese Einstellung nur ein Protokoll betrifft, das du gar nicht einsetzt?
 
Gruß, Nils
 

Moin,
 
nein, so wird der Zusammenhang ganz sicher nicht sein.
 
Warum nicht? 
 
Die einfachste und beste Lösung wäre, die Fehler auf dem virtuellen DC zu beheben, ihm die Master-Rollen zu übertragen, dann einen zweiten DC hinzu installieren und die "Reste" des ausgefallenen DCs aus dem AD und dem DNS zu entfernen.
 
Die zweitbeste Lösung wäre, den zweiten DC auch abzuschalten und die aktuelle Datensicherung des ADs wiederherzustellen, die du ja hast.
 
Die drittbeste Lösung ist, alles neu zu machen. Auch wenn es nur zehn User sind, ist der Aufwand dafür typischerweise höher, als man zunächst denkt.
 
Gruß, Nils
 

Moin,
 
der MS Wireless Display Adapter, mit dem ich gute Erfahrungen gemacht habe, kostet um 40 Euro. Damit habe ich bislang eine höhere "Trefferquote" gehabt als bei den Schnittstellen, die die TVs selbst hatten.
 
Eine Alternative könnte evtl. dies hier sein, wenn auf dem Endgerät Android läuft:
https://www.spacedesk.net/
 
Gruß, Nils
 

Moin,
 
vorweg: GUIs sind nicht die Stärke der PowerShell, eigentlich hat PowerShell einen Automatisierungsfokus.
 
Ohne die Technik, die du da einsetzt, näher zu kennen und ohne lange analysiert zu haben, würde ich vermuten, dass du hier in eine Scope-Falle gelaufen bist. Deine Objekte $Auswahlfeld und $Auswahlfeld2 sehen mir so aus, dass sie nur im Scope des jeweiligen Blocks existieren. Der Block $Option1 kennt also nur das $Auswahlfeld2, aber nicht das $Auswahlfeld, entsprechend im anderen Block.
 
Hab's jetzt mal geprüft, das dürfte so sein. Diese Ergänzung des Codes illustriert das:
$Option1.Add_Click({ $Auswahlfeld2=New-Object System.Windows.Forms.Listbox $Auswahlfeld2.SelectionMode="One" $Auswahlfeld2.Height=150 $Auswahlfeld2.Width=150 $Auswahlfeld2.Location =New-Object System.Drawing.Point(500,50) Write-Host 'Option1' Write-Host "Auswahlfeld2: $Auswahlfeld2" Write-Host "Auswahlfeld: $Auswahlfeld" $Abfrage.Controls.Add($Auswahlfeld2) $Abfrage.Controls.Remove($Auswahlfeld) }) $Option2.Add_Click({ $Auswahlfeld=New-Object System.Windows.Forms.Listbox $Auswahlfeld.SelectionMode="One" $Auswahlfeld.Height=150 $Auswahlfeld.Width=150 $Auswahlfeld.Location =New-Object System.Drawing.Point(300,50) Write-Host 'Option2' Write-Host "Auswahlfeld2: $Auswahlfeld2" Write-Host "Auswahlfeld: $Auswahlfeld" $Abfrage.Controls.Add($Auswahlfeld) $Abfrage.Controls.Remove($Auswahlfeld2) })  
Gruß, Nils
 

Moin,
 
Pauschal must du nichts beachten, das sollte einfach so funktionieren. Die CPU-Kompatibilität braucht man, wie du vermutest, nur bei der Live-Migration, wenn die Hosts unterschiedliche CPUs haben.
 
Kopiere die VMs gleich in den Zielordner, dann musst du sie nur noch registrieren.
 
Gruß, Nils
 
 

Moin,
 
das ist keine Komponente, die im Betriebssystem sitzt, sondern eine Bibliothek, die in Applikationen eingebunden ist. Dort ist das auch normalerweise nicht als separate DLL oder so ausgeführt. Als Anwender oder Admin hast du daher kaum Chancen, festzustellen, ob eine Applikation das nutzt.
 
Tendenziell sollte das Risiko auch nur bestehen, wenn auf einem Client Java-Anwendungen laufen.
 
Gruß, Nils
 

Moin,
 
dass du dir in der Form etwas "zerhaust", ist eher unwahrscheinlich. Aber wenn du einfach so ohne weitere Kenntnisse loslegst, ist es sehr wahrscheinlich, dass deine PKI eine schlechte wird.
 
Was heißt denn das genau?
Soll das ein interner oder ein externer Webserver sein?
 
Gruß, Nils
 

Moin,
 
Wenn man regelmäßig richtige Backups macht, wächst das Log normalerweise gar nicht so groß an. Aber im Wesentlichen ist die Antwort Ja.
 
https://www.faq-o-matic.net/2014/08/27/sql-server-transaktionsprotokoll-verkleinern/
 
Gruß, Nils
 

Moin,
 
dann rate ich dir in der gegebenen Situation von Experimenten ab. Und 10 GB freier Plattenplatz führen zu Experimenten.
 
Gruß, Nils
 

Moin,
 
[AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net]
https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/
 
Keine Webseite, aber nah dran. Und das Prinzip ist übertragbar.
 
Gruß, Nils
 

Moin,
 
ui, sowas heute noch in VBS zu machen ... ich sage mal voraus, dass dir hier einige zur PowerShell raten werden.
 
Ich hab's nicht mehr genau im Kopf, aber es kann sein, dass das FileSystemObject keine Filter bei der Dateiauswahl kennt. Du müsstest das also selbst prüfen. Dazu hast du ja auch schon eine Zeile in deinem Code:
If LCase(objFSO.GetExtensionName(objFile.Name)) = "xml" Then Hier könntest du die Bedingung mit AND um deine zweite Vorgabe zum Dateinamen ergänzen, vermutlich mit
Instr(objFile.Name, "deine-Zeichenkette") > 0  
Ist ungeprüft, versuch damit mal rum.
 
Puh, VBS war schon gruselig. 
 
Gruß, Nils
 

Moin,
 
wenn es eigentlich um die Daten geht, ist das Kopieren der Dateien der einfachste Weg.
 
Für Einzelfälle hatte sich für vollständige Profile in der Vergangenheit dies hier bewährt, scheint auch für Windows 10 zu gehen:
 
[Benutzerprofile an neue Benutzer übertragen | faq-o-matic.net]
https://www.faq-o-matic.net/2010/02/07/benutzerprofile-an-neue-benutzer-bertragen/
 
Gruß, Nils
 

Moin,
 
wenn ein ping auf den Kurznamen funktionieren soll, muss der anzusprechende Host entweder im selben Subnet sein, man muss WINS nutzen, oder der Client Resolver muss wissen, welche Suffixes er versuchen soll. In sofern: Ja.
 
Gruß, Nils
 

Moin,
 
da du die VMs vor dem Tausch herunterfährst, werden sie beim nächsten Start sich auf die neue CPU einstellen. Das ist genau wie bei einer Live Migration (bzw. vMotion, wie es in dieser Welt heißt) - eine laufende VM darf nicht plötzlich eine ganz andere CPU vor sich haben. Eine neu gestartete VM kommt mit recht großen Veränderungen klar.
 
Trotzdem ist so eine Aufrüstung eher unüblich, daher solltest du einen Plan B bereitliegen haben.
 
Gruß, Nils
 

Moin,
 
sofort plattmachen und neu einrichten. Wieso fackelt man da noch lange rum?
 
Gruß, Nils