1. Le cas de départ : les vérifications classiques n’ont pas suffi

Le projet consistait à remplacer des StoreFront anciens par de nouveaux serveurs, avec une cible Windows Server 2025 et StoreFront 2507. Je souhaitais repartir sur un groupe distinct, reprendre les éléments utiles et préparer la bascule côté Gateway et load balancing.

La reprise de configuration m’a conduit à un double blocage : propagation impossible et erreurs de certificats lors de la montée de version. Le serveur d’origine, celui dont la configuration devait être reprise, était en StoreFront 2203 LTSR. L’installeur 2507 CU1 faisait partie des tentatives de mise à niveau.

J’ai passé du temps sur ce dossier avec le support Citrix : contrôles des services, comptes locaux, permissions des clés privées, comparaison des certificats, redémarrage et nouvelle tentative d’installation. Malgré ces vérifications, la propagation restait en échec.

Failed to acquire certificates.
Invalid provider type specified.

... RSACryptoServiceProvider.GetKeyPair()
... X509Certificate2.get_PrivateKey()
... ServerConfiguration.GetMissingStoreCertificates(...)

Ce qui a été demandé, ce que les essais ont donné

La suite de l’échange prévoit une session distante pour poursuivre l’analyse. À ce stade, nous avions une erreur reproductible et une piste cryptographique sérieuse, mais pas une réparation validée. J’ai ensuite choisi de reconstruire la configuration sur les nouveaux serveurs.

Les étapes ci-dessous reprennent les enseignements de ce dossier et les complètent pour servir sur d’autres environnements. Elles permettent de décider quoi vérifier, puis comment préparer une reconstruction si le dépannage n’aboutit pas.

2. Diagnostiquer dans le bon ordre

Les vérifications de base, avant toute piste cryptographique

Elles ont été faites sur ce dossier et n’ont rien changé. Elles restent le préalable, parce que dans la majorité des cas elles suffisent, et parce qu’aucune analyse de certificat n’a de sens tant qu’elles ne sont pas acquises :

• une seule console d’administration StoreFront ouverte sur le groupe, les autres fermées ;
• iisreset sur le nœud concerné, puis redémarrage des services Citrix (Get-Service Citrix* | Restart-Service -Force) ;
• un redémarrage complet du nœud après toute modification de comptes ou de permissions ;
• résolution DNS dans les deux sens entre membres, port 808 joignable, horloges synchronisées ;
• les comptes de service de réplication et de cluster présents dans le groupe Administrateurs local, sans GPO qui les retire.

Citrix regroupe ces contrôles dans son guide de dépannage de la propagation (CTX206872). La suite de cet article concerne le cas où ils sont tous passés et où la propagation échoue encore.

Identifier l’opération qui échoue

Commencer par distinguer une installation, une montée de version, un import, une jonction au groupe et une propagation entre membres existants. Noter les versions et builds exacts, le serveur depuis lequel l’opération est lancée, le nœud en échec et l’heure du test.

Ces informations évitent de mélanger les journaux de plusieurs tentatives. Pour le support, une opération précise, son horodatage et les traces des deux serveurs sont plus utiles qu’une succession de captures sans contexte.

Contrôler les services et leur identité

Vérifier l’état des services StoreFront concernés et leur compte de démarrage. Cette commande effectue un inventaire en lecture seule :

Get-CimInstance Win32_Service |
    Where-Object {
        $_.Name -in @(
            'CitrixConfigurationReplication',
            'CitrixCredentialWallet',
            'CitrixSubscriptionsStore',
            'CitrixClusterService'
        )
    } |
    Select-Object Name, State, StartMode, StartName

Comparer avec un serveur sain de même version et avec la configuration attendue. Pendant les modifications, utiliser une seule console d’administration du groupe et fermer les autres consoles StoreFront. Citrix rappelle cette règle d’administration.

Vérifier le réseau sans réduire le diagnostic au port 808

