Aconselhamento sobre topologia e certificados do Exchange 2010

Question

Por acaso, me pediram para fazer uma pesquisa sobre uma migração do Exchange 2003 para 2010. Eu tenho trabalhado com o Exchange 2007 por alguns anos, mas sem qualquer certificação formal ou similar.

Eu tenho lido muito material educacional e whitepapers para ter uma noção do processo de migração e novos conceitos em 2010. Meu objetivo é obter uma sólida compreensão do que está acontecendo, fazer sugestões gerais para a topologia e ser capaz de fornecer assistência competente caso contrataremos uma empresa externa para cuidar da migração.

Topologia geral:
Eu me sinto bastante confiante sobre a minha compreensão geral dos papéis e princípios da configuração de alta disponibilidade - embora eu tenha poucas perguntas bônus, espero que você possa me ajudar com:)

• 1x servidor EDGE
• 2x servidores CAS / HT configurados com uma matriz CAS via NLB
• 2x servidores MB configurados em um DAG simples.

Agora, para a configuração acima, estou pensando em algumas coisas:

• Com servidores de 2 MB em um DAG, precisarei de um servidor testemunha na minha configuração?
• Com relação aos bancos de dados de caixa de correio - qual é a sua estratégia para dividir os bancos de dados? Por tamanho, volume ou ...?

Certificados:
Eu admito que meu conhecimento sobre certificados é bastante básico - estou trabalhando nisso :). Ao solicitar um certificado SAN do nosso provedor, esse certificado também precisa incluir endereços internos ou simplesmente os FQDNs externos? O que quero dizer é que preciso incluir o mail.contoso.com, autodiscover.contoso.com e legacy.contoso.com, mas além disso, é necessário incluir nomes internos? E quanto a várias extensões de TLDs - essas também precisam ser consideradas no certificado SAN?

Acho que as perguntas acima são as que mais me intrigam. Estou ansioso por algum feedback sobre este pequeno projeto meu e agradeço qualquer bom conselho:)

    

Answer 1

Se você tiver um número par de servidores de Caixa de Correio em um compartilhamento de arquivos de um DAG testemunha é necessária , então no seu caso você irá. A Microsoft recomenda que você use um servidor de Transporte de Hub como seu servidor testemunha. Se o seu servidor testemunha não for um servidor do Exchange 2010, você precisará adicionar a conta do computador do Active Directory ao grupo de segurança Subsistema Confiável do Exchange .

Lembre-se também de que o layout do disco em ambos os servidores do DAG deve ser idêntico . Se em um servidor você tiver o Sistema Operacional em C :, seus bancos de dados em E: e seus logs de transação em F :, isso deve ser o mesmo no outro servidor.

Você deve dividir seus bancos de dados como bem entender, e não estou ciente de nenhuma diretriz oficial. Vou listar algumas razões bastante comuns.

• Cotas de caixa de correio
• Separação de unidades de negócios
• Separação de locais físicos
• Desempenho. Quanto menos usuários um banco de dados de caixa de correio tiver, mais rápido será. Se os arquivos do banco de dados estiverem todos em um volume, o subsistema de disco poderá se tornar um gargalo.
• Seu objetivo de tempo de recuperação. Quanto menor o banco de dados, mais rápido ele pode ser restaurado no evento Something Bad Happens ™ .
• Por sobrenome. Não há uma rima real nem um motivo para isso - apenas distribui as pessoas pelos bancos de dados disponíveis.
• Aleatoriamente. Mais uma vez, isso é apenas para distribuir as pessoas entre os bancos de dados uniformemente e só funciona se você não usa bancos de dados para coisas relacionadas a políticas, como cotas. Se você tiver mais de um banco de dados e não for o proprietário de uma Caixa de Correio quando for criá-lo, o Exchange selecionará qualquer um para você. FWIW, você pode excluir determinados bancos de dados desse processo usando Set-MailboxDatabase <The DB Name> -IsExcludedFromProvisioning $true .

Com relação ao seu certificado, você deve executar o assistente de certificado que o Exchange 2010 fornece a você. Depois de preencher as informações apropriadas, ele gerará uma solicitação de certificado que você poderá enviar a uma autoridade de certificação para gerar um certificado. Ele lida com todos os vários subdomínios que você precisa (ActiveSync, AutoDiscover, OWA, etc) e é bastante simples de concluir.

    

Answer 2

Em resposta a sua pergunta sobre certificados, nossa configuração é a seguinte

Nossos servidores estão todos em nossa rede interna / domínio com FQDNs de, por exemplo, [xxx] .internal.lan. No entanto, temos um DNS dividido configurado nos nossos servidores DNS internos, por exemplo, exchange.company.com é um apelido para exchange.internal.lan

Dessa forma, podemos publicar o servidor externamente através do nosso firewall e dizer às pessoas para usarem o exchange.company.com, independentemente de estarem dentro ou fora da rede.

Publicamos a descoberta automática, o OWA, o ActiveSync, etc.

Portanto, precisamos apenas de um único certificado curinga para * .company.com que usamos nos servidores do Exchange por exemplo autodiscover.company.com, exchange.company.com, etc. etc.