none
Migration eines 2012er WSUS mit WPP zu 2012 R2 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich habe die Tage einen 2012er WSUS auf einen 2012er R2 WSUS als Replikaserver migriert.

    Das hat soweit ganz gut geklappt. Bei mir haben sich nur ein paar Fragen bzgl. dem WPP aufgeworfen. Sämtliche Updates, die ich mit dem WPP auf dem 2012er Server erstellt habe, wurden nicht mit auf den 2012er R2 repliziert. Kann das daran liegen, dass ich die Updates nicht in die "susdb" des WSUS vom WPP mit habe eintragen lassen? Heißt wohl soviel wie, dass meine selbstgehämmerten Updates auch nicht in der WSUS-Konsole erscheinen. Sollte ich die Option in Zukunft setzen, auch wenn sie ggf. "nicht empfohlen" ist? Irgendwelche Skripte vorher kamen bei mir auch nicht zur Anwendung. 

    Insgesamt ist das jetzt kein großes Problem für mich. Allerdings würde mich schon interessieren, warum meine selbst erstellten Update nicht mit repliziert wurden.

    Grüße

    Willy










    Montag, 12. September 2016 18:13
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Am 13.09.2016 schrieb willy-goergen: 

    Fehler beim Herunterladen der Inhaltsdatei.
Ursache: File cert verification failure.
Quelldatei: /Content/BF/4EA8AFBDB217644BA80BB0AE12E0EAD4FE57E8BF.cab
Zieldatei: D:\WSUS\WsusContent\BF\4EA8AFBDB217644BA80BB0AE12E0EAD4FE57E8BF.cab



    Das ist genau eines der fehlenden WPP-Updates. Für die restlichen Updates finden sich ähnliche Meldungen. Der neue WSUS hatte zu dem Zeitpunkt des Herunterladens noch kein Zertifikat für den WPP. Außerdem habe ich dem Ding nachträglich ein neues Zertifikat verpasst. Und meine GPOs für den Import des Zertifikats von WPP-Updates gelten nur für Clients. Meine Server hatte ich bisher davon ausgenommen. Bisher sah ich dafür auch noch keine Notwendigkeit.

    Weshalb die Server ausnehmen?

    Ist das vielleicht die Erklärung für meine Probleme?

    Das ist mit Sicherheit des Rätsels Lösung. Wie lange dauert der Test?

    Servus
    Winfried

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

    • Als Antwort markiert willy-goergen Mittwoch, 14. September 2016 05:18
    Dienstag, 13. September 2016 19:40
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Am 12.09.2016 schrieb willy-goergen:

    Das hat soweit ganz gut geklappt. Bei mir haben sich nur ein paar Fragen bzgl. dem WPP aufgeworfen. Sämtliche Updates, die ich mit dem WPP auf dem 2012er Server erstellt habe, wurden nicht mit auf den 2012er R2 repliziert. Kann das daran liegen, dass ich die Updates nicht in die "susdb" des WSUS vom WPP mit habe eintragen lassen?

    Wenn ein Update nicht in der SUSDB ist, kennt es der WSUS nicht und
    kann es auch nicht zur Verfügung stellen. Das ist dann so, also ob das
    Update gar nicht existiert.

    Natürlich sind sie da, Du mußt sie nur auf dem WSUS sichtbar machen.
    Installiere auf dem neuen WSUS das SQL Server Management Studio und
    verbinde dich zur
    SUSDB.http://www.wsus.de/ausfuehren_eines_scripts_auf_der_windows_internal_database
    Anstatt sql mußt Du ab 2012 tsql im Anmeldestring verwenden. In der
    Tabelle tbUpdate ist das Feld IsLocallyPublished für die Anzeige der
    in der WSUS.MSC verantwortlich. Schau doch dieses Bildchen an:
    http://www.wsus.de/images/content/lup/23_Run_Query.png Du kannst ganz
    einfach ein Update von <>0 auf 0 umstellen, dann siehst Du es auch in
    der WSUS.MSC.

    Heißt wohl soviel wie, dass meine selbstgehämmerten Updates auch nicht in der WSUS-Konsole erscheinen. Sollte ich die Option in Zukunft setzen, auch wenn sie ggf. "nicht empfohlen" ist? Irgendwelche Skripte vorher kamen bei mir auch nicht zur Anwendung. 

    Nein, du brauchst die Option auch zukünftig nicht zu setzen, die
    Updates sind aber trotzdem da.

    Insgesamt ist das jetzt kein großes Problem für mich. Allerdings würde mich schon interessieren, warum meine selbst erstellten Update nicht mit repliziert wurden.

    Die Updates sind da, auch wenn Du sie nicht 'siehst'. ;)

    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:12
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin Winfried,

    danke für deine Antwort! :)

    Soweit leuchtet mir das alles ein. Vielleicht sollte ich meine Frage nochmal etwas anders formulieren:

    Kann die Ursache dafür, dass die WPP-Updates (bzw. die Dateien dahinter) nicht mit auf den neuen WSUS repliziert wurden daran liegen, dass die Updates in der Konsole nicht als sichtbar erscheinen?

    Oder könnte ich vielleicht was anderes verkehrt gemacht oder vergessen haben? Den neuen WSUS habe ich zunächst als Replikat des alten erstellt und die Server danach replizieren lassen.

    Die selbsterstellten Updates waren zwar im WPP (lokal verbunden) auf dem neuen WSUS sichtbar, aber die Dateien dahinter wurden nicht mit übertragen. 

    Es wurde weder das "UpdateServicesPackages" übertragen - das war komplett leer - noch das (wenn ich es richtig verstehe) eigentliche Update im "WsusContent" Verzeichnis. Im WPP ist das dann farblich hinterlegt zu sehen. Der "Ordner" rot hinterlegt, die "ID" gelb.

    Versuche, die Dateien händisch an ihren Bestimmungsort zu bringen, schlugen fehl. Zumindest die Dateien, die ich händisch in "WsusContent" eingefügt habe, waren nach ein paar Tagen wieder verschwunden, womit die Updates wieder nicht mehr funktionierten.

    Meine Lösung hat so ausgesehen, dass ich die Updates lösche und dann nochmal neu erstelle. Das Thema ist aber trotzdem für mich interessant, falls ich mal in die Lage kommen sollte, einen WSUS Replikaserver zusammen mit WPP betreiben zu wollen.

    Grüße

    willy







    Dienstag, 13. September 2016 06:07
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 13.09.2016 schrieb willy-goergen:

    Kann die Ursache dafür, dass die WPP-Updates (bzw. die Dateien dahinter) nicht mit auf den neuen WSUS repliziert wurden daran liegen, dass die Updates in der Konsole nicht als sichtbar erscheinen?

    Nein, das kann nicht sein.

    Oder könnte ich vielleicht was anderes verkehrt gemacht oder vergessen haben? Den neuen WSUS habe ich zunächst als Replikat des alten erstellt und die Server danach replizieren lassen.

    Hast Du ihn auch als Replikat des Unternehmensservers konfiguriert?
    Wenn ja, wie oft und wie lange hast Du replizieren lassen? Stündlich
    replizieren lassen und am besten über einen Zeitraum von 24 Std.

    Die selbsterstellten Updates waren zwar im WPP (lokal verbunden) auf dem neuen WSUS sichtbar, aber die Dateien dahinter wurden nicht mit übertragen. 

    Es wurde weder das "UpdateServicesPackages" übertragen - das war komplett leer - noch das (wenn ich es richtig verstehe) eigentliche Update im "WsusContent" Verzeichnis. Im WPP ist das dann farblich hinterlegt zu sehen. Der "Ordner" rot hinterlegt, die "ID" gelb.

    Dazu sollte sich etwas im Eventlog auf dem Replica finden lassen.
    SoftwareDistribution.log im Programmverzeichnis des WSUS.

    Meine Lösung hat so ausgesehen, dass ich die Updates lösche und dann nochmal neu erstelle. Das Thema ist aber trotzdem für mich interessant, falls ich mal in die Lage kommen sollte, einen WSUS Replikaserver zusammen mit WPP betreiben zu wollen.

    Hat bei mir sofort einwandfrei funktioniert.

    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:21
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke für deine Antwort. Sie hat mir zumindest mal einen Impuls gegeben, wo ich nachsehen könnte. :)

    Im "Softwaredistribution.log" des WSUS ist nichts zu sehen. Hatte gezielt nach den fehlenden Dateinamen gesucht. Allerdings brachte etwas Stöbern im Eventlog des neuen WSUS folgendes zutage:

    Fehler beim Herunterladen der Inhaltsdatei.
