Activer Client‑ProjFS sur Windows Server 2019 pour Visual Studio 2022 : corriger l’erreur 14081 (DISM/WSUS/WinSxS)

Sur Windows Server 2019, l’activation de Client‑ProjFS peut échouer avec l’erreur 14081. Voici une procédure éprouvée pour diagnostiquer, réparer le magasin de composants et installer proprement la fonctionnalité requise par certains composants de Visual Studio 2022.

Sommaire

Vue d’ensemble de la question

Sur plusieurs hôtes Windows Server 2019, l’activation de la fonctionnalité facultative Client‑ProjFS échoue aussi bien par l’interface que via PowerShell/DISM, en affichant :

Enable-Feature / FeatureName:Client-ProjFS
Error: 14081 — The referenced assembly could not be found.

La fonctionnalité n’apparaît parfois même pas dans l’assistant Ajouter des rôles et des fonctionnalités. Faut‑il/peut‑on l’activer sur Server 2019 ? Oui — et l’échec indique presque toujours une incohérence ou un appauvrissement du magasin de composants (WinSxS) de l’image Windows, typique des images d’entreprise nettoyées de manière trop agressive (suppression des Features on Demand, désalignement des correctifs SSU/LCU, restrictions WSUS, etc.).

Réponse & solution — en bref

Oui, Client‑ProjFS existe et fonctionne sur Windows Server 2019.
Si l’activation échoue ou si la fonctionnalité n’est pas listée, cela signale quasi systématiquement un magasin de composants manquant/corrompu ou une image dont la charge utile FoD a été supprimée.
Sur une installation propre (ISO Server 2019 récent, VM Hyper‑V par défaut), Client‑ProjFS s’installe sans difficulté. Le problème vient donc de l’image de base utilisée pour déployer les serveurs affectés.

Ce que signifie l’erreur 14081

14081 — The referenced assembly could not be found : DISM ne trouve pas les assemblies requis dans le magasin de composants et n’est pas autorisé (ou ne parvient pas) à télécharger/obtenir la charge utile depuis une source valide (Windows Update, partage SxS, ISO aligné, etc.). En environnement géré, WSUS et une stratégie GPO mal configurée empêchent souvent l’accès direct aux sources de réparation.

Procédure recommandée (du plus simple au plus radical)

Vérifications rapides

Commencez par vérifier la présence de la fonctionnalité et l’état du magasin :

dism /online /Get-Features /Format:Table | findstr /I projf
dism /online /Cleanup-Image /AnalyzeComponentStore

La fonctionnalité apparaît (par ex. Client-ProjFS | Disabled) ? Passez à la tentative d’activation standard.
Elle n’apparaît pas ? L’image est probablement appauvrie ou désalignée : allez directement à l’activation avec une source correspondante (ISO) ou à la réparation sur place.

Tentative standard d’activation

Exécutez un contrôle d’intégrité suivi d’une activation classique :

sfc /scannow
dism /online /Cleanup-Image /RestoreHealth
dism /online /Enable-Feature /FeatureName:Client-ProjFS /All /NoRestart

Redémarrez si demandé, puis réessayez l’activation si nécessaire.

Activation avec une source d’installation correspondante

Indispensable si les charges utiles FoD ont été supprimées ou si WSUS bloque le contenu de réparation.

Montez un ISO Windows Server 2019 de même édition, langue et build que la machine.
Activez en pointant vers la source SxS (supposons que l’ISO est monté en D:) :

dism /online /Enable-Feature /FeatureName:Client-ProjFS /All ^
     /Source:D:\sources\sxs /LimitAccess

Si RestoreHealth échoue, réparez le magasin de composants à partir de l’ISO :

dism /Get-WimInfo /WimFile:D:\sources\install.wim
dism /online /Cleanup-Image /RestoreHealth ^
     /Source:wim:D:\sources\install.wim:&lt;IndexCorrespondant&gt; /LimitAccess

Re-tentez ensuite l’activation.

Astuce environnement géré (WSUS/GPO) : vérifiez la stratégie Spécifier les paramètres d’installation des composants facultatifs et de réparation et autorisez, si besoin, le contact direct avec Windows Update, tout en conservant WSUS pour le reste. Cela débloque le téléchargement des charges utiles manquantes.

Réparation sur place (in‑place upgrade)

Lorsque la corruption est trop avancée ou si plusieurs serveurs sont déjà en production, exécutez une mise à niveau de réparation depuis un ISO Server 2019 adéquat (même édition/langue). Cette opération restaure WinSxS et les charges utiles des fonctionnalités sans perte d’applications ni de données (effectuez quand même une sauvegarde). Après la réparation, relancez l’activation.

Après correction — contrôles

Vérifiez l’état du pilote et de la fonctionnalité :

sc query prjflt
dism /online /Get-Features /Format:Table | findstr /I projf

Remarque : selon les builds, le service du mini‑filtre ProjFS peut apparaître sous prjflt. Si vous aviez utilisé sc query projfs et obtenu « service introuvable », essayez sc query prjflt.

Tableau de diagnostic — symptômes, causes, remèdes

