hotzenplotz

sorry späte Antwort. Das Anmelden ist nie ein Problem - ist mir persönlich jedenfalls noch nicht aufgefallen und habe diesbezüglich auch keine Meldungen erhalten

Schwierig zu verifizieren - weil man das Problem nicht forcieren kann. Geht vorwiegend um Windows 10 Clients, die auch im gleichen Turnus die gleichen Updates erhalten. Ich persönlich nutze oft RDP und hab es die letzten Wochen vielleicht 2 mal gehabt. Hab nun mal die TCP only Konnektivität eingeschaltet, mal schauen...

Merci, danke für den Hinweis - werde das mal testen (ChatGPT hat leider versagt )

Liebe Community, seit geraumer Zeit, haben wir Probleme mit unseren RDP Verbindungen. Egal ob von physischen PC zu physichen PC oder einer VM - selben VLAN / Subnet. (kein Windows RDS im Einsatz) Das äußer sicht so, das die RDP Verbindung kurz unterbrochen wird, 2-3 Sekunden (siehe Screenshot) und dann wieder hergestellt wird. Das passiert mal 2-3 Mal hintereinander, dann ist wieder Ruhe oder den ganzen Tag über passiert gar nix. Es ist so kein Muster oder sowas erkennbar. Netzwerkmäßig sieht es soweit okay aus, das ein Dauerping ohne Paketverlust mitläuft, deshalb hätten wir das so erstmal ausgeschlossen. Stellt sich die Frage, was das Problem sein könnte - wonach man schauen könnte - Windows Logs klar, aber wonach schauen bzw. welche Auditpolicies müssten aktiv sein, die solche Problematiken mitschneiden. Ggf. irgendwelche GPOs die hier quer schießen etc. pp. Das Problem ist jedenfalls nicht reproduzierbar bzw. forcierbar - es passiert gefühlt rein zufällig. Bin dankbar für Ideen. Viele Grüße Hotze

ja, wollte nur auf nummer sicher gehen - kein bock wenn hunderte user dann bei mir anrufen, weil der anmeldeprozess sich hinzieht und aus lauter ungeduld die kiste hart ausgeschaltet wird - alles schon passiert umständlich finde ich das prozedere soweit schon, aber gut, dafür gibts ja foren. danke an alle, die die geduld aufbrachten, mir da weiterzuhelfen.

Informieren werden wir natürlich sowieso ;-). Nee die Daten die sich in den "Eigenen Dateien" befinden, werden nicht wieder lokal umgezogen. Das kann sich durchaus um Gigabyte an Daten handeln. Habe es mittlerweile mal mit einem Testuser probiert und eine "Konter"-GPO drüber gesetzt, eigentlich mit den selben Einstellungen, und dann "An den lokalen Benutzerprofilpfad umleiten" gesetzt. Ergebnis: Ordner sind wieder lokal, die Daten bleiben am Ursprungsort.

Also für mich bezieht sich das doch ausschließlich auf den leeren Ordner und nicht den Inhalt. Dafür gibt es doch extra einen Auswahlpunkt

hmm, diese richtlinie ist mehr als undurchsichtig gestaltet ... zumindest für mich ... Die Option des Zurückkopierens ist doch gar nicht aktiviert ... naja werd es mal so probieren.

versteh ich nicht ganz ... :-O. Die Settings sind gerade wie auf den ersten 3 Screenshots dargestellt. Ich würde einfach nur die Option "An lokalen Benutzerprofilpfad umleiten" setzen, mit dem Ziel das Eigene Dateien wieder unter dem lokalen Benutzerprofilpfad landen, ABER der Inhalt nicht mit kopiert wird, und das Zeug auf dem Server liegen bleibt. Sorry wenn ich mich da ein bissel unverständlich ausgedrückt habe. edit: und natürlich die Frage, wie man das am dümmsten mit einzelnen Testusern probieren kann. 1. mit Sicherheitsfilterung (Lesen ja, Anwenden nein) - ist das in dem Fall das gleiche wie die Einstellung rückgängig machen?! 2. eine neue GPO mit der aktiven Option "An lokalen Benutzerprofilpfad umleiten" die die andere GPO überschreibt? ...

Nein gegenwärtig ist da natürlich keine Verzögerung bzgl. der Ordnerumleitung. Ich befürchte nur, wenn ich die Option "Den Inhalt von Dokumente an neuen Ort verschieben" aktiviere, und die GPO wieder auf lokal umleite, er dann beim Kopiervorgang rumnudelt - weil es dann mitunter GB an Daten sind, die wieder rumgeschoben werden. Deshalb die Absicht, das "alte" Zeug auf dem Share zu belassen, aber zukünftig wieder alles lokal zu speichern. Die Frage ist ja in dem Sinne nur, ob ich das mit meiner geplanten "Methodik" so erfolgreich umsetzen kann oder ich einen Denkfehler drin habe

