Introduction : Un défi de performance en environnement Entra
L'intégration d'identités avec Microsoft Entra ID impose des contraintes architecturales très différentes de celles des environnements FIM/MIM traditionnels. Tandis que le Synchronization Service traite les modifications par lots, le service de provisioning outbound d'Entra dépêche chaque changement individuellement vers l'agent de provisioning local, créant une charge de travail fondamentalement opposée à celle des imports parallélisés.
Cette distinction explique pourquoi PowerShell 7, excellent pour les imports massifs (10k+ objets), devient contre-productif lors des exports avec l'ECMA Connector Host (ECMA2Host). La version 6.1.0604.2026 et ultérieures du connecteur PSMA Granfeldt introduisent une solution : un mécanisme de sélection du moteur PowerShell par connecteur.
Comprendre l'asymétrie des charges de travail : imports vs exports
Comportement dans FIM/MIM Synchronization Service
Dans les environnements FIM/MIM classiques, le moteur PowerShell démarre une seule fois au début d'une étape d'exécution et traite l'intégralité du lot. Le coût de démarrage du Common Language Runtime (CLR) est payé une seule fois, ce qui rend le choix du moteur presque indifférent sur le débit global.
Architecture événementielle d'Entra outbound provisioning
La situation diverge radicalement avec Microsoft Entra :
- Chaque modification (ajout, suppression, mise à jour d'utilisateur) génère un événement distinct
- L'agent de provisioning les transfère un par un à ECMA2Host
- ECMA2Host invoque le connecteur une fois par objet
- Un nouveau processus PowerShell enfant se crée pour chaque événement
Dans ce modèle, le coût de démarrage du processus domine le temps total par événement. PowerShell 7 (pwsh.exe) entraîne :
- Un démarrage complet de CoreCLR
- Initialisation de la runspace
- Découverte des modules
- Typiquement 9 à 11 secondes avant l'exécution du premier code métier
En contraste, Windows PowerShell 5.1 s'exécute in-process dans le service ECMA2Host sans démarrage CLR distinct, débutant en moins d'une seconde.
Risque de timeout critique
Microsoft Entra impose un délai d'expiration strict de 60 secondes par événement. Lorsque le temps par événement s'approche ou dépasse ce seuil, les événements retournent une erreur, quarantenant le connecteur même si l'application cible a effectivement traité les modifications. La combinaison "dispatch série + plafond de 60 secondes + démarrage à froid pwsh.exe" crée un risque élevé de faux positifs de timeout.
La solution : sélection du moteur PowerShell par export
Nouvelle case à cocher dans les paramètres globaux
Le connecteur PSMA expose désormais une option granulaire sur la page des paramètres globaux :
- Use Windows PowerShell 5.1 for Export
Si la version PowerShell du connecteur est définie sur PowerShell 7 (typiquement pour les fonctionnalités d'import parallèle) mais que le script d'export ne nécessite pas de fonctionnalités spécifiques à PS7, l'activation de cette case exécute l'export sous Windows PowerShell 5.1 à la place.
Points clés de cette implémentation
- Désactivée par défaut pour la compatibilité ascendante
- Contrôlable indépendamment par connecteur : chaque connecteur peut avoir sa propre configuration
- Gains mesurés en production : entre 1.3x et 3.5x plus rapide selon le workload, économisant 2 à 11 secondes par événement d'export
Mesurer votre propre performance : l'outil PSMA-Validation
Pourquoi une validation empirique ?
Les gains de performance dépendent fortement de :
- La logique spécifique de vos scripts d'export
- La latence réseau entre le serveur ECMA2Host et l'API cible
- Le workload par compte que vos scripts exécutent
- Le protocole d'intégration utilisé
Microsoft a publié un outil complémentaire pour éliminer les suppositions : PSMA-Validation.
Installation et utilisation de PSMA-Validation
L'outil se présente sous forme d'un module PowerShell unique à déployer sur le serveur ECMA2Host et à intégrer dans votre script export.ps1 existant.
Intégrer le module dans les phases Begin/Process/End
Ajoutez trois lignes dans votre script export.ps1 :
1Begin {2 . 'C:\ProgramData\PsmaValidation\PSMA-Validation.ps1'3 Write-PsmaProbe -Phase Begin4 5 # ...votre code Begin existant...6}7 8Process {9 Write-PsmaProbe -Phase Process -Identifier $identifier10 11 # ...votre code Process existant...12}13 14End {15 Write-PsmaProbe -Phase End16 17 # ...votre code End existant...18}Capturer des données sur les deux moteurs
Le module enregistre un JSON par phase dans C:\ProgramData\PsmaValidation\probe.jsonl. Capturez trente minutes de cycles sous PowerShell 7, puis la même charge de travail sous Windows PowerShell 5.1.
Analyser les résultats
Exécutez l'analyseur :
1. 'C:\ProgramData\PsmaValidation\PSMA-Validation.ps1'2Get-PsmaProbeSummaryVous obtenez une décomposition par cycle :
- Temps de spawn du processus
- Temps actif du script
- Écart inter-cycles (surcharge ECMA2Host architecturale)
- Un verdict final recommandant ou non l'activation du switch moteur
Nettoyer après validation
Une fois votre décision prise, supprimez les trois appels Write-PsmaProbe. Aucun autre nettoyage nécessaire.
Caractéristiques de PSMA-Validation
La sonde est non-intrusive, append-only, impose un surcoût de 5–20 ms par invocation, thread-safe cross-process, et ses défaillances sont silencieuses : un échec d'écriture de journal ne casse jamais un export.
Adapter votre script à Windows PowerShell 5.1
Compatibilité descendante : la plupart des scripts fonctionnent sans modification
La majorité des scripts d'export écrits pour PowerShell 7 s'exécutent sans changement sous Windows PowerShell 5.1. Seules exceptions : un petit ensemble de constructeurs et comportements spécifiques à PS7 nécessitant une adaptation.
Constructions PowerShell 7 à remplacer
| Construit PowerShell 7 | Remplacement compatible 5.1 et 7 | Notes |
|---|---|---|
| Opérateur null-coalescing (??) | Chaîne if/elseif/else explicite | Le remplacement fonctionne sur les deux versions |
| try { } catch { } comme expression RHS | try comme instruction indépendante | Séparation de la logique |
| Caractères non-ASCII en single-quoted strings (→, —, guillemets intelligents) | Équivalents ASCII (->; --; ', ") | Évite les encodages variables |
| ConvertFrom-Json retournant Double (PS7) vs Decimal (5.1) | Cast explicite [string][int64] au point d'entrée | Normalise le type de donnée |
| Add-Type avec blocs C# référençant System.Net.Http | Paramètre explicite -ReferencedAssemblies 'System.Net.Http' | Charge spécifiée |
| Invoke-WebRequest défaut IE COM (échoue NetworkService sur 5.1) | Ajouter -UseBasicParsing (no-op sur PS7) | Assure la compatibilité de compte |
Bon à savoir
Chacun de ces remplacements reste bénin sur PowerShell 7 : le code remplacé continue à fonctionner sur PS7. Un script export mis à jour pour la compatibilité 5.1 reste drop-in compatible avec le chemin PS7. Vous pouvez basculer la case sans réécriture.
Stratégie de migration progressive
Si un script de connecteur ne peut pas être mis à jour immédiatement, laissez simplement la case décochée. Le connecteur continuera à exécuter les exports sous PowerShell 7 exactement comme avant. Cette flexibilité permet une transition progressive par connecteur, sans blocage global.
Déploiement et configuration
Versioning et distribution
La fonctionnalité est disponible dans la version d'assembly 6.1.0604.2026 et ultérieures du PSMA Granfeldt. Comme pour la prise en charge PS7 des imports, la DLL est partagée entre tous les connecteurs sur un serveur ECMA2Host donné :
- Un seul déploiement par serveur ECMA2Host
- Activation par connecteur selon les besoins
Ressources de téléchargement
- Code source et binaires compilés : Repository GitHub Granfeldt PSMA
- Outil de validation compagnon : github.com/darrenjrobinson/PSMA-Validation
Bonnes pratiques de déploiement
Testez d'abord l'outil PSMA-Validation sur un connecteur non-critique pour valider les gains avant d'activer la case à cocher en production. Documentez vos résultats et réutilisez les valeurs pour les connecteurs similaires.
Résumé des bénéfices
Cette enhancement du connecteur PSMA Granfeldt répond directement aux contraintes architecturales de Microsoft Entra provisioning :
- Élimine les cold-starts inutiles de pwsh.exe lors des exports en série
- Réduit le risque de timeout critique (60 secondes) en production
- Maintient PowerShell 7 pour les imports parallèles haute performance
- Fournit l'instrumentation nécessaire (PSMA-Validation) pour décider empiriquement
- Offre une granularité par connecteur : adapter chaque intégration à son workload spécifique
Pour les environnements Entra outbound provisioning importants, le passage ciblé des exports à Windows PowerShell 5.1 représente un gain mesurable en latence, en fiabilité et en résilience face aux timeouts.
