Mapper un lecteur réseau à utiliser par un service

Supposons que certains services Windows utilisent du code qui souhaite des lecteurs réseau mappés et aucun chemin UNC. Comment puis-je rendre le mappage de lecteur disponible pour la session du service lorsque le service est démarré? La connexion en tant qu'utilisateur du service et la création d'un mappage persistant n'établira pas le mappage dans le contexte du service réel.

Vous devrez soit modifier le service, soit l'envelopper dans un processus d'assistance: à part les problèmes d'accès aux sessions / lecteurs, les mappages de lecteurs persistants ne sont restaurés que lors d'une connexion interactive, ce que les services n'effectuent généralement pas.

L'approche du processus d'assistance peut être assez simple: il suffit de créer un nouveau service qui mappe le lecteur et démarre le «vrai» service. Les seules choses qui ne sont pas entièrement triviales à ce sujet sont:

• Le service d'assistance devra transmettre toutes les commandes SCM appropriées (démarrage / arrêt, etc.) au service réel. Si le vrai service accepte les commandes SCM personnalisées, n'oubliez pas de les transmettre également (je ne m'attends pas à ce qu'un service qui considère les chemins UNC exotiques utilise de telles commandes, cependant ...)

• Les choses peuvent devenir un peu délicates au niveau des informations d'identification. Si le service réel s'exécute sous un compte d'utilisateur normal, vous pouvez également exécuter le service d'assistance sous ce compte, et tout devrait être OK tant que le compte dispose d'un accès approprié au partage réseau. Si le vrai service ne fonctionne que lorsqu'il est exécuté en tant que LOCALSYSTEM ou quelque chose du genre, les choses deviennent plus intéressantes, car il ne pourra pas du tout `` voir '' le lecteur réseau ou nécessitera un jonglage d'informations d'identification pour que les choses fonctionnent.

