Pourquoi un travail du Planificateur de tâches ne peut-il pas accéder à un lecteur réseau mappé?

J'ai un travail du Planificateur de tâches pour exécuter Robocopy pour sauvegarder les fichiers locaux sur un partage réseau. Je dois utiliser les informations d'identification du domaine pour accéder au partage réseau, mais l'ordinateur local n'est pas sur le domaine et le travail est exécuté en tant qu'administrateur local. Cette solutionde mapper et de démapper temporairement le partage réseau fonctionne, mais cela laisse mon mot de passe exposé en texte brut pour toute personne qui regarde les actions du planificateur de tâches. Je préférerais mapper le lecteur réseau normalement sur une base semi-permanente afin que le travail du Planificateur de tâches n'ait qu'à exécuter Robocopy et se référer à la lettre de lecteur appropriée. Cependant, j'obtiens toujours l'erreur "Le système ne trouve pas le chemin spécifié." dans le journal Robocopy lors de l'exécution à partir du Planificateur de tâches, même si la commande fonctionne correctement à partir d'une invite de commandes élevée (le travail est configuré pour s'exécuter avec les privilèges les plus élevés). Notez également que j'ai effectué cette modification du registre pour accéder aux lecteurs mappés à partir d'une invite de commande élevée.

EDIT: Pour clarifier, connecté en tant qu'administrateur local, je lance Windows Explorer en tant qu'administrateur. Je mappe le partage réseau à la lettre de lecteur Y. Je lance l'invite de commande en tant qu'administrateur et exécute

C:\Windows\System32\Robocopy.exe C:\temp Y:\temp

Fonctionne bien. Je crée un travail du Planificateur de tâches pour exécuter exactement la même commande, que l'utilisateur soit connecté ou non, avec les privilèges les plus élevés. Je l'exécute et j'obtiens une erreur. J'écris dans un journal et j'obtiens

ERROR 3 (0x00000003) Getting File System Type of Destination Y:\temp\
The system cannot find the path specified.

suivi par

ERROR 3 (0x00000003) Creating Destination Directory Y:\temp\
The system cannot find the path specified.

Les lecteurs mappés sont un concept d'interface utilisateur et ne sont pas disponibles pour des tâches d'arrière-plan comme celle-ci. Accédez à la cible via UNC et assurez-vous que l'utilisateur sous lequel la tâche s'exécute a accès à la cible.

Dans mon cas, tout ce que je devais faire était de décocher le run with highest privilegesdrapeau, mais j'exécutais la tâche sur le même utilisateur que l'utilisateur qui avait mappé le lecteur.

Essayez d'utiliser:

pushd \\machine\share

dans un fichier de commandes de votre tâche planifiée. Les lecteurs partagés en réseau ne sont disponibles que dans un environnement géré par l'utilisateur. "pushd" permettra de l'exécuter dans le contexte du script.

Lorsque vous avez terminé, utilisez:

popd \\machine\share

pour démapper le lecteur.

Référence: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html

Une autre option consiste simplement à utiliser le chemin d'accès réseau complet, car Robocopy les prend en charge. ie robocopy c: \ temp \\ server \ share \ temp

Ou mieux encore, exécutez la sauvegarde sur le serveur lui-même. Créez un compte d'administrateur de domaine uniquement pour le processus de sauvegarde. Feed robocopy le mot de passe à partir d'un fichier texte auquel seuls les administrateurs de domaine peuvent accéder.

Il y a des années, j'ai créé plusieurs scripts .cmd qui permettraient de sauvegarder les fichiers essentiels pour chaque système du réseau de cette façon. Le seul programme externe que j'ai utilisé était la commande Grep de Cgywin et un expéditeur de messagerie smtp à l'invite de commandes.

J'ai fait un script qui scannerait le réseau pour les systèmes. Il créerait un fichier texte de tous les noms de système et m'alerterait par e-mail de tout nouveau système qu'il aurait trouvé. (J'avais un fichier de configuration qu'il analyserait pour les systèmes à ignorer.) Chaque nouveau système avait un répertoire de sauvegarde créé pour lui et un fichier de configuration de sauvegarde placé dedans. L'utilisateur peut modifier ce fichier et répertorier tous les répertoires qui doivent être sauvegardés. Ils pouvaient également spécifier l'heure de leurs sauvegardes afin que cela ne se produise pas lorsqu'ils étaient au bureau. J'ai exécuté ce script sur le serveur toutes les 5 minutes, car cela n'a pris aucun temps de traitement et j'aime la fonction de sécurité de m'alerter lorsqu'un nouveau système a été branché sur le réseau.

