Defender for Endpoint : intégrer les appareils via Intune

Intégrer un parc à Microsoft Defender for Endpoint semble trivial tant que l'on n'a pas croisé plusieurs systèmes d'exploitation, plusieurs outils de gestion et un connecteur Intune qui ne se comporte pas comme prévu. Cet article compare les méthodes d'intégration, détaille la voie Microsoft Intune pas à pas, signale les pièges rapportés sur le terrain et fournit un script de contrôle local pour confirmer que l'appareil est réellement intégré.

Quelle méthode d'intégration choisir pour vos appareils ?

Le choix dépend du système d'exploitation et de l'outil qui gère déjà vos appareils : si vos postes Windows sont enrôlés dans Intune, la stratégie EDR (Endpoint Detection and Response) est la voie naturelle. L'assistant du portail Defender part du même principe : vous choisissez d'abord le système d'exploitation, puis la méthode de déploiement.

Un changement de navigation mérite d'être noté. La documentation Microsoft Learn place désormais la page d'intégration dans Système > Paramètres > Points de terminaison > Gestion des appareils > Intégration. Elle propose un type de connectivité « Streamlined » (rationalisée) ou « Standard ». Pour Windows, l'étape 1 sélectionne « Windows » (outil de déploiement) ou un groupe de versions pour un script local ou une autre méthode.

L'outil de déploiement Defender est parfois présenté comme la méthode privilégiée. Cette affirmation se nuance : si vous administrez déjà vos appareils avec Intune, la stratégie EDR évite d'introduire une seconde chaîne d'intégration à superviser.

Intégrer des appareils Windows avec une stratégie EDR Intune

La stratégie préconfigurée est le chemin le plus court : quelques clics, un déploiement immédiat vers tous les appareils Windows ciblés. Avant de commencer, validez les prérequis.

Une fois ces points confirmés, créez la stratégie.

Pour un contrôle plus fin (groupes d'appareils précis, balises d'étendue personnalisées), passez par Créer une stratégie et construisez le profil manuellement. Dans ce cas, la documentation Microsoft Learn recommande l'option « Auto from connector » lorsque la connexion de service est en place.

Connecteur, conflits de stratégie et erreur 65000 : les pièges connus

Trois situations expliquent la majorité des intégrations qui n'aboutissent pas : un connecteur inactif, des stratégies concurrentes et une option « Auto from connector » absente.

La documentation Intune précise qu'une stratégie de configuration d'appareil peut aussi servir à l'intégration, mais qu'elle ne gère pas les appareils en attachement de locataire. Cumuler plusieurs types de stratégies sur le même paramètre d'intégration provoque des conflits : gardez un seul type de stratégie par population d'appareils.

Le tableau suivant regroupe les symptômes les plus courants avec une piste de résolution. Les deux premières lignes reposent sur la documentation Microsoft ; les suivantes sur les retours cités ci-dessus et sur un raisonnement d'ingénierie à valider sur un appareil pilote.

L'outil de déploiement Defender : quand sortir d'Intune

L'outil de déploiement Defender (DefenderDT.exe) gère les prérequis, automatise les migrations depuis d'anciennes solutions et supprime le besoin de scripts d'intégration complexes ou de téléchargements séparés. Vous le lancez depuis l'assistant d'intégration en sélectionnant « Windows » (outil de déploiement) à l'étape 1.

Son fonctionnement repose sur une clé d'accès générée dans le portail Defender. Les packages expirent entre 1 jour et 1 an ; Microsoft recommande la durée de validité la plus courte possible, ce qui limite l'exposition si un package fuit. L'outil couvre aussi le mode passif sur serveur, le VDI non persistant et un prétest via le paramètre -Precheck.

Deux contraintes à retenir. Les packages sont propres à un locataire : ne les réutilisez jamais d'un locataire à l'autre. Et la prise en charge de Linux par l'outil est encore en préversion ; la page de documentation consultée ne mentionne pas macOS.

Si vous préparez aussi la bascule d'un autre antivirus, consultez notre article sur la migration sans risque entre Microsoft Defender et Intune.

Mise en œuvre : contrôler l'état d'intégration d'un poste Windows

Le portail confirme l'intégration côté cloud ; un contrôle local confirme que le capteur est bien en place sur l'appareil. Le script ci-dessous lit le service Sense (capteur Defender for Endpoint) et la valeur de registre OnboardingState. Ces deux éléments relèvent de l'expérience d'ingénierie courante et ne figurent pas dans les pages Microsoft Learn citées ici : validez-les sur un appareil pilote déjà visible dans le portail avant de généraliser.

• Module requis : aucun, PowerShell 5.1 ou supérieur suffit.
• Permission minimale : lecture locale ; pour interroger des machines distantes, un compte autorisé à utiliser Invoke-Command (WinRM) sur ces machines.
• Sortie : un objet par poste (service Sense, valeur OnboardingState, indicateur Onboarded), exportable en CSV. Le script est en lecture seule.

