Windows Autopilot Hybrid Entra ID Join: dlaczego przestaje działać i jak to naprawić krok po kroku

TL;DR: Autopilot w trybie Hybrid Entra ID Join to jeden z najbardziej kapryśnych elementów środowisk M365. Artykuł opisuje główne przyczyny awarii — od przestarzałego ODJ Connectora (wersje poniżej 6.2501.2000.5 są zdeprecjonowane) przez błędy uprawnień do OU, po enigmatyczne kody 0x80070774 i 0x80004005. Znajdziesz tu konkretne kroki diagnostyczne z lokalizacjami logów, gotowe polecenia PowerShell i opis pięciu pułapek, w które wpadają nawet doświadczeni administratorzy.

Problem

Wdrażasz nowy laptop przez Autopilot. Profil wdrożeniowy pobiera się poprawnie, użytkownik wpisuje dane korporacyjne, a potem — ekran błędu: "Something went wrong. Confirm you are using the correct sign-in information and that your organisation uses this feature." Albo scenariusz jeszcze trudniejszy do zdiagnozowania: urządzenie kończy rejestrację w Intune jako obiekt Azure AD, ale nigdy nie dołącza do lokalnej domeny. Intune widzi urządzenie jako zgodne, a IT nie może go znaleźć w Active Directory.

Tak wygląda klasyczna awaria Autopilot Hybrid Entra ID Join (dawniej Hybrid Azure AD Join). W grudniu 2025 roku problem dotknął jednocześnie dziesiątki organizacji — Microsoft zmienił architekturę endpointów Azure Front Door, a stary ODJ Connector przestał odbierać żądania. Wątek na Microsoft Tech Community zebrał 18 odpowiedzi w ciągu kilku tygodni od wielu firm w różnych krajach. Okazało się, że ich proces onboardingu był skonfigurowany prawidłowo — ale opierał się na komponencie, który przestał działać bez żadnego ostrzeżenia.

Hybrid Entra ID Join to architektura, w której urządzenia są jednocześnie członkami lokalnego Active Directory (klasyczne dołączenie do domeny) i zarejestrowane w Microsoft Entra ID. Microsoft przyznaje to wprost w dokumentacji: "Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended." Mimo to setki firm nadal korzystają z tego podejścia — mają legacy aplikacje korzystające z Kerberos, skrypty logowania przez GPO, certyfikaty on-premises i procesy, których migracja do chmury to projekt na lata, nie tygodnie.

Dlaczego tak się dzieje

Zrozumienie przyczyn awarii wymaga wiedzy o tym, co Autopilot Hybrid Join faktycznie robi pod maską podczas OOBE (Out-Of-Box Experience).

Rola ODJ Connectora. Centralnym elementem jest Intune Connector for Active Directory, znany też jako ODJ Connector (Offline Domain Join). Działa on na serwerze w sieci korporacyjnej i pełni rolę pośrednika między Intune a lokalnym Active Directory. Gdy urządzenie inicjuje proces Autopilot, connector tworzy obiekt komputera w AD, generuje plik ODJ blob (XML opisujący konfigurację dołączenia do domeny) i przesyła go do Intune. Urządzenie pobiera ten blob podczas OOBE i używa go do dołączenia do domeny — bez bezpośredniego dostępu do DC w momencie pobierania profilu.

Problem w tym, że cały ten łańcuch ma wiele punktów awarii, a każdy z nich objawia się podobnym komunikatem błędu na urządzeniu. To właśnie sprawia, że diagnostyka Hybrid Join jest tak trudna — te same objawy mogą mieć cztery różne przyczyny.

Dlaczego connector jest tak wrażliwy. ODJ Connector to długo działająca usługa Windows na serwerze, która utrzymuje połączenie z Intune przez chmurę Microsoft. Wymaga ona jednoczesnego dostępu do internetu (endpointy Intune) i do kontrolera domeny (RPC, LDAP). Każda zmiana po stronie Microsoftu w infrastrukturze chmurowej — zmiana endpointów, rotacja certyfikatów, aktualizacje wymagań protokołu — może zepsuć działającą konfigurację bez zmiany czegokolwiek lokalnie. Właśnie to wydarzyło się w grudniu 2025 roku.

Asynchroniczna natura Hybrid Join. W przeciwieństwie do czystego Entra Join, który kończy się synchronicznie podczas OOBE, Hybrid Join ma fazę asynchroniczną. Urządzenie dołącza do domeny, restartuje się, a dopiero po restarcie i synchronizacji przez Azure AD Connect pojawia się jako obiekt w Entra ID. Azure AD Connect domyślnie synchronizuje co 30 minut. To okno czasowe generuje problemy z ESP (Enrollment Status Page) i brakiem tokenu AzureADPRT przy pierwszym logowaniu użytkownika.

