Den fullständiga guiden till underhåll av Microsoft WSUS och Konfigurationshanteraren SUP

Den här artikeln tar upp några vanliga frågor om WSUS-underhåll för Configuration Manager miljöer.

Ursprunglig produktversion: Windows-servrar, Windows Server Update Services, Configuration Manager
Original-KB-nummer: 4490644

Introduktion

Frågor är ofta i stil med Hur ska jag köra det här underhållet i en Configuration Manager miljö, eller Hur ofta ska jag köra det här underhållet? Det är inte ovanligt att samvetsgranna Configuration Manager administratörer inte känner till att WSUS-underhåll ska köras alls. De flesta av oss har bara konfigurerat WSUS-servrar eftersom det är en förutsättning för en programuppdateringsplats (SUP). När SUP har konfigurerats stänger vi WSUS-konsolen och låtsas att den inte finns. Tyvärr kan det vara problematiskt för Configuration Manager klienter och den övergripande prestandan för WSUS/SUP-servern.

Med förståelsen för att det här underhållet måste utföras undrar du vilket underhåll du behöver göra och hur ofta du behöver göra det. Svaret är att du bör utföra månatligt underhåll. Underhåll är enkelt och tar inte lång tid för WSUS-servrar som har underhållits väl från början. Men om det har gått en tid sedan WSUS-underhållet gjordes kan rensningen vara svårare eller tidskrävande första gången. Det blir mycket enklare eller snabbare under efterföljande månader.

Underhåll WSUS samtidigt som du stöder Configuration Manager aktuella grenversion 1906 och senare versioner

Om du använder Configuration Manager aktuella grenversion 1906 eller senare, rekommenderar vi att du aktiverar WSUS-underhållsalternativen i konfigurationen av programuppdateringsplatsen på den översta nivån för att automatisera rensningsprocedurerna efter varje synkronisering. Den skulle effektivt hantera alla rensningsåtgärder som beskrivs i den här artikeln, förutom säkerhetskopiering och omindexering av WSUS-databasen. Du bör fortfarande automatisera säkerhetskopieringen av WSUS-databasen tillsammans med omindexering av WSUS-databasen enligt ett schema.

Mer information om underhåll av programuppdateringar i Configuration Manager finns i Underhåll av programuppdateringar.

Viktiga överväganden

Obs!

Om du använder underhållsfunktionerna som har lagts till i Configuration Manager version 1906 behöver du inte tänka på dessa objekt eftersom Configuration Manager hanterar rensningen efter varje synkronisering.

1. Innan du påbörjar underhållsprocessen bör du läsa all information och alla instruktioner i den här artikeln.

2. När du använder WSUS tillsammans med underordnade servrar läggs WSUS-servrarna uppifrån och ned, men bör tas bort nedifrån och upp. När de synkroniserar eller lägger till uppdateringar går de först till den överordnade WSUS-servern och replikerar sedan ned till de underordnade servrarna. När du utför en rensning och tar bort objekt från WSUS-servrar bör du börja längst ned i hierarkin.

3. WSUS-underhåll kan utföras samtidigt på flera servrar på samma nivå. När du gör det kontrollerar du att en nivå är klar innan du går vidare till nästa nivå. Stegen för rensning och omindexering som beskrivs nedan bör köras på alla WSUS-servrar, oavsett om de är en WSUS-replikserver eller inte. Mer information om hur du avgör om en WSUS-server är en replik finns i Neka ersatta uppdateringar.

4. Se till att sups inte synkroniseras under underhållsprocessen, eftersom det kan orsaka förlust av arbete som redan har utförts. Kontrollera synkroniseringsschemat för SUP och ange det tillfälligt som manuellt under den här processen.

   

5. Om du har flera SUP:er för den primära platsen eller den centrala administrationsplatsen (CAS) som inte delar SUSDB bör du överväga den WSUS-server som synkroniseras med den första SUP på platsen som finns på en nivå under platsen. Min CAS-webbplats har till exempel två SUP:er:

   • Den med namnet New syncs with Microsoft Update (Ny synkronisering med Microsoft Update) skulle vara min högsta nivå (nivå 1).
   • Servern med namnet 2012 synkroniseras med New och den skulle övervägas på den andra nivån. Det kan rensas samtidigt som jag skulle göra alla mina andra Nivå2-servrar, till exempel min primära plats enda SUP.

   

Utföra WSUS-underhåll

De grundläggande stegen som krävs för korrekt WSUS-underhåll är:

1. Säkerhetskopiera WSUS-databasen
2. Skapa anpassade index
3. Indexera om WSUS-databasen
4. Avböj ersatta uppdateringar och kör underhåll
5. Kör rensningsguiden för WSUS-server