Liebe ForenmitleserInnen, die Frage gab es wahrscheinlich schon mal, dann entschuldigt bitte. Kurz zum "Problem". Wir haben für Eigene Dokumente und Bilder die Ordnerumleitung aktiv, sprich Dateien die darunter abgespeichert werden, werden auf einem Fileshare geballert. Wir würden das gerne wieder deaktivieren, mit dem Ziel das die oben genannten Ordner wieder im lokalen Profil landen, die Daten aber nicht wieder mit rüberkopiert werden, sondern auf dem Server liegen bleiben (um einfach einen verzögerten Anmeldeprozess zu verhindern). Folgendes ist nun eingestellt: Einstellen würde ich, um diese Richtlinie rückgängig zu machen folgendes: Habe jetzt hier und da gelesen, das man eine Extra-GPO anlegen muss mit dem Pfad %USERPROFILE%\Eigene Dateien. Hoffe einfach es hat schon jemand damit Erfahrungen gemacht, das wieder anständig zu entfernen ... Danke für die Hilfe.. Viele Grüße Hotze

späte antwort, erstmal danke für die antwort. bin noch nicht wirklich weiter, habe hier und da noch bisschen probiert und die GPOs wirklich bzgl WSUS aufs minimalste runtergeschraubt und noch den alternativen Server gesetzt, Kontakt zu MS Updates deaktiviert und den Downloadmode auf 100 gesetzt. Mal funktionierts dann mal nicht vereinzelt. Wie gesagt, ist noch nicht wirklich gelöst. aber danke

Danke für die Rückmeldung. Alternate Downloadserver ist bei uns wieder leer. Wir haben noch in der DMZ einen WSUS, der soll aber nicht nochmal das komplette Updategeraffel speichern, deshalb haben wir den so konfiguriert, das Updates dann direkt bei MS heruntergeladen werden, aber trotzdem an den WSUS reportet wird. Wenn da nun als Alternate Downloadserver unser WSUS drin steht, klappt das nicht mehr mit den externen Clients die da ohne VPN rumdümpeln. Da ist sicherlich noch viel Zeugs aus Win 7 und gar XP mitgeschleppt bzw. eingestellt.

Hi liebe Community, wir haben da immer mal wieder vereinzelt Windows 10 Clients, die sich merkwürdig verhalten. Im Unternehmen haben wir einen WSUS und geben die Updates so frei. Klappt zu 90% auch gut. Ab und zu haben wir aber Clients, egal ob frisch per Softwareverteilung installiert oder länger nicht am Netz oder auch ganz normal am LAN, Updates liefen immer fein bis zu einem undefinierten Zeitpunkt / Zustand. Windows 10 Versionen waren da nicht spezifisch, kam bei 1909, 2004 und 20H2 vor. Haben die Settings/Button "Online nach Updates suchen" nicht deaktiviert (hatten wir aber auch schon) und die spezielle Einstellung, die den DualScan deaktiviert ist gesetzt (genaue Bezeichnung leider vergessen, ich sehe aber das der Registry Wert entsprechend gesetzt ist - soll ja damit Probleme geben). Zum eigentlichen Problem: Diese Clients erhalten dann in dem Windows Update Fenster, das Updates fehlen beispielsweise und der PC gefährdet ist - manchmal ist da aber auch gar nichts auffällig. Dann klickt man schön auf den Button nach Updates suchen, es wird gesucht, aber auf dem WSUS nix gefunden. Klickt man dann auf Online nach Updates suchen, werden unter anderem natürlich auch von uns nicht genehmigte Updates gefunden und dann auch immer KB4023057. Sobald dieses Update drauf ist, kann man auch wieder nur auf "Nach Updates suchen" klicken und siehe da, es werden auch andere Updates vom WSUS gefunden. So wie ich das immer lese ist KB4023057 im WSUS / Unternehmensumfeld überhaupt nicht relevant, man bekommts für neuere Windows Versionen auch gar nicht aus dem Catalog heruntergeladen. Wir sind da ein bisschen ratlos, woran es nun liegt - weil die anderen funktionierenden Clients ja die gleiche GPOs erhalten, wie die, die manchmal einfach rumspacken. Danke. Viele Grüße

Wir sind bei 1809, auch erst seit kurzem, also von aktuell weit entfernt ;). Standard Office PCs würde ich klar so behandeln, aber gibt leider auch Rechner die Spezialsoftware und dementsprechend Konfigurationen von externen Herstellern drauf haben, die man ungern einfach platt macht und frisch installiert:). Aber lässt sich wohl zukünftig nicht vermeiden.