O NT Authority \ System não pode baixar um anexo de email. Qual conta pode?

0

Acredite ou não, esta questão está relacionada a um processo real de produção. Porque a empresa com a qual estamos trabalhando é dirigida por homens das cavernas, eu acho, mas ... Enfim.

Existe uma tarefa agendada nesta máquina que se conecta a um servidor de email (usando um utilitário IMAP que escrevemos internamente) e baixa todos os anexos que foram enviados no último dia. Isso funciona bem quando o executamos sob uma conta de usuário no sistema, mas isso significa que temos que continuar mudando a senha (leia-se: isso significa que o processo falha uma vez por mês quando esquecemos de alterar a senha).

Obviamente, o procedimento padrão seria executá-lo como uma conta do sistema, para que não precisemos nos preocupar com isso, e temos alguns outros trabalhos que são executados como NT AUTHORITY\SYSTEM . Este, no entanto, não. Isso porque, quando tentamos executá-lo como SYSTEM, diz que ele fez seu trabalho, mas o diretório que deveria conter todos os anexos baixados permanece vazio enquanto a caixa de entrada permanece cheia.

IANASA (não sou um administrador de sistemas!): O que posso fazer para que isso seja executado? (De preferência, sem ter que definir algum tipo de lembrete no meu calendário que diz: "Ei, vá mudar as senhas bobas em seus trabalhos em lote".)

    
por archer884 12.12.2013 / 19:33

1 resposta

0

Versão resumida: não existe uma conta (SISTEMA incluso!) capaz de encontrar algo que não exista.

Vocês estão prontos para isso? Aqui está um snippet de código do script que esta tarefa estava executando:

Add-Type -Path ($env:UserProfile + '\bin\Email\Email.dll')

... Aposto que metade de você já descobriu porque isso não funcionará corretamente em NT AUTHORITY\SYSTEM , não foi?

Como o script estava tentando verificar a pasta base do usuário para o utilitário, ele não conseguiu encontrar nada remotamente executável quando o usuário estava configurado como SYSTEM. Nós finalmente notamos isso quando nós cavamos nossos logs e notamos que não havia nenhum para quando o utilitário deveria estar rodando sob SYSTEM.

Espero que esta pergunta salve algum outro pobre coitado um pouco na próxima vez em que o impossível ("Sério? Algo que o SISTEMA não pode fazer? Como isso é possível ?") acontece.

    
por 12.12.2013 / 21:33