1[CmdletBinding()]
2param(
3    # Postes à contrôler ; par défaut, la machine locale
4    [string[]]$ComputerName = $env:COMPUTERNAME,
5    # Chemin d'export CSV facultatif
6    [string]$OutputPath
7)
8 
9# Bloc exécuté sur chaque poste : lecture seule
10$check = {
11    $statusKey = 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status'
12    $service   = Get-Service -Name 'Sense' -ErrorAction SilentlyContinue
13    $state     = Get-ItemProperty -Path $statusKey -Name 'OnboardingState' -ErrorAction SilentlyContinue
14 
15    [pscustomobject]@{
16        Poste           = $env:COMPUTERNAME
17        ServiceSense    = if ($service) { [string]$service.Status } else { 'Absent' }
18        OnboardingState = if ($state) { $state.OnboardingState } else { 'Non défini' }
19        Onboarded       = [bool]($state -and $state.OnboardingState -eq 1)
20    }
21}
22 
23# Exécution locale ou distante selon le paramètre
24if ($ComputerName.Count -eq 1 -and $ComputerName[0] -eq $env:COMPUTERNAME) {
25    $results = & $check
26}
27else {
28    $results = Invoke-Command -ComputerName $ComputerName -ScriptBlock $check |
29        Select-Object -Property Poste, ServiceSense, OnboardingState, Onboarded
30}
31 
32$results | Format-Table -AutoSize
33 
34# Export facultatif
35if ($OutputPath) {
36    $results | Export-Csv -Path $OutputPath -NoTypeInformation -Encoding UTF8
37    Write-Host ('Résultats exportés vers ' + $OutputPath)
38}

Un poste correctement intégré affiche un service Sense en cours d'exécution et Onboarded à True. Un service absent ou une valeur non définie indique que la stratégie ne s'est pas appliquée : retournez au tableau de dépannage. Avant un déploiement par outil de déploiement, DefenderDT.exe avec -Precheck joue un rôle de contrôle comparable, en amont.

Vérifier dans le portail Defender : délai et filtres

Le délai d'apparition d'un appareil nouvellement intégré est de 15 à 30 minutes selon la documentation Intune et Defender (5 à 20 minutes pour Linux). Passé ce délai, un appareil absent justifie une investigation, pas une attente de plusieurs heures.

Pour vérifier :

1. Ouvrez l'inventaire des appareils depuis le volet des ressources (Devices).
2. Ajoutez un filtre sur le statut d'intégration et choisissez « Onboarded ».
3. Côté Intune, suivez la progression dans l'onglet État d'intégration EDR.

Pour un déploiement de masse, la documentation d'intégration recommande une approche par anneaux : 50 appareils, puis 50 à 100, puis le reste du parc. C'est la manière la plus sûre de détecter un conflit de stratégie avant qu'il ne touche tout le monde. Notre guide exploiter les licences Microsoft Intune déjà acquises aide à vérifier ce que vos licences couvrent avant de planifier les anneaux.

Questions fréquentes

Faut-il passer par l'outil de déploiement Defender ou par Intune ?

Si vos appareils Windows sont déjà gérés par Intune, la stratégie EDR est cohérente avec votre chaîne d'administration. L'outil DefenderDT est une méthode distincte, qui ne s'intègre pas à l'intégration via Intune ; il convient aux appareils que Intune ne couvre pas ou aux scénarios comme le mode passif sur serveur.

Combien de temps faut-il pour qu'un appareil intégré apparaisse ?

La documentation Microsoft indique 15 à 30 minutes pour un appareil Windows, et 5 à 20 minutes pour Linux. Au-delà, vérifiez le connecteur, la connexion Intune côté Defender et d'éventuels conflits de stratégies.

Le script d'intégration local convient-il à la production ?

Non. Il est limité à 10 appareils et réservé aux évaluations. En production, privilégiez une stratégie EDR Intune, Configuration Manager ou l'outil de déploiement Defender.

Peut-on réutiliser un package d'intégration entre deux tenants ?

Non. Les packages de l'outil de déploiement sont propres à un locataire et ne doivent pas être réutilisés d'un locataire à l'autre.

Par où commencer : trois contrôles avant de déployer

Commencez par le connecteur : tant que la connexion Intune n'est pas active des deux côtés, aucune stratégie ne produira de résultat fiable. Puis déployez sur un anneau pilote et contrôlez le résultat dans le portail et avec le script local.

Si votre organisation gère un tenant Intune relié à un autre tenant Microsoft Entra ID que celui de Defender, alors passez par l'intégration manuelle avec le package téléchargé. Pour l'enrôlement des postes eux-mêmes, voir notre guide Intune et Windows 11 : enrôlement et configuration de A à Z, et pour une vue d'ensemble de la plateforme, Microsoft Defender : plateforme de sécurité complète pour administrateurs IT.

Pour aller plus loin

• Deploy Windows devices by using the Microsoft Defender deployment tool : paramètres, clé d'accès, expiration des packages et déploiement par GPO.
• Deploy endpoint detection and response policy with Intune : stratégies EDR, mode Auto from connector ou manuel, rapport d'état d'intégration.
• Configure Microsoft Defender for Endpoint with Intune and onboard devices : prérequis, rôles et étapes pour connecter Intune à Defender.
• Onboard devices to Microsoft Defender for Endpoint : parcours du portail et déploiement par anneaux.