Säkerhetskopiera WSUS-databasen

Säkerhetskopiera WSUS-databasen (SUSDB) med hjälp av önskad metod. Se Skapa en delad postlåda för mer information.

Skapa anpassade index

Den här processen är valfri men rekommenderas, den förbättrar prestanda avsevärt under efterföljande rensningsåtgärder.

Om du använder Configuration Manager aktuell grenversion 1906 eller en senare version rekommenderar vi att du använder Configuration Manager för att skapa indexen. Om du vill skapa indexen konfigurerar du alternativet Lägg till icke-klustrade index i WSUS-databasalternativet i programuppdateringsplatsens konfiguration för den översta platsen.

Om du använder en äldre version av Configuration Manager eller fristående WSUS-servrar följer du dessa steg för att skapa anpassade index i SUSDB-databasen. För varje SUSDB är det en engångsprocess.

1. Kontrollera att du har en säkerhetskopia av SUSDB-databasen.

2. Använd SQL Management Studio för att ansluta till SUSDB-databasen på samma sätt som beskrivs i avsnittet Indexera om WSUS-databasen .

3. Kör följande skript mot SUSDB för att skapa två anpassade index:

   -- Create custom index in tbLocalizedPropertyForRevision
   USE [SUSDB]
   
   CREATE NONCLUSTERED INDEX [nclLocalizedPropertyID] ON [dbo].[tbLocalizedPropertyForRevision]
   (
        [LocalizedPropertyID] ASC
   )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
   
   -- Create custom index in tbRevisionSupersedesUpdate
   CREATE NONCLUSTERED INDEX [nclSupercededUpdateID] ON [dbo].[tbRevisionSupersedesUpdate]
   (
        [SupersededUpdateID] ASC
   )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
   

   Om anpassade index har skapats tidigare resulterar körningen av skriptet igen i ett fel som liknar följande:

   Msg 1913, nivå 16, status 1, rad 1
   Åtgärden misslyckades eftersom det redan finns ett index eller en statistik med namnet "nclLocalizedPropertyID" i tabellen "dbo.tbLocalizedPropertyForRevision".

Indexera om WSUS-databasen

Om du vill indexera om WSUS-databasen (SUSDB) använder du omindexering av WSUS Database T-SQL-skriptet.

Stegen för att ansluta till SUSDB och utföra omindexering varierar beroende på om SUSDB körs i SQL Server eller Intern Windows-databas (WID). Kontrollera värdet SQLServerName för registerposten på WSUS-servern som finns i undernyckeln HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup för att avgöra var SUSDB körs.

Om värdet bara innehåller servernamnet eller server\instansen körs SUSDB på en SQL Server. Om värdet innehåller strängen ##SSEE eller ##WID i den körs SUSDB i WID, enligt följande:

Om SUSDB installerades på WID

Om SUSDB installerades på WID måste SQL Server Management Studio Express installeras lokalt för att köra omindexera skriptet. Här är ett enkelt sätt att avgöra vilken version av SQL Server Management Studio Express som ska installeras:

• Windows Server 2012 och senare versioner

  • Gå till C:\Windows\WID\Log och leta reda på felloggen som innehåller versionsnumret.

  • Leta upp versionsnumret i How to determine the version, edition and update level of SQL Server and its components (Så här fastställer du version, utgåva och uppdateringsnivå för SQL Server och dess komponenter). Det här värdet anger vilken Service Pack-nivå (SP) som WID körs på. Inkludera SP-nivån när du söker i Microsoft Download Center efter SQL Server Management Studio Express.

• För Windows Server 2008 R2 eller tidigare versioner:

  • Gå till C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG och öppna den senaste felloggen med Anteckningar. Högst upp finns ett versionsnummer (till exempel 9.00.4035.00 x64). Leta upp versionsnumret i How to determine the version, edition and update level of SQL Server and its components (Så här fastställer du version, utgåva och uppdateringsnivå för SQL Server och dess komponenter). Det här versionsnumret anger vilken Service Pack-nivå som körs. Inkludera SP-nivån när du söker i Microsoft Download Center efter SQL Server Management Studio Express.

När du har installerat SQL Server Management Studio Express startar du det och anger servernamnet för att ansluta till:

• Om operativsystemet är Windows Server 2012 eller senare versioner använder du \\.\pipe\MICROSOFT##WID\tsql\query.
• Om operativsystemet är äldre än Windows Server 2012 anger du \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query.

