Konfiguracja Distribution Point

Punkt dystrybucyjny to rola serwerowa, która umożliwia pobieranie przez klientów serwera ConfigMgr plików instalacyjnych dla Software Distribution , Operating System Deployment oraz Software Updates.

Instalację rozpoczynamy na zakładce Site Configuration -> Site. Wybieramy opcje Create Site Server System.

 Rysunek 1.  Uruchomienie kreatora instalacji nowej roli serwerowej.
Rysunek 1.  Uruchomienie kreatora instalacji nowej roli serwerowej.

Na początku musimy podać nazwę FQDN systemu operacyjnego, na którym chcemy zainstalować Distribution Point. Można nazwę wpisać samemu, ale również skorzystać z Browse.

Rysunek 2. Wskazanie systemu operacyjnego do instalacji Distribution Point.

Kolejny krok to wskazanie roli serwerowej, którą chcemy zainstalować.

Rysunek 3. Wybór roli serwerowej.

Do działania Distribution Point jest potrzebny serwer IIS. Możemy go skonfigurować przed instalacją punktu dystrybucyjnego. Jeśli nie zrobiliśmy tego wcześniej to opcja Install and configure IIS if required by Configuration Manager służy do automatycznej instalacji i konfioguracji serwera IIS trakcie procesu instalacji punktu dystrybucyjnego.

Rysunek 4. Konfiguracja instalacji punktu dystrybucyjnego.

Przed wysłaniem paczki serwer zawsze sprawdza, która partycja ma najwięcej wolnego miejsca i na niej zapisywał ją w katalogu SCCMContelib. Ustawienia Drive Settings pozwalają na ustawienie podstawowej oraz dodatkowych partycji, na które będa wysyłane paczki. Dzięki temu paczki zostaną zapisane na drugiej partycji dopiero wtedy, kiedy skończy się wolne miejsce na partycji wskazanej jako Primary. Dodatkowo dzięki opcji Drive space reserve serwer zostawi wolna przestrzeń, na każdej przez siebie używanej partycji.

Rysunek 5. Ustawienia zapisywania paczek na partycjach punktu dystrybucyjnego.

Distribution Point oprócz udostępniania klientom ConfigMgr paczek instalacyjnych może również służyć do obsługi wdrażania systemów operacyjnych przy pomocy serwera Windows Deployment Services.  W takim przypadku skorsystamy z opcji Enable PXE support for clients. Do poprawnego działania tej funkcji należy wdrożyć Windows Deployment Services. Jednak jeśli tego nie zrobiliśmy, instalator zainstaluje i skonfiguruje serwer WDS podczas instalacji punktu dystrybucyjnego.

Rysunek 6. Konfiguracja ustawień PXE

Przy wdrażaniu systemów operacyjnych przy pomocy Windows Deployment Services mam możliwość wykorzystania funkcji Multicast. Dzięki niej można skrócić czas trwania przesyłania obrazów systemów operacyjnych poprzez sieć.

Rysunek 7. Ustawienia opcji Multicast.

Kolejną nowością jest możliwość ustawienia automatycznego sprawdzania przez serwer ConfigMgr integralności danych znajdujących się punkcie dystrybucyjnym.

Rysunek 8. Ustawienia automatycznego sprawdzania danych na punkcie dystrybucyjnym.

Utworzenie punktu dystrybucyjnego nie wystarczy, aby klienci ConfigMgr mogli pobierać z niego dane. Należy go dodać do uprzednio utworzonej Boundary Groups lub ją utworzyć. W celu dodania punktu dystrybucyjnego do Boundary Groups wybieramy opcje Add.

Rysunek 9. Dodawanie nowego punktu dystrybucyjnego do Boundary Groups.

Punkt dystrybucyjny może być przydzielony do więcej niż jednej Boundary Groups.

Rysunek 10. Wskazanie Boundary Groups przydzielonych do puntu dystrybucyjnego.

Po wybraniu Boundary Groups sprawdzamy poprawność danych i przechodzimy dalej.

Rysunek 11. Wykaz przydzielonych Boundary Groups.

Na zakończenie działania kreatora możemy obejrzeć podsumowanie wprowadzonych ustawień.

Rysunek 12. Podsumowanie wprowadzonych ustawień.

Naciskamy przycisk Next i czekamy, aż kreator zakończy pracę.

Rysunek 13. Podusmowanie pracy kreatora instalacji punktu dystrybucyjnego.

Po zakończeniu pracy instalatora możemy obejrzeć podstawowe ustawienia punktu dystrybucyjnego na zakładce Administration -> Distributions Points.

Rysunek 14. Ustawienia punktu dystrybucyjnego.

W trakcie instalacji możemy ustawić tylko niektóre z właściwości punktu dystrybucyjnego. Dodatkowe opcje są dostępne po instalacji. W zakładce Administration -> Distributions Points.

Rysunek 15. Wybór punktu dystrybucyjnego.

Na karcie Properties zwracają uwagę dwie zakładki: Schedule oraz Rate Limits. Dzięki nim można dla każdego punktu dystrybucyjnego ustawić inne godziny wysyłania paczek oraz szybkość

Rysunek 16. Zakładka Properties punktu dystrybucyjnego.

Ustawienia Schedule służą do okreslenia kiedy serwer będzie wysyłał paczki na punkt dystrybucyjny. W/g poniższych ustawień serwer ConfigMgr będzie wysyłał paczki na ten punkt dystrybucyjny tylko poniedziałku do piątku od godziny 4 rano do 19 popołudniu. Dotyczy to wszystkich paczek z priorytetem High. Pozostałe paczki będą wysyłane poza tymi godzinami.

Rysunek 17. Ustawienia harmonogramu wysyłania paczek na punkt dystrybucyjny

Na zakładce Rate Limits można ustawić szybkość wysyłania zawartości paczek. Zgodnie z poniższymi ustawieniami serwer ConfigMgr będzie wysyłał paczki na ten dystrybucyjny bez ograniczenia prędkości.

Rysunek 18. Ustawienia Rate Limits.

W przypadku posiadania większej ilości punktów dystrybucyjnych możemy je grupować w Distribution Points Group. Uławia to potem wysyłanie paczek na punkty dystrybucyjny, bo zamiast wskazywać wszystkie po kolei można wskazać calą grupę.

Rysunek 19. Tworzenie Distribution Point Group.

Musimy nazwać naszą Distribution Point Group.

