Sunny61

Diese GUID solltest Du im SYSVOL Ordner finden. Du kannst auch mal via Win+R ein RSOP.MSC aufrufen. Usereinstellungen reichen an der Stelle.

@casi4712 Wie genau lautet die Anforderung, die Du bekommen hast? Nicht deine Batch, sondern die Anforderung für diese Aufgabe. Möglicherweise lässt sich das viel einfacher lösen, wenn man die Anforderung kennen würde. Am AD kann man alle Rechner einfach per PS auslesen und mit diesen Namen arbeiten, dafür muss ich mich nicht über eine IP-Range mit allen Rechnern verbinden.

Da muss es auch einen Name des GPO geben, in dem Du die Software Installation findest. Die Meldung ist recht eindeutig, das MSI bzw. die Software ist nicht mehr an der Stelle, auf die im GPO verwiesen wird.

Also wird die Software unter Benutzern installiert, nicht beim Start des Rechners, sondern erst NACH der Anmeldung. Ist das so richtig? Falls ja, solltest Du das mit Hilfe von GPRESULT /H GPRESULT.HTML in einer Commandline herausbekommen. Schau dir das HTML an.

Es gibt doch Logdateien für fehlgeschlagenen Upgrades, danach suchen und lesen, dann solltest Du Details finden. Grundsätzlich gilt: BIOS aktualisieren, Treiber manuell aktualisieren, sauberen Reboot und erneut probieren.

GPEDIT.MSC ausführen und dort nachsehen. Sind Tools vom Hersteller des Rechners installiert? Falls ja, dort mal nachschauen.

Funktioniert es denn, wenn Du ein neues Outlook Profil anlegst?

Es gibt hier im Forum ein Script für das Automatische Genehmigen von Updates für bestimmte Gruppen. Hat AFAIR Dukel gepostet, am besten danach suchen und testen.

Das wird dir vermutlich nichts bringen, aber das siehst Du dann schon. :)

Du darfst hier und drüben (wsus.de) übrigens auf den jeweils anderen Thread hinweisen, Danke.

Wie genau lautet die Build? Hier wird die richtige Build angezeigt: Wen hier wirklich die von dir gen. Build angezeigt wird, den Server unbedingt aktualisieren. Kannst Du auch Online aktualisieren lassen. Bekommen denn die W2016er Server auch das GPO? Liegt der Eintrag für den WSUS an der richtigen Stelle? Kommt kein einziger W2016 in den WSUS? Findest Du Fehlermeldungen in der %windir%\windowsupdate.log auf den W2016er Servern? Die Log muss zuerst per Powershell erzeugt werden.

Hat die unbekannt SW-Verteilung einen Kiosk Modus? Falls ja, dann dort die SW veröffentlichen.

Wir haben eine Softwareverteilung im Einsatz, damit ist das alles kein Problem. Wenn Du die Installation angepasst hast, dann mach es wie vorgeschlagen mit einer geplanten Aufgabe.

Bei uns und bei Millionen anderer Admins funktioniert es wie es soll. Also ist bei dir irgendetwas nicht in Ordnung. Zu 99,99% hat sich bei Threads zu diesem Thema hier im Forum rausgestellt, dass eine Konfiguration vor Ort schuld für das Verhalten war. Ist auf der OU die Vererbung von GPOs unterbrochen? OU löschen und neu anlegen wäre noch eine Möglichkeit. RSOP.MSC zeigt auch als Admin nicht die Computerkonfig an, deshalb GPRESULT auf der Commandozeile verwenden.

Versionsnummer einer Datei zum Beispiel. Alternative: Via GPP eine Geplante Aufgabe anlegen, die einfach den o.g. Pfad aufruft. WMI-Filter für das GPO anlegen so dass nur Clients das GPO übernehmen, die auch in das Raster passen. BTW: Weshalb gibst Du das Upgrade nicht auf dem WSUS einfach für die betroffenen Clients frei? Das sollte ohne irgendwelche Klimmzüge funktionieren.

Das blöde an der Installation aus dem Netzwerk ist auch die Tatsache, dass im Fall eines Falles der User als Ausführender des Programmes später keinen Zugriff auf den UNC Pfad hat. Deshalb, wie Nils schrub, ist es besser die SW vorher auf den Client zu kopieren, ein Verzeichnis c:\_Install bietet sich dafür an, und dann daraus installieren. Dazu braucht man auch nicht vor Ort sein, per RDP direkt oder auch via Remoteunterstützung auf den Client verbinden, fertig. EDIT: Auch für schnelle Installationen eignet sich der WSUS Package Publisher in Kombination mit dem WSUS.

Die sind in den Authentifizierten Benutzern enthalten. @hwimmer Wie oft hast Du den Rechner schon neu gestartet? Bist Du sicher dass das Computerobjekt in der OU liegt, auf die das GPO verlinkt ist? Einfach mal ein gpupdate und anschließend neu starten.

Wenn nach dem ersten Versuch kein weiterer unternommen wird, sind die Regeln noch nicht passend. Manchmal muss man verschiedene Ansätze ausprobieren.

Nochmal Leserechte alleine reichen nicht, wenn ein Computer Einstellungen übernehmen soll, muss er neben lesen auch übernehmen dürfen. Das sind zwei verschiedene Rechte!

Wie sehen die exakten Freigabe- und NTFS-Einstellungen der Freigabe aus? Wenn der Job vom WU-Agent ausgeführt wird, müssen die Authentifizierten Benutzer, dort sind auch Computerkonten enthalten, Leserechte auf die Freigabe haben. Ansonsten erfolgt kein Zugriff. BTW: Wie genau sehen denn die beiden Regeln für dieses Custom Update in Bezug auf kann oder ist installiert aus?

Falls Du einen SQL Server tunen willst, dann hol dir einen Spezialisten ins Haus. Der kann möglicherweise viel erreichen und du lernst auch noch etwas dabei. Alles andere kann einfach nach hinten losgehen.

Das ist so nicht richtig. Natürlich übernehmen W10 Computer auch die GPO-Einstellungen für Computer, dazu muss ein Computer auch die GPO lesen und *übernehmen* dürfen. Lies doch diesen Artikel mal langsam und in Ruhe: https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/ D.h. in deinem Fall müssen die Authentifizierten Benutzer, dazu zählen übrigens auch die Computerkonten, das GPO lesen und übernehmen dürfen.

Eine Autorun.inf kann natürlich ein Sicherheitsrisiko darstellen, sehr pauschal ausgedrückt.

Wenn es ein Domain Account ist, einfach das lokale Benutzerprofil löschen und nach einem Neustart den Benutzer neu anmelden lassen.

Und was genau hast Du im GPO eingestellt? Was sagt GPRESULT auf dem Client?