GetHardware

Interaktywny skrypt Windows PowerShell 5.1 odczytujący informacje o sprzęcie i zapisujący je w plikach PHP przeznaczonych do importu do istniejącej bazy.

Aktualna wersja skryptu: v1.0.6. Numer wersji jest wyświetlany jako pierwszy komunikat po uruchomieniu. Nazwa pliku pozostaje stała niezależnie od wersji.

Wymagania

• Windows PowerShell 5.1;
• dostęp do poleceń CIM/WMI;
• możliwość odczytu urządzeń PnP;
• pliki Get-HardwareInventory.ps1 i hardware-models.json w tym samym katalogu.

Uruchomienie

Na inwentaryzowanym laptopie z czystym systemem otwórz Windows PowerShell i wklej poniższe polecenie w jednej linii. Nie wpisuj słowa PowerShell przed komendą. W oknie poświadczeń dopisz nazwę użytkownika po prefiksie SOFTSYSTEM\ i podaj hasło.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force; if ((Get-ExecutionPolicy) -ne 'Bypass') { throw 'Polityka wykonywania nadal nie ma wartości Bypass.' }; $Credential=Get-Credential -Message 'Podaj konto domenowe' -UserName 'SOFTSYSTEM\'; New-PSDrive -Name GH -PSProvider FileSystem -Root '\\ntshare\helpdesk\scripts\GetHardware' -Credential $Credential -ErrorAction Stop | Out-Null; try { & 'GH:\Get-HardwareInventory.ps1' } finally { Remove-PSDrive -Name GH -Force -ErrorAction SilentlyContinue }

Polecenie ustawia Bypass wyłącznie dla bieżącego procesu PowerShell i sprawdza, czy jest to skuteczna polityka; w razie niepowodzenia zatrzymuje się przed uruchomieniem skryptu. Nie zmienia trwale polityki komputera. Hasło jest podawane w bezpiecznym oknie i nie należy wpisywać go bezpośrednio w poleceniu. Skrypt oraz pliki bazy są odczytywane z udziału sieciowego, wyniki trafiają do \\ntshare\helpdesk\scripts\GetHardware\output, a tymczasowy dysk GH: jest automatycznie odłączany po zakończeniu pracy.

Jeśli MachinePolicy albo UserPolicy widoczne w Get-ExecutionPolicy -List są wymuszone administracyjnie, ustawienie dla zakresu Process może ich nie zastąpić. W takim przypadku potrzebny jest podpisany skrypt albo zmiana polityki przez administratora.

Skrypt nie przyjmuje nazwy spisu jako parametru. Przy pierwszym uruchomieniu prosi o jej wpisanie. Przy kolejnych uruchomieniach wyświetla istniejące spisy i opcję utworzenia nowego.

Przebieg

1. Potwierdzenie odłączenia dodatkowych monitorów, sesji pulpitu zdalnego, stacji dokujących i zewnętrznych urządzeń USB.
2. Odczyt modelu, Service Tagu, procesora, płyty głównej i pozostałych podzespołów.
3. Dla urządzenia Dell wyświetlenie adresu strony wsparcia bez automatycznego otwierania przeglądarki.
4. Sprawdzenie modelu w hardware-models.json.
5. Wybór istniejącego spisu albo utworzenie nowego.
6. Odczyt wspólnego pola bought z istniejącego spisu albo pytanie o nie dla nowego spisu.
7. Przegląd, edycja, dodawanie lub usuwanie wykrytych podzespołów.
8. Wprowadzenie gwarancji, ceny, etykiety Windows, pomieszczenia i notatki.
9. Wyświetlenie podsumowania i zapis po zatwierdzeniu.

W podsumowaniu pusta notatka jest pokazywana jawnie jako [pusta], aby łatwiej wychwycić brak danych przed zapisem.

Wykryty dysk USB jest pokazywany wraz z opisem, połączeniem i dostępnymi danymi diagnostycznymi, bez numeru seryjnego. Skrypt pyta, czy dodać go do listy sprzętu; po odmowie pomija tylko ten dysk.

Numery seryjne dysków i RAM-u nie są przypisywane automatycznie, ponieważ odczyt sprzętowy nie jest wystarczająco wiarygodny. Pole sn pozostaje puste i jest pomijane w PHP; numer można wpisać ręcznie w edytorze podzespołów.

Nieznany model uruchamia interaktywny kreator wpisu. Skrypt automatycznie uzupełnia nazwę modelu, awaryjny opis płyty, wykrytą konfigurację pamięci i typ urządzenia. Użytkownik podaje zweryfikowaną maksymalną pojemność RAM, powerMaxW, powerW oraz other, a wpis trafia do JSON-u dopiero po pokazaniu podsumowania i zatwierdzeniu. Jeśli bazy nie można zapisać lub jest niepoprawna, nadal można poprawić ją ręcznie i wczytać ponownie bez rozpoczynania pracy od początku.