Un autre script analyserait tous les fichiers de configuration de sauvegarde individuels et planifierait une tâche pour exécuter une sauvegarde sur ce système. Cela a été exécuté tous les jours à 00h01.

Enfin, le script de sauvegarde analysera le fichier de configuration qui lui a été transmis par le planificateur et à l'aide de robocopy copiera tous les fichiers. J'ai eu une vérification complète des erreurs sur les fichiers de configuration car les utilisateurs les éditeraient et je recevrais des e-mails en cas de problème.

Les utilisateurs pouvaient lire leurs fichiers de sauvegarde, mais ne pouvaient pas supprimer la sauvegarde. Cela a fourni une certaine protection contre les dommages causés par un éventuel employé mécontent.

Probablement quelque chose de beaucoup plus élégant aurait pu être fait en .vbs ou powershell, mais je ne suis pas vraiment un programmeur. Mes cours de programmation incluaient Cobal et JCL. Je me souviens avoir copié les scripts quand je suis parti, mais qui sait où ils sont maintenant.

J'ai surmonté le problème en modifiant l'option «Exécuter si l'utilisateur est connecté ou non» à «Exécuter uniquement lorsque l'utilisateur est connecté». Essayez ceci, cela peut vous aider.

echo Get-Date >> c:\mount_nfs_log.txt
net use X: \\share\folder password /user:domain\user>> c:\mount_nfs_log.txt 2>&1

La création de ce script PowerShell, la planification du travail en tant que SYSTEM et sa configuration pour s'exécuter au redémarrage m'ont permis d'utiliser des lettres de lecteur dans mes scripts, car UNC n'est pas une option en raison d'un mal de tête lié à d'autres problèmes.

Essayez de changer l'emplacement "start in" en "c: \". Cela a semblé le réparer pour moi, alors peut-être que le système empêchait le cmd.exe de s'exécuter à partir du \ windows \ system32 \ par défaut comme fonction de sécurité.

J'ai eu le même problème en essayant d'accéder à r: /xxxfilename.txt avec un lecteur mappé Windows r: \ server \ share lors de l'appel d'un script à partir du planificateur de tâches Windows.

J'ai résolu en utilisant //server/share/xxxfilename.txt
Veuillez noter la barre oblique inversée convertie en barre oblique.
Maintenant, mon script bash cygwin s'exécute dans le planificateur de tâches Windows et le shell cygwin.
Remarque: la commande " net use " peut accéder aux lecteurs de carte dans le shell mais affiche R non disponible: lorsque j'exécute cette commande dans le Planificateur de tâches Windows.

Comme un autre utilisateur l'a noté, le fait de définir l'option "Exécuter si l'utilisateur est connecté ou non" sur "Exécuter uniquement lorsque l'utilisateur est connecté" semble fonctionner. Vous pouvez ensuite utiliser le chemin mappé (par exemple Z :) ou le chemin du serveur (par exemple \\ ServerName \ Path).

Bien sûr, si vous utilisez cette option, vous devez faire ce qui est indiqué et vous assurer que vous vous êtes connecté au serveur en tant qu'utilisateur ayant accès au lecteur correspondant. Je me souviens avoir été dans une entreprise plus ancienne avec un certain nombre d'emplois comme celui-ci. Un jour, quelqu'un s'est «déconnecté» du serveur principal des travaux, ne s'attendant pas à ce que cela ait un impact, car il n'a pas arrêté la machine de quelque façon que ce soit ...

De plus, ces jours-ci, Windows aime faire beaucoup de redémarrages du système auto-invoqués. Utilisez donc cette solution à vos risques et périls.

Notez également que si vous effectuez le mappage dans le script et que le mot de passe contient%, il doit être écrit %% pour que le script fonctionne à partir du planificateur de tâches mais% pour fonctionner à partir de l'invite de commandes

on peut utiliser les commandes suivantes, à ajouter dans le script batch lui-même, pour exécuter le script batch à partir de la tâche de planification Windows pour obtenir dir, fichier copié sur le système local à l'aide de la tâche de planification Windows; utilisation nette Y: "\\ xxx \ xxx \ xxx cd / d Y: utilisateur net / d Y: / Y

Merci, je pense que l'utilisation de "démarrer en c: \" a résolu mon problème, je suivrai ce problème pour confirmer qu'il est résolu.

J'avais le même problème, si je cliquais directement sur le lot, il fonctionnait parfaitement mais pas sous la tâche planifiée.