J'ai un dossier partagé réseau mappé sur une lettre de lecteur, accessible à partir de Windows Explorer, à partir de l'invite de commande ainsi que de mon application WinForms sans problème. Il est également accessible depuis mon service Windows à l'aide d'un chemin UNC.
Cependant, lorsque j'essaie d'accéder à cet emplacement de réseau à l'aide d'une lettre de lecteur mappée du service Windows, l'accès échoue. Le service Windows est configuré pour utiliser mes identifiants de compte "Connexion" personnels, ce qui est le même dans tous les cas ci-dessus. Je suis un administrateur.
De nombreux sites clients utilisent des lettres de lecteur pour des actions réseau et je ne peux pas toujours le contrôler et les forcer à spécifier à la place des chemins UNC. Je dois pouvoir accéder aux actions réseau à l'aide de lettres de lecteur à partir d'un service Windows.
Que dois-je faire pour configurer mon service Windows, de sorte qu'il puisse accéder à des dossiers partagés réseau mappés sur des lettres d'entraînement? Mon service Windows est écrit en C #.
3 Réponses :
Les lecteurs mappés sont des objets de session. Chaque session interactive a donc sa propre cartographie et la session de service a une autre cartographie du lecteur. Afin d'obtenir le chemin UNC correct d'un lecteur mappé, vous devez appeler WnegetPonnection dans la bonne session.
Vous pouvez utiliser toutes les méthodes de communication inter-session pour lancer la demande et obtenir le résultat dans le service, tel que WCF, tuyau nommé, sockets, etc.
Merci beaucoup. J'ai pu convertir la lettre de lecteur au chemin UNC en utilisant Pinvoke et WnetGetConnection!
désolé; Vous ne pouvez pas accéder aux lecteurs mappés de Windows Services . Comme Sheng vous l'a suggéré, vous pouvez utiliser un processus d'interface utilisateur pour obtenir le chemin UNC à partir d'un lecteur mappé, puis transmettre ceci au service, qui doit utiliser le chemin UNC.
Merci pour l'article. Microsoft précise qu'il ne faut pas accéder aux disques mappés d'un service Windows.
L'article cité indique uniquement que les services ne doivent pas utiliser ou modifier des mappages de conduite, que ne signifie pas ne peut pas être fait. Dans l'article MSP de KB, il implique même une telle quand il est indiqué: "Par conséquent, les lecteurs redirigés ne peuvent pas être partagés entre des processus fonctionnant sous différents comptes d'utilisateurs." En d'autres termes, la session de connexion et le service doivent être exécutées sous les mêmes informations d'identification. Ça peut être fait.
@Garen: chaque version majeure de Windows augmente la séparation entre les services et le code de bureau, pour des raisons de sécurité. Il sont façons de le forcer à travailler maintenant. Il y avait aussi des moyens de le forcer sur des versions de Windows antérieures qui ne fonctionnent plus. Ce n'est pas pris en charge; Vous ne créeriez que créer un produit qui peut casser une future version Windows. (Je parle d'expérience ...)
L'affirmation selon laquelle on "ne peut pas accéder aux lecteurs mappés" est le problème, qui est une fausse déclaration. Les meilleures pratiques sont entièrement un sujet différent.
Vous ne pouvez pas accéder aux lecteurs mappés dans le même sens que vous ne pouvez pas masquer votre processus auprès de Task Manager. Les deux sont possibles, mais ne peut pas être fait en utilisant les API documentées fournies. Vous pouvez pirater une solution pour faire les deux, et les deux hacks vont casser sur des versions différentes / futures de Windows.
Et la vieille question, mais toujours pertinente. Le service en question est le service de construction TFS. Il construit notre projet, qui comprend une procédure de construction DOJO, qui doit accéder à une ressource partagée. Malheureusement, Dojo Build suppose que tout est local, il ne comprend donc ni des chemins UNC ni fichier: // URL. Nous avons donc recours à un lecteur mappé. Mais alors le service de construction TFS ne respecte pas la cartographie! Maintenant, je peux supprimer et recréer le mappage du script de construction et cela fonctionne. Que feriez-vous?
@mark: vos seules options prises en charge sont de corriger le dojo ou de copier la ressource partagée localement à votre machine de construction dans le cadre de votre construction. Vous avez mentionné que «cela fonctionne» pour créer un mappage du service, qui est partiellement vrai. Ça marche sur cette version de Windows ; Ceci n'est toujours pas pris en charge et Windows a modifié ce comportement dans le passé . To citation , "Bien que la [mapping lecteur] Les API peuvent revenir avec succès, les résultats seront incorrects. "
@StephenCleary: Je pense avoir une autre solution - un lien symbolique vers un dossier partagé à l'aide de la commande mklink / d. Êtes-vous au courant des raisons pour lesquelles il ne pouvait être une alternative acceptable?
@mark: Tant que le lien utilise UNC, ça devrait aller bien.
@Stephencleary: Il utilise l'UNC. Merci.
hi elan je suis confronté au même problème dans mon projet et j'ai trouvé une solution
et est que le travail est attendu Suivez mes étapes im en utilisant le script d'application hérité Objet du système de fichiers VB FSO 1, assurez-vous que votre chemin de carte accède à Iuer et à l'accès au service réseau Activez la machine fournie mappée.
2, ajout du script du système de référence 3 et de l'exemple de chemin UNC \ ComputerName \ SharedName \ Dossier \ FileName
4, juste fso.copyfile (CASPATH, TEMPFOLERER, VRAI)
5, vous accédez à un dossier de votre fichier, il est accessible attendu et travail parfait l'accès au dossier Temp "C: \ Windows \ Temp car la procédure peut prendre le dossier Temps Windows uniquement espérons que vous elan, il travaille parfaitement merci et regarde Jagadeesh Govindaraj Pillai
jagadeesh1492@facebook.com