Arquivos do Blog

Hybrid Configuration: Re-Migrando as caixas postais após cancelar o Move-Request

 

 

 

 

Olá pessoal,

Quando iniciamos um New-RemoteMoveRequest, no cenário de Exchange Híbrido, esta solicitação é criada automaticamente no ambiente do Exchange Online e marca o Mailbox no Exchange On-Premise com o símbolo de “Mailbox Movida”, conforme figura abaixo:

 

image

 

Porém, quando cancelamos esta requisição por algum motivo, ao tentar fazer a migração deste usuário novamente, as opções de “New-MoveRequest” e “New-RemoteMoveRequest” não aparecem, devido ao status de Move da Mailbox, que para o Exchange esta com o Status de “Mailbox Movida”.

É importante notar que a Move-Request é criada na Floresta do Exchange Online, e não localmente.

Para re-migrar os usuários basta seguir os seguintes passos:

 

1 – Abrir o ADSIEdit.msc e navegar até a partição de “Default Naming Context”:

 

image

 

2 – Em “Propriedades” do usuário, alterar o valor msExchMailboxMoveStatus  para “Not Set”:

 

image

 

3 – Pronto! Agora basta ir até o Exchange e verificar que o objeto não se encontra mais com o ícone de “Mailbox Migrada”.

 

Até a próxima,

Diogo Heringer

clip_image001

Exchange Server 2013 Preview: Movendo um Mailbox (New-MigrationBatch)

 

 

Olá pessoal,

No Exchange Server 2013 temos algumas novas opções quando iniciamos o Move de um Mailbox. A principal diferença é que agora além de buscar os Mailbox que serão migrados no Active Directory podemos tam mbém fazer a migração de várias Mailbox através da leitura de um arquivo CSV.

O arquivo CSV deve ter apenas uma coluna com o título: EmailAdress

 

image

 

Vamos ao passo a passo para migração do Mailbox:

 

1 – No EAC (Exchange Admin Center) navegar até Recipients > Migration:

 

MV - 2

 

2 – Clicar no botão “+” e selecionar o Mailbox que deseja migrar através do Active Directory ou pela leitura do CSV.

Neste exemplo vamos selecionar o usuário no Active Directory:

 

MV - 3

 

(Janela aberta ao clicar em “+” para adicionar Mailbox do Active Directory)

MV - 4

 

3 – Com o usuário selecionado vamos clicar em “Next”:

 

MV - 5

 

4 – Vamos dar um “Nome” para a Batch de Migração e em seguida escolher a opção “Move Primary Mailbox Only”, já que não temos Mailbox de Archive.

 

MV - 6

 

Escolher a MailboxDatabase de destino clicando em “Browse”:

 

MV - 7

 

Clicar em “Next”.

 

5 – Escolher o Malbox para qual o e-mail de Report será enviado clicando no botão “Browse””.

Deixar marcado o CheckBox “Automatically start the batch” e marcar também “Automatically complete the migration batch”.

 

MV - 8

 

Clicar em “New”.

 

Caso não marque o Checkbox “Automatically start the batch” você terá a opção de iniciar o “Migration Batch” manualmente depois que ele for criado.

Caso não marque o Checkbox “Automatically complete the migration batch” você terá que completar a migração do Mailbox manualmente após ela ser iniciada clicando no botão “Complete Migration Batch”.

 

6 – Verificar o status do Mailbox migrado:

 

MV - 10

 

7 – Pronto! Agora nosso Mailbox foi migrado para outra Database com sucesso!

 

Até a próxima,

Diogo Heringer

clip_image001

Projeto Office365: Problema no Mailbox Replication Service (MRS)

timeline_450

O Mailbox Replication Service é o serviço responsável por fazer a migração dos Mailbox no Ambiente Híbrido de Exchange Server 2010 + Exchange Online. Desde ontem estava com problemas ao realizar a migração, pois todo “New-RemoteMoveRequest” que eu realizava ficava apenas com status de “Queued”, sendo que o status correto seria “Moving”. Não é gerado nenhum log no Event Viewer relacionado a este problema.

