Pliki konfiguracyjne i logi Windows Autopilot: Gdzie system przechowuje profile wdrożeniowe

Zastanawiałeś się kiedyś, gdzie Windows Autopilot, ten sprytny mechanizm do automatycznego wdrażania i konfigurowania nowych komputerów, przechowuje swoje sekrety? No bo przecież gdzieś muszą być te profile wdrożeniowe, dane o rejestracji urządzenia i – co najważniejsze dla nas, administratorów – logi, które pomagają diagnozować wszelkie wpadki podczas Provisioningu. Odpowiedź nie jest taka prosta, jakby się wydawało, bo Autopilot to nie jeden zgrabny folder, tylko cały ekosystem rozproszonych danych i plików. Ale spokojnie, rozłożymy to na czynniki pierwsze.

Co to jest ten cały Autopilot i gdzie przechowuje swoje dane?

Windows Autopilot to, mówiąc wprost, taki wirtualny „asystent” do zero-touch deploymentu urządzeń. Zamiast ręcznie instalować system, sterowniki i aplikacje, Autopilot pozwala skonfigurować wszystko z chmury (najczęściej z Microsoft Intune i Azure AD) i dostarczyć użytkownikowi gotowe do pracy urządzenie. Ale gdzie te wszystkie instrukcje i informacje są fizycznie na komputerze?

Tak jak wspomniałem, to nie jeden folder, a raczej zestaw miejsc, w których system operacyjny gromadzi dane związane z Autopilotem. Kluczowe obszary, które warto znać to:

• Rejestr systemowy: To serce wielu ustawień Windows, w tym również tych związanych z Autopilotem. Znajdziesz tu ślady rejestracji urządzenia, status wdrożenia i inne kluczowe wartości, które system sprawdza podczas OOBE (Out-Of-Box Experience). Bez konkretnego klucza ciężko to wskazać, ale ogólnie szukaj w HKLM (HKEY_LOCAL_MACHINE).
• Foldery z logami diagnostycznymi: Tutaj robi się ciekawie dla tych, którzy walczą z błędami. Głównym miejscem, gdzie system zbiera logi z procesu Provisioningu, jest ścieżka: `C:\Windows\Provisioning\Diagnostics\Audits\`. To tutaj znajdziesz pliki XML i inne dane, które szczegółowo opisują, co poszło nie tak.
• Katalog danych aplikacji: Czasem, choć rzadko, jakieś tymczasowe pliki konfiguracyjne czy skrypty mogą lądować w okolicach `C:\ProgramData\Microsoft\Windows\Autopilot\` lub w innych folderach związanych z zarządzaniem urządzeniami (MDM), ale to bardziej wyjątki niż reguła dla głównych danych Autopilota.
• Dziennik zdarzeń (Event Viewer): To jest absolutna podstawa! Jeśli szukasz diagnostyki, to właśnie tam. Konkretnie, musisz zerknąć w „Podgląd zdarzeń” (czyli Event Viewer) i tam, w sekcji `Dzienniki aplikacji i usług\Microsoft\Windows\`, znajdziesz specjalne kanały dla Autopilota. Szukaj zwłaszcza:
• `Microsoft-Windows-Autopilot/Admin`
• `Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin`

To tam zobaczysz szczegółowe informacje o statusie wdrożenia, błędach i kolejnych krokach, jakie podejmuje Autopilot. A wiesz, co jest w tym wszystkim najfajniejsze? Wszystko to dzieje się jeszcze zanim użytkownik tak naprawdę zacznie korzystać z komputera!

Do czego to służy i co dokładnie zawiera?

Te rozproszone dane służą przede wszystkim do monitorowania i diagnostyki procesu Autopilot. Sam profil wdrożeniowy (czyli zbiór zasad, aplikacji do instalacji, ustawień konfiguracyjnych) jest przechowywany w chmurze (Intune), a urządzenie pobiera go podczas fazy OOBE. Lokalne foldery i rejestr zawierają przede wszystkim:

• Logi: Oczywiście, cała masa logów. Opisują one każdy etap procesu wdrożenia: połączenie z siecią, rejestrację urządzenia w Azure AD, pobranie profilu, status instalacji aplikacji, zastosowanie polityk. Bez tych logów, diagnostyka to byłaby wróżba z fusów. (Serio, bez nich jesteś jak ślepiec we mgle.)
• Status urządzenia: W rejestrze znajdziesz informacje o tym, czy urządzenie zostało zarejestrowane, czy ma przypisany profil Autopilot i jaki jest jego obecny status w procesie Provisioningu.
• Dane diagnostyczne: Pliki XML w `C:\Windows\Provisioning\Diagnostics\Audits\` mogą zawierać zrzuty stanu, które pomagają zidentyfikować konkretne problemy z Provisioningiem.

Czy można to usunąć/przenieść i co się stanie?

Usuwanie czy przenoszenie tych folderów „na własną rękę” to bardzo zły pomysł. Dlaczego? Bo to są kluczowe dane systemowe.

• Usunięcie folderów logów (np. `C:\Windows\Provisioning\Diagnostics\Audits\`): Same logi możesz usunąć – nie wpłynie to na działanie Autopilota, ale stracisz bezpowrotnie historię diagnostyczną. Jeśli masz problem, to strzelisz sobie w kolano, bo nie będziesz miał jak go zdiagnozować. Więc tak, można, ale po co?
• Modyfikacja/usunięcie wpisów w rejestrze: To już jest jazda bez trzymanki. Usunięcie kluczowych wpisów Autopilota z rejestru może sprawić, że urządzenie nie zostanie poprawnie zidentyfikowane jako przeznaczone do Autopilota, a cały proces wdrożenia legnie w gruzach. Skutek? Konieczność ręcznego resetu, a nawet reinstalacji systemu.
• Przeniesienie: Zapomnij. To są ścieżki systemowe, na sztywno zakodowane. Przeniesienie czegokolwiek z `C:\Windows\` czy rejestru to gwarancja problemów.

W zasadzie, jeśli chcesz „usunąć” Autopilota z urządzenia, to nie robisz tego poprzez kasowanie plików, ale poprzez resetowanie urządzenia do ustawień fabrycznych (np. funkcja „Resetuj ten komputer” w Windows, która może zachować lub usunąć dane użytkownika) albo, w przypadku poważnych problemów, reinstalację systemu operacyjnego. Po resecie Autopilot znowu spróbuje „załapać” i skonfigurować urządzenie od nowa, o ile nadal jest przypisane w Intune.

Typowe problemy z tym folderem (a raczej z Autopilotem)

Najczęściej problemy nie wynikają z uszkodzenia samych folderów, ale z tego, co w nich się znajduje – czyli z błędów w logach.

• Urządzenie nie jest rozpoznawane przez Autopilota: Często problem z brakiem przypisanego profilu w Intune, błędnym haszem urządzenia albo problemami z łącznością z Azure AD. W logach zobaczysz, że urządzenie nie pobiera profilu.
• Provisioning zatrzymuje się w połowie: To może być wina skryptu, który się nie wykonał, aplikacji, która nie chce się zainstalować, albo sterownika, który robi bałagan. Logi z Event Viewera i z `C:\Windows\Provisioning\` pokażą konkretny moment i błąd.
• „Something went wrong” (Coś poszło nie tak) – generyczny błąd: To ulubieniec każdego administratora, bo jest tak ogólny, że nic nie mówi. Tutaj dopiero musisz sięgnąć po logi i szukać konkretnych komunikatów o błędach.
• Problemy z siecią: Autopilot mocno polega na łączności internetowej. Jeśli DNS szwankuje, firewall blokuje porty, czy VPN nie działa, to Autopilot po prostu się zatrzyma. Logi mogą wskazać na problemy z połączeniem z usługami Microsoft.

Kiedy warto go wyczyścić?

Samo „czyszczenie” folderów Autopilota, tak jak np. czyszczenie folderu `Temp`, ma sens tylko w kontekście logów.

• Po udanej diagnostyce: Jeśli rozwiązałeś problem i nie potrzebujesz już starych logów, możesz spokojnie usunąć pliki z `C:\Windows\Provisioning\Diagnostics\Audits\`. Zwolni to trochę miejsca, choć zazwyczaj są to drobne ilości.
• Gdy logi zajmują zbyt dużo miejsca: To zdarza się rzadko, ale jeśli masz urządzenie, które przez długi czas miało problemy z Provisioningiem, logi mogą się nazbierać. Wtedy ich usunięcie jest uzasadnione.
• Przy resecie urządzenia: Kiedy wykonujesz reset urządzenia, większość tych danych i tak zostanie usunięta lub zresetowana przez system, więc ręczne czyszczenie nie jest konieczne.

Pamiętaj, że czyszczenie to jedno, a rozwiązywanie problemów to drugie. Zanim cokolwiek wyczyścisz, upewnij się, że nie potrzebujesz tych danych do analizy. A może zechcesz się pobawić i wymusić jeszcze raz OOBE na urządzeniu, żeby zobaczyć, jak Autopilot działa od podszewki?

Najczęstsze pytania

Czy Autopilot tworzy kopie zapasowe konfiguracji na urządzeniu?

Nie, Autopilot nie tworzy lokalnych kopii zapasowych konfiguracji. Głównym źródłem prawdy dla profilu wdrożeniowego jest chmura (np. Intune), a urządzenie pobiera go na żądanie.

Gdzie znajdę pliki z haszem urządzenia, który muszę zaimportować do Intune?

Plik CSV z haszem urządzenia generujesz za pomocą skryptu PowerShell (`Get-WindowsAutopilotInfo.ps1`), a nie znajdujesz go w folderze systemowym Autopilota po prostu leżącego i czekającego.