10 Perguntas Frequentes – Exchange Server
By: Caio Ribeiro César
Estava fazendo um review dos meus casos antigos e me deparei com algumas dúvidas que de tempos em tempos voltam a ser feitas em casos de advisory ou até troubleshooting.
Decidi criar este post para responder algumas dúvidas selecionando 10 FAQ:
1- Server Side Rules Limit – Exchange Server 2010
Alguns clientes usam diversas rules e nos perguntam quando eles terão problemas de scalability, se existe um limite de número/tamanho do ruleset para mailbox em um ambiente com Exchange Server 2010.
O limite máximo é de 256KB, com um default de 64KB:
Nota: Aumentar o tamanho do rules quota possui um efeito no consumo de memória durante o delivery. Quanto mais rules existirem para serem executadas, mais memória é consumida.
O correto seria efetuar um sizing experiment aumentando o valor de rules quota para um número de usuários que estão na mesma DB e validar as alterações de consumo de memória. Logicamente a quantidade de memória aumentará somente quando mais regras forem adicionadas. No Exchange Server 2010, o processo a ser monitorado é o transport e no Exchange Server 2007 o próprio store.exe.
2- Import Mailbox (Exchange Server 2007) 32b vs. 64b
Alguns clientes nos informam que não conseguem importar psts para mailboxes em sistemas operacionais com arquitetura 64b.
Para se importar data de um arquivo .pst, você deve ter a versão 32b do Exchange Management Tools. Você não conseguirá efetuar o procedimento de Import-Mailbox em um Exchange Server 2007 64b, você deverá executar o Import-Mailbox de um computador 32b com os seguintes pacotes instalados:
- Exchange Management Tools (32b);
- Outlook 2007 / Outlook 2003SP2.
Para maiores informações, acesse a documentação da Microsoft.
3- Exchange 2010 – Multiple DL Owners
Muitos clientes perguntam se ainda é possível ter diversos owners para uma Distribution List no Exchange Server 2010.
Quando falamos de “owner”, estamos nos referindo ao valor “ ManagedBy ”:
Managedy
Optional
Microsoft.Exchange.Data.MultiValuedProperty
 |
