Office 365 – Como funciona o Autodiscover no Hybrid Configuration

Durante uma configuração hibrida entre Exchange Server 2013 e Office 365, muitas vezes me deparo com a seguinte pergunta: “Julio, como funciona o fluxo de autodiscover após a mailbox ser migrada para o Exchange Online?”.

Hoje nós vamos entender todo o fluxo que o Outlook percorre durante o Autodiscover de uma mailbox migrada para o Exchange Online.

 

Autodiscover

O processo de Autodiscover, basicamente faz com que o Outlook receba as informações corretas de conexão com a Mailbox do usuário, ou seja, traz as configurações corretas do servidor de e-mail em que sua mailbox esteja hospedada.

Em uma implementação hibrida, o registro de Autodiscover deve estar apontando para seu ambiente de Exchange Server (CAS) local. Devemos também garantir que o serviço esteja funcionando corretamente e caso você queira testa-lo, basta executar um teste com o Remote Connectivity Analyzer selecionando a guia Exchange Server -> Descoberta Automática do Outlook -> Inserir as informações de uma mailbox local e inciar o teste:RCA

Após a migração da mailbox para o Exchange Online, o Outlook continuará a iniciar o processo de Autodiscover Lookup em seu servidor de Exchange local pois o registro estará apontando para seu ambiente local, assim como dito anteriormente. Mas como ocorre o processo de redirecionamento para o Autodiscover do Office 365? Vamos lá:

Autodiscover_Lookup_Hybrid

 

  1. Baseado no Email do usuário, o Outlook irá percorrer diversos passos até determinar o endereço de Autodiscover do seu servidor local. Esses passos são descritos no documento “Autodiscover for Exchange“. O cliente enviará um “Autodiscover Request” ao Endpoint descoberto durante o processo de Lookup, requisitando as informações da Mailbox baseado no Email Address que o Autodiscover Request irá enviar, o Exchange Server irá fazer uma pesquisa pelo recipiente no ambiente local. Ao encontrar o objeto, a busca irá verificar que esse objeto possui o atributo “TargetAddress” preenchido com um endereço do tipo “usuario@tenant.mail.onmicrosoft.com“. Esse atributo é preenchido automaticamente assim que a Mailbox é migrada para o Exchange Online e indica que ela está “hospedada” dentro do Exchange Online.TargetAddress
  2. Como o Outlook recebeu um endereço de e-mail diferente, que estava setado no atributo TargetAddress, ao invés das informações da mailbox, o processo de Autodiscover irá iniciar novamente, mas agora utilizando o TargetAddress  que no caso será algo como: usuario@tenant.mail.onmicrosoft.com. Neste novo processo, o novo EndPoint, ao invés de ser o seu autodiscover local, será sempre “autodiscover.tenant.mail.onmicrosoft.com” que será redirecionado para “Autodiscover.outlook.com“.
  3. O Outlook irá enviar um Autodiscover Request ao EndPoint de Autodiscover do Office 365 utilizando SSL. Esse request irá falhar fazendo com que o Outlook tente novamente, mas agora sem SSL utilizando a porta 80. A conexão será feita com sucesso, gerando um redirecionamento para “autodiscover-s.outlook.com”.
  4. Após a conexão com sucesso com o endereço anterior, o Exchange Online irá realizar um Lookup no “TargetAddress” especificado anteriormente. O valor do TargetAddress também estará especificado como um SMTP Secundário no atributo ProxyAddress. OBS: Após a execução do Hybrid Configuration Wizard, a politica de endereços de e-mail padrão será modificada, adicionando um SMTP Secundário nos usuários, como “usuario@tenant.mail.onmicrosoft.com“. Lembrando que esse endereço é um “Pré-requisito” para que a mailbox seja migrada para o Office 365, caso esse endereço não existe, o Move Request irá gerar um erro.
  5. Após o Lookup pela mailbox ser concluído com sucesso, o Exchange Online irá retornar informações sobre a Mailbox, Public Foldes e Delegated Mailbox do usuário.

