Devido a necessidades de usuários enviarem e-mails em nome de listas de distribuição/outro usuário, hoje vou mostrar como configurar o Exchange Online através do Shell, para fazer com que o Usuário possa enviar e-mails em nome de uma Lista de Distribuição/Usuário.

Segue os procedimentos:

1 – Instalar o Modulo do PowerShell para o Office365
http://onlinehelp.microsoft.com/Office365-enterprises/ff652560.aspx

2 – Importar o modulo do PowerShell**

**Se você está executando os comandos pela primeira vez no Windows Power Shell, execute os comandos abaixo no Windows PowerShell:

“Set-ExecutionPolicy RemoteSigned”

“Enable-PSRemoting –force”

Para iniciar uma sessão execute os comandos abaixo (copiar e colar no Windows Power Shell):

$Cred=GET-CREDENTIAL
CONNECT-MSOLService -credential $Cred
$s = NEW-PSSESSION -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $Cred -Authentication Basic -AllowRedirection
$importresults=import-pssession $s

3 – Executar o comando:

Add-RecipientPermission “Identity” -AccessRights SendAs -Trustee “User”

Identity = Nome do usuário ou lista de distribuição onde a permissão será aplicada

User = Nome do usuário que terá a permissão de enviar e-mails em nome de “Comunicacao”

4 – Verificar se as permissões foram aplicadas ao objeto através do comando:

Get-RecipientPermission <Nome do Grupo ou Nome do Usuário>

Após efetuar este procedimento é necessário aguardar um tempo para que as permissões sejam efetivamente validadas pelo Exhange Online.

IMPORTANTE: Caso o Outlook ainda apresente erro relativos a permissão na hora de enviar a mensagem, conforme o KB2679269, é necessário que o usuário baixe novamente o Catálogo de Endereços Offline (OAB) para que ele possa fazer o envio corretamente. Isto acontece porque a GAL é atualizada com a permissão, porém o Cliente Outlook está buscando as informações no seu OAB e não na GAL, ao utilizar o OWA o usuário conseguirá fazer o envio normalmente pois o mesmo busca informações na GAL.

Até a próxima,

Diogo Heringer

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

Após feita toda a configuração híbrida para efetuar a migração de um ambiente Exchange Server 2003 para o Exchange Online e depois de fazer o move de alguns Mailbox saio deste projeto sabendo que meu dever foi cumprido.

Gostaria de agradecer aos amigos Cláudio Ávila e Carlos Travagini que me ajudaram bastante no decorrer deste projeto e com certeza foram fundamentais para o sucesso do mesmo, apesar de todas as contas ainda não terem sido migradas, agora é apenas uma questão de tempo para migração das restantes.

Neste post vou mostrar o passo a passo de migração de um ambiente Exchange On-Premise para o Exchange Online, utilizando o processo de coexistência Híbrida:

1 – Preparando para a Implementação:

Exchange 2010 SP2 Hybrid Servers:

Recomendado a instalação do Update Rollup 2 para o Exchange Server 2010 SP2, pois corrige alguns problemas relacionados a Hybrid Configuration.

• 64-bit edition of Windows Server 2008 Standard Service Pack 2
  
• 64-bit edition of Windows Server 2008 Enterprise Service Pack 2
  
• 64-bit edition of Windows Server 2008 R2 Standard Service Pack 1
  
• 64-bit edition of Windows Server 2008 R2 Enterprise Service Pack 1

Os seguintes pré-requisitos  também devem estar instalados:

• .NET Framework 3.5 SP1
  
• Internet Information Services (IIS)
  
• Windows PowerShell V2.0
  
• Windows Remote Management V2.0

DirSync:

Requisitos de Computador:

•O computador deve fazer parte de um Domínio
da mesma Floresta que será sincronizada

•Não é necessário estar ingressado no domínio “Root”

•O computador não pode ser um DC

•O computador deve se comunicar com todos os DCS da floresta

Recomendação de Hardware

Requisitos de Software:

•Windows PowerShell versão 2.0

•Microsoft .NET Framework versão 3.5 ou mais novo

•Windows Server 2003/R2 x86 ou x64 com Service Pack 2 ou mais novo, Windows Server 2008 x86 ou x64 com o último Service Pack.

•Microsoft Online Services Sign-In Assistant (Não é um requisito para a instalação, mas necessário para a a conexão com o Office 365)

•Windows Installer 4.5 ou mais novo

Serviço de Diretório (Active Directory):

No site do Active Directory onde será instalado o servidor Híbrido de Exchange Server 2010 SP2, é necessário pelo menos um DC com as seguintes configurações:

• Windows Server 2003 Standard Edition with SP1 or later (32-bit or 64-bit)
  
• Windows Server 2003 Enterprise Edition with SP1 or later (32-bit or 64-bit)
  
• Windows Server 2008 Standard or Enterprise RTM or later (32-bit or 64-bit)
  
• Windows Server 2008 R2 Standard or Enterprise RTM or later
  
• Windows Server 2008 Datacenter RTM or later
  
