Arquivos do Blog
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:
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:
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:
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
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:
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”
2 – Executar o comando: ServiceModelReg –r
Caso peça alguma confirmação após o comando basta digitar “Y” e em seguida dar Enter
3 – Executar o comando: IISReset
4- Executar o comando: ServiceModelReg –i
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
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.
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:
10 – Clicar em “Browse” e selecionar o diretório virtual do Autodiscover e clicar em “Next”:
11 – Na página “Log Location” clicar em “Next”:
12 – Clicar em “Reset”:
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:
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
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:
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:
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”.
3 – Abrir o “DirSync Config Shell” e executar o comando “Start-OnlineCoexistenceSync”:
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
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:
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”:
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)”:
3 – Vamos clicar em “New” e em seguida em “SMTP Address”:
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”:
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:
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”:
6 – Pronto! Agora todos os seus usuários estão prontos e atendem todos os requisitos para a migração Híbrida.
Diogo Heringer
Projeto Office365: Erro ao configurar o Hybrid Configuration
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:
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:
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)
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.
Até a próxima,
Diogo Heringer
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.
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”.
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.
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:
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:
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á:
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”:
8 – Com as permissões verificadas vamos adicionar as replicas. No painel a direita vamos clicar na aba “Replicas” e em seguida em “Add”:
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.
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.
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:
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
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 ’0×80070005′.
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”:
2 – Expandir Configuration > CN=Configuration,DC=domain,DC=com > Services > Microsoft Exchange > OrganizationName > Administrative Groups > AdministrativeGroupName > Servers.
3 – Clicar com o botão direito no “Nome do Servidor”, em seguida em “Propriedades”:
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”:
5 – Agora basta reiniciar o servidor que o serviço “Microsoft Exchange System Attendant” irá iniciar normalmente.
Até a próxima,
Diogo Heringer
Projeto Office365: Lentidão Extrema na inicialização do Servidor Exchange 2010 SP2 / Serviços do Exchange “Starting”.
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.
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.
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
Erro: Instalar Exchange 2010 em um ambiente de Exchange 2003 para migração.
Bom pessoal,
Neste fim de semana fiz uma consultoria relativo a migração de Exchange Server 2003 para o Exchange Server 2010 RTM, que parecia no começo ser tranquilo. Após ter encontrado alguns problemas depois que a instalação do SP2 do Exchange Server foi executada no ambiente, resolvi remover o SP2 (Que na verdade só pode ser removido com a desinstalação total do Exchange Server) e subir novamente um servidor.
Ao tentar executar a instalação do Exchange Server novamente ele não conseguia instalar, nem através do SP2, já que o Schema estava expandido para o Exchange Server SP2.
Na instalação apresentava o seguinte erro:
“The following error was generated when “$error.Clear(); if ($server -eq $null) { new-exchangeserver -DomainController $RoleDomainController -Name $RoleNetBIOSName }” was run: “Couldn’t find the parent object for xxxx-EXCHANGE on domain controller xxxx-my.domain.com.au. Check that Servers exists and that the domain controller belongs to domain my.domain.com.au.”.
Couldn’t find the parent object for xxxx-EXCHANGE on domain controller my.domain.com.au. Check that Servers exists and that the domain controller belongs to domain my.domain.com.au.
Juntamente com o Analista de Infraestrutura da empresa fizemos diversos troubleshoots, porém não conseguimos sucesso no erro citado acima.
Após diversas pesquisas na internet e com ajuda no fórum do MSExchange conseguimos encontrar a solução que é a seguinte:
1. Instale as ferramentas administrativas do AD se ainda não tiver sido instalada:
Add-WindowsFeature Rsat-ADDS (se for Win 2008 R2).
Reiniciar o servidor.
2 – A partir do Pacote de Instalação do SP2 do Exchange Server:
Navegue através do Prompt de Comando (CMD) até a pasta do SP2 e siga os passos:
- Execute novamente o setup.com /PrepareLegacyExchangePermissions
- Execute novamente o setup.com /p ou /preparead
- Aguarde para ver se conclui com sucesso.
- Concluido com sucesso, aguarde a replicação do AD (em torno de 15 minutos), ou force a replicação do AD:
Forçar Replicação Entre DCS: repadmin /replicate dest-dc01 source-dc01 DC=contoso,DC=com
Replicar para todos os DCS: repadmin /syncall dst-dc01 dc=contoso,dc=com /d /e /a
/d: Identifies servers by distinguished name in messages.
/e: Synchronizes domain controllers across all sites in the enterprise. By default, this command does not synchronize domain controllers in other sites.
/a: Aborts, if any server is unavailable.
Todos os Parâmetros: http://technet.microsoft.com/pt-br/library/cc835086(WS.10).aspx
Espero ter ajudado quem está com este mesmo problema.
Abraço a todos,
Diogo Heringer