Ao pesquisar e depois de tentar resolver quase todos os problemas do Event Viewer (rs), percebi que esqueci de fazer o básico: Verificar a “Integridade do Serviço” no Portal do Office365.

Segue um print do problema:

image

Note que já tem 38 minutos para migrar uma conta de 47MB, isto não é normal.

Ao verificar a “Integridade do Serviço” no Portal Office365 juntamente com o fato de que eu já tinha migrado contas anteriormente, pude perceber que o problema não está no meu ambiente On-Premise, e sim é um problema que a Microsoft está passando e que está sendo solucionado o mais rápido possível.

Segue a nota do problema:

clip_image002

We’ve found the root cause for the Move Requests failures and are working on a code fix to resolve the problem. The ETA for that fix to get coded, tested, and completely deployed worldwide is Wednesday 5/9, at 8AM PDT, so certain types of new mailbox onboarding have been halted until this fix is put into place. A clarification on the types of onboarding that are currently blocked: 1) BPOS to O365 transitions 2) Exchange on-premise to O365 migrations using the Mailbox Replication Service (MRS) Types of onboarding that are not blocked: 1) 3rd party IMAP tools 2) 3rd party Exchange Web Services (EWS) tools 3) 3rd party MAPI tools We apologize for the inconvenience this is causing and the delay it is causing you to experience in your onboarding to Office 365. We will continue to regularly update this as we make progress toward resolution.

Para quem está com o mesmo problema fique tranquilo! Ele já está sendo tratado e em breve estará resolvido.

Até a próxima,

Diogo Heringer

clip_image001

Projeto Office365: Entendendo Mailbox Moves em Ambientes Cross-Premises (Office 365)

 
O ambiente on-cloud Office 365 da Microsoft roda em Exchange 2010, portanto quando efetuamos um move mailbox entre mailbox databases, o processo é executado pelo Microsoft Exchange Mailbox Replication Service (que será tratado como MRS).

O MRS é um serviço que é executado nos Exchange 2010 CAS servers e é o serviço que irá receber o move request do administrador e mover a mailbox de uma database para outra. O MRS suporta os mailbox moves sendo eles online ou offline, em um ambiente cross-premisse este move é considerado online.

Este é um exemplo de como um move request (simples) é executado:

image

  1. O administrador cria o move request utilizando o New-MoveRequest;
  2. O New-MoveRequest efetua as validações necessárias na mailbox que será movida;
  3. O New-MoveRequest cria uma mensagem de request que é inserida no DB do target server;
  4. Os seguintes atributos são adicionados na conta do usuário, para armazenar informações que serão utilizadas pelo move e que serão atualizadas durante o processo:
    • msExchMailboxMoveBatchName
    • msExchMailboxMoveFlags
    • msExchMailboxMoveRemoteHostName
    • msExchMailboxMoveSourceMDBLink
    • msExchMailboxMoveStatus
    • msExchMailboxMoveTargetMDBLink
  5. 1- O New-MoveRequest aciona o MRS informando que uma nova requisição de move está pronta para o processamento;
  6. 2- O MRS atualiza o atributo msExchMailboxMoveStatus do objeto no AD;
  7. 3- O MRS inicia o sincronismo de data;
  8. 4- Assim que o sincronismo é completo, o MRS irá efetuar o “lock” da account;
  9. 5- Após o lock, o MRS iniciará o delta, aonde será feito o sincronismo de mensagens novas ou de itens alterados;
  10. 6- O MRS irá então atualizar os atributos no AD para o mailbox enabled user (nova account criada):
  11. HomeMDB
  12. HomeMTA
  13. HomeServer
  14. MSExchangeVersion
  15. Proxy Address
  16. Target Address
  17. 7- O MRS remove a source mailbox do source DB e altera o move status do msExchMailboxMoveStatus e msExchMailboxMoveFlags para “Completed”;
  18. 8- Assim que este status for atualizado, a mailbox pode ser acessada;
  19. 9- No Exchange 2010, cada instância do MRS mantém um track dos move requests. Esta fila pode ser acessada utilizando o comando “Get-MoveRequestStatistics”, como é o exemplo abaixo:

Get-MoveRequestStatistics “Exchange Server” –MoveRequestQueue “User-Mailboxes”

