scirocco790

Werden diese Updates bei euch im WSUS auch erst mal zur Installation an die Server durchgereicht? Schon oder? Die haben ganz normal die Klassifikation "Updates" am WSUS. Von daher wüsste ich nicht wie ich die jeden Monat im WSUS blocken soll, ohne manuell aktiv zu werden. Das "richtige" Qualitätsrollup kommt ja eh noch. Sprich meine Server machen inzwischen dann 3 Reboots pro Monat, nur um die Updateschwemme durchzuinstallieren. Was für ein Käse.

Seit kurzem verteilt MS ja auch für Windows Server die Updaterollups. Unter anderem habe ich nun jedes Monat die "Vorschau des monatlichen Qualitätsrollups" mit dabei. Ist das nun eine Beta oder so etwas? Interessanterweise steht diese unter "wichtige Updates" auf meinen Servern mit drin. Ich hab da leider auch nichts bei MS gefunden, wo das genau beschrieben wird. Aufgefallen ist mir, daß bei einem Server der Updates NICHT von WSUS bezieht, stehen die "Vorschau des monatlichen Qualitätsrollups".Updates unter Optional, bei meinen Servern die Updates über WSUS bekommen unter "wichtige Updates". Dank euch!

... schon klar. Das sollten sie ja auch. Nur irgendwie bin ich wohl auf die Regel drunter gekommen und hatte es da aktiviert. Seis drum. Blöder Tag heut.

Fällt wohl beides unter die Rubrik "Shit happens!"... ;-)

Danke für den Tip. Der Installationsstichttag war auf genau dem betreffenden WSUS (versehentlich) in der Installationsrichtlinie für die Server, genau gleich gesetzt worden, wie für die Clients. Ein Klick daneben... Lag mal nicht an MS. Danke. Da hätt ich jetzt als letztes gesucht.

Mir platzt echt langsam der Kragen wegen der Vorgehensweise von MS und der Verteilung/Installation von Updates... Seit Oktober verteilt MS auch für die Windows Sever ja nur noch diese tollen Pakete. Meine Server beziehen diese alle von WSUS, geht auch soweit. Aber: Seit den Oktoberupdates ignorieren alle Server meine Einstellungen aus den Gruppenrichtlinien zum Installationszeitpunkt. Die Updates liegen auf den Servern vor, und werden "aus administrativen Gründen" welche nicht von mir definiert wurden, zu einem Zeitpunkt den ich ebenfalls nicht definiert habe, installiert. Das ist langsam wirklich Wahnsinn. Screenshot anbei. Das Verhalten ist auf allen Servern die ich habe (2008R2, 2012, 2012R2) nachvollziehbar. Für mich ist das eine mittlere Katastrophe, weil alle Server so gleichzeitg anfangen Updates zu installieren, und zwar über den Tag. Bisher hatte ich das immer Nachts am Wochenende erledigen lassen.

@AFM_Adm. Ich würd es trotzdem zumindest mal ausprobieren. Ist ja keine große Sache.

@lefg: Nein tut sie nicht. Die GPO habe ich gesetzt. Ich hatte deswegen sogar einen Call bei MS offen (hat ein halbes Jahr gedauert). Die Lösung wars eben das.

@AFM_Adm: Ich frage deswegen, ob die Shares auf einer VM (bei mir VMWare) liegen, da ich zur Einführung von W10 bei uns auch Probleme mit den Roaming Profiles hatte. Bei mir hat sich das so geäußert, daß ein Neustart der PCs immer Profilsynchronisationsfehler produzierte, besonders bei der NTUSER.dat, beim herunterfahren und danach wieder einschalten nicht mehr. Alternativ, wenn man vor der Anmeldung einfach 1 Minute gewartet hat ging es auch. Lösung war bei mir das hier: http://michlstechblog.info/blog/vmware-event-id-27-on-e1iexpress-nic-adapter/ Der Share liegt bei mir auf einem 2012 Server, war aber mit 2012R2 testweise ebenso. Vielleicht ists einen Versuch wert. MS hat da scheinbar doch einiges geändert, was die Profilsynchronisation angeht. Ob 1511 od 1607 ist übrigens egal.

