Business Digital

Joindre des postes Windows 11 au domaine et déploiement automatisé pas à pas

12 min de lecture

Joindre un poste Windows 11 au domaine est l’instant où l’infrastructure prouve sa valeur pour la première fois côté utilisateur. Le poste reçoit son nom dans l’annuaire, hérite des GPO, applique les politiques de sécurité, et l’utilisateur ouvre sa session avec son compte de domaine. Tout ce qui a été préparé en amont — DNS, DHCP, OU — converge dans ce geste, et un poste mal préparé révèle immédiatement les failles de configuration en amont.

Ce tutoriel pose une méthode reproductible : prérequis Windows 11, configuration réseau, jonction au domaine en GUI puis en PowerShell, déplacement automatique du poste dans la bonne OU, et automatisation du déploiement pour 50 postes ou plus avec Sysprep et scripts. À la fin, vous disposez d’un protocole complet pour intégrer un poste neuf en 15 minutes ou industrialiser le déploiement.

Prérequis recommandé : arborescence OU en place, DNS opérationnel, DHCP qui distribue les bons DNS. Panorama : Windows Server 2025 et Active Directory pour PME.

Prérequis

  • Un poste Windows 11 Pro, Education ou Enterprise. Windows 11 Home ne peut pas rejoindre un domaine — c’est une limitation matérielle de la licence.
  • Le poste sur le même LAN que les DC, avec accès réseau aux ports SMB 445, LDAP 389, Kerberos 88, RPC dynamique.
  • Un compte ayant le droit de joindre des postes au domaine. Par défaut, n’importe quel utilisateur peut joindre jusqu’à 10 postes (limite ms-DS-MachineAccountQuota). Idéalement, un compte dédié svc-join avec délégation sur l’OU Postes.
  • Le nom NetBIOS futur du poste arbitré : PC-001, NB-MARIE, suivant la convention.
  • Niveau attendu : intermédiaire pour la partie GUI, avancé pour l’automatisation.
  • Temps estimé : 15 minutes par poste manuel, 30 minutes de mise en place pour l’automatisation.

Étape 1 — Préparer le poste Windows 11

Avant toute jonction, le poste doit être propre. Sortie d’usine ou ré-image préinstallée, on désactive le compte Microsoft de l’OOBE et on prépare un compte administrateur local provisoire :

  • Sur Windows 11 23H2 et antérieures : Shift+F10 pendant l’OOBE, taper oobe\bypassnro, Entrée, choisir « Je n’ai pas Internet ».
  • Sur Windows 11 24H2 / 25H2 : Microsoft a retiré bypassnro.cmd à partir de la build 26200.5516. Le contournement temporaire start ms-cxh:localonly a également été bloqué dans plusieurs builds récentes. La méthode la plus fiable en 2026 consiste à préparer le média d’installation avec Rufus 4.5 ou supérieur : la case « Remove requirement for an online Microsoft account » dans l’écran personnalisation crée automatiquement un compte local et désactive les exigences réseau pendant l’OOBE.
  • Une fois le compte local créé (nom tempadmin), compléter l’installation et refuser les services Microsoft optionnels (OneDrive, Cortana suggestions, etc.).

Une fois le bureau accessible, appliquer toutes les mises à jour Windows et désactiver la mise en veille pour ne pas être coupé pendant l’installation. Le poste doit être à jour avant la jonction ; un Windows 11 sorti d’usine peut être en build 22H2 alors que le DC attend du 24H2 — la compatibilité Kerberos reste mais certaines GPO modernes échoueront.

Étape 2 — Configurer le réseau et tester la résolution

Sur le LAN d’entreprise, le poste reçoit sa configuration via DHCP. Vérifier que les DC apparaissent comme DNS :

ipconfig /all
nslookup ad.entreprise.com

Les serveurs DNS doivent être 10.10.0.10 et 10.10.0.11. nslookup doit renvoyer les IP des DC. Si la résolution échoue, le poste ne pourra pas trouver le DC pour la jonction — recheck DHCP, vlan, câblage.

