Sunny61

EDIT: Es gibt auch einen KB-Artikel dazu: https://support.microsoft.com/en-us/kb/2811566 Dann kopier doch mal den MSSQLSERVER alleine rein.

Copy und Paste, dann funktioniert das.

Sorry, aber das ist Quatsch. Wie soll das funktionieren? Bist Du sicher dass auf diesem betroffenen Client auch der richtige WSUS eingetragen ist? Wenn ja, hast Du vermutlich den BITS per GPO begrenzt und weißt es nicht mehr. Ist denn das Update schon auf dem Downstream WSUS angekommen? Was sagt der Downloadstatus auf der Startseite vom Downstream-WSUS? Wenn der Downstream WSUS den Mainstream WSUS als Updatequelle eingetragen hat, dann muss das so sein. BTW: Der Downstream *holt* sich die Daten vom Mainstream, nicht umgekehrt.

Jepp, gib dem Benutzer der den SQL Server Dienst ausführt, auf dieses Verzeichnis die passenden NTFS-Berechtigungen: C:\Windows\system32\LogFiles\Sum Hatte ich kürzlich auch bei einem SQL Server 2012.

Es reicht vollkommen aus auf dem Mainstream WSUS den WPP zu installieren, die Updates aus dem WPP werden natürlich vom Downstream-WSUS geholt und den Clients zur Verfügung gestellt. Vermutlich 'siehst' Du die Updates nicht auf dem Downstream-WSUS. Das macht aber nichts, die Clients holen sich die Updates und installieren sie.

Das ist im Handling aber nicht so einfach als mit Uninstall2Install. Steht auch so im HowTo zu Uninstall2Install. Hatte ich so noch nie, würde mich nicht wundern wenn dir irgendetwas schief gegangen wäre. Waren das alle Rechner oder nur einer? Auch wenn es alle wären, so lange ich mit Uninstall2Install alles erschlage, juckt mich der Eintrag in Programme und Features nicht. Setz dich hin, erstell ein Update mit Hilfe von Uninstall2Install und teste es. Achte aber unbedingt auch auf die passenden Regeln im WPP, dann läuft das ohne Probleme.

Liegt denn das Computerobjekt auch im Verwaltungsbereich des GPO? Zeichne das doch mal kurz auf bitte. Hast du den Server nach der Aufnahme in die neue Gruppe auch mal neu gestartet?

Erspar dir das Benutzerdefinierte Update im WPP und nimm Uninstall2Install: http://www.wsus.de/uninstall2install Erleichtert die Arbeit mit der Installation von Java ungemein.

Erstell doch bitte einen neuen eigenen Thread dafür. Und ja, das zur Verfügung stellen von Java 8 Update 51 funktionierte bei uns einwandfrei. 115 Computer haben seit Veröffentlichung am 15.07.2015 das Update fehlerfrei installiert.

Kopiere die Bilder in ein lokales Laufwerk und weise den Pfad per GPO zu.

Stimmt, Danke für den Hinweis. Hab ich jetzt im besagten Thread auch gepostet. ;)

Naja, wenn es so scheint, dann kannst Du sicherlich scheinbar die SUSDB wieder retour kopieren, oder nicht? Und Du hast scheinbar ein SQL Server Management Studio installiert, wenn ja, dann mach das einfach wieder rückgängig, oder geht das scheinbar nicht? Scheinbar hast Du den Artikel nicht gelesen, das ist kein Workaround sondern ein von MS empfohlener Weg den WSUS auf einem SBS wieder ordentlich ins System zu bringen. EDIT: Diesen Text hab ich gestern im falschen Thread gepostet, deshalb nochmal hier: In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup kannst Du nachsehen, wo der WSUS das Contentverzeichnis erwartet. Notfalls einfach wieder retour das ganze. Und wenn Du dich mit Hilfe ein SQL Server Management Studios auf die DB verbindest, kannst Du ja auch dieses Script ausführen: http://www.wsus.de/a...ternal_database Du kannst übrigens ein aktuelles SQL Server Management Studio verwenden, es muss kein 'altes' sein. Und in diesem Howto ist beschrieben, wie man die SUSDB verschiebt. Die ist im allgemeinen aber recht klein, die kannst Du eigentlich auf C:\ liegen lassen.