Wäre schön wenn sich der TO mal wieder äußern würde?

Liegen die Shares von den Profilen auf einer virtuellen Maschine?

Werd ich mal ausprobieren. Ist schon seltsam. Ich würde ja nichts sagen, wenn die Kisten dann nicht einfach ohne weitere Rückfragen einen Reboot machen würden. Hab grad mal noch ein GPResult mit /scope computer gemacht. Alles perfekt soweit.

Also wie gesagt, mir scheint das seit dem Oktober-Update so zu sein. Oder nur bei dem Oktober-Update? Vorher ist das alles wie gewollt geschehen.

Von den Usern sind nur zwei lokaler Admin. Auch hier war das so nachvollziehbar. Screenshot von meiner GPO anbei. Arbeitszeit für "Automatischen Neustart während Nutzungszeit deaktivieren" ist von 6:00 bis 18:00 definiert. "Automatische Updates konfigurieren" Steht auf Option 3 (herunterladen und benachrichtigen). Geplante Systemwartung auf Donnerstag 12:00 Die GPO wird an den Clients auch gezogen. Hab ich mit GPResult u. RSOP schon gecheckt. Sind übrigens ausschließlich Maschineneinstellungen.

Also bei uns auf den Clients kommt genau dieses Band mit der Meldung das ein Neustart erforderlich ist. Das schlimme ist ja, das scheinbar die GPO "Automatischen Neustart während Nutzungszeit deaktiveren" komplett ignoriert wird, und ebenso "Automatische Updates sofort installieren". Letztere definiert ja folgendes: "Legt fest, ob Updates, für die weder die Windows-Dienste unterbrochen werden müssen noch Windows neu gestartet werden muss, automatisch installiert werden. Wenn der Status auf "Aktiviert" festgelegt ist, werden diese Updates automatisch installiert, nachdem sie heruntergeladen wurden und installationsbereit sind. Wenn der Status auf "Deaktiviert" festgelegt ist, werden solche Updates nicht sofort installiert." ... steht bei mir auf aktiviert, was bisher auch funktioniert hat. Bei den Servern (2008R2/2012/2012R2) (dein Beispiel) kein Problem.

Ist mir bekannt soweit, und nutze ich auch genau so. Funktioniert nur mit dem kumulativen Update vom Oktober nicht mehr. Die Meldung mit dem blauen Balken über den ganzen Bildschirm ist völlig neu. Habe ich vorher noch nie gesehen. Verhalten ist wie oben beschrieben.

Ein Frage in die Runde: Seit dem kumulativen Update vom Oktober f. 1607 kommt neuerdings am Client eine blaue Meldung über den ganzen Bildschirm, daß eine Update einen Neustart erfordert, und man 20 Minuten Zeit bekommt um seine Arbeit zu speichern, oder eben gleich neu zu starten. Nach Ablauf der 20 Minuten startet Win10 Pro (1607) einfach den Client neu. Punkt. Kann man machen was man möchte. Keine Meldung mehr, nichts. Habt ihr dieses Verhalten auch? Bei mir ist das 100% nachvollziehbar. Alle meine Clients bekommen ihre Updates von WSUS, Gruppenrichtlinien definieren das nur Updates im Hintergrund installiert werden dürfen die KEINEN Neustart erfordern. Scheint nun auch alles egal zu sein. Weiterhin habe ich definiert, daß Updates zwar heruntergeladen werden aber nur bei der geplanten Computerwartung installiert werden, und das mit Benachrichtigung. Und die ist um 12:00, Donnerstags. Scheint ebenfalls nicht mehr ausgewertet zu werden. Hat MS da schon wieder am Verhalten herumgedoktert? Das sieht mir so aus. Denen gehört sich langsam wirklich mal gehörig eine runtergehauen. Warum wird von Monat zu Monat einfach einen komplette Verhaltensweise geändert, ohne das irgendwo etwas davon bekannt gegeben wird? Ich bin aktuell reichlich genervt von der Updatethematik.