Identyfikacja modelu

Skrypt pobiera producenta, Model, SystemFamily i SystemSKUNumber z Win32_ComputerSystem. Dane z Win32_ComputerSystemProduct oraz klucza HKLM:\HARDWARE\DESCRIPTION\System\BIOS są źródłami awaryjnymi dla pustych lub zastępczych wartości.

Nazwa używana do dokładnego wyszukania wpisu w hardware-models.json oraz później w polu PHP model jest budowana z SystemFamily i Model. Jeśli Model zawiera już nazwę rodziny, nie jest ona powtarzana: Latitude i Latitude 5421 dają Latitude 5421. Gdy wartości są różne, kod modelu jest dodawany w nawiasie: Yoga Slim 7 15ILL9 i 83HM dają Yoga Slim 7 15ILL9 (83HM).

Istniejący wpis w JSON-ie jest traktowany jako poprawny i musi dokładnie odpowiadać zbudowanej nazwie. Przy braku wpisu skrypt pokazuje producenta, rodzinę, model systemowy, SKU oraz proponowaną nazwę. Użytkownik musi zaakceptować propozycję, a następnie kompletny nowy wpis JSON przed jego zapisaniem. Struktura hardware-models.json nie została rozszerzona o dodatkowe pola identyfikacyjne.

Pliki wynikowe

Wyniki trafiają zawsze do katalogu output obok uruchomionego skryptu:

output\
└── BI_ONE\
    ├── .gethardware.lock
    ├── 13QJ7D3.php
    ├── 8ABC123.php
    └── BI_ONE.php

• plik nazwany Service Tagiem zawiera jedno urządzenie;
• plik nazwany tak jak spis zawiera wszystkie urządzenia w kolejności ich dodania;
• .gethardware.lock chroni spis przed jednoczesnym zapisem przez dwa uruchomienia skryptu;
• pliki PHP są kodowane jako UTF-8 bez BOM.

W pliku zbiorczym rekordy są otoczone komentarzami GET-HARDWARE-BEGIN i GET-HARDWARE-END. Pozwala to zastąpić istniejący Service Tag bez zmiany jego pozycji. Komentarze są prawidłowymi komentarzami PHP i nie wpływają na import.

Ręczna baza modeli

hardware-models.json jest listą obiektów:

{
  "model": "Latitude 7420",
  "baseboardFallback": "Latitude 7420",
  "memorySpec": "DDR3L 1600MHz x2, max8GB",
  "powerMaxW": 65,
  "powerW": 45,
  "other": "no Eth; zasilacz USB-C",
  "deviceType": "laptop"
}

Wszystkie pola są wymagane, a nazwa modelu musi być unikalna. baseboardFallback jest proponowany użytkownikowi tylko wtedy, gdy Win32_BaseBoard nie zwróci modelu płyty. memorySpec jest dołączany do wykrytej lub zatwierdzonej płyty w nawiasie.

Jeżeli ten sam model występuje z różnymi generacjami pamięci, pozostaw jeden wpis modelu i dodaj opcjonalne memoryVariants. Poniższy fragment należy umieścić wewnątrz obiektu modelu. Dotychczasowe wymagane pole memorySpec pozostaje w obiekcie, ale gdy istnieje memoryVariants, konfiguracja pamięci jest wybierana z tej listy. memoryType musi odpowiadać typowi w memorySpec; każda konfiguracja musi zawierać zweryfikowane maksimum lub oznaczenie soldered.

"memoryVariants": [
  {
    "memoryType": "DDR4",
    "memorySpec": "DDR4 3200MHz x2, max64GB"
  },
  {
    "memoryType": "DDR5",
    "memorySpec": "DDR5 4800MHz x2, max64GB"
  }
]

Jeśli wykryty typ RAM-u pasuje dokładnie do jednego wariantu, skrypt wybiera go automatycznie. Przy braku pewnego dopasowania pokazuje warianty do wyboru. Gdy wykryje nową generację, użytkownik może dopisać ją do memoryVariants; dotychczasowy memorySpec pozostaje wtedy zachowany jako pierwszy wariant. Skrypt wstępnie uzupełnia wykrytą konfigurację i znany limit pojemności w polu edycji. Użytkownik może ją poprawić albo zatwierdzić klawiszem Enter. Można też użyć konfiguracji tylko dla bieżącego komputera, bez zmiany wspólnego JSON-u.

