none
Windows 10 Anniversary Update per WSUS RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich habe leider ein kleines Problem beim verteilen des Funktionsupdates 1607 über den WSUS und ich hoffe ihr könnt mir helfen.

    Was habe ich gemacht/Ausgangssituation:

    1. Synchronisieren des Funktionsupdates
    2. Genehmigen des Updates für die EDV-Abteilung
    3. Installation auf verschiedenen Rechnern innerhalb der EDV Abteilung durchgeführt.
    4. Zum Einsatz kommt WSUS 6.3 auf Windows Server 2012 R2
    5. Client ist Windows 10 Pro 1511

    Das Problem: 

    Auf einem Rechner wird das Funktionsupdate angezeigt aber nicht heruntergeladen. Es steht die ganze zeit bei 0%. Vorher hat dieser aber schon ein Update vom WSUS installiert. Auf allen anderen Rechnern hat das Funktionsupdate Problemlos funktioniert.

    Jetzt zu den Unterschieden die auf dem Rechner herrschen: Der Rechner ist in einer anderen Domäne als die anderen EDV Rechner und der WSUS. Außerdem wurde dieser Rechner erst vor kurzem zum WSUS hinzugefügt.  Der Rechner meldet aber ohne Probleme seinen Status.

    Im Windows Update sieht das folgendermaßen aus:

    Bisher unternommen zur Problemlösung:

    • Zurücksetzen von Windows Update (inkl. Löschung des Software Distribution Ordners usw.) mit dem Reset Windows Update Tool hier aus dem Technet und einmal Manuell
    • Überprüfen ob das Update für den WSUS für die .esd Decryption installiert ist und ob der MIME-Typ .esd im IIS gesetzt ist (ist es)
    • Mehrere Neustarts von Client und WSUS
    • Client an ein anderes Subnetz angeschlossen. (An dem das Downloaden auf jeden Fall funktioniert hat.)

    Ich hoffe ich habe keine Informationen vergessen, falls doch reiche ich die gerne nach.

    Mit freundlichen Grüßen Logibooze


    • Bearbeitet Logibooze Freitag, 9. September 2016 13:59 Grußformel war doppelt
    Freitag, 9. September 2016 13:56
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Am 09.09.2016 schrieb Logibooze:

    ich habe leider ein kleines Problem beim verteilen des Funktionsupdates 1607 über den WSUS und ich hoffe ihr könnt mir helfen.

    /Klugscheissmodus an
    Der WSUS verteilt nichts, der stellt nur zur Verfügung. Der Client
    holt das Upgrade.
    /Klugscheissmodus aus

    Was habe ich gemacht/Ausgangssituation:

    1. Synchronisieren des Funktionsupdates
    2. Genehmigen des Updates für die EDV-Abteilung
    3. Installation auf verschiedenen Rechnern innerhalb der EDV Abteilung    durchgeführt.
    4. Zum Einsatz kommt WSUS 6.3 auf Windows Server 2012 R2

    Welche genau Build hat der WSUS? Hier findest Du den exakten Ort der
    Build: http://www.wsus.de/images/wsus-version.png

    5. Client ist Windows 10 Pro 1511

    Das Problem: 

    Auf einem Rechner wird das Funktionsupdate angezeigt aber nicht heruntergeladen. Es steht die ganze zeit bei 0%. Vorher hat dieser aber schon ein Update vom WSUS installiert. Auf allen anderen Rechnern hat das Funktionsupdate Problemlos funktioniert.

    Haben alle anderen Rechner auch das 1607 vom WSUS bekommen? In welcher
    Gruppe ist der WSUS? Ist für diese Gruppe das Upgrade auch
    freigegeben? Schau doch auf dem WSUS mal in die 'Nicht genehmigten
    Updates'. Findet sich auf der Startseite vom WSUS:
    http://www.wsus.de/images/wsus-version.png Nicht dass der Rechner eine
    andere Version/Edition anfordert.

    Jetzt zu den Unterschieden die auf dem Rechner herrschen: Der Rechner ist in einer anderen Domäne als die anderen EDV Rechner und der WSUS. Außerdem wurde dieser Rechner erst vor kurzem zum WSUS hinzugefügt.  Der Rechner meldet aber ohne Probleme seinen Status.

    Hmm, könnte natürlich sein, mit anderer Domain hatte ich noch nicht.
    Nur mit Arbeitsgruppe.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Freitag, 9. September 2016 14:27
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Am 09.09.2016 schrieb Logibooze:

    ich habe leider ein kleines Problem beim verteilen des Funktionsupdates 1607 über den WSUS und ich hoffe ihr könnt mir helfen.

    /Klugscheissmodus an
    Der WSUS verteilt nichts, der stellt nur zur Verfügung. Der Client
    holt das Upgrade.
    /Klugscheissmodus aus

    Was habe ich gemacht/Ausgangssituation:

    1. Synchronisieren des Funktionsupdates
    2. Genehmigen des Updates für die EDV-Abteilung
    3. Installation auf verschiedenen Rechnern innerhalb der EDV Abteilung    durchgeführt.
    4. Zum Einsatz kommt WSUS 6.3 auf Windows Server 2012 R2

    Welche genau Build hat der WSUS? Hier findest Du den exakten Ort der
    Build: http://www.wsus.de/images/wsus-version.png

    5. Client ist Windows 10 Pro 1511

    Das Problem: 

    Auf einem Rechner wird das Funktionsupdate angezeigt aber nicht heruntergeladen. Es steht die ganze zeit bei 0%. Vorher hat dieser aber schon ein Update vom WSUS installiert. Auf allen anderen Rechnern hat das Funktionsupdate Problemlos funktioniert.

    Haben alle anderen Rechner auch das 1607 vom WSUS bekommen? In welcher
    Gruppe ist der WSUS? Ist für diese Gruppe das Upgrade auch
    freigegeben? Schau doch auf dem WSUS mal in die 'Nicht genehmigten
    Updates'. Findet sich auf der Startseite vom WSUS:
    http://www.wsus.de/images/wsus-version.png Nicht dass der Rechner eine
    andere Version/Edition anfordert.

    Jetzt zu den Unterschieden die auf dem Rechner herrschen: Der Rechner ist in einer anderen Domäne als die anderen EDV Rechner und der WSUS. Außerdem wurde dieser Rechner erst vor kurzem zum WSUS hinzugefügt.  Der Rechner meldet aber ohne Probleme seinen Status.

    Hmm, könnte natürlich sein, mit anderer Domain hatte ich noch nicht.
    Nur mit Arbeitsgruppe.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Freitag, 9. September 2016 14:27
    |
  • Question
    Anmelden
    0
    Anmelden

    /Klugscheissmodus an

    Der WSUS verteilt nichts, der stellt nur zur Verfügung. Der Client holt das Upgrade.

    /Klugscheissmodus aus

    Das ist mir natürlich klar....Habe mich nur falsch ausgedrückt ^^

    Welche genau Build hat der WSUS?

    6.3.9600.18324

    Haben alle anderen Rechner auch das 1607 vom WSUS bekommen?

    Ja

    In welcher Gruppe ist der WSUS?

    In einer Eigenen für die Server.

    Ist für diese Gruppe das Upgrade auch freigegeben?

    Für die Servergruppe natürlich nicht. Warum sollte es auch die Server brauchen ja kein Anniversary Update.

    Für die EDV Gruppe in der sich der Client befindet, ist das Upgrade natürlich genehmigt sonst hätten es die anderen Clients ja nicht gezogen. Außerdem würde Der Client, der es nicht herunterlädt, nicht finden.

    Schau doch auf dem WSUS mal in die 'Nicht genehmigten Updates'

    Der Rechner erfordert keine Andere Version sondern genau die, die auch genehmigt ist.

    Hmm, könnte natürlich sein, mit anderer Domain hatte ich noch nicht. Nur mit Arbeitsgruppe.

    Das war auch erst meine Vermutung. Aber als ich danach im Internet auf die Suche gegangen bin hieß es nur , dass WSUS ohne Probleme Domänenübergreifend arbeitet. Ich meine der Rechner hat ja vor dem Anniversary Update auch schon ein anderes Update vom WSUS geladen und installiert. Ich vermute es liegt direkt am Anniversary Update. Kenne allerdings nicht das genau Problem geschweige denn eine Lösung(deswegen der Beitrag hier)

    Mit freundlichen Grüßen Logibooze

    Freitag, 9. September 2016 14:54
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Logibooze,

    das "Funktinosupdate" hat bei mir genau das gleiche Problem verursacht. Hatte leider aber nur einen Client zum Testen und bei dem das nicht ging. Bei mir ist der Rechner in der gleichen Domäne wie der WSUS. 

    Meine Vermutung bis gerade eben war, dass es eventuell an eine fehlenden Zuordnung des MIME-Typs im IIS liegt:
    https://social.technet.microsoft.com/Forums/office/en-US/d7dbb851-4e3a-41d9-9072-1f16d7b1bc1e/fix-domain-windows-10-wsus-upgrade-issues-file-not-found?forum=winserverwsus

    Aber nachdem das Upgrade bei dir auf anderen Clients angeblich geklappt hat, scheinst du ja nicht davon betroffen zu sein!?! Hast du die von mir genannte Anpassung am WSUS überhaupt vorgenommen oder ging es ohne?

    Ansonsten würde ich, wenn das Upgrade sonst reibungslos geklappt hat, und es nur um einen Rechner geht, das Ding ohne WSUS durchziehen:

    https://support.microsoft.com/en-us/help/12387/windows-10-update-history

    Grüße

    willy



    Freitag, 9. September 2016 16:10
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Logibooze,

    das "Funktinosupdate" hat bei mir genau das gleiche Problem verursacht. Hatte leider aber nur einen Client zum Testen und bei dem das nicht ging. Bei mir ist der Rechner in der gleichen Domäne wie der WSUS. 

    Meine Vermutung bis gerade eben war, dass es eventuell an eine fehlenden Zuordnung des MIME-Typs im IIS liegt:
    https://social.technet.microsoft.com/Forums/office/en-US/d7dbb851-4e3a-41d9-9072-1f16d7b1bc1e/fix-domain-windows-10-wsus-upgrade-issues-file-not-found?forum=winserverwsus

    Aber nachdem das Upgrade bei dir auf anderen Clients angeblich geklappt hat, scheinst du ja nicht davon betroffen zu sein!?! Hast du die von mir genannte Anpassung am WSUS überhaupt vorgenommen oder ging es ohne?

    Ansonsten würde ich, wenn das Upgrade sonst reibungslos geklappt hat, und es nur um einen Rechner geht, das Ding ohne WSUS durchziehen:

    https://support.microsoft.com/en-us/help/12387/windows-10-update-history

    Grüße

    willy



    Hallo willy,

    ja diese Anpassungen die du da geschrieben hast habe ich bereits vorher auch gemacht. Habe ich oben aber auch geschrieben. (Vielleicht ein wenig undeutlich). Also diese Einstellungen hatte ich noch vor dem Upgrade von Win 7 auf 10 vorgenommen, da ich schon zu dieser Zeit von dem Problem/der Einstellung gelesen habe.

    Und ich möchte ungern dieses Update erneut bzw. für diesen Rechner extra machen aus drei Gründen:

    1. Unsere Firmenleitung ist sagen wir mal bescheiden. Mit dem Update würde ich für mehrere Stunden die Leitung dicht machen, und die ganz Firma könnte nicht mehr arbeiten.

    2. Müssen dieses Update ja noch alle anderen 100 Rechner kriegen(nicht nur die in der EDV) und wenn da dieses Problem auftritt kenne ich dann wenigstens die Lösung. Muss nicht passieren kann aber sein, dass ich dann plötzlich 20 Rechner habe die das Update so nicht ziehen wollen.

    3. Muss dass ja eigentlich funktionieren.

    Mit freundlichen Grüßen Logibooze

    Freitag, 9. September 2016 18:14
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin Logibooze,

    wenn du das Update an noch ca. 100 Rechnern nachholen musst, ist es natürlich schlecht, wenn man probiert die Dinger einzeln mit der von mir vorgeschlagenen Methode zu patchen. Vergiss meinen Vorschlag am besten wieder. ;)

    Eine konkrete Antwort kann ich dir zwar auch nicht geben. Mich würde aber interessieren zu welchem Anteil das Update dann erfolgreich war. Wenn 100 Rechner das Upgrade nicht bekommen haben, wie viele haben es dann bekommen?

    Grüße

    willy

    Freitag, 9. September 2016 19:53
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 09.09.2016 schrieb Logibooze:

    In welcher Gruppe ist der WSUS?

    In einer Eigenen für die Server.


    Ist für diese Gruppe das Upgrade auch freigegeben?

    Für die Servergruppe natürlich nicht. Warum sollte es auch die Server brauchen ja kein Anniversary Update.

    Entschuldige, mein Fehler. ;)

    Für die EDV Gruppe in der sich der Client befindet, ist das Upgrade natürlich genehmigt sonst hätten es die anderen Clients ja nicht gezogen. Außerdem würde Der Client, der es nicht herunterlädt, nicht finden.

    Finden sich Fehlermeldungen in der %windir%\WindowsUpdate.log auf dem
    Client?

    Hmm, könnte natürlich sein, mit anderer Domain hatte ich noch nicht. Nur mit Arbeitsgruppe.

    Das war auch erst meine Vermutung. Aber als ich danach im Internet auf die Suche gegangen bin hieß es nur , dass WSUS ohne Probleme Domänenübergreifend arbeitet.

    Ja, zu dem Zeitpunkt gab es noch kein W10 und keine Upgrades über den
    WSUS.

    Ich meine der Rechner hat ja vor dem Anniversary Update auch schon ein anderes Update vom WSUS geladen und installiert. Ich vermute es liegt direkt am Anniversary Update. Kenne allerdings nicht das genau Problem geschweige denn eine Lösung(deswegen der Beitrag hier)

    Update oder Upgrade?

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Freitag, 9. September 2016 20:20
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 09.09.2016 schrieb Logibooze:

    Und ich möchte ungern dieses Update erneut bzw. für diesen Rechner extra machen aus drei Gründen:

    1. Unsere Firmenleitung ist sagen wir mal bescheiden. Mit dem Update würde ich

    Lass das mal nicht die richtigen Leute lesen. :)

    für mehrere Stunden die Leitung dicht machen, und die ganz Firma könnte nicht mehr arbeiten.

    Ohne Internet kann deine Firma nicht arbeiten? Wenn das so ist, wäre
    es u.a. an der Zeit hier anzusetzen. Wenn dann ein unwichtiges Upgrade
    die Firma lahmlegen kann, stimmt etwas ganz grundsätzliches nicht.

    2. Müssen dieses Update ja noch alle anderen 100 Rechner kriegen(nicht nur die

    Du kannst natürlich bei Mark abschauen:
    http://www.gruppenrichtlinien.de/artikel/windows-10-inplace-update-per-wsus-verteilen/

    in der EDV) und wenn da dieses Problem auftritt kenne ich dann wenigstens die Lösung. Muss nicht passieren kann aber sein, dass ich dann plötzlich 20 Rechner habe die das Update so nicht ziehen wollen.

    3. Muss dass ja eigentlich funktionieren.

    Eigentlich ja, aber uneigentlich muss gar nichts funktionieren. Mit
    dem Upgrade 1607 hat MSFT einen richtig großen Wurft gelandet,
    allerdings ein Wurf ins Abseits.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Freitag, 9. September 2016 20:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin Logibooze,

    wenn du das Update an noch ca. 100 Rechnern nachholen musst, ist es natürlich schlecht, wenn man probiert die Dinger einzeln mit der von mir vorgeschlagenen Methode zu patchen. Vergiss meinen Vorschlag am besten wieder. ;)

    Eine konkrete Antwort kann ich dir zwar auch nicht geben. Mich würde aber interessieren zu welchem Anteil das Update dann erfolgreich war. Wenn 100 Rechner das Upgrade nicht bekommen haben, wie viele haben es dann bekommen?

    Grüße

    willy

    Ja also wie gesagt bisher habe ich das Update nur für die EDV Abteilung genehmigt. Und dort haben es 8 von 9 Rechner installiert.

    Mit freundlichen Grüßen Logibooze

    Montag, 12. September 2016 06:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Das Grundsätzlich etwas nicht stimmt, ist richtig. Leider kann ich nichts daran ändern. Da Rede ich gegen eine wand.

    Der Rechner von dem ich sprach hat ein Update gezogen, für MS SQL oder so.

    Ich habe mir auf dem Client ein Windows Update.log generieren lassen mi Powershell konnte dort allerdings keine Fehlermeldungen finden.

    Wenn gewünscht kann ich das hier auch gerne einmal Posten.

    Mit freundlichen Grüßen Logibooze


    • Bearbeitet Logibooze Montag, 12. September 2016 07:09
    Montag, 12. September 2016 06:57
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ein Gedanke, der mir im Zusammenhang mit der Frage hier durch den Kopf ging ist der hier:

    http://www.gruppenrichtlinien.de/artikel/windows-10-inplace-update-per-wsus-verteilen/

    Warum es dann nicht so machen, wenn es über den WSUS direkt nicht klappt? Ist zwar nicht meine Idee, aber vielleicht einen Versuch wert.

    @Winfried:
    Bei Windows 10 (spätestens) findet man im "WindowsUpdate.log" nichts mehr, außer dem Hinweis, der auf eine weiterführende Website von MS führt. Dort wird meine ich empfohlen "get-WindowsUpdateLog" in einer Powershell auszuführen.

    Außerdem müssten die Verantwortlichen wohl fähig sein einen Internetbrowser zu bedienen, um die "Schmähkritik" vom TE lesen zu können. Ich für meinen Teil bezweifel das gerade mal sehr.... Zurück zum Thema. :)

    Grüße

    willy

    Montag, 12. September 2016 17:24
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 12.09.2016 schrieb willy-goergen:

    ein Gedanke, der mir im Zusammenhang mit der Frage hier durch den Kopf ging ist der hier:

    http://www.gruppenrichtlinien.de/artikel/windows-10-inplace-update-per-wsus-verteilen/

    Warum es dann nicht so machen, wenn es über den WSUS direkt nicht klappt? Ist zwar nicht meine Idee, aber vielleicht einen Versuch wert.

    In einem anderen Thread wurde ja schon festgestellt dass es an einer
    Einstellung in einem GPO liegt. Wozu dann also 'basteln', wenn es
    richtig geht?

    @Winfried:
    Bei Windows 10 (spätestens) findet man im "WindowsUpdate.log" nichts mehr, außer dem Hinweis, der auf eine weiterführende Website von MS führt. Dort wird meine ich empfohlen "get-WindowsUpdateLog" in einer Powershell auszuführen.

    Ich weiß, das sollte man ja auch machen können, oder nicht?

    Außerdem müssten die Verantwortlichen wohl fähig sein einen Internetbrowser zu bedienen, um die "Schmähkritik" vom TE lesen zu können. Ich für meinen Teil bezweifel das gerade mal sehr.... Zurück zum Thema. :)

    Welche Verantwortlichen meinst Du? MSFT? Wenn ja, die lesen ganz
    sicher im englischen Forum mit. Die Kritik an 1607 ist ganz sicher
    angekommen.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Montag, 12. September 2016 20:15
    |
  • Question
    Anmelden
    0
    Anmelden
    In einem anderen Thread wurde ja schon festgestellt dass es an einer Einstellung in einem GPO liegt. Wozu dann also 'basteln', wenn es richtig geht?
    Habe ich das jetzt irgendwie falsch verstanden? Das Problem was ich habe liegt also an einer Einstellung in einem GPO?

    Mit freundlichen Grüßen Logibooze

    Dienstag, 13. September 2016 06:24
    |
  • Question
    Anmelden
    0
    Anmelden

    Guten Morgen Logibooze,

    Winfried meint glaube ich dieses GPO:
    DisableOSUpgrade

    Es hat sich wohl herausgestellt, dass das 1607 Upgrade nur angefordert wird, wenn der Wert auf "Disabled" gesetzt ist.

    Gruß TechnikSC885


    PS:
    siehe z.B. hier https://social.technet.microsoft.com/Forums/de-DE/fa75ffb7-cad9-4dc5-8aaa-656d92af7f3e/windows-10-1511-clients-fordern-upgrade-auf-1607-von-wsus-nicht-an?forum=win10itprogeneralDE
    • Bearbeitet TechnikSC885 Dienstag, 13. September 2016 06:46 PS:
    Dienstag, 13. September 2016 06:43
    |
  • Question
    Anmelden
    0
    Anmelden

    Guten Morgen Logibooze,

    Winfried meint glaube ich dieses GPO:
    DisableOSUpgrade

    Es hat sich wohl herausgestellt, dass das 1607 Upgrade nur angefordert wird, wenn der Wert auf "Disabled" gesetzt ist.

    Gruß TechnikSC885


    PS:
    siehe z.B. hier https://social.technet.microsoft.com/Forums/de-DE/fa75ffb7-cad9-4dc5-8aaa-656d92af7f3e/windows-10-1511-clients-fordern-upgrade-auf-1607-von-wsus-nicht-an?forum=win10itprogeneralDE
    Hmmm.... netter Ansatz, aber leider nicht die Lösung für mein Problem. Die Richtlinie ist gar nicht konfiguriert und wenn diese nicht konfiguriert ist ist es als wäre die Richtlinie deaktiviert. Auch der Registry Key ist nicht gesetzt auf dem Client.

    Mit freundlichen Grüßen Logibooze

    Dienstag, 13. September 2016 07:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Die Richtlinie ist gar nicht konfiguriert und wenn diese nicht konfiguriert ist ist es als wäre die Richtlinie deaktiviert. Auch der Registry Key ist nicht gesetzt auf dem Client.

    Hast du's - spasseshalber mal mit dem GPO versucht?
    Afair gibt es sehr wohl einen Unterschied zwischen "nicht konfiguriert" und "deaktiviert".

    Gruß TechnikSC885

    Dienstag, 13. September 2016 07:36
    |
  • Question
    Anmelden
    0
    Anmelden


    Hast du's - spasseshalber mal mit dem GPO versucht?
    Afair gibt es sehr wohl einen Unterschied zwischen "nicht konfiguriert" und "deaktiviert".

    Gruß TechnikSC885

    So habe ich jetzt gemacht. Leider keine Veränderung der Situation. Update wird angezeigt aber nicht heruntergeladen.

    Mit freundlichen Grüßen Logibooze

    Dienstag, 13. September 2016 08:05
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 13.09.2016 schrieb Logibooze:

    In einem anderen Thread wurde ja schon festgestellt dass es an einer Einstellung in einem GPO liegt. Wozu dann also 'basteln', wenn es richtig geht?

    Habe ich das jetzt irgendwie falsch verstanden? Das Problem was ich habe liegt also an einer Einstellung in einem GPO?

    In diesem Thread ist die Lösung:
    https://social.technet.microsoft.com/Forums/de-DE/fa75ffb7-cad9-4dc5-8aaa-656d92af7f3e/windows-10-1511-clients-fordern-upgrade-auf-1607-von-wsus-nicht-an?forum=win10itprogeneralDE#fa75ffb7-cad9-4dc5-8aaa-656d92af7f3e

    Anschließend per gpupdate /target:computer den Client die
    Einstellungen übernehmen lassen. Neustart und prüfen ob die
    Einstellungen auch auf dem Client in der Registry angekommen sind.
    Wenn ja, dann kannst Du auf dem Client jetzt auch nach Updates suchen
    lassen.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Dienstag, 13. September 2016 16:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Wenn du die Gruppenrichtlinienergebnisse von dem betroffenen Client anforderst, finden sich da bei den Administrativen Vorlagen Einträge unter dem Punkt:

    "Zusätzliche Reg. -einst." ,die Windows Update betreffen?

    Wenn ja sollte dieses Problem zunächst aufgelöst werden da es Policity Konflikte verursachen kann.

     
    Mittwoch, 14. September 2016 07:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Wenn du die Gruppenrichtlinienergebnisse von dem betroffenen Client anforderst, finden sich da bei den Administrativen Vorlagen Einträge unter dem Punkt:

    "Zusätzliche Reg. -einst." ,die Windows Update betreffen?

    Wenn ja sollte dieses Problem zunächst aufgelöst werden da es Policity Konflikte verursachen kann.

     
    Hallo, nein wenn ich die Gruppenrichtlinienergebnisse anzeigen lasse, ist so eine Einstellung nicht vorgenommen

    Mit freundlichen Grüßen Logibooze

    Mittwoch, 14. September 2016 13:44
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi,
     
    Am 14.09.2016 um 09:17 schrieb Pö:
    > "Zusätzliche Reg. -einst." ,die Windows Update betreffen?
     
    Nein, dann fehlen dir die aktuellen/passenden ADMx Templates
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Mittwoch, 14. September 2016 16:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Es hat sich wohl herausgestellt, dass das 1607 Upgrade nur angefordert wird, wenn der Wert auf "Disabled" gesetzt ist.

    Disabled (dword:0) oder eben gar nicht vorhanden.

    Da der Client das Upgrade aber anfordert, aber bei 0% im Download stehen bleibt, ist das hier ein anderes Problem. Wenn der DisableOSUpgrade Eintrag gesetzt ist, kommt es garnicht erst zum Downloadversuch da das Upgrade nicht angefordert wird :)

    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    Mittwoch, 14. September 2016 20:23
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi,
     
    Am 14.09.2016 um 09:17 schrieb Pö:
    > "Zusätzliche Reg. -einst." ,die Windows Update betreffen?
     
    Nein, dann fehlen dir die aktuellen/passenden ADMx Templates
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Ich habe gesagt es sind keine gesetzt. Nicht das ich keine setzen kann. Dabei ging es bei der Frage auch nicht.

    Mit freundlichen Grüßen Logibooze

    Donnerstag, 15. September 2016 06:07
    |
  • Question
    Anmelden
    0
    Anmelden

    Es hat sich wohl herausgestellt, dass das 1607 Upgrade nur angefordert wird, wenn der Wert auf "Disabled" gesetzt ist.

    Disabled (dword:0) oder eben gar nicht vorhanden.

    Da der Client das Upgrade aber anfordert, aber bei 0% im Download stehen bleibt, ist das hier ein anderes Problem. Wenn der DisableOSUpgrade Eintrag gesetzt ist, kommt es garnicht erst zum Downloadversuch da das Upgrade nicht angefordert wird :)

    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    richtig.

    Bisher habe ich leider noch keine Lösung gefunden. So langsam gehen mir auch selber die Ideen aus.

    Ich hatte jetzt noch versucht den Registry Eintrag HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Windows / CurrentVersion / WindowsUpdate / OSUpgrade / AllowOSUpgrade zu setzen. Leider auch ohne erfolg.

    Mit freundlichen Grüßen Logibooze

    Donnerstag, 15. September 2016 06:11
    |
  • Question
    Anmelden
    0
    Anmelden
    Sehe es doch erstmal als Gnade an, dass das Upgrade noch nicht funktioniert hat.
    Donnerstag, 15. September 2016 06:11
    |
  • Question
    Anmelden
    0
    Anmelden
    Sehe es doch erstmal als Gnade an, dass das Upgrade noch nicht funktioniert hat.

    Hmmmm...... naja aber irgendwie stört es mich schon wie oft doch sachen bei MSFT nicht funktionieren.

    Es gab übrigens Heute wieder Updates für den Rechner, also Kumulative Updates und Office Updates usw. die alle ohne Probleme heruntergeladen und installiert wurden.

    Es liegt also direkt an dem Funktinosupdate.

    Mit freundlichen Grüßen Logibooze

    Donnerstag, 15. September 2016 07:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich habe leider ein kleines Problem beim verteilen des Funktionsupdates 1607 über den WSUS und ich hoffe ihr könnt mir helfen.


                

    Hallo,

    Fehler: RecoverCrypto: File is encrypted, but no key was provided. 0xc1800118

    Meine Win10 Clients sind erfolgreich upgraded 1607 (Server 2012 R2 - WSUS)

    Hab WSUS, WID, IIS neu installiert:

    Meine Schritte:

    • Uninstall Role "WSUS" and under Features "Windows Update Services Tools"
    • Open "SQL Server Management" and connect to "Windows Internal Database" and delete "SUSDB Database"
    • Uninstall Role "IIS" and Feature "Windows Process Activation Service", "Windows Internal Database"
    • Reboot
    • Delete Folder "WsusContont" and "UpdateServicesPackages"
    • Delete Folder "C:\Program Files\Update Services"
    • Delete or rename Folder "C:\Windows\WID"
    • Delete or rename Folder "C:\inetpub"
    • Delete key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services"
    • Install KB3095113 (if not installed previously)
    • Install KB3159706 (if not installed previously)
    • Reboot
    • Install Role "WSUS (with all the Components)" and Feature "HTTP Activation" under ".net Framework 4.5"
    • In Server Manager finish the installation of WSUS (WSUS is now installed)
    • In IIS add MIME typ ".esd application/octet-stream" for "WSUS Administration Site"
    • Run iisreset
    • Open WSUS Console finish the Wizard (under Product and Classification check Windows 10 and Upgrades)
    • Sync

    Donnerstag, 15. September 2016 09:39
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich habe leider ein kleines Problem beim verteilen des Funktionsupdates 1607 über den WSUS und ich hoffe ihr könnt mir helfen.


                

    Hallo,

    Fehler: RecoverCrypto: File is encrypted, but no key was provided. 0xc1800118

    Meine Win10 Clients sind erfolgreich upgraded 1607 (Server 2012 R2 - WSUS)

    Hab WSUS, WID, IIS neu installiert:

    Meine Schritte:

    • Uninstall Role "WSUS" and under Features "Windows Update Services Tools"
    • Open "SQL Server Management" and connect to "Windows Internal Database" and delete "SUSDB Database"
    • Uninstall Role "IIS" and Feature "Windows Process Activation Service", "Windows Internal Database"
    • Reboot
    • Delete Folder "WsusContont" and "UpdateServicesPackages"
    • Delete Folder "C:\Program Files\Update Services"
    • Delete or rename Folder "C:\Windows\WID"
    • Delete or rename Folder "C:\inetpub"
    • Delete key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services"
    • Install KB3095113 (if not installed previously)
    • Install KB3159706 (if not installed previously)
    • Reboot
    • Install Role "WSUS (with all the Components)" and Feature "HTTP Activation" under ".net Framework 4.5"
    • In Server Manager finish the installation of WSUS (WSUS is now installed)
    • In IIS add MIME typ ".esd application/octet-stream" for "WSUS Administration Site"
    • Run iisreset
    • Open WSUS Console finish the Wizard (under Product and Classification check Windows 10 and Upgrades)
    • Sync

    Haben die Clients denn danach neue Updates vom WSUS gezogen? Meines Wissens nach hat das Funktionsupdate einen Bug, die Clients können danach keine Updates mehr vom WSUS ziehen. Abhilfe schafft zur Zeit wohl nur die manuelle Installation des CU vom 13.09.

    Donnerstag, 15. September 2016 11:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Haben die Clients denn danach neue Updates vom WSUS gezogen? Meines Wissens nach hat das Funktionsupdate einen Bug, die Clients können danach keine Updates mehr vom WSUS ziehen. Abhilfe schafft zur Zeit wohl nur die manuelle Installation des CU vom 13.09.

    Zuerst diese Schritte durchführen, damit das Upgrade funktioniert.

    Nein, es liegt nicht am Funktionsupdate.

    Ich denke das Problem liegt schlicht und ergreifend beim Entschlüsseln des Updates. no private key

    Wenn das Upgrade funktioniert hat, dann das CU 14393.187 KB3189866 manuell installieren (behebt den WSUS BUG)

    Donnerstag, 15. September 2016 12:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Ja, da hatte ich mich wohl falsch ausgedrückt. Ich meinte ja, WENN dann endlich das Funktionsupdate 1607 von den Clients angefordert und installiert wird läuft man gleich ins das nächste Problem: Ohne KB3189866 ziehen die Clients nichts mehr vom WSUS. Und das muss man manuell installieren, da ja die Clients nix mehr vom WSUS ziehen.

    Sollte man schon wissen bevor man seine ganzen Maschinen fröhlich upgraded ;-) Ich denke ich werde mal warten bis MS (hoffentlich) ein Funktionsupdate auf 1607 OHNE den Bug nachschiebt...


    • Bearbeitet Marco3108 Donnerstag, 15. September 2016 13:08
    Donnerstag, 15. September 2016 13:07
    |
  • Question
    Anmelden
    1
    Anmelden

     das CU 14393.187 KB3189866 manuell installieren (behebt den WSUS BUG)

    Oder einfach das MSU auf eine Freigabe legen und von dort per Skript (Stichwort "wusa.exe") installieren lassen. Ist bei >20 Client schneller und komfortabler :)

    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    Donnerstag, 15. September 2016 13:20
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 09.09.2016 schrieb Logibooze:

    In welcher Gruppe ist der WSUS?

    In einer Eigenen für die Server.


    Ist für diese Gruppe das Upgrade auch freigegeben?

    Für die Servergruppe natürlich nicht. Warum sollte es auch die Server brauchen ja kein Anniversary Update.

    Entschuldige, mein Fehler. ;)

    Für die EDV Gruppe in der sich der Client befindet, ist das Upgrade natürlich genehmigt sonst hätten es die anderen Clients ja nicht gezogen. Außerdem würde Der Client, der es nicht herunterlädt, nicht finden.

    Finden sich Fehlermeldungen in der %windir%\WindowsUpdate.log auf dem
    Client?

    Hmm, könnte natürlich sein, mit anderer Domain hatte ich noch nicht. Nur mit Arbeitsgruppe.

    Das war auch erst meine Vermutung. Aber als ich danach im Internet auf die Suche gegangen bin hieß es nur , dass WSUS ohne Probleme Domänenübergreifend arbeitet.

    Ja, zu dem Zeitpunkt gab es noch kein W10 und keine Upgrades über den
    WSUS.

    Ich meine der Rechner hat ja vor dem Anniversary Update auch schon ein anderes Update vom WSUS geladen und installiert. Ich vermute es liegt direkt am Anniversary Update. Kenne allerdings nicht das genau Problem geschweige denn eine Lösung(deswegen der Beitrag hier)

    Update oder Upgrade?

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Windows Update log ist seit Windows 10 Technical Preview nicht mehr in %Windir%\WindowsUpdate.log, sondern im Eventviewer.

    @Topic
    Stoße auf das gleiche Problem.
    Schon lächerlich, was sich MS da erlaubt. Testen die Updates vorher überhaupt noch, oder heißt es nur noch Geschwindigkeit > Qualität?

    Eigentlich erübrigt sich der letzte Satz ja schon, wenn man auf dem WSUS Funktinosupdate liest...

    ................. und da fragen sich echt noch Menschen warum es Firmen gibt, die noch mit Windows XP arbeiten. Ich kann Sie mehr und mehr verstehen, ist ja so langsam einfach nur lächerlich was sich dieser "Weltkonzern" mit seinen Produkten erlaubt. Ich meine wenn es nun im Zusammenhang mit nem Drittanbieter stehen würde, dann könnte man es ja nachvollziehen. Aber die Hausinternen Komponenten so stümperhaft zu pflegen ist schon peinlich.

    • Bearbeitet BeatYa Freitag, 16. September 2016 07:33
    Donnerstag, 15. September 2016 14:29
    |
  • Question
    Anmelden
    0
    Anmelden

    Oder einfach das MSU auf eine Freigabe legen und von dort per Skript (Stichwort "wusa.exe") installieren lassen. Ist bei >20 Client schneller und komfortabler :)

    genau so hab ich es auch gemacht bei ca 30 Client.
    • Bearbeitet -Paz- Donnerstag, 15. September 2016 17:25
    Donnerstag, 15. September 2016 17:24
    |