Problembehandlung bei der Verwaltung von Softwareupdates in Configuration Manager

Dieser Artikel hilft Ihnen bei der Problembehandlung des Softwareupdateverwaltungsprozesses in Configuration Manager. Sie umfasst die Überprüfung von Clientsoftwareupdates, Synchronisierungsprobleme und Erkennungsprobleme mit bestimmten Updates.

Ursprüngliche Produktversion: Configuration Manager (Current Branch), System Center 2012 R2 Configuration Manager, System Center 2012 Configuration Manager
Ursprüngliche KB-Nummer: 4505440

Festlegen des Problems

In diesem Leitfaden wird davon ausgegangen, dass bereits ein Softwareupdatepunkt installiert und konfiguriert wurde. Weitere Informationen zum Konfigurieren von Softwareupdates in Configuration Manager finden Sie unter Vorbereiten der Verwaltung von Softwareupdates.

Bevor Sie mit der Problembehandlung beginnen, sollten Sie betonen: Je besser Sie das Problem verstehen, desto schneller und einfacher können Sie es beheben. Unabhängig davon, ob Sie mit der Behebung eines Problems beauftragt werden, das bei Ihnen auftritt, oder einem Problem, das Ihnen von einer Person in Ihrem organization gemeldet wurde, nehmen Sie sich einen Moment Zeit, und beantworten Sie die folgenden Fragen:

1. Was funktioniert konkret nicht und/oder was ist Ihr Ziel?
2. Was ist die Häufigkeit oder das Muster für das Problem? Tritt das Problem weiterhin auf?
3. Wie sind Sie darauf aufmerksam geworden, dass das Problem besteht?
4. Hat es jemals geklappt? Wenn ja, wann wurde es beendet? Hat sich etwas in der Umgebung geändert, bevor es nicht mehr funktionierte?
5. Welcher Prozentsatz der Clients ist betroffen?
6. Was wurde bereits (falls überhaupt) getan, um zu versuchen, es zu beheben?
7. Kennen Sie die genaue Version des Clients und die Version des Servers. Sind diese Systeme auf dem neuesten Stand?
8. Was haben betroffene Clients gemeinsam? Beispiel: Gleiches Subnetz, AD-Standort, Domäne, physischer Standort, Standort, Standortsystem.

Wenn Sie die Antworten auf diese Fragen kennen und verstehen, gelangen Sie auf den besten Weg für eine schnelle und einfache Lösung für jedes Problem, das Sie haben.

Wenn Sie den spezifischen Bereich innerhalb des Softwareupdateverwaltungsprozesses kennen, den Sie behandeln möchten, wählen Sie ihn unten aus. Beginnen Sie mit der Überprüfung von Clientsoftwareupdates, wenn Sie sich nicht sicher sind, und wir durchlaufen den gesamten Prozess von Anfang bis Ende.

• Überprüfung von Clientsoftwareupdates
• Synchronisierung von WSUS zu Microsoft Update
• Installation, Ablösung oder Erkennung von Problemen mit bestimmten Updates

Überprüfung von Clientsoftwareupdates

Der Clientüberprüfungsprozess wird in den folgenden Schritten beschrieben. Vergewissern Sie sich bei jedem Schritt, dass das Problem ordnungsgemäß festgelegt wird.

Schritt 1: Der Client sendet eine WSUS-Standortanforderung an den Verwaltungspunkt.

Als Erstes legt der Client den WSUS-Server fest, der als Updatequelle für Softwareupdatescans fungiert. Dieser Prozess wird unten beschrieben.

1. Wenn der Configuration Manager Client eine Softwareupdateüberprüfung verarbeiten muss, erstellt der Scan-Agent eine Überprüfungsanforderung basierend auf der verfügbaren Richtlinie, wie in ScanAgent.log angegeben:

   CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={SourceID}  
   ContentVersion=38  
   CScanAgent::ScanByUpdates- Added Policy to final ScanRequest List UpdateSourceID={SourceID}, Policy-ContentVersion=38, Required-ContentVersion=38
   

2. Der Scan-Agent sendet jetzt eine WSUS-Standortanforderung an die Standortdienste, wie in ScanAgent.log angegeben:

   Inside CScanAgent::ProcessScanRequest()  
   CScanJobManager::Scan- entered  
   ScanJob({JobID}): CScanJob::Initialize- entered  
   ScanJob({JobID}): CScanJob::Scan- entered  
   ScanJob({JobID}): CScanJob::RequestLocations- entered  
   - - - - - -Requesting WSUS Server Locations from LS for {WSUSLocationID} version 38  
   - - - - - -Location Request ID = {LocationRequestID}  
   CScanAgentCache::PersistInstanceInCache- Persisted Instance CCM_ScanJobInstance  
   ScanJob({JobID}): - - - - - -Locations requested for ScanJobID={JobID} (LocationRequestID={LocationRequestID}), will process the scan request once locations are available.
   

   Tipp

   Jeder Scanauftrag wird in WMI in der CCM_ScanJobInstance -Klasse gespeichert:

   Namespace: root\CCM\ScanAgent Klasse: CCM_ScanJobInstance

3. Location Services erstellt eine Standortanforderung und sendet sie an den Verwaltungspunkt. Die Paket-ID für eine WSUS-Standortanforderung ist die eindeutige ID der Updatequelle. In LocationServices.log:

   CCCMWSUSLocation::GetLocationsAsyncEx  
   Attempting to persist WSUS location request for ContentID='{ContentID}' and ContentVersion='38'  
   Persisted WSUS location request LocationServices  
   Attempting to send WSUS Location Request for ContentID='{ContentID}'
   WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest>  
   Created and Sent Location Request '{LocationRequestID}' for package {ContentID}
   

4. CCM Messaging sendet die Standortanforderungsnachricht an den Verwaltungspunkt. In CcmMessaging.log:

   Sending async message '{Message}' to outgoing queue 'mp:[http]mp_locationmanager'  
   Sending outgoing message '{Message}'. Flags 0x200, sender account empty
   

5. Der Verwaltungspunkt analysiert diese Anforderung und ruft die MP_GetWSUSServerLocations gespeicherte Prozedur auf, um die WSUS-Speicherorte aus der Datenbank abzurufen. In MP_Location.log:

   MP LM: Message Body : \<WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> MP_LocationManager  
   MP LM: calling MP_GetWSUSServerLocations
   

   In SQL Server Profiler:

   exec MP_GetMPSitesFromAssignedSite N'PS1'  
   exec MP_GetSiteInfoUnified N'<ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2-PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo>'  
   exec MP_GetWSUSServerLocations N'{WSUSServerLocationsID}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'
   

6. Nach dem Abrufen der Ergebnisse aus der gespeicherten Prozedur sendet der Verwaltungspunkt eine Antwort an den Client. In MP_Location.log:

   MP LM: Reply message body: <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply>
   

7. CCM Messaging empfängt die Antwort und sendet sie zurück an die Standortdienste. In CcmMessaging.log:

   Message '{Message1}' got reply '{Message2}' to local endpoint queue 'LS_ReplyLocations'  
   OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={*Message1*}):  
   Delivered successfully to host 'PS1SYS.CONTOSO.COM'.  
   Message '{Message2}' delivered to endpoint 'LS_ReplyLocations'
   

8. Location Services analysiert die Antwort und sendet den Speicherort zurück an den Scan-Agent. In LocationServices.log:

   Processing Location reply message LocationServices  
   WSUSLocationReply : <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply>  
   Calling back with the following WSUS locations  
   WSUS Path='http://PS1SITE.CONTOSO.COM:8530', Server='PS1SITE.CONTOSO.COM', Version='38'  
   WSUS Path='https://PS1SYS.CONTOSO.COM:8531', Server='PS1SYS.CONTOSO.COM', Version='38'  
   Calling back with locations for WSUS request {WSUSLocationID}
   

9. Der Scan-Agent verfügt jetzt über die Richtlinie und den Quellspeicherort des Updates mit der entsprechenden Inhaltsversion. In ScanAgent.log:

   *****WSUSLocationUpdate received for location request guid={LocationGUID}  
   ScanJob({JobID}): CScanJob::OnLocationUpdate- Received  
   Location=<http://PS1SITE.CONTOSO.COM:8530>, Version=38  
   ScanJob({JobID}): CScanJob::Execute- Adding UpdateSource={SourceID}, ContentType=2, ContentLocation=<http://PS1SITE.CONTOSO.COM:8530>, ContentVersion=38
   

10. Der Scan-Agent benachrichtigt WUAHandler, die Updatequelle hinzuzufügen. WUAHandler fügt der Registrierung die Updatequelle hinzu. Es initiiert eine Gruppenrichtlinie Aktualisierung, wenn sich der Client in der Domäne befindet, um festzustellen, ob Gruppenrichtlinie den hinzugefügten Updateserver überschreibt. Die folgenden Einträge werden WUAHandler.log mit einer neuen Updatequelle protokolliert, die hinzugefügt wird:

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it  
    Its a completely new WSUS Update Source  
    Enabling WUA Managed server policy to use server: <http://PS1SITE.CONTOSO.COM:8530>
    Policy refresh forced  
    Waiting for 2 mins for Group Policy to notify of WUA policy change  
    Waiting for 30 secs for policy to take effect on WU Agent.  
    Added Update Source ({UpdateSource}) of content type: 2
    

    Während dieser Zeit sieht der Windows Update-Agent eine Änderung der WSUS-Konfiguration. In WindowsUpdate.log:

    * WSUS server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
    * WSUS status server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
    Sus server changed through policy.
    

    Die folgenden Registrierungsschlüssel werden überprüft und festgelegt:

    Registrierungsunterschlüssel	Wertname	Typ	Daten
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate	WUServer	REG_SZ	Die vollständige WSUS-Server-URL einschließlich port. Beispiel: <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate	WUStatusServer	REG_SZ	Die vollständige WSUS-Server-URL einschließlich port. Beispiel: <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU	UseWUServer	REG_DWORD	0x1

    Für einen vorhandenen Client können wir erwarten, dass die folgende Meldung in WUAHandler.log angezeigt wird, um anzugeben, wann die Inhaltsversion erhöht wurde:

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it.  
    WSUS update source already exists, it has increased version to 38.
    

11. Nachdem die Updatequelle erfolgreich hinzugefügt wurde, löst der Scan-Agent eine Statusmeldung aus und startet die Überprüfung. In ScanAgent.log:

    ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2  
    ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
    

Behandeln von Problemen in Schritt 1

Probleme	Zu Überprüfen
ScanAgent.log zeigt keine Verfügbare Richtlinie für eine Updatequelle an, und es ist keine WUAHandler.log vorhanden oder keine aktuelle Aktivität in WUAHandler.log	Aktivieren Sie die Einstellung Softwareupdates auf Clients aktivieren .
Der Scan-Agent oder die Standortdienste empfangen den WSUS-Serverstandort nicht.	Ist für den Standort eine Rolle "Softwareupdatepunkt" (SUP) installiert? Falls nicht, installieren und konfigurieren Sie einen Softwareupdatepunkt, und überwachen Sie SUPSetup.log auf Fortschritt. Weitere Informationen finden Sie unter Installieren und Konfigurieren eines Softwareupdatepunkts. Wenn eine SUP-Rolle installiert ist, wird sie konfiguriert und synchronisiert? Überprüfen Sie WCM.log, WSUSCtrl.log und WSyncMgr.log auf Fehler. select * from WSUSServerLocations select * from Update_SyncStatus
Der Client empfängt den WSUS-Speicherort, kann aber die WSUS-Registrierungsschlüssel nicht konfigurieren.	Hat Gruppenrichtlinie Aktualisierung innerhalb des 2-Minuten-Timeouts pro WUAHandler.log geantwortet? Wenn ja, bezeichnet WUAHandler Gruppenrichtlinieneinstellungen, die von einer höheren Autorität (Domänencontroller) überschrieben wurden? Weitere Informationen finden Sie unter Gruppenrichtlinie überschreibt die richtigen WSUS-Konfigurationsinformationen.

Weitere Informationen zur Problembehandlung bei Fehlern bei der Überprüfung von Softwareupdates finden Sie unter Problembehandlung bei Fehlern bei der Überprüfung von Softwareupdates.

Schritt 2: Scan-Agent fordert die Überprüfung an, und WUAHandler startet die Überprüfung

Nachdem der Client den WSUS-Server identifiziert und festgelegt hat, der seine Updatequelle für Softwareupdatescans sein soll, fordert der Scan-Agent die Überprüfung von WUAHandler an, der die Windows Update-Agent-API verwendet, um eine Softwareupdateüberprüfung vom Windows Update-Agent anzufordern. Eine Überprüfung kann sich auf Folgendes ergeben:

• Eine geplante oder manuelle Überprüfung von Softwareupdates
• Eine geplante oder manuelle Neuauswertung der softwareupdateten Bereitstellung
• Eine Bereitstellung, die aktiv wird

Der Scan löst eine Auswertung aus. In ScanAgent.log:

ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

Scanergebnisse enthalten ersetzte Updates nur, wenn sie durch Service Packs und Definitionsupdates ersetzt werden. In WUAHandler.log:

Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')  
Running single-call scan of updates.  
Async searching of updates using WUAgent started.

Tipp

Überprüfen Sie WUAHandler.log nach einem Softwareupdatescan, um festzustellen, ob neue Einträge auftreten. Wenn keine neuen Einträge auftreten, gibt dies an, dass vom Verwaltungspunkt kein SUP zurückgegeben wird.

Behandeln von Problemen in Schritt 2

Viele Probleme bei der Überprüfung von Softwareupdates können aus einem der folgenden Gründe verursacht werden:

• Fehlende oder beschädigte Dateien oder Registrierungsschlüssel.
• Probleme bei der Komponentenregistrierung.

Informationen zum Beheben solcher Probleme finden Sie unter Scanfehler aufgrund fehlender oder beschädigter Komponenten.

Es gibt ein bekanntes Problem, dass ein 32-Bit-Windows 7 ConfigMgr 2012 R2-Client, der eine Updateüberprüfung anfordert, keine Überprüfungsergebnisse an Configuration Manager zurückgibt. Dies bewirkt, dass der Client falsche Compliance-status meldet, und die Updates können nicht installiert werden, wenn Configuration Manager den Updatezyklus anfordert. Wenn Sie jedoch das Windows Update Systemsteuerungs-Applet verwenden, werden die Updates in der Regel ordnungsgemäß installiert. Wenn dieses Problem auftritt, erhalten Sie eine Meldung ähnlich der folgenden in WindowsUpdate.log:

WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E

Bei 64-Bit-Windows 7-Computern wird dieser Fehler nicht angezeigt, da ihr Adressraum praktisch unbegrenzt ist. Sie weisen jedoch eine hohe Arbeitsspeicher- und CPU-Auslastung auf, was sich möglicherweise auf die Leistung auswirkt. X86-Clients weisen auch eine hohe Arbeitsspeicherauslastung auf (normalerweise zwischen 1,2 GB und 1,4 GB).

Um dieses Problem zu beheben, wenden Sie Windows Update Client für Windows 7 an: Juni 2015.

Überprüfen Sie bei der Problembehandlung bei Überprüfungsfehlern die WUAHandler.log- und WindowsUpdate.log-Dateien. WUAHandler meldet einfach, was Windows Update-Agent gemeldet hat. Daher wäre der Fehler in WUAHandler derselbe Fehler, der vom Windows Update-Agent selbst gemeldet wurde. Weitere Informationen zum Fehler finden Sie in WindowsUpdate.log. Informationen zum Lesen WindowsUpdate.log finden Sie unter Windows Update Protokolldateien.

Ihre beste Informationsquelle stammt aus den Protokollen und den darin enthaltenen Fehlercodes. Weitere Informationen zu den Fehlercodes finden Sie unter Windows Update häufig auftretende Fehler und Entschärfung.

Schritt 3: Windows Update-Agent (WUA) startet die Überprüfung auf dem WSUS-Computer

Windows Update-Agent startet eine Überprüfung, nachdem eine Anforderung vom Configuration Manager-Client (CcmExec) empfangen wurde. Wenn diese Registrierungswerte ordnungsgemäß auf einen WSUS-Computer festgelegt sind, der über eine lokale Richtlinie eine gültige SUP für den Standort darstellt, sollte eine COM-API-Suchanforderung vom Configuration Manager Client (ClientId = CcmExec) angezeigt werden. In WindowsUpdate.log:

COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]  
COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec] PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent ** START ** Agent: Finding updates [CallerId = CcmExec]  
Agent * Include potentially superseded updates  
Agent * Online = Yes; Ignore download priority = Yes  
Agent * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"  
Agent * ServiceID = {ServiceID} Managed  
Agent * Search Scope = {Machine}

PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent * Added update {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 to search result  
Agent * Added update {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 to search result  
Agent * Found 163 updates and 70 categories in search; evaluated appl. rules of 622 out of 1150 deployed entities  
Agent ** END ** Agent: Finding updates [CallerId = CcmExec]  
COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]  
COMAPI - Updates found = 163  
COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]

Behandeln von Problemen in Schritt 3

Während einer Überprüfung muss der Windows Update-Agent mit den ClientWebService virtuellen Verzeichnissen und SimpleAuthWebService auf dem WSUS-Computer kommunizieren, um eine Überprüfung durchführen zu können. Wenn der Client nicht mit dem WSUS-Computer kommunizieren kann, schlägt die Überprüfung fehl. Dieses Problem kann aus vielen Gründen auftreten, einschließlich:

• Proxybezogene Probleme

  Informationen zum Beheben dieser Probleme finden Sie unter Überprüfungsfehler aufgrund von Proxyproblemen.

  Weitere Informationen zu Proxyservern finden Sie in den folgenden Artikeln:

  • Wie der Windows Update-Client bestimmt, welcher Proxyserver zum Herstellen einer Verbindung mit der Windows Update-Website verwendet werden soll
  • DNS- und DHCP-Unterstützung für die Webproxy- und Firewallclient-Autoermittlung

• HTTP-Timeoutfehler

  Um HTTP-Timeoutfehler zu beheben, überprüfen Sie zunächst die IIS-Protokolle (Internet Information Services) auf dem WSUS-Computer, um zu bestätigen, dass die Fehler tatsächlich von WSUS zurückgegeben werden. Wenn der WSUS-Computer den Fehler nicht zurückgibt, liegt das Problem wahrscheinlich an einer Zwischenfirewall oder einem Proxy.

  Wenn der WSUS-Computer den Fehler zurückgibt, überprüfen Sie die Konnektivität mit dem WSUS-Computer. Die Schritte sind hier aufgeführt:

  1. Um zu bestätigen, dass der Client eine Verbindung mit dem richtigen WSUS-Server herstellt, suchen Sie die URL des WSUS-Computers, der vom Windows Update-Agent-Client verwendet wird. Diese URL finden Sie, indem Sie den HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate Registrierungsunterschlüssel überprüfen oder die WindowsUpdate.log-Datei anzeigen.

     Häufige Gründe dafür, dass die WSUS-Zuweisung möglicherweise falsch ist, sind:

     • Gruppenrichtlinie Konflikte
     • Hinzufügen einer SUP zu einem sekundären Standort nach der ersten Clientinstallation

     Hinweis

     Active Directory-Gruppenrichtlinie kann die lokale WSUS-Richtlinie außer Kraft setzen.

     Das Softwareupdatefeature konfiguriert automatisch eine lokale Gruppenrichtlinie-Einstellung für den Configuration Manager Client, sodass er mit dem Quellspeicherort und der Portnummer des Softwareupdatepunkts konfiguriert wird. Sowohl der Servername als auch die Portnummer sind erforderlich, damit der Client den Softwareupdatepunkt finden kann.

     Wenn eine Active Directory-Gruppenrichtlinie-Einstellung auf Computer für die Installation des Softwareupdatepunktclients angewendet wird, wird die Einstellung für die lokale Gruppenrichtlinie überschrieben. Wenn sich der Wert der im Active Directory-Gruppenrichtlinie definierten Einstellung von dem wert unterscheidet, der von Configuration Manager festgelegt wurde, schlägt die Überprüfung auf dem Client fehl, da der richtige WSUS-Computer nicht gefunden werden kann. In diesem Fall zeigt WUAHandler.log die folgende Meldung an:

     Gruppenrichtlinieneinstellungen wurden von einer höheren Autorität (Domänencontroller) in Server und Richtlinie AKTIVIERT überschrieben.<http://server>

     Der Softwareupdatepunkt für Clientinstallation und Softwareupdates muss derselbe Server sein. Außerdem muss er in der Einstellung Active Directory Gruppenrichtlinie mit dem richtigen Namensformat und den richtigen Portinformationen angegeben werden. Dies wäre <http://server1.contoso.com:80> z. B. der, wenn der Softwareupdatepunkt die Standardwebsite verwendet.

  2. Wenn die Server-URL korrekt ist, greifen Sie mithilfe einer URL ähnlich der folgenden auf den Server zu, um die Konnektivität zwischen dem Client und dem WSUS-Computer zu überprüfen:

     <http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab>

     Um zu überprüfen, ob der Client auf das ClientWebService virtuelle Verzeichnis zugreifen kann, versuchen Sie, auf eine URL zuzugreifen, die der folgenden ähnelt:

     <http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml>

     Um zu überprüfen, ob der Client auf zugreifen SimpleAuthWebServicekann, versuchen Sie, auf eine URL zuzugreifen, die der folgenden ähnelt:

     <http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx>

     Wenn eine dieser URLs fehlschlägt, sind einige der möglichen Gründe:

     • Probleme bei der Namensauflösung auf dem Client. Vergewissern Sie sich, dass Sie den FQDN des WSUS-Computers auflösen können.

     • Proxykonfigurationsprobleme.

     • Andere netzwerkbezogene Konnektivitätsprobleme.

     • Probleme mit der Portkonfiguration, daher empfiehlt es sich, zu überprüfen, ob die Porteinstellungen korrekt sind. WSUS kann für die Verwendung eines der folgenden Ports konfiguriert werden: 80, 443 oder 8530, 8531.

       Damit Clients mit dem WSUS-Computer kommunizieren können, müssen die entsprechenden Ports in der Firewall auf dem WSUS-Computer zulässig sein. Porteinstellungen werden konfiguriert, wenn die Standortsystemrolle des Softwareupdatepunkts erstellt wird. Diese Porteinstellungen müssen mit den Porteinstellungen identisch sein, die von der WSUS-Website verwendet werden. Andernfalls kann der WSUS-Synchronisierungs-Manager keine Verbindung mit WSUS herstellen, die auf dem Softwareupdatepunkt ausgeführt wird, um die Synchronisierung anzufordern. Die folgenden Verfahren enthalten Informationen zum Überprüfen der von WSUS verwendeten Porteinstellungen und des Softwareupdatepunkts.

       1. Bestimmen Sie die WSUS-Porteinstellungen, die in IIS 7.0 und höheren Versionen verwendet werden.

       2. Bestimmen Sie die WSUS-Porteinstellungen in IIS 6.0.

       3. Konfigurieren Sie Ports für den Softwareupdatepunkt.

       4. Überprüfen der Portkonnektivität

          Führen Sie den folgenden Befehl aus, um die Portkonnektivität vom Client zu überprüfen:

          telnet SUPSERVER.CONTOSO.COM <portnumber>
          

          Führen Sie beispielsweise den folgenden Befehl aus, wenn der Port 8530 ist:

          telnet SUPSERVER.CONTOSO.COM 8530
          

          Wenn auf den Port nicht zugegriffen werden kann, gibt telnet einen Fehler zurück, der dem folgenden ähnelt:

          Die Verbindung mit dem Host konnte am Port <PortNummer nicht geöffnet werden.>

          Dieser Fehler deutet darauf hin, dass die Firewallregeln nicht so konfiguriert sind, dass sie die Kommunikation für den WSUS-Computer zulassen. Dieser Fehler kann auch darauf hindeuten, dass ein Zwischennetzwerkgerät diesen Port blockiert. Führen Sie zur Überprüfung denselben Test von einem Client im selben lokalen Subnetz aus. Wenn dies funktioniert, sind die Computer ordnungsgemäß konfiguriert. Ein Router oder eine Firewall zwischen Segmenten blockiert jedoch den Port und verursacht den Fehler.

     • IIS-Verfügbarkeitsprobleme.

       1. Öffnen Sie auf dem WSUS-Computer den Internetinformationsdienste-Manager (IIS).
       2. Erweitern Sie Websites, klicken Sie mit der rechten Maustaste auf die Website für den WSUS-Computer, und klicken Sie dann auf Bindungen bearbeiten.
       3. Im Dialogfeld Websitebindungen werden die Http- und HTTPS-Portwerte in der Spalte Port angezeigt.
       4. Öffnen Sie auf dem WSUS-Server den IIS-Manager (Internetinformationsdienste).
       5. Erweitern Sie Websites, klicken Sie mit der rechten Maustaste auf die Website für den WSUS-Computer, und klicken Sie dann auf Eigenschaften.
       6. Klicken Sie auf die Registerkarte Website . Die HTTP-Porteinstellung wird im TCP-Port und die HTTPS-Porteinstellung im SSL-Port angezeigt.
       7. Wechseln Sie in der Configuration Manager-Konsole zu Verwaltung>Standortkonfigurationsserver>und Standortsystemrollen, und klicken Sie dann auf der rechten Seite auf SiteSystemName><.
       8. Klicken Sie im unteren Bereich mit der rechten Maustaste auf Softwareupdatepunkt , und klicken Sie dann auf Eigenschaften.
       9. Wechseln Sie zur Registerkarte Allgemein , und geben Sie die Portnummern der WSUS-Konfiguration an, oder überprüfen Sie sie.

• Authentifizierungsfehler

  Dies wird in der Regel angezeigt, wenn die Überprüfung mit Authentifizierungsfehlern 0x80244017 (HTTP-Status 401) oder 0x80244018 (HTTP-Status 403) fehlschlägt.

  Bestätigen Sie zunächst die richtigen WinHTTP-Proxyeinstellungen mit den folgenden Befehlen:

  • Unter Windows Vista oder höheren Versionen: netsh winhttp show proxy
  • Unter Windows XP: proxycfg.exe

  Wenn die Proxyeinstellungen korrekt sind, überprüfen Sie die Konnektivität mit dem WSUS-Computer, indem Sie die Schritte unter HTTP-Timeoutfehler ausführen. Überprüfen Sie auch die IIS-Protokolle auf dem WSUS-Computer, um zu bestätigen, dass die HTTP-Fehler von WSUS zurückgegeben werden. Wenn der WSUS-Computer den Fehler nicht zurückgibt, liegt das Problem wahrscheinlich an einer Zwischenfirewall oder einem Proxy.

• Zertifikatprobleme

  Zertifikatprobleme werden durch den Fehlercode 0x80072F0C angegeben, was bedeutet, dass "Ein Zertifikat ist erforderlich, um die Clientauthentifizierung abzuschließen". Informationen zum Beheben dieses Problems finden Sie unter Fehler bei der Überprüfung 0x80072f0c.

Schritt 4: WUAHandler empfängt Ergebnisse von Windows Update Agent und markiert die Überprüfung als abgeschlossen.

Die folgenden Werden in WUAHandler.log protokolliert:

Async searching completed.  
Finished searching for everything in single call.

Behandeln von Problemen in Schritt 4

Probleme sollten hier genauso behandelt werden wie Scanfehler in Schritt 3.

Wie bereits erwähnt, überprüfen Sie bei der Problembehandlung von Scanfehlern die WUAHandler.log und WindowsUpdate.log Dateien. WUAHandler meldet einfach, was Windows Update-Agent gemeldet hat. Der Fehler in WUAHandler wäre also derselbe Fehler, der vom Windows Update-Agent selbst gemeldet wurde. Weitere Informationen zum Fehler finden Sie unter WindowsUpdate.log. Informationen zum Lesen WindowsUpdate.log finden Sie unter Windows Update Protokolldateien.

Es gibt viele Gründe, warum ein Softwareupdatescan fehlschlägt. Es kann durch eines der oben erwähnten Probleme oder durch ein Kommunikations- oder Firewallproblem zwischen dem Client und dem Softwareupdatepunktcomputer verursacht werden. Ihre beste Informationsquelle stammt aus den Protokollen und den darin enthaltenen Fehlercodes. Weitere Informationen zu den Fehlercodes finden Sie unter Windows Update häufig auftretende Fehler und Entschärfung.

Schritt 5: WUAHandler analysiert die Scanergebnisse

WUAHandler analysiert dann die Ergebnisse, einschließlich des Anwendbarkeitszustands für jedes Update. Im Rahmen dieses Prozesses werden abgelöste Updates entfernt. Der Anwendbarkeitsstatus wird auf alle Updates überprüft, die den Kriterien entsprechen, die von CCMExec an den Windows Update-Agent übermittelt werden. Wichtig ist hier, dass Sie Anwendbarkeitsergebnisse für Updates sehen sollten, unabhängig davon, ob sich diese Updates in einer Bereitstellung befinden oder nicht.

Die folgenden Einträge werden WUAHandler.log protokolliert:

> Pruning: update id (70f4f236-0248-4e84-b472-292913576fa1) is superseded by (726b7201-862a-4fde-9b12-f36b38323a6f).  
> ...  
> Update (Installed): Security Update for Windows 7 for x64-based Systems (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104)  
> Update (Missing): Security Update for Windows 7 for x64-based Systems (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200)  
> ...  
> Successfully completed scan.

Behandeln von Problemen in Schritt 5

Probleme können auf die gleiche Weise wie Scanfehler in Schritt 3 behoben werden.

Wie bereits erwähnt, überprüfen Sie bei der Problembehandlung von Scanfehlern die WUAHandler.log und WindowsUpdate.log Dateien. WUAHandler meldet einfach, was Windows Update-Agent gemeldet hat. Der Fehler in WUAHandler wäre also derselbe Fehler, der vom Windows Update-Agent selbst gemeldet wurde. Weitere Informationen zum Fehler finden Sie unter WindowsUpdate.log. Informationen zum Lesen WindowsUpdate.log finden Sie unter Windows Update Protokolldateien.

Im Allgemeinen gibt es viele Gründe, warum ein Softwareupdatescan fehlschlägt. Es kann durch eines der oben genannten Probleme oder durch ein Kommunikations- oder Firewallproblem zwischen dem Client und dem Softwareupdatepunktcomputer verursacht werden. Ihre beste Informationsquelle stammt aus den Protokollen und den darin enthaltenen Fehlercodes. Als Referenz finden Sie Windows Update häufig auftretende Fehler und Risikominderung.

Schritt 6: Updatespeicher zeichnet die status auf und löst eine Statusmeldung für jedes Update in WMI aus.

Sobald die Überprüfungsergebnisse verfügbar sind, werden diese Ergebnisse im Updatespeicher gespeichert. Der Updatespeicher zeichnet den aktuellen Status jedes Updates auf und erstellt für jedes Update eine Statusmeldung. Diese Zustandsmeldungen werden am Ende des status Nachrichtenberichtszyklus (standardmäßig Minuten) massenweise an den Standortserver weitergeleitet. Wir senden eine Statusmeldung nur unter den folgenden Umständen:

• Eine vorherige Statusmeldung wurde noch nie für ein Update gesendet (Protokolleintrag: wurde noch nicht gemeldet, neue instance erstellt).
• Der Anwendbarkeitsstatus für ein Update hat sich seit dem Senden der letzten Statusmeldung geändert.

UpdatesStore.log, der den Status für fehlendes Update (KB2862152) anzeigt, das aufgezeichnet wird, und eine Statusmeldung, die ausgelöst wird:

Processing update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) with ProductID = 0fa1201d-4330-4fa8-8ae9b877473b6441  
Update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) hasn't been reported before, creating new instance.  
Successfully raised state message for update (505fda07-b4f3-45fb-83d9-8642554e2773) with state (Missing).  
Successfully added WMI instance of update status (505fda07-b4f3-45fb-83d9-8642554e2773).

StateMessage.log, dass die Statusmeldung mit der Status-ID 2 (fehlt) aufgezeichnet wird:

Adding message with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 to WMI  
State message(State ID : 2) with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 has been recorded for SYSTEM

Tipp

Für jedes Update wird ein instance der CCM_UpdateStatus -Klasse erstellt oder aktualisiert, und es wird die aktuelle status des Updates gespeichert. Die CCM_UpdateStatus -Klasse befindet sich im ROOT\CCM\SoftwareUpdates\UpdatesStore -Namespace.

Behandeln von Problemen in Schritt 6

Probleme sollten hier genauso behandelt werden wie Scanfehler in Schritt 3.

Wie bereits erwähnt, überprüfen Sie bei der Problembehandlung von Scanfehlern die WUAHandler.log und WindowsUpdate.log Dateien. WUAHandler meldet einfach, was Windows Update-Agent gemeldet hat. Der Fehler in WUAHandler wäre also derselbe Fehler, der vom Windows Update-Agent selbst gemeldet wurde. Weitere Informationen zum Fehler finden Sie unter WindowsUpdate.log. Informationen zum Lesen WindowsUpdate.log finden Sie unter Windows Update Protokolldateien.

Im Allgemeinen gibt es viele Gründe, warum ein Softwareupdatescan fehlschlägt. Es kann durch eines der oben genannten Probleme oder durch ein Kommunikations- oder Firewallproblem zwischen dem Client und dem Softwareupdatepunktcomputer verursacht werden. Ihre beste Informationsquelle stammt aus den Protokollen und den darin enthaltenen Fehlercodes. Als Referenz finden Sie Windows Update häufig auftretende Fehler und Risikominderung.

Schritt 7: Statusmeldungen werden an den Verwaltungspunkt gesendet

Wenn WUAHandler die Ergebnisse vom Windows Update-Agent erfolgreich empfängt, markiert er die Überprüfung als abgeschlossen und protokolliert die folgende Meldung in WUAHandler.log:

Async searching completed. WUAHandler  
Finished searching for everything in single call

Behandeln von Problemen in Schritt 7

Probleme sollten hier genauso behandelt werden wie Scanfehler in Schritt 3, obwohl Fehler in dieser Phase wahrscheinlich in der WindowsUpdate.log-Datei angezeigt werden. Informationen zum Lesen WindowsUpdate.log finden Sie unter Windows Update Protokolldateien.

Im Allgemeinen gibt es viele Gründe, warum ein Softwareupdatescan fehlschlägt. Es kann durch eines der oben genannten Probleme oder durch ein Kommunikations- oder Firewallproblem zwischen dem Client und dem Softwareupdatepunktcomputer verursacht werden. Ihre beste Informationsquelle stammt aus den Protokollen und den darin enthaltenen Fehlercodes. Als Referenz finden Sie Windows Update häufig auftretende Fehler und Risikominderung.

Synchronisierung von WSUS zu Microsoft Update

Die WSUS-Synchronisierung mit Microsoft Update wird in den folgenden Schritten beschrieben. Vergewissern Sie sich bei jedem Schritt, dass das Problem ordnungsgemäß festgelegt wird.

Schritt 1: Synchronisierung beginnt über eine geplante oder manuelle Anforderung

Wenn eine Synchronisierung ausgelöst wird, erwarten wir, dass die folgenden Meldungen im SoftwareDistribution.log des WSUS-Servers angezeigt werden:

Für die manuelle Synchronisierung:

Changew3wp.6AdminDataAccess.StartSubscriptionManuallySynchronization manually started  
Info WsusService.27EventLogEventReporter.ReportEvent  
EventId=382,Type=Information,Category=Synchronization,Message=A manual synchronization was started.

Für die geplante Synchronisierung:

InfoWsusService.10EventLogEventReporter.ReportEvent  
EventId=381,Type=Information,Category=Synchronization,Message=A scheduled synchronization was started.

Problembehandlung bei einer manuellen Synchronisierung in Schritt 1

1. Vergewissern Sie sich, dass der WSUS-Dienst ausgeführt wird. Wenn eine manuelle Synchronisierung gestartet wurde, aber bei 0 % bleibt, liegt dies daran, dass der WSUS-Dienst (Update Services auf WSUS 3.x; WSUSService in Windows Server 2012 und höheren Versionen) befindet sich in einem beendeten Zustand.

2. Setzen Sie den MMC-Cache der WSUS-Konsole wie folgt zurück:

   1. Schließen Sie die WSUS-Konsole.
   2. Beenden Sie den WSUS-Dienst (Update Services auf WSUS 3.x; WSUS-Dienst auf Windows Server 2012 und höheren Versionen).
   3. Navigieren Sie zu %appdata%\Microsoft\mmc.
   4. Benennen Sie wsus in wsus_bak um.
   5. Starten Sie den WSUS-Dienst.
   6. Öffnen Sie die WSUS-Konsole, und versuchen Sie es mit einer weiteren manuellen Synchronisierung.

Problembehandlung bei einer geplanten Synchronisierung in Schritt 1

1. Versuchen Sie eine manuelle Synchronisierung über die WSUS-Konsole.
2. Wenn eine manuelle Synchronisierung einwandfrei funktioniert, überprüfen Sie die Einstellungen für die geplante Synchronisierung.

Schritt 2: WSUS erstellt eine Verbindung mit Microsoft Update (MU)

Nachdem eine Synchronisierung gestartet wurde, versucht der WSUS-Server, eine HTTP-Verbindung über WinHTTP herzustellen. Berücksichtigen Sie bei der Problembehandlung der Verbindung die folgenden Faktoren:

WSUS <=winhttp=> Netzwerkentitäten <=> Internet

• Gibt es eine Netzwerkentität (Proxy, Firewall, Sicherheitsfilter usw.) zwischen dem WSUS-Hostcomputer und dem Internet?
• Wenn ein Proxy vorhanden ist und der WSUS-Server für die Verwendung des Proxys erforderlich ist, wird der Proxy dann in den richtigen WSUS-Einstellungen konfiguriert?

Problembehandlung bei einer manuellen Synchronisierung in Schritt 2

1. Vergewissern Sie sich, dass der WSUS-Dienst ausgeführt wird. Wenn eine manuelle Synchronisierung gestartet wurde, aber bei 0 % bleibt, liegt dies an dem WSUS-Dienst (Update Services auf WSUS 3.x; Der WSUS-Dienst auf Windows Server 2012 und höheren Versionen) befindet sich in einem beendeten Zustand.

2. Setzen Sie den MMC-Cache der WSUS-Konsole zurück, indem Sie die folgenden Schritte ausführen:

   1. Schließen Sie die WSUS-Konsole.
   2. Beenden Sie den WSUS-Dienst (Update Services auf WSUS 3.x; WSUS-Dienst auf Windows Server 2012 und höheren Versionen).
   3. Navigieren Sie zu %appdata%\Microsoft\mmc.
   4. Benennen Sie wsus in wsus_bak um.
   5. Starten Sie den WSUS-Dienst.
   6. Öffnen Sie die WSUS-Konsole, und versuchen Sie es mit einer weiteren manuellen Synchronisierung.

Problembehandlung bei einer geplanten Synchronisierung in Schritt 2

1. Versuchen Sie eine manuelle Synchronisierung über die WSUS-Konsole.
2. Wenn eine manuelle Synchronisierung einwandfrei funktioniert, überprüfen Sie die Einstellungen für die geplante Synchronisierung.

Schritt 3: Der WSUS-Computer empfängt Produkt- und Klassifizierungsinformationen von Microsoft Update und alle abonnierten Metadaten.

Nachdem WSUS Produkt- und Klassifizierungsinformationen sowie alle abonnierten Metadaten von Microsoft Update empfangen hat, ist die WSUS-Synchronisierung abgeschlossen.

Installation, Ablösung oder Erkennung von Problemen mit bestimmten Updates

Bereitstellungsprobleme, die bei bestimmten Updates auftreten, können in die folgenden Bereiche unterteilt werden. Wenn Sie mit der Problembehandlung beginnen, sollten Sie die folgenden Komponenten berücksichtigen, die diesen Bereichen zugeordnet sind.

Bereiche	Installation	Ablösung	Erkennung
Komponenten	WUA Updateinstallationsprogramm (komponentenbasierte Wartung (CBS), MSI) Ccmexec	Metadaten aktualisieren	WUA Metadaten aktualisieren Updateinstallationsprogramm (CBS, MSI)

Installationsprobleme

Was ist das Installationsprogramm (CBS, MSI, andere)?

CBS

Für Updates, die für Windows Vista und höhere Versionen gelten, wird CBS für die Installation verwendet.

1. Erfassen Sie das CBS-Protokoll (%Windir%\Logs\Cbs\Cbs.log), und führen Sie eine erste Überprüfung durch, um Einen Einblick in die Ursache des Fehlers zu erhalten. Die Behandlung von installationsbasierten Problemen über CBS-Protokolle geht über den Rahmen dieses Leitfadens hinaus. Weitere Informationen finden Sie unter Beheben von Windows-Beschädigungsfehlern mithilfe des DISM- oder Systemupdatebereitschaftstools.
2. Wird das Update erfolgreich als angemeldeter Benutzer installiert? Wenn dies der Fall ist, schlägt es nur fehl, wenn es unter dem Systemkontext installiert wird? Konzentrieren Sie sich in diesem Fall auf die Problembehandlung des manuellen Installationsfehlers im Systemkontext.

MSI (Windows Installer)

Bei Nicht-Windows-Softwareupdates wird msi verwendet, um die Installation zu verarbeiten.

1. Sammeln und überprüfen Sie die STANDARD-MSI-Protokolle für das Update. Informationen zu bekannten Problemen oder häufig gestellten Fragen finden Sie im zugehörigen KB-Artikel für das Update.

2. Aktivieren Sie die Windows Installer-Protokollierung , und reproduzieren Sie den Fehler.

   Überprüfen Sie beim Überprüfen der resultierenden Protokolle den Rückgabewert 3 im Protokoll und die Zeilen vor diesem Eintrag, um Einen Einblick in den Fehler zu erhalten.

3. Überprüfen Sie, ob dasselbe Update nicht manuell im lokalen Systemkontext installiert werden kann. Verwenden Sie dazu dieselben Installationsschalter, die während der Softwareupdatebereitstellung fehlgeschlagen sind.

   Wenn ein Fehler auftritt, testen Sie die Installation als angemeldeter Benutzer mit den gleichen Installationsoptionen. Überprüfen Sie, ob es sich um ein Problem bei der Installation unter dem lokalen System handelt. Wenn dies funktioniert, können Sie das Problem auf die ordnungsgemäße Installation des Updates mithilfe des lokalen Systemkontexts konzentrieren. Es kann erforderlich sein, in der Wissensdatenbank für das Update oder online nach administrativen Bereitstellungsanleitungen zu suchen.

Ablösungsprobleme

Versuchen Sie, das Problem im Zusammenhang mit der Ablösung zu isolieren, indem Sie die folgenden Fragen verwenden:

1. Fragen zum Steuern, wann Configuration Manager ein Update abläuft, finden Sie unter Ablösungsregeln.
2. Wenn ein Update von Configuration Manager abgelaufen ist, empfiehlt Microsoft, das neueste ablösende Update bereitzustellen. Wenn Sie die abgelaufenen Updates weiterhin bereitstellen müssen, können sie außerhalb einer Softwareupdatebereitstellung über Softwareverteilung oder Anwendungsverwaltung bereitgestellt werden.
3. Bei Fragen, die sich speziell auf die Ablösungslogik eines Updates beziehen, lesen Sie zunächst den KB-Artikel für das Update, um weitere Informationen zu erhalten. Sie können die Ablösung auch im Microsoft Update-Katalog, in der WSUS-Konsole oder in der Configuration Manager-Konsole überprüfen.

Erkennungsprobleme

Ermitteln des Konformitätsstatus pro Update auf einem Client

1. Informationen zu bekannten Problemen mit dem Update finden Sie im Kb-Artikel zum Update.
2. Führen Sie die Aktion Software Updates Scanzyklus auf dem Configuration Manager-Client aus.
3. Überprüfen Sie UpdatesStore.log und WindowsUpdate.log.

Problembehandlung bei der Anwendbarkeit von Updates

1. Überprüfen Sie anhand des KB-Artikels für das Update, ob erforderliche Komponenten fehlen. Erfordert das Update beispielsweise, dass die Anwendung oder das Betriebssystem auf eine bestimmte Service Pack-Ebene gepatcht wird?
2. Vergewissern Sie sich, dass die eindeutige Update-ID des betreffenden Updates mit dem bereitgestellten Update übereinstimmt. Ist das betreffende Update beispielsweise ein 32-Bit-Update, das auf einen 64-Bit-Host abzielt?

Weitere Informationen

Weitere Informationen zum Konfigurieren von Softwareupdates in Configuration Manager finden Sie in den folgenden Artikeln:

• Planen von Softwareupdates in Configuration Manager
• Konfigurieren eines Softwareupdatepunkts für die Verwendung eines NLB-Clusters (Netzwerklastenausgleich)
• Aktivieren der Zertifikatsperrlistenüberprüfung für Software-Updates

Sie können hier auch eine Frage in unserem Configuration Manager Supportforum zu Sicherheit, Updates und Compliance stellen.

Besuchen Sie unseren Blog, um die neuesten Nachrichten, Informationen und Technischen Tipps zu Configuration Manager.