Rysunek 20. Tworzenie Distribution Point Group.

Nastęnie dodajemy wybrane punkty dystrybucyjne.

Rysunek 21. Wskazanie punktów dystrybucyjnych należących do grupy.

Po stworzeniu grupy jej właściwości można obejrzeć w zakładce Administration -> Distribution Point Group.

Rysunek 22. Właściwości Distribution Point.

Compliance Settings – Items

Całkiem niedawno zakończyłem projekt migracji z Windows 7 do Windows 10. W trakcie projektu Klient poprosił o skonfigurowanie sprawdzania poprawności konfiguracji komputerów z Windows 10.

W projekcie oprócz migracji do Windows 10 należało utworzyć polityki GPO dla nowo wdrażanego systemu operacyjnego. Jednym ze sposobów jest wykorzystanie istniejącej od dawna funkcji serwera ConfigMgr, czyli Compliance Settings.

Konfiguracja Compliance Settings składa się z trzech kroków:

  • konfiguracja Compliance Items
  • Konfiguracji Comliance Baseline
  • wdrożeniu Compliance Baseline na wybranej kolekcji komputerów.

Poniżej przykład Compliance Settings. Do instalacji aktualizacji publikowanych samodzielnie na serwerze WSUS jest potrzebny certyfikat, którym zostały podpisane te aktualizacje oraz odpowiednie wpisy w rejestrze komputera.

Dla komputerów w domenie zmiany dokonujemy poprzez GPO, natomiast na komputerach pracujących w grupie roboczej musimy zastosować plik reg. Po dokonaniu zmian dobrze jest sprawdzać czy konfiguracja komputera nadal jest poprawna. Poniżej pokazałem poprawną konfigurację gałęzi rejestru odpowiedzialnej za pozwolenie instalacji certyfikatów opublikowanych samodzielnie na serwerze WSUS, nie pochodzących od Microsoftu.

Rysunek 1. Wpis AllowTrustedPusblisherCerts pozwalający na wdrażanie aktualizacji spoza witryny Microsoft Update.
Rysunek 1. Wpis AllowTrustedPusblisherCerts pozwalający na wdrażanie aktualizacji spoza witryny Microsoft Update.

Compliance Items to konfiguracja trzech rzeczy: tego, co sprawdzamy, jak sprawdzamy oraz jaki stan ma zostać zaraportowany do serwera ConfigMgr.

Rysunek 2. Widok konsoli na Compliance Settings Items.
Rysunek 2. Widok konsoli na Compliance Settings Items.

Konfigurację Compliance Items rozpoczynamy od wpisania nazwy oraz wskazania, jakich systemów operacyjnych będzie dotyczyć ta konfiguracja.

Rysunek 3. Konfiguracja nazwy Compliance Items oraz systemu operacyjnego, którego ma ona dotyczyć.

Kolejny krok to wskazania na jakich wersjach systemu operacyjnego będzie wykonywane sprawdzanie.

Rysunek 4. Wskazanie wersji systemu operacyjnego, którego ma dotyczyć Compliance Items.

Następnie przechodzimy do ustawień tego, co ma być sprawdzane. Wybieramy przycisk New, by stworzyć nową regułę.

Rysunek 5. Tworzenie nowych reguł Comilance Settings Items.
Rysunek 5. Tworzenie nowych reguł Comilance Items.

Nadajemy nazwę naszej regule, wybieramy typ ustawień, jakie będziemy sprawdzać. W celu sprawdzenia wartości w rejestrze wybieramy Registry value w Settings type.

Rysunek 6. Wybór typu ustawień, które będziemy sprawdzać.
Rysunek 6. Wybór typu ustawień, które będziemy sprawdzać.

Korzystając z przycisku Browse może w łatwy sposób wybrać interesujące nas wartości w rejestrze, które będą podlegały sprawdzeniu. Rejestr możemy przeglądać zarówno na komputerze, na którym jest uruchomiona konsola serwera ConfigMgr, jak również podłączyć się zdalnie do innego komputera. Po wyborze wartości rejestru trzeba ustawić sprawdzanie czy jest ona ustawiona na komputerze, czy też nie jest ustawiona.

Rysunek 7. Przeglądarka rejestru dostępna podczas konfiguracji Compliance Settings Items.
Rysunek 7. Przeglądarka rejestru dostępna podczas konfiguracji Compliance Items.

Kolejny krok to zapisanie wprowadzonych zmian.

Rysunek 8. Konfiguracja reguły sprawdzającej obecność wpisu w rejestrze.

Na razie konfiguracja Compliance Items pozwala na sprawdzenie, czy dany wpis w rejestrze istnieje na komputerze, czy też nie. Trzeba jeszcze stworzyć regułę sprawdzającą konkretną wartość wskazanego przez nas wcześniej wpisu w rejestrze. Zrobimy to poprzez ustawienia Compliance Rules. Wybieramy przycisk New, by stworzyć nową regułę.

Rysunek 9. Konfiguracja reguł sprawdzających stan komputera.

Nadajemy jej nazwę i wybieramy ustawienia, które będziemy konfigurować.

Rysunek 10. Konfiguracja reguł sprawdzającej wartość wpisaną w rejestrach komputera.
Rysunek 10. Konfiguracja reguł sprawdzającej wartość wpisaną w rejestrach komputera.

Wybieramy stworzoną wcześniej regułę AlloInstallUpdatesSCUP.

Rysunek 11. Wybór reguły.

Następnie wpisujemy wartość, która oznacza poprawną konfigurację. W tym wypadku ma to być wartość 1, która pozwala na instalację aktualizacji publikowanych na serwerze WSUS przy pomocy Update Publisher. Warto też ustawić, jaki stan będzie raportowany do serwera ConfigMgr w przypadku niezgodności konfiguracji. W tym wypadku, jeśli konfiguracja nie będzie poprawna, stan zostanie zaraportowany jako Critical.

Rysunek 11. Konfiguracja sprawdzania wartości w rejestrze.

Po skończeniu konfiguracji można obejrzeć ustawienia.

Rysunek 12. Dwie reguły skonfigurowane w Compliance Items.

Konfiguracja Compliance Itmes opiera na wiedzy o konfiguracji systemu operacyjnego oraz tym co i gdzie należy sprawdzać. Późniejsza konfiguracja na serwerze ConfigMgr nie jest trudna.

Automatic Deployment Rule