Espero que tenham gostado,

Até a próxima! 😀

Anúncios

#QuickTips – Atribuindo um IP Fixo a uma Máquina Virtual existente do Microsoft Azure

microsoft-azure-logo

Olá pessoal!

Seguindo a série de dicas rápidas, esses dias eu tive a necessidade de atribuir um IP Dedicado (conhecido também como “IP Fixo”) a uma máquina virtual existente no Microsoft Azure. Ao atribuir um IP Dedicado à uma máquina virtual, ele não será distribuído à nenhuma outra Máquina Virtual.

1. Primeiramente nós devemos fazer a instalação do Azure Powershell que pode ser feito o download aqui.

2. Após a instalação do Azure Powershell, execute-o como administrador e digite “Add-AzureAccount” para se conectar a sua conta do Azure:ScreenShot001

3. Insira suas credenciais:

ScreenShot002

4. Após a conexão com a sua conta do Azure, podemos testar se um IP especifico está disponível para ser atribuído à uma Máquina Virtual com o seguinte comando:

TestAzureStaticVNetIP VNetName NomedaVNet IPAddress 10.23.21.5 ScreenShot003

Aonde:

-VNetName: Nome da Rede Virtual (Virtual Network)

-IpAddress: IP que deseja consultar

Caso o IP esteja livre, o parâmetro “IsAvailable” deve ser “True

ScreenShot004

Agora que já verificamos que o IP está disponível para utilização, podemos prosseguir.

5. Para que possamos fixar este IP a uma máquina virtual, devemos executar o seguinte comando:

GetAzureVM ServiceName CloudServiceName Name NomedaVM | Set-AzureStaticVNetIP -IPAddress 10.10.0.7 | UpdateAzureVM

ScreenShot006

Aonde:

-ServiceName: Nome da Cloud Service que a VM se encontra

-Name: Nome da Máquina Virtual

-IPAddress: IP que deseja fixar nessa máquina virtual

Após a execução do comando, a máquina virtual será reiniciada caso esteja ligada por conta do comando “Update-AzureVM” que executamos acima.

6. Após executar o comando de verificação novamente, o parâmetro “IsAvailable” está com o valor “False“, indicando que o IP não está disponível pois foi atribuído a outra máquina virtual. Repare que o Azure nos da opções de IPs disponíveis:

ScreenShot007

Espero que seja útil, muito obrigado!

Julio Araujo

MSCloud365 no TechEd Brasil 2015!

insights1

Fala pessoal, tudo bem?

Como vocês já sabem, o maior evento técnico da Microsoft, o TechEd (agora chamado de Microsoft Insights), está de volta ao Brasil. Este ano ele vai acontecer nos dias 24 e 25 de Setembro no Transamerica Expo Center. Serão mais de 90 palestras técnicas com Engenheiros da Microsoft. Além disso alguns nomes de peso estarão palestrando nesse evento como: Paula Bellizia (Presidente da Microsoft Brasil), Jeff Woolsey (Principal Program Manager da Microsoft para a divisão de Enterprise e Cloud) entre outros grandes nomes diretamente da Microsoft Corp.

Eu estarei lá representando a MSCloud365 e já montei a minha grade de palestras. Ao final dos dois dias de evento vou fazer um resumão do que foi apresentado, quais foram as minhas impressões com relação ao evento e, posteriormente compartilhando todo o conhecimento adquirido com vocês através de artigos técnicos. Tenho uma grande expectativa com relação as palestras técnicas e estrutura do evento mesmo sendo o primeiro TechEd que vou participar.

Como eu disse acima, eu já montei a minha lista de palestras para os dois dias de evento e vou compartilha-la com vocês para que possam ter um gostinho do que vem por ai no blog.

Dia01_TechedDia02_Teched

Completando um único Move Request de uma Batch de migração via Powershell

Olá,

