Felsöka hantering av programuppdateringar i Configuration Manager

Den här artikeln hjälper dig att felsöka processen för hantering av programuppdateringar i Configuration Manager. Den innehåller genomsökning av klientprogramuppdateringar, synkroniseringsproblem och identifieringsproblem med specifika uppdateringar.

Ursprunglig produktversion: Configuration Manager (aktuell gren), System Center 2012 R2 Configuration Manager, System Center 2012 Configuration Manager
Ursprungligt KB-nummer: 4505440

Omfång för problemet

Den här guiden förutsätter att en programuppdateringsplats redan har installerats och konfigurerats. Mer information om hur du konfigurerar programuppdateringar i Configuration Manager finns i Förbereda för hantering av programuppdateringar.

Innan du börjar felsöka är det viktigt att betona att ju bättre du förstår problemet du upplever, desto snabbare och enklare blir det för dig att åtgärda det. Oavsett om du har till uppgift att åtgärda ett problem som du upplever eller ett problem som rapporterats till dig av någon i din organisation kan du ta en stund och svara på följande frågor:

1. Vad fungerar inte specifikt och/eller vad är ditt mål?
2. Vad är frekvensen eller mönstret för problemet? Är problemet fortfarande händer?
3. Hur blev du medveten om att problemet finns?
4. Har det någonsin fungerat? I så fall, när slutade det? Ändrades något i miljön precis innan det slutade fungera?
5. Vilken procentandel av klienterna påverkas?
6. Vad har redan gjorts (om något) för att försöka åtgärda det?
7. Känna till den exakta versionen av klienten och serverns version. Är dessa system uppdaterade?
8. Vad har berörda klienter gemensamt? Till exempel samma undernät, AD-plats, domän, fysisk plats, plats, platssystem.

Att känna till och förstå svaren på dessa frågor ger dig den bästa vägen för en snabb och enkel lösning på alla problem du upplever.

Om du känner till det specifika området i programuppdateringshanteringsprocessen som du vill felsöka väljer du det nedan. Börja med genomsökning av klientprogramuppdateringar om du är osäker så går vi igenom hela processen från början till slut.

• Genomsökning av klientprogramuppdatering
• Synkronisering av WSUS till Microsoft Update
• Problem med installation, ersättning eller identifiering med specifika uppdateringar

Genomsökning av klientprogramuppdatering

Processen för klientgenomsökning beskrivs i följande steg. Bekräfta varje steg för att korrekt fastställa var problemet finns.

Steg 1: Klienten skickar en WSUS-platsbegäran till hanteringsplatsen

Det första klienten gör är att ange den WSUS-server som ska vara dess uppdateringskälla för programuppdateringsgenomsökningar. Den processen beskrivs nedan.

1. När Configuration Manager-klienten behöver bearbeta en programuppdateringsgenomsökning skapar Scan Agent en genomsökningsbegäran baserat på den tillgängliga principen enligt ScanAgent.log:

   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 skickar nu en WSUS-platsbegäran till Location Services enligt ScanAgent.log:

   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.
   

   Dricks

   Varje genomsökningsjobb lagras i WMI i CCM_ScanJobInstance klassen:

   Namnområde: root\CCM\ScanAgent Klass: CCM_ScanJobInstance

3. Location Services skapar en platsbegäran och skickar den till hanteringsplatsen. Paket-ID:t för en WSUS-platsbegäran är uppdateringskällans unika ID. I 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 skickar meddelandet för platsbegäran till hanteringsplatsen. I CcmMessaging.log:

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