Wdrażanie aktualizacji do systemów oraz oprogramowania jest niezwykle istotną cześcią pracy każdego administratora. Poprzednie wersje serwera ConfigMgr można było wdrażać aktualizację, ale był to proces żmudny i czasochłonny. Nie było możliwości automatyzacji tego procesu.

ConfigMgr 2012 wprowadza nową funkcjonalność – Automatic Deployment Rule. Funkcja ta oferuje możliwość automatycznego wdrażania aktualizacji bez potrzeby ingerencji administratora systemu

Rysunek 1. Skonfigurowane reguły Automatic Deployment Rule.

Automatic Deployment Rule wykonuje następujące czynności:

  • uruchamia synchronizację pomiędzy serwerem ConfigMgr, a serwerem WSUS.
  • tworzy Software Update Group. Software Update Group zawiera wszystkie aktualizacje spełniające warunki ustawione w Automatic Deployment Rule.
  • wszystkie aktulizacje spełniające kryteria przypisuje do stworzonej wcześniej Software Update Group.
  • pobiera z internetu i kopiuje we wskazane miejsce pliki wykonywalne aktualizacji.
  • tworzy Deployment Package i wysyła ją na wskazane w kreatorze Distribution Point.

Automatic Deployment Rule wykonuje te zadania zgodnie z harmonogramem ustawionym podczas tworzenia reguły. Jeśli podczas synchornizacji danych z serwerem WSUS pojawią się nowe aktualizacje spełniające kryteria zostaną one automatyczne dodane do Software Update Point, co oznacza wdrożenie zgodnie z ustawieniami Deployment przypisanymi do tej Software Update Group.

Tworzenie Automatic Deployment Rule

Konfiguracja Automatic Deployment Rule nie jest skomplikowana. Przed przystapieniem do tworzenia reguł należy wykonać integrację serwera ConfigMgr z serwerem WSUS oraz dokonać synchronizacji danych pomiędzy serwerami.

W celu stworzenia reguły wykorzystujemy kreatora Create Automatic Deployment Rule.

Rysunek 2. Kreator Create Automatic Deployment Rule.

Wpisujemy nazwę reguły, opis oraz kolekcję której ta reguła będzie dotyczyć.

Rysunek 3. Ekran początkowy kreatora Create Automatic Deployment Rule.

Domyślnie zawsze są zaznaczone dwie opcje: Add to an existing Software Update Group oraz Enable the deployment after this rule is run.

Software Update Group służy do grupowania aktualizacji w celu ich wdrażania. Można to porównać do kolekcji, tylko z tą różnicą, że nie dotyczy to obiektów komputerów czy użytkowników, ale aktualizacji. Mając Software Update Group można utworzyć Deployment wdrażający te aktualizacje. W tym wypadku w trakcie tworzenia reguły Automatic Deployment Rule zostanie utworzony również Deployment. Właczając opcje Add to an existing Software Update Group decydujemy, że aktualizacje zawsze będą dodawane do tej samej Software Update Group, lub przy każdym wykonaniu tej reguły będzie tworzona osobna Software Update Group.

Ustawiając opcje Enable the deployment after this rule is run decydujemy, że nasza reguła jest włączona. Jeśli jej nie włączymy to reguła zostanie uruchomiona, aktualizacje zostaną dodane do Software Update Group. Nie zostaną one jednak ściągnięte z Internetu, nie zostanie stworzona paczka Deployments Package. Innymi słowy wdrażenie ich nie zostanie uruchomione. Ta opcja jest użyteczna, gdy najpierw chcemy obejrzeć jakie aktualizacje spełniają warunki Automatic Deployment Rule, a dopiero potem je wdrazać.

Rysunek 4. Ustawienia General.

Następnie ustawiamy opcje dotyczące wdrazania. Możemy użyć funkcji Wake on LAN, ustawić poziom szczegółowości wysyłanych przez klienta danych o trwającym wdrożeniu. Przy wartości Normal klient wysyła wszystkie informacje dotyczące, przy opcji Minimal wysyła tylko informacje dotyczące powodzenia lub błędów.

Niektóre aktualizacje wymagają akceptacji postanowień licencyjnych. Tworząc regułę automatycznego wdrażania należy zaznaczyć opcje Automatically deploy all software updates found by this rule, and approve any license agreements. Dzięki temu aktualizacje wymagające akceptacji postanowień licencji będą mogły być wdrażane razem z innymi.

Rysunek 5. Ustawienia Deployment Settings.

Kolejnym krokiem jest ustawienie kryteriów jakie muszą spełnić aktualizacje, które będą wdrażane przez tą regułę. Możemy np. wybrać filter Product, a nastepnie Windows 7.

Rysunek 6. Wybór kryteriów dla wdrażanych aktualizacji.

Kryteriów jakie mają spełnić aktualizacje może być więcej niż jeden. Możemy np. dodać typ aktualizacji jakie chcemy wdrożyć np. ważność Critical.

Rysunek 7. Dodawanie kryteriów ze względu na ważność.

Kolejnym krokiem może być dodanie aktualizacji po typie np. Security Updates.

Rysunek 8. Dodawanie kryteriów ze względu na typ aktulizacji.

Po ustawieniu kryteriów regula będzie automatycznie wdrażać aktualizacje krytyczne typu Security Updates dla systemów Windows 7

Rysunek 9. Końcowe ustawienia kryteriów aktualizacji wdrażanych przez regułę.

Kolejnym krokiem jest ustawienie harmonogramu wykonywania przez serwer reguły.

Rysunek 10. Ustawienia harmonogramu wykonywania reguły.

Po ustawieniu harmonogramu należy określić kiedy i jak będa wdrażane aktualizacje. Gdy serwer ConfigMgr obsługuje klientów będących w jednej strefie czasowej, trzeba ustawić opcje Time based on na Client Local Time.

Dwie następne opcje decydują o tym kiedy będa dostępne aktualizacje oraz kiedy nastapi automatyczna instalacja. Opcja Software available time okreśa od kiedy aktualizacje wdraźane przez tą regułę będą dostępne dla klientów. Domyślnym ustawieniem jest As soon as possible. Opcja Installation deadline decyduje kiedy aktualizacje zostaną zainstalowane przez klienta ConfigMgr. Domyślnym ustawieniem jest 7 dni od daty uruchomienia reguły.

Rysunek 12. Ustawienia Deployments Schedule.

