Eu tenho um executável .NET (que eu criei) que usa o Microsoft Interfaces de Serviço do Active Directory (via System.DirectoryServices.AccountManagement) para fazer consultas LDAP. Internamente para a ADSI, ele baixa o esquema do Active Directory e o armazena localmente . É suposto armazenar esse esquema em uma pasta em %LOCALAPPDATA%\Microsoft\Windows\SchCache\ .
Quando agendar esse executável no Agendador de Tarefas no Windows Server 2012 R2 e configurá-lo para ser executado como "UsuárioA" mesmo que esse usuário não esteja conectado , o programa roda mas tenta gravar o arquivo de cache acima em uma pasta literalmente chamada %LOCALAPPDATA%\Microsoft\Windows\SchCache\ dentro da pasta start-in da tarefa agendada (que é intencionalmente definida para a pasta do meu executável). Em outras palavras, está escrevendo algo como C:\MyApp\%LOCALAPPDATA%\Microsoft\Windows\SchCache\ . Eu tive que dar UserA explícito permissões de gravação para esta pasta para permitir que o programa seja executado corretamente.
Eu assisti o processo da tarefa com o Process Monitor e ele está indo imediatamente para essa pasta. Não é como se ele primeiro tentasse algo em C:\Users\ , mas falhasse.
Quando eu fizer login no servidor como meu próprio usuário e executar manualmente o executável como UserA usando Executar como um usuário diferente , o executável será executado e gravará com êxito o arquivo de cache em C:\Users\UserA\AppData\Local\Microsoft\Windows\SchCache\ .
Por que isso está acontecendo com o Agendador de Tarefas e o que posso fazer para corrigi-lo? Eu imagino que isso tenha a ver com o Agendador de Tarefas executando o programa no contexto do UserA, mas não inicializando o %LOCALAPPDATA% como uma variável de ambiente. Por um capricho, tentei definir Executar com privilégios mais altos na tarefa, mas isso não alterou o resultado.
Este é um bug no Windows Server 2012 R2 e 8.1; A Microsoft documentou isso em KB 2968540 .
O problema foi corrigido e o hotfix KB 3133689 está disponível. Esse hotfix resolve o problema.
Scheduled tasks that are run by using UBPM don't have sufficient environment variables such as APPDATA, USERPROFILE, or TEMP when the corresponding process is started.
Acredito que haja um erro nas tarefas agendadas do Windows 7/2012, para que elas não vejam as variáveis de ambiente corretas para o usuário que estão executando como:
Para confirmar que isso está ocorrendo, você pode executar SET>test.txt em um arquivo em lotes em uma tarefa agendada, no mesmo contexto de usuário. Quando tento isso, ele não mostra o conjunto completo e correto de variáveis de ambiente para o usuário especificado; Ou seja, não é o mesmo conjunto que você vê se executar o mesmo comando (ou arquivo de lote) quando estiver realmente conectado como aquele usuário. (Ainda mais confusamente, isso depende se o usuário está logado ou não quando a tarefa agendada é executada; se eles estiverem logados, a tarefa faz ver as variáveis corretas.)
Acho que esse comportamento não está documentado ou previsto, e é um bug na maneira como as tarefas agendadas do Windows Server 2012 (talvez apenas R2?) são tratadas.
NB Isso também se aplica à variável PATH , portanto, as tarefas agendadas só podem ver executáveis que estão no caminho padrão , no diretório atual ou com um caminho totalmente especificado. Chamar qualquer coisa que esteja no caminho do usuário especificado, mas não no caminho padrão, causará um erro difícil de depurar (já que funciona no teste!).
Esta é uma conseqüência da maneira como o Windows lida com contas de usuários. Quando uma conta de usuário não está conectada, sua seção de registro do usuário - a chave em HKEY_USERS que normalmente é mapeada como HKEY_CURRENT_USER - não está montada. Essa seção (que é armazenada em um arquivo, no perfil de cada usuário, chamada NTUSER.DAT ) armazena quase todos os dados por usuário, incluindo as variáveis de ambiente por usuário. O Windows também tem variáveis de ambiente do sistema - algumas variáveis, como PATH, estão presentes em ambos os locais e são mescladas - para que elas apareçam mesmo se a seção do Registro do usuário não estiver montada. Nenhum dos específicos do usuário, no entanto.
Não sei se o Agendador de Tarefas lidou com esse cenário de maneira diferente em outras versões do Windows. Ele poderia ser inteligente o suficiente para montar a seção do usuário antes de executar uma tarefa como esse usuário. No Win7 / 2012R2, aparentemente não é.
Para corrigir isso, você precisa garantir que a seção de registro do usuário esteja montada. A maneira mais simples de fazer isso é apenas certificar-se de que o usuário esteja conectado, já que a seção de um usuário conectado é sempre montada. Na falta disso, você pode tentar montar a ramificação por conta própria (a API é RegLoadKey mas eu nunca tentei invocá-lo para isso).