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

24

Eu tenho um trabalho do Agendador de Tarefas para executar o Robocopy para fazer backup de arquivos locais em um compartilhamento de rede. Eu tenho que 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 um administrador local. Esta solução de mapeamento e desmapeamento temporário do compartilhamento de rede funciona, mas deixa minha senha exposta em texto sem formatação para qualquer pessoa que examine as ações da tarefa do Agendador de Tarefas. Eu preferiria mapear a unidade de rede normalmente em uma base semipermanente para que o trabalho do Agendador de Tarefas apenas execute o Robocopy e consulte a letra de unidade apropriada. No entanto, eu sempre recebo o erro "O sistema não pode encontrar o caminho especificado". no log do Robocopy ao executá-lo no Agendador de Tarefas, embora o comando funcione bem em um prompt de comando elevado (o trabalho está definido para ser executado com privilégios mais altos). Observe também que eu fiz este registro tweak para acessar unidades mapeadas a partir de um prompt de comando elevado.

EDIT: Para esclarecer, logado como o administrador local, eu inicio o Windows Explorer como administrador. Mapeio o compartilhamento de rede para a letra Y. Eu inicio 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 logado ou não, com os mais altos privilégios. Eu corro e recebo um erro. Eu 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.
    
por Craig W 04.09.2013 / 19:21

11 respostas

15

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 a tarefa executa tem acesso ao destino.

    
por 06.09.2013 / 18:56
6

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

    
por 23.02.2016 / 17:55
3

Tente usar:

pushd \machine\share

dentro de um arquivo de lote da sua tarefa agendada. Unidades compartilhadas de rede só estão disponíveis em um ambiente de execução do usuário. "pushd" permitirá que ele seja executado no contexto do script.

Quando terminar, use:

popd \machine\share

para desmapear a unidade.

Referência: link

    
por 14.07.2014 / 09:21
1

Outra opção é apenas usar o caminho de rede completo, pois o Robocopy as 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. Alimente robocopie a senha de um arquivo de texto que somente os administradores de domínio podem acessar.

Anos atrás eu 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 prompt de comando smtp mail remetente.

Eu fiz um script que examinaria a rede em busca de sistemas. Ele criaria um arquivo de texto de todos os nomes do sistema e me alertaria via e-mail sobre qualquer novo sistema encontrado. (Eu tinha um arquivo de configuração que seria analisado para os sistemas pularem.) Cada novo sistema tinha um diretório de backup criado para ele e um arquivo de configuração de backup colocado nele. O usuário poderia modificar esse arquivo e listar todos os diretórios que precisassem de backup. Eles também poderiam especificar o tempo para seus backups, para que não acontecesse quando estivessem no escritório. Eu corri este script no servidor a cada 5 minutos, pois não levava 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. Este foi executado diariamente às 12:01 am.

Por fim, o script de backup analisaria o arquivo de configuração que foi passado a ele pelo agendador e, usando o robocopy, copiaria todos os arquivos. Eu tinha uma verificação completa dos arquivos de configuração, pois os usuários os editavam, e eu recebia e-mails sobre quaisquer problemas.

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

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-me de ter copiado os scripts quando saí, mas quem sabe onde eles estão agora?

    
por 08.10.2015 / 20:31
1
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 este script powershell, agendar o trabalho como SYSTEM e configurá-lo para ser executado na reinicialização permitiu que eu usasse letras de unidade em meus scripts, pois o UNC não é uma opção devido a uma dor de cabeça de outros problemas.

    
por 11.12.2017 / 17:00
0

Tente alterar o local "início" para "c: \". Isso pareceu corrigir isso para mim, então talvez o sistema estivesse impedindo que o cmd.exe fosse executado a partir do \ windows \ system32 \ padrão como um recurso de segurança.

    
por 03.09.2014 / 12:58
0

Eu tive o mesmo problema ao tentar acessar r: /xxxfilename.txt com uma unidade mapeada pelo 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.
Agora meu script bash cygwin é executado no Windows Task Scheduler e no Cygwin Shell.
Nota: o comando " net use " pode acessar as unidades de mapa no shell, mas mostra R indisponível: quando executo este comando no Agendador de tarefas do Windows.

    
por 08.11.2016 / 21:53
0

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

    
por 25.05.2017 / 11:38
0

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

É claro que, se você usar essa opção, terá que fazer o que está escrito e garantir que tenha feito login no servidor como um usuário com acesso à unidade relevante. Lembro-me de estar em uma empresa mais antiga com uma série de trabalhos como este. Um dia, alguém "desconectou-se" do servidor de jobs principal, sem esperar que isso tivesse algum tipo de impacto, já que eles não estavam desligando a máquina de qualquer forma ...

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

    
por 15.12.2017 / 21:43
0

Observe também que, se você fizer o mapeamento no script e a senha contiver%, ele deverá ser escrito %% para o script funcionar no taskscheduler, mas% para funcionar a partir do prompt de comando

    
por 16.08.2018 / 11:56
-2

Obrigado, acho que usar o "start in c: \" resolveu meu problema. Vou acompanhar esse problema para confirmar se está resolvido.

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

    
por 21.04.2016 / 22:30