Contrôler la résolution DNS entre nœuds, les écoutes locales et les flux correspondant à la version installée. Un test TCP indique qu’une connexion s’établit, pas que la réplication applicative fonctionne.

Le plan du support mentionnait le port 808. Dans la documentation 2507, ce port sert notamment à la synchronisation des favoris et des souscriptions ; Citrix décrit également un port TCP choisi parmi les ports non réservés pour les communications entre serveurs du groupe. Un test réussi sur 808 ne valide donc pas tous les échanges. Prérequis réseau StoreFront.

Première jonction : à quel moment vérifier l’écoute ?

Lors de la constitution du groupe, distinguer le serveur A, qui héberge déjà le déploiement, du serveur B, fraîchement installé et pas encore membre. Sur ce projet, un test depuis B vers A répondait alors que le test inverse échouait avant la jonction. Cette asymétrie ne suffisait pas à conclure à un filtrage réseau.

1. Avant la jonction : sur A, ouvrir Server Group > Add Server pour obtenir le code. Sur B, ouvrir Join existing server group. B n’héberge pas encore la configuration du groupe ; ne pas déduire un défaut réseau de la seule absence d’une écoute attendue sur un membre déjà configuré.
2. Au lancement de Join sur B : relever les écoutes et les événements sur les deux serveurs pendant l’autorisation et la reprise initiale. C’est pendant cette mise en place qu’il faut observer l’activation des points de communication nécessaires, plutôt que supposer qu’ils étaient tous actifs avant la jonction.
3. Après la jonction et la reprise de configuration : vérifier les services et les écoutes correspondant aux fonctions activées, puis lancer Propagate Changes. Pour les favoris utilisant la base locale, contrôler aussi le port 808 et leur synchronisation, indépendante de cette propagation.

La documentation Citrix situe la reprise de configuration après la jonction, mais ne donne pas l’instant précis où chaque écoute est créée. On ne peut donc pas affirmer que « le port 808 s’ouvre à la fin de la première synchro » pour toutes les versions. Le repère fiable reste l’état du service et l’écoute mesurée pendant Join, puis après configuration. Séquence de jonction et distinction avec les souscriptions.

# Sur chaque serveur : relever les ecoutes locales et leur processus
Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress, LocalPort, OwningProcess

# Exemple : verifier 808 quand la fonction correspondante est active
# Remplacer le nom et adapter le port au flux diagnostique
Test-NetConnection -ComputerName 'sf02.example.net' -Port 808

Si aucune écoute locale n’existe, rechercher d’abord pourquoi le service ne l’a pas créée. Si elle existe mais reste injoignable depuis l’autre nœud, examiner la résolution, l’adresse d’écoute et le filtrage. Conserver l’heure de chaque test pour la rapprocher des journaux.

Lire toute la séquence d’événements

Dans les captures de ce dossier, un événement 29 indiquait que le serveur distant avait terminé sa synchronisation. Pourtant, la console affichait un échec et les événements 13 et 31 contenaient les erreurs d’acquisition des certificats et de mise à jour.

3. Approfondir la piste des certificats

Identifier le certificat avant de le corriger

StoreFront utilise plusieurs certificats. Le certificat HTTPS d’IIS et les certificats de ses services internes n’ont pas le même rôle. Citrix documente notamment le magasin Citrix Delivery Services pour les services de réplication, de Credential Wallet et de souscriptions. Sécurité StoreFront.

Dans l’échange fourni, les captures concernent aussi des certificats du magasin personnel, émis par une autorité d’entreprise. L’erreur GetMissingStoreCertificates ne permet pas à elle seule de désigner un certificat interne corrompu. Il faut retrouver l’objet effectivement traité au moment de l’échec.

# Relever les noms exacts des magasins locaux
Get-ChildItem Cert:\LocalMachine |
    Select-Object Name, Location

# Examiner le magasin personnel
Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