Quando criamos um novo batch de migração (ExchServer to O365 ou O365 to ExchServer), temos a possibildiade de concluir manualmente esse batch de migração, ou seja, ao chegar em 95% o Move Request da mailbox entra em um estado de “AutoSuspended” e só após completarmos a batch de migração que o Move Request completa a migração e o usuário passa a acessar sua caixa direto no Office 365. OBS: Lembrando que até você concluir a batch de migração o usuário continua acessando a sua caixa de mensagens no Exchange Server.

“Mas qual é o intuito deste artigo, Julio?”

Bom, existem casos aonde o batch de migração contém muitos usuários, temos metade dos usuários com o estado “AutoSuspended” e metade em qualquer outro estado e você necessita completar apenas alguns usuários da sua batch, enquanto outros continuam sincronizando seus dados para o Office 365. Neste artigo eu vou ensinar como realizar essa taréfa de uma maneira simples e rápida utilizando o nosso grande amigo Powershell.

Se conectando ao Exchange Online via Powershell

Caso seja a primeira vez que você se conecta ao Office 365 via Powershell, você deve seguir os seguintes passos:

  1. Faça o Download e instalação do Microsoft Online Services Sign-in Assistant
  2. Faça o Download e instalação do Azure Active Directory (AD) Module

Após fazer o Download e Instalação dos itens acima, vamos aos passos para nos conectar o nosso serviço do Exchange Online:

  1. Abra o Powershell como Administrador e execute a seguinte serie de comandos

#Obtendo as credenciais de administrador do Office 365
$credential = get-credential

#Importando o Modulo do MSOnline
Import-Module MSOnline

#Conectando nos serviços do MSOnline com as credenciais inseridas
Connect-MsolService -Credential $credential

#Armazenando uma sessão do Exchange Server em uma variável
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “https://outlook.office365.com/powershell-liveid/” -Credential $credential -Authentication “Basic” -AllowRedirection

#Importando Sessão do Exchange
Import-PSSession $ExchangeSession

Completando um único Move Request em um Migration Batch que está com o estado “Sincronizando”

Para que você possa completar apenas um usuário que está em estado de “AutoSuspended” de um batch de migração, execute os seguintes comandos no Powershell após a conexão com o Exchange Online:

  1. Get-MoveRequest | Get-MoveRequestStatistcs para verificar o usuário que está com o estado “AutoSuspendedGet-MoveRequest-Antes
  2. Get-MoveRequest “DisplayNamedousuário” | Set-MoveRequest -SuspendWhenReadytoComplete:$false
  3. Get-MoveRequest “DisplayNamedousuário” | Resume-MoveRequest

Executando o comando

Espere alguns minutos, repita o 1º comando e verá que o usuário está com o “StatusDetail” como “Completed”.

Espero ter ajudado,

Abraços!

Exchange Server 2016 – O que vem por ai!?

No dia 22 de Julho de 2015  a Microsoft lançou a versão Preview do Exchange Server 2016.  Neste post iremos trazer um resumo sobre algumas novidades da versão Preview.
O Vídeo abaixo mostra algumas novidades do Produto:

Novidades
A primeira grande mudança esta na arquitetura, durante a instalação podemos escolher a função de Mailbox e Edge (Lembrando que no Exchange Server 2013 o Edge só foi disponibilizado no Exchange 2013 SP1). A função de Acesso ao Cliente foi absorvida pelo Mailbox.

A Imagem abaixo mostra a arquitetura de um ambiente com Exchange Server 2016.

e16_thumb_33FB2F9E

Continuar lendo

Instalando o Exchange Server 2016 Preview

A Versão preview do Exchange Server 2016 lançada no dia 22 de julho de 2015, ejá  está disponível para download. Neste Post iremos explicar os passos para executar uma instalação limpa do Exchange Server 2016.

Cenário:

Servidor 01

Função:   ADDS,ADCS,DNS.
Hostname: adds.mscloud365.com
IP:       192.168.1.20
SO:       Windows Server 2012 R2

Servidor 02

