End User Management

WSUS | Import informacji o aktualizacjach

Estimated reading time: 3 minuty

Tabela zawartości

Wymagania
Wyszukiwanie informacji o aktualizacji
Import aktualizacji

Wymagania

Windows Update Agent synchronizuje dane o dostępnych aktualizacjach bezpośrednio z Microsoftu lub z bazy danych serwera WSUS. Nie wszystkie aktualizacje Microsoft publikuje na serwerze WSUS.

W poprzednich wersjach serwera WSUS, informacje o aktualizacjach mogłem importować używając jego konsoli. Na serwerze WSUS, w wersji 4.0, ta opcja jest nadal dostępna na konsoli, natomiast proces importowania jest wykonywany przez administratora przy pomocy poleceń powershell.

**Rysunek** 1. Import aktualizacji Microsoft na konsoli serwera WSUS.

Po uruchomieniu importowania aktualizacji, zostałem przekierowany na stronę MS opisującą proces importu przy pomocy poleceń powershell.

**Rysunek** 2. Wymagane uprawnienia do importu aktualizacji.

Nie każdy może importować informacje o nowych aktualizacjach do bazy danych serwera WSUS. Importować je można na każdym komputerze, na którym jest zainstalowana konsola serwera. Jeśli importuję informacje o aktualizacjach, wystarczy że moje konto jest w grupie lokalnej – WSUS Administrators. Jeśli chcę wykonać import na komputerze zdalnym, konto użyte do importu musi dodatkowo mieć uprawnienia lokalnego administratora na serwerze WSUS.

Wyszukiwanie informacji o aktualizacji

Import informacji o aktualizacji do bazy danych WSUS polega na wgraniu do niej UpdateID danej aktualizacji. Wchodzę na stronę https://catalog.update.microosft.com i wyszukuję aktualizacje po numerze KB.

**Rysunek 3**. Lista dostępnych aktualizacji dla szukanego numeru KB.

Zaznaczam aktualizację dla danej platformy, którą obsługuje serwer WSUS.

**Rysunek** 4. Informacje o aktualizacji dla platformy x64

Następnie kopiuję UpdateID, którego użyję do importu informacji o aktualizacji.

Import aktualizacji

Ze strony PowerShell script to import updates into WSUS kopiuję go na dysk C do katalogu c:\temp. Nazywam go np.: ImportWSUS.ps1. Do jego uruchomienia potrzebuję kilku parametrów:

WsusServer– nazwa serwera WSUS
PortNumber – port do komunikacji z serwerem WSUS
UseSsl – import będzie wykonany z użyciem SSL
UpdateID – UpdateID importowanej aktualizacji

.\ImporWSUS.ps1 [-WsusServer] <String> [-PortNumber] <Int32> [-UseSsl] [-UpdateId] <String> [-UpdateIdFilePath] <string> [<CommonParameters>]

Poniżej przykład importu informacji o aktualizacji na serwerze WSUS pracującym bez użycia SSL.

.\ImportWSUS.ps1 -WsusServer WSUSServer.contoso.com -PortNumber 8530 -UpdateId c7e8a0a2-d424-4d2c-9aae-a83dc3cd9766

Poniżej drugi przykład importu informacji o aktualizacjach na serwerze WSUS pracującym przy użyciu SSL. Jako jeden z parametrów został podany plik txt, którym można zapisać wiele UpdateID, w celu importu więcej niż jednej aktualizacji na raz.

.\ImportWSUS.ps1 -WsusServer WSUSServer.contoso.com -PortNumber 8531 -UseSsl -UpdateIdFilePath C:\temp\UpdateIDs.txt

Po zakończeniu działania skryptu zaimportowana informacja o aktualizacja będzie już dostępna na konsoli serwera WSUS i będę mógł ją wdrażać.

Strona główna » Strona 3

Configuration Manager | Compliance Items

Strona główna » Strona 3

Szacowany czas czytania: 4 minuty

Compliance Items to pojedyncza konfiguracja do sprawdzenia na zarządzanym systemie. Z nich tworzymy później Compliance Baseline i wdrażamy na kolekcję, w celu sprawdzania stanu konfiguracji środowiska zarządzanego przez klienta ConfigMgr.

Wdrażając Third-Party Updates na serwerze ConfIgMgr trzeba wykonać zmianę w rejestrach, aby klient ConfigMgr miał możliwość instalacji aktualizacji firm trzecich. Oczywiście można to wykonać przy pomocy polisy GPO, ale zawsze sprawdzam czy zostały one poprawnie wykonane.

To co chce sprawdzać to wpis AcceptTrudtedPiublisherCerts wraz z wartościami w HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate.

**Rysunek 1**. Wpis w rejestrze który chce sprawdzać.

Na konsoli ConfigMgr wybieram \Assets and Compliance\Overview\Compliance Settings\Configuration Items i tworzę nowy Compliance Items.

Nadaje mu nazwę,

Na zakładce Supported Platforms konfiguruje dla jakich systemów operacyjnych będzie działąć sprawdzanie rejestru.

**Rysunek 3**. Konfiguracja systemów operacyjnych których dotyczy sprawdzanie.

Na zakładce Settings decydujemy co mam być sprawdzane. Wpisujemy nazwę reguły oraz miejsce w rejestrze, które ma być sprawdzane.

**Rysunek 4**. Konfiguracje tego co ma sprawdzane.

Korzystając z przycisku Browse wybieram interesujące mnie wartości w rejestrze, które będą podlegały sprawdzeniu. Rejestr przeglądam zarówno na komputerze, na którym jest uruchomiona jest konsola serwera, jak również mogę podłączyć się zdalnie do innego komputera. Po wyborze wartości rejestru ustawiam sprawdzanie czy jest ona ustawiona na komputerze, czy też nie jest ustawiona.

Po zapisaniu co mam być sprawdzane w zakładce Compliance Rules tworzę dwie reguły. Jedna regułą sprawdza czy sprawdzany wpis w rejestrze istnieje, a druga ustawia wartość 1 dla tego wpisu.

Poniżej reguła czy poszukiwany wpis w rejestrze ma wartość 1. Jeśli wartość ma być nie tylko sprawdzona, ale również zmieniona na poprawną trzeba zaznaczyć dwie dodatkowe opcje:

Remediate noncompliant rules ehen supported – opcja ta powoduje, że klient ConfigMgr po sprawdzeniu poprawia konfigurację na poprawną.
Report noncompliant if this settings instance ist not found – opcja ta powoduje że klient ConfigMgr raportuje do serwera o tym, że sprawdzanego wpisu w rejestrze nie było.

**Rysunek 6**. Reguła sprawdzająca wartość wpisu w rejestrze

Poniżej reguła do sprawdzenia czy poszukiwany wpis w rejestrze istnieje.

**Rysunek 7**.Reguła czy sprawdzany wpis istnieje.

Na koniec zapisuje moją regułę.

**Rysunek 8**. Konfiguracja sprawdzania konfiguracji.

Po stworzeniu Compliance Items mogę go doać do Cmpliance Baseline a następnie wdrożyć na kolekcję.