Récemment, j’ai rencontré une demande de client concernant des problèmes de connectivité entre SSIS sur le serveur de base de données et un serveur d’application. Le client recevait le message d’erreur suivant : “La connexion au service Integration Services sur l’ordinateur ‘SQL’ a échoué avec l’erreur suivante : ‘Classe non enregistrée’.”

Après avoir analysé le message d’erreur, il est apparu que le problème était lié à un problème d’enregistrement ou de DLL manquantes. Ce n’était pas un problème de sécurité ou de blocage de connexion. Pour commencer le dépannage, j’ai vérifié les versions de SSIS et SSMS sur le serveur d’application et j’ai découvert une incompatibilité de version. Il est crucial que les versions de SSIS et SSMS correspondent afin d’établir une connexion réussie.

Initialement, je pensais que la mise à niveau de la version de SSMS sur le serveur d’application résoudrait le problème. Cependant, même après la mise à niveau, j’ai rencontré un message d’erreur différent : “Le serveur RPC n’est pas disponible. (Exception de HRESULT : 0x800706BA) (Microsoft.SqlServer.DTSRuntimeWrap)”.

Dans cet environnement particulier, SQL Server 2016 fonctionnait en tant qu’instance nommée sur un port statique. La connexion de l’application n’était pas membre du groupe d’administrateurs local sur le serveur de base de données, conformément aux normes de l’entreprise. Pour poursuivre le dépannage, j’ai suivi ces étapes :

1. Vérifié que le service RPC était en cours d’exécution, comme indiqué par le message d’erreur.
2. Assuré que la sécurité était correctement configurée pour SSIS dans le groupe d’administrateurs et les autorisations DCOM, même s’il n’y avait pas d’erreurs liées aux autorisations.
3. Testé la connexion sur le port 135 du serveur d’application au serveur de base de données à l’aide de la commande telnet, car SSIS utilise ce numéro de port.

Malgré l’exécution de ces étapes, l’application ne parvenait toujours pas à se connecter à SSIS. À ce stade, j’ai écarté les autorisations comme cause de l’erreur et envisagé d’autres possibilités, telles que des problèmes de réseau ou de blocage de connexion. Étant donné que les pare-feu sont généralement activés sur les serveurs de base de données dans la plupart des entreprises, j’ai soupçonné que le pare-feu pouvait bloquer la connexion.

Pour tester cette hypothèse, j’ai temporairement désactivé le pare-feu en dehors des heures de production et j’ai constaté que la connexion commençait à fonctionner. Cependant, il était essentiel de réactiver le pare-feu et d’enquêter davantage sur le problème à l’aide de la commande netstat. J’ai découvert que SSIS n’utilisait pas le port 135, mais qu’il fonctionnait sur une plage de ports supérieurs (dynamiques) qui changeaient à chaque redémarrage du service.

Pour résoudre le problème, j’ai dû m’assurer que tous les ports dynamiques dans la plage de 49152 à 65535 étaient ouverts et que toutes les connexions étaient autorisées à partir de MsDtsSrvr.exe. J’ai créé une règle dans le pare-feu Windows sur le serveur de base de données, en spécifiant la configuration de la règle entrante comme suit :

• Nom de la règle : Test_RPC1
• Direction de la règle : Entrante
• Action de la règle : Autoriser la connexion
• Protocole : TCP
• IP locale : (10.10.xx.xx)
• IP distante : Adresse IP du serveur d’application – APP1
• Port local : (vide)
• Port distant : 49152-65535

Après avoir mis en place cette règle, le problème de connectivité a été résolu avec succès et le client a pu se connecter à SSIS sans aucun autre problème.

Il est important de noter que le dépannage des problèmes de connexion SSIS nécessite une approche systématique, en tenant compte de facteurs tels que la compatibilité des versions, les autorisations, la configuration réseau et les paramètres du pare-feu. En suivant les étapes décrites dans cet article, vous pouvez diagnostiquer et résoudre efficacement des problèmes similaires dans votre environnement SQL Server.