5. Hanteringsplatsen parsar den här begäran och anropar den MP_GetWSUSServerLocations lagrade proceduren för att hämta WSUS-platserna från databasen. I 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
   

   I 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. När du har hämtat resultaten från den lagrade proceduren skickar hanteringsplatsen ett svar till klienten. I 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 tar emot svaret och skickar tillbaka det till Location Services. I 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 parsar svaret och skickar tillbaka platsen till Scan Agent. I 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. Scan Agent har nu principen och platsen för uppdateringskällan med rätt innehållsversion. I 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. Genomsökningsagenten meddelar WUAHandler om att lägga till uppdateringskällan. WUAHandler lägger till uppdateringskällan i registret. Den initierar en grupprincip uppdatering om klienten finns i domänen för att se om grupprincip åsidosätter uppdateringsservern som har lagts till. Följande poster loggas i WUAHandler.log som visar en ny uppdateringskälla som läggs till:

    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
    

    Under den här tiden ser Windows Update Agent en WSUS-konfigurationsändring. I WindowsUpdate.log:

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

    Följande registernycklar är markerade och inställda:

    Registerundernyckel	Värdenamn	Typ	Data
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate	WUServer	REG_SZ	Den fullständiga WSUS-server-URL:en inklusive porten. Till exempel: <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate	WUStatusServer	REG_SZ	Den fullständiga WSUS-server-URL:en inklusive porten. Till exempel: <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU	UseWUServer	REG_DWORD	0x1

    För en befintlig klient kan vi förvänta oss att se följande meddelande i WUAHandler.log att ange när innehållsversionen har ökat:

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

11. När uppdateringskällan har lagts till genererar Scan Agent ett tillståndsmeddelande och startar genomsökningen. I ScanAgent.log:

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

Felsöka problem i steg 1

Problem	Vad du ska kontrollera
ScanAgent.log visar ingen tillgänglig princip för en uppdateringskälla och ingen WUAHandler.log finns eller ingen aktuell aktivitet i WUAHandler.log	Kontrollera inställningen Aktivera programuppdateringar på klienter.
Genomsökningsagenten eller Location Services tar inte emot WSUS-serverplatsen	Är en programuppdateringsplats (SUP)-roll installerad för platsen? Annars installerar och konfigurerar du en programuppdateringsplats och övervakar SUPSetup.log för förlopp. Mer information finns i Installera och konfigurera en programuppdateringsplats. Om en SUP-roll är installerad, är den konfigurerad och synkroniserad? Kontrollera WCM.log, WSUSCtrl.log och WSyncMgr.log efter fel. select * from WSUSServerLocations select * from Update_SyncStatus
Klienten tar emot WSUS-platsen men kan inte konfigurera WSUS-registernycklarna	Svarade grupprincip uppdatering inom tidsgränsen på 2 minuter per WUAHandler.log? Skriver WUAHandler i så fall över grupprincipinställningar av en högre utfärdare (domänkontrollant)? Mer information finns i grupprincip åsidosätter rätt WSUS-konfigurationsinformation.

Mer information om felsökning av fel vid genomsökning av programuppdateringar finns i Felsöka programuppdateringssökningsfel.

Steg 2: Genomsökningsagenten begär genomsökningen och WUAHandler startar genomsökningen

När klienten har identifierat och angett den WSUS-server som ska vara dess uppdateringskälla för programuppdateringsgenomsökningar begär Scan Agent genomsökningen från WUAHandler som använder Windows Update Agent-API:et för att begära en programuppdateringsgenomsökning från Windows Update Agent. En genomsökning kan bero på:

• En schemalagd eller manuell genomsökning av programuppdateringar
• Omvärdering av schemalagd eller manuell programvara har uppdaterats
• En distribution som blir aktiv

Genomsökningen utlöser en utvärdering. I ScanAgent.log:

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

Genomsökningsresultaten inkluderar ersatta uppdateringar endast när de ersätts av servicepaket och definitionsuppdateringar. I 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.

Dricks

Granska WUAHandler.log efter en programuppdateringsgenomsökning för att se om några nya poster inträffar. Om inga nya poster inträffar anger det att ingen SUP returneras av hanteringsplatsen.

Felsöka problem i steg 2

Många problem med genomsökning av programuppdateringar kan orsakas av någon av följande orsaker:

• Saknade eller skadade filer eller registernycklar.
• Problem med komponentregistrering.

Information om hur du åtgärdar sådana problem finns i Genomsökningsfel på grund av saknade eller skadade komponenter.

