Bonjour,

Après un premier article sur l'activation de ce fichier, voici un second sur l'analyse de celui-ci.

Vous pouvez le trouver dans le dossier C:\Windows\debug\usermode\gpsvc.log

Threads

Sur les machines avec des architectures multi-coeurs, il peut y avoir plusieurs threads qui s'exécutent au même moment (un thread pour les paramètres utilisateurs et un thread pour les paramètres machine.). Il peut être utile de savoir les différencier dans le fichier de log.

Pour se faire, il suffit d'analyser les valeurs rapportées pour GPSVC :

GPSVC(78d.666) 12:41:45:477 Caller requesting for user notification/lock is from session 0

On remarque que celles-ci sont composées de deux parties :

• 78d : Correspond au PID (Process ID) (en héxadécimal)
• 666 : Correspond au TID (Thread ID)

Début du traitement des stratégies

Le traitement des stratégies débute toujours avec les paramètres machine.

Il peut être repéré par l'enregistrement suivant :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1

Connectivité réseau

Immédiatement après le début du traitement des stratégies machines, une vérification de la connectivité réseau est faite :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1
GPSVC(2dc.520) 11:40:08:707 Waiting for connectivity before applying policies

Souvent, le client Stratégies de groupe démarre avant que la connectivité réseau soit effective, ce qui génère le message suivant :

GPSVC(2dc.18c) 11:40:08:806 There is no connectivity. Waiting for connectivity again …

Mais quelques secondes plus tard, la connectivité est établie :

GPSVC(2dc.18c) 11:42:09:106 We have network connectivity… proceeding to apply policy.

En cas de non connectivité (30 secondes de timeout par défaut), on trouvera toujours l'erreur suivante :

GPSVC(2dc.520) 11:45:10:033 Application complete with bConnectivityFailure = 1.

Note : Cela peut être une erreur de connectivité mais pas uniquement réseau, cela peut concerner du LDAP par exemple

Estimation de la bande passante

Avant de traiter les stratégies de groupe, une estimation de la bande passante est faite.

Celle-ci est calculée en se connectant d'abord à un contrôleur de domaine afin d'obtenir une liste de ceux-ci, puis en évaluant la vitesse de la connexion entre le poste et un contrôleur de domaine. Le calcul de la bande passante est effectuée par le NLA (Network Location Awarnesss).

Le début de l'estimation se présente comme ceci :

GPSVC(2cc.c28) 15:56:04:821 GetDomainControllerConnectionInfo: Enabling bandwidth estimate.
GPSVC(2cc.c28) 15:56:05:134 Started bandwidth estimation successfully

La fin de l'estimation se présente comme ceci :

Ordre de traitement des stratégies

• Le lien d'un GPO peut être appliqué (enforced) ou/et désactivé
• Une stratégie peut avoir des paramètres ordinateurs/utilisateurs désactivés
• Le blocage de l'héritage au niveau de l'OU est activé
• Le mode bouclage est activé

Lecture des stratégies :

• 0 : Paramètre par défaut
• 1 : Le lien est désactivé
• 2 : Le lien est appliqué (enforced)

Traitement des stratégies :

• La présence d'un filtre WMI est détecté en 1er et s'il est présent, il est évalué.
• Le GUID de la GPO renvoie à son chemin physique dans le dossier SYSVOL.
• La présence de paramètres CSE est évaluée
• L'état de la GPO (désactivée ou non) est évaluée afin de décider de son traitement
• La présence de paramètres CSE est évaluée

Bonjour à tous !

Aujourd'hui nous allons aborder la résolution de problèmes d'application des stratégies de groupe (coté poste client) et plus précisément la partie avancée de cette résolution.

Débug usuel

Habituellement, il faut passer par l'Observateur d'Evènements du poste client afin d'obtenir plus de détails sur l'application des stratégies de groupe.

Deux sections peuvent vous intéresser :

• Journaux Windows/Système
  • Le niveau de détail est assez limité mais c'est un bon point de départ
  • Vous pouvez filtrer les événements par les sources pour ne garder que les parties intéressantes

• Journaux des applications et des services/Microsoft/Windows/GroupPolicy
  • Est beaucoup plus détaillé
  • Ne contient que les evènements stratégies de groupe

Mais parfois, il peut s'avérer que les informations remontées par ces logs ne soient pas assez précises pour trouver la vraie cause du problème.

Débug avancé

Les messages d'état détaillés

Le fichier gpsvc.log

