POC – Private “Update for Business” – Automatyczna akceptacja poprawek

8 lipca 2015 at 05:36

Spis treści projektu:

1. POC – Private “Update for Business” – Intro

2. POC – Private “Update for Business” – Komputery i Grupy

3. POC – Private “Update for Business” – Inwentaryzacja klientów

4. POC – Private “Update for Business” – Inwentaryzacja poprawek

5. POC – Private “Update for Business” – Automatyczna akceptacja poprawek

6. POC – Private “Update for Business” – Automatyczny Maintenance


W kolejnej części naszego projektu Private “Update for Business” pochylimy się nad głównym tematem przybliżającym nas do osiągnięcia zbliżonego schematu działania usług aktualizacji, jak oryginalne rozwiązanie Microsoftu, czyli cyklów release’owych poprawek dla poszczególnych grup komputerów.

Dla naszego „Pierwszego okręgu”, czyli grupy testowej, gdzie wysyłamy wszytkie poprawki od razu po synchronizacji z serwerem WSUS’a jest najprościej, bo możemy wykorzystać do tego celu reguły dotyczące poprawek.

Przechodzimy więc do konsolki mmc służącej do zarządzania serwerem WSUS, następnie do „Options” oraz „Automatic Approvals”. Tutaj tworzymy nową regułę, którą nazwiemy – „Grupa_Testowa_Auto_Approve” i w sekcji „Step 1” zaznaczamy:

1. When an update is in any classification

2. When an update is in any product

Natomiast w sekcji „Step 2” określamy:

1. Approve the update for Grupa_Testowa

Mamy automat akceptujący wszystkie poprawki dla naszego „pierwszego okręgu”, antomiast stworzenie kolejnych nie jest już takie banalne… Trzeba mieć najpierw informację o tym, kiedy dane poprawki zostały pobrane/zaakceptowane na konkretne grupy i dopiero później bazując na tej wiedzy przechodzić do ich akceptacji.

Ok. Znajdźmy najpierw informację o tym, jakie poprawki zostały zsynchronizowane w ciągu ostatnich 7 dni (tutaj uwaga – każdy powinien do siebie dopasować harmonogram poprawek. Jak wiadomo większość poprawek wychodzi  w trakcie „patching Tuesday” Microsoftu, więc wysyłając poprawki na kolejne grupy np.  w poniedziałek albo we wtorek przed oficjalnym releasem mamy 99% szans, że poprawki wygrzały się przez tydzień w przeciwnym razie musimy pooperować zapytaniem SQL’owym, ale podstawowe to:

Powyższe zapytanie SQL zapisujemy do pliku: C:\scripts\Auto_approve\Poprawki_nowe.sql

Ale jeśli chcemy mieć pewność, że poprawki będą z zakresu czasowego 7-14 dni zapytanie może wyglądać tak:

Skoro mamy już adekwatne informacje o poprawkach w podanym zakresie czasowym pora przejść do Powershell’a żeby cały proces zautomatyzować:

Prawe słów wyjaśnienia w stosunku do powyższego skryptu:

1. Wykonujemy zapytanie SQL’owe , które zwraca nam wszystkie poprawki z wybranego zakresu np: do 7 dni wstecz. Dane zapisujemy do pliku

2. Sprawdzamy, czy plik zawiera jakieś poprawki, jeśli nie – pomijamy

3. Następnie zajmujemy się plikiem z poprzedniego cyklu (ten, który ostatnio był wygenerowany dla Grupy_Pilotazowej – obecnie zmienia nazwę i staje się bazą dla Grupy_Produkcyjnej – żeby nie powielać zapytań SQL tylko pracować na wygenerowanych wcześniej danych).

4. Ponownie sprawdzamy, czy plik nie jest pusty, a następnie dla każdej poprawki weryfikujemy, czy nie została odrzucona (Declined). Jeśli jest odrzucona – pomijamy, w przeciwnym wypadku akceptujemy na produkcję.

W przypadku pierwszej akceptacji – dorzucone zostało sprawdzanie, czy poprawkę uda się zaakceptować. Sa niestety pewne poprawki jak ServicePack’i, które wymagają ręcznego zaakceptowania umowy EULA. W takim wypadku kłopotliwe poprawki zostaną zrzucone do osobnego pliku, żebyśmy wiedzieli o nich od razu :)

 

Pozostał nam tylko jeszcze maintenanc’e całego rozwiązania, który a jakże rónież będzie dziać się automatycznie 😉