Arquivos do Blog

DirSync: Como forçar a troca do UPN do usuário quando ele não é alterado pelo DirSync

 

 

 

Olá pessoal,

Uma atividade comum de administração de um ambiente de Office 365 com DirSync, é a alteração dos endereços UPNS.

A alteração deste valor deve ser replicada (bem como outros atributos) no intervalo de tempo estabelecido pelo arquivo de configuração do DirSync.

Algumas vezes podemos nos deparar com o problema em que o UPN sofre alterações e as mesmas não são replicadas para o Office 365. Neste caso, como solução de urgência, é recomendado que faça a alteração do UPN de forma manual através do PowerShell.

Para fazer esta alteração basta executar os passos abaixo:

 

1 – Conectar no Tenant do Office 365:

$livecred = Get-Credential

Connect-MsolService -Credential $livecred

$Session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUrihttps://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

 

2 – Executar o seguinte comando:

Set-MsolUserPrincipalName -UserPrincipalName <UPN Atual>  -NewUserPrincipalName <Novo UPN>

 

3 – Pronto! Agora basta conferir no portal do Office 365 e validar se o UPN está correto!

 

Créditos ao Flávio Filho que ajudou com esta solução!

 

Até a próxima,

Diogo Heringer

clip_image001

Hybrid Configuration: Error “Unable to perform the save operation. is not within a valid server write scope”

 

 

 

 

Olá pessoal,

Quando executamos o Move-Mailbox em um ambiente Híbrido temos as opções de fazer a migração de:

  • Mailbox Principal
  • Mailbox de Archive
  • Mailbox Principal + Archive

 

Quando migramos apenas a Mailbox principal, afim de criar um novo Archive vazio para o usuário migrado, podemos encontrar alguns problemas, pois o Exchange Online reconhece que ainda existe uma Mailbox de Archive a ser migrada e impossibilita a criação de uma nova Mailbox de Archive para o usuário.

 

Ao tentar habilitar o novo Archive, recebemos o seguinte erro:

 

image

 

Para resolver este problema basta seguir os procedimentos abaixo:

 

1- Abrir o ADSIEdit.msc e em seguida navegar até o usuário desejado.

 

2 – Clicar em “Propriedades” e em seguida alterar o atributo msExchRemoteRecipientType. Notem que o valor atual é “4”.

Alterar o valor para “3”.

 

image

 

3 – Com o atributo alterado, no Shell do DirSync vamos sincronizar o objeto através do comando:

Start-OnlineCoexistenceSync

 

4 – Pronto? Sim, mas como saber quais usuários estão com o atributo msExchRemoteRecipientType = 4 ?

 

É simples, basta conectar no Tenant do Office 365 e executar os comandos abaixo:

 

Conectar no Tenant:

$livecred = Get-Credential

Connect-MsolService -Credential $livecred

$Session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

 

Listar usuários com problema:

Get-Mailbox -ResultSize Unlimited -Filter {(RecipientTypeDetails -eq “UserMailbox”) -and (RemoteRecipientType -eq “Migrated”)}

 

Agora basta seguirmos o procedimento acima para cada usuário listado.

 

Até a próxima,

Diogo Heringer

clip_image001

Hybrid Configuration: Prompt para credenciais repetidamente “Autodiscover-S.Outlook.com” na visualização de Free/Busy.

Olá pessoal,

Recentemente participando de um projeto de Hybrid Configuration me deparei com um problema que demorei bastante tempo para resolução do mesmo e também achei poucas informações relevantes na Internet a respeito.

O ambiente consistia no seguinte cenário:

  • 2 ADFS Proxy
  • 2 ADFS Server
  • 1 Exchange Server 2010 (Mailbox Server)
  • 1 Exchange Server 2010 (CAS/HUB)
  • 3 Servidores Exchange Server 2003 (BackEnd)
  • 1 Servidor Exchange Server 2003 (Front-End)

O problema basicamente era que o usuário ao tentar abrir o calendário do usuário que havia sido migrado para o Office 365 apresentava repetidamente a tela de Prompt abaixo:

 

image

 

Para o troubleshoot foi feito vários testes de visualização de Free/Busy em todos os sentidos (Nuvem > Local, Local > Nuvem). Abaixo os resultados que obtive nos testes de Free/Busy:

 

