cj_berlin

Aber: Dieses Experiment zeigt schon mal, dass der Rechner nicht Mitglied im AD sein muss, um auf den besagten Lizenzserver zuzugreifen.

Das ist das Snapshotting, das ich oben - ebenfalls als vorletzte Option - bereits erwähnte.

Wenn es die überhaupt gibt, findest Du sie bestimmt heraus Google hilft da extrem, und es gibt ja insgesamt eine einstellige Zahl an Installer-Engines. Doch auch die "bösen" selbstgenagelten Installer von Leuten, die meinen, sie wüssten es besser, lassen sich automatisieren - entweder per Snapshotting (wovon ich selbst kein großer Fan bin, aber gerade bei solchen Assi-Produkten ist der Ansatz durchaus erfolgsversprechend) oder mit Klick-Skripten a la AutoIt. Wenn aber alle Stricke reißen, installierst Du einmal manuell und machst mit dem MDT ein WIM-Capture des fertige

Wenn Du irgendwelche Dinge beeinflussen willst, die CustomSettings.ini nicht hergibt. Ich schalte z.B. bei Server-Tasksequenzen den Autostart des Server Managers per Registry ab und bei Client-TS das "Wir bereiten alles für Sie vor"-Video. Per Antwortdatei kannst Du auch beispielsweise Updates und FeaturesOnDemand (.NET 3.5, RSAT, was auch immer) bereits bei der OS-Installation integrieren.

Wenn das ein halbwegs ordentlich programmiertes Produkt mit einem halbwegs ordentlichen Installer ist, ist die Software nach der Installation für alle angemeldeten Benutzer verfügbar.

Moin, welches ist denn "die Software"? Ich mache in letzten Jahren (wieder) relativ viel MDT, und "die Software", nachdem sie unter dem Administrator-Account installiert wurde, steht in der Regel allen anderen Benutzern ebenfalls zur Verfügung. Das würde man ja auch sonst so machen, bei einem Rechner, der bereits im Betrieb ist: Wird neue Software benötigt, wird sie mit administrativen Rechten für alle installiert...

Da sehe ich schon die Schlagzeile: "DSBs steigen deutschlandweit auf Linux um, um den Druck auf Microsoft zu erhöhen"

Moin, Windows speichert da gar nichts. Jeder Browser pflegt die Autocomplete-Daten für sich. "Einfaches Adressbuch zur Nutzung im Netzwerk" ist sehr schwammig. Was soll denn mit den Adressen geschehen?

Moin, was steht denn (beispielhaft) in $Name und $Path ?

"VM escape" ist eine extrem rare Geschichte und meist nur unter Laborbedingungen reproduzierbar. Nimmt man diesen Angriffsvektor aber als konkrete Gefährdung an, folgt daraus, dass auch der Host, auf dem die DMZ läuft, mit seinem Management-Interface nicht im LAN stehen darf (und somit auch nicht Mitglied des produktiven AD ist). Der nächste logische Schritt ist dann, dass auch für die Verwaltung dieses Hosts eine Admin-Workstation verwendet werden muss, die im DMZ-Management-Netz steht und nicht im LAN. Jetzt muss man sich aber die viel profanere Frage stellen: Wenn Du eine Edge-V

Wenn das die Erklärung für den Eintrag im AD ist, ja.

Moin, wenn der Key, z. B. im KMS, Enterprise ist, wird eine Pro-Installation zu Enterprise und umgekehrt.

Du ziehst doch Daten aus dem AD. In diesem kannst Du ja auch mit den GUI-Tools nachschauen, welche Werte bei welchen Objekten in welchen Attributen stehen. Das AD weiß übrigens nicht, welches Betriebssystem auf dem Rechner Deines Kollegen jetzt installiert ist. Dort steht nur, welches Betriebssystem unter diesem Namen dem AD beigetreten ist. Wenn das Cmdlet andere Werte liefert als dsa.msc., dann sind die Ergebnisse nicht stimmig.

Moin, alles, was Du mit Select-Object auswählen möchtest und was keine Standard-Property ist, musst Du natürlich zuerst in Get-ADComputer zu den -Properties hinzufügen, damit das auch aus dem AD geholt wird

Das ist aber für den Cloud-Admin der eigentliche Preis dafür, dass er sich nicht mehr mit Servern herumschlagen muss.