Wdrażane aktualizacje mogą być widoczne dla użytkownika, nawet jeśli podlegają automatycznej instalacji. Opcje User notifications służą do ukrywania powiadomień dla użytkowników o rozpoczęciu instalacji. Ta opcja jest też przydatna gdy chcemy najpierw przetestować działanie reguły na komputerach testowych. Opcje Deadline behavior służą do sterowania instalacją poza zdefiniowanymi dla komputera Maintenance Windows. Opcje Device restart behavior służą do sterowania możliwością ponownego uruchomienia po instalacji aktualizacji.

Rysunek 11. Ustawienia User Expierence.

Nowością w ConfigMgr 2012 jest możliwość skorzystania z alertów. Alerty te pokazują się na konsoli serwera. Można je skonfigurować również dla AutomatiC Deployments Rule. Domyślnie alerty nie sa aktywne. Tak samo jak w poprzedniej wersji przy pomocy opcji Operations Manager alerts można wyłączyć monitorowanie wykonywane przez System Center Operations Manager 2007/2012.

Rysunek 13. Ustawienia Alerts.

Przeważająca większość wykonywanych instalacji przez klienta ConfigMgr jest poprzedzona ściągnięciem do katalogu Cache plików potrzebnych do wykonania przypisanego zadania. Na zakładce Download Settings określamy kiedy klient ConfigMgr ma kopiować na lokalny dysk pliki wykonywalne aktualizacji. Te opcje są identyczne jak w poprzedniej wersji. Możemy je określić oddzielnie dla granic typu Slow i Fast. Domyślnie jesli adres IP klienta zawarty jest w granicy typu Slow, żadne pliki nie zostaną pobrane przez klienta. Jeśli adres IP zawiera się w granicy typu Fast pliki będą pobierane z punktu dystrybucyjnego do lokalnego katalogu Cache. Typy granic określa się przy tworzeniu Boundary Groups

Rysunek 14. Ustawienia Download Settings.

Kolejnym krokiem jest utworzenie na serwerze ConfigMgr paczki, która będzie zawierać wdrażane aktualizacje. Musimy podać nazwę udziału sieciowego, do którego serwer ConfigMgr ma nadane prawa Full Control.  Zostaną tam ściągnięte z Internetu pliki wykonywalne aktualizacji.

Rysunek 15. Tworzenie Deployment Package.

Jeśli mamy już stworzoną wcześniej paczkę Deployment Packages możemy do niej dorzucić wdrażane przez Automatic Deployment Rule aktualizacje. W taki układzie wybieramy opcje Select deployment packages.

Ponieważ tworzona reguła ma automatycznie wdrażać aktualizacje musimy wskazać punkt dystrybucyjny na który zostanie wysłana paczka po jej stworzeniu lub aktualizacji.

Rysunek 16. Wybór punktu dystrybucyjnego.

Pliki wykonywalne mogą zostać ściągnięte z Internetu lub wskazanego udziału sieciowego. W przypadku wdrażania aktualizacji np. Adobe przy użyciu System Center Update Publisher należy również wskazać opcje Download software updates from the Internet.

Rysunek 17. Wskazanie miejsca skąd zostaną skopiowane pliki wykonywalne aktualizacji.

Końcowym etapem konfiguracji reguły jest wkazanie jakie wersje językowe aktualizacji nas interesują. Trzeba pamiętać, że każda wersja językowa to oddzielny plik wykonywalny.

Rysunek 18. Wybór wersji językowej aktualizacji.

Po wyborze wersji językowych możemy przeczytać podsumowanie ustawień reguły i sprawdzić przed jej utworzeniem czy wszystko jest odpowiednio ustawione.

Rysunek 19. Podsumowanie ustawień reguły.

Po zakończeniu pracy kreatora możemy przeczytać podsumowanie pracy kreatora. Pamiętajmy, że stworzyliśmy samą regułę.

Rysunek 20. Podsumowanie po zakończeniu pracy kreatora tworzącego regułę.

Reguły Automatic Deployment Rules można obejrzeć na zakładce Software Library\Overview\Software Updates\Automatic Deployment Rules.

Rysunek 21. Utworzone reguły Automatic Deploymet Rules.

Teraz wystarczy poczekać aż reguła zacznie działać. W logu PatchDownloader.log na serwerze ConfigMgr możemy obejrzeć czy serwer ConfigMgr ściąga pliki wykonywalne z Internetu, a następnie zapisuje je we wskazanym w regule udziale sieciowym.

Rysunek 22. Log PachDownloader zawiera informacje dotyczące pobierania z internetu aktualizacji.

Ściągnięte pliki możemy tez objerzeć poprzez udział sieciowy lub dysk lokalny,

Rysunek 23. Katalog ze ściągniętymi plikami wykonywalnymi aktualizacji.
Rysunek 23. Katalog ze ściągniętymi plikami wykonywalnymi aktualizacji.

Po zakończeniu ściągania plików tworzona jest na serwerze Deployment Packages zgodnie z ustawieniami w regule.

Rysunek 24. Informacje o utworzonej przez regułe paczce Deployment Packages.
Rysunek 24. Informacje o utworzonej przez regułe paczce Deployment Packages.

W logu serwera distmgr.log możemy obejrzeć informacje o utworzeniu paczki oraz dodaniu jej do serwera ConfigMgr.

Rysunek 25. Log distmgr.log zawiera informacje o utworzeniu paczki.
Rysunek 25. Log distmgr.log zawiera informacje o utworzeniu paczki.

Utworzoną przez regułę Software Update Group możemy obejrzeć na zakładce Software Library\Overview\Software Updates\Software Updates Groups.

Rysunek 26. Informacje o utworzonej Software Update Groups.
Rysunek 26. Informacje o utworzonej Software Update Groups.

Warto też sprawdzić, czy został stworzony Deployment zgodnie z ustawieniami reguły.

Rysunek 27. Ustawienia Deployment dotyczące Software Update Groups.
Rysunek 27. Ustawienia Deployment dotyczące Software Update Groups.

Gdy klienci ConfigMgr pobiorą polise z ustawieniamia Software Updates, stacja zostanie przeskanowana przez Windows Udpate Agent. Zgodnie z ustawieniami User Expierence użytkownik został poinformowany o dostępnych dla jego komputera aktualizacjach. Może on je zainstalować samodzielnie lub poczekać, aż klient ConfigMgr zainstaluje zgodnie z ustwieniami reguły.