1. Ouvrez l'éditeur de registre avec la commande Regedit
2. Dépliez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
3. Crééz une nouvelle clé Diagnostics si elle n'existe pas
4. Crééz une nouvelle valeur DWORD (32-bit) GPSvcDebugLevel
5. Modifiez la valeur GPSvcDebugLevel par la valeur 30002 (Hexadecimal)
6. Fermez le Registre
7. Crééz le dossier Usermode si celui-ci est absent du dossier C:\Windows\Debug\
8. Lancez la commande Gpupdate /force
9. Le fichier gpsvc.log doit se créer

Bonjour à tous !

Comme vu dans le billet précédent, la plupart des erreurs rencontrées sur RUM proviennent plus de votre infrastructure (IP manquantes/non à jour dans les zones DNS, découverte réseau Windows désactivée, ...) que de RUM en lui même.

Afin de minimiser ces erreurs, sur les postes concernés par la migration, il convient de mettre en place un certain nombre de pré-requis que nous allons détailler ci-dessous.

Les pré-requis

Droits d'accès administratifs sur les postes de travail

Le serveur RUM utilise deux comptes de services distincts :

• Le compte de service du service RUM Controller
  • Il correspond au compte renseigné lors de l'installation du logiciel RUM
  • Il peut être configuré depuis la console RUM en allant dans le menu Tools -> Manage Controller Credentials

• Le compte de service du service Dell Migration Manager RUM Agent Service
  • Il correspond au compte utilisé par l'agent RUM quand il est installé sur un poste
  • ll peut être configuré depuis la console RUM en allant dans le menu Project -> Manage Domains Credentials

Le compte de service du service Controller RUM doit faire partie du groupe local Administrateurs du serveur RUM.

Le compte de service du service Dell Migration Manager RUM Agent Service doit faire partie du groupe local Administrateurs sur tous les postes devant être migrés.

Le firewall Windows/d'Entreprise

Pour la liste complète des ports, je vous renvoie à ce lien : What firewall ports need to be opened for Migration Manager for AD / Resource Updating

Pour la partie qui nous intéresse, à savoir le poste à migrer, il faut bien entendu une connectivité à minima vers les serveurs Active Directory des domaines sources et cibles.

La liste des ports à ouvrir entre un poste client et un serveur RUM est quelque peu longue, la faute au RPC Dynamique.

Vous devrez donc ouvrir de manière bi-directionnelle, entre un poste et un serveur RUM, les ports suivants :

• 135-139
• 445
• 1024-65535

La résolution de noms d'hôtes

Mais RUM utilisant également des noms d'hôtes courts, le poste doit être capable de les résoudre aussi.

Pour cela, il faut configurer sur les postes ciblés le paramètre de Liste de recherche de suffixes DNS comme ceci :

• Nom de domaine du domaine AD source
• Nom de domaine du domaine AD cible

Astuce : Ce paramètre peut aussi être mis en oeuvre sur votre serveur RUM si vous voulez travailler avec des noms d'hôtes courts (non FQDN).

Les services Windows

Sur les postes à migrer, les services Windows suivants doivent être démarrés et configurés en mode Démarrage automatique :

• Server
• Workstation
• Netlogon
• Remote Procedure Call
• Remote Procedure Call Locator
• Remote Registry
• Function Discovery Provider Host
• SSDP Discovery
• UPnP Device Host

Mise en place des pré-requis

Deux méthodes peuvent être utilisées afin de mettre en place les pré-requis décrits précédemment :

• Par GPO
• Par script

Par GPO

Voici un exemple de GPO pouvant être déployée sur les postes du domaine source :

Par Script

Voici un exemple de script pouvant être utilisé sur les postes du domaine source :

A savoir : La commande net localgroup ne supporte pas l'ajout d'un groupe étant composé de plus de 20 caractères (NET.EXE /ADD command does not support names longer than 20 characters)

REM Set startup type for services
sc config RpcSs start= auto
sc config SSDPSRV start= auto
sc config upnphost start= auto
sc config fdPHost start= auto
sc config RpcLocator start= auto
sc config Netlogon start= auto
sc config RemoteRegistry start= auto
sc config LanmanServer start= auto
sc config LanmanWorkstation start= auto

REM Start services
net start RpcSs
net start SSDPSRV
net start upnphost
net start fdPHost
net start RpcLocator
net start Netlogon
net start RemoteRegistry
net start LanmanServer
net start LanmanWorkstation

REM Disable Firewall on Domain profile
netsh advfirewall set DomainProfile state off

REM Add group to local Administrators group
net localgroup Administrateurs XXX\CORP-QUEST-ADMIN /ADD

REM Set DNS Suffix Search list
REG ADD HKLM\System\CurrentControlSet\Services\TCPIP\Parameters /v SearchList /t REG_SZ /f /d "domaine_source_fqdn,domaine_cible_fqdn"

