Compartir a través de


Recuperando Mailboxes Inativas no Exchange Online

Por: Caio Ribeiro César

 

Já discutimos o método de recuperação de objetos sincronizados com HardMatch e SoftMatch. Alguns administradores me perguntam – enfim, e no Exchange?

Existem diversos métodos. O método irá variar de acordo como o ambiente foi preparado – por exemplo, existe algum tipo de litígio nos dados para que possamos exportá-los para uma nova/segunda mailbox? A mailbox está recoverable (soft deleted/inactive)?

O blog post faz referência ao artigo da Microsoft – recomendo que este seja revisado como conteúdo adicional.

Conforme informado anteriormente, o hold nos ajdua em recuperação de dados e de mailboxes. Uma mailbox pode se tornar inativa caso o Litigation/InPlace seja habilitado na mailbox antes de que ela seja removida e o grace period de softdeleted (30 dias) tenha sido alcançado.

O conteúdo é preservado, habilitando ao administrador uma recuperação mais simples.

Caso o Hold não seja habilitado para uma mailbox e ela seja removida, ela entra no que chamamos de status “SoftDeleted” – significa que ela ficará 30 dias disponível para a recuperação, após os 30 dias, o conteúdo é removido permanentemente do Exchange Online, o que chamamos de status “HardDeleted” ou “Purged”.

SoftDeleted – mailbox removida em grace period de 30 dias. Pode ser recuperada no período;

InactiveMailbox – mailbox removida, com hold habilitado. Pode ser recuperada no período de hold (configurado pelo administrador);

HardDeleted – mailbox removida, sem hold habilitado em que o período de 30 dias é excedido.

Quando o administrador valida que uma mailbox está Inactive/SoftDeleted/HardDeleted e não sabe o motivo, vale a pena revisar:

a)      Exchange Online Admin Logs. Caso a mailbox tenha sido removida por outro GA, o Exchange terá os logs de administração que podem nos auxiliar a entender o ocorrido;

b)     Azure Active Directory Audit Logs. Para entender se algum objeto que possui a mailbox foi removido por algum administrador específico;

c)      RBAC. Se existe permissão, deve existir um controle de quem a possui. Em resumo, os comandos abaixo podem ajudar a identificar os admins da empresa vs. roles atribuídas.

Get-RoleGroupMember "Organization Management“

Get-RoleGroupMember "TenantAdmins_XYZ"

Get-RoleGroup "Organization Management" | Select-Object -ExpandProperty RoleAssignments

Get-ManagementRoleAssignment -GetEffectiveUsers | Where { $_.EffectiveUserName -Eq "usuario" }

d)     Remover uma licença de Exchange, remove uma Mailbox. Atribuir uma licença de Exchange, atribui uma Mailbox. Alguma licença de Exchange foi removida do usuário em questão?

Então para simular uma recuperação, tenho que inicialmente habilitar algum tipo de litígio na mailbox para que após a remoção (+30 days), ela possa ser recuperada como uma InactiveMailbox.

clip_image002

clip_image004

Exchange Admin Center > Recipients > Mailboxes > Mailbox Edit > Mailbox Features > Litigation Hold > Enable

clip_image006

Ou seja, configurei a mailbox para litígio em tempo “unlimited”. Caso a mailbox seja removida, os dados ficarão sempre disponíveis para o administrador (a não ser que sejam manualmente removidos).

Comparando mailboxes - com e sem Litigation:

clip_image008

clip_image010

Já discutimos anteriormente o melhor método para remover/atribuir licenças. Hoje, temos ainda a possibilidade de utilizar a feature “switch plans”, que facilita o administrador para alterar subscrições sem perder dados.

clip_image011

O que seria remover uma licenca de Exchange Online? Remover uma licença de Exchange Online é o mesmo que remover a mailbox atribuída ao objeto do WAAD. Então iremos utilizar este método para remover as mailboxes:

clip_image015

*A mailbox “jude” (com litigation habilitado em 2014) também foi removida - manualmente pelo portal, já que era uma shared mailbox e não possui licenciamento.

Comportamento mailbox vs. mailbox com litigation:

clip_image017

clip_image019

Temos então 3 mailboxes removidas:

jude – shared mailbox com litigation, removida manualmente

