Retour vers la synthèse des nouveautés de Powerpivot V2.

D’autres articles à venir sur les autres nouveautés…

Symptômes :

Le problème se manifeste par un « blocage technique » de Visual Studio (avec perte de la main) d’une durée de 8 à 15 minutes lorsque :

• l’on ouvre un fichier de flux SSIS (*.dtsx)
• l’on lance une exécution de flux SSIS (*.dtsx) en mode debug, (l’attente déclenchant généralement un timeout sur le « fork » du processus de debug de Visual Studio cf. ci-après)

Ce blocage est indépendant du processus (normal) de vérification des lots du package, qui intervient une fois les 8/15 minutes de blocage technique passées.

Ce problème persiste :

• au changement de user
• au changement de machines
• à la bascule des fichiers et/ou bases de données en local

Le retard à l’exécution est parfois tellement important que le « fork » du thread de debug par rapport au thread de Visual Studio, passe en « time out », provoquant le message d’erreur suivant :

Une fois que le « fork » a échoué une fois, toute les autres tentatives échoueront venant s’ « empiler » par process ID :

Pour qu’un nouveau test d’exécution de flux en mode debug soit de nouveau effectif, il faut réinitialiser les paramètres utilisateur de Visual Studio :

• Menu Démarrer -> Exécuter -> ‘devenv /resetsettings‘

Analyse :

Une analyse poussée du problème a permis de se rendre compte :

• lorsque le problème se manifeste, une connexion HTTP est effectuée vers un serveur distant de Microsoft (crl.microsoft.com) visible avec la commande MS-DOS NETSTAT
• cette connexion est bloquée en attente de réponse (statut SYN_SENT) (voir la copie d’écran ci-jointe)
• au bout des 10 à 15 minutes d’attente cette connexion se ferme et le fichier s’ouvre/s’exécute -> cette connexion en attente est à l’origine du problème
• CRL veut dire « Certificate Revocation List« , et cette connexion automatique est une vérification de licence/certificat
• une ouverture/exécution de flux à partir d’une connexion avec un compte local (hors domaine) sur les machines concernées par le problème, ne pose pas de souci -> avec un compte local la vérification de licence n’est pas effectuée

Il semble donc qu’il s’agisse soit d’un problème de domaine utilisateur, soit de proxy/firewall qui refuse la connexion HTTP vers le site de vérification de licence.
Le compte local doit être considéré comme « suffisamment sûr » par Microsoft pour ne pas effectuer de vérification de certificat.

En attendant, l’installation du SP2 de SQL-Server 2005 sur le poste ne change rien au problème ci-dessus.

Solution/Palliatif :

Au final on peut désactiver cette vérification de certificat en effectuant les opérations suivantes :

1. Dans les options avancées d’Internet Explorer décocher les cases « Vérification de révocations des certificats »
2. Changer la valeur de la base de registre [HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]< de ‘23c00‘ à ‘23e00‘

(source : http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125768 )

Ces manipulations, semblent corriger définitivement le problème (par contre la première est à effectuer pour chaque utilisateur utilisant le poste). En attente d’une plus ample utilisation pour confirmation.
Les utilisateurs appartenant à des domaines sont probablement configurés pour faire ces vérifications de certificats par défaut, tandis que les utilisateurs locaux ne les font pas, ce qui peut expliquer les différences que nous constations.

Sources :

• http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125768
• http://www.bizbert.com/bizbert/default,date,2007-04-01.aspx