Om fel som liknar följande för WID inträffar när du försöker ansluta till SUSDB med hjälp av SQL Server Management Studio (SSMS) kan du prova att starta SSMS med alternativet Kör som administratör.

Om SUSDB installerades på SQL Server

Om SUSDB installerades på en fullständig SQL Server startar du SQL Server Management Studio och anger namnet på servern (och instansen om det behövs) när du uppmanas till det.

Tips

Alternativt kan ett verktyg med namnet sqlcmd användas för att köra omindexera skriptet. Se Viktig information för mer information.

Köra skriptet

Om du vill köra skriptet i antingen SQL Server Management Studio eller SQL Server Management Studio Express väljer du Ny fråga, klistrar in skriptet i fönstret och väljer sedan Kör. När den är klar visas ett meddelande om att frågan har körts korrekt i statusfältet. Och fönstret Resultat innehåller meddelanden relaterade till vilka index som återskapades.

Avböj ersatta uppdateringar och kör underhåll

Neka ersatta uppdateringar på WSUS-servern för att hjälpa klienter att söka effektivare. Innan du avböjer uppdateringar bör du se till att de ersatta uppdateringarna distribueras och att ersatta uppdateringar inte längre behövs. Configuration Manager innehåller en separat rensning som gör att den kan upphöra att gälla ersatta uppdateringar baserat på angivna villkor. Mer information finns i följande artiklar:

• Ersättningsregler
• Rensningsbeteende för WSUS från och med version 1810

Följande SQL-fråga kan köras mot SUSDB-databasen för att snabbt fastställa antalet ersatta uppdateringar. Om antalet ersatta uppdateringar är högre än 1500 kan det orsaka olika problem med programuppdatering på både server- och klientsidan.

-- Find the number of superseded updates
Select COUNT(UpdateID) from vwMinimalUpdate where IsSuperseded=1 and Declined=0

Om du använder Configuration Manager aktuella grenversion 1906 eller en senare version rekommenderar vi att du automatiskt nekar de ersatta uppdateringarna genom att aktivera alternativet Neka utgångna uppdateringar i WSUS enligt alternativ för ersättningsregler i konfigurationen av programuppdateringsplatsen för den översta platsen.

När du använder det här alternativet kan du se hur många uppdateringar som nekades genom att granska filen WsyncMgr.log när synkroniseringsprocessen har slutförts. Om du använder det här alternativet behöver du inte använda skriptet som beskrivs senare i det här avsnittet (antingen genom att köra det manuellt eller genom att konfigurera som uppgift att köra det enligt ett schema).

Om du använder fristående WSUS-servrar eller en äldre version av Configuration Manager kan du manuellt neka ersatta uppdateringar med hjälp av WSUS-konsolen. Eller så kan du köra det här PowerShell-skriptet. Kopiera och spara sedan skriptet som en Decline-SupersededUpdatesWithExclusionPeriod.ps1 skriptfil.

Obs!

Det här skriptet tillhandahålls som det är. Det bör testas fullständigt i ett labb innan du använder det i produktion. Microsoft ger inga garantier om användningen av det här skriptet på något sätt. Kör alltid skriptet med parametern -SkipDecline först för att få en sammanfattning av hur många ersatta uppdateringar som kommer att nekas.

Om Configuration Manager är inställt på Omedelbart upphörande av ersatta uppdateringar (se nedan) kan PowerShell-skriptet användas för att neka alla ersatta uppdateringar. Det bör göras på alla autonoma WSUS-servrar i hierarkin Configuration Manager/WSUS.

Du behöver inte köra PowerShell-skriptet på WSUS-servrar som har angetts som repliker, till exempel sekundära plats-SUP:er. Om du vill ta reda på om en WSUS-server är en replik kontrollerar du inställningarna för Uppdateringskälla .

Om uppdateringar inte har konfigurerats att omedelbart upphöra att gälla i Configuration Manager måste PowerShell-skriptet köras med en undantagsperiod som matchar inställningen Configuration Manager för antal dagar som ska upphöra att gälla ersatta uppdateringar. I det här fallet skulle det ta 60 dagar eftersom EGENSKAPERNA för SUP-komponenten har konfigurerats att vänta två månader innan ersatta uppdateringar upphör:

Följande kommandorader illustrerar de olika sätt som PowerShell-skriptet kan köras på:

Obs!

När du kör skriptet på WSUS-servern använder du LOCALHOST i stället för själva SERVERNAME.

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530 –SkipDecline

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530 –ExclusionPeriod 60

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8531

Köra skriptet med en -SkipDecline och -ExclusionPeriod 60 för att samla in information om uppdateringar på WSUS-servern och hur många uppdateringar som kan nekas:

Köra skriptet med -ExclusionPeriod 60 för att neka ersatta uppdateringar som är äldre än 60 dagar:

Utdata- och förloppsindikatorerna visas medan skriptet körs. Observera SupersededUpdates.csv-filen , som innehåller en lista över alla uppdateringar som nekas av skriptet:

Obs!

Om det uppstår problem när du försöker använda ovanstående PowerShell-skript för att neka ersatta uppdateringar kan du läsa avsnittet Om tidsgränsen för att köra Decline-SupersededUpdatesWithExclusionPeriod.ps1 skript överskrids när du ansluter till WSUS-servern, eller så uppstår ett 401-fel när du kör för felsökningssteg.

När ersatta uppdateringar har avböjts bör SUSDB indexeras igen för bästa prestanda. Relaterad information finns i Indexera om WSUS-databasen.

Kör rensningsguiden för WSUS-server

Rensningsguiden för WSUS-server innehåller alternativ för att rensa följande objekt:

• Oanvända uppdateringar och uppdateringsrevisioner (även kallade föråldrade uppdateringar)
• Datorer som inte kontaktar servern
• Onödiga uppdateringsfiler
• Uppdateringar som har upphört att gälla
• Ersatta uppdateringar

I en Configuration Manager miljö är datorer som inte kontaktar servern och alternativ för onödiga uppdateringsfiler inte relevanta eftersom Configuration Manager hanterar programuppdateringsinnehåll och enheter, såvida inte alternativen Skapa alla WSUS-rapporteringshändelser eller Skapa endast WSUS-statusrapporteringshändelser väljs under Synkroniseringsinställningar för programuppdatering. Om du har något av dessa alternativ konfigurerat bör du överväga att automatisera rensningen av WSUS-servern för att utföra rensningen av dessa två alternativ.

Om du använder Configuration Manager aktuell grenversion 1906 eller en senare version, så hanterar alternativet Neka utgångna uppdateringar i WSUS enligt ersättande regler degressiv av uppdateringar som har upphört att gälla och Ersatta uppdateringar baserat på de ersättningsregler som anges i Configuration Manager. Om du aktiverar alternativet Ta bort föråldrade uppdateringar från WSUS-databasen i Configuration Manager aktuella grenversion 1906 hanteras rensningen av oanvända uppdateringar och uppdateringsrevisioner (föråldrade uppdateringar). Vi rekommenderar att du aktiverar dessa alternativ i programuppdateringsplatsens konfiguration på den översta nivån så att Configuration Manager kan rensa WSUS-databasen.

Om du aldrig har rensat upp föråldrade uppdateringar från WSUS-databasen tidigare kan den här aktiviteten överskrida tidsgränsen. Du kan granska WsyncMgr.log för mer information och manuellt köra SQL-skriptet som anges i HJÄLP! Min WSUS har pågått i flera år utan underhåll och rensningsguiden fortsätter att överskrida tidsgränsen en gång, vilket skulle göra att efterföljande försök från Configuration Manager kan köras korrekt. Mer information om rensning och underhåll av WSUS i Configuration Manager finns i dokumenten.

För fristående WSUS-servrar eller om du använder en äldre version av Configuration Manager rekommenderar vi att du kör rensningsguiden för WSUS med jämna mellanrum. Om rensningsguiden för WSUS-servern aldrig har körts och WSUS har varit i produktion ett tag kan rensningen överskrida tidsgränsen. I så fall indexerar du om med steg 2 och steg 3 först och kör sedan rensningen med endast alternativet oanvända uppdateringar och uppdateringsrevisioner markerat.

Om du aldrig har kört rensningsguiden för WSUS kan det krävas några ändringar när du kör rensningen med oanvända uppdateringar och uppdateringsrevisioner . Om tidsgränsen överskrids kör du den igen tills den har slutförts och kör sedan vart och ett av de andra alternativen en i taget. Slutligen gör du ett fullständigt pass med alla alternativ markerade. Om tidsgränser fortsätter att inträffa kan du se SQL Server alternativ i HJÄLP! Min WSUS har pågått i flera år utan underhåll och rensningsguiden håller tidsgränsen ute. Det kan ta flera timmar eller dagar för serverrensningsguiden eller SQL-alternativet att slutföras.

Rensningsguiden för WSUS-server körs från WSUS-konsolen. Den finns under Alternativ, som du ser här:

Mer information finns i Visa felloggen för SQL Server.

När den rapporterar antalet objekt som har tagits bort slutförs rensningen. Om du inte ser den här informationen som returneras på WSUS-servern är det säkert att anta att tidsgränsen för rensningen har överskridits. I så fall måste du starta den igen eller använda SQL-alternativet.