Rysunek 28. Software Centre pokazuje dostępne aktulizacje.
Rysunek 28. Software Centre pokazuje dostępne aktualizacje.

Po zakończeniu konfiguracji reguł system będzie już wykonywał wszystko sam. Administratorowi pozostaje monitorować ilość wolnego miejsca na pliki wykonywalne oraz stan komponentów serwera ConfigMgr odpowiedzialnych za poprawne działanie Automatic Deployment Rules.

Task Sequences Standalone Media

Wdrażając systemy operacyjne możemy napotkać problem wolnych lub złej jakości sieci. Problem ten dotyczy zwłaszcza operacji związanych z przesłaniem dużej ilości danych poprzez sieć. Jednym z rozwiązań tego problemu jest wykorzystanie Stand-alone media. Używa się go w trzech przypadkach:

  • gdy połączenie sieciowe pomiędzy komputerem, na którym trwa instalacja, a punktem dystrybucyjnym jest zbyt wolne lub złej jakości.
  • gdy nie ma połączenia sieciowego pomiędzy komputerem, na którym trwa instalacja, a punktem dystrybucyjnym
  • gdy nie chcemy korzystać z połączenia sieciowego.

Poniżej przykład Task Sequences, który posłuży nam do utworzenia Stand-alone media.

Rysunek 1. Konfiguracja przygotowanego Task Seqeunces

Stand-alone media jest specjalnym plikiem .iso, który zawiera w sobie wszystkie pliki potrzebne do wykonania wszystkich zadań zawartych w danym Task Sequences. Wszystkie obiekty wchodzące w jego skład, muszą być wysłane na punkt dystrybucyjny zanim przystąpimy do tworzenia Stand-alone media.

Rysunek 2. Sprawdzenie czy wszystkie obiekty zostały wysłane na punkt dystrybucyjny.

Warto tutaj zwrócić uwagę, na fakt, że konsola nie pokazuje informacji o innych aplikacjach zdefiniowanych jako zależności do aplikacji wdrażanych przez Task Sequences oraz nie pokazuje paczek z sterownikami.

Do stworzenia Stand-alone media wykorzystujemy kreatora Create Task Sequences Media.

Rysunek 3. uruchomienie kreatora tworzeznia Stand-alone media.

Z dostępnych opcji wybieramy Stand-alone media

Rysunek 4. Wybór Media Types.

Pierwszym krokiem jest decyzja na jaki nośnik będzie nagrany Stand-alone media. Mamy do wyboru nośnik USB lub nośnik CD/DVD. W celu nagrania płyty CD/DVD lub nagrania na bezpośrednio na nośnik USB musimy konsolę serwera uruchomić na komputerze fizycznym z nagrywarką CD/DVD lub włożonym nośnikiem USB. Jeśli uruchomimy konsolę bez dostępu do nagrywarki lub nośnika USB, należy wybrać typ nośnika oraz wskazać miejsce i nazwę pliku ISO. Plik ISO możemy później nagrać na CD/DVD lub nośnik USB, lub używać bezpośrednio przy wdrażaniu wirtualnych maszyn.

Rysunek 5. Wybór sposobu zapisania Task Sequences.

Ponieważ Stand-alone media może być wykorzystywany bez dostępu do sieci warto go zabezpieczyć hasłem przed nieautoryzowanym użyciem

Rysunek 6. Konfiguracja hasła

Po zabezpieczeniu hasłem wskazujemy przyciskiem Browse, który Task Sequences chcemy wykorzystać do stworzenia Stand-alone media. Kreator pokaże nam wszystkie elementy wchodzące w skład wskazanego Task Sequences. Tworząc Stand-alone media mamy możliwość skorzystania ze wszystkich aplikacji razem z aplikacjami zależnym lub tylko z aplikacji głównych. Służy do tego opcja Detect associated application dependencies and add them to the media. Opcja ta jest domyślnie włączona. Dodatkowo kreator przy każdym elemencie danego Tak Sequences wyświetla nam informacje, czy ten element posiada jakieś zależności. Do Stand-alone media zostaną wgrane tylko aplikacje pokazane w okienku Stand-Alone CD/DVD.

Rysunek 7. Aplikacje wchodzące w skład Stand-alone media wraz z aplikacjami zależnymi.
Rysunek 8. Aplikacje wchodzące w skład Stand-alone media bez aplikacji zależnych.

W kolejnych kroku wskazujemy z jakiego punktu dystrybucyjnego zostaną wgrane pliki do obrazu Stand-alone media.

Rysunek 9. Wskazanie punktu dystrybucyjnego na którym sa pliki potrzebne do utworzenia Stand-alone media.

Stand-alone media umożliwia wykorzystanie zmiennych w trakcie wdrażania systemu. Ja wykorzystałem zmienną OSDComputerName do konfiguracji nazwy komputera.

Rysunek 10. Wybór zmiennej.
Rysunek 11. Konfiguracja zmiennej.

Po zakończeniu konfiguracji możemy przejrzeć ustawienia i przystąpić do tworzenia Stand-alone media.

Rysunek 12. Proces tworzenia Stand-alone media.

Proces tworzenia Stand-alone media możemy obejrzeć oprócz konsoli również w logu serwera CreateTSMedia.log.

Rysunek 13. Informacje w logu o procesie tworzenia Stand-alone media.

Po zakończeniu pracy kreatora dostajemy komunikat na konsoli o status wykonania kreatora.

Rysunek 14. Zakończenie pracy kreatora

Tę samą informacje możemy obejrzeć w logu CreateTsMedia.log.

Rysunek 15. Informacja w logu o zakończeniu tworzenia Stand-alone media.

Proces wdrożenia systemu operacyjnego możemy rozpocząć z nośnika USB lub płytki CD/DVD. Po załadowaniu Windows PE natychmiast startuje Task Sequences. Jeśli podczas tworzenia Stand-alone media wpisaliśmy hasło należy je podać, aby przejść dalej.

Rysunek 16. Rozpoczęcie wdrożenia systemu operacyjnego.

Po wpisaniu hasła pokaże się nam komunikat jaki Task Sequences zostanie uruchomiony. W naszym przykładzie nazywa się StandAlone.

Rysunek 17. Informacja jaki Task Seqeunces zostanie wykonany.

