Mapper un lecteur réseau à utiliser par un service

Supposons qu’un service Windows utilise du code qui nécessite des lecteurs réseau mappés et aucun chemin UNC. Comment puis-je rendre le mappage de lecteur disponible pour la session du service au démarrage du service? La connexion en tant qu’utilisateur du service et la création d’un mappage persistant n’établissent pas le mappage dans le contexte du service réel.

    Vous devrez soit modifier le service, soit l’envelopper dans un processus d’assistance: hormis les problèmes d’access de session / lecteur, les mappages de lecteurs persistants ne sont restaurés que sur une ouverture de session interactive, que les services n’effectuent généralement pas.

    L’approche par processus d’assistance peut être assez simple: créez simplement un nouveau service qui mappe le lecteur et lance le service «réel». Les seules choses qui ne sont pas totalement insignifiantes sont les suivantes:

    • Le service d’assistance devra transmettre toutes les commandes SCM appropriées (start / stop, etc.) au service réel. Si le service réel accepte les commandes SCM personnalisées, n’oubliez pas de les activer é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 être un peu compliquées en termes de justificatifs d’identité. 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 correct tant que le compte dispose d’un access approprié au partage réseau. Si le service réel ne fonctionne que lorsqu’il est exécuté en tant que LOCALSYSTEM ou tout simplement, les choses deviennent plus intéressantes, car il ne sera pas capable de «voir» le lecteur réseau ou nécessitera un jonglage des informations d’identification pour que les choses fonctionnent.

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

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

    Etape 1: Ouvrez une invite cmd.exe élevée (Exécuter en tant qu’administrateur)

    Etape 2: Relancez à nouveau en utilisant PSExec.exe: Naviguez jusqu’au dossier contenant SysinternalsSuite et exécutez la commande suivante psexec -i -s cmd.exe vous êtes maintenant dans une invite qui n’est pas d’ nt authority\system et vous pouvez le prouver par taper whoami . Le -i est nécessaire car les mappages de lecteurs doivent interagir avec l’utilisateur

    Troisième étape: Créez 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 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 changez la commande de l’étape 3 pour net use z: /delete .

    REMARQUE : Le lecteur mappé nouvellement créé apparaît désormais pour TOUS les utilisateurs de ce système, mais il apparaîtra 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. C’est comme ça que vous pouvez dire que ce hack n’est pas supporté par M $.

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

    Ajoutez simplement une tâche planifiée, insérez “system” 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 

    Ensuite, sélectionnez “exécuter au démarrage du système” (ou similaire, je n’ai pas de version anglaise) et vous avez terminé.

    Un meilleur moyen serait d’utiliser un lien symbolique en utilisant mklink.exe. Vous pouvez simplement créer un lien dans le système de fichiers que toute application peut utiliser. Voir http://en.wikipedia.org/wiki/NTFS_symbolic_link .

    Vous pourriez nous 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 le WNetAddConnection2 Winapi et PInvoke

    Edit: Evidemment je vous ai mal compris – vous ne pouvez pas changer le code source du service, non? Dans ce cas, je voudrais suivre la suggestion de mdb , mais avec un petit changement: créez votre propre service (appelons-le service de mappage) qui mappe le lecteur et ajoute ce service de mappage aux dépendances du premier service (le fonctionnement réel). De cette façon, le service de travail ne démarrera pas avant que le service de mappage ait démarré (et mappé le lecteur).

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

    Ie Vous pouvez utiliser un lien symbolique, par exemple

     mklink /DC:\myLink \\127.0.0.1\c$ 

    ForcePush,

    REMARQUE : Le lecteur mappé nouvellement créé apparaît désormais pour TOUS les utilisateurs de ce système, mais il apparaîtra 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 supporté par M $ …

    Tout dépend des permissions de partage. Si vous disposez de tous les droits de partage, ce lecteur mappé sera accessible par les autres utilisateurs. Mais si vous ne disposez que d’un utilisateur particulier dont vous avez utilisé les informations d’identification dans votre script de commandes et que ce script a été ajouté aux scripts de démarrage, seul le compte Système aura access à ce partage, même pas à Administrateur. Donc, si vous utilisez, par exemple, un travail ntbackuo planifié, le compte système doit être utilisé dans «Exécuter en tant que». Si votre service est “Connectez-vous en tant que: compte système local”, cela devrait fonctionner.

    Ce que j’ai fait , je n’ai pas mappé de lettre de lecteur dans mon script de démarrage, j’ai simplement utilisé net use \\\server\share ... et utilisé le chemin UNC dans mes tâches planifiées. Ajout d’un script d’ouverture de session (ou ajoutez simplement un fichier de commandes au dossier de démarrage) avec le mappage vers le même partage avec une lettre de lecteur: net use Z: \\\... avec les mêmes informations d’identification. Maintenant, l’utilisateur connecté peut 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 “disque réseau déconnecté …”. Mais si vous avez vraiment besoin d’accéder à ce partage par la lettre du lecteur, pas seulement UNC, mappez ce partage avec les différentes lettres de lecteur, par exemple Y pour System et Z pour les utilisateurs.

    Vous avez trouvé un moyen d’accorder au service Windows un access au lecteur réseau.

    Prenez Windows Server 2012 avec NFS Disk par exemple:

    Etape 1: Ecrivez un fichier batch sur le assembly.

    Écrivez un fichier de commandes, 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: monter le disque en tant que NT AUTHORITY / SYSTEM.

    Ouvrez “Planificateur de tâches”, créez une nouvelle tâche:

    1. Exécuter en tant que “SYSTEM”, au “démarrage du système”.
    2. Créer une action: Exécutez “C: \ mount_nfs.bat”.

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

    La raison pour laquelle vous êtes en mesure d’accéder au lecteur lorsque vous exécutez normalement l’exécutable à partir de l’invite de commandes est que lorsque vous l’exécutez comme un exécutable normal, vous exécutez cette application sur le compte d’utilisateur à partir duquel vous vous êtes connecté. Et cet utilisateur a les privilèges pour accéder au réseau. Mais, lorsque vous installez l’exécutable en tant que service, par défaut, si vous le voyez dans la tâche, le gérer 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 du réseau.

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

    1. Pour mapper le lecteur comme persistant, comme indiqué ci-dessus.

    2. Une autre approche peut être suivie. Si vous ouvrez le gestionnaire de services en tapant le fichier “services.msc”, vous pouvez accéder à votre service et dans les propriétés de votre service, il existe un onglet logOn dans lequel vous pouvez spécifier le compte comme “Système” démarrer le service à partir de votre propre compte d’utilisateur connecté ou via «Service réseau». Lorsque vous faites cela, le service peut accéder à tout composant et lecteur réseau même s’ils ne sont pas persistants. Pour y parvenir par programmation, vous pouvez consulter 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 le compte “Service réseau” et vous aurez terminé.

    3. Vous pouvez également essayer en rendant le service 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’à XP car 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 voulez pas modifier l’utilisateur sous lequel le service s’exécute à partir de «système» ou trouver un moyen sournois d’exécuter votre mappage en tant que système.

    La chose amusante est que cela est possible en utilisant la commande “at” , programmez simplement votre lecteur en mappant une minute dans le futur et il sera exécuté sous le compte système rendant le lecteur visible à votre service.

    Je ne peux pas encore commenter (travaillant sur la réputation) mais créé un compte juste pour répondre à @Tech Jerk @ spankmaster79 (nom gentil lol) et aux problèmes de @NMC qu’ils ont rapportés en réponse à la “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 consiste à naviguer dans ce dossier à partir du compte connecté, à savoir:

      \\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 se réfèrent tous deux à 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 reps ici, j’appendai ceci en guise de reponse.

    Au lieu de compter sur un lecteur persistant, vous pouvez définir le script pour mapper / désappeler 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.