Bonjour à tous !

Aujourd'hui nous allons voir quelles sont les erreurs les plus courantes lorsque vous travaillez avec Quest RUM (Resource Updating Manager) et quelles sont leurs solutions.

C'est parti !

The RPC Server is unavailable

Derrière son nom trivial qui indique que le serveur RPC de la machine que vous essayez de joindre n'est pas disponible, vous pouvez avoir deux comportements :

• L'erreur arrive juste après un Discovery/Processing/Move : RUM n'arrive pas à résoudre le nom de l'hôte. Vérifiez si le poste est bien référencé dans les DNS configurés sur votre serveur RUM.
• L'erreur arrive environ 20/30 secondes après un Discovery/Processing/Move : RUM arrive bien à résoudre le nom de l'hôte mais celui-ci n'est pas joignable. Vérifiez en priorité que le pare-feu Windows est correctement configuré ou désactivé et vérifiez si la découverte réseau Windows est bien activé dans les options du Centre Réseau et Partage.

En dernier, comme son nom l'indique, vous pouvez toujours vérifier si le service Serveur RPC est bien lancé mais c'est le cas le moins souvent rencontré.

Access is denied

L'erreur indique le poste est joignable mais que le serveur RUM n'arrive pas à atteindre le partage administratif du poste ciblé pour y effectuer ses opérations.

Bien qu'étant assez générique, cette erreur se rencontrera surtout lors des trois cas suivants :

• La découverte réseau Windows n'est pas active sur le poste ciblé
• Le serveur RUM ne contacte pas la machine voulue car l'IP de la machine ciblée n'est pas à jour dans les serveurs DNS utilisés
• La machine ciblée n'est pas dans le domaine renseigné (déjà migrée ou autre domaine)

Log path RUM_Server_Name is not accessible

L'erreur indique que l'agent RUM sur le poste n'arrive pas à contacter le serveur RUM ou/et n'arrive pas à accéder au partage QuestResourceUpdatingLogs$ pour y transférer ses logs.

Vous êtes plus susceptible de rencontrer cette erreur si votre poste et le serveur RUM sont dans des domaines différents. Bien souvent, cela indique que le poste n'arrive pas à résoudre le nom du serveur RUM car l'agent utilise le nom d'hôte court du serveur et non son nom FQDN pour le contacter.

Dans ce cas, la solution consiste à vérifier dans la liste de recherche de suffixes DNS Windows si le nom de domaine du serveur RUM est bien présent.

The network path was not found

De manière générale, cette erreur concerne plus les problèmes de résolution de nom NetBIOS des postes, cela étant dit, vous pouvez rencontrer également les deux comportements suivants :

• L'erreur se produit lors d'un Discovery/Processing alors que le poste était joignable juste avant : Le poste a été éteint entre temps ou son IP n'est pas à jour dans les DNS
• L'erreur se produit lors d'un Move : Il faut désactiver la recherche LMHOSTS dans les paramètres TCP/IP avancés du poste ciblé

A security package specific error occurred

Cette erreur se produit lors d'un Discovery. Une installation manuelle de l'agent RUM se terminera par la même erreur sur le poste ciblé.

La solution la plus souvent appliquée est d'utiliser l'IP du poste plutôt que son FQDN pour faire le Discovery.

The parameter is incorrect

Cette erreur se produit lors d'un Move.

Elle peut être rencontrée lorsque le serveur RUM contacte un contrôleur de domaine sous Windows Server 2012 R2 pour migrer le poste dans le domaine cible.

Deux solutions à ce problème :

