Les projets de migration Intune tenant à tenant s’inscrivent généralement dans des contextes de fusions-acquisitions, de rationalisation de tenants Microsoft 365 ou de modernisation de l’environnement Endpoint Manager. Dans chacun de ces scénarios, la gestion du réenrôlement des appareils Autopilot et la reconfiguration des profils Microsoft Entra ID représentent des défis majeurs, tant sur le plan technique qu’organisationnel. Pour appréhender l’ensemble des enjeux d’une telle opération, il est utile de consulter notre analyse dédiée à la migration tenant à tenant Microsoft 365 en contexte de fusion-acquisition. Ce guide détaille les étapes clés du plan de bascule Intune et du reprovisionnement des postes pour garantir une transition maîtrisée.
À retenir :
- Migration Microsoft Intune nécessite ré-enrôlement complet, aucune politique ne se transfère automatiquement entre tenants.
- Sous-estimer le ré-enrôlement Autopilot peut causer des interruptions de productivité significatives.
- Corporate identifiers cruciaux pour identification des appareils et leur sécurité lors du transfert vers le nouveau tenant.
- La préparation avant migration inclut l’inventaire des appareils et la reconfiguration des profils pour maintenir la conformité.
- Après le ré-enrôlement, reconstituer manuellement les politiques et profils est essentiel pour éviter les vulnérabilités.
- Automatisation du ré-enrôlement et suivi via Endpoint Analytics optimisent la gestion des migrations à grande échelle.
Comprendre le rôle d’Autopilot dans la migration Intune tenant à tenant
Windows Autopilot automatise la préparation des appareils Windows lors d’une migration tenant à tenant, en simplifiant leur réinscription dans le nouvel environnement Microsoft Endpoint Manager. Comprendre son fonctionnement est indispensable pour éviter toute interruption de productivité pendant le basculement.
Principe d’Autopilot et Device Preparation
Windows Autopilot repose sur un mécanisme d’approvisionnement basé sur le cloud : l’appareil est reconnu dès son démarrage grâce à son profil matériel, puis configuré automatiquement selon les politiques définies dans Intune. La fonctionnalité Device Preparation complète ce mécanisme en orchestrant les étapes de déploiement — installation des applications, application des règles de conformité, personnalisation de l’environnement utilisateur — sans intervention manuelle. Selon Microsoft, cette approche permet de préparer et configurer de nouveaux appareils pour un usage immédiatement productif. (Source : Microsoft — 2025-04-02)
Dans un projet de migration tenant à tenant Microsoft 365, le ré-enrôlement Autopilot constitue l’un des points les plus sensibles : chaque appareil doit être rattaché au nouveau tenant avec un profil Autopilot valide, sous peine de perdre la gestion MDM et l’accès aux ressources de l’entreprise.
Corporate identifiers : sécuriser la réinscription des appareils
Les Corporate identifiers jouent un rôle central dans la fiabilité du réenrôlement Autopilot. Ces identifiants — numéros de série, hash matériel ou identifiants IMEI pour les appareils mobiles — permettent à Intune de reconnaître formellement un appareil comme appartenant à l’entreprise, indépendamment du tenant source. Lors d’une migration, leur exportation depuis l’ancien tenant et leur importation dans le nouveau constituent une étape critique : tout appareil non identifié risque d’être traité comme un appareil personnel, ce qui restreint les politiques applicables et compromet la sécurité des données.
| Type d’identifiant | Usage principal | Priorité en migration |
|---|---|---|
| Hash matériel (Hardware Hash) | Identification unique de l’appareil dans Autopilot | Haute |
| Numéro de série | Corporate identifier Intune | Haute |
| IMEI | Appareils mobiles gérés | Moyenne |
| ID Autopilot existant | Réutilisation du profil source (si compatible) | À évaluer |
Étapes préparatoires avant le basculement vers le nouveau tenant
Avant toute migration, plusieurs actions préparatoires s’imposent. Il convient d’abord d’inventorier l’ensemble des appareils enrôlés dans l’ancien tenant via Endpoint Analytics, afin d’identifier ceux qui bénéficient d’un profil Autopilot actif. Ensuite, les profils de déploiement Autopilot doivent être recréés dans le tenant cible avec des paramètres équivalents — ou améliorés — pour garantir la continuité des politiques de sécurité. Il est également recommandé de tester le processus de préparation des appareils Windows Intune sur un lot pilote avant le déploiement en masse, afin de détecter les éventuelles incompatibilités avec les applications métier ou les stratégies de confort.
Ces fondations posées, il est désormais possible d’aborder les opérations concrètes de ré-enrôlement : la suppression des appareils de l’ancien tenant et leur réinscription effective dans le nouveau.
Gérer les profils et politiques de configuration après migration
Après un ré-enrôlement Autopilot réussi, les appareils enregistrés dans le tenant cible sont des objets vierges du point de vue des politiques : aucune stratégie de conformité, aucun profil de configuration Intune ni aucune App Protection Policy ne leur est encore appliquée. La priorité est donc de reconstituer, adapter et affecter l’ensemble de ces éléments dans le nouvel environnement avant de déployer les appareils auprès des utilisateurs.
Réutiliser les stratégies de conformité et de protection applicative
Les Compliance Policies et les App Protection Policies ne se transfèrent pas automatiquement d’un tenant à l’autre. Il faut les recréer manuellement dans le tenant cible, ou s’appuyer sur des outils d’export comme l’Intune Backup & Restore (solution communautaire) pour exporter les définitions JSON et les réimporter. Cette étape est l’occasion d’auditer les politiques existantes : certaines règles de conformité, notamment celles liées aux versions minimales d’OS ou aux exigences BitLocker, peuvent être mises à jour pour refléter l’état réel du parc migré. Les profils de conformité Intune doivent couvrir, dès la première affectation, l’ensemble des appareils nouvellement enrôlés pour éviter toute fenêtre de non-conformité.
Recréer les groupes dynamiques Microsoft Entra ID
Les groupes dynamiques Microsoft Entra ID (anciennement Azure AD) constituent le mécanisme central de ciblage des politiques de configuration Intune. Ils ne migrent pas avec les objets appareils : leurs règles de membership doivent être recréées dans le tenant cible en s’appuyant sur des attributs disponibles après re-enrôlement, tels que deviceEnrollmentType, deviceCategory ou des propriétés Autopilot injectées via les profils de déploiement. La bascule des stratégies de sécurité endpoint ne sera effective que lorsque ces groupes dynamiques Azure AD seront correctement peuplés et que les politiques leur seront explicitement affectées.
| Objet à recréer | Méthode recommandée | Priorité |
|---|---|---|
| Compliance Policies | Export JSON + réimport manuel | Critique |
| Configuration Profiles | Recréation manuelle ou script PowerShell | Haute |
| App Protection Policies | Export JSON + validation métier | Haute |
| Groupes dynamiques Entra ID | Recréation via règles de membership | Critique |
Prendre en compte la limite d’enrôlement par utilisateur
Un point souvent sous-estimé dans la planification du réenrôlement concerne le quota d’appareils par compte. Selon Microsoft, Intune permet à un utilisateur d’enrôler jusqu’à 15 appareils par défaut (Source : Microsoft — date non disponible). Ce plafond doit être vérifié et, si nécessaire, ajusté via une stratégie de limite d’enrôlement avant de lancer les vagues de migration, sous peine de blocages silencieux pour les utilisateurs possédant plusieurs appareils professionnels. Cette contrainte est particulièrement sensible dans les environnements avec appareils partagés ou scénarios BYOD. La configuration de la stratégie de conformité tenant cible doit donc s’accompagner d’une vérification systématique de ces limites pour garantir un réenrôlement sans interruption.
Résoudre les erreurs d’enrôlement et les problèmes d’accès conditionnel
Les échecs d’enrôlement Intune lors d’une migration tenant à tenant résultent le plus souvent d’une mauvaise configuration de l’auto-enrollment ou d’un conflit avec les politiques d’accès conditionnel. Identifier précisément la cause racine permet de réduire significativement le temps de remédiation.
Causes fréquentes liées à Microsoft Entra ID
Le troubleshooting enrôlement Intune débute invariablement par l’analyse des journaux d’événements Windows (Event Viewer, canal DeviceManagement-Enterprise-Diagnostics-Provider) et par la vérification de l’état de l’objet appareil dans Microsoft Entra ID. Les causes les plus courantes d’un problème d’inscription Intune incluent : un objet hybride en double suite à une mauvaise jointure Entra, un token MDM expiré, ou encore l’absence de licence Intune correctement assignée dans le nouveau tenant. Une erreur de synchronisation Entra ID peut également laisser subsister un enregistrement orphelin de l’ancien tenant, ce qui bloque l’enrôlement dans le nouveau.
| Symptôme observé | Cause probable | Action corrective |
|---|---|---|
| Code 0x80180026 | Objet appareil dupliqué dans Entra ID | Supprimer l’entrée obsolète via le portail Entra ou PowerShell |
| Erreur MFA Intune lors de l’enrôlement | Application Intune soumise à une politique MFA | Exclure l’application Intune des politiques Conditional Access |
| Auto-enrollment silencieux échoué | Clé de registre MDM absente ou mal configurée | Vérifier et recréer la clé AutoEnrollMDM via GPO ou script |
| Appareil non visible dans Intune | Synchronisation Entra Connect incomplète | Forcer un cycle de delta sync sur Microsoft Entra Connect |
Corriger les configurations d’auto-enrôlement et de politique MFA
La configuration de l’Auto-enrollment Intune repose sur la définition précise de la portée MDM dans le portail Azure AD. Une portée « Aucun » laissée par inadvertance dans le nouveau tenant suffit à bloquer l’ensemble du flux d’enrôlement automatique. Il convient de la positionner sur « Tous » ou sur un groupe de sécurité ciblé. Concernant le Conditional Access, Microsoft indique qu’il est nécessaire d’exclure l’application Microsoft Intune des politiques exigeant une authentification multifacteur pour éviter les boucles d’échec lors de l’enrôlement automatique (Source : Microsoft — 2025-02-11). Cette exclusion doit être temporaire et strictement documentée pour respecter le cadre de gouvernance sécurité de l’organisation.
Suppression des anciens certificats et resynchronisation Entra Connect
Lorsque des appareils hybrides ont été précédemment joints au tenant source, des certificats d’enrôlement résiduels peuvent persister dans le magasin de certificats local (Certificates – Local Machine > Personal). Leur présence bloque la création d’un nouveau lien MDM. La procédure consiste à supprimer ces certificats via certlm.msc, à désinscrire l’appareil du tenant source avec dsregcmd /leave, puis à rejoindre le tenant cible. En parallèle, une resynchronisation forcée de Microsoft Entra Connect (Start-ADSyncSyncCycle -PolicyType Delta) garantit que les attributs deviceId et objectId sont correctement propagés vers le nouveau répertoire. Pour les migrations de grande envergure impliquant plusieurs centaines d’appareils, ces étapes gagneront à être automatisées par script PowerShell et déployées en séquence contrôlée.
Optimiser le suivi et l’automatisation du ré-enrôlement
Automatiser le ré-enrôlement Autopilot et centraliser le reporting Intune permet de réduire significativement les délais et les erreurs lors d’une migration tenant à tenant à grande échelle. Ces deux leviers constituent la colonne vertébrale d’une opération industrialisée et maîtrisée.
Automatiser le ré-enrôlement et la désinscription via PowerShell et Microsoft Graph API
Les scripts PowerShell couplés à la Microsoft Graph API offrent un niveau d’automatisation du réenrôlement Intune qui rend les migrations volumineuses réalistes sans sur-solliciter les équipes IT. Concrètement, un script peut interroger l’API Graph pour lister les appareils encore rattachés à l’ancien tenant, déclencher leur désinscription via DELETE /deviceManagement/managedDevices/{id}, puis réinjecter les hash matériels dans le nouveau tenant pour préparer le profil Autopilot correspondant.
Cette approche permet également de traiter les enrôlements par lots, d’intégrer des délais de sécurité entre les phases de désinscription et de ré-enrôlement, et de journaliser chaque opération pour faciliter l’audit. Les équipes peuvent ainsi orchestrer des vagues successives d’appareils sans intervention manuelle, tout en conservant une traçabilité complète des statuts. Il est recommandé de tester les scripts sur un périmètre pilote restreint avant toute généralisation.
Selon Microsoft, les identifiants d’entreprise dans Intune garantissent que seuls les appareils de confiance passent par Windows Autopilot Device Preparation (Source : Microsoft — 2025-04-02). Cette logique s’intègre naturellement dans les scripts en conditionnant le déclenchement du ré-enrôlement à la validation préalable de l’identifiant corporate de chaque appareil.
Mettre en place un tableau de bord Endpoint Analytics pour le suivi de migration Intune
Le suivi de migration Intune gagne en lisibilité grâce au tableau de bord Endpoint Analytics, accessible depuis le portail Microsoft Intune. Cet outil consolide en temps réel des indicateurs clés : taux d’enrôlement Autopilot réussi, temps moyen de provisioning, taux d’échec par modèle d’appareil ou par site géographique.
| Indicateur | Source | Utilité lors de la migration |
|---|---|---|
| Taux de succès Autopilot | Endpoint Analytics | Identifier les lots d’appareils bloqués |
| Temps de provisioning moyen | Endpoint Analytics | Détecter les anomalies de performance |
| Erreurs de politique de conformité | Intune — Rapports | Corriger les profils mal appliqués |
| Statut de chiffrement BitLocker | Intune — Chiffrement | Vérifier la rotation des clés de récupération |
Ce tableau de bord permet aux responsables IT de communiquer sur l’avancement de la migration avec des données objectives, et d’ajuster les vagues planifiées en fonction des résultats observés.
Optimiser la rotation des clés BitLocker et la ré-injection des profils réseau
Après chaque ré-enrôlement Autopilot, deux opérations critiques doivent être automatisées : la rotation des clés de récupération BitLocker vers le nouveau tenant, et la ré-injection des profils réseau (Wi-Fi, VPN). Sans ces étapes, les appareils peuvent se retrouver dans un état de chiffrement orphelin ou incapables de se connecter aux ressources de l’entreprise. Des scripts PowerShell ciblant l’API Graph permettent de déclencher automatiquement la rotation de clé BitLocker dès la confirmation de l’enrôlement, puis de pousser les profils réseau via les politiques de configuration Intune. L’enchaînement logique de ces automatisations constitue le cœur de l’optimisation du réenrôlement Autopilot à grande échelle.
Conclusion
Une migration Intune tenant à tenant réussie repose avant tout sur une préparation rigoureuse et une remédiation automatisée bien orchestrée. En structurant dès le départ les politiques, les groupes dynamiques et les profils Autopilot dans le nouveau tenant, les équipes IT limitent sensiblement les interruptions de service post-bascule.
Windows Autopilot joue un rôle central dans ce processus : il garantit la réinscription fiable des appareils sans intervention manuelle, condition indispensable à une bascule Intune contrôlée. Microsoft Entra ID permet par ailleurs d’encadrer précisément ce périmètre — selon Microsoft, la limite de périphériques par utilisateur peut être fixée à 20 maximum pour un meilleur contrôle du parc (Source : Microsoft — 2026-04-09).
Enfin, mesurer la réussite d’une migration Intune réussie via Endpoint Analytics et le suivi de l’adoption utilisateurs permet d’ajuster les actions post-migration et de consolider durablement le nouvel environnement Microsoft 365.