Det finns ett känt problem med att en 32-bitars Windows 7 ConfigMgr 2012 R2-klient som begär en uppdateringsgenomsökning inte kan returnera genomsökningsresultat till Configuration Manager. Det gör att klienten rapporterar felaktig efterlevnadsstatus och uppdateringarna kan inte installeras när Configuration Manager begär uppdateringscykeln. Men om du använder Windows Update-kontrollpanelens applet installeras uppdateringarna vanligtvis bra. När du upplever det här problemet får du ett meddelande som liknar följande i WindowsUpdate.log:

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

Det är ett problem med minnesallokering, 64-bitars Windows 7-datorer ser inte det här felet eftersom deras adressutrymme i praktiken är obegränsat. De uppvisar dock hög minnesanvändning och hög CPU-användning, vilket kan påverka prestandan. X86-klienter har också hög minnesanvändning (vanligtvis cirka 1,2 GB till 1,4 GB).

Lös problemet genom att använda Windows Update-klienten för Windows 7: juni 2015.

När du felsöker genomsökningsfel kontrollerar du filerna WUAHandler.log och WindowsUpdate.log. WUAHandler rapporterar helt enkelt vad Windows Update Agent rapporterade. Felet i WUAHandler skulle därför vara samma fel som rapporterades av själva Windows Update-agenten. Mer information om felet finns i WindowsUpdate.log. Information om hur du läser WindowsUpdate.log finns i Windows Update-loggfiler.

Din bästa informationskälla kommer från loggarna och de felkoder som de innehåller. Mer information om felkoderna finns i Vanliga fel och åtgärder för Windows Update.

Steg 3: Windows Update Agent (WUA) startar genomsökningen mot WSUS-datorn

Windows Update Agent startar en genomsökning efter att ha tagit emot en begäran från Configuration Manager-klienten (CcmExec). Om dessa registervärden är korrekt inställda på en WSUS-dator som är en giltig SUP för platsen via en lokal princip bör du se en COM API-sökbegäran från Configuration Manager-klienten (ClientId = CcmExec). I 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]

Felsöka problem i steg 3

Under en genomsökning måste Windows Update-agenten kommunicera med och ClientWebService SimpleAuthWebService virtuella kataloger på WSUS-datorn för att utföra en genomsökning. Om klienten inte kan kommunicera med WSUS-datorn misslyckas genomsökningen. Det här problemet kan inträffa av många orsaker, bland annat:

• Proxyrelaterade problem

  Information om hur du åtgärdar dessa problem finns i Genomsökningsfel på grund av proxyrelaterade problem.

  Mer information om proxyservrar finns i följande artiklar:

  • Så här avgör Windows Update-klienten vilken proxyserver som ska användas för att ansluta till Windows Update-webbplatsen
  • DNS- och DHCP-stöd för automatisk upptäckt av webbproxy och brandväggsklient