Symptôme	Indice concret	Cause la plus probable	Action immédiate
Client‑ProjFS absent de la liste	`dism /Get-Features` ne retourne rien contenant « projf »	Image appauvrie (FoD supprimées) ou magasin WinSxS incomplet	Activer via ISO SxS (`/Source`), sinon réparation sur place
Erreur 14081 à l’activation	« The referenced assembly could not be found »	Payload manquant, WSUS/GPO bloque la source de réparation	Configurer la GPO « composants facultatifs », relancer avec `/Source` et `/LimitAccess`
`RestoreHealth` échoue	DISM : échec de réparation, erreur SxS	Magasin sévèrement corrompu ou source non alignée (édition/langue/build)	Utiliser `install.wim` aligné + index correct, sinon in‑place upgrade
Fonctionnalité s’installe mais Visual Studio échoue	VS 2022 signale un prérequis ProjFS	Absence de redémarrage, service mini‑filtre non chargé	Redémarrer, vérifier `sc query prjflt`, relancer le setup VS

Scénarios concrets & interprétation des journaux

Journaux à consulter

C:\Windows\Logs\DISM\dism.log : détails des opérations DISM, notamment les sources utilisées et les erreurs SxS.
C:\Windows\Logs\CBS\CBS.log : composant servicing, erreurs d’assemblies manquants.
Observateur d’événements → Applications and Services Logs → Microsoft → Windows → Servicing.

Recherchez les mentions de payload removal, Cannot find source, Package_* et les GUID de fonctionnalités. Si vous voyez des références à un Alternate Repair Source non joignable, forcez la source locale (ISO) avec /Source + /LimitAccess.

Éditions, langues et builds : l’alignement est critique

Édition : gardez Standard ↔ Standard, Datacenter ↔ Datacenter.
Langue : ISO identique à la langue installée (évite les erreurs de correspondance d’assemblies).
Build : une source un peu plus récente fonctionne souvent, mais évitez les grands écarts (préférez un ISO slipstreamé aligné sur votre LCU).

Activation avec PowerShell (alternative à DISM)

Sur Windows Server 2019, vous pouvez aussi utiliser les cmdlets DISM exposées en PowerShell :

# Vérifier la fonctionnalité
Get-WindowsOptionalFeature -Online -FeatureName Client-ProjFS

# Activer (équivalent de DISM /Enable-Feature)

Enable-WindowsOptionalFeature -Online -FeatureName Client-ProjFS -All -NoRestart

Avec une source SxS montée (D:\), utilisez :

Enable-WindowsOptionalFeature -Online -FeatureName Client-ProjFS -All `
  -Source D:\sources\sxs -LimitAccess

Automatiser sur plusieurs serveurs

Exemple de script pour auditer et corriger un parc (exécuter depuis une station d’admin avec droits d’exécution à distance) :

$Servers = @("SRV-A","SRV-B","SRV-C")
$Source  = "D:\sources\sxs" # Monter l'ISO à la même lettre sur chaque hôte ou partager via UNC

Invoke-Command -ComputerName \$Servers -ScriptBlock {
param(\$Source)
\$name = "Client-ProjFS"

```
Write-Host "=== $env:COMPUTERNAME ==="
$f = Get-WindowsOptionalFeature -Online -FeatureName $name -ErrorAction SilentlyContinue
if (-not $f) {
    Write-Warning "Fonctionnalité introuvable dans la liste. Tentative d'activation avec source…"
    try {
        Enable-WindowsOptionalFeature -Online -FeatureName $name -All -Source $Source -LimitAccess -NoRestart -ErrorAction Stop
    } catch {
        Write-Error "Echec avec source. Suggérer une réparation sur place."
    }
} elseif ($f.State -ne "Enabled") {
    try {
        Enable-WindowsOptionalFeature -Online -FeatureName $name -All -NoRestart -ErrorAction Stop
    } catch {
        Write-Warning "Activation en ligne a échoué. Tentative avec source…"
        Enable-WindowsOptionalFeature -Online -FeatureName $name -All -Source $Source -LimitAccess -NoRestart
    }
} else {
    Write-Host "Déjà activé."
}