Tester ensuite la connectivité Kerberos :

Test-NetConnection -ComputerName dc01.ad.entreprise.com -Port 88
Test-NetConnection -ComputerName dc01.ad.entreprise.com -Port 389

Les deux tests doivent renvoyer TcpTestSucceeded: True. Sinon : pare-feu intermédiaire, segmentation VLAN.

Étape 3 — Renommer le poste avant jonction

Renommer le poste avant la jonction permet de garder le compte ordinateur AD avec le bon nom dès la première synchronisation. Renommer après jonction est possible mais oblige à mettre à jour le compte machine et à régénérer le secret Kerberos.

Rename-Computer -NewName 'PC-MARIE' -Force -Restart

Respecter le format NetBIOS : maximum 15 caractères, ASCII, sans espaces. Après redémarrage, vérifier avec hostname.

Étape 4 — Joindre le poste au domaine en GUI

La méthode classique fonctionne et reste recommandée pour 1 à 5 postes :

  • Win+R, taper sysdm.cpl, Entrée.
  • Cliquer Modifier, choisir Membre d’un domaine, saisir ad.entreprise.com.
  • Le système demande un compte autorisé : svc-join@ad.entreprise.com et son mot de passe.
  • Au bout de 30 secondes, message de bienvenue dans le domaine, redémarrage requis.

Au redémarrage, l’écran de connexion permet désormais d’ouvrir une session avec un compte du domaine : marie.dupont avec son mot de passe AD.

Étape 5 — Joindre le poste au domaine en PowerShell

Pour un déploiement plus reproductible, on utilise Add-Computer. Le cmdlet accepte un objet PSCredential pour le compte de jonction, l’OU cible directement, et même le renommage en une seule opération :

$cred = Get-Credential
Add-Computer -DomainName 'ad.entreprise.com' `
  -NewName 'PC-MARIE' `
  -OUPath 'OU=Bureaux,OU=Postes,DC=ad,DC=entreprise,DC=com' `
  -Credential $cred `
  -Restart -Force

Le paramètre -OUPath place directement le compte ordinateur dans la bonne OU — fini les déplacements manuels dans ADUC. -Restart -Force redémarre automatiquement après jonction. Le poste est désormais entièrement intégré.

Étape 6 — Vérifier la jonction côté serveur et côté poste

Côté DC, le compte ordinateur doit apparaître dans la bonne OU :

Get-ADComputer -Identity 'PC-MARIE' -Properties * |
  Select-Object Name, DistinguishedName, Enabled, OperatingSystem, LastLogonDate

Le DistinguishedName doit pointer dans OU=Bureaux,OU=Postes,…. Enabled à True. L’OS à Windows 11 Pro.

Côté poste, ouvrir une session avec un compte de domaine et vérifier :

whoami /fqdn
gpresult /R /SCOPE COMPUTER
klist tickets

whoami /fqdn retourne le distinguishedName du compte utilisateur. gpresult liste les GPO appliquées. klist tickets liste les tickets Kerberos émis pour la session — au minimum un TGT pour le compte utilisateur et un service ticket pour le DC.

Aparté — Le secret machine et le canal sécurisé

Quand un poste rejoint un domaine, AD lui attribue un compte ordinateur (visible dans ADUC avec un nom terminé par $) et lui associe un secret partagé — fondamentalement, un mot de passe. Ce secret est utilisé en permanence pour établir un canal sécurisé entre le poste et un DC, qui permet ensuite de relayer les authentifications Kerberos des utilisateurs, d’appliquer les GPO, de synchroniser les politiques de sécurité.

Par défaut, ce secret est renouvelé tous les 30 jours automatiquement par le service Netlogon du poste. Si le poste reste éteint plus de 30 jours et que la fenêtre de tolérance (60 jours) est dépassée, le secret stocké côté poste ne correspond plus à celui d’AD. Symptôme : message The trust relationship between this workstation and the primary domain failed à l’ouverture de session.

