none
SCEP Client Update Problem RRS feed

  • Frage

  • Hallo zusammen,

    zur Vorgeschichte: Wir hatten SCCM 2012 installiert und konfiguriert und auf den Clients den SCEP Client verteilt. Besondere Umstände machten es aber nötig, den SCCM wieder deinstallieren mussten. Der SCEP Client sollte jedoch als eigener Client weiterhin in Betrieb sein und sich über den normalen WSUS aktualiseren. Tut er aber nicht.

    Der WSUS funktioniert, da die Windows Clients sich die Updates wie erwartet ziehen. Der SCEP Client bringt jedoch die Fehlermeldung, dass die Verbindung fehlgeschlagen ist. Hat der SCEP Client noch irgendwo alte EInstellungen des SCCM ausser in der GPO? Der WSUS-Pfad hat sich nach der deinstallation des SCCM geändert und ist in der GPO soweit korrekt angepasst, den SCEP Client interessiert das aber recht wenig.

    Danke für eure Hilfe!

    • Verschoben Alex Pitulice Montag, 14. Mai 2012 08:57 Verschoben (aus:Microsoft Security Produkte ( Forefront, TMG, ISA, Essentials, … ))
    Mittwoch, 9. Mai 2012 15:00

Alle Antworten

  • Hi,

    diese Konstellation hatte ich noch nicht, muss also Vermutungen anstellen:
    geh mal in die Registry auf einem SCEP Client:
    HKLM\Software\microsoft\Microsoft Security Client - Loesche lastSuccessfulAppliedPolicy und lastSuccessfulAppliedPolicyTimeUTC
    HKLM\Software\microsoft\Microsoft Antimalware\Signature Updates und schau Dir den key fallbackOrder an. Steht da InternalDefinitionUpdateServer als erstes drin? SCCM steht nicht drin?
    Bei beiden Regpfaden sollte der Key "ForceUpdatefromMU" auf 1 stehen
    Schau auch mal in die Datei WindowsUpdate.log im Windows Verzeichnis, wo sich der Client Updates zieht
    Im Verzeichnis: C:\ProgramData\Microsoft\Microsoft Security Client\Support liegen MSSECURITY*.* Logdateien. Das sind die SCEP Antimalware Logfiles. Kannst Du da was auffaelliges sehen?
    BTW: Lizentechnisch darfst Du den SCEP Client nicht ohne eine entsprechende System Center Lizenz einsetzen


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    Mittwoch, 9. Mai 2012 15:38
  • Hallo,

    vielen Dank für die Antwort.
    Hab die Reg-Keys geprüft, sieht alles so aus wie du beschrieben hast. FallbackOrder lautet "InternalDefinitionUpdateServer|MicrosoftUpdateServer|MMPC".
    Im WindowsUpdate.log steht:
    "WARNING: WinHttp: SendRequestUsingProxy failed for <http://www.update.microsoft.com/v9/windowsupdate/redir/muv4wuredir.cab>. error 0x8024402c"
    Von unserem internen WSUS ist nichts zu sehen. Die Umgebung hat keinen Zugriff auf das Internet, der interne WSUS wird über einen Proxy mit dem externen WSUS abgeglichen.

    In den MSSECURITY Logs steht ebenfalls nichts ungewöhnliches drin.

    Was ich oben nicht erwähnt hatte ist, dass über die Windows Updates die Definition Updates für den SCEP installiert werden. Wir können den SCEP aktuell halten, der Fehler tritt nur beim direkten Update-Vorgang des SCEP auf.

    Donnerstag, 10. Mai 2012 07:33
  • Hi,

    schau mal im Verzeichnis C:\ProgramData\Microsoft\Microsoft Antimalware\Support auf einem betroffenen Client nach. Dort gibt es die Logdatei MPLOG*.*. Was steht da bei einem manuellen Aktualisierungsversuch des SCEP Clients?.... Signature updated via ...?
    Habt Ihr die SCEP DefUpdates frueher ueber den SCCM verteilt oder auch ueber WSUS?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    Donnerstag, 10. Mai 2012 07:58
  • Hier der Auszug aus dem MPLOG:

    --------------------------------------------------------------------------------
    System Center 2012 Endpoint Protection (xxx) Service Log
    Started On ‎Do ‎Mai ‎10 ‎2012 09:59:48
    **********************************************************************Cache stats************
    No. Of buckets -> 53
    Each Bucket has max capacity of -> 128 entries
    number of Entries is 0
    Number of invalid entries is 0
    Number of Inserts issued is 0
    Number of replaces issued is 0
    Number of Insert failures is 0
    Number of lookups is 0
    Number of misses is 0
    Number of false fast lookups is 0
    Number of invalidations is 0
    Number of maintenance invalidations is 0
    Current File Size is 438272
     
    2012-05-10T07:59:48.226Z Verifying RTP plugin...
    2012-05-10T07:59:48.241Z verified!
    2012-05-10T07:59:48.491Z Verifying Nis plugin...
    2012-05-10T07:59:48.506Z verified!
    2012-05-10T07:59:48.506Z Initializing Nis plugin state...
    2012-05-10T07:59:48.506Z Nis initialized!
    2012-05-10T07:59:48.506Z Loading engine...
    2012-05-10T07:59:48.506Z loaded!
    2012-05-10T07:59:48.506Z Verifying license file...
    2012-05-10T07:59:48.506Z Resetting Cache
    2012-05-10T07:59:48.506Z Disabling cache because the SetOrValidateChangeJournalId operation didnt succeed with 0x80501002
    2012-05-10T07:59:48.506Z Cache Disabled
    2012-05-10T07:59:48.506Z verified!
    2012-05-10T07:59:48.506Z Product supports installmode: 2
    2012-05-10T07:59:48.506Z Auto purger task is scheduled to run in 600000(ms) from now with period 86400000(ms)
    Product Version: 3.0.8410.0
    Service Version: 3.0.8410.0
    Engine Version: 0.0.0.0
    AS Signature Version: 0.0.0.0
    AV Signature Version: 0.0.0.0
    ************************************************************
    2012-05-10T08:00:26.024Z Task(SignaturesUpdateService -UnmanagedUpdate) launched
    2012-05-10T08:04:48.510Z Task(Scan -ScheduleJob -RestrictPrivileges -ScanType 2) is scheduled to run in 57360000(ms) from now with period 86400000(ms)
    2012-05-10T08:06:29.754Z Task(SignaturesUpdateService -UnmanagedUpdate) launched
    2012-05-10T08:09:48.515Z AutoPurgeWorker triggered with dwWork=0x3
    2012-05-10T08:09:48.515Z Product supports installmode: 2
    2012-05-10T08:09:48.515Z Detection State: Finished(0) Failed(0) CriticalFailed(0) Additional Actions(0)
    System Center 2012 Endpoint Protection (xxx) Log, (c) 2006
    Stopped On ‎Do ‎Mai ‎10 ‎2012 10:12:58 (Exit Code = 0x0)
    ************************************************************

    Die Updates wurden vorher über den SCCM verteilt. Clients die vorher über den SCCM angebunden waren haben dieses Problem, neue Clients funktionieren einwandfrei.

    Donnerstag, 10. Mai 2012 08:17
  • Hi,

    >> Die Updates wurden vorher über den SCCM verteilt. Clients die vorher über den SCCM angebunden waren haben dieses Problem, neue Clients
    >> funktionieren einwandfrei

    dann sehe ich das Problem weniger als SCEP Problem sondern als SCCM Problem. Es muss noch "Reste" der SCCM Client Konfiguration geben, dass der SCCM Client die Windows Updates vom SCCM holen will und somit der SCEP Client auch versucht die Updates der Def Updates vom SCCM holen will.
    Ich wuerde mal mit ein paar WSUS Diagnostic Tools checken warum sich der Client die Updates nicht beim WSUS holt:
    http://www.wsus.de/index.php?section=downloads&category=8
    Da sich der CSEP Client aber nur bei einem manuellen Update nicht die DefUpdates vom WSUS holt, denke ich eher, Du solltest die Frage mal im SCCM Forum stellen, warum ein SCCM Client sich die Updates nicht mehr vom internen WSUS holt, sondern versucht zum SCCM zu gehen auch wenn sein SUP entfernt wurde, bzw. SCCM entfernt wurde


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    Donnerstag, 10. Mai 2012 09:29
  • Evtl. ist die lokale Windows Update GPO noch aktiviert die der SCCM Agent
    setzt. Siehst du per gpedit.msc oder in der Registry unter
    HKLM/Software/Policies/Microsoft/Windows/Windows Update. Die GPO sollte
    allerdings automatisch gelöscht werden wenn man den SCCM Agent regulär
    deinstalliert.
     
    Grüße
    Wolfgang
     
     
    Samstag, 12. Mai 2012 11:38
  • Hallo gpist,

     

    Ich habe den Thread auf System Center Forum verschoben, um deine Anfrage die bestmögliche Antwort zu bekommen.

     

    Vielen Dank für das Verständnis.

    Grüße,

    Alex



    Alex Pitulice, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Montag, 14. Mai 2012 08:59