När ersatta uppdateringar har avböjts bör SUSDB indexeras igen för bästa prestanda. Se avsnittet Indexera om WSUS-databasen för relaterad information.

Felsökning

Hjälp Min WSUS har pågått i flera år utan underhåll och rensningsguiden håller tidsgränsen ute

Det finns två olika alternativ här:

1. Installera om WSUS med en ny databas. Det finns ett antal varningar relaterade till detta, inklusive längden på den inledande synkroniseringen och fullständiga klientgenomsökningar mot SUSDB, jämfört med differentiella genomsökningar.

2. Se till att du har en säkerhetskopia av SUSDB-databasen och kör sedan en omindexering. När det är klart kör du följande skript i SQL Server Management Studio eller SQL Server Management Studio Express. När den är klar följer du alla ovanstående instruktioner för att köra underhåll. Det här sista steget är nödvändigt eftersom den spDeleteUpdate lagrade proceduren endast tar bort oanvända uppdateringar och uppdateringsrevisioner.

Obs!

Innan du kör skriptet följer du stegen i Den lagrade proceduren spDeleteUpdate körs långsamt för att förbättra prestanda för körningen av spDeleteUpdate.

DECLARE @var1 INT
DECLARE @msg nvarchar(100)

CREATE TABLE #results (Col1 INT)
INSERT INTO #results(Col1) EXEC spGetObsoleteUpdatesToCleanup

DECLARE WC Cursor
FOR
SELECT Col1 FROM #results

OPEN WC
FETCH NEXT FROM WC
INTO @var1
WHILE (@@FETCH_STATUS > -1)
BEGIN SET @msg = 'Deleting' + CONVERT(varchar(10), @var1)
RAISERROR(@msg,0,1) WITH NOWAIT EXEC spDeleteUpdate @localUpdateID=@var1
FETCH NEXT FROM WC INTO @var1 END

CLOSE WC
DEALLOCATE WC

DROP TABLE #results

Tidsgränsen uppnås när Decline-SupersededUpdatesWithExclusionPeriod.ps1 skript körs när du ansluter till WSUS-servern, eller så inträffar ett 401-fel när du kör

Om fel uppstår när du försöker använda PowerShell-skriptet för att neka ersatta uppdateringar kan ett alternativt SQL-skript köras mot SUDB.

1. Om Configuration Manager används tillsammans med WSUS kontrollerar duErsättningsregler för komponentegenskaper > för programuppdateringsplatsför att se hur snabbt ersatta uppdateringar upphör att gälla, till exempel omedelbart eller efter X månader. Anteckna den här inställningen.

   

2. Om du inte har säkerhetskopierat SUSDB-databasen gör du det innan du fortsätter.

3. Använd SQL Server Management Studio för att ansluta till SUSDB.

4. Kör följande kommando: Talet 90 på raden som innehåller DECLARE @thresholdDays INT = 90 bör motsvara ersättningsregler från steg 1 i den här proceduren och rätt antal dagar som överensstämmer med antalet månader som har konfigurerats i Ersättningsregler. Om detta är inställt på att upphöra att gälla omedelbart ska värdet i SQL-frågan för @thresholdDays anges till noll.

   -- Decline superseded updates in SUSDB; alternative to Decline-SupersededUpdatesWithExclusionPeriod.ps1
   DECLARE @thresholdDays INT = 90 -- Specify the number of days between today and the release date for which the superseded updates must not be declined (i.e., updates older than 90 days). This should match configuration of supersedence rules in SUP component properties, if ConfigMgr is being used with WSUS.
   DECLARE @testRun BIT = 0 -- Set this to 1 to test without declining anything.
   -- There shouldn't be any need to modify anything after this line.
   
   DECLARE @uid UNIQUEIDENTIFIER
   DECLARE @title NVARCHAR(500)
   DECLARE @date DATETIME
   DECLARE @userName NVARCHAR(100) = SYSTEM_USER
   
   DECLARE @count INT = 0
   
   DECLARE DU CURSOR FOR
     SELECT MU.UpdateID, U.DefaultTitle, U.CreationDate FROM vwMinimalUpdate MU
     JOIN PUBLIC_VIEWS.vUpdate U ON MU.UpdateID = U.UpdateId
   WHERE MU.IsSuperseded = 1 AND MU.Declined = 0 AND MU.IsLatestRevision = 1
     AND MU.CreationDate < DATEADD(dd,-@thresholdDays,GETDATE())
   ORDER BY MU.CreationDate
   
   PRINT 'Declining superseded updates older than ' + CONVERT(NVARCHAR(5), @thresholdDays) + ' days.' + CHAR(10)
   
   OPEN DU
   FETCH NEXT FROM DU INTO @uid, @title, @date
   WHILE (@@FETCH_STATUS > - 1)
   BEGIN
     SET @count = @count + 1
     PRINT 'Declining update ' + CONVERT(NVARCHAR(50), @uid) + ' (Creation Date ' + CONVERT(NVARCHAR(50), @date) + ') - ' + @title + ' ...'
     IF @testRun = 0
        EXEC spDeclineUpdate @updateID = @uid, @adminName = @userName, @failIfReplica = 1
     FETCH NEXT FROM DU INTO @uid, @title, @date
   END
   
   CLOSE DU
   DEALLOCATE DU
   
   PRINT CHAR(10) + 'Attempted to decline ' + CONVERT(NVARCHAR(10), @count) + ' updates.'
   

