Perguntas[exchange](server)

Eu estava configurando o CBA para ActiveSync e OWA no Exchange Server 2019 localmente seguindo este guia: https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/configure-certificate-based-auth?view=exchserver-2019

Depois de aumentar o valor de uploadReadAheadSize para 49152 para OWA, ecp e ActiveSync, comecei a receber o erro no navegador "muitos redirecionamentos, tente limpar os cookies".

Limpar cookies não ajudou. Janelas privadas também não ajudaram. Eu Chrome e OWA começaram a funcionar e aceitar certificados. O navegador Edge não está funcionando para OWA.

Suspeito que não seja o Edge o problema, mas dados que foram armazenados em cache que não permitem a conexão. Consegui conectar ao OWA com o Edge em outro computador, que não era usado antes.

Depois que o OWA funcionou em um PC, instalei o certificado de usuário em um iPhone, e o OWA também funcionou lá com certificado (ótimo!! um problema resolvido).

No entanto, por razões desconhecidas, o ActiveSync ainda não funciona com a exigência do certificado no mesmo iPhone. Eu presumo que o iPhone deve usar o mesmo certificado que ele usa para o OWA (que funciona), então o certificado não é o problema.

O ActiveSync funciona se não exigir certificado de cliente, então permissões/políticas não devem ser o problema.

A exigência de certificado resulta nos códigos de erro 403 7 64 e 403 7 5.

Alguém tem alguma sugestão???

Quando envio um e-mail para vários grupos de distribuição, mas no rastreamento de e-mail, só consigo ver o nome do destinatário e não consigo visualizar o nome específico do grupo de distribuição. Por que isso acontece? Como rastrear para quais grupos de distribuição os usuários enviaram e-mails?

Estamos usando o Exchange Server 2013 CU23. Eu uso "delegação de caixa de correio" para outras caixas de correio da minha organização para controlar e-mails quando outros funcionários estão de férias.

Agora tenho muitos links que não são necessários para mim. Eu removi a delegação, mas os links não desapareceram. Eu reconectei o Outlook, mas todos os links foram restaurados, sem acesso. Eu posso vê-lo, mas sem mostrar o que está dentro dele.

Pelo que me lembro, tudo isso era fácil de usar, mas agora tenho esse problema estranho.

Alguém pode me ajudar?

Tenho meu calendário publicado no Exchange 2010, de modo que tenho links que posso usar para obter anonimamente os detalhes do calendário como um ICS, com todos os detalhes disponíveis, que uso para acessar meu calendário a partir de meus próprios aplicativos e sistemas privados.

O que eu gostaria de fazer é também ter um par separado de links que eu possa disseminar mais amplamente, que contenham apenas informações de livre/ocupado. Embora esta seja uma das opções, não consigo gerar links adicionais, pois o calendário já está compartilhado com detalhes, ou seja, parece que só consigo compartilhar o calendário em uma configuração, não em várias:

Há algo que estou esquecendo aqui que permitiria que fosse compartilhado de várias maneiras diferentes? No outlook.com/Office365 online, é possível fazer isso, mas não encontrei nenhuma documentação que diga que não pode ser feito nas versões locais (mostrado abaixo, eu já tenho um link "todos os detalhes" publicado, e tenho a opção de compartilhá-lo novamente, com livre/ocupado):

É possível compartilhar um calendário em cada configuração possível com o Exchange 2010, como acontece com o outlook.com/Exchange Online, ou apenas uma configuração por vez é possível?

Estou ciente de ferramentas de proxy iCal como https://github.com/scy/calproxy que podem fornecer uma visualização filtrada de livre/ocupado, mas parece muito trabalhoso configurar algo assim se houver uma maneira de fazer isso nativamente.

Temos um servidor hospedado externamente que precisa ser capaz de enviar e-mails para endereços de e-mail externos e internos.

Este servidor está usando o serviço SMTP fornecido pela empresa de hospedagem e é capaz de enviar e-mails para endereços externos sem problemas (de server[AT]mydomain.com para customer[AT]gmail.com). SPF e DKIM são configurados para este servidor.

Mas se tentarmos enviar e-mail para nossos endereços internos (hospedados no Exchange Online), o e-mail nunca será recebido (de server[AT]mydomain.com para user[AT]mydomain.com). O endereço server(AT)mydomain.com pode receber e-mails no Exchange de endereços internos e externos sem problemas, mas não estamos vendo nenhuma mensagem de rejeição. Não vemos esses e-mails com falha no rastreamento de mensagens ou na quarentena.

Alguma ideia de quais configurações podem estar faltando ou onde devo procurar em seguida?

Seguindo o guia aqui:

https://learn.microsoft.com/en-us/exchange/manage-hybrid-exchange-recipients-with-management-tools

Estou na etapa 5 em Desligando permanentemente seu último servidor Exchange. Essa etapa diz o seguinte:

Lista de Comandos

Esses comandos em cada bloco são executados um de cada vez? Eles fornecem resultados que precisam ser copiados e inseridos posteriormente? As instruções nesta parte não são muito claras.

ou seja. Eu digito:

$thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint

Então aperte Enter? O tipo:

$oAuthCert = (dir Cert:\LocalMachine\My) | onde {$_.Thumbprint -match $thumbprint}

Então aperte Enter? Etc?

