Arquivo da categoria: Client Acess

Exchange 2010 Outlook Anywhere: Configurando Certificado Wildcard

 

ssl-cert

 

Olá pessoal,

Ao utilizar o Remote Connectivity Analyzer (www.testexchangeconnectivity.com) para testar o Outlook Anywhere para uma migração Cutover de Exchange Server, se o certificado do Exchange Server for Wildcard é normal que aconteça o seguinte erro:

 

d1_thumb

Este erro acontece porque o RCA (Remote Connectivity Analyzer) está tentando se conectar na URL do Outlook Anywhere (msstd:mail.empresa.com.br), porém o CN do Certificado é “*.empresa.com.br”.

Para resolvermos este problema devemos definir que o OutlookProvider do Exchange Server para o endereço “*.empresa.com.br”.

Segue os passos da correção do problema:

 

1 – No EMS (Exchange Management Shell) executar o comando “Get-OutlookProvider”:

 

image

 

Notem que o CertPrincipalName está vazio ou nulo.

 

2 – Executar o comando abaixo para definir o CertPrincipalName do Outlook Anywhere:

 Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.domain.com.br

 

image

 

3 – Pronto, agora o Outlok Anywhere funcionará normalmente com certificado Wildcard. Interessante verificar novamente através do RCA (Remote Connectivity Analyzer).

 

Até a próxima,

Diogo Heringer

clip_image001

Hybrid Configuration: Publicando Autodiscover e EWS para o Ambiente Híbrido

 

Olá pessoal,

Hoje achei um artigo muito interessante sobre a publicação das URLS que são utilizadas pelo Hybrid Configuration no TMG. Este artigo foi feito por especialistas do Community Office 365, vale a pena conferir e validar o seu ambiente na preparação para o Hybrid Configuration.

 

Segue os passos:

 

Create the new Rule for use with the Hybrid components

  1. From Within TMG Management Console, right click on the FireWall Policy from the left tree
  2. Then select New
  3. Then select Web Publishing Rule

 

4. From the Welcome to the New Web Publishing Rule Wizard window type in a name for the rule and select next

 

 

5. On the select Rule Action screen select the Allow radio button then select next.

 

6. On the Publishing Type page select the appropriate option and then select next (in my case I have select the Publish a single Web site or load balancer option)

 

7. On the Server Connection Security page select the Use SSL option then select next

 

 

8. On the Internal Publishing Details page fill in the proper site name and IP address such as the example depicted below. If you are not sure what to put just take a look at your current Exchange publishing rule, once completed select the next option.

 

 

9. From the Internal Publishing Details leave the defaults then select the next option. We will configure the paths later in the configuration

 

 

10. On the Public Name Details section be sure that the EWS external web site names(for example Mail.Contoso.com) is listed as depicted below then select the next option

 

 

11. Then from the Select Web Listener page select the listener used for the regular exchange rule from the drop down menu then select the next option

 

12. Then from the Authentication Delegation page select the No Delegation, but client may authenticate directly option then select next

 

 

13. Then from the Select User Sets page choose the All Users option then select next. Then select the finish option

 

Then we need to go to the properties of the newly created rule and modify the Paths and the public names within the rule.

  1. From the TMG management interface right click the newly created rule and select properties
  2. Then select the Public Names tab and add the autodiscover external URL (for example autodiscover.contoso.com) and apply that change

 

 