A alteração feita no Exchange Server 2010 nos impossibilita adicionar grupos para gerenciar Distributions Lists. O mesmo não se aplica para indivíduos múltiplos.
Este comportamento é by default, o .ps1 descrito neste post pode reverter esta configuração.
4- Instalação de OWA 2007/2010 em uma DMZ
A instalação de um CAS em uma DMZ é um ambiente não suportado pela Microsoft. O CAS deve ser membro de um Active Directory service domain e estar no grupo de segurança “Exchange Servers Active Directory”. Este grupo possui acesso de read/write em todos os Exchange Servers da sua organização e a comunicação do CAS server para o Mailbox é por RPC.
Source: https://technet.microsoft.com/en-us/library/bb232184(EXCHG.80).aspx
Existe um artigo muito bom dizendo exatamente o que não deve ser feito na instalação de um CAS server, pode ser acessado neste link.
5- Exchange Server em um ambiente Virtualizado
Diversos clientes abrem casos de advisory para validar se a versão instalada do Exchange Server é compatível com a tecnologia de virtualização. Basta acessar este site da Microsoft e as versões/suportabilidade estarão detalhadas. Esta regra não se aplica somente para o Exchange Server J.
6- ActiveSync com 3rd party mobile devices
Quais são os known-issues de versões dos 3rd party mobile devices configurados em um ambiente 2010/2007/BPOS? A lista dos problemas mais conhecidos está descrita neste artigo.
7- Free Busy OWA 2003 coexistence O365
Quando os usuários on-premisse utilizam o OWA do Exchange 2003 e tentam ver a disponibilidade dos usuários on cloud, eles não conseguem.
O Outlook Web Access do Exchange Server 2003 não pode efetuar conexões Web-based Distributed Authoring and Versioning (WebDAV) para uma Free/Busy system folder dos usuários on cloud. A arquitetura do O365 é do Exchange Server 2010 e esta versão não suportaconexões WebDAV.
Na documentação da Microsoft (Exchange Calendaring Sharing Matrix) podemos ver que o Free/Busy funciona com clientes MAPI. Basta então utilizar um cliente Outlook que estes usuários on-premisse terão estas informações de disponibilidade (Free/Busy) dos usuários on cloud.
8- Criação de rules de move mailbox para um servidor Exchange Server 2007
Alguns clientes possuem dúvidas de como configurar o Exchange Server 2007 para prevenir que os usuários administrativos não movam as mailboxes de usuários para um Mailbox server específico.
A opção de Split Permissions com alguns Access Control Lists configurados em diferentes Databases pode alcançar este objetivo (Split Permissions Model Reference / Planning and Implementing a Split Permissions Model).
O RBAC do Exchange Server 2010 nos traz esta feature de um modo muito mais simples.
9- Prevenir que os usuários removam seus emails permanentemente – Exchange Server 2010
Como posso fazer com que os usuários não removam permanentemente os emails por engano? Diversas vezes tivemos que efetuar restores por uma pequena desatenção do usuário final.
Alguns clientes tentam habilitar esta feature com comandos como:
Add-MailboxPermission –Identity mailbox1 –User “NT Authority\Self” –Deny –AccessRights DeleteItem
[Não irá funcionar, o usuário ainda terá acesso para deletar seus emails].
Remove-mailboxpermission –identity mailbox1 –user “NT Authority\Self “ –Accessrights FullAccess –inheritancetype all
MailboxPermission –Identity mailbox1 –User “NT Authority\Self” –AccessRights ReadPermission,ChangePermission –Inheritancetype All
[Não irá funcionar, o usuário ainda terá acesso para deletar seus emails].
Partindo da premissa de que o usuário tem Full Mailbox Access, ele terá acesso para remover os emails de sua mailbox. Para que esta feature seja habilitada, use o “Enable Single Item Recovery”, assim eles não poderão remover os emails permanentemente.
10- Exchange Server instalado em um Domain Controller
Este cenário é suportado, porém não recomendado. Por motivos de segurança e performance, recomendamos que você instale o Exchange Server em um servidor que não seja um Domain Controller.
Você não conseguirá efetuar um DCPromo em um computador que tiver o Exchange Server 2010 instalado. Após a instalação de um Exchange Server 2010, a alteração de member role dele de um member server para um directory server (ou vice-versa) não é suportada.
Se você gostaria de utilizar Address Book policies para o seu address list, você não deve instalar o Exchange em um Global Catalog/Domain Controller. O serviço de Name Service Provided Interface (NSPI) é um serviço oferecido pelo AD e pelo DoMT (Directory on the Middle Tier/Address Book Service), se você efetuar a instalação do Exchange em um GC/DC você utilizará este serviço do AD o que significa que não existirão Address Book policies para clientes MAPI.
Além disso, o fator de performance é importante. Reforçamos a idéia de um single role por servidor e não diversas roles, o que facilita o gerenciamento e a capacidade do servidor para tratar os serviços em execução. Os algoritimos de gerência de memória do Windows dependem do parâmetro “LargeSystemCache” que basicamente possue duas possibilidades de configuração (0 e 1):
 |
No setup o Exchange configura esta opção como “0” (desta maneira o Exchange consegue gerenciar o seu próprio cache assumindo assim que nenhum outro importante processo está instalado no mesmo sistema).
O Domain Controller altera esta opção para “1”, para que esta memória seja utilizada por todas as API’s que a utilizem. Isto dá uma maior prioridade para o System Cache e consequentemente menos prioridades para outros processos como é o exemplo do Exchange.
Isto pode ser alterado pelo registro/control panel, system, advanced porém os comportamentos padrões de cada tecnologia são diferentes.
Em geral, entrar neste cenário não é uma boa idéia. A Microsoft não suporta a utilização de um Exchange Server em cluster nodes que também são configurados como Domain Controllers. Caso você já tenha um Exchange Server 2003 em um Domain Controller, efetuar o dcpromo deste servidor também não é um cenário suportado. O correto seria mover o Exchange antes de qualquer alteração deste Domain Controller.
Se a empresa está buscando contenção de custos, o correto seria avaliar a melhor estratégia como ambientes on-cloud ou hardwares que suportem o ambiente com uma boa análise de sizing.