MRSProxy

No Exchange 2007, quando administradores tinham que efetuar mailbox moves entre diferentes florestas (cross-forest environment), era necessário habilitar o acesso MAPI entre os servidores, configurar trusts e habilitar o full administrator access para os administradores em ambas as Exchange Organizations.

O MRSProxy trabalha em conjunto com o MRS para facilitar a comunicação requerida entre o source e target server em cada floresta de Exchange Server 2010. Cada CAS server posssui uma instância do MRS e uma instância do MRSProxy como uma parte da implementação do Exchange Web Services (EWS). A grande diferença é que o MRSProxy não vem habilitado por default no CAS server.

Portanto, para efetuar um move em um ambientes cross premise ou até em um cross forest, é necessário habilitar este serviço. Para habilitar este serviço, basta configurar o arquivo de configuração (web.config) para o CAS on-premise. Lembre-se de habilitar para ambos os CAS nodes se você possui um array configurado.

Habilitando o MRSProxy

1. No servidor on-premise, abra o arquivo de configuração com o seu notepad:

<Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config

2. Altere a configuração de IsEnabled de False para True:

<!– Mailbox Replication Proxy Server configuration –>
<MRSProxyConfiguration
IsEnabled=”False”
MaxMRSConnections=”100″
DataImportTimeout=”00:01:00″ />

3. Salve e feche o arquivo;

4. Reinicie o serviço do MRS e o IIS para que as alterações tenham efeito.

 

Lembrando que ao utilizar o “Hybrid Configuration” disponível no Exchange 2010 SP2, o MRSProxy é habilitado automaticamente.

 

Até a próxima,

Diogo Heringer

clip_image001

Exchange On-Premise: New Local Move Request

 

12234655723mefzC

 

Uma atividade comum na administração do Exchange Server 2010 é mover Mailbox entre Databases diferentes. Muita das vezes por questão de organização devemos re-alocar os nossos usuários em novas Databases, ou até mesmo por questão de espaço em disco.

Para fazer esta re-alocação vamos utilizar o EMC (Exchange Management Console) e o comando “New Local Move Request”. Vamos lá:

 

1 – Abrir o EMC (Exchange Management Console), expandir o nó “Recipient Configuration”, navegar até “Mailbox”:

 

 

image

 

2 – Clicar com o botão direito do mouse na Mailbox que desejamos migrar e em seguida em “New Local Move Request…”, para abrir a seguinte janela:

 

image

 

3 – Através do botão “Browse” vamos escolher a Database de destino. Clicar em “Next”:

 

image

 

4 – Na página “Move Settings” deixar as configurações padrões e clicar em “Next”:

 

image

 

5 – Na tela de resumo das configurações vamos clicar em “New”:

 

image

 

6 – O comando foi completado com sucesso.

 

image

 

Agora a Mailbox “Diogo Heringer” que estava na Database “heringerDB” se encontra na Database “heringerDB2”.

 

Abraço a todos,

Diogo Heringer

clip_image001

Criando Databases e movendo as “Arbitrations Mailbox”

Olá pessoal,

Como podemos ver após o Exchange Server instalado uma Database é criada automaticamente e nesta Database temos duas Mailbox “visíveis”, que são o Administrator e o DiscoverySearchMailbox. Digo “visíveis” pois além destas duas Mailbox existem também algumas outras Mailbox que desempenham funções para o nosso Exchange. Antes de falar destas Mailbox irei listar os tipos de Mailbox que temos no Exchange Server 2010.

  • Room Mailbox: Caixa de correio para agendamento de salas.
  • Equipment Mailbox: Caixa de correio para agendamento de equipamentos.
  • Linked Mailbox: Caixa de correio que é acessada por um usuário em uma floresta confiável separada.
  • Forwarding Mailbox: Caixa de correio que pode receber e encaminhas mensagens fora do local de trabalho (off-site).
  • Archive Mailbox: Caixa para armazenar as mensagens de um usuário, como seria necessário para usuários de maior importância na organização.
  • Arbitration Mailbox: Caixa utilizada para gerenciar solicitações de aprovação, como pode ser necessário para manipular aprovações de membro de grupo e destinatários moderadores.
  • Discovery Mailbox: Destino das pesquisas de Discovery e, depois de criada, não pode ser convertida em outro tipo de caixa de correio.
  • Shared Mailbox: Caixa de correio que é compartilhada por múltiplos usuários, como uma caixa de correio geral para pesquisa de clientes.