5. Kontrollera förloppet genom att övervaka fliken Meddelanden i fönstret Resultat .

Vad händer om jag får reda på att jag behövde en av uppdateringarna som jag avböjde?

Om du bestämmer dig för att du behöver någon av dessa nekade uppdateringar i Configuration Manager kan du få tillbaka den i WSUS genom att högerklicka på uppdateringen och välja Godkänn. Ändra godkännandet till Inte godkänt och synkronisera sedan om SUP för att få tillbaka uppdateringen.

Om uppdateringen inte längre finns i WSUS kan den importeras från Microsoft Update Catalog om den inte har upphört att gälla eller tagits bort från katalogen.

Automatisera WSUS-underhåll

Obs!

Om du använder Configuration Manager version 1906 eller en senare version kan du automatisera rensningsprocedurerna genom att aktivera WSUS-underhållsalternativen i programuppdateringsplatsens konfiguration på den översta nivån. De här alternativen hanterar alla rensningsåtgärder som utförs av rensningsguiden för WSUS-server. Du bör dock fortfarande automatiskt säkerhetskopiera och indexera om WSUS-databasen enligt ett schema.

WSUS-underhållsaktiviteter kan automatiseras, förutsatt att några krav uppfylls först.

1. Om du aldrig har kört WSUS-rensning måste du göra de två första rensningarna manuellt. Din andra manuella rensning bör köras 30 dagar från din första eftersom det tar 30 dagar för vissa uppdateringar och uppdateringsrevisioner att åldras ut. Det finns specifika orsaker till varför du inte vill automatisera förrän efter den andra rensningen. Din första rensning kommer förmodligen att köras längre än normalt. Så du kan inte bedöma hur lång tid detta underhåll normalt tar. Den andra rensningen är en mycket bättre indikator på vad som är normalt för dina datorer. Detta är viktigt eftersom du måste ta reda på hur lång tid varje steg tar som baslinje (jag vill också lägga till cirka 30 minuters svängrum) så att du kan bestämma tidpunkten för ditt schema.

2. Om du har underordnade WSUS-servrar måste du utföra underhåll på dem först och sedan utföra de överordnade servrarna.

3. Om du vill schemalägga omindexering av SUSDB behöver du en fullständig version av SQL Server. Intern Windows-databas (WID) har inte möjlighet att schemalägga en underhållsaktivitet men SQL Server Management Studio Express. Som sagt, i fall där WID används kan du använda schemaläggaren med SQLCMD som nämnts tidigare. Om du går den här vägen är det viktigt att du inte synkroniserar dina WSUS-servrar/SUP:er under den här underhållsperioden! Om du gör det är det möjligt att dina underordnade servrar bara synkroniserar om alla uppdateringar som du just försökte rensa ut. Jag schemalägger detta över natten innan min AM-synkronisering, så jag har tid att kontrollera det innan synkroniseringen körs.

Nödvändiga/användbara länkar:

• Indexera om WSUS-databasen
• Konfigurationsalternativ för Agent XPs Server
• Weekend Scripter: Använd Schemaläggaren för Windows för att köra ett Windows PowerShell-skript

Rensningsskript för WSUS

Obs!

När du kör skriptet på WSUS-servern använder du LOCALHOST i stället för själva SERVERNAME. Ersätt dessutom PORT med den använda.

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")`
 | out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("SERVERNAME",$true,PORT);
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
$cleanupScope.DeclineSupersededUpdates = $true
$cleanupScope.DeclineExpiredUpdates = $true
$cleanupScope.CleanupObsoleteUpdates = $true
$cleanupScope.CompressUpdates = $true
#$cleanupScope.CleanupObsoleteComputers = $true
$cleanupScope.CleanupUnneededContentFiles = $true
$cleanupManager = $wsus.GetCleanupManager();
$cleanupManager.PerformCleanup($cleanupScope);