Ponieważ skonfigurowaliśmy zmienną OSDComputerName kreator pyta nas czy chcemy pod zmienną podstawić wartość. Zaznaczamy zmienną i naciskamy dwa razy myszką.

Rysunek 18. Wykaz skonfigurowanych zmiennych.
Rysunek 19. Konfiguracja wartości zmiennej.

Task Sequences oparty o Stand-alone media może wykonywać się bez korzystania z połączeń sieciowych ponieważ wszystkie potrzebne elementy potrzebne do wykonania są dostępne offline na komputerze. Poniżej widok katalogu SMS\PKG na dysku D (czyli płycie DVD, lub pendrive). W tym katalogu znajdują się wszystkie paczki wykorzystywane przez Task Sequences.

Rysunek 20. Wykaz wszystkich paczek dostępnych offline na komputerze.

W poszczególnych katalogach znajdują się pliki paczek. Poniżej widok na katalog zawierający plik wim z obrazem systemu operacyjnego wdrażanego w tym Task Sequences.

Rysunek 21. Katalog z obrazem systemu operacyjnego.

Po zakończeniu działania Task Sequnces w Control Panel możemy sprawdzić jakie aplikacje zostały zainstalowane. Mimo że nie było dostępu do sieci, zostały zainstalowane aplikacje główne oraz zależne.

Rysunek 22. Zainstalowany system operacyjny wraz z aplikacjami.

Failed to Run Task Sequences – Network Access Account

Podczas wdrażania systemów operacyjnych możemy napotkać komunikat Failed to Run Task Sequence. Przyczyny takiego stanu mogą być bardzo różne. Poniżej komunikat związany jest z brakiem skonfigurowanego konta Network Access Account.

Rysunek 1. Komunikat Failed to Run Task Sequences związany z brakiem dostępu do punktu dstrybucynego

Konto Network Access Account jest potrzebne, żeby podczas instalacji systemu operacyjnego instalator mógł pobrać z punktu dystrybucyjnego pliki.

Dla pewności powinniśmy sprawdzić w logu czy faktycznie problemem jest brak skonfigurowanego konta. Informacje te znajdziemy w logu smsts.log. Jest on zapisywany w katalogu X:\SMSTS.LOG jeśli komputer, na którym jest uruchomiony Task Sequences nie ma żadnej partycji. Natomiast na komputerze, który ma już partycję stworzoną i sformatowaną to log będzie zapisywany w katalog c:\SMSTS.LOG.

Rysunek 2. Błędy w logu smsts.log.

Wpis Attepting to connect to “\\SCCM.VPRODEMO.COM\SMSPKGD$\A010001” świadczy o tym, że TS próbuje ściągnąć na lokalny komputer paczkę z boot image. Wpis Failed to connect “\\SCCM.VPRODEMO.COM\SMSPKGD$\A010001” (86) świadczy o tym, że instalator nie mógł dostać się do punktu dystrybucyjnego. Jeśli sprawdziliśmy, że wszystkie paczki są dostępne na punkcie dystrybucyjnym to na pewno ten błąd jest spowodowany, tym że instalator nie ma odpowiednich uprawnień do pobrania plików z punktu dystrybycyjnego.

Konto Network Access Account ustawiamy w Administration\Overview\Site Configuration\Sites. Zaznaczamy site i następnie prawy klawisz myszy.

sdsds
Rysunek 3. Administration\Overview\Site Configuration\Sites

Korzystamy z opcji Configure Site Component\Software Distribution

Rysunek 4. Opcja Software Distribution

Na zakładce Network Access Account definiujemy konto/konta, jakie będą używane do pobrania plików z punktu dystrybucyjnego.

Rysunek 5. Zdefiniowane konta Network Access Account.

Wpisujemy konto oraz hasło. Pamiętajmy, że konto ani hasło nie są sprawdzane. W celu weryfikacji konta można skorzystać z opcji Verify.

Rysunek 6. Definiowanie konta

Teraz wystarczy ponownie uruchomić Task Sequences, żeby przekonać się, że problem został rozwiązany.

Rysunek 7. Brak błędów podczas pobierania plików z punktu dystrybucyjnego.

Wpis Successfully connected to “\\SCCM.VPRODEMO.COM\SMSPKGD$\A0100001” świadczy, że podaliśmy poprawnie konto Network Access Account.

Asset Intelligence

Asset Intelligence to funkcja umożliwiająca administratorom posiadanie wiedzy na temat licencji wykorzystywanych w środowisku zarządzanym przez serwer ConfigMgr. Konfiguracja Asset Intelligence składa się z trzech etapów:

  • sprawdzenia czy jest włączone skanowanie Hardware Inventory.
  • zmianie konfiguracji konfiguracji skanowania Hardware Inventory przez dodanie dodatkowych klas bazy Windows Management Instrumentation.
  • zaimportowania do bazy danych serwera ConfigMgr informacji o zakupionych licencjach

Sprawdzenie działania Hardware Inventory

Sprawdzenie czy Hardware Inventory działa poprawnie jest bardzo proste. Zaznaczamy na konsoli serwera dowolny komputer i sprawdzamy w Resource Explorer, czy są dostępne dane ze skanowania Hardware

Rysunek 1. Dane ze skanowania Hardware Inventory widoczne na konsoli serwera.

Zmiana konfiguracji Hardware Inventory

Zmianę domyślnej konfiguracji klas Aseet Intelligence wykonuje na konsoli serwera w \Assets and Compliance\Overview\Asset Intelligence.

Rysunek 2. Opcja Edit Inventory Classes służy do miany konfiguracji Asset Intelligence.

Następnie musimy zdecydować, które klasy chcemy włączyć lub nie. Każda z klas zawiera dane wykorzystywane później w konkretnych raportach Asset Intelligence.

Rysunek 3. Klasy Asset Intelligence.

Importowanie danych o licencjach do bazy serwera

Importowanie danych o zakupionych licencjach wykonuje się na konsoli serwera w \Assets and Compliance\Overview\Asset Intelligence.

Rysunek 4. Kreator importowania danych o licencjach

Dane o licencjach dzielimy na dwa rodzaje. Licencje Microosft Volume License oraz Geeneral License. Te pierwsze są importowane z pliku pobrane ze strony MVLS. te drugie są importowane na podstawie ręcznie przygotowanego pliku xls. Dane type General License mogą zawierać informacje o liencjach nie kupionych od Microsoft.