Agora que conhecemos todos os tipos de Mailbox irei mostrar como “enxergar” estas Mailbox “Invisíveis”, que são na verdade as “Arbitrations Mailbox”.

Na imagem abaixo podemos ver a Database que foi criada automaticamente na instalação do Exchange Server:

image

Para visualizarmos as Mailbox que estão criadas devemos navegar até “Recipient Configuration” e em seguida “Maiilbox”:

image

Note que as “Arbitrations Mailbox” ainda não foram mostradas. Para exibir estas Mailbox devemos acessar o Exchange Management Shell (EMS) e executar o seguinte comando:

Get-Mailbox –Database <Nome da Database> –Arbitration

image

Através deste comando podemos exibir as “Arbitrations Mailbox”, agora o próximo passo é criar uma nova Database para que possamos mover estas Mailbox para a nova Database. Para criarmos esta nova Database devemos navegar até “Organization Configuration”, em seguida “Mailbox” e Clicarmos no botão “New Mailbox Database”

image

Assim que clicarmos em “New Mailbox Database” abrirá uma nova janela o qual você deverá digitar no primeiro campo o “Mailbox Database Name” e no segundo campo “Server name´”, o nome do servidor que irá hospedar esta database.

image

A janela abaixo será aberta quando clicarmos em “Browse” para escolher o servidor:

image

Com o nome da Database e o Servidor escolhido o próximo passo é definirmos o local de armazenamento dos Logs e o local de armazenamento das Databases. Iremos marcar também a opção para que a Database seja montada assim que concluirmos a criação da mesma.

image

Após clicar em “Next” teremos a tela de confirmação da criação das “Databases, onde iremos clicar em “New”:

image

Enfim nossa Database está criada e pronta para receber novas Mailbox.

image

Com a nova Database criada podemos mover as “Arbitrations Mailbox” para a nova Database e remover a Database padrão criada pelo Exchange:

Get-Mailbox –Database “Mailbox Database 1445973460” –Arbitration | New-MoveRequest

-TargetDatabase “heringerDB”

image

Agora que nossas Mailbox já estão na nova Database criada, podemos remover a Database padrão criada pelo Exchange Server.

Primeiramente devemos apagar as “Move Requests” e em seguida iremos apagar a Database criada pelo Exchange. Para apagar as “Move Requests” basta navergarmos até “Recipient Configurations”, em seguida “Move Requests” e selecionarmos as Move Requests a serem deletadas e no “Action Panel” clicar em “Clear Move Requests”.

image

Para remover a Database basta navergamos até “Organization Configuration”, em seguida “Mailbox” e na guia “Database Management” selecionar a Database criada pelo Exchange Server. Feito isso iremos no “Action Panel” e iremos clicar em “Remove”, mas antes disso devemos mover a Mailbox do Administrator e a Discovery Search mailbox através do EMC com o botão “New Local Move Request”.

Para fazermos o” “New Loca Move Request” basta selecionarnos os Mailbox a serem movidos, navegando até “Recipient Configuration” e logo após clicando em “New Local Move Request” no “Action Panel”. Selecionamos a Database e destino e clicamos em “Next”.

image

Iremos marcar a opção para que o move do Mailbox seja descartado em casa de mensagens corrompidas, clicaremos em “Next” e logo após em “New” para podermos realizar o move da Mailbox:

image

Clicando em “New” teremos o resultado que as Mailbox foram movidas com sucesso.

image

Após mover as Aritration Mailbox e e as Mailbox criadas pelo exchange podemos confirmar a exclusão da database criada pelo Exchange Server e assim teremos apenas a database que criamos.

image

image

Então pessoal, agora já sabemos fazer o Move-Request das “Arbitrations Mailbox” e fazer a remoção da Database criada por padrão no Exchange Server 2010.

Até a próxima!

Abraço a todos,

Diogo Heringer

clip_image001