# Examiner aussi le magasin Citrix identifie, avec son nom exact
# Get-ChildItem 'Cert:\LocalMachine\NOM_DU_MAGASIN' |
#     Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

Pour chaque certificat suspect, relever son magasin, son empreinte, son usage, son fournisseur et les droits sur sa clé privée. La présence de la clé dans une console administrateur ne valide pas son utilisation par le service.

Comprendre ce que le test de clé valide

Le résultat conservé dans les captures était le suivant, pour les certificats testés :

HasPrivateKey : True
RSAStatus     : OK
RSAType       : System.Security.Cryptography.RSACng

En parallèle, StoreFront échouait dans un chemin passant par RSACryptoServiceProvider et X509Certificate2.get_PrivateKey(). Le test RSA et l’opération StoreFront n’établissaient donc pas la même chose : un contrôle positif ne garantissait pas que le service puisse accomplir son opération.

Cette différence justifie d’examiner le fournisseur, l’API utilisée et le contexte de sécurité. Elle ne prouve pas que toute clé CNG est incompatible. Microsoft Software Key Storage Provider, cité par le support parmi les fournisseurs possibles, appartient lui-même à CNG. Documentation Microsoft sur les KSP.

Corriger les permissions sur l’objet identifié

Le support demandait de vérifier les accès en lecture de NT SERVICE\CitrixConfigurationReplication et NT SERVICE\CitrixClusterService, ainsi que de NT SERVICE\CitrixCredentialWallet en présence d’erreurs Credential Wallet. Dans MMC, l’action All Tasks > Manage Private Keys, lorsqu’elle est disponible, permet d’examiner les permissions de la clé sélectionnée.

Dans mon cas, cette reprise des droits n’a pas suffi. Étendre encore les permissions sans nouvel indice n’aurait pas constitué un diagnostic. La lecture demandée pour une clé précise ne doit pas devenir un contrôle total généralisé sur les certificats.

Le mail proposait aussi des actions conditionnelles, comme changer l’identité d’un service qui ne démarre pas ou traiter un conflit de fichiers IIS. Elles doivent rester attachées au symptôme correspondant. Je ne les transformerais pas en prérequis systématiques d’une reconstruction.

4. Quand passer à la reconstruction

Les limites de l’upgrade en place

Une montée de version StoreFront en place conserve le serveur et fait évoluer le déploiement existant. Elle peut être adaptée à un environnement sain, mais elle ne constitue pas une remise à zéro des magasins de certificats, des clés privées, des permissions ou des paramètres IIS. L’historique des renouvellements, des imports et des changements de comptes reste donc à examiner.

Un certificat renouvelé peut coexister avec son prédécesseur ; une association à une clé peut être absente ou inutilisable ; les droits peuvent avoir été modifiés au fil des interventions. Ce sont des états à inventorier, pas une raison de supprimer tous les anciens certificats. La date d’expiration ou la présence de doublons ne suffit pas à désigner le responsable.

Une désinstallation suivie d’une réinstallation n’efface pas nécessairement cet héritage. Citrix documente notamment un cas où des éléments IIS conservés après un upgrade en échec empêchent ensuite la jonction au groupe. Ce cas illustre la limite de la réinstallation sur le même socle, sans prouver qu’il explique notre incident. CTX695451 : échec de jonction après upgrade en place.

Ce que les versions récentes changent pour une reconstruction

Le chemin officiel vers la 2607 LTSR, sortie le 18 août 2026, part de 2203 LTSR (toute CU), 2402 LTSR, 2507 LTSR, 2503, 2511 ou 2603, avec deux contraintes rappelées par Citrix : les serveurs d’un groupe se mettent à niveau l’un après l’autre, jamais en parallèle, et un groupe ne fonctionne pas en versions mixtes. La 2603 et les suivantes exigent .NET 10, que l’installeur ajoute s’il manque. Pour un nouveau groupe construit aujourd’hui, la 2607 LTSR est la cible naturelle : version à support long, socle Windows Server 2025, et un point de départ propre qui évite d’hériter des états intermédiaires décrits plus haut. Le projet raconté ici visait la 2507, disponible au moment des faits. Upgrade StoreFront (documentation Citrix), notes de version StoreFront.

