daabm

@Nils: Was hat denn bitte UAC mit der Verwendung von Gruppen in RG zu tun??? @Nico: Was sagt "whoami /groups" und was sagt der Gruppenrichtlinien-Ergebnissatz? Verschachtelst Du globale oder DL-Gruppen? Du solltest globale verwenden...

Crossposts sind nie gerne gesehen...

Klar - MsgBox kannst Du ja ersetzen durch was auch immer Du willst :thumb1: Edit sagt: Wer die Sprechblase nicht sieht, schaut auch nicht auf den Desktophintergrund...

Warum - siehe oben - willst Du einen DC klonen? :confused: Das lohnt sich nur, wenn Du Dutzende oder Hunderte brauchst... Kennst Du USN; Invocation ID, DFSR ganz genau? Der Aufwand, AD und Sysvol Replikation hinterher sauber zu kriegen, dürfte höher sein als die Neuinstalation...

DFS-Client aktivieren? Gar nicht - die Fehlermeldung ist so alt wie falsch und hat noch nie gestimmt Wobei - bei Dir mit dem deaktivierten Client für MS Netzwerke stimmt "a)" sogar ausnahmsweise mal - sonst ist es immer ein Sysvol-Replikationsfehler der DCs...

Hab ich noch nie probiert - kann man da eine benutzerdefinierte Query hinterlegen? Dann such mal nach "eventlog query xml xpath" :cool:

Dann lösch das Benutzerprofil (vorher ggf. wegsichern). Geht schneller als langes Suchen...

Die ESC (Enhanced Security Configuration) gibt es auf Clients "eigentlich" gar nicht... Schau Dich mal um, welche Reg-Keys dazu gehören und behalte die im Auge. BTW: Wurde irgendwelche Software installiert? Habt Ihr servergespeicherte Profile und Terminalserver?

Muß ja nicht immer spannend sein - der Löffel wurde vor mehreren zigtausend Jahren erfunden und ich esse noch heute damit :thumb1: Außerdem gilt immer noch KISS - keep it simple and stupid :cool:

Steht das wirklich genau so in deinem Unattend? Schau mal hinten - "%c:\" sieht für mich komisch aus :cool: Und gibt es denn - falls doch nur Tippfehler - das Log und was steht drin?

...oder eine popelige Messagebox anzeigen - quick and dirty, aber funktioniert auch: http://evilgpo.blogspot.de/2013/08/passwortablaufwarnung-in-windows-7-und.html

Bei "Trigger" - meinst Du da grad Taskplaner-Events? Das dürfte schiefgehen - möglicherweise hilft VBScript mit WMI weiter: ExecNotificationQueryAsync wäre das Stichwort. Hab mich in WMI allerdings noch nie mit Druckjobs beschäftigt (nur mit Treibern/Ports/Queues), daher grad aus dem Kopf keine Ahnung, ob's ne passende Klasse gibt...

Ja, so ist es - erstellen ist ganz einfach, aber das Analysieren ist - mit Verlaub - ein echter Sch*****dr*ck :mad: Vor allem, weil Du mitunter auch noch nen Trace von einem Zwischenpunkt dazu benötigst... Und wenn dann noch "magische" Wunderkisten wie die Steelheads im Spiel sind, dann wird's vollends wahnsinnig :p

E2E-Trace? Ganz einfach: Netmon/Wireshark/Message Analyzer/netsh hernehmen auf dem Client und dem Zielsystem, und dann gleichzeitig Trace starten, und dann die betreffende Anwendung (hier also RDP) starten. Und dann kommt das mühsame Korrelieren der einzelnen Pakete auf Server- und Clientseite inkl. der zugehörigen Timestamps.

Stimmt auch wieder - boote immer x86, von da aus kannst Du auch amd64 installieren. Mußt ggf. das unattend.xml von Hand anpassen, weil da drin die WinPE-Settings natürlich x86 sein müssen, auch wenn Du amd64 installierst.

%logonserver% würde ich vermeiden - damit kannst Du nur auf DCs zugreifen. Besser DFS-N, das ist auch AD-integriert und site-aware. Und "Profile synchron über mehrere Standorte" - das steht ja schon weiter oben: Ja, technisch geht es mit DFS-R, aber MS supportet es nicht, und die Profile werden immer wieder mal kapput gehen. Daher ja auch UE-V.

Zum Thema "unbeaufsichtigte Installation" kann ich msfn.org empfehlen. Und wie lefg sagt: Es ist - leider - bei jeder Anwendung individuell... Die Wartezeit für Skripts steckt unter Admin-Vorlagen/System/Skrips.

In welcher Phase? Run gibt's (soweit ich mich erinnere) im Specialize (da würde es hingehören) und im OOBE. Und warum eigentlich per Powershell??? Unattend läuft nicht in Powershell, das sind normale Commands, das kannst Du einfach direkt als Exe aufrufen mit Parameter...

Ja, ich weiß es aus dem Stegreif. Aber ich bin nicht immer da :jau: Und bitte um Verständnis, dass wir oft das Gefühl haben, daß "richtig suchen" die meisten Threads in den meisten Foren obsolet machen würde... Schön, dass Du es gefunden hast, und wenn Du nicht klarkommst, dann einfach noch mal "erst suchen, dann gerne fragen" :D

USBDLM ist in der Tat das perfekte Werkzeug für dieses Szenario - hier seit Jahren problemlos im (privaten) Einsatz :cool: Die INI-Datei dazu kann komfortabel mit Group Policy Preferences zentral verwaltet werden.

"Synchrone Profile" sind eine Altlast aus der Zeit servergespeicherter Profile :-) Lokale Profile verwenden, alle wichtigen Daten per Ordnerumleitung zentralisieren, ggf. (wenn SA vorhanden) mit UE-V ergänzen, erledigt. DFS-R kann man durchaus verwenden, aber NIEMALS mit mehr als einem aktiven Ordnerziel, wenn man nicht ständig Replikation und Benutzererwartung wieder in Einklang bringen will. Das gilt für Profile UND für Homesets.

lefg hat recht - 30 Minuten warten lassen bei der Anmeldung ist eher ungeschickt. Aber wenn Du unbedingt willst -> konfiguriere Startskripts auf "gleichzeitig ausführen", damit sie sequentiell verarbeitet werden ("Startskripts asynchron ausführen" deaktivieren).

...und dann gäbe es ja auch noch gpsearch.azurewebsites.net.... Aber das muss jetzt reichen :eek:

Nein, nicht auf diese Weise. Woher soll er wissen, dass Du auf amd64 nicht evtl. x86 installieren willst? Was gehen würde, ist ein angepasstes unattend.xml in Verbindung mit einem "All In One" install.wim (das Du Dir mit dism/imagex recht einfach bauen kannst).

Was für Abhängigkeiten? Bei mir macht das ein Batch, der vorgegebene Verzeichnisse in alphabetischer Reihenfolge abklappert, den passe ich einmal richtig an und gut is... Die "komplexe" Anwendung kommt hinterher aus System Center, und die Konfig dieser komplexen Anwendung kommt aus passenden GPOs - alles ganz einfach und wesentlich stressfreier als Sysprep. ym2c... :cool: