Freigeben über

Problembehandlung bei der Verwaltung von Softwareupdates in Configuration Manager

  • Artikel

Dieser Artikel hilft Ihnen bei der Problembehandlung des Softwareupdateverwaltungsprozesses in Configuration Manager. Es umfasst die Überprüfung von Clientsoftwareupdates, Synchronisierungsproblemen 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

Umfang Ihres Problems

In diesem Handbuch 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, ist es wichtig zu betonen, dass Sie das Problem besser verstehen, das Sie erleben, desto schneller und einfacher ist es für Sie, es zu beheben. Ganz gleich, ob Sie mit der Behebung eines Problems, das Sie haben, oder ein Problem, das Ihnen von einer Person in Ihrer Organisation gemeldet wurde, einen Moment in Anspruch nehmen und die folgenden Fragen beantworten:

  1. Was funktioniert nicht und/oder was ist Ihr Ziel?
  2. Was ist die Häufigkeit oder das Muster für das Problem? Tritt das Problem noch auf?
  3. Wie sind Sie sich bewusst geworden, dass das Problem besteht?
  4. Hat es jemals geklappt? Wenn ja, wann hat es beendet? Hat sich etwas in der Umgebung geändert, bevor es nicht mehr funktioniert?
  5. Welcher Prozentsatz der Clients ist betroffen?
  6. Was wurde bereits getan (falls vorhanden), um 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, erhalten Sie den besten Weg, um eine schnelle und einfache Lösung für das problem zu finden, das Sie erleben.

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 nicht sicher sind, und wir werden den gesamten Prozess von Anfang bis Ende durchgehen.

Überprüfung von Clientsoftwareupdates

Der Clientscanprozess wird in den folgenden Schritten beschrieben. Bestätigen Sie jeden Schritt, um den Speicherort des Problems ordnungsgemäß festzulegen.

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 verwendet wird. Dieser Prozess ist unten ausführlich beschrieben.

  1. Wenn der Configuration Manager-Client eine Softwareupdateüberprüfung verarbeiten muss, erstellt der Scan-Agent eine Scananforderung 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. Scan-Agent sendet jetzt eine WSUS-Standortanforderung an Location Services, 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: Klasse: root\CCM\ScanAgentCCM_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. Nachdem die Ergebnisse aus der gespeicherten Prozedur abgerufen wurden, 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 an die Standortdienste zurück. 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 Speicherort der Updatequelle 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, um die Updatequelle hinzuzufügen. WUAHandler fügt der Registrierung die Updatequelle hinzu. Es initiiert eine Gruppenrichtlinienaktualisierung, wenn sich der Client in der Domäne befindet, um festzustellen, ob die Gruppenrichtlinie den hinzugefügten Updateserver außer Kraft setzt. Die folgenden Einträge werden in WUAHandler.log protokolliert, in dem eine neue Updatequelle angezeigt wird, 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 WSUS-Konfigurationsänderung. 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 des Ports. 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 des Ports. 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önnte erwartet werden, dass die folgende Meldung in WUAHandler.log angezeigt wird, wenn 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 den Scan. 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 Was soll überprüft werden?
ScanAgent.log zeigt keine Richtlinie an, die für eine Updatequelle verfügbar ist und keine WUAHandler.log vorhanden ist oder keine aktuelle Aktivität innerhalb WUAHandler.log Überprüfen Sie die Einstellung "Softwareupdates auf Clients aktivieren".
Scan-Agent oder Standortdienste empfangen nicht den WSUS-Serverspeicherort.

  • Ist eine SUP-Rolle (SoftwareUpdate Point) für die Website 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, ist 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, konfiguriert jedoch die WSUS-Registrierungsschlüssel nicht.

Hat die Gruppenrichtlinienaktualisierung innerhalb des 2-Minuten-Timeouts pro WUAHandler.log geantwortet? Ist dies der Fall , gibt WUAHandler an, dass Gruppenrichtlinieneinstellungen 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 Softwareupdate-Überprüfungsfehlern finden Sie unter "Problembehandlung bei Softwareupdatescanfehlern".

Schritt 2: Scan-Agent fordert den Scan an, und WUAHandler startet den Scan.

Nachdem der Client den WSUS-Server identifiziert und festgelegt hat, der seine Updatequelle für Softwareupdatescans sein wird, fordert Scan-Agent den Scan von WUAHandler an, der die Windows Update Agent-API verwendet, um einen Softwareupdatescan vom Windows Update-Agent anzufordern. Eine Überprüfung kann aus:

  • Ein geplanter oder manueller Softwareupdatescan
  • Eine geplante oder manuelle Software, die die Erneute Auswertung der Bereitstellung aktualisiert hat
  • 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 abgelöste 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 vorhanden sind, gibt sie an, dass keine SUP vom Verwaltungspunkt zurückgegeben wird.

Behandeln von Problemen in Schritt 2

Viele Probleme mit der Softwareupdateüberprüfung können durch einen der folgenden Ursachen 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 Aktualisierungsüberprüfung anfordert, keine Überprüfungsergebnisse an Configuration Manager zurückgibt. Der Client meldet einen falschen Compliancestatus, und die Updates werden nicht installiert, wenn Configuration Manager den Updatezyklus anfordert. Wenn Sie jedoch das Windows Update-Systemsteuerungs-Applet verwenden, installieren die Updates in der Regel einwandfrei. Wenn dieses Problem auftritt, erhalten Sie in WindowsUpdate.log eine Ähnliche Meldung wie die folgende:

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

Es handelt sich um ein Speicherzuweisungsproblem, 64-Bit-Windows 7-Computer werden diesen Fehler nicht sehen, da ihr Adressraum effektiv unbegrenzt ist. Sie weisen jedoch einen hohen Arbeitsspeicher und eine hohe CPU-Auslastung auf, was sich möglicherweise auf die Leistung auswirkt. X86-Clients weisen auch eine hohe Speicherauslastung auf (in der Regel ca. 1,2 GB bis 1,4 GB).

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

Überprüfen Sie bei der Problembehandlung von Scanfehlern die dateien WUAHandler.log und WindowsUpdate.log. WUAHandler meldet einfach, was der 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 in WindowsUpdate.log. Informationen zum Lesen von 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 Allgemeine Fehler und Entschärfung von Windows Update.

Schritt 3: Der Windows Update-Agent (WUA) startet den Scan auf dem WSUS-Computer.