Rozwiązanie krok po kroku

Krok 1: Sprawdź wersję Intune Connector for Active Directory

To jest punkt startowy każdej diagnostyki. Na serwerze z connectorem otwórz Panel sterowania → Programy → Programy i funkcje i znajdź "Intune Connector for Active Directory". Jeśli wersja jest niższa niż 6.2501.2000.5 — to masz główny problem. Od początku 2025 roku starsze wersje są oficjalnie zdeprecjonowane i nie mogą już przetwarzać żądań rejestracji.

Aktualizacja nie jest automatyczna i wymaga ręcznej interwencji. Microsoft zaleca następującą kolejność (żeby uniknąć przestoju):

1. Zainstaluj nowy connector na dodatkowym serwerze (nie na tym, gdzie jest stary)
2. Dopiero po weryfikacji, że nowy działa, odinstaluj stary ze starego serwera
3. Pobierz nowy installer z: Intune admin center → Devices → Windows → Enrollment → Intune Connector for Active Directory → Add (plik ODJConnectorBootstrapper.exe)

Podczas instalacji potrzebujesz konta z uprawnieniem do tworzenia obiektów msDs-ManagedServiceAccount w kontenerze Managed Service Accounts domeny. Nie musisz być Domain Adminem, ale to konkretne uprawnienie jest obowiązkowe. Connector tworzy konto MSA o nazwie w formacie msaODJ##### — zanotuj tę nazwę, będzie potrzebna przy konfiguracji OU.

Od wersji 6.2504.2001.8 connector używa WebView2 (opartego na Edge) zamiast przestarzałego Internet Explorer. Oznacza to, że nie musisz już wyłączać Internet Explorer Enhanced Security Configuration na serwerze — co było jednym z irytujących kroków wstępnych.

Krok 2: Zweryfikuj uprawnienia MSA do docelowej OU

Jeśli w profilu Deployment Profile określiłeś konkretną OU (pole "Domain join OU"), Managed Service Account connectora musi mieć tam uprawnienia do tworzenia obiektów Computer. Sprawdź to PowerShellem:

# Znajdź MSA stworzone przez connector
Get-ADServiceAccount -Filter {Name -like "msaODJ*"} | 
    Select-Object Name, DistinguishedName, Created

# Sprawdź uprawnienia na docelowej OU
$ouPath = "OU=Autopilot,DC=firma,DC=local"
(Get-Acl "AD:\$ouPath").Access | 
    Where-Object { $_.IdentityReference -like "*msaODJ*" } | 
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

Jeśli MSA nie pojawia się na liście ACL — musisz dodać uprawnienia. Minimalne wymagane: Create Computer objects, Delete Computer objects i Read/Write all properties na obiektach Computer w OU. Możesz użyć Delegation of Control Wizard w ADUC lub nadać uprawnienia przez Advanced Security Settings na OU.

Charakterystyczny symptom tego problemu: błąd 0x80070774 (kod sieci 1908, "Could not find the domain controller for this domain") lub 0x8fffffff ("Parameter error for WindowsDomainJoinConfiguration") przy jednoczesnym działaniu połączenia do DC — connector łączy się z DC, ale nie może tam nic zapisać.

Krok 3: Sprawdź logi ODJ Connector Service na serwerze

Na serwerze z connectorem otwórz Event Viewer i przejdź do: Application and Services Logs → ODJ Connector Service

Ignoruj event IDs 30121 i 30150 — to szum informacyjny. Szukaj następujących zdarzeń z czasu wdrożenia urządzenia:

• Event 30120: Connector odebrał żądanie z Intune (dobry znak — odbiór działa)
• Event 30130: Żądanie zostało przetworzone (connector stworzył obiekt w AD)
• Event 30140: ODJ blob został przesłany do Intune (sukces — urządzenie powinno pobrać blob)

Jeśli z czasu wdrożenia nie ma żadnych eventów — connector nigdy nie dostał żądania. Problem leży po stronie komunikacji między Intune a connectorem (firewall, przestarzała wersja, zmiana endpointów). Jeśli jest 30120 ale nie ma 30130 — connector dostał żądanie, ale nie mógł stworzyć obiektu w AD (uprawnienia, OU, DC niedostępny).

Krok 4: Diagnostyka na urządzeniu podczas OOBE

Podczas OOBE możesz otworzyć wiersz poleceń kombinacją Shift+F10 i uruchomić diagnostykę Autopilot:

Set-ExecutionPolicy Bypass -Scope Process -Force
Install-Script Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics

W wynikach zwróć uwagę na:

• "ODJ applied: No" — blob ODJ nie dotarł do urządzenia (problem po stronie connectora lub Intune)
• "Timed out waiting for ODJ blob" — connector nie odpowiedział w wymaganym czasie lub nie istnieje profil Domain Join Configuration
• "Domain join profile not found" — profil Domain Join nie jest przypisany do tego urządzenia lub grupy

Krok 5: Wymuś synchronizację Azure AD Connect

Jeśli urządzenie poprawnie dołączyło do lokalnego AD, ale nie pojawia się w Entra ID lub Intune nie widzi go jako Hybrid Joined:

# Na serwerze z Azure AD Connect — delta sync (szybsza)
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

# Jeśli delta nie wystarczy — pełna synchronizacja inicjalna
Start-ADSyncSyncCycle -PolicyType Initial

# Sprawdź status ostatniego cyklu synchronizacji
Get-ADSyncScheduler | Select-Object LastSyncAttemptedTime, LastSyncSuccessTime, SyncCycleEnabled

Pamiętaj, że standardowy cykl trwa do 30 minut. Jeśli po wymuszeniu sync urządzenie nadal nie pojawia się w Entra ID, sprawdź, czy OU urządzenia jest objęta zakresem synchronizacji. W Synchronization Service Manager (miisclient.exe) przejdź do Connectors → Azure AD Connector → Properties → Configure Directory Partitions i zweryfikuj filtrowanie OU.

Krok 6: Usuń zduplikowane obiekty urządzeń w Entra ID

Jeśli widzisz dwa obiekty dla jednego urządzenia w Entra ID:

# Znajdź duplikaty po nazwie urządzenia
Get-MgDevice -Filter "displayName eq 'LAPTOP-CORP01'" | 
    Select-Object Id, DisplayName, RegistrationDateTime, TrustType, ApproximateLastSignInDateTime

# TrustType "AzureAd" = zarejestrowane przez Autopilot (wstępna rejestracja)
# TrustType "ServerAd" = zsynchronizowane przez AAD Connect (właściwy obiekt)
# Usuń obiekt z TrustType "AzureAd" — zostanie ponownie zsynchronizowany
Remove-MgDevice -DeviceId "<id-obiektu-AzureAd>"

Krok 7: Napraw timeout ESP — wyłącz User Status Page

Jeśli urządzenia zatrzymują się z błędem timeout podczas fazy ESP User (Enrollment Status Page), zastosuj custom OMA-URI policy w Intune:

OMA-URI: ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
Data type: Boolean
Value: True

Hybrid Join w trybie user-driven kończy się asynchronicznie — po zalogowaniu użytkownika, a nie w trakcie ESP. User Status Page bez tego ustawienia czeka na zakończenie procesu, który z definicji nastąpi później.

Typowe pułapki i edge cases

Pułapka 1: Domain Join Profile przypisany do użytkowników zamiast urządzeń

To prawdopodobnie najczęstszy błąd, który jest też najtrudniejszy do wykrycia, bo na pierwszy rzut oka konfiguracja wygląda poprawnie. Profile Autopilot Deployment i Domain Join Configuration muszą być przypisane do grup urządzeń (Devices), nie użytkowników. Jeśli przypisałeś do grupy użytkowników, profil może w ogóle nie dotrzeć do urządzenia podczas OOBE — Autopilot sprawdza przypisanie przez identyfikator urządzenia, zanim użytkownik się zaloguje.

Sprawdź to w: Intune admin center → Devices → Windows → Enrollment → Deployment Profiles → [profil] → Assignments. Jeśli widzisz grupy użytkowników — zmień na grupy urządzeń lub "All Devices".

Pułapka 2: Jeden connector per domena, jeden serwer per connector

ODJ Connector obsługuje wyłącznie domenę, do której należy serwer, na którym jest zainstalowany. W środowiskach z wieloma domenami AD (np. firma.local i subsidiary.local) potrzebujesz osobnego serwera z connectorem dla każdej domeny. Microsoft nie wspiera instalacji dwóch connectorów na jednym serwerze. Możliwa jest redundancja — wiele serwerów w tej samej domenie, każdy z własnym connectorem — ale nie obsługa wielu domen z jednego serwera.

Pułapka 3: Brak AzureADPRT po pierwszym logowaniu

Po dołączeniu do domeny i zalogowaniu użytkownika Teams, OneDrive i inne aplikacje M365 wymagają ponownego wpisania hasła lub w ogóle nie działają. Przyczyna: urządzenie nie ma jeszcze tokenu PRT (Primary Refresh Token) z Entra ID, bo Azure AD Connect jeszcze nie zsynchronizował obiektu urządzenia. Użytkownik jest sfrustrowany, dzwoni do helpdesku, a problem sam rozwiąże się po restarcie lub po upływie 30 minut.