Utilisez-le à vos risques et périls. (Je l'ai testé sur XP et Server 2008 x64 R2)

Pour ce hack, vous aurez besoin de SysinternalsSuite de Mark Russinovich :

Étape 1: Ouvrez une invite cmd.exe élevée (Exécuter en tant qu'administrateur)

Deuxième étape: élever à nouveau à la racine à l'aide de PSExec.exe: accédez au dossier contenant SysinternalsSuite et exécutez la commande suivante, psexec -i -s cmd.exe vous êtes maintenant à l'intérieur d'une invite qui est nt authority\systemet vous pouvez le prouver en tapant whoami. Le -iest nécessaire parce que les correspondances d'entraînement doivent interagir avec l'utilisateur

Étape 3: créer le lecteur mappé persistant en tant que compte SYSTEM avec la commande suivante net use z: \\servername\sharedfolder /persistent:yes

C'est si facile!

AVERTISSEMENT : vous ne pouvez supprimer ce mappage que de la même manière que vous l'avez créé, à partir du compte SYSTEM. Si vous devez le supprimer, suivez les étapes 1 et 2 mais remplacez la commande de l'étape 3 par net use z: /delete.

REMARQUE : Le lecteur mappé nouvellement créé apparaîtra maintenant pour TOUS les utilisateurs de ce système, mais ils le verront affiché comme "Lecteur réseau déconnecté (Z :)". Ne laissez pas le nom vous tromper. Il peut prétendre être déconnecté, mais cela fonctionnera pour tout le monde. Voilà comment vous pouvez dire que ce hack n'est pas pris en charge par M $.

J'ai trouvé une solution similaire à celle avec psexec mais fonctionne sans outils supplémentaires et survit à un redémarrage .

Ajoutez simplement une tâche planifiée, insérez "système" dans le champ "exécuter en tant que" et pointez la tâche vers un fichier de commandes avec la commande simple

net use z: \servername\sharedfolder /persistent:yes

Sélectionnez ensuite "exécuter au démarrage du système" (ou similaire, je n'ai pas de version anglaise) et vous avez terminé.

Une meilleure façon serait d'utiliser un lien symbolique à l'aide de mklink.exe. Vous pouvez simplement créer un lien dans le système de fichiers que n'importe quelle application peut utiliser. Voir http://en.wikipedia.org/wiki/NTFS_symbolic_link .

Il y a une bonne réponse ici: https://superuser.com/a/651015/299678

C'est-à-dire que vous pouvez utiliser un lien symbolique, par exemple

mklink /D C:\myLink \\127.0.0.1\c$

Vous pouvez nous utiliser la commande 'net use':

var p = System.Diagnostics.Process.Start("net.exe", "use K: \\\\Server\\path");
var isCompleted = p.WaitForExit(5000);

Si cela ne fonctionne pas dans un service, essayez Winapi et PInvoke WNetAddConnection2

Edit: Évidemment, je vous ai mal compris - vous ne pouvez pas changer le code source du service, non? Dans ce cas, je suivrais la suggestion de mdb , mais avec une petite torsion: créez votre propre service (appelons-le service de mappage) qui mappe le lecteur et ajoutez ce service de mappage aux dépendances du premier service (le travail réel). De cette façon, le service de travail ne démarre pas avant le démarrage du service de mappage (et le mappage du lecteur).

ForcePush,

REMARQUE : Le lecteur mappé nouvellement créé apparaîtra maintenant pour TOUS les utilisateurs de ce système, mais ils le verront affiché comme "Lecteur réseau déconnecté (Z :)". Ne laissez pas le nom vous tromper. Il peut prétendre être déconnecté, mais cela fonctionnera pour tout le monde. Voilà comment vous pouvez dire que ce hack n'est pas pris en charge par M $ ...

Tout dépend des autorisations de partage. Si vous avez Tout le monde dans les autorisations de partage, ce lecteur mappé sera accessible par d'autres utilisateurs. Mais si vous n'avez qu'un utilisateur particulier dont vous avez utilisé les informations d'identification dans votre script de commandes et que ce script de commandes a été ajouté aux scripts de démarrage, seul le compte système aura accès à ce partage, pas même l'administrateur. Ainsi, si vous utilisez, par exemple, un travail ntbackuo planifié, le compte système doit être utilisé dans «Exécuter en tant que». Si «Ouvrir une session en tant que: compte système local» de votre service, cela devrait fonctionner.

Ce que j'ai fait , je n'ai mappé aucune lettre de lecteur dans mon script de démarrage, j'ai simplement utilisé net use \\\server\share ...et utilisé le chemin UNC dans mes travaux planifiés. Ajout d'un script d'ouverture de session (ou tout simplement ajouter un fichier de commandes dans le dossier de démarrage) avec le mappage sur le même partage avec une lettre de lecteur: net use Z: \\\...avec les mêmes informations d'identification. L'utilisateur connecté peut maintenant voir et accéder à ce lecteur mappé. Il y a 2 connexions au même partage. Dans ce cas, l'utilisateur ne voit pas ce "lecteur réseau déconnecté ..." ennuyeux. Mais si vous avez vraiment besoin d'accéder à ce partage par la lettre de lecteur et pas seulement UNC, mappez ce partage avec les différentes lettres de lecteur, par exemple Y pour System et Z pour les utilisateurs.

Trouvé un moyen d'accorder l'accès du service Windows au lecteur réseau.

Prenez Windows Server 2012 avec NFS Disk par exemple:

Étape 1: écrire un fichier de commandes à monter.

Écrivez un fichier batch, ex: C: \ mount_nfs.bat

echo %time% >> c:\mount_nfs_log.txt
net use Z: \\{your ip}\{netdisk folder}\ >> C:\mount_nfs_log.txt 2>&1

Étape 2: Montez le disque en tant qu'AUTORITÉ / SYSTÈME NT.

Ouvrez le "Planificateur de tâches", créez une nouvelle tâche:

1. Exécutez en tant que "SYSTEM", à "System Startup".
2. Créer une action: exécutez "C: \ mount_nfs.bat".

Après ces deux étapes simples, mon service Windows ActiveMQ s'exécute sous le privilège "Système local", fonctionne parfaitement sans connexion.

La raison pour laquelle vous pouvez accéder au lecteur lorsque vous exécutez normalement l'exécutable à partir de l'invite de commande est que lorsque vous l'exécutez en tant qu'exe normal, vous exécutez cette application dans le compte utilisateur à partir duquel vous vous êtes connecté. Et cet utilisateur a les privilèges d'accéder au réseau. Mais, lorsque vous installez l'exécutable en tant que service, par défaut si vous voyez dans la tâche gérer il s'exécute sous le compte 'SYSTEM'. Et vous savez peut-être que le «SYSTÈME» n'a pas le droit d'accéder aux ressources réseau.

Il peut y avoir deux solutions à ce problème.

1. Pour mapper le lecteur aussi persistant que déjà indiqué ci-dessus.

2. Il existe une autre approche qui peut être suivie. Si vous ouvrez le gestionnaire de services en tapant «services.msc», vous pouvez accéder à votre service et dans les propriétés de votre service, il y a un onglet de connexion où vous pouvez spécifier le compte comme n'importe quel autre compte que «Système», vous pouvez soit démarrer le service à partir de votre propre compte utilisateur connecté ou via «Service réseau». Lorsque vous faites cela .. le service peut accéder à n'importe quel composant réseau et conduire même s'ils ne sont pas persistants également. Pour y parvenir par programme, vous pouvez examiner la fonction «CreateService» à l' adresse http://msdn.microsoft.com/en-us/library/ms682450(v=vs.85).aspx et définir le paramètre «lpServiceStartName» sur «NT AUTHORITY \ NetworkService '. Cela démarrera votre service sous «Service réseau»

3. Vous pouvez également essayer de rendre le service aussi interactif en spécifiant SERVICE_INTERACTIVE_PROCESS dans l'indicateur de paramètre servicetype de votre fonction CreateService (), mais cela ne sera limité que jusqu'à ce que XP comme Vista et 7 ne prennent pas en charge cette fonctionnalité.

J'espère que les solutions vous aideront. Faites-moi savoir si cela a fonctionné pour vous.

Vous ne devez pas changer l'utilisateur sous lequel le service est exécuté à partir de "Système" ou trouver un moyen sournois pour exécuter votre mappage en tant que système.

Ce qui est amusant, c'est que cela est possible en utilisant la commande "at" , il suffit de planifier le mappage de votre lecteur dans une minute dans le futur et il sera exécuté sous le compte système, rendant le lecteur visible pour votre service.

Au lieu de compter sur un lecteur persistant, vous pouvez définir le script pour mapper / démapper le lecteur chaque fois que vous l'utilisez:

net use Q: \\share.domain.com\share 
forfiles /p Q:\myfolder /s /m *.txt /d -0 /c "cmd /c del @path"
net use Q: /delete

Cela fonctionne pour moi.

Je ne peux pas encore commenter (travaillant sur la réputation), mais j'ai créé un compte juste pour répondre à @Tech Jerk @ spankmaster79 (joli nom lol) et aux problèmes @NMC qu'ils ont signalés en réponse au message "J'ai trouvé une solution similaire à celle avec psexec mais fonctionne sans outils supplémentaires et survit à un redémarrage. " post @Larry avait fait.

La solution à cela est de simplement parcourir ce dossier à partir du compte connecté, c'est-à-dire:

    \\servername\share  

et laissez-le vous inviter à vous connecter, et entrez les mêmes informations d'identification que vous avez utilisées pour l'UNC dans psexec. Après cela, il commence à fonctionner. Dans mon cas, je pense que c'est parce que le serveur avec le service n'est pas membre du même domaine que le serveur auquel je mappe. Je pense que si l'UNC et la tâche planifiée font référence à l'IP au lieu du nom d'hôte

    \\123.456.789.012\share 

cela peut éviter complètement le problème.

Si jamais j'obtiens suffisamment de points de répétition ici, j'ajouterai cela comme réponse à la place.