underhållsfönster: det aldrig aldrig landet av Patching

underhållsfönster är ett koncept som kan vara svårt att förstå helt först. Jag är för lat för att ens försöka hjälpa dig där, så om du behöver lite splainin föreslår jag att du först går över till docs och Jason Sandys utmärkta rundown.

innan vi kommer in i det men jag vill snabbt rant om en sak först. Underhåll fönster kan bara minska din patch efterlevnad. Använd dem eftersom det finns ett verkligt liv och / eller affärs hotande anledning att göra det. Om du bara behöver se till att patchar/applikationer/aktivitetssekvenser installeras vid ett visst datum eller tid … det är vad distributionsfrister är för.
Ok, av tvålboxen. Det finns två krav som jag har sett ofta frågade om att jag använder underhållsfönster för att lösa. Den här veckan ska vi bara ta itu med den första:

Jag vill aldrig någonsin att du ska patcha den här rutan

om du har följt med min blogg eller pratat med mig för även den kortaste tiden kommer du att känna igen hur smärtsamt den rubriken var att skriva. Det brinner. Patching är för viktigt för att lämna oss köttpåsar och bör automatiseras så mycket som möjligt. Det finns dock vissa situationer där det finns en legitim anledning att inte automatisera patchning och omstart (vilket är samma sak). Dessa situationer tenderar att vara på serversidan av saker där arbetsbelastningar måste flyttas runt (ex. SQL, Exchange) men det finns också vissa arbetsstationsanvändningsfall. Om du har arbetsstationer i ett operationsrum får du ett pass på att automatiskt uppdatera dem. Åtminstone när jag är på bordet tack. Din Windows 2000-låda som kör en kärnreaktor är förmodligen också bra. Snälla, kör inte på den där.

det finns en mängd olika lösningar på detta problem, men för att vara helt ärlig finns det bara bra: stöd för tillgängliga distributioner för ADR. Fram till dess är lösningen Jag gillar bäst och enligt min mening är den mest tillförlitliga att skapa det jag kallar ett ’aldrig’ underhållsfönster. Skapa ett engångsunderhållsfönster som inträffade tidigare. Det borde sluta se ut så här:

detta fungerar eftersom när en enhet har ett enda underhållsfönster kommer den inte att fungera utanför den. Om det enda underhållsfönstret är tidigare och inte upprepar sig kommer ingenting någonsin att installeras automatiskt på den enheten igen. Istället, när en utplaceringsfrist träffar det kommer att försöka installera, upptäcka att det för närvarande inte är inom ett underhållsfönster, och permanent rapportera sig själv som ’förfallna’ väntar på ett underhållsfönster som aldrig kommer. Dåliga små uppdateringar … så ensam. De kommer alltid att förbli så tills någon öppnar Software Center och initierar installationen manuellt. Om du ville få alla fancy-shmancy du kan utlösa manuella installationer på distans med hjälp av en mängd olika tekniker, inklusive <full shill läge> något som högerklick verktygets installera saknade programuppdateringar verktyg </full shill läge>.

det finns två antaganden som görs här. Först: att du inte distribuerar något som åsidosätter underhållsfönster. Det finns ingen fixering dum så var inte dum. För det andra: att du inte tillämpar ett annat underhållsfönster på enheterna I never collection. Den här är lite svårare och är en del av varför det är nästan universellt överens om att du ska skapa separata samlingar som bara finns för underhållsfönsterändamål. Vidare rekommenderar jag starkt att du gör det enkelt att identifiera dina underhållsfönster genom att lägga dem i en mapp och/eller prefixa samlingarna med något meningsfullt. Till exempel: ’MW – aldrig’. På så sätt vet du var dina underhållsfönster är och du kan se till att de alla utesluter ditt aldrig underhållsfönster. Om du ser till att varje underhållsfönstersamling utesluter ditt aldrig underhållsfönster, så lägger du bara till enheter i ditt aldrig underhållsfönster garanterar att du inte korsar strömmarna:

ett underhållsfönster med fördelar!

det finns några fördelar med att använda ett aldrig underhållsfönster som du inte försöker lösa detta problem på andra sätt.

först, med hjälp av en aldrig underhåll fönster är ett bra sätt att underlätta i helautomatisk lapp. Har några lagmedlemmar som tror att deras enheter är speciella små snöflingor istället för nötkreatur redo för slakt? Sätt sina enheter i ett aldrig underhållsfönster och distribuera patchar till dem normalt. Du får kontroll och rapportering medan slutanvändaren får undvika att behöva vänta på Windows Update-skanningar och uppdateringar för att ladda ner. Mina serveradministratörer älskade det faktum att de kunde öppna Software Center under dagen för att validera vilka patchar som väntade på att tillämpas innan de loggade in under kvällen för att tillämpa dem. De älskade också möjligheten att skriva processen så att den kunde göras manuellt men utan att behöva logga in på varje maskin. Avgörande, efter ett tag frågade många sig varför de stod upp klockan för att trycka på en enda knapp. Det gjorde automatiserade patchkonverter till förmån för datorrace.

för det andra är ditt aldrig underhållsfönster en överenskommen svartlista över enheter som är döda för dig. Min rapporteringspanel skrevs specifikt för att rapportera om servrar globalt, servrar med aktiva underhållsfönster och servrar med fönstret aldrig underhåll. Detta gjorde det möjligt för mig att visa ledningen hur hemskt några av mina kolleger administratörer var på manuellt lappa sina enheter samtidigt utesluta dem från efterlevnaden nummer jag brydde sig om. När säkerheten kom knackar om en viss låda steg Ett var att granska min aldrig underhåll fönster medlemskap för enheten (s) i fråga. Om de var där sa jag gärna till dem att ta upp det med appägarna som höll på att manuellt lappa sina egna enheter. Detta bidrog också till att skapa automatiserade patchkonverter … om än mindre villiga.

slutligen, relaterat till ovanstående, var never maintenance-fönstret ett utlopp för att hantera kumulativa uppdateringar som endast påverkade en liten delmängd av applikationer. Med kumulativa uppdateringar betyder det bara att blockera månadens patch att de bara kommer att bryta igen när nästa månads patchar kommer ut om inte det underliggande problemet är löst. Om en applikationsägare berättade för mig att inte lappa sin låda riktade jag dem till vår CIO och krävde CIO: s skriftliga godkännande för att placera sina lådor i fönstret aldrig underhåll och … det här är den avgörande delen … lappa aldrig dessa lådor igen. Ungefär 50% av fallen kom aldrig förbi den delen och de som gjorde var inte längre mitt problem eftersom de uteslöts från rapporteringen som är viktig för mig.

så där har du det. Som jag sa finns det mer än ett sätt att ta itu med detta krav, men av orsakerna ovan är begreppet aldrig underhållsfönster ett som jag ständigt faller tillbaka på som den bästa lösningen tills produktteamet ger oss tillgängliga distributioner i ADR. Men även då, om du är orolig för applikationer och uppgiftssekvenser som oavsiktligt distribueras efter behov istället för tillgängliga, kan bara ett aldrig underhållsfönster garantera det.

Lämna ett svar

Din e-postadress kommer inte publiceras.