test pg – mailbox com litigation, removida pelo licenciamento

aux pg – mailbox sem litigation, removida pelo licenciamento

 

Inactive mailboxes:

clip_image021

Para recuperar as mailboxes inativas, tendo em conta que os 30 dias de SoftDeleted já foram alcançados, iremos inicialmente coletar mais informações:

clip_image023

Então irei criar uma variável para cada mailbox inativa e criar uma new-mailbox com o valor de ExchangeGUID ou DN:

clip_image025

Então irei executar o comando New-Mailbox para cada variável:

clip_image027

clip_image029

As inactive mailboxes são recuperadas:

clip_image031

O processo de recover, informado acima, cria uma nova mailbox para que os dados sejam preservados. Existe um segundo processo chamado “restore”, em que os dados são migrados para uma mailbox existente. Chamamos isto de “merge” ou processo de “restauração”.

O processo de restore geralmente é efetuado quando a inactive mailbox está em um ambiente federado. Caso o admin tente efetuar o recover de uma federated inactive mailbox, ele receberá o erro:

"The parameters passed to the cmdlet represent a managed account, which doesn't match the namespace state, which is federated"

Para efetuar o restore, ou seja, migrar os dados de uma inactive mailbox para uma mailbox existente basta efetuar o restore com os comandos abaixo:

$InactiveMailbox = Get-Mailbox -InactiveMailboxOnly -Identity <identity of inactive mailbox>

New-MailboxRestoreRequest -SourceMailbox $InactiveMailbox.DistinguishedName -TargetMailbox newemployee@contoso.com -AllowLegacyDNMismatch

Exemplo:

New-MailboxRestoreRequest -SourceMailbox $InactiveMailbox.DistinguishedName -TargetMailbox newemployee@contoso.com -TargetRootFolder "Inactive Mailbox" -AllowLegacyDNMismatch

Veja que a diferença é que no recover, utilizamos o new-mailbox. Já o restore, utilizamos um request com o valor de TargetMailbox, ou seja, uma mailbox existente que receberá estes dados.

Já a mailbox “aux pg”, por não possuir hold, ficará com o status “SoftDeleted” por 30 dias. Após este período, a mailbox será “HardDeleted”:

clip_image033

Para recuperar uma mailbox “softdeleted”, basta executar o comando abaixo:

clip_image035

Então confirmamos:

clip_image037

clip_image039

 

Como precaução:

- Valide com os usuários finais se os dados coincidem com o que a mailbox possuia antes do restore;

- Valide a uilização da mailbox (Get-MailboxStatistics);

- Valide se o objeto não é sincronizado, em que o restore de objeto deve ser feito no SoA;

- Tenha certeza de que o objeto possui licenciamento de Exchange (caso contrário, os dados serão removidos após o grace period);

- Se a mailbox está sendo removida de tempos em tempos, valide retention e ações feitas por outros administradores;

- Se o conteúdo da mailbox está sendo removido de tempos em tempos, valide mailbox audit/inbox rules/retention policies/shared permissions/mobile access na mailbox/ações feitas por outros administradores;

 

Se você não conseguir recuperar uma InactiveMailbox com o erro:

 

The ExternalDirectoryObjectID of this inactive mailbox still exists and this command can only be executed when

inactive mailbox does NOT have ExternalDirectoryObjectID. Please run Undo-SoftdeletedMailbox -SoftDeletedObject to

recover it.

 

Basta executar o commando Undo-SoftDeletedMailbox ou recuperar o Usuário no portal.

 

O valor “ExternalDirectoryObjectID” informa o período de retenção de uma SoftDeletedMailbox. Se este valor é inferior a 30 dias, significa que ela ainda pode ser recuperada sem o método de InactiveMailbox restore.

 

Caso o valor seja nulo, isto significa que o período de 30 dias já expirou e a mailbox pode ser recuperada/restaurada pelos processos descritos neste post. Lembrando sempre que isto só pode ser feito caso a mailbox tenha hold habilitado antes de ser removida, caso contrário ela será HardDeleted.

Comments

  • Anonymous
    January 19, 2017
    Muito bom este artigo. Muito claro e objetivo nas informações!Show...
    • Anonymous
      January 26, 2017
      Obrigado
    • Anonymous
      January 26, 2017
      Muito Obrigado!