As mensagens de acesso negado geralmente vêm da conta executando a sessão do PowerShell sem permissão suficiente. Eu recebo isso o tempo todo quando eu inicio o Shell de Gerenciamento do Exchange em vez de executar como minha conta de usuário administrativo.
Após sua atualização, o que suspeito pode estar acontecendo é que o User1 faz parte de um grupo protegido (Print Operators), portanto o Exchange não está permitindo que você conceda o Send As ao User2 porque ele sabe que só será retirado na próxima hora. Parece que você confirmou essa teoria adicionando manualmente o Send As usando o ADUC e vendo isso sendo tirado pouco tempo depois.
No Controlador de Domínio que executa a função FSMO do Emulador PDC, a cada hora, algo chamado segmento adminSDHolder é executado. O que isto faz é levar todas as contas que estão (ou já foram, mesmo que tenham sido removidas posteriormente) em grupos protegidos (Administradores de Empresa, Admins do Domínio, Operadores de Conta, Operadores de Impressão para citar alguns dos mais comuns) e remove todos permissões concedidas aos objetos e as substitui por certas permissões explicitamente definidas. A ideia é que uma conta delegada não é capaz de causar estragos e privar um administrador de domínio de seus privilégios.
Não estou totalmente convencido de que sua correção de conceder permissão explicitamente irá funcionar e não será redefinida a cada hora, mas eu estava errado antes - então, se isso acontecer, ótimo! Se, no entanto, o usuário não precisar estar no grupo Operadores de impressão, recomendo que você modifique sua conta usando o ADSI Edit e defina a propriedade adminCount como zero. Em seguida, ative as permissões herdáveis no objeto do usuário e redefina as permissões padrão. Depois de fazer isso, tente novamente o cmdlet do Exchange e, com um pouco de sorte, ele funcionará (obviamente, dê tempo suficiente para que a replicação do AD ocorra).
Eu não acho que você será capaz de modificar o seu cmdlet para acomodar isso - como eu disse, eu imagino (não tenho certeza) que ele não permitirá que você faça isso porque O Exchange sabe que a permissão só será removida logo depois e está tentando salvar a confusão de sua parte. Em circunstâncias "normais" (por exemplo, um usuário padrão), o cmdlet deve funcionar sem problemas, porque nem todo o segmento adminSDHolder entra em ação.
