Sunny61

Ja, gibt es nur W2016er Server. Deshalb hab ich das ja auch geschrieben, dass Du die ADMX-Templates direkt auf den Servern verwenden sollst. Computergruppen in der WSUS-Konsole. Die Gruppe1 bekommt die Freigabe in Woche 1, die Gruppe 2 in Woche 2 oder 3. BTW: Es gibt im Userprofil in %APPDATA%, genauer hab ich es gerade nicht, eine Datei WSUS, ohne Endung. Darin sind die persönlichen Einstellungen der Konsole gespeichert. Die kannst Du ja an deine Kollegen verteilen, am besten per Script ins Dateisystem kopieren, dann haben alle das gleiche. Ist ja auch so in Ordnung. Ich bezweifle stark, dass ein W2016 mit den 'Wocheneinstellungen aus deinem GPO klar kommt. Prüfen und vor allem, testen. OK, beim Hinzufügen der Computergruppen bzw. entfernen der Authentifizierten Benutzer unbedingt über den Reiter Delegierung gehen. https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

Wenn es dabei wirklich nur um Server 2016 gehen soll, dann nimm bitte dafür das WindowsUpdate Template für die W2016er Server. Denn in den reinen W2016 Templates existiert die Wochenangabe nicht. Möglicherweise greift es bei der Installation, möglicherweise auch nicht. Testen ist angesagt. In den Einstellungsmöglichkeiten für Automatische Updates konfigurieren gibt es übrigens einen Punkt 7: 7=Notify for install and notify for restart. (Windows Server only) Zum zweiten trenne die GPO-Einstellungen ab von den anderen. Ein Basis GPO erstellen, die restlichen Einstellungen pro GPO vornehmen. Mit den Freigaben der Updates für die Gruppen ebenfalls so vorgehen. Gruppe 1 bekommt die neuen Updates freigegeben, Gruppe 2 bekommt sie in Woche 4 freigegeben und so weiter.

Super dass Du die Lösung gepostet hast! :) BTW: Auf solchen Rechnern schaue ich auch immer die installierten Programme durch, sortiert nach Installationsdatum bringt so manches an den Tag. Falls jemand von chip downloadet, findet man fast immer etwas.

Ja, nutze Remote Unterstützung. Da kann der User zuschauen was Du tust und wenn Du fertig bist, kann er sofort wieder arbeiten. Dein geschilderter Fall ist ganz normal und völlig in Ordnung. https://www.anreiter.at/it-support-windows-remoteunterstuetzung/

Wenn es im abgesicherten Modus auch nicht klappt, ist eine saubere Neuinstallation mit W8.1 vermutlich der beste Weg. Alternativ auf W10 testen ob man das Programm nicht im W7 Kompatibilitätsmodus starten kann.

Die Firmware der beteiligten Switche ist aktuell?

Du kannst natürlich den Modus 100 einstellen, die Updates werden ja trotzdem aus dem Internet geholt. Das definierst Du ja in den WSUS-Optionen. Wenn die 100 eingestellt ist, wird der Dienst BITS (Intelligenter Hintergrund Übertragungsdienst) für den Download benutzt. Und den kannst Du per GPO-Einstellungen eingrenzen. Dann wird nicht die komplette Bandbreite benutzt. https://www.wsus.de/bits/ Wenn der Client nur das holen soll was auf dem WSUSfreigegeben ist, dann deaktiviere zusätzlich noch den DualScan Modus. https://www.escde.net/blog/windows-update-richtlinien-und-dual-scan

Sorry, ganz vergessen. Ja, selbstgehosteter Exchange 2016. Norbert meinte die exakte Version/Build des Exchange. Wie das das rausfindest, steht hier: https://social.technet.microsoft.com/wiki/contents/articles/15776.exchange-server-2013-2016-and-2019-build-numbers-with-cumulative-updates.aspx

Startet Outlook auch nicht mit gedrückter STRG-Taste?

Bei Click2Run kann man AFAIR auch einen eigenen Update Server im LAN definieren.

Auf https://www.wsus.de/ findest Du HowTos zur Nutzung von WPP + WSUS. Lesen, lesen und nochmal lesen. Dann an einem Produkt ausprobieren.

