Freigeben über

Como o evento 9359 pode tirar o sono do administrador Exchange

  • Artikel

Autor: Rodrigo de Andrade Dias / Technical Reviewer: Viviane Lopes

O seu coordenador te liga no meio da noite, e te diz algo que só Sherlock Holmes estaria acostumado: Os usuários sumiram! Da GAL... (O cenário):

Você possui um servidor Exchange 2010 Service Pack 1, em dia, e com todos os updates possíveis.

Você está seguro, com a certeza de estar fazendo um ótimo trabalho, e se dá ao direito de cogitar desligar o celular do plantão, no domingo à tarde, para ver a o SuperBowl em paz.

Ironicamente, o celular do plantão toca, já na sua mão, e você diz: “Celular inconveniente!” (É claro que você não diz só isso).

O coordenador explica que o endereço de e-mail de uma das caixas de correio do Exchange 2010 SP1 (com tudo em cima), simplesmente não está aparecendo para os usuários do Microsoft Outlook. E você se pergunta: “Por que ele me liga no domingo a tarde, se é só um usuário”. Mas a História nos ensina que nada é tão ruim que não possa piorar. E o coordenador completa que a conta do usuário é a conta do seu Vice-presidente do setor de TI (novidade). Rá! Você acaba de perder o SuperBowl...

Você testa o seu cliente Outlook 2010 e constata a chateação já comunicada pelo chefe. Vai até o console remoto de seu Windows Server 2008 R2 (obviamente, com tudo em cima, e em breve com SP1), e faz o que ninguém mais poderia:

  1. Abre o Powershell no Mailbox server, usando “run as Administrator”

  2. Executa um belo Get-GlobalAddressList | Update-GlobalAddressList

  3. Executa mais um belo Get-OfflineAddressBook | Update-AddressBook

    Mas você não é um mero Administrador Exchange convencional, então, você acessa o CAS server e no Powershell (admin mode), faz um:

  4. “Get-Service MSExchangeFDS | Restart-Service”, só para acelerar a entrega do recém gerado OAB file (passo 3) que já conta com a nova GAL (passo 2).

De volta ao cliente Outlook 2010, você não perde tempo, e vai até a aba “Enviar e receber”, e depois, clica em “Grupos de envio e recebimento”, finalizando com “Baixar o Catálogo de endereço”. Maroto! Assim, você baixou só o que lhe importava. Muito bem! MAS LEMBRE-SE que nada é tão ruim que não possa piorar... O problema não se resolve, e você teme que possa ter que fazer mais do que recriar o OAB distribution file.

Não se limitando ao básico, você abre o event viewer em seu Mailbox Server, e vai direto ao Application Log. E você se depara com seu verdadeiro desafio... Um tenebroso evento 9359, com cara de um inofensivo “information”, mas que trás a horrível notícia da fonte (source) MSExchangeSA, igualzinho esse aqui:

++++++++++++++++++++++++++
Log Name: Application
Source: MSExchangeSA
Date: 12/03/2021 15:11:30
Event ID: 9359
Task Category: (13)
Level: Information
Keywords: Classic
User: N/A
Computer: exchlab2k7-cms.mssupport2k7.local
Description:
OALGen truncated or dropped properties for entry 'O chato do seu vice-presidente' in address list '\Global Address List' because they exceeded the configured size limits for the version 4 offline address list. The affected MAPI ids are: 8c6a 8008.
- \OAB
Event Xml:
<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="MSExchangeSA" />
<EventID Qualifiers="16384">9359</EventID>
<Level>4</Level>
<Task>13</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2021-12-03T15:11:30.000000000Z" />
<EventRecordID>209741</EventRecordID>
<Channel>Application</Channel>
<Computer>O_seu_Mailbox_server</Computer>
<Security />
</System>
<EventData>
<Data>O chato do seu vice-presidente</Data>
<Data>\Global Address List</Data>
<Data> 8c6a 8008</Data>
<Data>\OAB</Data>
</EventData>
</Event>
++++++++++++++++++++++++++