• Windows Server 2008 R2 Datacenter RTM or later

O nível funcional da floresta deve ser Windows Server 2003 ou posterior

Exchange Server 2003:

• Microsoft Exchange Server 2003 SP2 ou posterior
• Organização do Exchange Server 2003 em modo nativo

2 – Pré Requisitos para configuração do Ambiente Híbrido

Adicionar domínios SMTP no Office365:

1. Fazer logon no Portal Microsoft Online
2. Clicar em “Admin”, em seguida em “Domains”
3. Clicar em “Add a Domain”
4. Preencher com o endereço SMTP que será usado pelos usuários. Por exemplo, “contoso.com”. Clicar em “Next” m
5. Clicar em “Verify Domain”
6. Seguir as instruções na tela para verificação do domínio. Aguardar cerca de 15 minutos e clicar em “Verify”

Configurar o DirSync:

Seguir os passos:

1. Pré-Requisitos
2. Planejamento
3. Instalando e Configurando

Instalar o Exchange Server 2010 (CAS e Mailbox)

1 – Fazer o download do Exchange Server 2010 SP2

2 – Executar a instalação do Exchange Server seguindo o Tutorial de Instalação do Exchange Server, porém escolhendo a opção “Custom Installation” e selecionando as funções de CAS e MB.

Instalar o Exchange Server 2010 (HUB)

1 – Fazer o download do Exchange Server 2010 SP2

2 – Executar a instalação do Exchange Server seguindo o Tutorial de Instalação do Exchange Server, porém escolhendo a opção “Custom Installation” e selecionando as funções de HT.

( Caso exista algum problema na criação dos Routing Groups ver o post: “Projeto Office365: Criando Routing Groups”)

Configurar os Registros DNS

1 – Criar os seguintes registros no DNS:

Configurar a Interface de Gerenciamento

1 – Abrir o EMC (Exchange Management Console)

2 – Na console, clicar com o botão direito em “Microsoft Exchange” e em seguida em “Add Exchange Forest”

3 – Na tela que se abrirá vamos preencher os campos da seguinte forma:

4 – Na tela onde irá pedir as credenciais vamos digitar “Usuário” e “Senha” de um “Global Admin” do tenant Office365.

Importar o certificado válido para o Exchange Server (.pfx)

1 – Abrir o Exchange Management Console (EMC), navegar até “Server Configuration” e clicar em “Import Exchange Certificate”:

2 – Na tela que se abrirá vamos dar um “Browse” no certificado, digitar a senha correspondente e clicar em “Next”:

3 – Selecionar o servidor de “Client Access” e clicar em “Next”

4 – Clicar em “Import” para concluir a importação

5 – Novamente na tela do “Server Configuration” clicar em cima do certificado importado e em seguida em “Assign services to certificate”:

6 – Selecionar o servidor e clicar em “Next”:

7 – Escolher os serviços de “SMTP” e “IIS”:

8 – Clicar em “Assign” para associar os serviços:

Configurar o Exchange Web Services

1 – Abrir o Exchange Management Console (EMC), navegar até “Server Configuration” em seguida em “Client Access”.

No “Action Panel” clicar em “Configure External Client Access Domain”:

2 – Definir a URL que iremos utilizar para o nosso servidor “Client Access” e clicar em “Configure”:

Criar o Hybrid Deployment

1 – Abrir o Exchange Management Console (EMC) e navegar até “Organization Configuration”.

Clicar na aba “Hybrid” Configuration” em seguida clicar com o botão direito na tela e em “New Hybrid Configuration”.

2 – Clicar em “New”, aguardar a criação e em seguida clicar em “Finish”.

3 – Clicar com o botão direito em “Hybrid Configuration” que acaba de ser criado e em seguida em “Manage Hybrid Configuration”:

4 – Inserir as credenciais On-Premise ( Organization Administrator ) e também as credenciais Online ( Global Administrators ) e clicar em “Next”:

5 – Inserir os domínios que irão fazer parte do Hybrid Configuration. É necessário criar um sub-domínio, de acordo com o Exchange Deployment Assistant. Para isso devemos criar este subdomínio como “Autoritativo” em “”Organization Management > Hub Transport > Accepted Domains” e também devemos validar este sub-domínio no Portal do Microsoft Online.

Clicar em “Next”:

6 – Criar na Zona de DNS Externa os registros TXT correspondentes ao domínio e subdomínio adicionados no passo anterior.

Clicar em “Next”:

7 – Adicionar os servidores de “Hub Transport” e “Client Access” que irão ser responsáveis pelo Hybrid Configuration:

Clicar em “Next”:

8 – Inserir o endereço IP público do seu servidor Híbrido (Ou endereço IP do Firewall que irá redirecionar) e em seguida preencher a URL referente ao servidores Hibridos de Hub Transport (Endereço escolhido em “Configure Exchange Web Services” neste documento).

Clicar em “Next”.