3. Then select the paths tab and add the paths listed below , be sure to also remove the default “/*” path, then apply those changes

    • /ews/mrsproxy.svc
    • /ews/exchange.asmx/wssecurity
    • /autodiscover/autodiscover.svc/wssecurity
    • /autodiscover/autodiscover.svc

 

4. The last step it to ensure that this new rule is higher in the list than the primary exchange rule. You can simply right click on the rule and select move up until it is above the primary exchange rule. Then apply the changes

 

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

Projeto Office365: Entendendo Mailbox Moves em Ambientes Cross-Premises (Office 365)

 
O ambiente on-cloud Office 365 da Microsoft roda em Exchange 2010, portanto quando efetuamos um move mailbox entre mailbox databases, o processo é executado pelo Microsoft Exchange Mailbox Replication Service (que será tratado como MRS).

O MRS é um serviço que é executado nos Exchange 2010 CAS servers e é o serviço que irá receber o move request do administrador e mover a mailbox de uma database para outra. O MRS suporta os mailbox moves sendo eles online ou offline, em um ambiente cross-premisse este move é considerado online.

Este é um exemplo de como um move request (simples) é executado:

image

  1. O administrador cria o move request utilizando o New-MoveRequest;
  2. O New-MoveRequest efetua as validações necessárias na mailbox que será movida;
  3. O New-MoveRequest cria uma mensagem de request que é inserida no DB do target server;
  4. Os seguintes atributos são adicionados na conta do usuário, para armazenar informações que serão utilizadas pelo move e que serão atualizadas durante o processo:
    • msExchMailboxMoveBatchName
    • msExchMailboxMoveFlags
    • msExchMailboxMoveRemoteHostName
    • msExchMailboxMoveSourceMDBLink
    • msExchMailboxMoveStatus
    • msExchMailboxMoveTargetMDBLink
  5. 1- O New-MoveRequest aciona o MRS informando que uma nova requisição de move está pronta para o processamento;
  6. 2- O MRS atualiza o atributo msExchMailboxMoveStatus do objeto no AD;
  7. 3- O MRS inicia o sincronismo de data;
  8. 4- Assim que o sincronismo é completo, o MRS irá efetuar o “lock” da account;
  9. 5- Após o lock, o MRS iniciará o delta, aonde será feito o sincronismo de mensagens novas ou de itens alterados;
  10. 6- O MRS irá então atualizar os atributos no AD para o mailbox enabled user (nova account criada):
  11. HomeMDB
  12. HomeMTA
  13. HomeServer
  14. MSExchangeVersion
  15. Proxy Address
  16. Target Address
  17. 7- O MRS remove a source mailbox do source DB e altera o move status do msExchMailboxMoveStatus e msExchMailboxMoveFlags para “Completed”;
  18. 8- Assim que este status for atualizado, a mailbox pode ser acessada;
  19. 9- No Exchange 2010, cada instância do MRS mantém um track dos move requests. Esta fila pode ser acessada utilizando o comando “Get-MoveRequestStatistics”, como é o exemplo abaixo:

Get-MoveRequestStatistics “Exchange Server” –MoveRequestQueue “User-Mailboxes”

MRSProxy

No Exchange 2007, quando administradores tinham que efetuar mailbox moves entre diferentes florestas (cross-forest environment), era necessário habilitar o acesso MAPI entre os servidores, configurar trusts e habilitar o full administrator access para os administradores em ambas as Exchange Organizations.

O MRSProxy trabalha em conjunto com o MRS para facilitar a comunicação requerida entre o source e target server em cada floresta de Exchange Server 2010. Cada CAS server posssui uma instância do MRS e uma instância do MRSProxy como uma parte da implementação do Exchange Web Services (EWS). A grande diferença é que o MRSProxy não vem habilitado por default no CAS server.

Portanto, para efetuar um move em um ambientes cross premise ou até em um cross forest, é necessário habilitar este serviço. Para habilitar este serviço, basta configurar o arquivo de configuração (web.config) para o CAS on-premise. Lembre-se de habilitar para ambos os CAS nodes se você possui um array configurado.

Habilitando o MRSProxy

1. No servidor on-premise, abra o arquivo de configuração com o seu notepad:

<Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config

2. Altere a configuração de IsEnabled de False para True:

<!– Mailbox Replication Proxy Server configuration –>
<MRSProxyConfiguration
IsEnabled=”False”
MaxMRSConnections=”100″
DataImportTimeout=”00:01:00″ />

3. Salve e feche o arquivo;

4. Reinicie o serviço do MRS e o IIS para que as alterações tenham efeito.

 

Lembrando que ao utilizar o “Hybrid Configuration” disponível no Exchange 2010 SP2, o MRSProxy é habilitado automaticamente.

 

Até a próxima,

Diogo Heringer

clip_image001

Configurando o Exchange Control Panel

17634368311060220210

Hoje após assistir a “Webcast: Office 365 dicas de certificação…” e pela utilização do ECP(Exchange Control Panel) no Office365, resolvi falar um pouco sobre o ECP. A Console do Exchange Online é bem parecida com o a do Exchange On-Premise, porém na console do Exchange Online possui algumas configurações específicas de coexistência do Exchange Online x Exchange On-Premise. Vamos aos conceitos:

O Exchange Control Panel é um aplicativo da Web que é executado em um servidor “Client Access” e fornece alguns serviços para administração do Exchange Server. O ECP (Exchange Control Panel) é instalado automaticamente quando você instala um servidor “Client Access”. Para gerenciar o Exchange a partir de qualquer lugar, você só precisa digitar a URL configurada no Exchange Server no seu navegador.

Por padrão, a URL Interna do ECP é https://yourserver.yourdomain.com/ecp. Temos também que configurar nossa URL Externa e publicá-la para Internet para que possamos ter acesso de qualquer lugar que não seja nossa organização.

O recurso ECP (Exchange Control Panel) está disponível no Exchange Server 2010 SP1 ou superior. Vou mostra como iremos configurar a URL do ECP, bem parecido com o processo de configuração do OWA:

1 – Para configurarmos o ECP devemos primeiramente navegar até a guia “Server Configuration”, em seguida “Client Access” e iremos ver a aba “Exchange Control Panel”:

image

2 – Vamos dar um click-duplo em cima de “Owa (Default Web Site)”, onde irá abrir uma nova janela. Nesta janela, na guia “General” iremos preencher o campo “External URL”. O campo “Internal URL” já estará preenchido por padrão:

image

3 – Com as URLS preenchidas basta clicar em “Ok”  e nossa configuração do ECP (Exchange Control Panel) no Exchange Server está pronto, ficando pendente apenas a publicação da URL “https://mail.dheringer.com/ecp”.

4 – Para fazer o teste de funcionamento do ECP, no “Exchange Server” vamos abrir o “Internet Explorer” e digitar: “https://localhost/ecp”. Abrirá uma tela de logon idêntica a tela de logon do OWA, onde iremos digitar um usuário administrativo e senha:

Loginpage

5 –  Ao efetuar o logon no ECP, vamos ter várias opções de gerenciamento como mostra a imagem abaixo:

image

Pronto, agora podemos fazer a gerencia do nosso Exchange Server através da WEB. Lembrando que o ECP é válido tanto para o Exchange Server On-Premise quanto para o Exchange Online, alterando apenas a URL de acesso.

Em breve irei mostrar como configurar a RBAC (Role Based Access Control) através do ECP (Exchange Control Panel) e também através dos Cmdlets.

Até a próxima!

Abraços,

Diogo Heringer

clip_image001

Configurando o Outlook Web App (OWA)

smtp

 

Uma das facilidades que o Exchange Server nos fornece é o acesso ao e-mail, calendário e tarefas via browser. Afunção do Exchange Server responsável por promover este acesso é o “Client Access”. A ferramenta que iremos utilizar para este acesso é o “Outlook Web App”. Através de sua configuração vamos definir uma URL para que os usuários possam acessar ter acesso ao Outlook Web App.

Para configurarmos o OWA devemos primeiramente navegar até a guia “Server Configuration”, em seguida “Client Access” e iremos ver a aba “Outlook Web App”:

 

image

 

Vamos dar um click-duplo em cima de “Owa (Default Web Site)”, onde irá abrir uma nova janela. Nesta janela, na guia “General” iremos preencher o campo “External URL”. O campo “Internal URL” já estará preenchido por padrão:

 

image

 

Configurado a URL podemos passar para a guia “Authentication”. Temos que marcar o Check Box “Use Forms-Based Authentication” e em seguida o Check Box “User Name Only”. Ao marcar o segundo checkbox vamos clicar em “Browse” onde abrirá uma janela com o nome do nosso domínio interno cadastrado, que iremos marca-lo e clicar em “OK”:

 

image

 

Ao clicar em “Ok” voltaremos para tela anterior onde iremos clicar em “Ok” novamente. Agora nosso OWA está configurado corretamente no Exchange Server.

 

image

 

Ao aplicar as alterações o Exchange Server irá nos dar um “Warning” pedindo para que o IIS seja reiniciado. Para isto vamos abrir o prompt de comandos e digitar o comando: IISRESET

 

image

 

Um detalhe importante é configurarmos o nosso diretório do IIS para fazer o redirecionamento de site. Este redirecionamento será utilizado para que quando o usuário acessar “mail.dheringer.com” no browser, ele será automaticamente redirecionado para “mail.dheringer.com/owa”.

Vamos no “Menu Iniciar” em seguida “Administrative Tools”, onde irá se expandir em várias ferramentas de gerenciamento. Vamos clicar em “IIS Manager”:

 

image

 

Na console do IIS vamos navegar até “Default Web Site”:

 

image

 

Agora no painel ao lado vamos dar um duplo-click em “HTTP Redirect”:

image

 

Na janela aberta vamos configurar o campo “Redirect requests to this destination” com o valor “/owa”, e vamos marcar o checkbox “Only redirect requests to content in this directory (not subdirectories).

 

Capturar

 

Finalmente nosso OWA está configurado corretamente. Lembrando apenas que a “Configuração do Serviço” Microsoft Exchange Forms Based Authentication deve estar configurado como “Automatic” e o serviço deve estar com o status “Started”.

image

Abraço a todos,

Diogo Heringer

clip_image001