La réparation est désormais simple en PowerShell : Test-ComputerSecureChannel -Repair -Credential (Get-Credential) régénère le secret côté AD avec un compte habilité, sans avoir à désinscrire/réinscrire le poste. L’ancienne méthode (retirer du domaine, redémarrer, rejoindre) reste fonctionnelle mais coûte 30 minutes alors que la nouvelle prend 30 secondes.

Étape 7 — Configurer la jonction hybride avec Entra ID (optionnel)

Si l’entreprise utilise Microsoft 365 et veut bénéficier du SSO sur les services cloud, on configure la Hybrid Join. Le poste apparaît alors à la fois dans AD on-prem et dans Entra ID. Le mécanisme repose sur la synchronisation des comptes par Entra ID Connect et sur une tâche planifiée locale qui inscrit le poste auprès d’Entra.

Étapes minimales (Entra Connect déjà installé sur un DC ou serveur tiers) :

  • Dans Entra Connect, activer Hybrid Azure AD join.
  • Configurer le SCP (Service Connection Point) dans AD via AzureADKerberos pour que les postes trouvent leur tenant Entra.
  • Forcer la jonction Entra sur le poste : dsregcmd /join.
  • Vérifier 10 minutes plus tard : dsregcmd /statusAzureAdJoined: YES et DomainJoined: YES.

Le poste peut ensuite ouvrir Outlook ou Teams sans saisir le mot de passe Microsoft 365 : le SSO s’opère via le ticket Kerberos AD.

Étape 8 — Automatiser le déploiement avec Sysprep

Pour 50 postes ou plus, on prépare une image golden qui sert de référence. Sur un poste pilote, on installe Windows 11, on applique les configurations standards (apps métier, désactivation de fonctionnalités, etc.), puis on lance Sysprep pour généraliser le poste :

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown

Sysprep efface l’identité du poste (SID, nom, jonction de domaine si présente) et arrête la machine. On en extrait alors une image WIM via dism :

dism /Capture-Image /ImageFile:D:\images\win11-golden.wim `
  /CaptureDir:C:\ /Name:'Win11-Golden-2026-05'

Cette image se déploie ensuite via MDT (Microsoft Deployment Toolkit), Configuration Manager, ou par clé USB préparée avec diskpart. Au premier boot du poste cible, Sysprep régénère un SID unique et applique l’unattend.xml qui contient les réponses pré-remplies (clé produit, fuseau horaire, jonction au domaine, OU cible).

Étape 9 — Préparer un unattend.xml de jonction automatique

L’unattend.xml est le fichier que Sysprep consomme au premier boot pour configurer le poste sans interaction. La section critique pour la jonction au domaine :

<component name="Microsoft-Windows-UnattendedJoin">
  <Identification>
    <Credentials>
      <Domain>ad.entreprise.com</Domain>
      <Username>svc-join</Username>
      <Password>MotDePasseSvcJoin</Password>
    </Credentials>
    <JoinDomain>ad.entreprise.com</JoinDomain>
    <MachineObjectOU>OU=Bureaux,OU=Postes,DC=ad,DC=entreprise,DC=com</MachineObjectOU>
  </Identification>
</component>

Le fichier complet inclut la clé produit, le fuseau horaire, la langue, et le compte administrateur local par défaut. Microsoft propose l’outil graphique Windows System Image Manager pour générer cet XML correctement (les balises sont sensibles à la casse et à l’ordre).

Stocker le mot de passe svc-join en clair dans un XML n’est pas idéal — on chiffre la valeur via cipher /e et on délimite l’accès au compte svc-join à la seule jonction (refus de logon interactif via GPO sur l’OU).

Étape 10 — Alternative légère : provisionnement par script PowerShell

Pour les PME qui n’ont pas l’envie d’apprendre MDT ou Configuration Manager, une alternative pragmatique consiste à packager toute la post-installation dans un seul script PowerShell. Le poste est installé manuellement depuis l’ISO Windows 11, on ouvre une console admin, on exécute le script, et 10 minutes plus tard le poste est intégré.

# post-install.ps1 - exécuter en admin sur poste neuf
param([string]$NewName, [string]$User, [string]$OU)

# Mise à jour Windows
Install-Module -Name PSWindowsUpdate -Force -SkipPublisherCheck
Import-Module PSWindowsUpdate
Install-WindowsUpdate -AcceptAll -IgnoreReboot

# Nettoyage Modern Apps inutiles
$apps = 'Microsoft.YourPhone','Microsoft.GetHelp','Microsoft.MicrosoftSolitaireCollection'
foreach ($a in $apps) {
  Get-AppxPackage -Name $a -AllUsers | Remove-AppxPackage -ErrorAction SilentlyContinue
}

# Jonction au domaine
$cred = Get-Credential -UserName $User -Message 'Compte de jonction'
Add-Computer -DomainName 'ad.entreprise.com' `
  -NewName $NewName -OUPath $OU -Credential $cred -Restart -Force

