Troubleshooting

Exchange 2010 – The certificate status could not be determined because the revocation check failed

Problema

Quando você tem proxy configurado no IE, pode receber um erro na console do Exchange relacionado à certificado digital, onde o Exchange não consegue checar os endereços de CRL (Certificate Revocation List) da unidade certificadora pública. Isso pode ser causado também por firewall ou algum bloqueio, pode ser que você configure a solução abaixo mas o endereço não esteja liberado em seu proxy.

O problema foi reportado no seguinte link:

http://msexchangeteam.com/archive/2010/07/26/455639.aspx

Você irá obersar a seguinte imagem na console do Exchange 2010:

Screenshot: Status of certificate with revocation check failed

“The certificate status could not be determined because the revocation check failed”.

Solução

Para consultar suas configurações de proxy, abra o powershell ou cmd, e execute:

netsh winhttp show proxy

Deverá aparecer algo como:

image

O que vamos fazer é importar as configurações de proxy do IE, rodando o comando abaixo:

netsh winhttp import proxy ie

As configurações são importadas da seguinte configuração do IE, então valide que seu proxy está configurado corretamente.

image

Após isso, verifique se o problema de certificado continua no Exchange. Se você não consegue habilitar o certificado no Exchange 2010, você pode habilitar via Shell, pois o shell não verifica esse problema de CRL.

Referência:

http://technet.microsoft.com/pt-br/library/bb430772(v=exchg.141).aspx

Share

Post to Twitter

Exchange 2013 – Content Index status Failed

Introdução

As vezes o estado do Content Index fica marcado como Failed quando você verifica através do comando: Get-MailboxDatabaseCopyStatus.

 

Problema

Ao rodar o comando: Get-MailboxDatabaseCopyStatus, você vê o status do content index como Failed, conforme imagem abaixo:

Screenshot for the status of content indexes

Você também pode encontrar o evento: 1009 ou 1010 no Event Viewer.

Log Name: Application
Source: MSExchangeFastSearch
Event ID: 1009
Task Category: General
Level: Warning

Log Name: Application
Source: MSExchangeFastSearch
Event ID: 1010
Task Category: General
Level: Warning

Segundo o KB:

http://support.microsoft.com/kb/2807668

“This issue may occur if the search platform tries to check its membership in a security group that is named "ContentSubmitters." This group is not created by the search platform or by Exchange Server 2013 and is therefore not usually present. Although the check usually fails silently, without any consequences, an exception sometimes occurs. This causes the search component to fail.”

Ou seja, isso ocorre quando a plataforma de pesquisa tentar checar os membros de um grupo de segurança chamado “ContentSubmitters”. Mas o grupo não é criado pelo Exchange e não vai estar lá.

Segundo eles, esse erro falha silenciosamente  Confused smile

Mas uma exceção pode ocorrer (como no meu caso) Sad smile

E o componente pode falhar, deixando o status como Failed.

 

Solução

Há duas formas de resolver, verifique o KB citado, mas prefiro a primeira, segue abaixo:

 

Method 1

 

  1. Create a new Active Directory group that is named "ContentSubmitters," and then grant Admistrators and NetworkService full access to the group. This is a dummy group and should be used as a placeholder only. You might want to add a description so that the group is not removed. 
  2. Force or wait for Active Directory replication.
  3. Restart the following services:
    • Microsoft Exchange Search 
    • Microsoft Exchange Search Host Controller
  4. Acho mais rápido e prático essa solução.

    KB: http://support.microsoft.com/kb/2807668
Share

Post to Twitter

Resolvendo problemas de integração AD RMS e Gigatrust Desktop Client 8.0

 

Sintomas:

 

Quando vamos abrir um documento PDF protegido por um template do AD RMS, mesmo que o usuário tenha permissão para abrir o arquivo, o arquivo não abre.

Isso levando em consideração que as chaves de registro que o Gigatrust precisa para encontrar os templates do AD RMS esteja devidamente configuradas.

 

Causa:

 

A versão 8.0 está com bug no que diz respeito a acentos que colocamos no campo descrição dos templates do AD RMS.

 

Solução:

 

A solução encontrada foi ou o downgrade na versão do GigaTrust Desktop Client ou a retirada dos acentos dos templates do AD RMS. Segundo a empresa responsável, isso já esta sendo tratado em laboratório.

 

Nota:

 

Foram encontrados alguns outros bugs nessa versão, como por exemplo, o nome que utilizamos para proteger o arquivo PDF, está vindo como algo assim “IDS_COMMOM_COMPANY”.

Share

Post to Twitter

Resolução de problemas ao inserir usuários em grupos associados a templates AD RMS

 