Não perde tempo: Abre seu browser predileto (O Internet Explorer, claro), e vai direto ao seu buscador preferido (O Bing!, lógico!). Digita: “event 9359 exchange 2010 mapi Id” e qual não é sua surpresa com o primeiro tópico que surge? É este aqui? => PLEASE READ –> Events 9320 and 9359 on new installation of Exchange 2010 … E o que ele te diz pra fazer? Para ignorar e voltar para o SuperBowl! Você fica contente com a ideia, mas pensa: “Tem algo de muito errado. Se posso ignorar esse evento tranquilamente, por que é que não vejo o usuário lá? O pessoal da Microsoft pirou de vez”.

Então, cansado, você liga para o suporte Microsoft, e fala conosco. Aí te explicamos o que realmente está havendo.

Por quê? E como resolver? (Possíveis causas; e solução):

O que você deixou passar foram 4 digitozinhos: 8c6a.

Olhando o post no Blog do nosso colega “DGoldman”, vemos uma mensagem idêntica a nossa:

Description: OALGen truncated or dropped properties for entry ‘Dgoldman’ in address list '\Global Address List' because they exceeded the configured size limits for the version 4 offline address list. The affected MAPI ids are: 8008. - \Default Offline Address Book

Só que a nossa mostra algo a mais:

Description: OALGen truncated or dropped properties for entry 'O chato do seu vice-presidente' in address list '\Global Address List' because they exceeded the configured size limits for the version 4 offline address list. The affected MAPI ids are: 8c6a 8008.

Isso muda tudo…

O valor 8c6a, nos mostra que o problema é um pouco maior. Investigando em nossa base de dados, descobri que isso ocorre quando um usuário do AD (mailbox-enabled) tem muitos certificados ligados ao seu objeto de AD.

Ainda não temos o motivo pelo qual o usuário acaba entupido de certificados, mas de todo modo, a solução existe! Yes! J

  1. Abra o “Active Directory Users and Computers”, e no menu “View”, clique em “Advanced Features”.
  2. Localize o objeto que representa o usuário afetado, descrito no evento 9359, e exiba as propriedades do usuário.
  3. Localize a aba “Published Certificates” e... Tcharans! Você achará uma longa lista de certificados (eu precisei de mais de 30 certificados para simular o problema, e no ambiente real, o cliente tinha mais de 150) nessa aba, e é este o seu vilão.
  4. Você pode fazer o back-up desses certificados (clicando em “Copy to file”), e após isso, não tenha dó de removê-los, com o botão “Remove”. Mas, atenção: Algumas aplicações muito específicas podem precisar desses certificados, então converse com seu time de TI, e garanta que esses certificados estão lá por excesso, e não por necessidade.

No cenário que abordei, todos os certificados vinham com o campo “Intended Purposes” descrito assim: “Encrypting File System, Secure E-mail, Client Authentication”, o que, sinceramente, assusta demais. Na prática, eu não tinha nenhuma dessas funções ativas para o usuário, e remover esses certificados não causou nenhum efeito, além do desejado efeito de corrigir o problema com o OAB.

Após remover todos os certificados do usuário, utilizei novamente os cmdlets “Update-GlobalAddressList” e “Update-OfflineAddressBook” no Mailbox, além do “restart” do File Distribution Service no CAS, e o usuário apareceu, após o download do novo OAB no cliente Outlook.

Isso ocorre porque o limite do Offline Address Book v4, para este campo do usuário do AD, é de 64KiB. Teoricamente, esse tamanho nos permite algo em torno de 30 certificados por usuário, variando do conteúdo de cada certificado (número de nomes, funções e etc.), é lógico.

Em outra pesquisa que fiz, parece que o problema pode surgir se diversas GPO’s forem aplicadas ao usuário e cada uma definir um certificado diferente ao mesmo. No entanto, eu não consegui esse efeito através de GPO’s, logo, não sei se esse é um fator relevante.

Para saber mais:

Até a próxima!