Importer le module ActiveDirectory PowerShell hors‑ligne : guide complet étape par étape

Déplacer un serveur hors réseau ne doit plus empêcher l’administration d’Active Directory. Ce guide pas à pas explique comment recopier et importer hors‑ligne le module ActiveDirectory PowerShell sans dépendre d’Internet ni de Windows Update, en évitant l’erreur « The system can’t find the file specified ». Toutes les commandes proposées sont éprouvées en production.

Sommaire

Pourquoi le module ActiveDirectory est indispensable

Le module ActiveDirectory (Microsoft.ActiveDirectory.Management) est la brique qui donne accès aux cmdlets Get‑ADUser, New‑ADGroup, Move‑ADObject, etc. Il s’installe traditionnellement via le rôle AD DS ou via RSAT. Dans un environnement isolé (laboratoire sécurisé, maquette hors production, DMZ, réseau classifié), ces méthodes ne sont pas toujours disponibles :

pas d’accès aux dépôts Windows (Windows Update, WSUS) ;
ISO d’installation introuvable ou absent ;
politique de changement de configuration du système très restrictive.

Copier le module manuellement est alors la solution la plus rapide — à condition de ne pas oublier un fichier.

Étape 1 : identifier et collecter le module sur le contrôleur de domaine

1.1 Localiser le dossier exact

Sur le DC source, ouvrez une fenêtre PowerShell (Run as administrator) et recherchez la localisation précise :

$mod = Get-Module -ListAvailable ActiveDirectory
$mod | Select-Object Name,Version,ModuleBase

Dans la majorité des cas, la variable $mod.ModuleBase pointe vers :

%SystemRoot%\System32\WindowsPowerShell\v1.0\Modules\ActiveDirectory\

1.2 Que contient le répertoire ?

Le dossier comporte systématiquement :

Fichier	Rôle
`Microsoft.ActiveDirectory.Management.dll`	Bibliothèque principale : implémente toutes les cmdlets.
`Microsoft.ActiveDirectory.Management.resources.dll`	Ressources localisées (messages d’erreur, aide).
`ActiveDirectory.psd1`	Manifeste : déclare l’export des fonctions et la version.
`ActiveDirectory.psm1`	Script d’initialisation du module.
Fichiers d’aide (.maml, .xml)	Aide intégrée à `Get‑Help`.

Important : copier uniquement les DLL n’est pas suffisant ; le manifeste et le script sont indispensables pour que le chargement dynamique fonctionne.

1.3 Exporter le contenu en toute sécurité

Privilégiez un outil qui préserve les attributs NTFS :

robocopy "$mod.ModuleBase" "D:\Export\ActiveDirectory" /MIR /Z /COPY:DAT

Vous pouvez aussi générer une archive compressée si le support d’échange est limité :

Compress-Archive -Path "D:\Export\ActiveDirectory\*" -DestinationPath "D:\Export\ActiveDirectory.zip"

Étape 2 : préparer le serveur cible

2.1 Vérifier la version de .NET Framework

Le module s’appuie sur .NET. Sur la cible, exécutez :

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" |
  Get-ItemProperty -Name Release |
  Select-Object -ExpandProperty Release

Comparez la release avec la table officielle Microsoft ; assurez‑vous qu’elle est ≥ celle du DC source.

2.2 Choisir le répertoire d’installation

PowerShell recherche les modules selon la variable d’environnement PSModulePath. Par défaut :