Les limites des scripts PowerShell d’export/import

Export-STFConfiguration et Import-STFConfiguration servent à sauvegarder et reprendre un déploiement. Ils ne constituent pas une procédure de nettoyage de son historique. L’import impose une version StoreFront identique et remplace la configuration présente sur la cible ; il ne transforme pas automatiquement une configuration ancienne en configuration minimale maîtrisée. Périmètre de l’export/import Citrix.

Pour les certificats, il faut distinguer ce que l’opération reprend effectivement, les certificats déjà présents sur Windows et ceux provisionnés séparément, par exemple pour HTTPS. Selon le certificat et son rôle, contrôler le magasin, la clé privée, le fournisseur, les permissions et les références utilisées par la configuration. Un script terminé sans erreur ne valide pas à lui seul tous ces points sur la cible.

Changer de serveur tout en réimportant la configuration ne garantit donc pas de laisser derrière soi les problèmes liés à l’historique des certificats. Une dépendance peut être conservée, une clé nécessaire peut manquer, ou une GPO peut recréer le même état. À l’inverse, on ne peut pas conclure que l’export/import copie indistinctement tous les certificats et tous les défauts de la machine source.

La bonne validation reste opérationnelle : après la reprise, tester l’authentification, le lancement de ressources et la propagation. Dans mon cas, les erreurs persistaient malgré les contrôles et les corrections ; reconstruire la configuration utile permettait de réduire ce que je reprenais de l’ancien environnement.

Choisir un périmètre de reprise maîtrisable

Après les corrections et les nouveaux essais, le blocage était toujours présent. Il fallait encore investiguer avec le support, alors que la migration devait avancer. J’ai choisi de reconstruire manuellement la configuration utile sur les nouveaux StoreFront.

Pour prendre cette décision, je compare le temps déjà passé, les prochaines investigations réellement identifiées, le volume de configuration à reprendre et la possibilité de tester la cible sans toucher à l’existant. Si chaque nouvel essai reproduit la même erreur sans apporter d’information, la reconstruction devient une option concrète.

Recréer les serveurs ne résout toutefois pas automatiquement un problème apporté par une GPO, un modèle de certificat ou un paramètre réimporté. Il faut tester progressivement la cible pour repérer à quel moment le défaut réapparaîtrait.

5. Reconstruire un groupe StoreFront

Voici la méthode que je retiens pour préparer une reconstruction. Elle doit être adaptée aux fonctions réellement utilisées ; toutes les étapes ne correspondent pas à des opérations attestées par l’échange de support.

Étape 1 : relever ce qui doit être conservé

Avant de créer le premier store, constituer un inventaire de la configuration utile :

• Accès : URL de base, chemins des stores et des sites Web, adresses utilisées par Workspace, DNS, VIP et certificats HTTPS.
• Ressources : Delivery Controllers ou Cloud Connectors selon le déploiement, transports, ports, regroupements et paramètres d’énumération.
• Authentification : méthodes activées, domaines, pass-through depuis la Gateway et éventuelle intégration FAS.
• Gateway : URL, callback si utilisé, STA, routage HDX et paramètres côté NetScaler qui pointent vers StoreFront.
• Expérience utilisateur : favoris, reconnexion, délais, personnalisations, fichiers de provisioning et réglages PowerShell spécifiques.
• Exploitation : moniteurs de disponibilité, règles réseau, sauvegardes, supervision et dépendances apportées par les GPO.

Conserver une sauvegarde exploitable de l’existant et exporter la configuration si l’état du déploiement le permet. Pour une reprise par import, respecter la même version StoreFront à l’export et à l’import. Une reconstruction manuelle n’utilise pas cet import pour restaurer l’ensemble. Export et import de configuration.

