Sunny61

Danke, aber ich nehme lieber die ADMX-Templates aus dem laufenden System. Wir wissen nicht was der Installer zu tun hat, das mußt Du schon MSFT selbst fragen. Wenn Du unbedingt mit dem Central Store arbeiten möchtest, dann kopier von einem W10 1607 oder einer anderen Version die ADMX-Templates aus dem passenden Ordner in den Central Store. Hier nochmal ein HwoTo dafür: https://www.gruppenrichtlinien.de/artikel/central-store-fuer-administrative-vorlagen/ Ansonsten bleibe ich dabei, für jede W10 Version die es gibt im jeweiligen LAN, eine eigene VM betreiben. GPOs passend benennen und mit WMI-Filter ausstatten. MSFT nimmt Einstellungen weg, die findest Du auch nicht mehr, sie bleiben aber auf den Clients vorhanden und können Fehlverhalten hervorrufen.

Nein, ist es nicht. Zumindest nicht bis in die 1703.

Keys hab ich auch genug, hast Du auch genug Nachweise (Rechnungen) im Schrank? Hält das alles einer Überprüfung der Lizenzen stand?

Nur wenn Du exakt an der Stelle die Werte einstellst, werden sie auch von den Clients übernommen.

Immer nur eine Version von W10? Glaub ich nicht. Auch wenn es so wäre, Du musst ja auch vorbereiten für die nächste Version, die eingesetzt wird. Jepp, extra VM. Für was braucht man einen ADMX Installer? Du weißt nicht wo die aktuellen ADMX-Templates zu finden sind, oder weshalb brauchst Du einen Installer dafür?

IMO sollte die Grenze vom Exchange greifen. Ich würde den Benutzer einfach informieren und ihm raten, Outlook schließen und nach einer Wartezeit von 1 Minute wieder neu zu starten. Jetzt sollte in Outlook auch die neue Größe angezeigt werden.

Mit der Einführung von W10 ist es sinnvoller pro W10 Version eine VM aufzusetzen und darin die GPOs für die jeweilige W10 Version zu pflegen. Entsprechend würde ich die GPOs passend benamsen und mittels WMI-Filter filtern.

Bei VNC und/oder Dameware freut sich der Betriebsrat.

So ein Benutzerprofil ist in 30 Sekunden neu erstellt, das kann doch nicht so schwer sein.

Probier es einfach mal aus, innerhalb eines Windows Netzwerkes gibt es IMO nichts einfacheres und besseres für den User: https://www.gruppenrichtlinien.de/artikel/remoteunterstuetzung-remote-assistance-netzwerkweit-anbieten/

Na wunderbar, dann hoffen wir, dass das Streifenproblem in der 1709 mit den Remote Apps auch weg ist, dann könnte man die 1709 tatsächlich testen. :) Danke für deine Rückmeldung.

Die Remoteunterstützung ist seit XP in Windows vorhanden und kann durch GPO konfiguriert werden.

Welches Profil hast Du schon erneuert? Outlook- oder Benutzerprofil? Wenn ersteres, dann zweiteres erneuern.

Du siehst das nur über den Screenshot: https://static.spiceworks.com/shared/post/0001/9738/5-30-2014_6-51-55_PM.png

Schau mal ob dir dieser Thread beim Verständnis hilft: https://community.spiceworks.com/topic/506431-wsus-approving-updates-to-certain-groups Oder auch dieses Script: https://gallery.technet.microsoft.com/scriptcenter/5c01defe-1da0-4003-80b1-a653e789dbf5 Und dieser Artikel könnte auch helfen: https://blogs.technet.microsoft.com/heyscriptingguy/2012/01/18/approve-or-decline-wsus-updates-by-using-powershell/ Oder auch dieser Thread: https://social.technet.microsoft.com/Forums/office/en-US/42f102bb-065c-40c9-85e3-534476513220/is-update-approved-for-specific-group-via-powershell?forum=winserverpowershell BTW: Der WSUS verteilt nichts, er stellt zur Verfügung. Das mag jetzt nach Haarspalterei klingen, ist aber im Fehlerfall wichtig zu wissen wie es funktioniert. Der Client/Server *HOLT* beim WSUS, nicht der WSUS liefert irgendjemandem etwas.

Nicht alles was man liest ist gängige Praxis. Kleinigkeiten kann man ins Netlogon legen. Das ist aber auch nicht so dolle. Lieber ein Share anlegen, passend bezeichnen und freigeben.

Super, den dritten Wert benötigen übrigens auch die Clients. Danke für die Rückmeldung. ;)

Ein Boot tut immer gut. :) Danke für die Rückmeldung. ;)

Alternativ kann man auch bei Gelegenheit das Ereignisprotokoll der VM anschauen, da könnte sich ein Hinweis auf den Fehler finden.

Noch ein Hinweis, natürlich kannst Du die neuen Laufwerke gleich mit dem DFS-Pfad zuweisen. Spart beim erneuten Umzug das Löschen und neu verbinden.

Na endlich, trag beim Alternativen Downloadserver auch den WSUS ein, wenn der Server den Wert in der Registry stehen hat, dann den Dienst WUAUSERV einmal neu starten. Beim Client den Schnellstart deaktivieren und dann neu starten. Jetzt auch Softwaredistribution löschen und wieder neu starten. Jetzt nach Updates suchen lassen.

Alternativ den Server booten, anschließend sollte es funktionieren. Gibt es in der Liste der offenen Dateien noch Zugriffe auf das Verzeichnis?

Wieso händisch auf dem Client löschen? Das net use * /delete /yes kannst Du auch in einem Script auf jedem Client laufen lassen, anschließend dann die neuen Laufwerke verbinden, ebenfalls mit net use x: \\Server\Share /persistent:no

Im GPO gibt es Einträge für die Adresse des WSUS, wie viel hast Du? Zwei oder drei?

Wie viel Einträge für den WSUS hat dein GPO? Zwei oder drei?