# Vérifier le mini-filtre ProjFS
Write-Host "Service prjflt :"
sc.exe query prjflt | Out-String | Write-Host
```

} -ArgumentList \$Source

Vous pouvez intégrer ce contrôle à un pipeline (pré‑prod) pour empêcher la diffusion d’images appauvries.

GPO & WSUS : réglage qui change tout

Si votre domaine impose WSUS, la GPO suivante détermine la capacité de Windows à récupérer les charges utiles FoD manquantes :

Chemin : Configuration ordinateur → Modèles d’administration → Système → Spécifier les paramètres d’installation des composants facultatifs et de réparation
Recommandation : activer l’option autorisant le contact direct avec Windows Update pour les contenus de réparation uniquement. Cela n’ignore pas WSUS pour les mises à jour classiques, mais débloque l’installation de fonctionnalités comme Client‑ProjFS.

Bonnes pratiques pour images d’entreprise

Corriger la « golden image » : bannissez les nettoyages irréversibles (/ResetBase) et les scripts qui retirent les FoD indispensables.
Conserver une source SxS alignée sur la build déployée, disponible en local (ISO/clé USB) ou via un partage résilient (DFS, haute dispo).
Aligner SSU/LCU : appliquez d’abord le Servicing Stack Update puis le Latest Cumulative Update dans vos images de référence.
Tester l’activation à blanc de Client‑ProjFS dans le pipeline de construction d’image (dism /Get-Features + essai /Enable-Feature sur VM jetable).
Documenter la dépendance : Client‑ProjFS doit rester disponible sur les hôtes destinés à héberger des outils de développement Visual Studio 2022.

FAQ rapide

Client‑ProjFS est‑il pris en charge sur toutes les variantes de Server 2019 ?

Oui, la fonctionnalité est disponible sur Windows Server 2019 (Desktop Experience et Server Core). Sur Core, l’activation se fait exclusivement via DISM/PowerShell.

Quelle différence entre Client‑ProjFS et le service prjflt ?

Client‑ProjFS est la fonctionnalité Windows facultative qui installe et configure le mini‑filtre Projected File System. Le service/driver associé apparaît généralement sous le nom prjflt (mini‑filtre). L’activation de la fonctionnalité doit rendre le service présent et démarrable.

Dois‑je redémarrer ?

Souvent oui : l’installation de pilotes de mini‑filtre nécessite un redémarrage pour que Visual Studio et les outils basés sur ProjFS fonctionnent correctement.

Comment savoir si mon magasin est trop endommagé pour être réparé sans réinstallation ?

Si sfc /scannow et dism /RestoreHealth échouent même avec une source alignée (install.wim et index corrects), et que CBS.log répertorie de nombreuses erreurs SxS répétées, la réparation sur place est l’option la plus fiable et rapide.

Checklist opérationnelle (copiable)

Vérifier la présence de la fonctionnalité :
dism /online /Get-Features /Format:Table | findstr /I projf
Contrôler/soigner l’image :
sfc /scannow
dism /online /Cleanup-Image /RestoreHealth
Activer la fonctionnalité :
dism /online /Enable-Feature /FeatureName:Client-ProjFS /All /NoRestart
Si échec : monter un ISO aligné et relancer en pointant /Source:D:\sources\sxs et /LimitAccess.
Si échec persistant : réparer via install.wim (/RestoreHealth /Source:wim:…:<Index>), sinon in‑place upgrade.
Vérifier sc query prjflt et relancer l’installation de Visual Studio 2022.

Conclusion

Le problème ne vient pas de Windows Server 2019 en soi : sur une installation propre et à jour, Client‑ProjFS s’active normalement. Si l’activation échoue (ou que la fonctionnalité n’apparaît pas), le diagnostic pointe vers une image système appauvrie ou un magasin WinSxS altéré. Corrigez votre image de référence, autorisez la réparation via GPO/WSUS si nécessaire et, en cas de blocage, pointez l’installation sur une source SxS correspondante ou effectuez une réparation sur place. Une fois la fonctionnalité rétablie, vérifiez le mini‑filtre prjflt et relancez le setup de Visual Studio 2022 : les composants dépendants de ProjFS fonctionneront alors comme attendu.

Annexes — commandes prêtes à l’emploi

Pack “tout‑en‑un” (local)

:: 1) Santé du système
sfc /scannow
dism /online /Cleanup-Image /AnalyzeComponentStore
dism /online /Cleanup-Image /RestoreHealth

\:: 2) Activation standard
dism /online /Enable-Feature /FeatureName\:Client-ProjFS /All /NoRestart

\:: 3) Activation avec source (adapter la lettre du lecteur)
dism /online /Enable-Feature /FeatureName\:Client-ProjFS /All ^
/Source\:D:\sources\sxs /LimitAccess

\:: 4) Réparation via install.wim (trouver l'Index valable)
dism /Get-WimInfo /WimFile\:D:\sources\install.wim
dism /online /Cleanup-Image /RestoreHealth ^
/Source\:wim\:D:\sources\install.wim:\ /LimitAccess

\:: 5) Vérifications finales
sc query prjflt
dism /online /Get-Features /Format\:Table | findstr /I projf

Contrôle GPO (rapide)

gpresult /h C:\Temp\gpresult.html

Ouvrez le rapport et vérifiez la stratégie : Spécifier les paramètres d’installation des composants facultatifs et de réparation (autoriser le contact Windows Update pour la réparation).

Points d’attention (à ne pas négliger)

Évitez d’utiliser /ResetBase dans vos images de référence si vous devez conserver la possibilité d’ajouter des fonctionnalités plus tard.
Ne mélangez pas les langues et éditions entre l’ISO de réparation et la machine cible.
Planifiez un redémarrage : ProjFS installe un mini‑filtre système.
Documentez la dépendance ProjFS dans les exigences de vos hôtes de build/dev (VS 2022).

En appliquant ces étapes, vous éliminerez durablement l’erreur 14081 et rétablirez une base saine pour l’installation de fonctionnalités facultatives sur vos serveurs Windows Server 2019.