none
SCCM 2012 SP1 - Client ruft Pakete für die Endpoint Protection nicht ab RRS feed

  • Allgemeine Diskussion

  • Hallo,

    ich habe das Problem, dass meine Clients die Pakte für die Endpoint Protection nicht vom SCCM abholen. Irgendwo habe ich einen Denkfehler oder übersehe etwas wie die System zusammenspielen.

    Wir betreiben einen dedizierten WSUS-Server, der die Rollen Endpoint Protection Point und Software Update Point hat, sowie den SCCM, der unter anderem den Distribution Point enthält. Die Synchronisation zwischen WSUS und SCCM funktioniert ohne Fehler.

    Endpoint Protection ist wie folgt konfiguriert:

    • Gerätesammlung mit den Clients
    • Endpoint Protection-ADR (Paket wird aktualisiert, neue Definitionen heruntergeladen und hinzugefügt)
    • Client Device Settings: Endpoint Protection
    • Antimalware Policy: Quelle nur auf Configuration Manager eingestellt

    Beim manuellen Aktualisieren kommt eine Fehlermeldung:

    Fehlercode: 0x80248014 

    Fehlerbeschreibung: Die Definitionspakete konnten vom System Center Entpoint Protection nicht installiert werden.

    Vielleicht habt ihr ja eine Idee.

    mfg & thx

    Thorsten

    Mittwoch, 15. Mai 2013 12:27

Alle Antworten

  • Was steht denn in den Logs auf dem Client (v.a. U*.log und C:\ProgramData\Microsoft\Microsoft Antimalware\Support)?
    Nicht einfach alle Logs posten; bitte vorher einfach mal selbst durchsuchen und schauen, was wichtig ist.

    Torsten Meringer | http://www.mssccmfaq.de

    Mittwoch, 15. Mai 2013 12:49
    Beantworter
  • Aus meiner Sicht sehen die Einträge im Log gut aus. CMTrace hat zumindestens nichts als Fehler oder Warnung gekennzeichnet. Auf was solllte ich besonders achten.

    Thorsten

    Donnerstag, 16. Mai 2013 12:59
  • Die genannten Logs mit cmtrace.exe öffnen, die clientseitige Aktion ausführen und Logs beobachten. Der Fehler sollte sich darin widerspiegeln.

    Torsten Meringer | http://www.mssccmfaq.de

    Donnerstag, 16. Mai 2013 14:26
    Beantworter
  • Die Logs auf der Clientseite sind aus meiner Sicht unauffällig, anbei die Essenz.

    UpdatesStore.log: Status der Definitionsupdates wird abgefragt und festgestellt dass diese fehlen.

    UpdateHandler.log: Der angestossene Job wird dokumentiert und läuft ohne Fehler durch.

    UpdatesDeployment.log: Fehlende Updates werden erkannt (EnumerateUpdates for action (UpdateActionInstall) - Total actionable updates = 3)

    UpdateTrustedSites.log: die entsprechenden fünf Einträge

    -----------------------------

    Starting UpdateTrustedSites with FALSE http://*****:80/CMApplicationCatalog

    AddDefaultPortalToTrustedSites: Existing URL is empty or add to trusted sites is true and the default URL hasn't changed. Not deleting the existing URL from trusted sites list.

    AddDefaultPortalToTrustedSites: It was determined that catalog Url should not be added to the trusted sites zone.

    AddDefaultPortalToTrustedSites: Existing URL is empty.

    AddDefaultPortalToTrustedSites: It was determined that catalog Url should not be added to the trusted sites zone.

    -------------------------------

    In den MP-Logs wird nur noch der fehlerfreie Start des Dienstes dokumentiert. Spielen noch andere Kompenenten ausser Client und SCCM beim Aktualisieren des FEP-Clients mit, die ich berücksichtigen muss z. B. WSUS.

    Thorsten

    Freitag, 17. Mai 2013 06:38
  • Siehe oben: die Endpoint Protection Logs und ggfs noch WUAHandler.log und WindowsUpdate.log.

    Torsten Meringer | http://www.mssccmfaq.de

    Freitag, 17. Mai 2013 07:54
    Beantworter
  • Entschuldige hatte ich übersehen. Im WindowsUpdate.log gibt es Einträge, wobei ich nicht nachvollziehen kann warum die Virendefinitionen heruntergeladen werden sollen. WUAHandler.log ist unauffällig.

    2013-05-17 10:58:39:613  952 10f4 Misc WARNING: Send failed with hr = 80072ee7.
    2013-05-17 10:58:39:613  952 10f4 Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None>
    2013-05-17 10:58:39:613  952 10f4 Misc WARNING: Send request failed, hr:0x80072ee7
    2013-05-17 10:58:39:613  952 10f4 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab>. error 0x8024402c
    2013-05-17 10:58:39:613  952 10f4 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x8024402c
    2013-05-17 10:58:39:613  952 10f4 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x8024402c
    2013-05-17 10:58:39:613  952 10f4 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x8024402c

    mfg

    Thorsten

    Freitag, 17. Mai 2013 09:15
  • Hallo,

    im Ereignislog steht, dass der WSUS ordnungsgemäß funktioniert.

    Ich dachte dass beim Einsatz des SCCM alle Einstellungen über den SCCM gemacht werden und keine GPOs mehr verwendet werden sollen zum Konfigurieren des WSUS.

    Die Sync zwischen WSUS und SCCM funktioniert übrigens hervorragend.

    mfg

    Thorsten

    Dienstag, 21. Mai 2013 06:43
  • Hallo Raul,

    leider bin ich noch nicht wirklich weitergekommen.

    mfg

    Thorsten

    Dienstag, 21. Mai 2013 06:43
  • Windows Updates GP muss konfiguriert sein! -> Specify Intranet Microsoft Update Service location, FQDN und Port des primary SUP

    Dienstag, 21. Mai 2013 07:21
  • Windows Updates GP muss konfiguriert sein! -> Specify Intranet Microsoft Update Service location, FQDN und Port des primary SUP


    Nein. Nicht zwingend. ConfigMgr erledigt dies alles mittels einer lokalen Richtlinie. Prinzipiell braucht es für ConfigMgr überhaupt keine GPO. (Ausnahme: SCUP)

    Torsten Meringer | http://www.mssccmfaq.de


    Dienstag, 21. Mai 2013 07:24
    Beantworter