image

 

Vamos a resolução do problema:

O prompt de Autodiscover-S aparece repetidamente pois o usuário que está tentando “ABRIR”o calendário compartilhado não consegue se autenticar. Para que ele visualize o calendário corretamente, tanto o UPN do Usuário que foi migrado para a o Office 365, tanto o UPN do usuário do Exchange On-Premise devem estar configurados corretamente com UPNS válidos.

Com este conceito vamos a correção:

1 – No Active Directory Users and Computers efetuar a troca do UPN do usuário:

 

image

 

2 – Acessar o servidor de DirSync e no “DirSyncConfigShell.ps1” executar o seguinte comando:

Start-OnlineCoexistenceSync

 

Ok! Agora nosso usuário irá se autenticar de forma correta e o Prompt de Autodiscover-S não irá mais acontecer, porém podemos esbarrar na possibilidade do USUÁRIO SE AUTENTICAR E NÃO VISUALIZAR OS COMPROMISSOS.

Para corrigir este problema basta fazer a DESATIVAÇÃO DO CACHE DO ADFS SERVER utilizando o seguinte KB:

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

 

Com o KB executado recomendo a reinicialização do servidor ADFS Server e testar o funcionamento perfeito do problema de Free/Busy!

Até a próxima,

Diogo Heringer

clip_image001

Projeto Office365: Outlook exige senha repetidamente após migração do Mailbox para o Office 365 (Hybrid)

 

 

Olá pessoal,

O troubleshoot apresentado pode ser utilizado para a resolução de dois problemas:

 

Item 1: Outlook exige senha repetidamente após migração do Mailbox para o Office 365

Item 2:  Após instalar o Update Rollup 3 for Exchange 2010 SP2 e executar o Update-HybridConfiguration temos o seguinte erro:

ERROR:Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships.

Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.