Der 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 ein gültiges SUP für den Standort über eine lokale Richtlinie ist, 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 und SimpleAuthWebService virtuellen Verzeichnissen auf dem WSUS-Computer kommunizieren, um eine Überprüfung durchzuführen. Wenn der Client nicht mit dem WSUS-Computer kommunizieren kann, schlägt die Überprüfung fehl. Dieses Problem kann aus vielen Gründen auftreten, darunter:

  • Probleme im Zusammenhang mit Proxys

    Informationen zum Beheben dieser Probleme finden Sie unter Scanfehler aufgrund von Proxyproblemen.

    Weitere Informationen zu Proxyservern finden Sie in den folgenden Artikeln:

  • HTTP-Timeoutfehler

    Um HTTP-Timeoutfehler zu beheben, überprüfen Sie zunächst die Internetinformationsdienste (IIS)-Protokolle 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 bei einer Zwischenfirewall oder einem Proxy vor.

    Wenn der WSUS-Computer den Fehler zurückgibt, überprüfen Sie die Verbindung mit dem WSUS-Computer. Im Folgenden werden die Schritte 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 kann gefunden werden, 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, warum die WSUS-Zuordnung falsch sein kann, sind:

      • Gruppenrichtlinienkonflikte
      • Das Hinzufügen einer SUP zu einem sekundären Standort nach der erstinstallation des Clients

      Notiz

      Active Directory-Gruppenrichtlinien können die lokale WSUS-Richtlinie außer Kraft setzen.

      Das Feature für Softwareupdates konfiguriert automatisch eine lokale Gruppenrichtlinieneinstellung für den Configuration Manager-Client, sodass sie mit dem Quellspeicherort und der Portnummer des Softwareupdatepunkts konfiguriert ist. Sowohl der Servername als auch die Portnummer sind erforderlich, damit der Client den Softwareupdatepunkt finden kann.

      Wenn eine Active Directory-Gruppenrichtlinieneinstellung auf Computer für die Installation des Softwareupdatepunktclients angewendet wird, setzt sie die lokale Gruppenrichtlinieneinstellung außer Kraft. Wenn sich der Wert der in der Active Directory-Gruppenrichtlinie definierten Einstellung von der von Configuration Manager festgelegten Einstellung unterscheidet, schlägt die Überprüfung auf dem Client fehl, da sie den richtigen WSUS-Computer nicht finden kann. In diesem Fall zeigt WUAHandler.log die folgende Meldung an:

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

      Der Softwareupdatepunkt für Clientinstallation und Softwareupdates muss derselbe Server sein. Außerdem muss sie in der Active Directory-Gruppenrichtlinieneinstellung mit den richtigen Namensformaten und Portinformationen angegeben werden. Beispielsweise würde <http://server1.contoso.com:80> der Softwareupdatepunkt die Standardwebsite verwenden.

    2. Wenn die Server-URL korrekt ist, greifen Sie mit einer URL wie der folgenden auf den Server zu, um die Verbindung 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 die URL zugreifen kann, versuchen Sie, auf eine url zuzugreifen, die SimpleAuthWebServiceder 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. Stellen Sie sicher, dass Sie den FQDN des WSUS-Computers auflösen können.

      • Proxykonfigurationsprobleme.

      • Andere netzwerkbezogene Konnektivitätsprobleme.

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

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

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

        2. Ermitteln 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 der folgenden ähnelt:

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

          Dieser Fehler deutet darauf hin, dass die Firewallregeln nicht so konfiguriert sind, dass die Kommunikation für den WSUS-Computer zugelassen wird. Dieser Fehler kann auch vorschlagen, dass ein Zwischennetzwerkgerät diesen Port blockiert. Um dies zu überprüfen, probieren Sie denselben Test von einem Client im selben lokalen Subnetz aus. Wenn dies funktioniert, werden 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 Internetinformationsdienste (IIS)-Manager.
        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 Internetinformationsdienste (IIS)-Manager.
        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 angezeigt, und die HTTPS-Porteinstellung wird im SSL-Port angezeigt.
        7. Wechseln Sie in der Configuration Manager-Konsole zu Verwaltungsstandortkonfigurationsservern>>und Standortsystemrollen, und klicken Sie dann auf den< Rechten Bereich "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 ", geben Sie die WSUS-Konfigurationsportnummern an, oder überprüfen Sie sie.

  • Authentifizierungsfehler

    Es wird in der Regel angegeben, 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 mithilfe der folgenden Befehle:

    • Unter Windows Vista oder neueren Versionen: netsh winhttp show proxy
    • Unter Windows XP: proxycfg.exe

    Wenn die Proxyeinstellungen korrekt sind, überprüfen Sie die Verbindung mit dem WSUS-Computer, indem Sie die Schritte in HTTP-Timeoutfehlern ausführen. Überprüfen Sie außerdem 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 bei einer Zwischenfirewall oder einem Proxy vor.

  • Zertifikatprobleme

    Zertifikatprobleme werden durch Fehlercode 0x80072F0C angegeben, d. h., "Ein Zertifikat ist erforderlich, um die Clientauthentifizierung abzuschließen". Informationen zum Beheben dieses Problems finden Sie unter "Scan schlägt mit fehler 0x80072f0c fehl.

Schritt 4: WUAHandler empfängt Ergebnisse vom Windows Update-Agent und kennzeichnet den Scan als abgeschlossen.

Nachfolgend sind WUAHandler.log protokolliert:

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

Behandeln von Problemen in Schritt 4

Hier sollten Probleme auf die gleiche Weise behoben werden wie Scanfehler in Schritt 3.

Wie weiter oben in diesem Handbuch erwähnt, überprüfen Sie beim Beheben von Scanfehlern die dateien WUAHandler.log und WindowsUpdate.log. WUAHandler meldet einfach, was der 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 in WindowsUpdate.log. Informationen zum Lesen von 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 Allgemeine Fehler und Entschärfung von Windows Update.

Schritt 5: WUAHandler analysiert die Scanergebnisse

