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.