Função:   Exchange Server 2016 (Mailbox)
Hostname: exchange.mscloud365.com
IP:       192.168.1.30
SO:       Windows Server 2012 R2

Instalando

Pré-Requisitos

Abra o Windows Power Shell e execute o comando abaixo:

Install-WindowsFeature RSAT-ADDS, AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

Capturar

Continuar lendo

Exchange Server 2013 – Recriando os conectores de recebimento padrão

Olá, recentemente tive a necessidade de recriar todos os conectores de recebimentos padrão (Default Receive Connectors) da instalação do Exchange Server 2013.

Para que possamos fazer isso, basta executar a seguinte série de comandos no Exchange Management Shell:

$range = “0.0.0.0-255.255.255.255″,”::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff”

New-ReceiveConnector -Name “Client Proxy SRV-MAIL02 (Nome do meu servidor CAS/MBX)” -Bindings 0.0.0.0:465, [::]:465 -AuthMechanism Tls,Integrated,BasicAuth,BasicAuthRequireTLS,ExchangeServer -RemoteIPRanges $range -TransportRole HubTransport -PermissionGroups ExchangeUsers,ExchangeServers -MaxMessageSize 35MB -MessageRateLimit 5 -MessageRateSource User -EnableAuthGSSAPI $True -Server SRV-MAIL02 (Nome do meu servidor CAS/MBX)

New-ReceiveConnector -Name “Default Frontend SRV-MAIL02 (Nome do meu servidor CAS/MBX)” -Bindings 0.0.0.0:25, [::]:25 -AuthMechanism Tls,Integrated,BasicAuth,BasicAuthRequireTLS,ExchangeServer -RemoteIPRanges $range -TransportRole FrontendTransport -PermissionGroups AnonymousUsers,ExchangeServers,ExchangeLegacyServers -MaxMessageSize 36MB -DomainSecureEnabled $True -ProtocolLoggingLevel Verbose -Server SRV-MAIL02 (Nome do meu servidor CAS/MBX)

New-ReceiveConnector -Name “Outbound Proxy Frontend SRV-MAIL02 (Nome do meu servidor CAS/MBX)” -Bindings 0.0.0.0:717, [::]:717 -AuthMechanism Tls,Integrated,BasicAuth,BasicAuthRequireTLS,ExchangeServer -RemoteIPRanges $range -TransportRole FrontendTransport -PermissionGroups ExchangeServers -MaxMessageSize 36MB -DomainSecureEnabled $True -ProtocolLoggingLevel Verbose -Server SRV-MAIL02 (Nome do meu servidor CAS/MBX)

New-ReceiveConnector -Name “Client Frontend SRV-MAIL02 (Nome do meu servidor CAS/MBX)” -Bindings 0.0.0.0:587, [::]:587 -AuthMechanism Tls,Integrated,BasicAuth,BasicAuthRequireTLS -RemoteIPRanges $range -TransportRole FrontendTransport -PermissionGroups ExchangeUsers -MaxMessageSize 35MB -MessageRateLimit 5 -MessageRateSource User -EnableAuthGSSAPI $True -Server SRV-MAIL02 (Nome do meu servidor CAS/MBX)

New-ReceiveConnector -Name “Default SRV-MAIL02 (Nome do meu servidor CAS/MBX)” -Bindings [::]:2525, 0.0.0.0:2525 -AuthMechanism Tls,Integrated,BasicAuth,BasicAuthRequireTLS,ExchangeServer -RemoteIPRanges $range -TransportRole HubTransport -PermissionGroups ExchangeUsers,ExchangeServers,ExchangeLegacyServers -MaxMessageSize 35MB -MaxInboundConnectionPerSource Unlimited -MaxInboundConnectionPercentagePerSource 100 -MaxRecipientsPerMessage 5000 -SizeEnabled EnabledWithoutValue -Server SRV-MAIL02 (Nome do meu servidor CAS/MBX)

Muito obrigado, até a próxima!