Nein, konnte ich in an keinem unserer Standorte feststellen. Das einzige was bei W10 etwas eigenwillig ist: Sobald ein Client ein Update am WSUS findet das er benötigt, wird dies sofort mit maximal verfügbarer Bandbreite heruntergeladen. Wenn das X-Clients gleichzeitig machen (Stichwort Zeiten mit hoher Last, z.B. der Klassiker morgens nachdem der Rechner eingeschaltet wurde), kann es da evtl. schon zu Engpässen kommen. Ich würde bei Deinem Problem da auch mal eher in Richtung Treiber der NIC tendieren.

Letzteres scheint es gewesen zu sein. Nachdem ich die Updates noch mal gelöscht und neu synchronisiert habe, scheint es gar zu gehen. Dank euch für die Hilfe. Die 1607 hat mich die letzen Wochen echt Nerven gekostet.

WSUS und 1607... Das scheint mir eine Vorhölle zu sein. Am ersten unserer Standorte hat das 1607 Upgrade per WSUS geklappt, und ist nun auch auf nahezu allen PCs drauf. Aber: Ich habe auf den WSUS Installationen an unseren weiteren Standorten folgendes Problem: Der WSUS lädt das Update gar nicht erst von MS herunter. Alle notwendigen Patches sind in der richtigen Reihenfolge installiert. Screenshoot anbei. Habt Ihr da einen Tip parat? Danke schonmal. :)

Noch ein Update zu der Sache: So 100% gelöst scheint mir das immer noch nicht zu sein. Ich habe heute das 1607 Upgrade an die ersten paar Clients freigegeben. Nun bekomme ich wieder den Fehler 0xc1800118 ... Gestern konnte ich an meinen 2 Testinstallationen das Upgrade vom WSUS aus einspielen, heute gehts wieder nicht mehr. Wie sind eure Erfahrungen? EDIT! Vergesst es. Wenn es immer noch nicht geht: net stop wuauserv del %windir%\SoftwareDistribution\DataStore\* Dann läuft das.

Funktioniert! :D :D :D @Pfuscher: Danke für Deinen kleinen Hinweis bei "Edit 3". Hatte ich übersehen, deswegen gings bei mir erst mal auch nicht.

@Pfuscher: Hattest Du bisher Erfolg? Ich bin bisher noch nicht dazu gekommen, das ganze mal zu testen. DIe WSUS Neuinstallationen hab ich mir gespart, da ich das in allen Werken hätte machen müssen. Irrer Aufwand. Wenn der Weg hier funktioniert, okay. Ganz lustig: Nachdem ich heute den KB-Artikel https://support.microsoft.com/en-us/kb/3194588 aufgerufen hatte wurde er mir automatisch übersetzt auf deutsch angezeigt. Inkl. aller SQL Befehle, die wurden auch mit "eingedeutscht". Die sind zur Zeit schon ganz schön cool drauf bei MS.

Seit heute gibts einen KB-Artikel zu dem Thema: https://support.microsoft.com/en-us/kb/3194588 Mal sehen ob es damit funktioniert. Edit: Achtung, der Artikel von MS enthält einige Schreibfehler. Im Skript muss es "delete from" und nicht "deletefrom" heissen. Weiterhin passen einige Tabellennamen nicht, da das Skript für die Englische Sprachversion ist. Mein Güte, was treiben die bei MS?

Kurze Rückinfo: Mit dem Update vom September (KB3189866) melden sich meine 1607 Installationen wieder am WSUS.