Eu tenho um executável .NET (que criei) que usa o MicrosoftInterfaces de serviço do Active Directory(via System.DirectoryServices.AccountManagement) para fazer consultas LDAP. Internamente à 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 eu agendo este executável emAgendador de tarefasno Windows Server 2012 R2 e configure-o para ser executado como "UserA"mesmo que esse usuário não esteja logado, o programa é executado, mas tenta gravar o arquivo de cache acima em umpasta literalmente chamada%LOCALAPPDATA%\Microsoft\Windows\SchCache\dentro docomeçarpasta da tarefa agendada (que é intencionalmente definida como a pasta do meu executável). Em outras palavras, está escrevendo em algo como C:\MyApp\%LOCALAPPDATA%\Microsoft\Windows\SchCache\. Tive que conceder permissões de gravação explícitas ao UserA para esta pasta para permitir que o programa funcionasse corretamente.
Observei o processo da tarefa com o Process Monitor e ela foi imediatamente para essa pasta. Não é como se primeiro tentasse algo, C:\Users\mas falhasse.
Quando eu faço login no servidor como meu próprio usuário e executo manualmente o executável como UserA usandoExecute como um usuário diferente, o executável é executado e grava com êxito o arquivo de cache no C:\Users\UserA\AppData\Local\Microsoft\Windows\SchCache\.
Por que isso está acontecendo com o Agendador de Tarefas e o que posso fazer para corrigir isso? Imagino que possa ter a ver com o Agendador de Tarefas executando o programa no contexto do UserA, mas não inicializando %LOCALAPPDATA%como uma variável de ambiente. Por capricho, tentei configurarExecute com privilégios mais altosna tarefa, mas isso não mudou o resultado.
Responder1
Este é um bug no Windows Server 2012 R2 e 8.1; A Microsoft documentou isso emKB 2968540.
O problema foi corrigido e hotfixKB3133689está disponível. Esse hotfix resolve o problema.
As tarefas planejadas que são executadas usando UBPM não possuem variáveis de ambiente suficientes, como APPDATA, USERPROFILE ou TEMP, quando o processo correspondente é iniciado.
Responder2
Acredito que haja um bug nas tarefas agendadas do Windows 7/2012, para que eles não vejam as variáveis de ambiente corretas para o usuário que estão executando como:
https://stackoverflow.com/questions/32589381/
Para confirmar que isso está ocorrendo, você pode executar SET>test.txtum arquivo em lote em uma tarefa agendada, no mesmo contexto de usuário. Quando eu tento isso, acontecenãomostrar o conjunto correto e completo 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 em lote) quando estiver logado como esse usuário. (Ainda mais confuso, isso depende se o usuário está conectado ou não quando a tarefa agendada é executada; se ele estiver conectado, a tarefafazveja as variáveis corretas.)
Acho que esse comportamento não está documentado ou pretendido e é um bug na maneira como as tarefas agendadas do Windows Server 2012 (talvez apenas R2?) São tratadas.
ObservaçãoIsso também se aplica à PATHvariável, portanto, as tarefas agendadas só podem ver os executáveis que estão nopadrãocaminho, ou 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 em testes!).
Responder3
Isso é consequência da maneira como o Windows lida com as contas dos usuários. Quando uma conta de usuário não está conectada, sua seção de registro do usuário - a chave HKEY_USERSque normalmente é mapeada como HKEY_CURRENT_USER- não é montada. Esse hive (que é armazenado em um arquivo, no perfil de cada usuário, chamado NTUSER.DAT) armazena quase todos os dados por usuário, incluindo variáveis de ambiente por usuário. O Windows também possui variáveis de ambiente do sistema - algumas variáveis, como PATH, estão presentes em ambos os locais e são mescladas - portanto, elas aparecerão mesmo se a seção de registro do usuário não estiver montada. Porém, nenhum dos específicos do usuário o fará.
Não sei se o Agendador de Tarefas lidou com esse cenário de maneira diferente em outras versões do Windows. Istopoderiaseja inteligente o suficiente para montar o hive 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 é garantir que o usuário esteja logado, já que o hive de um usuário logado está sempre montado. Na falta disso, você mesmo pode tentar montar o hive (a API éRegLoadKeymas nunca tentei invocá-lo para isso).