Metodtips för Windows Server Update Services
Den här artikeln innehåller tips för att undvika konfigurationer som upplever sämre prestanda på grund av design- eller konfigurationsbegränsningar i WSUS.
Ursprunglig produktversion: Configuration Manager (aktuell gren), Windows Server Update Services
Ursprungligt KB-nummer: 4490414
Kapacitetsbegränsningar
Även om WSUS har stöd för 100 000 klienter per server (150 000 klienter när du använder Configuration Manager) rekommenderar vi inte att du närmar dig den här gränsen.
Överväg i stället att använda en konfiguration av 2–4 servrar som delar samma SQL Server-databas. På så sätt har du säkerhet i antal. Om en server kraschar förstörs inte helgen omedelbart eftersom ingen klient kan uppdateras medan du måste uppdateras mot den senaste dag noll-exploateringen.
Scenariot med delad databas förhindrar också en genomsökningsstorm.
En genomsökningsstorm kan inträffa när många klienter ändrar WSUS-servrar och servrarna inte delar en databas. WSUS spårar aktivitet i databasen, så att båda vet vad som har ändrats sedan en klient senast genomsöks och endast skickar metadata som har uppdaterats sedan dess.
Om klienterna ändras till en annan WSUS-server som använder en annan databas måste de köra en fullständig genomsökning. En fullständig genomsökning kan orsaka stora metadataöverföringar. Överföringar på mer än 1 GB per klient kan ske i dessa scenarier, särskilt om WSUS-servern inte underhålls korrekt. Det kan generera tillräckligt med belastning för att orsaka fel när klienter kommunicerar med en WSUS-instans. Och klienter försöker igen upprepade gånger i det här fallet.
Att dela en databas innebär att när en klient växlar till en annan WSUS-instans som använder samma databas uppstår inte genomsökningsstraffet. Belastningsökningarna är inte den stora straffavgift som du betalar för att byta databas.
Configuration Manager-klientgenomsökningar ökar efterfrågan på WSUS än de fristående automatiska uppdateringarna. Configuration Manager, eftersom det inkluderar efterlevnadskontroll, genomsöker begäranden med kriterier som returnerar alla uppdateringar som har någon status, förutom nekad.
När agenten för automatiska uppdateringar genomsöker, eller om du väljer Sök efter uppdateringar i Kontrollpanelen, skickar agenten kriterier för att endast hämta de uppdateringar som godkänts för installation. De metadata som returneras är vanligtvis mindre än när genomsökningen initieras av Configuration Manager. Uppdateringsagenten cachelagrar data och nästa genomsökningsbegäran returnerar data från klientcachen.
Inaktivera återanvändning och konfigurera minnesgränser
WSUS implementerar en intern cache som hämtar uppdateringsmetadata från databasen. Den här åtgärden är dyr och mycket minneskrävande. Det kan göra att IIS-programpoolen som är värd för WSUS (kallas WSUSPool) återanvänds när WSUSPool överskrider standardgränserna för privat och virtuellt minne.
När poolen återanvänds tas cachen bort och måste återskapas. Det är inte något större problem när klienter genomgår deltagenomsökningar. Men om du hamnar i ett genomsökningsstorm-scenario återanvänds poolen hela tiden. Och klienter får fel när du gör genomsökningsbegäranden, till exempel felen HTTP 503.
Vi rekommenderar att du ökar standardlängden för köer och inaktiverar både den virtuella och den privata minnesgränsen genom att ange dem till 0. IIS implementerar automatisk återvinning av programpoolen var 29:e timme, ping och inaktiv timeout, vilket bör inaktiveras. De här inställningarna finns i IIS Manager-programpooler>> och välj WsusPool och klicka sedan på länken Avancerade inställningar i den högra rutan i IIS-hanteraren.
Här är en sammanfattning av rekommenderade ändringar och en relaterad skärmbild. Mer information finns i Planera för programuppdateringar i Configuration Manager.
Inställningsnamn | Värde |
---|---|
Kölängd | 2000 (upp från standardvärdet 1000) |
Tidsgräns för inaktivitet (minuter) | 0 (ned från standardvärdet 20) |
Ping aktiverat | Falskt (från standardvärdet Sant) |
Gräns för privat minne (KB) | 0 (obegränsat, upp från standardvärdet 1 843 200 KB) |
Regelbundet tidsintervall (minuter) | 0 (för att förhindra återanvändning och ändrad från standardvärdet 1740) |
I en miljö med cirka 17 000 cachelagrade uppdateringar kan mer än 24 GB minne behövas när cachen skapas tills den stabiliseras (cirka 14 GB).
Kontrollera om komprimering är aktiverat (om du vill spara bandbredd)
WSUS använder en komprimeringstyp som anropar Xpress-kodning. Den implementerar komprimering av uppdateringsmetadata och kan resultera i betydande bandbreddsbesparingar.
Xpress-kodning är aktiverat i IIS-ApplicationHost.config med den här raden under <httpCompression>
elementet och en registerinställning:
ApplicationHost.Config
<scheme name="xpress" doStaticCompression="false" doDynamicCompression="true" dll="C:\Program Files\Update Services\WebServices\suscomp.dll" staticCompressionLevel="10" dynamicCompressionLevel="0" />
Registernyckel
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\IIsDynamicCompression
Om båda inte finns kan det aktiveras genom att köra det här kommandot och sedan starta om programpoolen WsusPool i IIS.
cscript "%programfiles%\update services\setup\DynamicCompression.vbs" /enable "%programfiles%\Update Services\WebServices\suscomp.dll"
Xpress-kodning ger en del högre CPU-åtgång och kan inaktiveras om bandbredden inte är ett problem, men CPU-användningen är det. Följande kommando inaktiverar det.
cscript "%programfiles%\update services\setup\DynamicCompression.vbs" /disable
Konfigurera produkter och kategorier
När du konfigurerar WSUS väljer du endast de produkter och kategorier som du planerar att distribuera. Du kan alltid synkronisera kategorier och produkter som du måste ha senare. Om du lägger till dem när du inte planerar att distribuera dem ökar metadatastorleken och omkostnaderna på WSUS-servrarna.
Inaktivera Itanium-uppdateringar och andra onödiga uppdateringar
Det bör inte vara ett problem mycket längre eftersom Windows Server 2008 R2 var den senaste versionen som stöder Itanium. Men det är värt att nämna.
Anpassa och använd det här skriptet i din miljö för att neka Itanium-arkitekturuppdateringar. Skriptet kan också neka uppdateringar som innehåller Förhandsversion eller Beta i uppdateringsrubriken.
Det leder till att WSUS-konsolen blir mer lyhörd, men påverkar inte klientgenomsökningen.
Avböj ersatta uppdateringar och kör underhåll
En av de viktigaste sakerna som du kan göra för att hjälpa WSUS att köra bättre. Att behålla uppdateringar som har ersatts längre än nödvändigt (till exempel när du inte längre distribuerar dem) är den främsta orsaken till WSUS-prestandaproblem. Det är ok att behålla dem om du fortfarande distribuerar dem. Ta bort dem när du är klar med dem.
Information om degressiva ersatta uppdateringar och andra WSUS-underhållsobjekt finns i artikeln Fullständig guide till underhåll av Microsoft WSUS och konfigurationshanteraren SUP.
WSUS med SSL-konfiguration
Som standard är WSUS inte konfigurerat att använda SSL för klientkommunikation. Det första steget efter installationen bör vara att konfigurera SSL på WSUS för att säkerställa säkerheten mellan server-klientkommunikation.
Detta gör du på något av följande sätt:
- Skapa ett självsignerat certifikat. Det är inte idealiskt eftersom alla klienter måste lita på det här certifikatet.
- Hämta ett certifikat från en tredjeparts-leverantör.
- Hämta ett från den interna certifikatinfrastrukturen.
Certifikatet måste ha det korta servernamnet, FQDN och SAN-namn (alias) som det går efter.
När du har installerat certifikatet uppgraderar du grupprincip (eller klientkonfigurationsinställningar för programuppdateringar i Konfigurationshanteraren) för att använda adressen och SSL-porten för WSUS-servern. Porten är vanligtvis 8531 eller 443.
Konfigurera till exempel grupprincipobjektEt Ange microsoft update service-platsen för intranätet tillhttps://wsus.contoso.com:8531
<> .
Information om hur du kommer igång finns i Skydda WSUS med Secure Sockets Layer Protocol.
Konfigurera antivirusundantag
Om kumulativa uppdateringar och månatliga sammanslagningar
Du kan se termerna Månatliga sammanslagningar och Kumulativ uppdatering som används för Windows OS-uppdateringar. De är helt utbytbara. Sammanslagningar refererar till uppdateringar som publicerats för Windows 7, Windows 8.1, Windows Server 2008 R2 och Windows Server 2012 R2 som endast delvis är kumulativa.
Mer information finns i följande blogginlägg:
- Förenklad service för Windows 7 och Windows 8.1: de senaste förbättringarna
- Mer information om serviceändringar i Windows 7 och Windows 8.1
Med Windows 10 och Windows Server 2016 var uppdateringarna kumulativa från början:
Kumulativ innebär att: du installerar lanseringsversionen av operativsystemet och bara behöver tillämpa den senaste kumulativa uppdateringen för att vara helt uppdaterad. För de äldre operativsystemen har vi inte sådana uppdateringar ännu, även om det är den riktning vi är på väg i.
För Windows 7 och Windows 8.1 innebär det att fler uppdateringar kommer att behövas när du har installerat den senaste månatliga sammanslagningen. Här är ett exempel för Windows 7 och Windows Server 2008 R2 på vad som krävs för att ha ett nästan helt korrigerat system.
Följande tabell innehåller listan över Windows månatliga sammanslagningar och kumulativa uppdateringar. Du kan också hitta dem genom att söka efter Uppdateringshistorik för Windows-version<>.
Windows-version | Uppdatera |
---|---|
Windows 7 SP1 och Windows Server 2008 R2 SP1 | Uppdateringshistorik för Windows 7 SP1 och Windows Server 2008 R2 SP1 |
Windows 8.1 och Windows Server 2012 R2 | Uppdateringshistorik för Windows 8.1 och Windows Server 2012 R2 |
Windows 10 och Windows Server 2016 | Uppdateringshistorik för Windows 10 och Windows Server |
Windows Server 2019 | Uppdateringshistorik för Windows 10 och Windows Server 2019 |
En annan sak att tänka på är att inte alla uppdateringar publiceras så att de synkroniseras automatiskt till WSUS. Kumulativa uppdateringar i C - och D-veckan är till exempel förhandsversionsuppdateringar och synkroniseras inte med WSUS, utan måste importeras manuellt i stället. Se avsnittet Månatliga kvalitetsuppdateringar i Windows 10 uppdateringsfrekvens av tjänsten.
Använda PowerShell för att ansluta till en WSUS-server
Här är bara ett kodexempel för att komma igång med PowerShell och WSUS-API:et. Den kan köras där administrationskonsolen för WSUS är installerad.
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$WSUSServer = 'WSUS'
# This is your WSUS Server Name
$Port = 8530
# This is 8531 when SSL is enabled
$UseSSL = $False
#This is $True when SSL is enabled
Try
{
$Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($WSUSServer,$UseSSL,$Port)
}
Catch
{
Write-Warning "$($WSUSServer)<$($Port)>: $($_)"
Break
}
Referenser
Den fullständiga guiden till underhåll av Microsoft WSUS och Konfigurationshanteraren SUP
Använda PowerShell för att utföra grundläggande administrativa uppgifter på WSUS
Godkänn eller neka WSUS-uppdateringar med hjälp av PowerShell
Använda PowerShell för att hitta uppdateringar som saknas på WSUS-klientdatorer
Hämta Windows Update statusinformation med hjälp av PowerShell
Introduktion till PoshWSUS, en kostnadsfri PowerShell-modul för att hantera WSUS
Använd den kostnadsfria PowerShell-modulen PoshWSUS för administrativt arbete med WSUS
Ladda ned resurser och program för Windows, SharePoint, Office och andra produkter
PowerShell-modul för att hantera Windows Server Update Services (WSUS)