Por que um trabalho do Agendador de tarefas não pode acessar uma unidade de rede mapeada?

Eu tenho um trabalho do Agendador de tarefas para executar o Robocopy para fazer backup de arquivos locais em um compartilhamento de rede. Preciso usar credenciais de domínio para acessar o compartilhamento de rede, mas o computador local não está no domínio e o trabalho é executado como administrador local. Esta soluçãode mapear e remover o mapeamento temporariamente do compartilhamento de rede funciona, mas deixa minha senha exposta em texto sem formatação para quem observar as ações da tarefa do Agendador de Tarefas. Eu preferiria mapear a unidade de rede normalmente de forma semi-permanente, para que o trabalho do Agendador de tarefas apenas execute o Robocopy e consulte a letra da unidade apropriada. No entanto, sempre recebo o erro "O sistema não consegue encontrar o caminho especificado". no log do Robocopy ao executar isso no Agendador de tarefas, mesmo que o comando funcione bem em um prompt de comando elevado (o trabalho está definido para ser executado com os privilégios mais altos). Observe também que fiz esse ajuste no registro para acessar unidades mapeadas em um prompt de comando elevado.

EDIT: Para esclarecer, logado como administrador local, inicio o Windows Explorer como administrador. Mapeio o compartilhamento de rede para a letra da unidade Y. Ativo o prompt de comando como administrador e executo

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

Funciona bem. Eu crio um trabalho do Agendador de tarefas para executar exatamente o mesmo comando, esteja o usuário conectado ou não, com os privilégios mais altos. Eu corro e recebo um erro. Escrevo para um log e recebo

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

Seguido por

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

As unidades mapeadas são um conceito de interface do usuário e não estão disponíveis para tarefas em segundo plano como essa. Acesse o destino via UNC e verifique se o usuário que executa a tarefa tem acesso ao destino.

No meu caso, tudo o que tive que fazer foi desmarcar a run with highest privilegesbandeira, mas estou executando a tarefa no mesmo usuário que o usuário que mapeou a unidade.

Tente usar:

pushd \\machine\share

dentro de um arquivo em lotes da sua tarefa agendada. As unidades compartilhadas de rede estão disponíveis apenas em um ambiente executado pelo usuário. "pushd" permitirá que seja executado no contexto do script.

Quando terminar, use:

popd \\machine\share

para remover o mapeamento da unidade.

Referência: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html

Outra opção é apenas usar o caminho completo da rede, pois o Robocopy os suporta. ou seja, robocopy c: \ temp \\ servidor \ compartilhamento \ temp

Ou melhor ainda, execute o backup no próprio servidor. Crie uma conta de administrador de domínio apenas para o processo de backup. O feed copia a senha de um arquivo de texto que somente administradores de domínio podem acessar.

Anos atrás, criei vários scripts .cmd que faziam backup de arquivos essenciais para todos os sistemas da rede dessa maneira. O único programa externo que usei foi o comando Grep do Cgywin e um remetente de email smtp do prompt de comando.

Eu criei um script que varreria a rede em busca de sistemas. Ele criaria um arquivo de texto com todos os nomes do sistema e me alertaria por e-mail de todos os novos sistemas encontrados. (Eu tinha um arquivo de configuração que ele analisaria para os sistemas pularem.) Cada novo sistema tinha um diretório de backup criado para ele e um arquivo de configuração de backup nele. O usuário pode modificar esse arquivo e listar todos os diretórios necessários para o backup. Eles também poderiam especificar a hora de seus backups, para que isso não acontecesse quando eles estivessem no escritório. Executei esse script no servidor a cada 5 minutos, pois não demorou tempo de processamento e eu gosto do recurso de segurança de me alertar quando um novo sistema foi conectado à rede.

Outro script analisaria todos os arquivos de configuração de backup individuais e agendaria uma tarefa para executar um backup nesse sistema. Isso acontecia diariamente às 12h01.

Finalmente, o script de backup analisaria o arquivo de configuração que foi passado pelo planejador e o uso de robocopy copiaria todos os arquivos. Eu tive uma verificação de erro total nos arquivos de configuração, já que os usuários os editavam e recebia e-mails com problemas.

Os usuários puderam ler seus arquivos de backup, mas não puderam excluir o backup. Isso forneceu alguma proteção contra danos de um possível funcionário insatisfeito.

Provavelmente algo muito mais elegante poderia ter sido feito em .vbs ou powershell, mas eu não sou realmente um programador. Minhas aulas de programação incluíam Cobal e JCL. Lembro que copiei os scripts quando saí, mas quem sabe onde eles estão agora.

Eu superei o problema alterando a opção "Executar se o usuário está conectado ou não" para "Executar apenas quando o usuário está conectado". Tente isso, pode ajudá-lo.

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

Criar esse script do PowerShell, agendar o trabalho como SYSTEM e configurá-lo para ser executado na reinicialização me permitiu usar letras de unidade em meus scripts, pois o UNC não é uma opção devido a uma dor de cabeça de outros problemas.

Tente alterar o local "iniciar em" para "c: \". Isso pareceu corrigi-lo, então talvez o sistema esteja impedindo a execução do cmd.exe a partir do \ windows \ system32 \ como um recurso de segurança.

Eu tive o mesmo problema ao tentar acessar r: /xxxfilename.txt com uma unidade mapeada do Windows r: \ server \ share ao chamar um script do agendador de tarefas do Windows. Resolvi

usando //server/share/xxxfilename.txt
Observe a barra invertida convertida em barra invertida.
Agora, meu script bash cygwin é executado no agendador de tarefas do Windows e no shell cygwin.
Nota: o comando " net use " pode acessar as unidades de mapa no shell, mas mostra Indisponível R: quando executo esse comando no Agendador de tarefas do Windows.

Como outro usuário observou, definir a opção "Executar se o usuário está conectado ou não" para "Executar apenas quando o usuário estiver conectado" parece funcionar. Você pode usar o caminho mapeado (por exemplo, Z :) ou o caminho do servidor (por exemplo, \\ ServerName \ Path).

Obviamente, se você usar esta opção, precisará fazer o que está escrito e garantir que fez login no servidor como um usuário com acesso à unidade relevante. Lembro-me de estar em uma empresa mais antiga, com vários trabalhos configurados como este. Um dia alguém "desconectou" o servidor principal de tarefas, sem esperar que isso tivesse algum impacto, pois não desligaria a máquina de forma alguma ...

Além disso, atualmente, o Windows gosta de fazer muitas reinicializações auto-invocadas do sistema. Portanto, use esta solução por sua conta e risco.

Observe também que, se você fizer o mapeamento no script e a senha contiver%, será necessário gravar %% para que o script funcione a partir do agendador de tarefas, mas% funcione a partir do prompt de comando

pode-se usar os seguintes comandos, a serem adicionados no próprio script em lote, para executar o script em lote da tarefa de agendamento do Windows para obter dir, arquivo copiado no sistema local usando a tarefa de agendamento do Windows; uso líquido Y: "\\ xxx \ xxx \ xxx cd / d Y: usuário líquido / d Y: / Y

Obrigado, acho que usando "start in c: \" resolveu o meu problema, rastreamos esse problema para confirmar que foi resolvido.

Eu estava tendo o mesmo problema, se eu clicasse diretamente no lote, ele funcionava perfeitamente, mas não na tarefa agendada.