Federation information could not be received from the external organization.
at Microsoft.Exchange.Management.Hybrid.RemotePowershellSession.RunCommand(String cmdlet, Dictionary`2 parameters, Boolean ignoreNotFoundErrors)

 

Vamos aos Procedimentos de Correção do Item 1:

1 – Instalar o Update Rollup 3 for Exchange Server 2010 SP2

2 – Executar novamente o Hybrid Configuration Wizard:

 

image

 

3 – Ao executar novamente o Hybrid Configuration, caso você tenha o problema citado no Item 2 ir para “Procedimentos de Correção do Item 2”, senão prossiga.

4 – Com o Update Rollup 3 instalado e o Hybrid Configuration atualizado verificar se o problema do Outlook pedir senha repetidamente ainda persiste para usuários que já foram migrados. Os usuários que forem migrados depois da instalação não apresentarão problemas. Para corrigir o erro dos usuários já migrados executar o procedimento:

  • Logar com o usuário que apresenta o problema na sua respectiva estação
  • Navegar até:  [HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider]
  • Excluir a chave de registro: “Closest GC”=dword:00000001
  • Remover o perfil MAPI do usuário no Outlook
  • Navegar até: C:\Users\<username>\AppData\Roaming\Microsoft e renomear a pasta Outlook
  • Iniciar o Outlook e recriar o perfil de Outlook do usuário

    5 – Pronto! O perfil será configurado com sucesso e o Outlook não irá mais pedir senha repetidamente.

     

     

    Agora os Procedimentos de Correção do Item 2:

    1 – No Prompt de Comando navegar até a pasta: “C:\windows\Microsoft.Net\Framework64\v3.0\Windows Communication Foundation”

     

    image

     

    2 – Executar o comando: ServiceModelReg –r

    Caso peça alguma confirmação após o comando basta digitar “Y” e em seguida dar Enter

     

    image

     

    3 – Executar o comando: IISReset

     

    4-   Executar o comando: ServiceModelReg –i

     

    image

 

5 – Executar o comando: IISReset

 

6 – No Exchange Management Shell (EMS) executar o seguinte comando:

Set-AutodiscoverVirtualDirectory -identity “SERVER\Autodiscover (Default Web Site)”

-WSSecurityAuthentication $true

 

image

 

7 – Testar novamente a execução do Hybrid Configuration, caso apresente o mesmo erro avance para o número 8, senão o seu Hybrid Configuration está concluído com sucesso e atualizado!

 

8 – Abrir o Exchange Management Console (EMC) e navegar até “Server Configuration > Client Access.

 

image

 

9 – Clicar com o botão direito em cima do Servidor de Client Access e em seguida em “Reset Virtual Directory” onde iremos ver a seguinte tela:

 

image

 

10 – Clicar em “Browse” e selecionar o diretório virtual do Autodiscover e clicar em “Next”:

 

image

 

11 – Na página “Log Location” clicar em “Next”:

 

image

 

12 – Clicar em “Reset”:

 

image

 

13 – No Prompt de Comandos executar o comando: IISReset

 

14 – No Prompt de Comando navegar até a pasta: “C:\windows\Microsoft.Net\Framework64\v3.0\Windows Communication Foundation”

 

15 – Executar o comando: ServiceModelReg –r

 

16 – No Prompt de Comandos executar o comando: IISReset

 

17 – Executar novamente o Hybrid Configuration Wizard:

 

image

 

Pronto! Agora o seu Hybrid Configuratio está configurado e atualizado com o Update Rollup 3 do Exchange Server 2010 SP2!

 

Até a próxima,

Diogo Heringer

clip_image001

Troubleshoot: DirSync não sincroniza usuários adicionados em um Grupo de Segurança/Distribuição

 

 

 

Após a transição de BPOS para Office 365 é comum que aconteça um erro referente ao “Proprietário” dos “Grupos de Distribuição”. Ao tentar adicionar um “Proprietário” no Grupo de Distribuição/Segurança que foi sincronizado pelo DirSync temos a seguinte mensagem:

 

image

 

Ok, como o usuário é sincronizado com o DirSync devemos alterá-lo no Active Directory, e não diretamente na Console do Exchange Control Panel. O problema está justamente neste momento:

Ao fazer alterações no grupo do meu Active Directory, como inclusão de usuário e remoção de usuário, o DirSync ao sincronizar não atualiza os respectivos grupos no Exchange Control Panel.

Este problema ocorre pois o atributo “DisplayName” dos grupos não estão preenchidos.

 

Para resolver este problema vamos seguir os seguintes passos:

 

1 – Abrir o AdsiEdit.msc e popular o campo “DisplayName” dos grupos:

 

image

 

2 – Alterar o valor da chave de registro:

“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\FullSyncNeeded” de “0” para “1” para fazer com que o próximo sincronismo do DirSync seja um “FullSync”.

 

image

 

image

 

3 – Abrir o “DirSync Config Shell” e executar o comando “Start-OnlineCoexistenceSync”:

 

image

 

4 – Com a sincronização concluída todos os membros adicionados no ambiente On-Premise serão sincronizados no Exchange Online!

 

Até a próxima,

Diogo Heringer

clip_image001

Projeto Office365: Warning referente a “SMTP Address” no Hybrid Configuration

 

 

Conforme citado anteriormente, neste post iremos aprender como corrigir um Warning durante a configuração do nosso Ambiente Híbrido. Segue o Warning apresentado:

 

Problema Resolvido

 

Para corrigirmos este Warning teremos que alterar a “Recipient Policies” no Exchange Server 2003. Segue o passo a passo:

 

1 – Abrir o “Exchange System Manager”, expandir “Recipients” e em seguida “Recipient Policies”:

 

image

 

2 – Clicar com o botão direito na Policie utilizada pela sua organização e em seguida clicar em “Properties”.

Na janela que se abrirá vamos navegar até a guia “E-Mail Addresses (Policy)”:

 

image

 

3 – Vamos clicar em “New” e em seguida em “SMTP Address”:

 

image

 

4 – Vamos preencher o campo “Address” com o endereço do nome de domínio que foi criado pelo Exchange Server 2010 ao criarmos o “Hybrid Configuration”:

 

image

 

O “Hybrid Configuration” irá criar um “Accepted Domain” no padrão “seudominio.mail.onmicrosoft.com”. Vamos utilizá-lo como endereço secundário para todos os usuários da organização:

 

image

 

5 – Agora basta clicar em “Ok” até fechar todas as janelas, e em seguida clicar com o botão direito na política alterada e clicar em “Aplly this policy now”:

 

image

 

6 – Pronto! Agora todos os seus usuários estão prontos e atendem todos os requisitos para a migração Híbrida.

 

Diogo Heringer

clip_image001

Projeto Office365: Erro ao configurar o Hybrid Configuration

 

image

 

 

Ao preencher todas as configurações necessárias para o “Hybrid-Configuration” no servidor Exchange 2010, recebi o seguinte erro ao executar a configuração:

 

 

Update-HybridConfiguration:

Failed

Error:

Updating hybrid configuration failed with error ‘Subtask ValidateConfiguration execution failed: Configure Legacy Exchange Support

   at Microsoft.Exchange.Management.Hybrid.Engine.ExecuteTask(TaskBase taskBase, TaskContext taskContext)

Additional troubleshooting information is available in the Update-HybridConfiguration log file located at C:\Program Files\Microsoft\Exchange Server\V14\Logging\Update-HybridConfiguration\HybridConfiguration_4_17_2012_16_16.log

 

Lembrando que o erro está relacionado também ao Exchange Server 2003 que possuímos na rede, portanto devemos corrigir os Erros de Replicação de Public Folders, pois ela serão utlizadas pelo Exchange 2010 para fornecer informações de Free/Busy para os usuários do Exchange Online.

 

Segue os passos para a correção do problema:

 

1 – No servidor Exchange Server 2010, abrir o Exchange Management Shell (EMS) e digitar o seguinte comando:

 

image

Copy: Set-EventLogLevel –Identity “MSExchange ADAccess\Validation” –Level Expert

 

2 – Ao realizar o “Hybrid-Configuration” novamente, vamos verificar o “Event Viewer” que nos apresentará o seguinte erro:

 

Event

 

3 – Para corrigir vamos criar um usuário com permissões de “Organization Management” no Exchange Server 2010, criar também uma Mailbox para este usuário e em seguida executar o “Hybrid Configuration” novamente:

                               (Usuário c/ Mailbox e no Grupo “Organization Management)

image

 

4 – O “Hybrid Configuration” foi concluído com sucesso, apenas com um Warning relacionado a “SMTP Address” que veremos como corrigir no próximo post.

 

Problema Resolvido

 

Até a próxima,

Diogo Heringer

clip_image001

Projeto Office365: Erro de replicação de Public Folder (OAB) entre Exchange 2003 e Exchange 2010

 

 

Após redefinirmos as pastas públicas de sistema é necessário verificar se a replicação está ocorrendo corretamente entre os servidores Exchange 2003 e Exchange 2010. Para fazermos a verificação desta replicação vamos seguir os seguintes passos:

 

1 – No servidor Exchange Server 2003 vamos fazer o download do aplicativo PFDAVAdmin, que irá fazer a gerencia de replicação das Publics Folders no Exchange 2003.

Download PFDAVAdmin

 

2 – Executar o PFDAVAdmin, navegar até a aba “File” e em seguida clicar em “Connect” onde iremos inserir as seguintes informações:

  • Nome do servidor Exchange Server 2003
  • Nome do servidor Catálogo Global
  • Usuário com credenciais autorizadas a realizar esta operação (Domain Admins)

Clicar em “Ok”.

 

image

 

3 –  Expandir “System Folders” > “Offline Address Book” > “/o=Nome Organização/cn=addrlists/cn=oabs/cn=Offline Address List”.

Veremos que temos três tipos de versões de OAB. Vou demonstrar a configuração de replicação em uma das versões do OAB, que é válido  para a replicação de qualquer pasta pública.

 

image

 

4 – Clicar com o botão direito do mouse em “OAB Version 2” e em seguida clicar em “Check DACL State”. Aparecerá a seguinte mensagem:

image

 

Vamos clicar em “Yes”.

 

5 – Como resultado do “Check DACL State” teremos uma janela onde irá mostrar o status das permissões da pasta pública:

 

image

6 – Caso o resultado gerado pelo “Check DACL State” não seja “Good”, basta clicar com o botão direito na public folder desejada e em seguinda clicar em “Fix Folders DACLS”. A seguinte tela se abrirá:

 

image

 

Basta clicar em “Execute” que as permissões serão automaticamente corrigidas.

 

7 – Após o passo 6, vamos verificar se o “State DACL” está como “Good”.

Para isso vamos clicar com o botão direito na public folder “OAB Version 2” e em seguida em “Folders Permissions”:

 

image

 

8 – Com as permissões verificadas vamos adicionar as replicas. No painel a direita vamos clicar na aba “Replicas” e em seguida em “Add”:

 

image

 

Escolher a Database correspondente ao Exchange 2010 e clicar em “Ok”.

 

Lembrando que quando instalamos o Exchange 2010 em um ambiente Exchange 2003 automaticamente é criado uma “Public Folder Database 1231233213” no Exchange 2010.

 

9 – Clicar em “Commit Changes” para confirmar a alteração.

 

image

 

Pronto? Ainda não! Agora temos que configurar o nosso Exchange Server 2010 para replicação com o Exchange Server 2003, vamos lá:

 

10 – No servidor Exchange Server 2010 vamos fazer o download do aplicativo EXFolders, que irá fazer a gerencia de replicação das Publics Folders no Exchange 2010.

 Download EXFolders

 

11 – Para instalação basta seguirmos o arquivo do bloco de notas “Readme” que é baixado juntamente com o executável do EXFolders:

 

1. INSTALLATION:

– ExFolders must be run from an Exchange Server 2010 machine with the Microsoft Exchange Active Directory Topology service, which means it will not currently run on a tools-only install. This might change in the future.
– ExFolders.exe must be placed in the server’s Exchange \bin folder. If you try to run it from anywhere else, it will simply crash.
– This build is not signed. In order to allow it to run, you can import the included .reg file on the server where you want to run the tool or run “sn -Vr ExFolders.exe” (using the 64 bit version of the SN tool) to allow it to launch. If you don’t, it will crash. To read more about the SN tool, please go here: http://msdn.microsoft.com/en-us/library/k5b5tt23.aspx

 

2. VARIOUS TOOL NOTES:

– ExFolders can connect to stores on Exchange 2010 or 2007 only, both mailbox and public stores. Connection to Exchange 2003 and earlier is not possible (use PFDAVAdmin for that)
– ExFolders can now connect to more than one mailbox store at a time; just ctrl-click or shift-click to select multiple stores. This allows you to operate against multiple servers or every single mailbox in the org all at once if you need to do so.
– You’ll notice the Tools menu now gives you the option to Export Item Properties, which allows you to export item properties to a tab-delimited file (just like the Export Folder Properties option). Item property imports are not implemented.
– Folder property imports are implemented. Tools -> Import, just like any other import. Note that the default property list in Export Folder Properties contains a lot of properties that are not writable, so if you turn around and try to import that same file, you will see a lot of errors. Any properties that are not writable (other than the Folder Path) should be removed from the file before importing.
– The old Property Editor has been changed to Bulk Property Editor, and a new Property Editor has been added, which is better-suited to editing properties on a single folder or item. Also note you can File -> Save to save the window contents to a file.
– The permissions interface, including the Folder Permissions GUI and exports/imports, supports the special Free/Busy rights on Calendar folders. Exports/Imports have two new keywords, FreeBusyDetails and FreeBusyBasic.
– The format of mailbox folder paths in imports/exports has changed, so mailbox exports from PFDAVAdmin cannot be imported with ExFolders, and vice-versa.
– Set Calendar Permissions will throw an error and not make any changes to a mailbox if it doesn’t find the FreeBusy Data folder in the mailbox root, which means the user has never logged on to the mailbox. This is by design (because if we set rights on the Calendar folder and the FreeBusy Data folder later gets created, the permissions won’t match).
– When you connect to mailboxes, some folders will appear in blue. These are search folders. They are ignored when you run Content Report.
– Set Calendar Permissions and Item Property Export are not currently exposed through Custom Bulk Operation.

 

12 – O procedimento que deverá ser feito no “EXFolders” é exatamente igual ao procedimento citado acima no “PFDAVAdmin”.

A única diferença entre as duas ferramentas é que utilizando o “ExFolders”, caso você deseje resetar as permissões dos usuários para que elas fiquem no estado “Good” (Este estado não é visualizado no “EXFolders”), basta clicar com o botão direito em cima da Public Folder desejada e em seguida em “Clear Permissions”.

Para forçar que uma subpasta herde as permissões da pasta pai, basta clicar com o botão direito na Public Folder e em seguida em “Propagate Folders ACEs

 

13 – Agora basta conferir os Logs no Event Viewer para verificar a replicação. Para isto, precisamos aumentar a sensibilidade do LOG no Exchange Server 2010 utilizando o comando:

Set-EventLogLevel

 

image

 

Com a replicação de Public Folders configurada podemos fazer a nossa configuração Híbrida do Exchange Server 2010 On-Premise com o Exchange Online.

 

Até a próxima,

Diogo Heringer

clip_image001

Projeto Office365: Erro ao iniciar o serviço “System Attendant”. EventID: 9149 e 1005

 

 

 

Após um procedimento efetuado no servidor Exchange Server 2003 para corrigir alguns erros referentes a Public Folder, foi necessário reiniciar o servidor Exchange Server. Ao reiniciar o servidor percebi que ele não estava funcional. Após análise dos serviços percebi que o serviço “Microsoft Exchange System Attendant” não conseguia iniciar, e consequentemente o “Microsoft Exchange Information Store” também não.

Com a verificação dos LOGS no Event Viewer pude perceber os seguintes erros:

 

__________________________________________________________________________________________

Event Type: Error
Event Source: MSExchangeSA
Event Category: General
Event ID: 9149
Description:
Microsoft Exchange System Attendant failed to start Exchange server ‘<SERVERNAME>’. Error code ‘0x80070005’.
For more information, click http://search.support.microsoft.com/search/?adv=1.

__________________________________________________________________________________________

Event Type: Error
Event Source: MSExchangeSA
Event Category: General
Event ID: 1005
Description:
Unexpected error Access denied. Facility: LDAP Provider ID no: 80070005 Microsoft Exchange System Attendant occurred.

__________________________________________________________________________________________

 

Através destes erros fiz o seguinte troubleshoot:

 

1 – Abrir o “adsiedit.msc”:

 

image

 

2 – Expandir Configuration > CN=Configuration,DC=domain,DC=com > Services > Microsoft Exchange > OrganizationName > Administrative Groups > AdministrativeGroupName > Servers.

 

image

 

3 – Clicar com o botão direito no “Nome do Servidor”, em seguida em “Propriedades”:

 

image

 

4 – Na guia “Security” adicionar o nome do servidor que apresenta erro e dar a permissão de “Full Control” para o servidor. Neste caso o Servidor Exchange que apresentava problema é o “Resplendor”:

 

image

 

5 – Agora basta reiniciar o servidor que o serviço “Microsoft Exchange System Attendant” irá iniciar normalmente.

 

Até a próxima,

Diogo Heringer

clip_image001

Projeto Office365: Lentidão Extrema na inicialização do Servidor Exchange 2010 SP2 / Serviços do Exchange “Starting”.

 

Print

 

Depois de uma semana parado no projeto devido a problemas pessoais, volto a postar a solução de um problema que tive durante o processo de preparação do Exchange Server 2010 para fazer a migração para o Exchange Online.

Para coexistência rica é necessário a instalação do Exchange Server 2010 SP1, no mínimo. Conforme dito anteriormente fiz a instalação do SP2, pois facilita a migração para nuvem.

Ao reiniciar meu servidor ele demorava cerca de 2 horas para inicilização e ficava na seguinte tela:

Applying Computer Settings

 

Quando consegui logar no servidor percebi que muitos dos serviços do Microsoft Exchange estava com o Status de “Starting”. Este problema ocorre devido a conexão do servidor Exchange Server 2010 com o Active Directory. O meu servidor Exchange Server não fazia parte dos grupos necessários para fazer a conexão com o Active Directory, não sei o motivo o qual ele não entrou nos grupos corretos durante a instalação. Para resolver este problema procedi da seguinte forma:

 

1 – Localizar o objeto de computador referente ao Exchange Server no Active Directory.

 

image

 

2 – Abrir as propriedades do objeto e verificar se o servidor Exchange Server faz parte do grupo “Exchange Domain Servers”. Inseri o servidor no grupo “Domain Admins” também, apenas para garantir que o funcionamento correto e a permissão máxima para o Troubleshoot.

 

image

 

3 – Feito isto, baste reiniciar o servidor que ele irá iniciar normalmente e todos os serviços do Exchange Server também!

 

Até a próxima,

Diogo Heringer

clip_image001