• HTTP-timeoutfel

  Om du vill felsöka HTTP-timeoutfel granskar du först IIS-loggarna (Internet Information Services) på WSUS-datorn för att bekräfta att felen faktiskt returneras från WSUS. Om WSUS-datorn inte returnerar felet är problemet troligtvis med en mellanliggande brandvägg eller proxy.

  Om WSUS-datorn returnerar felet kontrollerar du anslutningen till WSUS-datorn. Här är stegen:

  1. För att bekräfta att klienten ansluter till rätt WSUS-server letar du reda på URL:en för den WSUS-dator som används av Windows Update Agent-klienten. Den här URL:en kan hittas genom att kontrollera registerundernyckeln HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate eller genom att visa filen WindowsUpdate.log.

     Vanliga orsaker till att WSUS-tilldelningen kan vara felaktig är:

     • grupprincip konflikter
     • Tillägg av en SUP till en sekundär plats efter den första klientinstallationen

     Kommentar

     Active Directory-grupprincip kan åsidosätta den lokala WSUS-principen.

     Funktionen programuppdateringar konfigurerar automatiskt en lokal grupprincip inställning för Configuration Manager-klienten så att den konfigureras med källplatsen för programuppdateringsplatsen och portnumret. Både servernamnet och portnumret krävs för att klienten ska kunna hitta programuppdateringsplatsen.

     Om en Active Directory-grupprincip-inställning tillämpas på datorer för klientinstallation av programuppdateringsplatser åsidosätter den lokala inställningen grupprincip. Om värdet för inställningen som definierats i Active Directory-grupprincip skiljer sig från den som angetts av Configuration Manager misslyckas genomsökningen på klienten eftersom den inte kan hitta rätt WSUS-dator. I det här fallet visar WUAHandler.log följande meddelande:

     Grupprincipinställningar skrevs över av en högre utfärdare (domänkontrollant) till: Server <http://server> och princip AKTIVERAD

     Programuppdateringsplatsen för klientinstallation och programuppdateringar måste vara samma server. Och den måste anges i inställningen Active Directory grupprincip med rätt namnformat och portinformation. Det skulle till exempel vara <http://server1.contoso.com:80> om programuppdateringsplatsen använde standardwebbplatsen.

  2. Om server-URL:en är korrekt får du åtkomst till servern med en URL som liknar följande för att verifiera anslutningen mellan klienten och WSUS-datorn:

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

     Om du vill kontrollera om klienten kan komma åt den ClientWebService virtuella katalogen kan du prova att komma åt en URL som liknar den här:

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

     Om du vill kontrollera om klienten kan komma åt SimpleAuthWebServicekan du prova att komma åt en URL som liknar den här:

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

     Om någon av dessa URL:er misslyckas kan några av de möjliga orsakerna vara:

     • Problem med namnmatchning på klienten. Kontrollera att du kan matcha det fullständiga domännamnet för WSUS-datorn.

     • Problem med proxykonfiguration.

     • Andra nätverksrelaterade anslutningsproblem.

     • Problem med portkonfigurationen, så det är en bra idé att kontrollera att portinställningarna är korrekta. WSUS kan konfigureras för att använda någon av följande portar: 80, 443 eller 8530, 8531.

       För att klienter ska kunna kommunicera med WSUS-datorn måste lämpliga portar tillåtas i brandväggen på WSUS-datorn. Portinställningar konfigureras när platssystemrollen för programuppdateringsplatsen skapas. Dessa portinställningar måste vara samma som portinställningarna som används av WSUS-webbplatsen. Annars kan WSUS Synchronization Manager inte ansluta till WSUS som körs på programuppdateringsplatsen för att begära synkronisering. Följande procedurer innehåller information om hur du verifierar portinställningarna som används av WSUS och programuppdateringsplatsen.

       1. Fastställ de WSUS-portinställningar som används i IIS 7.0 och senare versioner.

       2. Fastställa WSUS-portinställningarna i IIS 6.0.

       3. Konfigurera portar för programuppdateringsplatsen.

       4. Verifiera portanslutningen

          Kör följande kommando för att kontrollera portanslutningen från klienten:

          telnet SUPSERVER.CONTOSO.COM <portnumber>
          

          Kör till exempel följande kommando om porten är 8530:

          telnet SUPSERVER.CONTOSO.COM 8530
          

          Om porten inte är tillgänglig returnerar telnet ett fel som liknar följande:

          Det gick inte att öppna anslutningen till värden på portPortNumber <>

          Det här felet tyder på att brandväggsreglerna inte har konfigurerats för att tillåta kommunikation för WSUS-datorn. Det här felet kan också tyda på att en mellanliggande nätverksenhet blockerar porten. Kontrollera genom att prova samma test från en klient i samma lokala undernät. Om det fungerar konfigureras datorerna korrekt. En router eller brandvägg mellan segment blockerar dock porten och orsakar felet.

     • IIS-tillgänglighetsproblem.

       1. Öppna IIS-hanteraren (Internet Information Services) på WSUS-datorn.
       2. Expandera Webbplatser, högerklicka på webbplatsen för WSUS-datorn och klicka sedan på Redigera bindningar.
       3. I dialogrutan Webbplatsbindningar visas HTTP- och HTTPS-portvärdena i kolumnen Port.
       4. Öppna IIS-hanteraren (Internet Information Services) på WSUS-servern.
       5. Expandera Webbplatser, högerklicka på webbplatsen för WSUS-datorn och klicka sedan på Egenskaper.
       6. Klicka på fliken Webbplats . INSTÄLLNINGEN HTTP-port visas i TCP-porten och HTTPS-portinställningen visas i SSL-porten.
       7. I Configuration Manager-konsolen går du till Administration>Platskonfigurationsservrar>och Platssystemroller och klickar sedan på den< högra rutan SiteSystemName.>
       8. Högerklicka på Programuppdateringspunkt i den nedre rutan och klicka sedan på Egenskaper.
       9. Gå till fliken Allmänt , ange eller verifiera WSUS-konfigurationsportnumren.

