Comportement étrange dans le client de service Web .NET lorsqu'il n'est PAS exécuté en tant qu'administrateur local

Question

Nous avons rencontré une situation très étrange lorsque nous avons déployé une application sur un site client. Cette application est implémentée en tant que service utilisant C# sur .NET 3. L'application communique avec un service Web écrit à l'aide de gSOAP. Dans notre application .NET, les classes qui enveloppent le service Web ont été créées en exécutant "Ajouter un service" dans Visual Studio et en référençant le WSDL. La communication est effectuée en utilisant HTTPS, mais en utilisant le port 35000.

Ce que nous voyons est que lorsque notre application s'exécute en tant que "compte administrateur local" tout fonctionne bien. Cependant, lorsque notre application s'exécute comme n'importe quel autre compte, y compris «compte système local» et même un compte d'utilisateur avec des privilèges d'administrateur réseau, les appels de méthode de service Web arrivent parfois à expiration. D'autres fois, ils réussissent mais après très, très longtemps, par ex. 100 secondes au lieu de moins de 1 seconde comme prévu.

Ce client utilise des commutateurs Cisco sur son réseau.

Nous n'avons pas rencontré ce comportement sur d'autres sites. Toute idée ou suggestion serait grandement appréciée.

Answer 1

Tous les messages du journal des événements pour les délais d'attente, les exceptions, etc.

L'application est-elle un service Windows? Utilisez-vous RunAs pour fonctionner dans un contexte utilisateur différent? Cela nécessite-t-il une interaction avec le bureau ou des références à System.Windows.Forms?

@Comment 1: Service Windows, service Web, service WCF?

Enable security auditing pour les machines locales et distantes pour les ressources que le service est susceptible d'utiliser.

Une autre chose est d'ajouter la journalisation de niveau de débogage comme ça ... (Désolé pour le pseudo VB)

Sub OnStart(args()) 
LogToFile("Starting Service, processing arguments") 
'process args' 
LogToFile("ArgsProcessed calling main worker method") 
'call main worker method' 
End OnStart 

Sub LogToFile(message as String) 
If (AppConfigKeys[debugLogging] = True) Then 
    'writes "DateTime.Now.ToString() & "-" & message" to a text file log' 
End If 
End Sub 

Intégrer ce genre de connexion à l'application avant et après tout processus qui est susceptible d'échouer.

Answer 2

Le client dispose-t-il de règles BI sur le matériel du pare-feu? (Je saisis les pailles, mais nous avons eu un comportement similaire de la part d'un de nos clients consommant un de nos services il y a quelques années car ils avaient activé certaines règles BI sur le firewall.)