Wie soll er sich denn mit dem Server verbinden? Soll er nur auf eine Freigabe zugreifen? Falls ja, dann ist dein eingeschlagener Weg falsch.

In obigen Bild musst Du den Silent Parameter in der Befehlszeile eingeben. Wenn der Client allerdings rückmeldet 0 Updates erforderlich, passen die Regeln noch nicht. Zuerst kommt die Regel ob das Update bereits installiert ist, mit einem MSI geht das natürlich einfach. Es wird der Productcode geprüft. Als zweite Regel wird geprüft, ob das Update installiert werden kann. Schau dir dazu dieses HowTo an: https://www.wsus.de/uninstall2install-update-erstellen/ Das HowTo sollte auch beim Verständnis helfen: https://www.wsus.de/chrome-per-wpp-als-update-bereitstellen/

Darunter ist dann das VB-Script zu finden. ;)

Aufgrund dieser Befehle wird IMO kein einziges Update installiert. In diesem Thread https://social.technet.microsoft.com/Forums/exchange/de-DE/76ffb02b-15df-45e0-b4a9-473be4757d31/wuauclt-updatenow-doesnt-work-on-windows-server-2012-r2?forum=winserver8gen geht es daru, dass /Updatenow wohl nur unter ganz bestimmten Bedingungen, Einstellungen am Client, funktioniert. Da ist diese Variante die sicherere: https://znil.net/index.php/Windows_Update_per_Skript_suchen_herunterladen_installieren_reboot

Wie genau hast Du das denn gemacht? Woher weißt Du dass der Server up2date ist? Hast Du keinen WSUS im Einsatz?

Geht doch IMO recht einfach. Entweder per mittels Script in eine Freigabe alle Drucker pro User in eine Logdatei ausgeben oder gleich zu Beginn beim Login jeden Drucker auf dem Client löschen und im zweiten Schritt neu anlegen. Wenn per Script, dann die Logdateien auslesen und gezielt die Drucker löschen. Sind es wirklich viele Drucker oder nur ein paar?

Diese Änderung fand im Juni 2016 statt, es jährt sich in diesen Tagen schon wieder. ;) Aufmerksam lesen und das/die GPO(s) anpassen, schon läuft wieder alles wie vor Juni 2016. https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

Bist Du sicher? Ich kann das nicht sehen und noch weniger glauben, dass MS das gestrichen haben soll. Welche genaue Einstellung meinst Du? Per GPP geht es immer noch.

Ein Ticketsystem ist hier ein passendes System. Einmal eingerichtet und die User dorthin geleitet hilft das beiden Seiten. Der Kunde, in dem Fall der User, kann reinschreiben und sieht auch Kommunikation eines Tickets. Zusätzlich kann der Admin benötigte Zeiten eintragen. BTW: Solche Ansprachen/Anfragen auf dem Flur kann man dann gleich ins Ticketsystem einkippen lassen.

Seit 14.06.2016 gibt es diese Änderung, Aber es muss ein Geheimnis sein, hält sich ziemlich lange im Hintergrund. :) https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

Ob es der WSUS das Update hat kann und soll man manuell prüfen.

@d33jay Das Log von einem Client nützt nichts, wenn es der WSUS schon nicht downlädt. @Squire Hast Du denn die Möglichkeit, dass der eine WSUS vom anderen abholt? Ich kann das von dir nachvollziehen, wir haben das hier auch bei einem WSUS. Hast Du denn schon mal probiert, auf dem WSUS, auf dem es NICHT funktioniert, das Update manuell zu importieren in den WSUS? Dazu musst Du in der WSUS-Konsole bei Updates > Rechtsklick ausführen > Updates importieren. Es muss über den IE abgewickelt werden.

Erstell doch mal ein Update mit einem MSI, dann wird eine Package Level Rule erstellt.

Defender ist out of the Box auf dem Exchange an, beendet und deaktiviert wirklich jeder den Dienst vor der Installation der CUs? Dann erst ist der Defender aus. Bei 3rd Party AV-Scanner Dienst beenden, deaktivieren und Reboot machen. So wäre meine Vorgehensweise. Und das Wartungsfenster immer schön großzügig planen. :)