Fila do Exchange & R: Exchange está sempre mudando

Se você estiver alterando dias do calendário padrão, os pontos de extremidade do datacenter ou redirecionando a servidores, você precisa sempre estar pronto para fazer alterações ao Exchange.

Henrik Walther

Blues segunda-feira

**P.**Estamos uma grande empresa européia e apenas migrou do IBM Lotus Domino e Microsoft Exchange 2010. A maioria dos nossos usuários usa o Outlook Web App 2010 como o cliente de email padrão. Vários usuários observado que "Domingo" é o padrão primeiro dia da semana definido em configurações | Calendário no painel de controle do Exchange (consulte a Figura 1).

Figura 1 O padrão do primeiro dia da semana para uma caixa de correio do Exchange 2010.

Como segunda-feira é considerada o primeiro dia da semana de trabalho na nossa região, desejamos alterar essa configuração para todos os usuários de 2010 Exchange na organização. Podemos usar o Console de Gerenciamento do Exchange (EMC) ou o Shell de gerenciamento do Exchange (EMS) para fazer isso de forma centralizada para todos os nossos usuários? Já analisamos na página de propriedades para caixas de correio no EMC e até mesmo por meio de EMS usando o cmdlet Get-Mailbox, mas não podemos ver todos os atributos relacionados ao primeiro dia da semana da semana. Você pode ajudar?

**R.**Segunda-feira é o primeiro dia da semana de trabalho na maioria dos países europeus, portanto, entendo sua frustração. Felizmente, é relativamente fácil alterar essa configuração para todos os usuários. Você não pode fazê-lo usando a EMC, mas poderá certamente fazê-lo com o Shell de gerenciamento do Exchange (EMS). A maioria pensaria que você precisaria usar o cmdlet Set-Mailbox para alterar essa configuração. Na verdade, você precisará usar o cmdlet Set-MailboxCalendarConfiguration.

Execute o seguinte comando e você verá todas as configurações de calendário específicas que você pode manipular uma caixa de correio (consulte a Figura 2):

Get-MailboxCalendarConfiguration –Identity <user> | fl

Figura 2 alterar o padrão do primeiro dia da semana por meio do Shell de gerenciamento do Exchange.

Se você deseja alterar o "WeekStartDay" a segunda para todos os usuários na organização do Exchange 2010 que tinham "Contoso" no atributo da empresa (por exemplo), use o seguinte comando:

Get-User –Filter "Company –eq 'Contoso'" | Set-MaiboxCalendarConfiguration –WeekStartDay “Monday”

Voltar ao centro

**P.**Estamos já executando Exchange 2010 por aproximadamente um ano agora. Somos uma grande organização e até agora que tivemos um único data center que hospedam nossos 2010 Exchange, solução de mensagens. Apresentamos um datacenter extra para que podemos alcançar resiliência de caixa de correio no nível do site. Haverá usuários ativos, conectando a ambos os data centers, portanto, criamos uma matriz de servidor de acesso para cliente (matriz de autoridades de certificação) no outro data center.

Mudamos já os primeiros 100 usuários para o novo data center para verificar se as coisas funcionará como esperado. Não estamos lá. Podemos ver problemas com tendo o ponto de extremidade de cliente MAPI do Outlook foi alterado de "outlook-1.contoso.com" (CAS objeto array FQDN no primeiro datacenter) para "outlook-2.contoso.com" (novo CAS objeto array FQDN no novo data center).

Clientes MAPI do Outlook simplesmente continuam a usar o ponto de extremidade antigo, o que significa que os clientes Outlook criar sessões RPC para o array de CAS no primeiro data center e a matriz de CAS, em seguida, se comunica com RPC com os servidores de caixa de correio no data center novo. Qualquer idéia se isso é intencional? Caso contrário, você tem qualquer idéia como possamos corrigi-lo?

**R.**Algumas respostas do Exchange & Um leitores lembrará apresentei esse assunto antes. Quando você move caixas de correio de um data center com um array de CAS para outro data center com outro array de CAS, você não deseja disponibilizar o antigo ponto de extremidade não resolvida /. Isso afetará todos os usuários que estão ativos no primeiro data center.

A solução aqui — embora ele não é nada bonito — é atualizar o perfil MAPI do Outlook para os usuários que tiveram suas caixas de correio movidas para o novo data center (usando a opção "Reparo Profile" dentro do Outlook. Por exemplo) o.

Alguns de vocês deve estar imaginando por que o Exchange 2010 se comporta dessa maneira. Funcionou muito bem com versões anteriores do Exchange. Clientes MAPI do Outlook agora conectar-se ao serviço de acesso para cliente RPC (serviço de autoridade de certificação de RPC) na função de servidor acesso para cliente, não diretamente para o armazenamento na função de servidor caixa de correio.