Konfigurera WSUS-rensningsaktiviteten i Schemaläggaren

Obs!

Om du använder Configuration Manager aktuell grenversion 1906 eller en senare version kan du automatisera rensningsprocedurerna genom att aktivera WSUS-underhållsalternativen i programuppdateringsplatsens konfiguration på den översta nivån. För fristående WSUS-servrar eller äldre versioner av Configuration Manager kan du fortsätta att använda följande steg.

Blogginlägget Weekend Scripter som nämndes i föregående avsnitt innehåller grundläggande anvisningar och felsökning för det här steget. Men jag går igenom processen i följande steg.

1. Öppna Schemaläggaren och välj Skapa en aktivitet. På fliken Allmänt anger du namnet på uppgiften, den användare som du vill köra PowerShell-skriptet som (de flesta använder ett tjänstkonto). Välj Kör om en användare är inloggad eller inte och lägg sedan till en beskrivning om du vill.

   

2. Under fliken Åtgärder lägger du till en ny åtgärd och anger det program/skript som du vill köra. I det här fallet måste vi använda PowerShell och peka det på PS1-filen som vi vill att den ska köra. Du kan använda rensningsskriptet för WSUS. Det här skriptet utför rensningsalternativ som Configuration Manager aktuella grenversion 1906 inte gör. Du kan avkommentera dem om du använder fristående WSUS eller en äldre version av Configuration Manager. Om du vill ha en logg kan du ändra den sista raden i skriptet på följande sätt:

   Obs!

   När du kör skriptet på WSUS-servern använder du LOCALHOST i stället för själva SERVERNAME. Ersätt dessutom PORT med den använda.

   [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
   $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("SERVERNAME",$true,PORT);
   $cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
   # $cleanupScope.DeclineSupersededUpdates = $true # Performed by CM1906
   # $cleanupScope.DeclineExpiredUpdates    = $true # Performed by CM1906
   # $cleanupScope.CleanupObsoleteUpdates   = $true # Performed by CM1906
   $cleanupScope.CompressUpdates          = $true
   $cleanupScope.CleanupObsoleteComputers = $true
   $cleanupScope.CleanupUnneededContentFiles = $true
   $cleanupManager = $wsus.GetCleanupManager();
   $cleanupManager.PerformCleanup($cleanupScope) | Out-File C:\WSUS\WsusClean.txt;
   

   Du får en FYI/varning i Schemaläggaren när du sparar. Du kan ignorera den här varningen.

   

3. På fliken Utlösare anger du schemat för en gång i månaden eller enligt önskat schema. Återigen måste du se till att du inte synkroniserar din WSUS under hela rensningen och indexerar om tiden.

   

4. Ange även andra villkor eller inställningar som du vill justera. När du sparar uppgiften kan du uppmanas att ange autentiseringsuppgifter för Kör som-användaren .

5. Du kan också använda de här stegen för att konfigurera Decline-SupersededUpdatesWithExclusionPeriod.ps1 skriptet så att det körs var tredje månad. Jag brukar ställa in det här skriptet för att köra före de andra rensningsstegen, men först efter att jag har kört det manuellt och sett till att det har slutförts. Jag springer klockan 12:00 den första söndagen var tredje månad.

Konfigurera SUSDB-omindexering för WID med SQLCMD och Schemaläggaren

1. Spara WSUS-databasskriptet om som en .sql-fil (till exempel SUSDBMaint.sql).

2. Skapa en grundläggande uppgift och ge den ett namn:

   

3. Schemalägg den här aktiviteten så att den startar cirka 30 minuter efter att du förväntar dig att rensningen ska slutföras. Min rensning körs kl. 01:00 varje första söndag. Det tar cirka 30 minuter att köra och jag kommer att ge det ytterligare 30 minuter innan jag startar min omindex. Det innebär att jag schemalägger den här uppgiften för varje första söndag kl. 02:00, som du ser här:

   

4. Välj åtgärden för att starta ett program. Skriv samma lösenord i rutan Bekräfta lösenord. Filen som anges efter parametern -i är sökvägen till DET SQL-skript som du sparade i steg 1. Filen som anges efter parametern -o är där du vill att loggen ska placeras. Här är ett exempel:

   "C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.exe" -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt

   

5. Du får en varning som liknar den du fick när du skapade rensningsaktiviteten. Välj Ja för att acceptera argumenten och välj sedan Slutför för att tillämpa:

   

6. Du kan testa skriptet genom att tvinga det att köra och granska loggen efter fel. Om du stöter på problem visar loggen varför. Om det misslyckas har kontot som kör aktiviteten vanligtvis inte rätt behörighet eller så har WID-tjänsten inte startats.

Konfigurera en grundläggande schemalagd underhållsaktivitet i SQL för SUSDB:er som inte är WID

Obs!

Du måste vara en sysadmin i SQL Server för att skapa eller hantera underhållsplaner.

1. Öppna SQL Server Management Studio och anslut till din WSUS-instans. Expandera Hantering, högerklicka på Underhållsplaner och välj sedan Ny underhållsplan. Ge planen ett namn.

   

2. Välj underplan1 och se sedan till att verktygslådan är i kontext:

   

3. Dra och släpp aktiviteten Kör T-SQL-instruktionsaktivitet:

   

4. Högerklicka på Windows.edb och välj sedan Egenskaper. Kopiera och klistra in WSUS-omindexera skriptet och välj sedan OK:

   

5. Schemalägg den här aktiviteten så att den körs cirka 30 minuter efter att du förväntar dig att rensningen ska slutföras. Min rensning körs kl. 01:00 varje första söndag. Det tar cirka 30 minuter att köra, och jag kommer att ge det ytterligare 30 minuter innan jag börjar indexera om. Det innebär att jag schemalägger den här uppgiften så att den körs varje första söndag kl. 02:00.

   

6. När du skapar underhållsplanen bör du överväga att även lägga till en säkerhetskopia av SUSDB i planen. Jag brukar säkerhetskopiera först och sedan indexera om. Det kan ge mer tid till schemat.

Sammanställa allt

När du kör den i en hierarki bör WSUS-rensningskörningen utföras längst ned i hierarkin uppåt. Men när du använder skriptet för att neka ersatta uppdateringar bör körningen göras uppifrån och ned. Att avböja ersatta uppdateringar är egentligen en typ av tillägg till en uppdatering snarare än en borttagning. Du lägger faktiskt till en typ av godkännande i det här fallet.

Eftersom en synkronisering inte kan utföras under den faktiska rensningen föreslås det att du schemalägger/slutför alla aktiviteter över natten. Kontrollera sedan att de har slutförts via loggningen följande morgon, före nästa schemalagda synkronisering. Om något misslyckades kan underhåll schemaläggas om för nästa natt, när det underliggande problemet har identifierats och lösts.

De här uppgifterna kan köras snabbare eller långsammare beroende på miljö, och schemats tid bör återspegla detta. Förhoppningsvis går de snabbare eftersom min labbmiljö tenderar att vara lite långsammare än en normal produktionsmiljö. Jag är lite aggressiv när det gäller tidpunkten för avböjningsskripten. Om nivå 2 överlappar Nivå3 med några minuter orsakar det inte något problem eftersom min synkronisering inte är schemalagd att köras.

Om du inte synkroniserar hindras av misstag från att flöda till mina WSUS-servrar för Tier3-replikering från nivå 2. Jag gav mig själv extra tid mellan tier3-nedgången och rensningen på Nivå3 eftersom jag definitivt vill se till att neka skriptet slutförs innan jag kör min rensning.

Det ger en gemensam fråga: Eftersom jag inte synkroniserar, varför ska jag inte köra alla rensningar och omindexeringar samtidigt?

Svaret är att du förmodligen kan, men det skulle jag inte. Om min medarbetare över hela världen behöver köra en synkronisering skulle jag med det här schemat minimera risken för överblivna uppdateringar i WSUS. Och jag kan schemalägga den så att den körs igen nästa kväll.

Tid	Nivå	Uppgifter
00:00	Nivå 1–Avböj
00:15	Nivå 2– Avböj
00:30	Nivå 3– Avböj
01:00	Nivå 3 WSUS-rensning
02:00	Indexera om nivå 3	Rensning på nivå 2 för WSUS
03:00	Tier1-Cleanup	Indexera om nivå 2
04:00	Indexera om nivå 1

Obs!

Om du använder Configuration Manager aktuella grenversion 1906 eller en senare version för att utföra WSUS-underhåll utför Configuration Manager rensningen efter synkroniseringen med hjälp av metoden uppifrån och ned. I det här scenariot kan du schemalägga säkerhetskopieringen av WSUS-databasen och indexera om jobben så att de körs före det konfigurerade synkroniseringsschemat utan att behöva bekymra dig om något av de andra stegen, eftersom Configuration Manager hanterar allt annat.

Mer information om detta felmeddelande finns i följande avsnitt:

• Programuppdateringspunkt
• Underhåll av programuppdateringar i Configuration Manager