• Autentiseringsfel

  Det anges vanligtvis när genomsökningen misslyckas med autentiseringsfel 0x80244017 (HTTP-status 401) eller 0x80244018 (HTTP-status 403).

  Bekräfta först rätt WinHTTP-proxyinställningar med hjälp av följande kommandon:

  • I Windows Vista eller senare versioner: netsh winhttp show proxy
  • I Windows XP: proxycfg.exe

  Om proxyinställningarna är korrekta kontrollerar du anslutningen till WSUS-datorn genom att slutföra stegen i HTTP-timeoutfel. Granska även IIS-loggarna på WSUS-datorn för att bekräfta att HTTP-felen returneras från WSUS. Om WSUS-datorn inte returnerar felet är problemet troligtvis med en mellanliggande brandvägg eller proxy.

• Certifikatproblem

  Certifikatproblem anges med felkod 0x80072F0C som innebär att "Ett certifikat krävs för att slutföra klientautentiseringen". Information om hur du åtgärdar det här problemet finns i Genomsökning misslyckas med fel 0x80072f0c.

Steg 4: WUAHandler tar emot resultat från Windows Update Agent och markerar genomsökningen som slutförd

Följande loggas i WUAHandler.log:

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

Felsöka problem i steg 4

Problem här bör åtgärdas på samma sätt som genomsökningsfel i steg 3.

Som tidigare nämnts i den här guiden kontrollerar du WUAHandler.log- och WindowsUpdate.log-filerna när du felsöker genomsökningsfel. WUAHandler rapporterar helt enkelt vad Windows Update Agent rapporterade. Felet i WUAHandler skulle därför vara samma fel som rapporterades av själva Windows Update-agenten. Mer information om felet finns i WindowsUpdate.log. Information om hur du läser WindowsUpdate.log finns i Windows Update-loggfiler.

Det finns många orsaker till att en programuppdateringsgenomsökning kan misslyckas. Det kan orsakas av något av de problem som nämnts tidigare, eller ett kommunikations- eller brandväggsproblem mellan klienten och programuppdateringsplatsens dator. Din bästa informationskälla kommer från loggarna och de felkoder som de innehåller. Mer information om felkoderna finns i Vanliga fel och åtgärder för Windows Update.

Steg 5: WUAHandler parsar genomsökningsresultatet

WUAHandler parsar sedan resultaten, som inkluderar tillämplighetstillståndet för varje uppdatering. Som en del av den här processen rensas ersatta uppdateringar bort. Tillämplighetstillståndet kontrolleras för alla uppdateringar som överensstämmer med de kriterier som CCMExec har skickat till Windows Update-agenten. Det viktiga att förstå här är att du bör se tillämplighetsresultat för uppdateringar oavsett om uppdateringarna finns i en distribution eller inte.

Följande poster loggas i WUAHandler.log:

> 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.

Felsöka problem i steg 5

Problem kan åtgärdas på samma sätt som genomsökningsfel i steg 3.

Som tidigare nämnts i den här guiden kontrollerar du WUAHandler.log- och WindowsUpdate.log-filerna när du felsöker genomsökningsfel. WUAHandler rapporterar helt enkelt vad Windows Update Agent rapporterade. Felet i WUAHandler skulle därför vara samma fel som rapporterades av själva Windows Update-agenten. Mer information om felet finns i WindowsUpdate.log. Information om hur du läser WindowsUpdate.log finns i Windows Update-loggfiler.