Die RUs kommen über den WSUS rein, dann vermutlich auch über Windows Update. ;)

In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup kannst Du nachsehen, wo der WSUS das Contentverzeichnis erwartet. Notfalls einfach wieder retour das ganze. Und wenn Du dich mit Hilfe ein SQL Server Management Studios auf die DB verbindest, kannst Du ja auch dieses Script ausführen: http://www.wsus.de/ausfuehren_eines_scripts_auf_der_windows_internal_database Du kannst übrigens ein aktuelles SQL Server Management Studio verwenden, es muss kein 'altes' sein. Und in diesem Howto ist beschrieben, wie man die SUSDB verschiebt. Die ist im allgemeinen aber recht klein, die kannst Du eigentlich auf C:\ liegen lassen. Ist hier im falschen Thread gelandet. ;)

Ist das ein Öffentliches Netzwerk im Netzwerk- und Freigabecenter oder ein privates Netzwerk? EDIT: Dann zeig doch mal ein ipconfig /all vom Problemclient wenn er per WLAN verbunden ist, und von einem funtionierenden Client. Aber bitte keine Screenshots davon posten, sondern richtig machen. In einer Commandline ein ipconfig /all | clip [ENTER] und dann hier in einen Code-Tag einfügen, Danke.

Gibt es denn in der %programfiles%\Update Services\LogFiles\SoftwareDistribution irgendwelche genaueren Fehlermeldungen? Nach welchen Anleitungen hast Du denn genau was alles verschoben?

Sind die Treiber auch aktuell? Nicht einfach nur ja schreiben, sondern unbedingt manuell auf der Website der NIC-Hersteller überprüfen. Gibt es denn Fehlermeldungen im Ereignisprotokoll? Welches Netzwerk wird denn im Netzwerk- und Freigabecenter angezeigt, wenn Du dich via WLAN verbunden hast? Bekommst Du denn überhaupt eine IP-Adresse aus eurem LAN?

Und weshalb wird das Programm nicht auf jedem Client installiert? Und warum hilft euch der Support des Herstellers nicht? Die verkaufen das Programm und müssen wissen was man machen kann. Ist die Version vom verwendete Programm evtl. nicht für W7 freigegeben?

Evtl. hilft dir der Artikel von Bent: http://bent-blog.de/wsus-fehler-bei-der-synchronisierung-fehler-0x80072f8f-bei-windows-update/ EDIT: Soll der Server direkt auf Windows Update zugreifen oder auf einen WSUS im Haus?

Nimm den FixIt und probier anschließend das Update manuell zu installieren.

Probier doch einfach die als Antwort markierten Vorschläge: https://social.technet.microsoft.com/Forums/windows/en-US/53a1f2ab-037b-438e-a690-00a0e745730d/windows-7-update-error-0x80070057?forum=w7itprogeneral

Dann prüf doch über OWA nach ob der Ordner noch da ist. Hat der Benutzer mehrer Postfächer in seinem Outlook? Wenn ja, dort auch gleich den Ordner suchen lassen.

Inplace wäre und ist für mich keine Option. Der große Nachteil, Du nimmst alles (alle Fehler) mit. Wenn es unbedingt die gleiche IP und der gleiche Name sein muss, dann kann man das so machen wie Du vorgeschlagen hast. Nach Namens- und IP-Änderungen sollte man ruhig DNS und alles mögliche andere manuell kontrollieren und nicht zu ungeduldig sein. ;)

In diesem Fall ist das sicherlich vom Entwickler so eingebaut worden, möglicherweise gibt es eine Stored Procedure oder eine Function in der Du Hinweis fidnest. Aber ohne Quellcode ist das natürlich ganz schlecht und schwer. Und so wie es aussieht, wohl auch kein Interesse sich damit zu beschäftigen, anders deute ich deine Antwort nicht. Nein, aber das nicht updaten rächt sich nun.

Und was hast Du geändert? Nichts, ist die falsche Antwort.