WUAHandler analysiert dann die Ergebnisse, die den Anwendbarkeitsstatus für jedes Update enthalten. Im Rahmen dieses Prozesses werden abgelöste Updates ausgeschnitten. Der Anwendbarkeitsstatus wird auf alle Updates überprüft, die an den von CCMExec an den Windows Update-Agent übermittelten Kriterien ausgerichtet sind. Es ist wichtig zu verstehen, dass Sie anwendbare Ergebnisse für Updates sehen sollten, unabhängig davon, ob sich diese Updates in einer Bereitstellung befinden oder nicht.

Die folgenden Einträge werden in 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 behoben werden wie Scanfehler in Schritt 3.

Wie weiter oben in diesem Handbuch erwähnt, überprüfen Sie beim Beheben von Scanfehlern die dateien WUAHandler.log und WindowsUpdate.log. WUAHandler meldet einfach, was der 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 in WindowsUpdate.log. Informationen zum Lesen von 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 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. Eine Referenz finden Sie unter Windows Update häufige Fehler und Entschärfung.

Schritt 6: Aktualisieren des Speichers zeichnet den Status auf und löst eine Statusmeldung für jedes Update in WMI aus.

Sobald die Scanergebnisse verfügbar sind, werden diese Ergebnisse im Aktualisierungsspeicher gespeichert. Der Updatespeicher zeichnet den aktuellen Status jeder Aktualisierung auf und erstellt eine Statusmeldung für jedes Update. Diese Statusmeldungen werden am Ende des Statusmeldungsberichtszyklus (standardmäßig minutenweise) an den Standortserver weitergeleitet. Wir senden nur eine Statusnachricht unter den folgenden Umständen:

  • Eine vorherige Statusnachricht wurde noch nie für eine Aktualisierung gesendet (Protokolleintrag: wurde noch nicht gemeldet, neue Instanz erstellt).
  • Der Anwendbarkeitsstatus für eine Aktualisierung wurde seit der letzten Statusmeldung geändert.

UpdatesStore.log den Zustand für fehlende Aktualisierungen (KB2862152) anzeigen, die aufgezeichnet werden, 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 die Anzeige der Statusmeldung, die mit der Status-ID 2 aufgezeichnet wird (fehlt):

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 eine Instanz der CCM_UpdateStatus Klasse erstellt oder aktualisiert und speichert den aktuellen Status des Updates. Die CCM_UpdateStatus-Klasse befindet sich im ROOT\CCM\SoftwareUpdates\UpdatesStore-Namespace.

Behandeln von Problemen in Schritt 6

Hier sollten Probleme auf die gleiche Weise behoben werden wie Scanfehler in Schritt 3.

Wie weiter oben in diesem Handbuch erwähnt, überprüfen Sie beim Beheben von Scanfehlern die dateien WUAHandler.log und WindowsUpdate.log. WUAHandler meldet einfach, was der 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 in WindowsUpdate.log. Informationen zum Lesen von 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 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. Eine Referenz finden Sie unter Windows Update häufige Fehler und Entschärfung.

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

Hier sollten Probleme auf die gleiche Weise behoben werden wie Scanfehler in Schritt 3, obwohl Fehler in dieser Phase wahrscheinlich in der WindowsUpdate.log Datei speziell angezeigt werden. Informationen zum Lesen von 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 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. Eine Referenz finden Sie unter Windows Update häufige Fehler und Entschärfung.

WSUS zur Microsoft Update-Synchronisierung

Die WSUS-Synchronisierung mit Microsoft Update wird in den folgenden Schritten beschrieben. Bestätigen Sie jeden Schritt, um den Speicherort des Problems ordnungsgemäß festzulegen.

Schritt 1: Die Synchronisierung beginnt mit einer geplanten oder manuellen 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 geplante Synchronisierung:

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

Behandeln von Problemen mit 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 unter Windows Server 2012 und höheren Versionen) befindet sich in einem angehaltenen 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 unter Windows Server 2012 und höher).
    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 für eine geplante Synchronisierung in Schritt 1

  1. Probieren Sie eine manuelle Synchronisierung über die WSUS-Konsole aus.
  2. Wenn eine manuelle Synchronisierung einwandfrei funktioniert, überprüfen Sie die geplanten Synchronisierungseinstellungen.

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