Generellt sett finns det många orsaker till varför en programuppdateringssökning kan misslyckas. Det kan orsakas av något av de problem som nämnts tidigare, eller av ett kommunikations- eller brandväggsproblem mellan klienten och programuppdateringsplatsens dator. Din bästa informationskälla kommer från loggarna och de felkoder som de innehåller. Som referens kan du läsa vanliga fel och åtgärder i Windows Update.

Steg 6: Uppdateringsarkivet registrerar statusen och skapar ett tillståndsmeddelande för varje uppdatering i WMI

När genomsökningsresultaten är tillgängliga lagras dessa resultat i uppdateringsarkivet. Uppdateringsarkivet registrerar det aktuella tillståndet för varje uppdatering och skapar ett tillståndsmeddelande för varje uppdatering. Dessa tillståndsmeddelanden vidarebefordras till platsservern i grupp i slutet av rapportcykeln för statusmeddelanden (vilket är minuter som standard). Vi skickar bara ett tillståndsmeddelande under följande omständigheter:

• Ett tidigare tillståndsmeddelande har aldrig skickats för en uppdatering (loggpost: har inte rapporterats tidigare, vilket skapar en ny instans).
• Tillämplighetstillståndet för en uppdatering har ändrats sedan det senaste tillståndsmeddelandet skickades.

UpdatesStore.log som visar status för saknade uppdateringar (KB2862152) som registreras och ett tillståndsmeddelande som genereras:

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 som visar statusmeddelande som registreras med tillstånds-ID 2 (saknas):

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

Dricks

För varje uppdatering skapas eller uppdateras en instans av CCM_UpdateStatus klassen och den lagrar uppdateringens aktuella status. Klassen CCM_UpdateStatus finns i ROOT\CCM\SoftwareUpdates\UpdatesStore namnområdet.

Felsöka problem i steg 6

Problem här bör åtgärdas på samma sätt som genomsökningsfel i steg 3.

Som tidigare nämnts i den här guiden kontrollerar du WUAHandler.log- och WindowsUpdate.log-filerna när du felsöker genomsökningsfel. WUAHandler rapporterar helt enkelt vad Windows Update Agent rapporterade. Felet i WUAHandler skulle därför vara samma fel som rapporterades av själva Windows Update-agenten. Mer information om felet finns i WindowsUpdate.log. Information om hur du läser WindowsUpdate.log finns i Windows Update-loggfiler.

Generellt sett finns det många orsaker till varför en programuppdateringssökning kan misslyckas. Det kan orsakas av något av de problem som nämnts tidigare, eller av ett kommunikations- eller brandväggsproblem mellan klienten och programuppdateringsplatsens dator. Din bästa informationskälla kommer från loggarna och de felkoder som de innehåller. Som referens kan du läsa vanliga fel och åtgärder i Windows Update.

Steg 7: Tillståndsmeddelanden skickas till hanteringsplatsen

När WUAHandler tar emot resultaten från Windows Update-agenten markerar den genomsökningen som slutförd och loggar följande meddelande i WUAHandler.log:

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

Felsöka problem i steg 7

Problem här bör åtgärdas på samma sätt som genomsökningsfel i steg 3, även om fel i det här skedet sannolikt kommer att visas i WindowsUpdate.log filen specifikt. Information om hur du läser WindowsUpdate.log finns i Windows Update-loggfiler.

Generellt sett finns det många orsaker till varför en programuppdateringssökning kan misslyckas. Det kan orsakas av något av de problem som nämnts tidigare, eller av ett kommunikations- eller brandväggsproblem mellan klienten och programuppdateringsplatsens dator. Din bästa informationskälla kommer från loggarna och de felkoder som de innehåller. Som referens kan du läsa vanliga fel och åtgärder i Windows Update.

Synkronisering av WSUS till Microsoft Update

