Hoje o time do Exchange disponibilizou o link para o poster do Exchange 2010, como já existia para o Exchange 2007.
Este poster é interessante pois ele traz um resumo das funções executadas por cada componente do Exchange, e isto ajuda muito os administradores, que como eu, vieram do Exchange 2007 e ignoram a existência de algumas novas features.
Para fazer o download clique em http://www.microsoft.com/downloads/en/details.aspx?FamilyID=cea0cf7e-d824-49bb-8924-39d66a5fb88e
No nosso ambiente instalamos um servidor Dell e as cinco VMs antes distribuidas em 3 maquinas físicas foram consolidadas. Porem, nossos Domain Controllers são duas VMs e notamos o problema da falta de um DC no momento do startup das outras VMs, principalmente a do Exchange, quando o servidor é atualizado pelo WUA, por exemplo ou em caso de pane na host.
Como resolver isso?
Solução 1
A maquina fisica ser o Domain Controller e hospedar os FSMOs.
A desvantagem deste método é que a recomendação padrão é que a maquina do Hyper-V seja dedicada a esta função, e que nem driver de video ela tenha (Problemas com o driver Intel Graphics Media Integrated HD e o Hyper-V). Tanto esta solução quanto a abaixo não eram viáveis porque o cliente mantem uma segunda maquina em outro local fisico com as VMs copiadas para apenas atualizar o BD do SQL em caso de pane do servidor ou do prédio, e sincronizar AD neste caso seria inviável.
Solução 2
Colocar um servidor fisico hospedando o AD.
Não é víável para este cliente porque sua intenção foi comprar um servidor bi-processado, fontes redundantes e storage dedicado, alem de um poderoso no-break para 1h30m de operação. Colocar mais um servidor seria contra o projeto apresentado, até porque no ambiente também existe um servidor System Center Data Protection Manager (DPM) que não pode ser DC. Com isso, precisamos limitar o ambiente a 3 maquinas físicas (servidor Hyper-V, DPM e TMG).
Solução 3 
Sequenciar as VMs, fazendo com que a DC que hospeda o FSMO fosse a primeira.
Esta se tornou a opção ideal, não incluiria mais uma maquina a ser gerenciada e permitiria fazer o restore de emergencia rapidamente no caso de pane do servidor.
Porem, note que este processo é invertido. Não se diz qual máquina irá ligar na frente, mas sim coloca-se um delay nas maquinas que dependem. Isso pode ser feito nas configurações de cada VM que dependa de outra maquina e alterar as configurações “Automatic Start Action”, como mostrado abaixo:
NOTA: Esta solução é adequada para casos de reinicio do servidor onde as VMs foram salvas e irão reiniciar automaticamente e não se aplicam ao startup manual, obviamente.