Nach dem Starten einer Synchronisierung versucht der WSUS-Server, eine HTTP-Verbindung über WinHTTP herzustellen. Berücksichtigen Sie bei der Problembehandlung bei 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 zum Verwenden des Proxys erforderlich ist, ist der Proxy 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, sie aber bei 0 % bleibt, liegt dies daran, dass der WSUS-Dienst (Update Services auf WSUS 3.x; WSUS-Dienst unter Windows Server 2012 und höheren Versionen) befindet sich in einem angehaltenen 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 unter Windows Server 2012 und höher).
    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 für eine geplante Synchronisierung in Schritt 2

  1. Probieren Sie eine manuelle Synchronisierung über die WSUS-Konsole aus.
  2. Wenn eine manuelle Synchronisierung einwandfrei funktioniert, überprüfen Sie die geplanten Synchronisierungseinstellungen.

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

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

Installations-, Supersedence- oder Erkennungsprobleme mit bestimmten Updates

Bereitstellungsprobleme, die mit bestimmten Updates auftreten, können in die folgenden Bereiche unterteilt werden. Berücksichtigen Sie beim Beginn der Problembehandlung die folgenden Komponenten, die diesen Bereichen zugeordnet sind.

Bereiche Installation Ablösung Erkennung
Komponenten
  • WUA
  • Update Installer (komponentenbasierte Wartung (CBS), MSI)
  • CCMExec
 Aktualisieren von Metadaten
  • WUA
  • Aktualisieren von Metadaten
  • Update Installer (CBS, MSI)

Probleme bei der Installation

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 Behandlung der Installation verwendet.

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

MSI (Windows Installer)

Bei Nicht-Windows-Softwareupdates wird MSI zum Behandeln der Installation verwendet.

  1. Sammeln und überprüfen Sie die Standard-MSI-Protokolle für das Update. Überprüfen Sie den zugehörigen KB-Artikel für das Update auf bekannte Probleme oder häufig gestellte Fragen .Check the associated KB article for the update for any known issues or FAQ.

  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, die diesem Eintrag vorausgehen, um Einen Einblick in den Fehler zu erhalten.

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

    Wenn der Fehler auftritt, testen Sie die Installation als angemeldeter Benutzer mit denselben Installationsoptionen. Überprüfen Sie, ob es sich um ein Problem bei der Installation unter dem lokalen System handelt. Wenn dies funktioniert, können Sie sich auf das Problem konzentrieren, um das Update mithilfe des lokalen Systemkontexts ordnungsgemäß zu installieren. Es kann eine Überprüfung auf administrative Bereitstellungsanleitungen innerhalb der KB für das Update oder online erforderlich sein.

Supersedence-Probleme

Versuchen Sie, das Problem zu isolieren, das sich auf Übersehrungen bezieht, indem Sie die folgenden Fragen verwenden:

  1. Fragen zum Steuern, wann Configuration Manager ein Update abläuft, finden Sie unter "Supersedence rules".
  2. Wenn ein Update vom Configuration Manager abgelaufen ist, empfiehlt Microsoft, das neueste übergeordnete Update bereitgestellt zu werden. Wenn Sie die abgelaufenen Updates weiterhin bereitstellen müssen, können sie außerhalb einer Softwareupdatebereitstellung über die Softwareverteilung oder Anwendungsverwaltung bereitgestellt werden.
  3. Für Fragen, die sich speziell auf die Überdachtungslogik eines Updates beziehen, lesen Sie zunächst den KB-Artikel für das Update, um weitere Informationen zu erhalten. Sie können auch die Überschreibung innerhalb des Microsoft Update-Katalogs, der WSUS-Konsole oder der Configuration Manager-Konsole überprüfen.

Erkennungsprobleme

Ermitteln des Compliancestatus pro Update auf einem Client

  1. Überprüfen Sie den KB-Artikel für das Update auf bekannte Probleme mit dem Update.
  2. Führen Sie die Scanzyklusaktion für Softwareupdates 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, ob erforderliche Komponenten mit dem KB-Artikel für das Update 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 Element übereinstimmt. Ist das Update beispielsweise ein 32-Bit-Update, ist aber auf einen 64-Bit-Host ausgerichtet?

Weitere Informationen

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

Sie können auch eine Frage in unserem Configuration Manager-Supportforum für Sicherheit, Updates und Compliance hier posten.

Besuchen Sie unseren Blog , um alle aktuellen Neuigkeiten, Informationen und technischen Tipps zu Configuration Manager zu finden.