Ursache: File cert verification failure. 
Quelldatei: /Content/BF/4EA8AFBDB217644BA80BB0AE12E0EAD4FE57E8BF.cab 
Zieldatei: D:\WSUS\WsusContent\BF\4EA8AFBDB217644BA80BB0AE12E0EAD4FE57E8BF.cab

    Das ist genau eines der fehlenden WPP-Updates. Für die restlichen Updates finden sich ähnliche Meldungen. Der neue WSUS hatte zu dem Zeitpunkt des Herunterladens noch kein Zertifikat für den WPP. Außerdem habe ich dem Ding nachträglich ein neues Zertifikat verpasst. Und meine GPOs für den Import des Zertifikats von WPP-Updates gelten nur für Clients. Meine Server hatte ich bisher davon ausgenommen. Bisher sah ich dafür auch noch keine Notwendigkeit. Ist das vielleicht die Erklärung für meine Probleme?

    Grüße

    willy



    Dienstag, 13. September 2016 17:26
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 13.09.2016 schrieb willy-goergen: 

    Fehler beim Herunterladen der Inhaltsdatei.
Ursache: File cert verification failure.
Quelldatei: /Content/BF/4EA8AFBDB217644BA80BB0AE12E0EAD4FE57E8BF.cab
Zieldatei: D:\WSUS\WsusContent\BF\4EA8AFBDB217644BA80BB0AE12E0EAD4FE57E8BF.cab



    Das ist genau eines der fehlenden WPP-Updates. Für die restlichen Updates finden sich ähnliche Meldungen. Der neue WSUS hatte zu dem Zeitpunkt des Herunterladens noch kein Zertifikat für den WPP. Außerdem habe ich dem Ding nachträglich ein neues Zertifikat verpasst. Und meine GPOs für den Import des Zertifikats von WPP-Updates gelten nur für Clients. Meine Server hatte ich bisher davon ausgenommen. Bisher sah ich dafür auch noch keine Notwendigkeit.

    Weshalb die Server ausnehmen?

    Ist das vielleicht die Erklärung für meine Probleme?

    Das ist mit Sicherheit des Rätsels Lösung. Wie lange dauert der Test?

    Servus
    Winfried

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

    • Als Antwort markiert willy-goergen Mittwoch, 14. September 2016 05:18
    Dienstag, 13. September 2016 19:40
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 13.09.2016 schrieb willy-goergen: 

    Weshalb die Server ausnehmen?

    Ist das vielleicht die Erklärung für meine Probleme?

    Das ist mit Sicherheit des Rätsels Lösung. Wie lange dauert der Test?

    Servus
    Winfried

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

    Hallo Winfried,

    wieso sollte ich solche Zertifikate mit einer recht allgemein gefassten GPO in den Speicher aller Server importieren? Ich hatte bisher nicht einen Fall, in dem das nötig gewesen wäre. Bis jetzt...

    Ich finde das insofern problematisch weil derjenige der den WPP bedient, unter Umständen nicht weiß, was er damit anstellen kann und ziemlich viel Schaden mit fehlerhaft erstellten Updates auch auf Servern anrichten könnte. Allerdings überlege ich, das etwas aufzuweichen. Wäre das dann mein Problem?

    Grüße

    willy





    Dienstag, 13. September 2016 22:11
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 14.09.2016 schrieb willy-goergen:

    wieso sollte ich solche Zertifikate mit einer recht allgemein gefassten GPO in den Speicher aller Server importieren? Ich hatte bisher nicht einen Fall, in dem das nötig gewesen wäre. Bis jetzt...

    Wenn Du ein Update für Server bereitstellen möchtest wäre das schon
    hilfreich. Denn jetzt hast Du viel gesucht.

    Ich finde das insofern problematisch weil derjenige der den WPP bedient, unter Umständen nicht weiß, was er damit anstellen kann und ziemlich viel Schaden mit fehlerhaft erstellten Updates auch auf Servern anrichten könnte. Allerdings überlege ich, das etwas aufzuweichen. Wäre das dann mein Problem?

    Jemand der den WSUS bedient sollte schon wissen was er tut, wenn
    nicht, was tut er dann an Servern und am WPP? Löse doch mal das erste
    Problem und mach dann das nächste auf.

    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/

    Mittwoch, 14. September 2016 04:54
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 14.09.2016 schrieb willy-goergen:

    wieso sollte ich solche Zertifikate mit einer recht allgemein gefassten GPO in den Speicher aller Server importieren? Ich hatte bisher nicht einen Fall, in dem das nötig gewesen wäre. Bis jetzt...

    Wenn Du ein Update für Server bereitstellen möchtest wäre das schon
    hilfreich. Denn jetzt hast Du viel gesucht.

    ...

    Jemand der den WSUS bedient sollte schon wissen was er tut, wenn
    nicht, was tut er dann an Servern und am WPP? Löse doch mal das erste
    Problem und mach dann das nächste auf.

    Servus
    Winfried


    Um das Thema hier abzuschließen.

    Hab auf jeden Fall wieder was dazugelernt und weiß für die Zukunft zumindest schon mal, wie ich es nicht mehr machen sollte.

    Der Rest ist bei mir "Firmenpolitik". Nachdem meinen Job ja jeder machen könnte, denke gerade schon mal etwas für meinen Nachfolger vor. Ich will das hier aber nicht vertiefen. 

    Vielen Dank dir jedenfalls für die Hilfe! :)



    Mittwoch, 14. September 2016 06:24
    |
  • Question
    Anmelden
    1
    Anmelden
    Hi,
     
    Am 14.09.2016 um 00:11 schrieb willy-goergen:
    > Ich finde das insofern problematisch weil derjenige der den WPP
    > bedient, unter Umständen nicht weiß, was er damit anstellen kann
     
    Naja, nur weil du ein Zertifikat verteilst, passiert da noch nichts.
     
    Wer Software verteilt muss auch die 2 großen Fragen beantworten:
    - Wer kriegt die Software?
    - Woran erkenne ich, daß sie evtl schon vorhanden ist?
     
    Ich denke, wer "jede" software immer "für alle" freigibt, ohne
    Targeting, und als einzigen Schutz ein "fehlendes Zertifikat" einsetzt
    hat ganz andere Probleme.
     
    Das "wenn, wenn, wenn oder wenn" ist immer möglich. Kaputt geht aber
    auch mit einem einzigen Registry Key per Startup Script oder per GPO,
    oder oder oder oder.
     
    Frag dich nicht, was passiert, wenn Deppen die Technik bedienen.
    Du kannst soziale Probleme nicht mit Technik lösen.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Mittwoch, 14. September 2016 06:55
    |