WSUS-synkronisering med Microsoft Update beskrivs i följande steg. Bekräfta varje steg för att korrekt fastställa var problemet finns.

Steg 1: Synkroniseringen startar via en schemalagd eller manuell begäran

När en synkronisering utlöses förväntar vi oss att se följande meddelanden i WSUS-serverns SoftwareDistribution.log:

För manuell synkronisering:

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

För schemalagd synk:

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

Felsöka en manuell synkronisering i steg 1

1. Bekräfta att WSUS-tjänsten körs. Om en manuell synkronisering har startats men ligger kvar på 0 %, beror det på att WSUS-tjänsten (Update Services på WSUS 3.x; WSUSService på Windows Server 2012 och senare versioner) är i ett stoppat tillstånd.

2. Återställ MMC-cachen för WSUS-konsolen genom att följa dessa steg:

   1. Stäng WSUS-konsolen.
   2. Stoppa WSUS-tjänsten (Update Services på WSUS 3.x; WSUS-tjänsten på Windows Server 2012 och senare versioner).
   3. Bläddra till %appdata%\Microsoft\mmc.
   4. Byt namn på wsus till wsus_bak.
   5. Starta WSUS-tjänsten.
   6. Öppna WSUS-konsolen och prova en annan manuell synkronisering.

Felsöka en schemalagd synkronisering i steg 1

1. Prova en manuell synkronisering från WSUS-konsolen.
2. Om en manuell synkronisering fungerar bra kontrollerar du de schemalagda synkroniseringsinställningarna.

Steg 2: WSUS skapar en anslutning till Microsoft Update (MU)

När en synkronisering har startats försöker WSUS-servern upprätta en HTTP-anslutning via WinHTTP. Tänk på följande faktorer när du felsöker anslutningen:

WSUS <=winhttp=> Nätverksentiteter <=> Internet

• Finns det en nätverksentitet (proxy, brandvägg, säkerhetsfilter och så vidare) mellan WSUS-värddatorn och Internet?
• Om det finns en proxyserver och WSUS-servern krävs för att använda proxyn, konfigureras proxyn inom rätt WSUS-inställningar?

Felsöka en manuell synkronisering i steg 2

1. Bekräfta att WSUS-tjänsten körs. Om en manuell synkronisering har startats men den ligger kvar på 0 %, beror det på att WSUS-tjänsten (Update Services på WSUS 3.x; WSUS-tjänsten på Windows Server 2012 och senare versioner) är i ett stoppat tillstånd.

2. Återställ MMC-cachen för WSUS-konsolen genom att utföra följande steg:

   1. Stäng WSUS-konsolen.
   2. Stoppa WSUS-tjänsten (Update Services på WSUS 3.x; WSUS-tjänsten på Windows Server 2012 och senare versioner).
   3. Bläddra till %appdata%\Microsoft\mmc.
   4. Byt namn på wsus till wsus_bak.
   5. Starta WSUS-tjänsten.
   6. Öppna WSUS-konsolen och prova en annan manuell synkronisering.

Felsöka en schemalagd synkronisering i steg 2

1. Prova en manuell synkronisering från WSUS-konsolen.
2. Om en manuell synkronisering fungerar bra kontrollerar du de schemalagda synkroniseringsinställningarna.

Steg 3: WSUS-datorn tar emot produkt- och klassificeringsinformation från Microsoft Update och eventuella metadata som prenumererar

När WSUS har fått produkt- och klassificeringsinformation och eventuella prenumerationsmetadata från Microsoft Update är WSUS-synkroniseringen klar.

Problem med installation, ersättning eller identifiering med specifika uppdateringar

Distributionsproblem som uppstår med specifika uppdateringar kan delas in i områdena nedan. När du börjar felsöka bör du överväga följande komponenter som är associerade med dessa områden.

Områden	Installation	Supersedence	Detection
Komponenter	WUA Uppdateringsinstallationsprogram (komponentbaserad service (CBS), MSI) CCMExec	Uppdatera metadata	WUA Uppdatera metadata Uppdateringsinstallationsprogram (CBS, MSI)