Skrypt automatycznie buduje propozycję memorySpec z danych SMBIOS. Jeżeli jest ona zgodna z JSON-em, nie zadaje dodatkowych pytań. Przy różnicy generacji użytkownik może zapisać wykrytą konfigurację jako nowy wariant, zachować wartość z bazy, użyć jej tylko dla bieżącego komputera albo wpisać własną. Nowy wariant trafia do JSON-u tylko po jednoznacznym wyborze użytkownika i jest zapisywany przez zweryfikowany plik tymczasowy.

Odczyt zainstalowanych modułów RAM jest niezależny od ustalania konfiguracji pamięci obsługiwanej przez płytę główną. Jeśli moduły zostały wykryte, ale nie udało się ustalić np. liczby gniazd dla memorySpec, skrypt wyraźnie informuje, że problem dotyczy tylko opisu pola mainb. Dopiero brak wpisów zainstalowanej pamięci powoduje ostrzeżenie o konieczności ręcznego dodania RAM-u w edytorze podzespołów.

Przy dodawaniu nieznanego modelu baseboardFallback otrzymuje nazwę komputera, a deviceType jest pobierany z jednoznacznego wyniku Win32_SystemEnclosure.ChassisTypes. Jeśli typu nie można ustalić, skrypt prosi o jego wybór. Maksymalna pojemność w memorySpec zawsze wymaga ręcznego potwierdzenia na podstawie dokumentacji producenta; wartość MaxCapacity/MaxCapacityEx z SMBIOS nie jest używana jako limit konkretnego modelu.

Moduły wymienne są zapisywane osobno jako 16GB 3200MHz DDR4, z conn'=>'on board'. Rekordy pamięci lutowanej są grupowane w jeden wpis z conn'=>'soldered'. Automatycznie wykryte moduły mają puste sn, niezależnie od numeru zwróconego przez SMBIOS.

Walidacja danych ręcznych

W formularzach tekst w nawiasach kwadratowych, np. [A216], jest rzeczywistą wartością domyślną zatwierdzaną klawiszem Enter. Tekst po np. jest wyłącznie przykładem. Pola, które mogą pozostać puste, są oznaczone jako opcjonalne i nie pokazują pustych nawiasów [].

• bought: YYYY-MM-DD, wspólne dla całego spisu;
• warr: YYYY-MM-DD+N, np. 2021-05-20+3;
• cenan: kwota PLN z dwiema cyframi po przecinku, np. 1414,08;
• label: interaktywny wybór W10P, W11P albo wpisanie dowolnej niepustej etykiety;
• room: domyślnie A216;
• note: opcjonalny numer SCC, wybór REFURBISHED (T/N) i opcjonalny dodatkowy tekst; gotowa notatka jest wyświetlana do akceptacji lub poprawy i nie kończy się średnikiem.

Testy

Testy nie odczytują prawdziwego sprzętu. Sprawdzają bazę modeli, walidację podstawowych danych, generowanie PHP, kolejność rekordów, zastępowanie rekordu i kodowanie bez BOM:

.\tests\Test-GetHardwareInventory.ps1

Automatyczny odczyt sprzętu należy sprawdzić na docelowym laptopie. Dane zwracane przez WMI, szczególnie pamięć karty graficznej, rodzaj osadzenia RAM i powiązanie rozdzielczości z ekranem EDID, mogą wymagać ręcznej korekty w interaktywnym przeglądzie.

Publikacja

Skrypt Deploy.ps1 publikuje pliki produkcyjne do \\ntshare\helpdesk\scripts\GetHardware:

.\Deploy.ps1

Jeżeli udział wymaga innych poświadczeń niż bieżąca sesja:

$Credential = Get-Credential
.\Deploy.ps1 -Credential $Credential

Przed publikacją skrypt pobiera hardware-models.json z udziału do lokalnego repozytorium i sprawdza poprawność bazy. Produkcyjna baza nie jest kopiowana w przeciwną stronę ani usuwana, ponieważ uruchomienia inwentaryzacji dopisują do niej nowe modele. Jeżeli lokalna baza była inna, jej kopia bezpieczeństwa trafia do ignorowanego katalogu .deploy-backup.

Publikowane są wyłącznie Get-HardwareInventory.ps1, README.md i CHANGELOG.md. Katalogi .git, .codex, tests, output, pliki robocze oraz sam skrypt wdrożeniowy nie trafiają na udział. Publikacja nie usuwa innych plików z katalogu docelowego. Przewidywane operacje można sprawdzić bez zapisu poleceniem .\Deploy.ps1 -WhatIf.