Procuro uma saída para inserir outro comando mais tarde? Normalmente consigo analisar esses comandos e eles geralmente são claros sobre quais valores observar e quando inserir os valores recuperados como parte de um comando posteriormente, mas, neste caso, não está claro para mim.

Temos um servidor híbrido Exchange 2019 para habilitar remotamente nossos usuários de AD para email e enviar para nossas caixas de correio a partir de determinados aplicativos legados. Embora nossos usuários sejam todos vinculados ao AD, criamos algumas caixas de correio (por exemplo, compartilhadas) diretamente no EOL/M365 (também conhecido como nenhum objeto AD).

O servidor híbrido envia mensagens de forma confiável para todas as nossas caixas de correio remotas vinculadas ao AD, mas assim que alteramos o destinatário para uma caixa de correio compartilhada criada diretamente no EOL (sem objeto AD), obtemos algo assim:

<550 4.4.7 QUEUE.Expired; message expired in unreachable destination queue. Reason: A matching connector cannot be found to route the external recipient>

Além disso, pelo que vale a pena, notei nos logs de rastreamento de mensagens que quando endereçamos para " [email protected] " as entregas bem-sucedidas fazem uma fonte de roteamento resolver para " [email protected] ". Nossas caixas de correio compartilhadas são criadas diretamente no EOL e teriam apenas " [email protected] " por padrão.

Enquanto escrevia isso, tentei adicionar um SMTP secundário de " [email protected] " por meio do EOL e enviar outra mensagem de teste, mas o host híbrido ainda considera a caixa de correio compartilhada como um destinatário externo.

Se alguém já passou por isso e tiver alguma sugestão, ficarei grato. Obrigado!

Ao enviar e-mails por meio de nosso serviço Exchange 365, esses e-mails são enviados com êxito, mas se olharmos os cabeçalhos dos e-mails, vemos que onde o remetente e o destinatário estão em nosso locatário, o SPF do e-mail realmente falhou; enquanto que se enviamos e-mails para terceiros (por exemplo, para um endereço do Gmail), o SPF está correto.

Especificamente, vemos que o e-mail enviado internamente mostra ter um IP no ip6:2603:1000::/24intervalo (por exemplo 2603:10a6:400:49::16... e esse IP não está listado em spf.protection.outlook.com.

Da mesma forma, ao verificar os cabeçalhos dos e-mails enviados a terceiros, vemos que um seletor DKIM está incluído no cabeçalho do e-mail. Para aqueles enviados para outras caixas de correio dentro do nosso locatário, esse cabeçalho não existe.

Outros têm relatado o mesmo há vários anos. Como os outros, falei com o suporte da MS, mas esse cenário está fora do roteiro para eles, então isso não me levou a lugar nenhum.

Meu palpite é que a MS não se importa com SPF/DKIM quando as mensagens estão dentro do locatário, pois sabem que esses e-mails são válidos e não os filtram. No entanto, não consigo encontrar nenhuma documentação para confirmar isso, e isso parece errado (por exemplo, se o seu cliente de e-mail tiver sua própria lógica para validá-los, como ele saberia confiar neles). Este é um problema frustrante, pois ao investigar problemas reais de e-mail, é mais difícil dizer se os e-mails que falham nessas verificações indicam um problema real ou, como e-mails válidos também falham nessas verificações, estamos procurando no lugar errado.

estou usando o Office365/Exchange e configurei um bom modelo HTML para anexar assinaturas de e-mail dinâmicas usando a regra de fluxo de correio: "anexar isenção de responsabilidade".

Eu usei o atributo %%PhoneNumber%% que está sempre vazio, embora as informações de contato estejam perfeitamente preenchidas em UserAccount e Exchange.

Tudo o que eu faço permanece vazio.

Então comecei a usar %%CustomAttribute1%% - e digitei "333333" há duas horas. A string no E-Mail permaneceu Vazia.

Então, depois de mais 30 minutos mexendo desesperadamente, de repente funcionou para exibir 333333.

Agora, há duas horas, substituí esta string de teste pelo número de telefone real, desabilitei/habilitei a regra e atualizei a regra. Atualizado o perfil do usuário, tanto no Office365 Admincenter quanto no Exchange...

Ainda está exibindo "33333". É frustrante porque nunca sei ou posso testar se atualizei/usei o campo correto nem se funcionou.

O Exchange está usando um cache muito agressivo ou é muito lento? A documentação sobre os espaços reservados também é muito ruim. Há uma lista de variáveis ​​sem explicar a qual campo a variável pertence exatamente.

Alguns funcionam, outros não.

Se a variável não puder ser resolvida, ocorrerá um erro ao salvar (pelo menos), mas se salvar e permanecer vazia, isso também não será útil.

Estou tentando descobrir se existe uma maneira de os usuários fazerem login em nosso servidor CAS Exchange 2019 OWA usando seu endereço de e-mail principal em vez de seu UPN. Por alguma razão, quando o Exchange foi configurado aqui pela primeira vez (antes da minha época), eles adotaram um formato diferente para o login do usuário. Nosso login (UPN) é apenas o nome do usuário (ou seja: [email protected] ), mas o endereço de e-mail é a inicial/sobrenome (ou seja: [email protected] ). Este NÃO é um problema de sufixo UPN, pois ambos os sufixos são iguais (ou seja: @contoso.com). Posso fazer login no OWA usando o UPN, mas não usando o endereço de e-mail. O Exchange permite isso?