• Utiliser un contrôleur de domaine non 2012 R2 pour effectuer la bascule (voir l'article Définition des contrôleurs de domaine préférés)
• Ne pas utiliser l'option "Create the computer object in this OU in the target domain" mais les attributs RestrictedKrbHost/ComputerName SPN ne seront pas repris pour l'objet ordinateur migré

Bonjour à tous,

Aujourd'hui nous allons partir à la découverte du fichier NetLogon.dns

Vous trouverez ce fichier, propre à chaque contrôleur de domaine, dans le dossier %systemroot%\System32\Config.

Comme vous le savez surement, les services AD et DNS sont très étroitement liés car les informations relatives aux différents contrôleurs de domaine ou aux différents sites AD sont stockées dans la zone DNS de la forêt AD correspondante. 

Celle-ci contient donc des enregistrements A faisant référence directement aux adresses IP des contrôleurs de domaine ou des enregistrements SRV permettant aux postes clients de la forêt AD de pouvoir accéder aux services essentiels AD.

Ce fichier intéressera donc en premier lieu :

• Ceux qui doivent résoudre des problèmes relatifs au fonctionnement des services AD et qui ont localisé des irrégularités au niveau des enregistrements stockés dans la zone DNS AD
• Ceux dont la zone DNS correspondant à la forêt AD se trouve sur un serveur DNS non Microsoft (gestion "manuelle" des enregistrements)

Un exemple valant mieux que 1000 mots, vous trouverez ci-dessous le contenu de ce fichier avec l'ensemble des enregistrements mentionnés ci-dessus :

Bonne exploration !

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
   1. Mars 2017
      1. KB4012598
2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
   1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
   2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
   3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
3. Pour Windows Server 2012 :
   1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
   2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
   3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
4. Pour Windows 8.1 et Windows 2012 R2 :
   1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
   2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
   3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
5. Pour Windows 10 (Release 1511) :
   1. Mars 2017
      1. KB4013198
      2. KB4016636
   2. Avril 2017
      1. KB4015219
   3. Mai 2017
      1. KB4019473
6. Pour Windows 10 (Release 1607) :
   1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
   2. Avril 2017
      
      1. KB4015217
   3. Mai 2017
      
      1. KB4019472
      2. KB4023680
7. Pour Windows 10 LTSB : 
   1. Mars 2017 
      1. KB4012606
      2. KB4016637
   2. Avril 2017
      
      1. KB4015221
   3. Mai 2017
      
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

Introduction :

Cette article va vous montrer comment migrer un DHCP failover existant de Windows server 2012 à Windows server 2016

Installation :

Installer le rôle DHCP sur les deux nouveaux serveurs.

Sur un des nouveaux serveurs créer deux répertoires : export et backup avec la commande mkdir. Par la suite toutes les commandes seront à effectuer sur ce serveur

Exporter la configuration DHCP de l’ancien Serveur en exécutant la commande suivante :

Export-DhcpServer –ComputerName nameoldserver –File C:\export\naomeoldserverexp.xml -Verbose

Importer la configuration sur le nouveau serveur DHCP avec la commande suivante

Import-DhcpServer –ComputerName DHCP2012R2-1 –File C:\export\DHCP2012-1exp.xml -BackupPath C:\backup\ -ServerConfigOnly -Verbose -Force

Note : Le paramètre « -BackupPatch » est utilisé pour sauvegarder la database du serveur actuel avant toute modification dans le cadre de la migration. Pour annuler l’opération de migration il suffit d’utiliser la commande Restore-dhcpServer suivit du paramètre –path en spécifiant le répertoire backup.

Configuration :

Pour configurer le mode DHCP Failover il faut se rendre dans l’interface DHCP du nouveau serveur et de cliquer sur Configure Failover

Choisir les scopes qui vont être répliqués

Sélectionner le second serveur

Configurer le Failover a isopérimètre avec l’ancien Failover.

Pour vérifier que le Failover est en place utiliser la commande suivante :

Get-DhcpServerv4Failover

Désinstaller l’ancien DHCP :

Une fois le nouveau DHCP Failover en place il faut supprimer l’ancien. Pour ce faire nous allons commencer par retirer la relation entre les deux avec la commande :

Remove-DhcpServerv4Failover –Name nameofrelationship

Une fois la commande réalisée avec succès, il faut arrêter les deux anciens DHCP depuis l’interface :

Si aucun effet de bord ce produit, Il ne reste plus qu’à désinstaller les rôles sur les deux anciens serveurs :

Suite à l'interrogation d'un client à propos des différentes versions d'OS et de leurs Services Pack, force m'a été de constater que le "Convenience Rollup Update for Windows 7 SP1 and Windows Server 2008 R2 SP1" paru en avril 2016, soit 5 ans après le SP1 (février 2011), n'était pas fourni directement par Microsoft via Windows update.

En effet, ce qui s'apparente à un service pack mais qui n'en est pas un, n'est mis à disposition que sur le "Microsoft Catalog Update".

Ce "CRU" de 316 à 476Mo selon le package, contient un peu plus de 200 mises à jour soit toutes celles depuis le SP1 jusqu'au mois de mai 2016 (à l'heure ou j'écris ces lignes). 

Prérequis :

Pour pouvoir installer le Rollup package vous devrez disposer des éléments suivants:

1. Service Pack 1 for Windows 7 or Windows Server 2008 R2 (KB976932)
2. April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2 (KB3020369)
3. 4Go d'espace libre sur le disque
4. Utiliser Internet Explorer pour le téléchargement (Vous aurez un message comme ci-dessous avec les autres navigateurs)

Téléchargement :

Pour télécharger le package utilisez Internet Explorer puis rendez vous sur l'URL : Microsoft Catalog Update

Ici un Pop-up vous invitant à installer un module complémentaire apparaît, cliquez sur "installer"

Ensuite à l'aide du menu contextuel recherchez la KB3125574 (vous n'êtes pas obligé d'écrire KB le numéro suffit).

3 packages s'offrent à vous : 

1. Le premier pour Windows 7 SP1 32 bits
2. Le deuxième pour Windows Serveur 2008 R2 SP1 64 bits
3. Le troisième pour Windows 7 SP1 64bits

Sélectionnez celui ou ceux qui vous intéressent à l'aide du bouton "Ajouter"

Puis cliquez sur "Afficher le panier"

Et enfin "Télécharger". 

Une fenêtre s'ouvre pour afin que vous puissiez indiquer le répertoire de destination de votre téléchargement, à la suite de quoi le téléchargement débutera automatiquement.

Une fois ce dernier terminé il ne vous reste plus qu'a vous rendre dans le répertoire que vous avez indiqué plus tôt; dedans se trouvera un ou plusieurs répertoires portant le nom du ou des packages récupérés.

Vous n'aurez plus qu'à ouvrir le "Package autonome Microsoft Update (.msu)" précédemment téléchargé et attendre sagement que les mises à jours s'installent.

Nota bene :

Microsoft n'a prévu aucun correctif pour le navigateur "Internet Explorer", la firme américaine vous propose simplement de télécharger et installer la dernière version disponible et bien entendu de faire les mises à jours via Windows update.

https://support.microsoft.com/en-us/kb/3125574

https://support.microsoft.com/en-us/kb/3156417

Comment désactiver la recherche Web ou paramétrer rapidement Cortona

Par défaut Cortana est paramétrée sur « recherche web et dans Windows ».

Pour en revenir à une recherche locale nous allons désactiver les fonctions non désirées, pour obtenir des résultats uniquement sur les applications et les fichiers de Windows.

Ouvrir « Paramètres » et faire une recherche sur Cortana ou Cliquer sur l’icône « Rechercher » et sélectionner l’icône « Paramètres »

Vous pouvez alors désactiver la recherche web entre autres.

Maintenant retrouver facilement vos applications en commençant à taper Wor ou Exce ou solit…

Cet outil permet d'exporter les imprimantes et ses pilotes d'un serveur à un autre tout en maintenant les paramètres.
Aussi simple d'utilisation que PrintMig, sur les plateformes antérieurs à Windows Server 2008-Windows Vista.
Le chemin de l'outil sur Windows Server 2012 R2 et Windows 10 
C:\Windows\System32\PrintBrmUi.exe (mode graphique) et
C:\Windows\System32\spool\tools>PrintBrm.exe (ligne de commande)

Mon serveur d'impression source est Windows Server 2008 R2 et la destination est un Windows Server 2012 R2.

Etape 1 - L'exportation à partir du serveur source.

Dans le menu déroulant en mode graphique, exporter vers un fichier. La liste complète d'imprimante est utilisée.

Un fichier de quelques centaines de Mo avec extension .printerExport est crée et sauvegardé à l’emplacement voulu.

Etape 2 - L'importation sur le serveur de destination.

La procédure est inverse.

> Importer les imprimantes depuis un fichier. Le fichier sélectionné est celui crée à l'étape précédente.

Etape 3 - Gestion d'erreurs

Lors de la première importation toutes les imprimantes n'ont pas été migrées à cause d'une série d'erreurs.

Justement une fois l'importation terminée, des erreurs sont signalées dans l'observatoire d'évènements, principalement dues aux pilotes.

Les pilotes importés ne sont pas compatibles avec l'architecture du serveur cible et ou Les pilotes natifs sont manquants Event ID 81, 22, 20, 18.

Le port de communication de certaines imprimantes est modifié par une redirection vers un fichier. (Queue d'impression d'une imprimante USB et partagée à partir d'un poste client)

Contournements ou résolutions

En uniformisant l'isolement du pilote, définir "aucun" au lieu de "partagé".

Installer en amont des pilotes récents et compatibles au serveur cible avant l’export, ou disposer de pilotes natifs ou constructeurs sur le serveur cible.

Les queues à destination d'imprimantes installées en USB sont à vérifier, un problème connu ne permet pas à PrintBrm de déterminer la disponibilité du chemin réseau relatif au port USB cible.

D’autres détails sur les Event ID de PRINTBRM https://technet.microsoft.com/en-us/library/cc773846%28v=ws.10%29.aspx

A la deuxième tentative 99% des queues actives sont migrées.