Perché la strategia di join viene prima del metodo di deployment

Prima di scegliere come consegnare un dispositivo Windows 11 all’utente, l’endpoint administrator deve decidere a quale identità il dispositivo appartiene. In un tenant moderno la scelta ricade su Microsoft Entra join (cloud-only) oppure Microsoft Entra hybrid join (aggancio simultaneo ad Active Directory on-prem e a Entra ID). Questa decisione condiziona a cascata l’enrollment in Microsoft Intune, l’applicazione delle policy, l’accesso condizionale e la stessa esperienza di Windows Autopilot.

Entra join (cloud-only): il default raccomandato

Con Entra join il dispositivo ha una sola identità, quella cloud. L’enrollment in Intune avviene automaticamente se è configurata la MDM auto-enrollment (scope utente in Entra ID + licenza EMS/Intune). È il modello che Microsoft raccomanda perché:

  • non richiede line-of-sight verso un domain controller;
  • funziona ovunque ci sia connettività internet, ideale per lavoro remoto e ibrido;
  • abilita pienamente Windows Hello for Business, la gestione moderna e i profili Autopilot user-driven senza dipendenze legacy.

Per accedere a risorse on-prem (file server, stampanti, app Kerberos) senza dominare la macchina si usano Microsoft Entra Kerberos / Cloud Kerberos Trust e, per lo SSO applicativo interno, l’Application Proxy. Questo elimina gran parte delle ragioni storiche a favore dell’hybrid.

Entra hybrid join: quando serve davvero

L’hybrid join mantiene la macchina joinata ad AD DS e la registra anche in Entra ID tramite Microsoft Entra Connect. Serve solo quando persistono dipendenze reali:

  • applicazioni line-of-business che richiedono l’appartenenza al dominio o Group Policy specifiche non ancora convertite in policy Intune;
  • autenticazione integrata verso sistemi legacy che presuppongono il computer account in AD.

Per fare enrollment via Autopilot in scenario hybrid è necessario l’Intune Connector for Active Directory (Offline Domain Join Connector), che crea il computer account on-prem durante l’OOBE. Proprio qui nasce il vincolo critico: durante il provisioning il dispositivo deve raggiungere un domain controller (VPN pre-login o rete corporate). Senza line-of-sight, l’ODJ blob non viene applicato e l’OOBE fallisce o si allunga.

Autopilot, provisioning package o reimaging

Sul metodo, i tre approcci coprono esigenze diverse:

  • Windows Autopilot — dispositivo consegnato con l’OEM image, hash hardware registrato nel Autopilot service, profilo (user-driven, self-deploying, pre-provisioning/white glove) applicato all’accensione. È l’approccio cloud-native: nessuna immagine custom, zero touch per l’IT, ideale per shipping diretto all’utente.
  • Provisioning package (.ppkg) — creato con Windows Configuration Designer, applica configurazioni e join a un device già installato. Utile per scenari offline, ambienti senza registrazione Autopilot, o per bulk enrollment rapido su hardware esistente.
  • Reimaging tradizionale (MDT/Configuration Manager, task sequence) — controllo totale sull’immagine, ma pesante da mantenere e legato a infrastruttura on-prem. Giustificato solo per requisiti di immagine molto rigidi o refresh massivi di parco esistente.

Criterio di scelta

Nuovo hardware + tenant moderno → Autopilot user-driven con Entra join. Serve provisioning veloce con tecnico che pre-carica app pesanti prima della consegna → Autopilot pre-provisioning. Nessuna connessione ad Autopilot service o esigenza offline puntuale → provisioning package. Dipendenze AD irrinunciabili → hybrid join, ma valutando prima la migrazione delle GPO a Intune.

Trappole tipiche d’esame

  • Scenario: utenti in smart working ricevono laptop via corriere e non hanno VPN pre-login. → Risposta: Autopilot user-driven con Entra join cloud-only; l’hybrid join fallirebbe per mancanza di line-of-sight al domain controller.
  • Scenario: il cliente chiede hybrid join “per sicurezza” ma non ha app che richiedono il dominio. → Risposta: raccomandare Entra join cloud-native; l’hybrid aggiunge complessità e allunga l’OOBE senza benefici.
  • Scenario: serve Autopilot in modalità hybrid join. → Risposta: installare l’Intune Connector for Active Directory e garantire connettività al DC durante l’OOBE (VPN pre-login o rete corporate).
  • Scenario: il tecnico deve consegnare dispositivi con tutte le app aziendali già installate, pronti all’uso in pochi minuti dall’utente. → Risposta: Autopilot pre-provisioning (white glove), non user-driven puro.
  • Scenario: enrollment necessario su PC esistenti senza registrare l’hash hardware in Autopilot. → Risposta: provisioning package creato con Windows Configuration Designer, non Autopilot.