9 – Na tela da escolha do certificado, automaticamente o certificado importado já será escolhido. Basta clicar em “Next”, caso não queira que as mensagens sejam todas roteadas através do seu ambiente On-Premise:

10 – Clicar em “Manage” para a configuração do Hybrid Configuration:

11 – A configuração foi concluída com sucesso.

Com a configuração feita agora podemos executar “Remote Move Request” para fazer o move de Mailbox do ambiente On-Premise para o ambiente Online.

Até a próxima,

Diogo Heringer

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

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

Temos uma grande notícia! “Temos?” você deve estar se perguntando…É temos! falando como nós: o Learning 365! Dia 09/06/2012: Mauricio Cassemiro, Fernando Andreazi, Sara Barbosa, Felipe Moreno e Diogo Heringer mostrarão à todos este projeto que foi cuidadosamente pensado e arquitetado com muito empenho: O Learning 365! O lançamento será na sede da Microsoft em São Paulo das 08h30 às 17h00 no evento chamado #Office 365 Day e contamos com a presença de todos vocês!

Segue a agenda do nosso evento:

• 08:30 as 9:00 – Welcome Coffe
• 9:00 as 09:30 – Agenda do evento e apresentação do Learning365
• 09:30 as 10:00 – Overview do Office 365
• 10:00 as 10:40 – Explorando o Office Professional Plus e o Office Web Apps
• 10:40 as 11:20 – Modelo de negócios do Office 365
• 11:20 as 11:30 – Apresentação do novo site de treinamentos Learning365
• 11:30 as 12:00 – Visão geral do Lync Online
• 12:00 as 13:00 – Almoço
• 13:00 as 14:30 – Migrando para o Exchange Online
• 14:30 as 15:30 – Identity Fedaration – SSO
• 15:30 as 16:30 – SharePoint Online
• 16:30 as 17:00 – Dicas de certificações para Office 365

Abordaremos toda a plataforma e suas novas updates e features!

Faça já sua inscrição através do link em Microsoft Events:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032513522&Culture=pt-BR

Palestrantes: Fernando Andreazi, Sara Barbosa, Mauricio Cassemiro, Felipe Moreno e Diogo Heringer.

Até a próxima,

Diogo Heringer

O Mailbox Replication Service é o serviço responsável por fazer a migração dos Mailbox no Ambiente Híbrido de Exchange Server 2010 + Exchange Online. Desde ontem estava com problemas ao realizar a migração, pois todo “New-RemoteMoveRequest” que eu realizava ficava apenas com status de “Queued”, sendo que o status correto seria “Moving”. Não é gerado nenhum log no Event Viewer relacionado a este problema.

Ao pesquisar e depois de tentar resolver quase todos os problemas do Event Viewer (rs), percebi que esqueci de fazer o básico: Verificar a “Integridade do Serviço” no Portal do Office365.

Segue um print do problema:

Note que já tem 38 minutos para migrar uma conta de 47MB, isto não é normal.

Ao verificar a “Integridade do Serviço” no Portal Office365 juntamente com o fato de que eu já tinha migrado contas anteriormente, pude perceber que o problema não está no meu ambiente On-Premise, e sim é um problema que a Microsoft está passando e que está sendo solucionado o mais rápido possível.

Segue a nota do problema:

We’ve found the root cause for the Move Requests failures and are working on a code fix to resolve the problem. The ETA for that fix to get coded, tested, and completely deployed worldwide is Wednesday 5/9, at 8AM PDT, so certain types of new mailbox onboarding have been halted until this fix is put into place. A clarification on the types of onboarding that are currently blocked: 1) BPOS to O365 transitions 2) Exchange on-premise to O365 migrations using the Mailbox Replication Service (MRS) Types of onboarding that are not blocked: 1) 3rd party IMAP tools 2) 3rd party Exchange Web Services (EWS) tools 3) 3rd party MAPI tools We apologize for the inconvenience this is causing and the delay it is causing you to experience in your onboarding to Office 365. We will continue to regularly update this as we make progress toward resolution.

Para quem está com o mesmo problema fique tranquilo! Ele já está sendo tratado e em breve estará resolvido.

Até a próxima,

Diogo Heringer

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:

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

Olá pessoal,

A MessageOps possui uma ferramenta muito útil para nos auxiliar no processo de atualização das estações de trabalho para transição de BPOS para Office365. O Office 365 Client Updater é um aplicativo simples que fornece aos administradores um método automatizado para implantar as atualizações recomendadas para o Office 365.

Hoje, sem o Office 365 Client Updater, temos duas opções, executar o Office365 Desktop Setup, ou baixar as atualizações manualmente e fazer a distribuição via GPO, SMS, SCCM, WSUS, etc.

Atualizações manuais: http://community.office365.com/en-us/w/administration/manually-install-office-365-desktop-updates.aspx

O Office365 Client Updater está disponível no Office365Download: O365Update.exe

Lembrando que as atualizações são necessarias para que após a transição o Microsoft Outlook se reconecte automaticamente com o Office365.

Diogo Heringer

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”.

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.

 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

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