Rysunek 5. Wybór typu licencji jakie będą importowane.

Po zaimportowaniu danych możemy wyniki działania Asset Intelligence przejrzeć na konsoli serwera o raz w raportach

Dane Asset Intelligence

Przegląd danych Asset Intelligence zaczynamy od sprawdzenia konfiguracji na konsoli w \Assets and Compliance\Overview\Asset Intelligence.

Rysunek 6. Stan konfiguracji Asset intelligence.

Zakładka Asset Intelligence podzielona jest na trzy części: Catalog, Inventoried Software oraz Hardware Requirements. Do każdego odnalezionego oprogramowania można przydzielić dwa atrybuty: Family oraz Category. Służą one do wyszukania aplikacji o podobnym charakterze i przeznaczeniu. Administrator ma możliwość stworzenia swoich własnych Category lub Family oraz zmieniać przydział atrybutów do aplikacji.Poniżej zakładka Asset Intelligence -> Catalog w której znajdują stworzone podczas instalacji Family oraz Category.

Rysunek 7. Wykaz domyślnych Family oraz Category.

Zakładka Hardware Requirements pokazuje nam domyślne wymagania, jakie muszą być spełnione, aby uznać system operacyjnych za gotowy do instalacji danej aplikacji. Instalator tworzy domyślne wymagania, lecz tak samo jak w poprzednim przypadku administrator może tworzyć swoje własne wymagania. Wymagania te można wykorzystywać w raportach do wyszukania systemów zgodnych z danymi wymaganiami.

Rysunek 8. Wykaz domyślnych Hardware Requirements.

Zakładka Inventoried Software pokazuje nam całe oprogramowanie znalezione przez serwer ConfigMgr. Znajdziemy tutaj informacje o nazwie aplikacji, producencie, wersji aplikacji oraz przydzielonych do aplikacji atrybutach Category lub Family. Przydział ten można zmieniać w dowolnym momencie. Dlaczego ten wykaz jest taki istotny ? Z bardzo prostego powodu. Znacznie łatwiej wyszukać komputer, na którym jest zainstalowana aplikacja jeśli wiemy jak się ona dokładnie nazywa. Poniżej wykaz wykrytego oprogramowania przez serwer ConfigMgr.

Rysunek 9. Wykaz wykrytego oprogramowania przez serwer ConfigMgr.

Na serwerze mamy do dyspozycji ponad 60 różnych raportów wykorzystujących dane Asset Intelligence. Poniżej przykłady kilku z nich. Raport Microsoft Volume License ledger for Microsoft license statements pokazuje dane dotyczące ilości wykrytego oprogramowania dostępne w programie Volume License.

Rysunek 10. Raport pokazujące zainstalowane oprogramowania Volume License.

Raport Software in a specific product family and category pokazuje dane o wykrytych oprogramowania w/g przynależności do rodziny i kategorii produktu.

Rysunek 11. Software in a specific product family and category

Raport Generali license reconclilation pokazuje porównanie danych o licencjach innych niż Volume License do bazy danych, z tymi pochodzącymi z Hardware Inventory

Rysunek 12. Generali license reconclilation

Raport Microosft Volume Licensing reconclliation pokazuje porównanie danych Voluem license zaimportowanych do bazy danych, z tymi pochodzącymi z Hardware Inventory.

Rysunek 13. Microosft Volume Licensing reconclliation

ConfigMgr Remote Actions

Agent ConfigMgr jest zarządzany poprzez ustawienia które zapisane są w polisie, a którą pobiera z serwera Management Point. Zwykle nie potrzebujemy nic zmieniać w harmonogramie wykonywania zadań agenta ConfigMgr. Jednak czasami są sytuacje, gdy potrzebujemy uruchomić konkretne zadanie niezależnie od harmonogramu ustawionego przez administratora. Możemy to zrobić ręcznie, lub zdalnie.

Rysunek 1. Zakładka Actions służąca do uruchamiania zadań wykonywanych przez agenta ConfigMgr.

Poznać Meaase ID przypisane do zadań możemy poznac również z poziomu wiersza poleceń. Użyjemy do tego programu sendschedule.exe. Wykonując polecenie sendschedule /L otrzymamy informację jakie Message GUID odpowiadają konkretnym zadaniom.

Rysunek 2. Dostępne Message GUID.

Już wiemy, który Message GUID jest skojarzony z jaką akcją. Gdy potrzebujemy uruchomić np. skanowanie Hardware Inventory należy wykonać następującą komendę: sendschedule {00000000-0000-0000-0000-000000000001} SCCM01. Pozostaje tylko sprawdzić czy komenda została wykonana. Uruchamiamy Trace32 i podłączamy się zdalnie do komputera SCCM01, aby obejrzeć log InventoryAgent.log.

Rysunek 3. Informacje o wykonywanych zadaniach Hardware Inventory możemy obejrzeć w logu InevntoryAgent.log.

Wpis Inventory: Message Type is InevntoryAction świadczy o typie rozpoczętego zadania, natomiast Inventory: Opennig store for action 00000000-0000-0000-0000-000000000001} świadczy o tym, że nasz komunikat został przez agenta odebrany i zostanie przez niego wykonany.Dla pewności sprawdźmy czy wyniki skanowania zapisały się w bazie. Uruchamiamy Resource Exlorer. W sekcji Hardware > Workstation Status są zapisane informacje o czasie ostatniego skanowania Hardware Inventory.

Rysunek 4. Hardware Status są zapisane informacje o dacie wykonania skanowania Hardware Inventory.

Wiedząc jak wywołać akcję na jednym prostym zadaniem będzie przygotować rozszerzenie konsoli serwera ConfigMgr, aby móc wykonywać zadania na komputerach z wybranej przez nas kolekcji.

User Migration Recovery Key

W trakcie wdrażania systemów operacyjnych mamy możliwość migracji profili użytkowników z jednego systemu operacyjnego do drugiego. Migracja jest wykonywana przez narzędzie User State Migration Tool. Migracja profili może byc wykonana pomiędzy dwoma różnymi komputerami. W takim wypadku jest używana rola serwerowa State Migration Point. Profile użytkowników są skompresowane oraz zaszyfrowane w celu zabezpieczenia ich przed nieautoryzowanym dostępem. Zdarza się, że administrator musi dostać się do tego pliku. Można to zrobić przy pomocy narzędzia usmtutil.exe. Jest ono częścią Windows Assestment and Deployment Toolkit. Oprócz narzędzia usmtutil.exe Point, musimy znać Recover key. Recovery key posłuży nam do odszyfrowania danych. Informacje o wykonanych przez serwer migracjach danych znajdziemy na zakładce Asset and Compliance\User State Migration. W tym miejscu serwer zapisuje z jakich komputerów zostały zapisane profile, jaki scenariusz jest/został wykorzystany oraz na jaki komputer dane zostały/zostaną ponownie wgrane.