Étape 2 : préparer le socle et le premier serveur

Choisir un couple Windows Server / StoreFront supporté et un build commun aux futurs membres. Citrix demande la même version d’OS, la même langue et les mêmes paramètres régionaux dans un groupe ; la mise à niveau de l’OS avec StoreFront installé n’est pas supportée. Prérequis système.

Vérifier les GPO appliquées, les groupes locaux, DNS et les chemins IIS avant l’installation. Un autre blocage rencontré sur ce projet venait d’un SID non résolu dans les administrateurs locaux, maintenu par une ancienne GPP. Nettoyer uniquement le serveur aurait laissé la stratégie réintroduire le problème.

Sur le premier serveur, créer un nouveau déploiement. Définir l’URL de base prévue pour le groupe, cohérente avec l’accès via le load balancer, et préparer le certificat HTTPS correspondant. Créer un déploiement StoreFront.

Étape 3 : recréer un premier store et tester son fonctionnement

Configurer les sources de ressources, les méthodes d’authentification et le site Web du store. Commencer avec un périmètre limité : un compte de test, l’énumération attendue et le lancement d’une ressource représentative.

Réintroduire ensuite les paramètres spécifiques par ensembles identifiables, avec un test entre chaque étape. Cela permet de comprendre ce qu’apporte chaque réglage et de repérer une régression sans avoir recopié tout l’héritage.

Étape 4 : joindre le deuxième serveur et tester la propagation tôt

Installer le même build sur le deuxième serveur, puis utiliser la procédure de jonction au nouveau groupe. Ne pas créer deux déploiements indépendants pour tenter ensuite de synchroniser leurs configurations. Citrix décrit la génération du code d’autorisation depuis le groupe et son utilisation sur le serveur à joindre. Configurer un groupe de serveurs.

Tester une propagation avant d’avoir repris tous les stores et toutes les personnalisations. Si elle échoue déjà sur cette configuration minimale, le périmètre de recherche est beaucoup plus réduit. Poursuivre la configuration depuis un seul nœud d’administration, puis propager.

Étape 5 : reprendre les accès Gateway et les favoris

Recréer les paramètres d’accès distant, puis vérifier leur cohérence avec le NetScaler : adresses StoreFront, authentification, callback et STA selon le montage. Le remplacement des StoreFront n’impose pas à lui seul de changer les STA ; identifier les composants qui assurent réellement ce rôle.

Traiter séparément les favoris utilisateurs. Une configuration de store recréée ne suffit pas à les reprendre. Si leur conservation est attendue, Citrix documente leur export et leur import vers un store nouvellement provisionné avec Export-STFStoreSubscriptions et Import-STFStoreSubscriptions. Vérifier ensuite les données et leur synchronisation selon le mode de stockage utilisé. Gérer les souscriptions.

6. Tester, basculer et conserver un retour arrière

Tester la cible avec un chemin d’accès dédié ou un groupe pilote, en conservant des URL et des certificats cohérents. Ouvrir directement l’adresse IP d’un serveur ne reproduit pas nécessairement les conditions d’accès habituelles.

Préparer la modification exacte côté load balancing, Gateway ou DNS, selon l’architecture. Garder l’ancien groupe disponible le temps de la validation et éviter les changements de configuration simultanés sur les deux environnements pendant la bascule.

Après validation, sauvegarder la nouvelle configuration et documenter les réglages retenus. Les anciens serveurs peuvent être retirés lorsque les critères de recette et la période d’observation définie pour le projet sont satisfaits.

Dans ce dossier, les échanges avec le support ont fourni des pistes utiles, mais les corrections n’ont pas débloqué la réplication. La reconstruction a permis de poursuivre le projet. Le bénéfice à en tirer pour une prochaine migration : disposer à la fois d’un diagnostic structuré et d’une configuration suffisamment documentée pour pouvoir la reconstruire.