Le script se lance ainsi : .\post-install.ps1 -NewName 'PC-MARIE' -User 'svc-join@ad.entreprise.com' -OU 'OU=Bureaux,OU=Postes,DC=ad,DC=entreprise,DC=com'. L’avantage : c’est traçable, versionnable dans Git, modifiable en deux minutes. Pour 50 postes, c’est largement suffisant. Pour 500, MDT s’impose. La maintenance d’un tel script est triviale : on ajoute une politique de mot de passe ici, une désactivation de service Windows obsolète là, on l’archive sur un partage interne, et chaque technicien reproduit la même installation propre sur n’importe quel poste neuf. L’ennemi de la cohérence en PME, c’est la dérive lente entre 50 postes installés par 5 techniciens différents sur 18 mois — un script unique élimine cette dérive en imposant une recette commune.

Étape 11 — Tester la chaîne complète sur un poste pilote

Avant de déployer 50 postes, valider la chaîne :

  • Booter un poste neuf sur la clé USB d’image.
  • Vérifier que l’installation Windows se déroule sans questions.
  • Au reboot, le poste se renomme automatiquement et joint le domaine.
  • Le compte ordinateur apparaît dans la bonne OU dans ADUC.
  • Les GPO s’appliquent dès la première ouverture de session.
  • L’utilisateur peut ouvrir sa session AD sans intervention IT.

Si l’une de ces étapes échoue, corriger l’unattend.xml ou les permissions du compte de jonction avant de continuer.

Erreurs fréquentes

Symptôme Cause Solution
Erreur The specified domain either does not exist DNS ne résout pas le domaine, poste sur mauvais DNS Vérifier ipconfig /all, corriger DHCP, tester nslookup ad.entreprise.com.
Erreur The user account is locked out pour svc-join 10 tentatives ratées, GPO de verrouillage active Déverrouiller le compte côté DC, vérifier que le mot de passe est correct dans l’XML.
Le poste joint mais n’apparaît pas dans l’OU souhaitée -OUPath ignoré ou délégation incomplète Vérifier les droits CreateChild sur l’OU pour le compte de jonction, tester via PowerShell direct.
Trust relationship between this workstation and the primary domain failed Secret machine désynchronisé, poste resté hors-ligne plus de 30 jours Sur le poste : Test-ComputerSecureChannel -Repair -Credential (Get-Credential).
Sysprep refuse de s’exécuter Apps Modern Windows installées (Edge, Store apps) cassent Sysprep Retirer les apps avec Get-AppxPackage | Remove-AppxPackage avant Sysprep.

Vérification finale

Vous avez maintenant une méthode robuste pour intégrer des postes Windows 11 au domaine, manuellement pour les cas isolés et industriellement avec Sysprep + unattend pour les déploiements de masse. Chaque poste atterrit dans la bonne OU, hérite des GPO immédiatement, et l’utilisateur n’a qu’à se connecter avec son compte AD.

La suite logique : poser les GPO essentielles pour PME qui s’appliqueront à ces postes. Pour la sécurité du poste : Durcissement Windows : GPO, BitLocker, Defender, AppLocker et LAPS. Panorama : Windows Server 2025 et Active Directory pour PME.

Ressources officielles

Partager