Perguntas e respostas do Exchange: Automatizar e consolidar
Há muitas maneiras de contornar a automação, o compartilhamento de caixa de correio e os problemas de consolidação no Exchange.
Henrik Walther
Com clientes colaboradores Georg Hinterhofer
Resiliência de site em conectores de envio
**P.**Nós estamos no processo de implantação do Exchange 2010 em vários sites e configuração de backup para redundância. Ao planejar para entrega de email de saída via hosts inteligentes, queremos alcançar redundância automática caso o local principal vai para baixo. Gostaríamos de manter o tráfego no local principal, quando tudo está bem. Como podemos conseguir isso?
**R.**Você pode facilmente adicionar que vários hosts inteligentes de um conector de envio e a troca serão alternada apenas através deles. No entanto, isto só resolve uma exigência: redundância entre sites. O tráfego ainda ser uniformemente distribuído mesmo quando todos os sites estão em alta, queimando assim desnecessária da largura de banda entre os sites.
Neste caso, o conector de envio é configurado com dois gateways de email primário e secundário listados como hosts inteligentes. Exchange usará aqueles em ordem alternada para entregar emails de saída.
Para resolver isso, você precisará aplicar um truque bacana lecionou na formação Microsoft Certified Master. Ele é baseado no fato pouco conhecido que na caixa host inteligente no Exchange (versões 2003, 2007 e 2010) não podem ter somente os registros ou endereços, IP resolvido, mas deve também ter registros do Mail Exchanger (MX). Você pode, no entanto, atribuir prioridade aos registros MX.
Em primeiro lugar, certifique-se de que você tem registros DNS A para os gateways de email no local. Em seguida, veio acima com um nome aleatório para seu registro MX em breve-a-ser-criado no DNS. Neste exemplo, eu escolhi allsmarthosts.forest1.local. Crie os necessários registros MX no DNS.
Com simples MX roteamento baseado, o Exchange usará o registro MX com prioridade mais alta, enquanto ele está disponível. Agora a única coisa que resta fazer é reconfigurar o conector de envio do Exchange para ler allsmarthosts.forest1.local como o host inteligente somente.
Fazendo isso, o Exchange usará primary.forest1.local para emails de saída, enquanto ele está disponível. Uma vez que ele vai para baixo ou se torna inacessível, Exchange começará usando secondary.forest1.local como o host inteligente. Isso é o que um pequeno truque DNS pode fazer por você.
Compartilhamento entre organizações
**P.**Nós recentemente adquiriu uma empresa que está executando o Exchange 2010. Enquanto o plano é a consolidação de ambos os ambientes, precisamos estabelecer imediatamente o calendário (não apenas Free/Busy) compartilhamento entre ambas as organizações. Parece haver pouca informação lá fora. Você pode compartilhar alguns detalhes no calendário de 1:1 como compartilhamento funciona e o que precisamos configurar para isso?
**R.**Esse recurso foi desenvolvido para o Office 365 facilitar a coexistência no local. Você pode usá-lo para este cenário também. Ambas as organizações precisam estar executando o Exchange 2010. Os clientes podem ser 2010 do Outlook Web Access (OWA) ou Outlook 2010.
Neste caso, o cliente de compartilhamento de calendário pode especificar a quantidade de informações (somente Free/Busy, Free/Busy mais local, com todos os detalhes de Free/Busy) para compartilhar. Então, como funciona? Tecnicamente, seu próprio servidor de caixa de correio vai criar uma cópia ou cache do calendário compartilhado e mostrá-lo para você no Outlook ou no OWA. Este é um dos principais obstáculos. Os servidores de caixa de correio devem ser capazes de acessar a Internet, como eles são os consultar para itens de calendário compartilhado.
Quando você olha no calendário compartilhado no MFCMAPI, parece muito com uma de sua preferência. A exceção é que ele é marcado como somente leitura. Você pode ver todos os itens do calendário compartilhado, como eles são realmente armazenados em sua própria caixa de correio.
Para configurá-lo, você precisará configurar ambas as organizações a Federação com o Microsoft Federation Gateway (MFG). Você também precisará garantir que, se uma organização ainda estiver executando a versão RTM do Exchange, você precisará atualizá-lo pelo menos o primeiro service pack para que você vai pegar a mesma instância do MFG. Relações organizacionais não é necessário neste caso. (Você precisaria aqueles para o compartilhamento de livre/ocupado, mas você vai querer obter neste caso, o compartilhamento de calendário.)
A Federação sua organização com a MFG, basta seguir os passos descritos aqui. Você precisará publicar registros TXT adicionais no DNS para comprovar a propriedade do domínio. Faça isso para ambos os sites que deseja agrupar e adicionar domínios apropriados. Além disso, você precisará definir as diretivas de compartilhamento em ambos os lados para permitir o compartilhamento com detalhes de calendário.
Aviso já a diretiva padrão permite que os usuários compartilharem calendário informações de livre/ocupado com o mundo inteiro (indicado pela * domínio). Você quer ter completo calendário partilha com o seu parceiro, então você precisa definir o compartilhamento dial corretamente e adicionar os domínios da organização que você deseja ser capaz de compartilhar com. Novamente, você precisará fazer isso em ambos os locais.
Compartilhar políticas efetivamente permite controlar quais usuários podem compartilhar seus calendários e com quem. Esta partilha não se limita a itens de calendário. Você pode compartilhar seus contatos também.
Primeiro Compartilhe o calendário. O destinatário pode então optar por adicionar o calendário compartilhado. Seu calendário aparecerá logo com os itens compartilhados.
Se você precisa resolver este problema, um bom lugar para começar é olhar para a URL real. Isso é armazenado na caixa de correio do destinatário. Você pode recuperá-lo com MFCMAPI. Verifique se que o URL é acessível a partir de seus servidores de caixa de correio locais.
Agentes de extensão de cmdlet
**P.**Para cada nova caixa de correio que criamos, nós queremos desabilitar o ActiveSync por padrão. Acesso só deve estar disponível a pedido. No entanto, ao criar uma nova caixa de correio com o cmdlet New-Mailbox, não temos a opção de desabilitar o ActiveSync no momento da criação. Temos de executar um –ActiveSyncEnabled Set-CASMailbox:$ false manualmente após a criação. As pessoas às vezes esquecer essa etapa e, portanto, deixar acesso ActiveSync habilitado para pessoas que não deveriam ter acesso. Você sabe de qualquer maneira para alterar esses padrões globalmente, ou se há alguma outra maneira fácil em torno dele?
**R.**Esta pergunta surge com freqüência. Infelizmente, a resposta é não. Não há nenhuma maneira para alterar esses padrões (tais como acesso Web habilitados por padrão, ActiveSync habilitado por padrão, de litígio desabilitada e assim por diante). Exchange sempre irá configurar os seus gostos codificado.
Felizmente, há uma maneira de contornar essa limitação — com agentes de extensão de cmdlet. O que faz um agente de extensão de cmdlet (também conhecido como um agente de script) é ouvir qualquer comando de câmbio sendo demitido. Se programado para fazê-lo, ele irá executar qualquer comando dado posteriormente ou alterar dados no cmdlet real sendo demitido.
Aqui está um exemplo que se adapte a sua pergunta:
New-Mailbox -Name "Georg Hinterhofer" -Database DB1 -UserPrincipalName hiho22@hihosoft.local –Password $p.password
Isso cria um usuário com todas as configurações padrão no lugar. O agente de extensão de cmdlet detecta que o cmdlet New-Mailbox foi executado e gira automaticamente um segundo cmdlet (aquele que não é visível para você). Ele é executado Set-CASMailbox –identity hiho22 –ActiveSyncEnabled:$ false, definindo configurações de todas as suas necessidades.
Então, como temos o agente instalado e funcionando? Em primeiro lugar, identificar qual ação você deseja definir como o gatilho e a ação que deseja executar quando o gatilho é acionado. Neste caso, é fácil. Cada vez que alguém executa o cmdlet New-Mailbox, você quer fogo até o cmdlet Set-CASMailbox para desabilitar o ActiveSync.
Agora você pode ir e fazer a codificação real. Procure por um arquivo chamado scriptingagentconfig.xml.sample na %ExchangeInstallPath%\bin\CmdletExtensionAgents e copiá-lo. Renomeie a cópia para ler apenas scriptingagentconfig.xml e abri-lo com seu editor favorito. Para este exemplo, modifica o conteúdo do arquivo para algo como isto:
<?xml version="1.0" encoding="utf-8" ?> <Configuration version="1.0"> <Feature Name="DisableEASonNewlyCreatedMailboxes" Cmdlets="new-mailbox"> <ApiCall Name="OnComplete"> if ($succeeded) { $dc = (Get-ADServerSettings).DefaultPreferredDomaincontrollers $user = $provisioninghandler.UserSpecifiedParameters["UserPrincipalName"] set-casmailbox $user -ActiveSyncEnabled:$false -DomainController $dc.item(0) } </ApiCall> </Feature> </Configuration>
Salve o arquivo modificado. Se você tiver mais de um servidor Exchange, você também precisará copiar a cópia modificada do arquivo para cada um desses servidores. Observe também como o Get-ADServerSettings determina o controlador de domínio preferencial para evitar erros relacionados à latência de replicação do Active Directory. Você pode remover esta opção se você tiver apenas um DC no seu ambiente.
Finalmente, você precisará habilitar o agente de script. Esta é uma configuração de toda a organização, então você só precisa executar este vez, não uma vez para cada servidor:
Enable-CmdletExtensionAgent "Scripting Agent"
Verifique se o resultado e pronto. Agora, execute favorito cmdlet New-Mailbox e assistir todos como ActiveSync é automaticamente desativado.
.jpg)
.jpg)
Henrik Walther é um Microsoft Certified Master: Exchange 2007 e MVP em Exchange com mais de 16 anos de experiência na atividade de TI. Ele trabalha como arquiteto de tecnologia para um Microsoft gold partner na Dinamarca e como redator técnico para a Biblioso Corporation (uma empresa norte-americana especializada em gestão de serviços de documentação e localização). Ele também é um fornecedor contratado trabalhando em várias equipes de produto (incluindo equipes do Exchange e Lync) na Microsoft.
Georg Hinterhofer é um Microsoft Certified Master: Exchange 2010. Ele trabalha como engenheiro de campo premier sênior, focando exclusivamente no Microsoft Exchange. Ele baseia-se na Áustria, perto de Viena.