Système	Chemin système (pour tous)	Chemin utilisateur
Windows Server 2016 ⇢ 2025	`%SystemRoot%\System32\WindowsPowerShell\v1.0\Modules\`	`%UserProfile%\Documents\WindowsPowerShell\Modules\`
Windows 10/11	`%ProgramFiles%\WindowsPowerShell\Modules\`	`%UserProfile%\Documents\WindowsPowerShell\Modules\`
PowerShell 7+	`$Env:ProgramFiles\PowerShell\Modules\`	`$Env:USERPROFILE\.local\powershell\Modules\`

2.3 Déposer le module

Copiez le dossier ActiveDirectory ou extrayez l’archive dans l’un de ces emplacements. Pour un répertoire personnalisé :

$custom = "D:\Modules"
$env:PSModulePath = "$($env:PSModulePath);$custom"

Vous pouvez automatiser ce réglage avec [Environment]::SetEnvironmentVariable() afin qu’il persiste entre les sessions.

Étape 3 : importer et tester

Lancez PowerShell en administrateur.
Vérifiez la détection :
Get‑Module ‑ListAvailable ActiveDirectory
Chargez le module :
Import‑Module ActiveDirectory
Validez un appel concret :
Get‑ADDomain | Format‑List Forest,DomainMode

Si le module se charge sans erreur, la majorité des cmdlets AD sont immédiatement utilisables, même si le serveur n’est pas membre du domaine ; il suffit que le port LDAP/TCP 389 soit joignable ou que vous utilisiez le paramètre -Server.

Étape 4 : dépannage détaillé

Symptôme	Cause probable	Correctif
`Import‑Module : file not found`	Fichiers manquants ou nom de dossier incorrect.	Recopier intégralement le dossier, vérifier l’orthographe du dossier (ActiveDirectory).
`Import‑Module : bad image`	Version .NET insuffisante ou plateforme x86 vs x64.	Mettre à jour .NET Framework ou copier le module depuis un système de même architecture.
`Scripts are disabled`	Policy ExecutionPolicy restrictive.	`Set‑ExecutionPolicy RemoteSigned ‑Scope Process`
`Operation is not legal in the current state of the object`	Fichiers bloqués (zone Internet).	`Get‑ChildItem ‑Recurse \| Unblock‑File`

Étape 5 : alternatives hors‑ligne RSAT/Feature

5.1 Server Core ou système avec accès ISO

Install‑WindowsFeature&nbsp;RSAT‑AD‑PowerShell&nbsp;‑Source&nbsp;D:\Sources\SxS

Le paramètre -Source pointe vers le dossier SxS de l’ISO Windows Server correspondant.

5.2 Client Windows (10, 11)

Depuis une invite cmd élevée :

dism /online /add-capability `
     /capabilityname:Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 `
     /source:D:\Sources\SxS /LimitAccess

LimitAccess garantit qu’aucune source externe n’est contactée.

Étape 6 : automatiser le déploiement dans un environnement fermé

Pour des dizaines de machines, la copie manuelle n’est plus viable. Le script suivant :

param(
    [string]$Repo = "\\SrvDepot\PSModules",
    [string]$TargetPath = "$Env:ProgramFiles\WindowsPowerShell\Modules"
)

\$adPath = Join-Path \$Repo "ActiveDirectory"
if (-not (Test-Path \$adPath)) {
Write-Error "Dépôt absent : \$adPath"
exit 1
}

Copy-Item -Path \$adPath -Destination \$TargetPath -Recurse -Force
Write-Host "Module ActiveDirectory installé dans \$TargetPath"
Import-Module ActiveDirectory
Write-Host "Version :" (Get-Module ActiveDirectory).Version

Ce script peut être poussé via GPO Startup Script, SCCM, ou un simple Scheduled Task.

Bonnes pratiques de sécurité et de maintenance

Signer vos modules : utilisez Set‑AuthenticodeSignature avec un certificat interne afin que la politique AllSigned reste applicable.
Versionner : conservez chaque version de ActiveDirectory dans un dépôt Git ou un partage daté (\\SrvDepot\PSModules\2025‑08‑31). Vous pourrez revenir en arrière si un patch Microsoft modifie la DLL.
Contrôler l’intégrité : stockez le hash SHA‑256 du dossier (commande Get‑FileHash) pour repérer toute corruption ou altération.
Limiter les droits NTFS : donnez lecture au groupe Domain Admins uniquement ; empêchez les comptes non privilégiés de modifier les scripts.

Foire aux questions

• Puis‑je importer le module sur un serveur hors domaine ?
Oui. Les cmdlets utilisent LDAP ou RPC vers un DC spécifié via ‑Server; seule l’authentification Kerberos ou NTLM doit être négociée.

• PowerShell 7 est‑il compatible ?
À ce jour, le module repose sur les cmdlets Windows PowerShell (v5.1). Sous PS 7, chargez‑le via Import‑Module ‑UseWindowsPowerShell.

• Quelle différence avec le module System.DirectoryServices ?
System.DirectoryServices est un namespace .NET pour le scripting C#. ActiveDirectory fournit des cmdlets natives et plus simples.

Conclusion

En isolant proprement le dossier ActiveDirectory et en respectant la structure attendue par PowerShell, vous pouvez administrer votre annuaire même dans les réseaux les plus fermés. Cette approche évite l’installation de rôles supplémentaires, réduit l’empreinte de sécurité et garantit la portabilité de vos scripts.

Importer le module ActiveDirectory PowerShell hors‑ligne : guide complet étape par étape