Installationsproblem

Vad är installationsprogrammet (CBS, MSI, övrigt)?

CBS

För uppdateringar som gäller för Windows Vista och senare versioner används CBS för att hantera installationen.

1. Samla in CBS-loggen (%Windir%\Logs\Cbs\Cbs.log) och utför en första granskning för att få insikt i orsaken till felet. Felsökning av installationsbaserade problem via CBS-loggar ligger utanför omfånget för den här guiden. Mer information finns i Åtgärda windows-fel med hjälp av verktyget DISM eller System Update Readiness.
2. Installeras uppdateringen som en inloggad användare? I så fall misslyckas den bara när den installeras under systemkontexten? I det här fallet fokuserar du på att felsöka det manuella installationsfelet i systemkontexten.

MSI (Windows Installer)

För programuppdateringar som inte kommer från Windows används MSI för att hantera installationen.

1. Samla in och granska MSI-standardloggarna för uppdateringen. I den associerade KB-artikeln finns information om kända problem eller vanliga frågor och svar om uppdateringen.

2. Aktivera Loggning av Windows Installer och återskapa felet.

   När du granskar de resulterande loggarna kontrollerar du returvärdet 3 i loggen och raderna före posten för att få insikt i felet.

3. Kontrollera om samma uppdatering inte kan installeras manuellt under den lokala systemkontexten. Det gör du genom att använda samma installationsväxlar som misslyckades under programuppdateringsdistributionen.

   Om det misslyckas testar du installationen som den inloggade användaren med samma installationsväxlar. Kontrollera om det är problem med att installera under det lokala systemet. Om det fungerar kan du fokusera problemet på hur du installerar uppdateringen korrekt med hjälp av den lokala systemkontexten. Det kan kräva kontroll av administrativ distributionsvägledning inom KB för uppdateringen eller online.

Problem med ersättning

Försök att isolera problemet som rör ersättning med hjälp av följande frågor:

1. Frågor om hur du styr när Configuration Manager förfaller en uppdatering finns i Ersättande regler.
2. Om en uppdatering har upphört att gälla av Configuration Manager rekommenderar Microsoft att den senaste ersatta uppdateringen distribueras. Om du fortfarande behöver distribuera de utgångna uppdateringarna kan de distribueras utanför en programuppdateringsdistribution via programdistribution eller programhantering.
3. Om du vill ha frågor som specifikt rör ersättningslogik för en uppdatering läser du först KB-artikeln för att få mer information om uppdateringen. Du kan också granska ersättningen i Microsoft Update Catalog, WSUS-konsolen eller Configuration Manager-konsolen.

Identifieringsproblem

Fastställa efterlevnadstillstånd per uppdatering på en klient

1. I artikeln uppdatera KB finns kända problem med uppdateringen.
2. Kör åtgärden Genomsökningscykel för programuppdateringar på Configuration Manager-klienten.
3. Granska UpdatesStore.log och WindowsUpdate.log.

Felsöka uppdaterings tillämplighet

1. Kontrollera om några förutsättningar saknas med hjälp av KB-artikeln för uppdateringen. Kräver uppdateringen till exempel att programmet eller operativsystemet korrigeras till en viss service pack-nivå?
2. Bekräfta att det unika uppdaterings-ID:t för uppdateringen i fråga matchar det som distribueras. Är uppdateringen i fråga till exempel en 32-bitars uppdatering men är riktad till en 64-bitars värd?

Mer information

Mer information om hur du konfigurerar programuppdateringar i Configuration Manager finns i följande artiklar:

• Planera för programuppdateringar i Configuration Manager
• Så här konfigurerar du en programuppdateringsplats för att använda NLB-kluster (Network Load Balancing)
• Så här aktiverar du CRL-kontroll för programuppdateringar

Du kan också ställa en fråga i vårt Configuration Manager-supportforum för säkerhet, uppdateringar och efterlevnad här.

Besök vår blogg för alla de senaste nyheterna, informationen och tekniska tipsen om Configuration Manager.