daabm

Wenn Du "Warteschlangen je Server" meinst: IMHO nein. Wenn doch, dann ist sie so hoch, daß sie in der Praxis keine Relevanz hat.

Warum ist Nachforschen in der Ereignisanzeige mühsam? Filter konfigurieren - Event-ID, Quelle, Zeitraum - und fertig... Oder XML schreiben

Konfiguriere https://gpsearch.azurewebsites.net/#319 auf einen Wert, der für dich passt. Standard sind 30 Sekunden.

Den Kram kenn ich alles. Nutzt nur kaum was, sieht halt auf dem Papier gut aus. Was ich sehe, kann ich weitergeben. Isso

Nils, das war mir schon klar. Aber %clientname% ist speziell, weil es nicht direkt im (Re-)Connect bereitsteht, sondern erst danach. Wenn Du bginfo per Logonskript aufrufst, hat es verloren. Und wenn es beim Reconnect-Event läuft, ebenfalls. Beide Möglichkeiten laufen aus einem Prozess, in dem %clientname% nicht verfügbar ist... Also haben wir uns seinerzeit mit Volatile Environment beholfen. Herausforderung dabei: Die richtige Sitzungsnummer, die den Unterschlüssel darstellt, unter dem der aktuelle Clientname zu suchen ist.

Manche Anforderungen des Managements gehen an der Praxis einfach meilenweit vorbei... Traust Du deinem Admin? Wenn nein, besorge Dir einen neuen Admin. Traust Du deinem Mitarbeiter? Wenn nein... usw. Niemand kann das Abfotografieren von Bildschirmen verhindern. Wenns schnell gehen muß, filmt man beim Durchscrollen mit. Und dann? ym2c...

Also wir hatten schon Kunden mit knapp 300 Druckern auf einem einzigen Printserver - bist Du sicher, daß das Dein Problem ist?

Wenn im Eventlog nix zu sehen ist, ist es ein HW-Problem und kein Bluescreen. Ich wäre auch beim Netzteil, ggf. beim Mainboard.

WDS mit ADK/MDT ist an einem Tag funktionsfähig eingerichtet. Der Feinschliff kann dann noch mal ein paar Tage dauern - oder auch Monate Dann noch WSUS mit dem WPP, und Du bist schon beinahe im Enterprise-Komfort angekommen.

Irgendwas war halt immer wichtiger... Ist bei uns genauso, noch einige k Server auf 2008R2... Irgendwann geht dann die Update-Prio nach oben, weil die Supportkosten präsenter werden

BGInfo geht, aber ich bin nicht sicher, ob das den %clientname% mitbekommt. Und beim Reconnect wird es ohnehin schwierig - oder Du machst nen geplanten Task darauf mit 30 Sekunden Verzögerung, das sollte klappen und wäre auch für mich dann die bessere Lösung.

https://blogs.technet.microsoft.com/askds/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat/ Wenn Du dazu Fragen hast - einfach fragen ?

Das orientiert sich ganz stumpf an der GUID der CSEs - alphabetisch. Einzige Ausnahme: Registry... Und wunderbar, irgendwer hat immer schon einen Blogpost dazu geschrieben http://evilgpo.blogspot.com/2012/11/guids-guids-guids.html PS: Ob Computer oder User gewinnt, entscheidet der Implementierer. Bei mir kommt es drauf an - meistens ist es in der Tat der Computer, aber z.B. in unserer Druckerlösung gewinnt der User.

RDP bedingt interaktiv, und "nur eine Anwendung" ist halt auch eine Anmeldesitzung. Also "nein".

Ich oute mich als ahnungslos - was bitte ist ABC-Update?

Yupp, %clientname%. Und DNS sollte dann den Rest liefern können... Edit: %clientname% kannst in RDS-Sessions weder bei Logonskripts noch in geplanten Tasks beim Reconnect verwenden - die wird zu spät in die aktuelle Session gebracht. Da mußt direkt in der Registry suchen unter Volatile Environment\<Session-Nummer> Vielleicht erklärst mal, was Du vorhast?

Bin schon von Batch über VBS nach PS gewandert - InTune möchte ich mir nicht antun Aber wir sind schon wieder OT...

Welche Rechte? Lokaler Admin...

Wo ist das Problem? Die gibt's immer noch... Rechtsklick in den freien Bereich der Baumanzeige links, "Alle Ordner anzeigen". Das gibts übrigens auch schon länger

Das sieht MS leider anders - im MVP-Programm wurde die komplette GPO-Expertise letzes Jahr gekickt... "OnPremise - braucht doch keiner mehr..." BTT: Wenn die Kennwortrichtlinien nirgends außer in der DDP gesetzt sind, könnte man alternativ auch direkt per ADSIEdit die Domain Attribute bearbeiten, die wandern dann - it's magic! - in die DDP zurück.

'Meiner ist länger wie Deiner'? Und so ganz allgemein: Wenn Ihr Skripts entwerft - vermeidet Pipes (besser ForEach-Schleifen) und PS-Arrays und += (besser .NET ArrayList oder so was). Der Performancezuwachs dürfte hinlänglich bekannt sein.

Änderungen im UI macht MS bei Fixen extrem ungern, weil das alles in allen Sprachen getestet werden muß. Deaktivieren ist tatsächlich einfacher als ausbauen. Und die Kennwörter in Preferences liest Dir PowerSploit im Handumdrehen aus, das mußte also tatsächlich unterbunden werden. Edit: Funktionieren tun die Kennwörter in den Preferences übrigens nach wie vor, die Client-Seite wurde diesbezüglich nicht beschnitten. Man bräuchte also nur einen Rechner ohne MS15-025 - oder man trägt das Zeug manuell in das XML ein. Ist ausreichend dokumentiert, wie das gehen würde. Oder man schaut sich PowerSploit mal genauer an und macht da dann das gleiche, nur andersrum

MaxPWLen per DDP ist durch das dämliche UI von secedit limitiert... Das ist ne Implementierung aus W2K Zeiten, die nie aktualisiert wurde. Schon alleine der Kram mit sceregvl.inf und den zugehörigen Registry-Werten kann einem schlaflose Nächte bescheren. Wie kamen die damals auf dieses hirnrissige Konstrukt?

Für so Zeug ist nahezu immer Drittanbietersoftware verantwortlich.

Der Hersteller soll den Quatsch bleiben lassen. MSI-Pakete lassen sich mit der jeweils neuesten (OS-integrierten) Installer-Version problemlos installieren, nahezu egal wie alt sie sind.