Exchange 2010 unindo sites em sites diferentes com namespace DNS externo comum

Question

Procurando conselhos sobre como unir dois sites existentes do Exchange 2010. O driver principal é compartilhar informações de calendário e uma GAL comum.

Devido a complexidades com nomes de domínios internos e domínios raiz compartilhados (inexistentes) que unem os dois sites no Exchange, parece complexo.

Estas são as informações do fluxo de mensagens [email protected] é encaminhado para um filtro de conteúdo MTA baseado em nuvem e, em seguida, as regras no MTA encaminham os e-mails para o site relevante do Exchange: [email protected] FQDN interno uk.domian.com [email protected] FQDN interno us.domian.internal

Devido ao fato de o site dos EUA ser um namespace .internal fazer com que o site se torne problemático, investiguei a renomeação do domínio ou a criação de um novo domínio e migração, mas isso requer muita entrada administrativa e o site americano tem pouca TI recurso pessoal.

Como resultado, parece que a criação de uma confiança de federação do Exchange parece ser a única opção viável (a menos que haja outras soluções?)

Olhando para a confiança federada, parece que o DNS precisa ser corrigido, as entradas de descoberta automática alteradas, etc.

Como há um túnel IPSEC privado entre os dois sites, imaginei se era possível criar as regras de descoberta automática nos servidores DNS internos e, em seguida, usar o túnel VPN para a federação.

Quaisquer outras opções viáveis ou recomendações?

Obrigado antecipadamente!

    

Answer 1

Você está se referindo a informações de disponibilidade ou compartilhamento de calendário real? Sua melhor rota é usar a federação para informações de disponibilidade. Você precisará do galsync (FIM 2010 R2) para a configuração da GAL. Ou use um dos scripts do PowerShell que criará os contatos para você sem utilizar o FIM.

    

Answer 2

Eu fiz uma configuração exatamente como você está perguntando. Ele vai lidar com listas de distribuição, etc. Seja cauteloso sobre ter os mesmos cross-forest embora ... como helpdesk ou vendas ou qualquer outra coisa.

Basicamente, isso se resume a duas coisas:

1. Você deve (se ainda não tiver) um namespace SMTP compartilhado para domain.com. Isso fará com que o envio e recebimento como domain.com para TODOS ... e simplifique os namespaces usados. Você consegue fazer isso floresta cruzada.
2. Examine a Federação entre florestas, se necessário. Basicamente, isso permitirá a disponibilidade de recursos entre florestas e a sincronização de disponibilidade. Ajuda para reuniões, etc     Usamos (e eu recomendo) um produto da netsec.de chamado GAL Sync ... link feito por um Empresa alemã, mas tem suporte completo em inglês e funciona incrivelmente bem. Será necessário instalá-lo em ambos os lados, mas funciona assim bem com tantas opções personalizáveis. Nós tínhamos olhado em todo o outros, como o IIFP (agora ILM), o Quest Collaboration Services, fazendo isso em casa, contatos manuais em ambos os lados, etc.

Isso não é para os fracos de coração no geral. Você tem que ter certeza de que está certo, porque o Exchange é mimado. Tomemos por exemplo um único contato que você já tem na outra floresta. Agora, exclua-o, recrie-o e observe o que acontece quando alguém tenta responder a um e-mail existente a partir do "contato" original. Irá saltar porque está procurando aquele objeto original do Exchange, não o endereço SMTP. Portanto, tenha cuidado e vá devagar. Mesmo com as opções acima, eu demorei alguns meses planejando e testando para ter certeza de que iria funcionar sem problemas.