Sintoma:

 

Quando temos um grupo associado a algum template do AD RMS, e inserimos um usuário ao grupo, porém o usuário inserido no grupo ainda não possui a permissão atribuída ao template.

Causa

Isso se deve ao cache de grupos que o AD RMS deixa armazenado no seu banco de dados, esse período é de 12 horas por padrão, ou seja, se inserirmos algum usuário em um grupo que esteja associado com um template do AD RMS, esse usuário só estará habilitado a utilizar o template que está associado após o período de 12 horas (que é o padrão).

 

Solução:

 

Para desabilitar esse período de 12 horas que é o padrão, devemos alterar o cache que fica armazenado no banco de dados do AD RMS, para isso devemos seguir o seguinte procedimento:

1- Devemos ter instalado o RMSToolkit (http://www.microsoft.com/download/en/details.aspx?id=1479)

2- Abra o RMSToolki e conecte para a base de dados do SQL usando o RMSConfigEditor.

3- Conecte para a base de dados DRMS_Config… e vá em DRMS_ClusterPolicies.

4- Procure o UseDirectoryServicesCacheDatabase e altere o valor para 0.

5- Após será necessário reiniciar os serviços do IIS.

 

Nota:

 

Existe outros procedimento de fazer essa alteração, segue o link de referencia:

http://blogs.technet.com/b/rmssupp/archive/2007/05/11/troubleshooting-your-rms-server-and-group-membership.aspx

Share

Post to Twitter

Utilizando a ferramenta Klist para deletar tickets Kerberos que estão em cache

Como já sabemos, o protocolo Kerberos é o principal protocolo de autenticação utilizado em domínios do AD, algumas vezes podemos encontrar problemas relacionados com os tickets Kerberos distribuídos na rede.

A Microsoft disponibiliza uma ferramenta de linha de comando chamada “Klist.exe” que faz parte do resource kit do Windows Server. Utilizamos essa ferramenta principalmente para deletar tickets Kerberos que estão em cache e suspeitamos de problemas com esse ticket.

Para utilizar essa ferramenta precisamos primeiro fazer o download do resource kit do Windows Server, e instalar no Servidor. Após ter instalado o resource kit, vá em iniciar > todos os programas > Windows Resources Kit Tools > selecione command shell, isso irá abrir o prompt de command.

Agora basta digitar > klist purge, ele irá mostrar quantos tickets estão em cache, para deletar digite “y” para cada ticket.

Use esse comando com cautela, pois após deletar um ticket a máquina pode não conseguir se autenticar para os recursos, se isso acontecer faça um logoff e logon.

[]´s

Diogo Molina

Share

Post to Twitter

Erro no Internet Explorer: Faulting module name: Flash10d.ocx

Esse é daqueles probleminhas que incomodam!

Ele trava o IE e está relacionado com o Flash Player, segue detalhes do event viewer para verificar se é realmente o mesmo caso:

Log Name:      Application
Source:        Application Error
Date:          19/02/2010 22:41:33
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      HAL9000
Description:
Faulting application name: iexplore.exe, version: 8.0.7600.16385, time stamp: 0x4a5bc69e
Faulting module name: Flash10d.ocx, version: 10.0.42.34, time stamp: 0x4ae7baed
Exception code: 0xc0000005
Fault offset: 0x00157ec4
Faulting process id: 0xd70
Faulting application start time: 0x01cab1c51dc60807
Faulting application path: C:\Program Files (x86)\Internet Explorer\iexplore.exe
Faulting module path: C:\Windows\SysWow64\Macromed\Flash\Flash10d.ocx
Report Id: b0f87a03-1db8-11df-a42f-00235aab5b70

Resolvido aqui instalando atualização para o player no site oficial Adobe.

http://get.adobe.com/br/flashplayer/

No meu caso a versão do Adobe Flash Player 10.0.45.2.

Enfim as travadas no IE pararam. E NÃO era problema no IE como as pessoas gostam de pensar num primeiro momento. rs ;)

[]s
Tiago Ferreira de Souza

Share

Post to Twitter

É possível Servidores Dell ligarem sozinhos após uma queda de energia?

Achei interessante divulgar uma thread do fórum da DELL. Já passei por isso e é bem útil.

FONTE: http://pt.community.dell.com/servidores_e_storage/f/38/t/26756.aspx

A pergunta no fórum era a seguinte:

“Com o apagão de ontem surgiu uma dúvida, existe maneira dos servidores da Dell subirem sozinhos após uma queda de energia ou só apertando o botão de power mesmo ?”

A resposta da DELL:

“Postado por DELL-Fabiano I em Tue, Feb 2 2010 3:47 AM
Verificada por DELL-Fabiano I martinez,

existe sim, basta ativar na bios a opção “AC Power Recovery” para “Last”. É interessante verificar a necessidade desta configuração, uma vez que se o sistema tiver inúmeras quedas de energia o seu server irá iniciar repetidamente e poderá comprometer o seu equipamento ou sistema.”

[]s
Tiago Ferreira de Souza

Share

Post to Twitter

Error message when you try to remove an orphaned mailbox after a failed move operation in Exchange 2003

Um cenário que pode ocorrer na transição do Exchange 2003 para o 2007 é que ao executar o move mailbox a conta é movida, mas no console do exchange 2003 continua aparecendo, mas como desconectada. Essas contas que não foram movidas totalmente são chamadas de “oprhaned mailbox” (contas orfãs).

Se você executar um purge no exchange system manager você obetrá a seguinte mensagem:

—————————
Exchange System Manager
—————————
The operation cannot be performed because this mailbox was already reconnected to an existing user.

ID no: c1034ad6
Exchange System Manager
—————————
OK
—————————

Para resolver isso, consulte o KB:

http://support.microsoft.com/kb/930363

Existem 2 métodos para se livrar dessas contas, eu achei o primeiro mais prático, segue abaixo:

Method 1: Remove the orphaned mailbox by using Exchange maintenance

1. Start Exchange System Manager.
2. Locate and then click the mailbox store that you want. For example, to locate the Mailbox Store (My_Server) store, follow these steps:

a. Expand Administrative Groups, expand First Administrative Group, expand Servers, and then expand My_Server.
b. Expand First Storage Group, and then click Mailbox Store (My_Server).

3. On the Action menu, click Properties, and then click the Limits tab.
4. Under Deletion settings, type a number that is less than the age of the orphaned mailbox in the Keep deleted mailboxes for (days) box. For a mailbox that is newly orphaned, type 0 (zero).
5. Configure the maintenance schedule. To do this, follow these steps:

a. Click the Database tab.
b. In the Maintenance interval box, click Use custom schedule, and then click Customize.
c. In the list of days, click the current day so that the row for that day is highlighted. This schedules the maintenance for all day.

Note The scheduling of maintenance for all day can be set or removed. To do this, click a day in the list of days.

6. Click OK.
7. Exit Exchange System Manager.
8. Allow for online maintenance to finish. This may take several hours. You will see event ID 1221 logged in the Application log when online maintenance is finished.
9. In Exchange System Manager, use the Run Cleanup Agent on the Mailboxes folder that contains the orphaned mailbox.

[]s
Tiago Ferreira de Souza

Share

Post to Twitter

Utilizando a ferramenta Kerbtray para verificar os tickets Kerberos

O protocolo Kerberos é utilizado para fazer autenticação de clientes e Servidores ou de Servidores para Servidores. O AD utiliza por padrão o protocolo Kerberos para fazer a autenticação, segue link que explica como o Kerberos trabalha:

http://technet.microsoft.com/pt-br/library/cc780469(WS.10).aspx

As vezes temos alguns problemas relacionados com os tickets Kerberos, para identificarmos os problemas do protocolo Kerberos a Microsoft disponibiliza algumas ferramentas para ajudar na identificação e resolução do problema.

Nesse artigo vou falar da ferramenta “Kerbtray”, utilizamos ela para verificar algumas informações sobre o tickets Kerberos, como por exemplo, quando o ticket irá expirar.

Antes de utilizar essa ferramenta, precisamos instalar o “resource kit do Windows Server”, para isso vá no site de downloads da Microsoft e faça o download e instalação do resource kit.

Após a instalação, vá no diretório de instalação do resource kit que por padrão esta localizado em > c:\Program Files\Windows Resource Kit\Tools, procure pelo arquivo “kerbtray.exe” clique duas vezes sobre o arquivo, isso irá abrir o kerberos tickets. Nessa janela temos informações sobre o ticket kerberos como o dia em que o ticket foi concedido, quando irá expirar, período de renovação, tipos de criptografia utilizados, etc.

Essa ferramenta é útil quando estamos suspeitando de erro com a distribuição de tickets kerberos, como por exemplo, se por algum motivo o ticket não está sendo renovado.`

Se ao abrir a janela do ticket kerberos a opção de “Client Principal” estiver com a frase “No Network Credentials”, provavelmente está com problema no protocolo Kerberos, verifique se o serviço do kerberos está iniciado.

Irei postar mais artigos com outras ferramentas que podemos utilizar para fazer o troubleshooting do protocolo Kerberos.

[]´s

Diogo Molina

Share

Post to Twitter