Spis treści
Zanim zaczniesz: planowanie wdrożenia ILMT
Wdrażaliśmy ILMT w środowiskach od 30 endpointów do ponad 15 000. Jeden czynnik wpływa na powodzenie instalacji bardziej niż wszystkie pozostałe razem wzięte: planowanie. Zanim pobierzesz pierwszy instalator, musisz dokładnie wiedzieć, jak duże jest Twoje środowisko i jakich zasobów będzie potrzebował ILMT.
Na początek podziel swoje środowisko na kategorie. Małe środowisko to wszystko poniżej 100 endpointów. Średnie obejmuje od 100 do 1000. Duże oznacza 1000 lub więcej. Te progi są istotne, bo bezpośrednio wpływają na wymagania sprzętowe, architekturę BigFix i czas trwania projektu.
Dla małego środowiska poniżej 100 endpointów można uruchomić serwer BigFix i serwer ILMT na jednej maszynie. Przydziel co najmniej 4 GB RAM, 2 rdzenie CPU i 80 GB przestrzeni dyskowej. To rozsądny punkt wyjścia na potrzeby weryfikacji koncepcji lub dla organizacji z niewielkim portfolio oprogramowania IBM.
Średnie środowiska wymagają oddzielnych serwerów. Serwer BigFix powinien mieć co najmniej 8 GB RAM, 4 rdzenie CPU i 200 GB dysku. Serwer ILMT potrzebuje własnej maszyny z 8 GB RAM, 4 rdzeniami i 100 GB przestrzeni. ILMT korzysta z wbudowanej instancji DB2 do przechowywania danych, a ta baza rośnie wraz z rozwojem środowiska i historią raportów. Nie lekceważ wymagań dyskowych. Widzieliśmy instalacje, w których przestrzeń dyskowa kończyła się w ciągu sześciu miesięcy, bo ktoś zaplanował pojemność na podstawie danych z pierwszego dnia zamiast prognozowanego wzrostu.
Duże środowiska wymagają jeszcze staranniejszego planowania. Prawdopodobnie będziesz potrzebować przekaźników BigFix (relay), żeby rozłożyć obciążenie komunikacyjne agentów, szczególnie jeśli masz oddalone lokalizacje lub centra danych połączone łączami WAN. Przekaźnik to lokalny punkt dystrybucji, z którym agenty komunikują się zamiast kontaktować się z centralnym serwerem BigFix przy każdym żądaniu. Bez przekaźników duże środowiska przeciążają centralny serwer, a agenty zaczynają gubić raporty. Zaplanuj co najmniej jeden przekaźnik na każdą zdalną lokalizację lub na 500 do 1000 agentów.
Planowanie sieci zasługuje na osobną uwagę. Agenty BigFix komunikują się z serwerem (lub przekaźnikiem) domyślnie na porcie TCP 52311. Serwer ILMT potrzebuje dostępu do bazy danych BigFix, zwykle przez port TCP 50000 dla DB2 lub 1433 dla SQL Server. Jeśli Twoje środowisko obejmuje wiele stref sieciowych z firewallami między nimi, udokumentuj te połączenia wcześnie i otwieraj reguły firewalla przed rozpoczęciem instalacji. Problemy z firewallem to przyczyna numer jeden zatrzymanych wdrożeń, które spotykamy w praktyce.
Krok 1: Instalacja serwera BigFix
BigFix jest fundamentem każdego wdrożenia ILMT. Bez działającej infrastruktury BigFix, ILMT nie ma z czym pracować. Serwer BigFix zbiera dane z każdego endpointa w środowisku i przechowuje je centralnie. ILMT następnie odczytuje te dane, żeby generować raporty zgodności licencyjnej.
Jeden szczegół, który wiele organizacji pomija: klienci Passport Advantage mają prawo korzystać z BigFix Inventory bez dodatkowego kosztu licencyjnego, konkretnie w celach raportowania sub-capacity. Uprawnienie nazywa się IBM License Metric Tool. Oprogramowanie, które zainstalujesz, może być oznaczone jako BigFix Inventory (brandowanie HCL) lub IBM License Metric Tool (brandowanie IBM) w zależności od tego, jak je pozyskałeś. To ten sam kod, certyfikowany jako równoważny dla sub-capacity. To nie jest pełna licencja BigFix Lifecycle ani BigFix Compliance. Możesz uruchamiać skany, generować raporty i operować platformą do celów metryki licencyjnej. Jeśli BigFix Inventory nie pasuje do Twojego środowiska, istnieją inne zatwierdzone alternatywy dla ILMT, które IBM akceptuje w raportowaniu sub-capacity. Używanie tych samych agentów i serwera BigFix do patchowania, utwardzania systemów operacyjnych czy dystrybucji oprogramowania wymaga oddzielnej komercyjnej licencji BigFix. Mieszanie tych dwóch rzeczy to częsta luka zgodności, którą znajdujemy podczas audytów u klientów. Instalator pobierzesz ze strony IBM Passport Advantage lub IBM Fix Central.
Serwer BigFix działa na Windows Server albo na Red Hat Enterprise Linux. Dla Windows aktualnie wspierane wersje to Windows Server 2019 i 2022 (Windows Server 2016 jest nadal wspierany w starszych wydaniach BigFix, ale wyszedł poza mainstream support Microsoftu, nie polecamy go do nowych wdrożeń). Dla Linuksa BigFix Platform 10 i 11 wspiera RHEL 8 na x86_64, a jako backend bazodanowy potrzebujesz IBM DB2 11.5.x. Wybór zależy od tego, co Twój zespół już dobrze obsługuje. Wdrożenia na Windows są nadal częstsze w praktyce, bo BigFix przez lata żył na Windowsie zanim pojawiło się wsparcie dla Linuksa. Jeśli Twoja organizacja jest Linux-first i nie ma mocnego zespołu Windows ops, instalacja na RHEL jest w pełni wspieraną ścieżką. Kreator instalacji różni się między platformami, ale funkcjonalność końcowa jest taka sama.
Dla instalacji Windows backendem bazodanowym jest Microsoft SQL Server lub IBM DB2. Dla nowych instalacji SQL Server Express sprawdza się jako punkt wyjścia dla małych środowisk, z jednym zastrzeżeniem: ma limit 10 GB na bazę danych. Wdrożenie BigFix z kilkuset endpointami osiąga ten sufit w ciągu roku. Średnie i duże wdrożenia powinny korzystać z SQL Server Standard lub Enterprise od pierwszego dnia, albo z IBM DB2, który BigFix też obsługuje. Odbudowa bazy BigFix, bo SQL Express wyczerpał miejsce, to doświadczenie, którego nikt nie chce. Kreator instalacji przeprowadza przez konfigurację bazy danych, generowanie certyfikatów i początkową konfigurację serwera.
Podczas instalacji utworzysz plik masthead, który służy jako punkt zaufania dla wszystkich agentów BigFix. Agenty używają tego pliku do weryfikacji, że komunikują się z prawidłowym serwerem. Zachowaj ten plik w bezpiecznym miejscu. Będziesz go potrzebować przy każdym wdrożeniu nowego agenta.
Po uruchomieniu serwera aktywuj site BigFix Inventory. Ten site zawiera fixlety (zautomatyzowane zadania), które umożliwiają skanowanie oprogramowania, zarządzanie katalogiem i zbieranie danych niezbędnych do działania ILMT. Bez aktywacji tego site'u BigFix będzie zarządzał endpointami, ale nie będzie zbierać danych inwentaryzacyjnych, których ILMT potrzebuje.
Krok 2: Wdrożenie agentów BigFix
Ten etap trwa najdłużej w niemal każdym wdrożeniu, które realizowaliśmy. Techniczna instalacja agenta BigFix na pojedynczej maszynie jest prosta. Wdrożenie go na każdym serwerze, na którym działa oprogramowanie IBM, w różnych systemach operacyjnych, segmentach sieci i jednostkach organizacyjnych, to już zupełnie inna historia.
Agenty BigFix są dostępne na popularne platformy korporacyjne: Windows Server, RHEL, SLES, Ubuntu, AIX i IBM i. Pokrycie Solaris i HP-UX istnieje w starszych wersjach BigFix, ale kurczy się. Solaris 10 został w szczególności wycofany z listy IBM Eligible Virtualization Technology, więc nawet jeśli agent działa, matematyka sub-capacity już nie. Jeśli uruchamiasz oprogramowanie IBM na jednej z tych platform, zweryfikuj aktualną macierz wsparcia, zanim założysz, że masz prawo do sub-capacity. Sam agent jest lekki, zwykle zużywa od 50 do 100 MB RAM przy minimalnym obciążeniu CPU. Działa jako usługa systemowa i przeżywa restarty automatycznie.
Do wdrożenia agentów na dużą skalę masz kilka opcji. BigFix Client Deploy Tool to własne narzędzie IBM do zdalnej instalacji agentów. Działa dobrze, gdy masz dane uwierzytelniające administratora do docelowych maszyn i łączność sieciową na porcie 52311. W środowiskach Windows sprawdza się wdrożenie przez zasady grupy (GPO). Zapakuj agent MSI do GPO i przypisz go do odpowiednich jednostek organizacyjnych. Jeśli Twoja organizacja używa SCCM lub innego narzędzia do dystrybucji oprogramowania, możesz wypchnąć pakiet agenta BigFix przez istniejącą infrastrukturę.
Na serwerach Linux i AIX powszechną metodą są instalacje skryptowe. Prosty skrypt oparty na SSH, który kopiuje pakiet agenta, instaluje go, konfiguruje adres serwera i uruchamia usługę, może wdrożyć agentów na dziesiątki serwerów w kilka minut. Dołącz plik masthead do pakietu wdrożeniowego, żeby agenty mogły uwierzytelnić się z serwerem BigFix przy pierwszym połączeniu.
I tu jest kluczowa kwestia, której nie możemy dostatecznie podkreślić: musisz wdrożyć agentów na każdym serwerze, na którym działa oprogramowanie IBM. Na każdym bez wyjątku. Dotyczy to serwerów produkcyjnych, deweloperskich, środowisk testowych, stagingowych, serwerów disaster recovery i każdej maszyny, na której ktoś mógł zainstalować produkt IBM. Jeśli serwer ma oprogramowanie IBM, ale nie ma agenta BigFix, ILMT nie wie, że ten serwer istnieje. Podczas audytu audytor IBM, który odkryje niemonitorowane serwery z oprogramowaniem IBM, potraktuje to jako lukę w zgodności. Widzieliśmy organizacje, które starannie pokryły środowisko produkcyjne, ale kompletnie zapomniały o laboratoriach deweloperskich i testowych, w których czasem działało więcej oprogramowania IBM niż na produkcji.
Po wdrożeniu agentów sprawdź, czy wszystkie raportują do serwera BigFix. Konsola BigFix pokazuje status agentów, w tym czas ostatniego raportu. Każdy agent, który nie raportuje od ponad 24 godzin, wymaga zbadania. Typowe przyczyny to blokady firewalla, problemy z rozwiązywaniem DNS, błędny adres serwera w konfiguracji agenta lub niedziałająca usługa agenta.
Potrzebujesz pomocy przy planowaniu wdrożenia ILMT?
Robiliśmy to setki razy w środowiskach każdej wielkości. Powiedz nam o swojej infrastrukturze, a pomożemy zaplanować odpowiednią architekturę. Bez zobowiązań.
Uzyskaj pomoc przy wdrożeniuKrok 3: Instalacja serwera ILMT
Gdy BigFix działa i agenty raportują, możesz przystąpić do instalacji serwera ILMT. ILMT pod brandem BigFix Inventory 10/11 działa na Linuksie, obecnie RHEL 8 i 9 oraz SLES 15 (RHEL 7 i SLES 12 wyszły poza mainstream support i nie powinieneś używać ich do nowych wdrożeń). To aplikacja webowa, do której po instalacji uzyskujesz dostęp przez przeglądarkę.
ILMT jest dostarczany z wbudowaną instancją DB2, która służy jako własny magazyn danych. To jest oddzielna baza od tej, której używa serwer BigFix. Wbudowane DB2 przechowuje dane konfiguracyjne ILMT, zaimportowane wyniki skanów i dane raportowe. Nie musisz osobno instalować ani konfigurować DB2. Instalator ILMT zajmuje się tym automatycznie. Potrzebny będzie też Java Development Kit (JDK) na serwerze ILMT. Instalator IBM zawiera dołączony JDK, więc w większości przypadków to również jest obsługiwane automatycznie.
Sama instalacja przebiega przez kreator. Uruchamiasz instalator, akceptujesz umowę licencyjną, wybierasz katalog instalacyjny, konfigurujesz połączenie z bazą danych serwera BigFix, tworzysz konto administratora ILMT i pozwalasz kreatorowi zakończyć pracę. Sam kreator zajmuje mniej niż godzinę. Tym, co ludzie niedoceniają, jest wszystko wokół: przygotowanie VM do specyfikacji, otwarcie reguł firewalla do bazy BigFix, przygotowanie wymagań systemu operacyjnego, skonfigurowanie backupu, konfiguracja początkowego importu katalogu, podpięcie VM Managerów. Dla dobrze zaplanowanego wdrożenia zaplanuj od pół dnia do całego dnia od przekazania pustej VM do momentu, kiedy patrzysz na działającego ILMT. Znacznie szybsze wdrożenie zwykle oznacza, że coś pominięto.
Jeśli potrzeba biznesowa wymaga odporności, zapoznaj się z wysoką dostępnością i DR dla ILMT przed projektowaniem warstwy serwerowej. ILMT działa jako pojedyncza instancja, a wspierane wzorce (warm standby, HA na warstwie wirtualizacji) decydują o tym, co tu przydzielisz.
Częsty błąd, który widzimy w średnich i dużych środowiskach: instalowanie serwera ILMT na tej samej maszynie co serwer BigFix. To działa przy małych konfiguracjach poniżej 100 endpointów. Powyżej tej granicy obie aplikacje rywalizują o CPU, pamięć i I/O dyskowe. BigFix nieustannie odbiera dane od agentów i zapisuje je w bazie. ILMT okresowo uruchamia duże importy danych, które pochłaniają znaczne zasoby. Uruchamianie obu na jednym serwerze prowadzi do wolnego generowania raportów, timeoutów importu i ogólnej niestabilności. Daj im osobne maszyny.
Po instalacji zaloguj się do interfejsu webowego ILMT i sprawdź połączenie z serwerem BigFix. ILMT powinien pokazywać całkowitą liczbę połączonych endpointów i ich status raportowania. Jeśli liczba endpointów nie zgadza się z tym, co widzisz w konsoli BigFix, sprawdź ustawienia połączenia z bazą danych i reguły firewalla między serwerem ILMT a bazą danych BigFix.
Krok 4: Konfiguracja katalogu oprogramowania i skanów
ILMT identyfikuje oprogramowanie IBM przez dopasowywanie plików, wpisów rejestru i innych znaczników na endpointach do katalogu oprogramowania utrzymywanego przez IBM. Ten katalog zawiera tysiące sygnatur dla produktów IBM we wszystkich wersjach i na wszystkich platformach. Bez aktualnego katalogu ILMT nie jest w stanie prawidłowo zidentyfikować, co jest zainstalowane w Twoim środowisku.
Pierwsze zadanie po instalacji to import najnowszego katalogu oprogramowania. Katalog możesz pobrać z IBM Fix Central lub przez site BigFix Inventory. Importujesz go do ILMT przez interfejs webowy. IBM aktualizuje katalog mniej więcej co kwartał, czasem częściej. Ustaw sobie przypomnienie o regularnym sprawdzaniu aktualizacji katalogu. Nieaktualny katalog oznacza, że ILMT może nie rozpoznać nowo wydanych produktów IBM lub nieprawidłowo zidentyfikować zaktualizowane wersje istniejących.
Następnie skonfiguruj harmonogram skanowania. ILMT opiera się na dwóch typach skanów uruchamianych przez agentów BigFix. Skan inwentaryzacji oprogramowania identyfikuje, jakie oprogramowanie jest zainstalowane na każdym endpoincie. Skan wydajności zbiera dane o konfiguracji sprzętowej i wirtualizacyjnej. Oba skany muszą być uruchamiane regularnie. Zalecamy planowanie skanu inwentaryzacji oprogramowania co najmniej raz w tygodniu, a skanu wydajności codziennie. Same skany są lekkie i zwykle kończą się w ciągu kilku minut na endpoincie.
Trzecia krytyczna konfiguracja to połączenie VM Managera. Tu ILMT pobiera dane o wirtualizacji. Dla środowisk VMware musisz skonfigurować połączenie z serwerem vCenter. ILMT używa go do mapowania maszyn wirtualnych na hosty fizyczne, co jest niezbędne do obliczania wartości PVU w trybie sub-capacity. Dla środowisk IBM PowerVM ILMT łączy się z Hardware Management Console (HMC). Dla Microsoft Hyper-V agent BigFix na hoście Hyper-V zbiera niezbędne dane automatycznie, ale nadal musisz upewnić się, że agent jest wdrożony na każdym hoście Hyper-V.
Prawidłowa konfiguracja VM Managera jest kluczowa. Jeśli ILMT nie może określić, na którym hoście fizycznym działa maszyna wirtualna, nie jest w stanie obliczyć fizycznej pojemności tego hosta. Bez tej informacji ILMT przyjmuje kalkulacje pełnej pojemności dla dotkniętych maszyn wirtualnych. Widzieliśmy organizacje, które traciły prawo do sub-capacity dla całych klastrów VMware, bo połączenie z vCenter było zerwane i nikt tego nie zauważył przez miesiące. Przetestuj połączenie VM Managera po konfiguracji i zweryfikuj, że ILMT pokazuje prawidłowe mapowania hostów na maszyny wirtualne w widoku topologii.
Krok 5: Generowanie pierwszych raportów
Gdy początkowy import danych się zakończy (daj mu co najmniej 24 do 48 godzin na uruchomienie pierwszych skanów przez agentów i import danych przez ILMT), możesz wygenerować pierwsze raporty. Zacznij od Audit Snapshot, bo to jest raport, o który IBM poprosi w przypadku audytu.
Uruchom Audit Snapshot i przejrzyj go dokładnie. Twój pierwszy raport prawie na pewno będzie zawierać problemy. To jest zupełnie normalne. Oto, czego możesz się spodziewać i co zrobić z każdym problemem.
Brakujące agenty. Niektóre serwery, na których powinny działać agenty BigFix, nie pojawią się w raporcie. Porównaj listę endpointów ILMT ze swoim inwentarzem serwerów. Każdy serwer z oprogramowaniem IBM, który nie pojawia się w ILMT, to luka, którą trzeba zamknąć. Wróć do Kroku 2 i wdróż agentów na tych maszynach.
Nieznane lub nieskategoryzowane produkty. ILMT może wykryć instalacje oprogramowania, których nie potrafi przypisać do konkretnego produktu IBM. Zwykle oznacza to, że katalog oprogramowania nie ma sygnatury dla tej konkretnej wersji lub zainstalowane pliki nie pasują do żadnego znanego wzorca. Sprawdź, czy dostępna jest nowsza wersja katalogu. Jeśli oprogramowanie rzeczywiście nie jest produktem IBM, możesz wykluczyć je z raportów.
Wyższe wartości PVU niż oczekiwano. Początkowe liczby PVU mogą być wyższe, niż zakładałeś. Często dzieje się tak dlatego, że ILMT liczy produkty, o których instalacji nie wiedziałeś, lub dlatego, że konfiguracja VM Managera jest niekompletna i niektóre maszyny wirtualne są liczone przy pełnej pojemności. Zbadaj każdy przypadek indywidualnie.
Luki w topologii wirtualizacji. Jeśli ILMT pokazuje maszyny wirtualne bez znanego hosta, połączenie VM Managera wymaga uwagi. Te „osierocone" maszyny wirtualne będą liczone w raporcie przy pełnej pojemności. Zweryfikuj połączenia z vCenter, HMC lub hostami Hyper-V.
Nie panikuj z powodu początkowych wyników. Pierwszy raport to narzędzie diagnostyczne, a nie werdykt zgodności. Napraw znalezione problemy, poczekaj na kolejny cykl importu danych i wygeneruj kolejny raport. Każda iteracja powinna wyglądać lepiej niż poprzednia. Większość środowisk osiąga stabilny, dokładny stan w ciągu dwóch do czterech tygodni aktywnego dostrajania.
Problemy z pierwszymi raportami ILMT?
Interpretacja danych ILMT po świeżej instalacji to jeden z najczęstszych powodów, dla których organizacje się z nami kontaktują. Możemy przejrzeć Twoje początkowe raporty i pomóc dojść do czystego stanu bazowego.
Poproś o przegląd raportówNajczęstsze błędy instalacyjne
Po latach wdrażania i przejmowania środowisk ILMT widzieliśmy te same błędy wielokrotnie. Uniknięcie ich zaoszczędzi Ci sporo czasu i frustracji.
Użycie niewłaściwej wersji DB2
ILMT wymaga konkretnych wersji DB2. Instalacja niewspieranej wersji prowadzi do niejasnych błędów podczas konfiguracji lub, co gorsza, do cichego uszkodzenia danych, które wychodzi na jaw dopiero po miesiącach. Zawsze sprawdź dokument wymagań systemowych ILMT pod kątem dokładnej macierzy wersji DB2, zanim zaczniesz. Jeśli korzystasz z wbudowanego DB2 dostarczanego z instalatorem ILMT, ten problem jest rozwiązany automatycznie. Kłopoty pojawiają się, gdy organizacje próbują użyć istniejącej instancji DB2, która przypadkiem jest w innej wersji.
Niewystarczająca przestrzeń dyskowa na dane skanów
Dane ze skanów kumulują się w czasie. Każdy skan inwentaryzacji oprogramowania i skan wydajności generuje dane, które BigFix przechowuje, a ILMT importuje. Dla średniego środowiska z cotygodniowymi skanami należy liczyć się ze wzrostem bazy danych BigFix o kilka gigabajtów miesięcznie. Baza danych ILMT również rośnie, szczególnie jeśli zachowujesz historyczne dane za długie okresy raportowania. Zalecamy przydzielenie co najmniej podwojonej początkowej pojemności dyskowej i ustawienie alertów monitoringowych przy 70% wykorzystania. Brak wolnego miejsca na serwerze BigFix lub ILMT to jeden z najszybszych sposobów na utworzenie luk w danych zgodności.
Brak przekaźników w zdalnych lokalizacjach
Jeśli masz serwery w wielu centrach danych lub strefach sieciowych połączonych łączami WAN, potrzebujesz przekaźników BigFix. Bez nich każdy agent komunikuje się bezpośrednio z centralnym serwerem BigFix. To działa dobrze w sieci lokalnej. Przez połączenie WAN prowadzi do wolnego raportowania agentów, nieudanych przesyłanych skanów i znacznego zużycia pasma. Pojedynczy przekaźnik w każdej zdalnej lokalizacji rozwiązuje wszystkie te problemy. Zainstaluj przekaźnik na serwerze Windows lub Linux w zdalnej lokalizacji, skieruj lokalne agenty na niego, a przekaźnik obsłuży całą komunikację z serwerem centralnym.
Brak konfiguracji VM Managera
Widzimy to w niemal połowie przejmowanych środowisk. Serwer BigFix działa, agenty są wdrożone, ILMT generuje raporty, ale połączenie VM Managera nigdy nie zostało skonfigurowane lub w pewnym momencie przestało działać. Skutek: każda maszyna wirtualna w dotkniętym klastrze wirtualizacji jest wykazywana z pełną pojemnością PVU. Administrator ILMT może nawet tego nie zauważyć, bo raporty wyglądają na „kompletne". Po prostu pokazują znacznie wyższe zużycie PVU, niż jest to konieczne. Zawsze weryfikuj połączenie VM Managera jako część kontroli po instalacji i monitoruj je na bieżąco.
Pominięcie środowisk deweloperskich i testowych
Serwery deweloperskie i testowe są równie istotne dla zgodności licencyjnej IBM jak serwery produkcyjne. Jeśli deweloper zainstalował DB2 lub WebSphere na testowej maszynie wirtualnej, ta instalacja zużywa jednostki PVU. Warunki licencyjne IBM nie rozróżniają między wykorzystaniem produkcyjnym a nieprodukcyjnym, chyba że posiadasz specyficzną licencję nieprodukcyjną. Wdróż agentów BigFix na każdym serwerze w każdym środowisku. Widzieliśmy ustalenia audytowe, gdzie większość luki zgodności pochodziła z niemonitorowanych serwerów deweloperskich i testowych, a nie z produkcji.
Założenie, że agenty BigFix pokryją wszystko
Niektóre maszyny nie mogą hostować agenta BigFix. LPAR-y IBM i, zablokowane appliance, starsze platformy, które straciły wsparcie agenta, VM-ki w odseparowanych sieciach, gdzie nie jest dozwolona żadna komunikacja przychodząca z BigFix. Widzieliśmy organizacje, które całkowicie pomijały te maszyny w ILMT, bo „ILMT ich nie widzi". To luka zgodności czekająca, aż stanie się ustaleniem audytowym.
Właściwą odpowiedzią jest skaner offline. ILMT zawiera pakiet skanera, który wdrażasz lokalnie na tych maszynach (przez SSH, skryptową instalację, albo dowolny mechanizm pasujący do platformy). Skaner generuje podpisany plik z wynikami. Przenosisz plik na serwer ILMT według harmonogramu, a ILMT importuje go obok danych BigFix. To bardziej ręczne niż standardowy przepływ i wymaga dyscypliny operacyjnej, żeby utrzymać aktualność, ale utrzymuje pełny obraz zgodności. Zaplanuj to podczas wdrożenia, zamiast odkrywać podczas audytu.