Rysunek 1. Informacje na konsoli serwera o wykonanych migracjach profili użytkowników.

Dane z komputera są zapisywane na State Migration Point do oddzielnych katalogów w plikach o rozszerzeniu mig. W celu dostania się do tych danych potrzebujemy dwóch informacji: nazwy katalogu, w którym są zapisane dane oraz przypisanego do tego profilu Recovery Key.

Rysunek 2. Opcja View Recovery Information wyświetla informacje o Recovery Key.

User State Recovery Information zawiera wszystkie dane potrzebne, aby móc uzyskać dostęp do danych zapisanych na State Migration Point.

Rysunek 3. User State Recovery Information dotyczące zapisanych danych z konkretnego komputera.

User state recovery key trzeba skopiować z konsoli serwera i zapisać do pliku tekstowego. Dostęp do pliku mig, w którym zapisaye jest User State uzyskamy poprzez wykorzystanie narzędzia usmtutil.exe. Przed jego użyciem należy stworzyć katalog do którego zostaną zapisane dane przechowywane w pliku mig. Następnie otwieramy Deployment and Imaging Tools Environment i uruchamiamy polecenie: usmtutil.exe /extract <śceżka do pliku MIG\usmt.mig> <ścieżka do katalogu, w którym dostepne będa dane> /decrypt /keyfile: <nazwa pliku z recovery key>.

Rysunek 4. Komenda usmtutil służąca do wyodrębnienia plików ze wskazanego pliku mig do wskazanego katalogu.

W zależności od wielkości pliku mig proces wyodrębniania może zająć dłuższą chwilę.

Rysunek 5. Proces działania usmtutil.exe

Wskazany jako parametr katalog zawiera dane z pliku mig. Dane nie są już zaszyfrowane i skompresowane. Od tej chwili mamy dostęp do danych zapisanych podczas wykonywania Task Sequences w zadaniu Capture User State.

Rysunek 6. Katalog zawierający dane zapisane w pliku mig.

Incremental evaulation collections

Podstawą dla wykonywanych przez serwer Configuration Manager zadań są kolekcje. Są one tworzone na podstawie zapytań do bazy WMI. Kolekcje dzielimy na dwa podstawowe: dynamiczne oparte o wyniki zapytań wykonywanych przez serwer zgodnie z zadanym harmonogramem, oraz te do których obiekty są dodawane ręcznie przez administratora serwera.Dane na których wykonują się zapytania są zapisywane w bazie ConfigMgr np. na podstawie Active Directory Discovery Methods. Skanowanie bazy Active Directory wykonuje sie rowniez zgodnie z harmonogramem ustalonym przez administratora. Wykonanie pełengo skanowania powoduje utworzenie nowych obiektów (w przypadku wykrycia nowego obiektu Active Directory) lub aktualizacji już istniejących obiektów (w przypadku zmian atrybutu Active Directory danego obiektu). Można ustawić dodatkowe skanowanie delta, które skanuje Active Directory w poszukiwaniu zmian dotyczących obiektów, które już są w bazie serwera ConfigMgr. Skanowanie to może odbywać się najdłużej co 60 minut.Zapisanie w bazie zmian wykrytych przez ten rodzaj skanowania nie powoduje natychmiastowych zmian przynależności obiektów do danej kolekcji. W celu aktualizacji kolekcji musimy wymusić ręcznie aktualizację na konsoli serwera, lub poczekać aż dobędzie się aktualizacja zgodnie z zadeklarowanym przez administratora harmonogramem.Pracując z serwerem ConfigMgr mamy możliwość skorzystania z dodatkowej opcji, która powoduje znacznie szybsze aktualizację kolekcji na podstawie zmian dokonywanych w bazie serwera ConfigMgr, niezależnie od tego w jaki sposób te dane zostały zapisane (np. czy przez Discovery Methods lub Hardware Inventory).Poniżej pokażę jak skonfigurować Icremental updates dla kolekcji bazującej na zapytaniu o przynależnośc komputera do wskazanego przez administratora jednostki organizacyjnej AD.

Rysunek 1. Kolekcja bazująca na informacji o tym w jakim OU znajduje się konto komputera.

Kolekcja ta bazuje na zapytaniu o tym, w jakiej jednostce organizacyjnej Active Directory znajduje się dany komputer. Atrybut SystemOUName jest zapisywany w bazie ConfigMgr podczas wykonywania skanowania Active Directory System Discovery. To skanowanie domyślnie wykonuje się co 7 dni. Sama kolekcja tez swój harmonogram aktualizacji, domyślnie co 7 dni. Wyniki tego zapytania możemy obejrzeć na konsoli. Nie zmienią się one do momentu następnej pełnej aktualizacji.Włączenie opcji Use icremental updates for this collection powoduje aktualizację kolekcji po 10 min od momentu wykonaniu skanowania typu delta przez komponent Actve Directory System Discovery.

Rysunek 2. Ustawienia aktualizacji kolekcji.

Zapytanie, które pokazuje komputery należące do danej jednostki organizacyjnej bazuje na atrybucie SystemOUName.

Rysunek 3. Definicja zapytania opartego o atrybut SystemOUName.

W naszym przykładzie pełne wykrywanie obiektów Active Directory wykonuje się raz dziennie, natomiast co 5 minut odbywa się skanowanie delta discovery Active Directory w poszukiwaniu zmian konfiguracji obiektów AD, które już istnieją w bazie ConfigMgr.

Rysunek 4. Ustawienia komponentu Active Directory System Discovery.

Przed wykonaniem Incremental updates w OU CM2012 znajdowało się 7 kont komputerów.

Rysunek 5. Komputer znadujące sie w jednostce organizacyjnej CM 2012.

Informacje widoczne na serwerze pokrywają się z tymi w Active Directory. Kolekcja zawiera 7 obiektów typu Computer.

Rysunek 6. Obiekty znajdujące się w kolekcji OU Server CM2012.