Obejście dla środowisk produkcyjnych: po wdrożeniu przez Autopilot, zanim oddasz urządzenie użytkownikowi, poczekaj na pełny cykl synchronizacji AAD Connect lub wymuś go poleceniem Start-ADSyncSyncCycle. Możesz zweryfikować obecność PRT poleceniem dsregcmd /status — szukaj AzureADPrt : YES.

Pułapka 4: Firewall nie przepuszcza nowych endpointów Azure Front Door

W grudniu 2025 roku Microsoft zmienił endpointy używane przez ODJ Connector do komunikacji z Intune. Organizacje z restrykcyjnymi regułami firewall lub proxy musiały whitelistować nowe adresy. Jeśli Twój connector przestał działać bez żadnej zmiany konfiguracji lokalnej po grudniu 2025 — sprawdź reguły wyjścia dla serwera:

Endpointy wymagane dla ODJ Connector (poza standardowymi endpointami Intune):

• clientconfig.passport.net (port 443)
• *.delivery.mp.microsoft.com (port 443)

Connector wymaga tych samych endpointów co Intune ogółem — pełna lista: learn.microsoft.com/en-us/intune/fundamentals/endpoints.

Pułapka 5: Replikacja AD między kontrolerami domeny

Connector tworzy obiekt komputera na DC, z którym ma bezpośrednie połączenie. Urządzenie podczas OOBE może "trafić" na inny DC (szczególnie w środowiskach rozproszonych geograficznie z Site and Services AD), na którym obiekt jeszcze się nie zreplikował. Wynik: urządzenie dostaje blob ODJ, próbuje dołączyć do domeny, ale dostaje "computer account not found". Błąd pojawia się nieregularnie — raz działa, raz nie.

W środowiskach z wieloma lokalizacjami lub wolną replikacją AD warto skonfigurować connector tak, żeby działał na DC w tej samej lokalizacji co wdrażane urządzenia. Możesz też zweryfikować replikację:

# Sprawdź status replikacji między DC
repadmin /replsummary

# Sprawdź, na którym DC jest zreplikowany konkretny obiekt
repadmin /showattr * "CN=LAPTOP-CORP01,OU=Autopilot,DC=firma,DC=local" /atts:objectGUID

Jak my to rozwiązujemy w Evolit

Autopilot Hybrid Join to obszar, gdzie ręczny onboarding urządzeń generuje nieproporcjonalnie dużo ticketów do helpdesku — szczególnie przy wdrożeniach do kilku lokalizacji jednocześnie. W Evolit używamy Nexmy do zarządzania procesem onboardingu nowych pracowników, w tym inicjowania wdrożeń Autopilot i weryfikacji statusu rejestracji urządzenia. Nexma integruje się z Intune i Entra ID, dzięki czemu w jednym widoku widać: czy urządzenie przeszło przez ESP poprawnie, czy pojawiło się w AD, czy użytkownik ma właściwe licencje i dostępy — bez ręcznego sprawdzania każdego portalu z osobna. Dla zespołów, które wolą natywne narzędzia, ten sam poziom wglądu można uzyskać przez Intune admin center + Microsoft Endpoint Analytics, ale wymaga to otwierania kilku zakładek i łączenia danych ręcznie.

Więcej o możliwościach platformy: nexma.app

Podsumowanie

• Wersje Intune Connector for Active Directory poniżej 6.2501.2000.5 są zdeprecjonowane — aktualizacja bez downtime'u wymaga instalacji nowej wersji na dodatkowym serwerze przed odinstalowaniem starej
• Błąd 0x80070774 to zazwyczaj problem z brakiem dostępu sieciowego do DC lub niewystarczającymi uprawnieniami MSA connectora do docelowej OU
• Błąd 0x80004005 = malformed id_token podczas OtaDomainJoin — często wystarczy kliknąć "Try Again", ale to objaw problemu po stronie platformy Microsoftu
• Profile Domain Join Configuration muszą być przypisane do grup urządzeń, nie użytkowników — błąd prawie niewidoczny w konfiguracji
• Jeden ODJ Connector obsługuje jedną domenę; środowiska multi-domain wymagają osobnych serwerów z connectorami
• Microsoft oficjalnie rekomenduje Entra Join (cloud-native) zamiast Hybrid Join dla nowych wdrożeń — jeśli masz możliwość migracji, rozważ ją poważnie
• Diagnostyka: logi ODJ Connector Service (event IDs 30120/30130/30140) + skrypt Get-AutopilotDiagnostics na urządzeniu + dsregcmd /status po dołączeniu