No Exchange 2007 e versões anteriores, quando você moveu uma caixa de correio do banco de dados de uma caixa de correio para outro, resultaria no banco de dados de caixa de correio de origem enviando um "ecWrongserver" para o cliente Outlook. Que forçado para localizar a caixa de correio no banco de dados no qual a caixa de correio está armazenada agora.

O serviço de autoridade de certificação de RPC não pode responder com um "ecWrongServer" quando um * sobre (switch de banco de dados ou failover) ocorre entre dois centros de dados (e o serviço de autoridade de certificação de RPC está disponível). Da mesma forma, ele não pode responder se você mover uma caixa de correio de um banco de dados de caixa de correio em um data center para um banco de dados de caixa de correio em outro, onde o atributo RpcClientAccessServer do banco de dados de destino contém outro totalmente qualifed nome do domínio (FQDN).

Durante o desenvolvimento do Exchange 2010 SP1, havia planos para apresentar uma opção "Permitir Cross Site RPC acesso para cliente" suposta que você configuraria para um grupo de disponibilidade do banco de dados (DAG). Esta opção foi considerada excessivamente complexa, para que foi recortado direita antes Exchange 2010 SP1 entregue.

Podemos podem coexistir?

**P.**Implantamos 2010 do Exchange em nossa organização do Exchange 2003. Atualmente estamos planejando apontar o namespace que usamos para acessar uma caixa de correio do Exchange 2003 para o array de autoridades de certificação Exchange 2010. Já adicionamos um FQDN legado (legacy.contoso.com) para o certificado de SAN/UC e configuramos o URL de legado no diretório virtual OWA 2010.

Terminamos de descarregamento de SSL de habilitar a solução de balanceador de carga que distribui o tráfego de cliente em autoridades de certificação. Podemos também tenha seguido as etapas deste artigo do TechNet Wiki para configurar o descarregamento de SSL em servidores Exchange 2010 CA. Descarregamento de SSL não está habilitado nos servidores Exchange 2003 front-end (FE).

Estamos um pouco inseguros de se descarregamento de SSL funcionará em um cenário de coexistência, onde os clientes se conectar aos servidores Exchange 2010 da autoridade de certificação e são redirecionados para os servidores Exchange 2003 FE. Você sabe se funcionará neste cenário?

**R.**Sim, os usuários do OWA 2003 acessarem suas caixas de correio autenticando contra servidores de autoridade de certificação Exchange 2010 que redirecione a sessão para servidores do Exchange 2003 FE. Isso funcionará mesmo com SSL habilitado sobre a solução de balanceador de carga e servidores Exchange 2010 CA.

Alguns de vocês talvez esperasse outra resposta. URL do Exchange 2003 configurada no diretório virtual OWA 2010 deve estar na forma de "https://legacy.contoso.com/exchange" e não "http://legacy.contoso.com/exchange". Caso contrário, você obterá um 91 de ID de evento no log do aplicativo (consulte a Figura 3).

Figura 3 erro no log do aplicativo quando URL legado é configurado com HTTP, em vez de HTTPS.

O legacy URL deve começar com HTTPS e não HTTP. Porque os servidores de autoridade de certificação Exchange 2010 simplesmente redirecionam a sessão do cliente para um servidor Exchange 2003 FE, ele funcionará bem ao usar HTTPS para o URL de legado do OWA.

Fila de cópia

P. Quando trabalho com diversos cenários de Exchange 2010 DAG (geralmente em ambientes de laboratório), algumas vezes, vejo um comprimento de fila de cópia extremamente alto (consulte a Figura 4).

Figura 4 uma fila de cópia extremamente alto é sempre uma possibilidade.

Na primeira vez, percebi que ela pensei, "o que o?" Após mais investigação, vejo que é o mesmo número exato toda vez que elas ocorram. Você sabe se este é um bug ou algo?

**R.**O número você vendo é o valor mais alto, você pode definir para o comprimento da fila de cópia. Cópia do log não está acontecendo e as atualizações de banco de dados de cluster não estão acontecendo. Uma perda de conectividade de rede entre os nós de DAG geralmente faz com que algo assim.

Em um ambiente de laboratório lenta, isso pode ocorrer ocasionalmente. Você não deve vê-lo em um ambiente de produção, embora. Se fizer isso, recomendo tentar encontrar a causa básica de perder a conectividade de rede entre os nós DAG..

**Henrik Walther**é um Microsoft Certified Master: Exchange 2007 e MVP em Exchange com mais de dezesseis anos de experiência na atividade de TI. Ele trabalha como arquiteto de tecnologia para um Microsoft Gold Certified Partner na Dinamarca e como redator técnico da Biblioso Corp. (uma empresa baseada nos EUA especializada em gerenciado documentação e serviços de localização). Ele também é um fornecedor contratado trabalhando em várias equipes de produtos (inclusive as equipes do Exchange e Lync) na Microsoft.

Conteúdo relacionado

• Fila do Exchange & R: não existe mais para os DAGs
• Fila do Exchange & A:. transições e migrações de
• Fila do Exchange & R: migrar caixas de correio