Perguntas e respostas do ExchangeTempos limites do OWA, solução de problemas de cmdlet e muito mais

KC Lemson and Nino Bilic

P: Nós migramos recentemente do Exchange Server 2003 para o Exchange Server 2007. Estamos recebendo reclamações de que o tempo limite do Outlook® Web Access (OWA) está se esgotando para Usuários Restritos que tenham selecionado a opção "Este é um computador particular" ao fazer logon no OWA 2007. Que comando do Shell de Gerenciamento do Exchange é apropriado para verificar o tempo limite para computadores particulares?

R: Vamos voltar um pouco. Primeiro explicarei por que há uma seleção separada para um computador particular, o que não existe para um computador público (consulte a Figura 1), e mostrarei como essas opções se comportam de modo diferente. A intenção é permitir que o usuário informe ao Exchange qual nível de segurança é necessário – se você está fazendo logon no OWA usando um quiosque público de um aeroporto, por exemplo, ou seu computador doméstico. O administrador do Exchange pode optar por tratar esses tipos de sessão de maneira diferente. Por exemplo, fazendo com que o tempo limite de sessões autenticadas se esgote mais rápido em computadores públicos (em questão de minutos) do que em computadores particulares (até três dias, no máximo). O administrador também pode definir outras configurações de forma diferente, dependendo da seleção do usuário. Por exemplo, que o acesso a bibliotecas de documentos do SharePoint® e compartilhamentos de arquivos do Windows® seja permitido apenas para o logon particular. Obviamente, isso depende de o usuário especificar a opção correta. Caso os administradores não confiem na capacidade dos usuários de tomar a decisão certa, poderão atribuir a cada opção os mesmos valores de tempo limite e outras opções de configuração.

Figura 1** Os tipos de sessão de computador particular e público possibilitam diferentes configurações de tempo limite e outras opções de configuração **(Clique na imagem para aumentar a exibição)

A opção em questão é uma que transferimos do Exchange 2003, quando a autenticação baseada em formulários foi introduzida no OWA. (Nota histórica: a primeira implementação de autenticação baseada em formulários foi projetada em parte por uma brilhante gerente de programas. Não vou revelar sua identidade, mas posso dizer que, mais tarde, ela conquistou fama e fortuna escrevendo uma coluna bimensal da TechNet Magazine.)

Na verdade, a configuração é armazenada no Registro, mas, como o Windows PowerShell™ possui uma interface para atualizar o Registro, é possível definir essa configuração usando o Shell de Gerenciamento do Exchange. O exemplo a seguir define o tempo limite como 1.440 minutos (um dia) quando os usuários escolhem a opção de computador particular durante o logon:

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

Obviamente, como a configuração está no Registro, você mesmo pode atualizar a chave usando regedit. Nesse caso, escolha:

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

De qualquer modo, será preciso reiniciar o IIS para ter certeza de que o OWA selecionará a nova configuração. Você pode fazer isso selecionando Iniciar | Executar e depois executando iisreset /noforce.

P: Incentivamos os funcionários que usam os clientes MAPI completos do Outlook a arquivar todos os itens de menor urgência em arquivos de pastas particulares (.pst). Entretanto, os itens arquivados não ficam disponíveis quando os usuários fazem logon no Outlook Web Access em casa. Como podemos disponibilizar esses arquivos .pst através da interface do OWA?

R: Lamento dizer que não há suporte no OWA para o acesso a arquivos .pst. Desde o início, o OWA foi projetado para ser um cliente somente online. Trabalhamos muito para não deixar nenhum traço de dados pessoais no computador local. Isso inclui recursos como o mecanismo de logoff seguro oferecido pela primeira vez no Exchange 2003 e a Exibição de Documento WebReady no Exchange 2007, que garante que cópias de anexos armazenadas em cache não sejam deixadas no disco rígido. Por isso, o acesso a arquivos .pst a partir do OWA não se enquadra no nosso objetivo de torná-lo um cliente simples de implantar e somente online.

Isso posto, o uso de arquivos .pst em geral é um cenário interessante que gostaríamos de discutir. Há alguns meses, tive uma reunião com um cliente cujos usuários possuíam cotas de caixa de correio com cerca de 200 MB e quase todos tinham pelo menos um arquivo .pst, se não mais. Como essa organização tinha uma diretiva que permitia o apagamento de dados e a substituição de computadores de usuários com esforço mínimo, era solicitado que todos os usuários armazenassem seus arquivos .pst em um compartilhamento de rede. O backup desse compartilhamento de rede, por sua vez, era feito por um sistema central.

Em primeiro lugar, existem problemas conhecidos ao acessar arquivos .pst a partir de compartilhamentos de rede. Assim como o OWA foi projetado desde o início para ser somente online, a finalidade original dos arquivos .pst era armazenamento local. Não importa a qualidade da sua rede: ela está sujeita a latência e outros problemas que podem tornar complicado o armazenamento remoto de dados (que também precisam ser acessados por usuários ao mesmo tempo).

Em segundo lugar, essa organização tinha uma cota de caixa de correio bastante pequena (admito que somos privilegiados por termos uma caixa de correio corporativa de 2 GB, aproximadamente) porque não queria ter todos esses dados no Exchange, já que seria responsável por fazer o backup deles. Entretanto, com usuários armazenando os dados em arquivos .pst em um compartilhamento de rede do qual era feito backup, o trabalho dos administradores não diminuía em nada. Na verdade, provavelmente era até maior devido a vários fatores, como: nenhum armazenamento de cópia única em vários arquivos .pst; custos de suporte técnico relacionados a problemas com arquivos .pst (como senhas esquecidas e flocosidade geral da rede); dificuldade de limpar mensagens em arquivos .pst após um ataque de vírus; dificuldade de detectar mensagens em arquivos .pst quando surge uma questão legal; sobrecarga de manter um sistema de backup diferente; e assim por diante.

Por isso, insistimos para que você considere todos os custos envolvidos nas suas decisões de configuração. É possível que você descubra que eles podem atingir cifras bastante significativas e que uma outra configuração pode acabar sendo uma escolha melhor.

P: Estou tendo problemas com um comando do Shell de Gerenciamento do Exchange. Ele simplesmente não está funcionando. O que há de errado?

R: Não podemos responder essa pergunta, mas podemos lhe dizer que, para obter a melhor ajuda possível – onde quer que esteja procurando – você deve usar o cmdlet interno no Windows PowerShell chamado start-transcript para registrar em log os comandos que está tentando e os resultados obtidos. Isso permitirá que você cole os detalhes exatos em uma mensagem de email, postagem de blog ou pergunta em um fórum.

Abra uma sessão do Shell de Gerenciamento do Exchange e digite start-transcript, como mostra a Figura 2. O Shell de Gerenciamento do Exchange iniciará automaticamente o registro em log de todos os futuros comandos em um arquivo de texto como o mostrado na Figura 3 (não se preocupe: o aplicativo lhe informará o local do arquivo de texto). Para interromper o registro em log, basta digitar stop-transcript.

Figura 2** Use o cmdlet start-transcript para registrar em log os comandos que você usar e seus resultados  **(Clique na imagem para aumentar a exibição)

Figura 3** O Windows PowerShell salva uma transcrição dos comandos que você usar e a armazena em um arquivo .txt **(Clique na imagem para aumentar a exibição)

Ter a lista completa de comandos usados e os resultados retornados ajuda bastante a quem for solucionar seu problema. Porém, antes de compartilhar o log com alguém que você não conhece ou não confia, examine-o em busca de dados confidenciais ou sigilosos que possam ter sido retornados.

P: Vejo que a instalação do Exchange 2007 cria uma OU (unidade organizacional) no domínio raiz. Ela se chama Grupos de Segurança do Microsoft Exchange e contém cinco novos grupos de segurança do Exchange 2007. É possível mover esses grupos para outra OU? E para outro domínio?

R: Essa pergunta se refere a cinco USGs (grupos de segurança universais) que foram criados no domínio raiz durante a etapa de preparação do Active Directory. São eles:

• Administradores da Organização do Exchange
• Administradores de Destinatários do Exchange
• Administradores Somente para Exibição do Exchange
• Servidores Exchange
• ExchangeLegacyInterop

Na época do Exchange 2000 e do Exchange 2003, a capacidade de mover os grupos de segurança padrão (Servidores de Domínio do Exchange e Exchange Enterprise Servers) era limitada. Uma forma melhor de dizer isso é que você podia movê-los, mas danificaria outros itens no processo. (Consulte support.microsoft.com/kb/260914 para obter mais detalhes sobre esse problema.) Como você pode ver, esse recurso era de fato muito limitado.

No Exchange 2007, as coisas são diferentes. Os cinco grupos padrão podem ser movidos, tanto para outra OU dentro do mesmo domínio como para um domínio diferente.

Caso você "perca" esses cinco grupos e não saiba para onde os moveu (qual OU ou domínio), poderá verificar o valor do atributo otherWellKnownObjects neste contêiner:

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

A localização dos grupos é atualizada nesse atributo à medida que eles são movidos, permitindo que você descubra onde estão. Legal!

P: Descobri um grupo de Segurança Global chamado "Servidores de Domínio de Instalação do Exchange" no meu domínio. Para que ele serve?

R: Você está definitivamente controlando seu Active Directory®. De fato, haverá um grupo chamado Servidores de Domínio de Instalação do Exchange em cada domínio que tenha servidores Exchange 2007 instalados. Esse grupo é criado na OU Objetos do Sistema do Microsoft Exchange (MESO). Se você examiná-lo, verá que ele passará a ser membro do grupo Servidores Exchange do domínio raiz, que é um Grupo de Segurança Universal.

Resumindo, Servidores de Domínio de Instalação do Exchange é um grupo usado para contornar possíveis ciclos longos de replicação do Active Directory caso você esteja executando a instalação do Exchange 2007 em um dos domínios filho. Por exemplo, digamos que você tenha um domínio raiz chamado Root, um domínio filho chamado Child e um domínio filho de Child chamado Grandchild. (Sabemos que o esquema de nomeação é brilhante! Consegue adivinhar quais são as nossas senhas?)

Para começar a configurar o Exchange 2007 nessa organização, primeiro você precisa estender o esquema e preparar seu domínio Root. Isso cria os cinco USGs originais que abordamos na resposta anterior.

Em seguida, digamos que você precisa executar a instalação no domínio Grandchild. Para poder iniciar os serviços do Exchange 2007 no domínio local, a instalação coloca uma conta de computador da máquina do Exchange 2007 no grupo Servidores Exchange a partir do domínio Root. Mas, como agora você está no domínio Grandchild, a associação do grupo Servidores Exchange pode demorar um pouco para ser replicada.

Servidores Exchange é um grupo universal e sua associação é replicada através da floresta. Devido à possível latência de replicação, talvez a instalação no domínio Grandchild não consiga iniciar serviços, já que as permissões não seriam replicadas até o término da instalação. É por essa razão que, quando o primeiro servidor Exchange 2007 é configurado em um domínio, ele cria o grupo Servidores de Domínio de Instalação do Exchange no domínio local.

Como parte da instalação, a conta de computador do Exchange será colocada como membro desse grupo. Uma associação nesse grupo dá permissões suficientes aos serviços para serem iniciados no final da instalação, mesmo que a associação no grupo Servidores Exchange não tenha sido ainda replicada do domínio Root. Observe que a replicação de domínio local geralmente é mais rápida que a entre domínios.

P: A documentação do Exchange 2007 informa que eu deveria estar executando a instalação com a opção /PrepareLegacyExchangePermissions, mesmo antes de estender meu esquema para o Exchange 2007. Por que isso? (E vocês não poderiam ter feito o nome dessa opção mais longo?)

R: Ficamos satisfeitos em saber que você está lendo a documentação antes de executar a instalação. Gostou dela?

Embora tenha um nome comprido, a opção /PrepareLegacyExchangePermissions (ou /pl, para abreviar) concede aos RUSes (Serviços de Atualização de Destinatário) do Exchange 2000 e do Exchange 2003 as permissões necessárias para gravar nos conjuntos de propriedades Informações do Exchange e Informações Pessoais. Durante o processo de extensão do esquema do Exchange 2007, diversos atributos (como proxyAddresses) são movidos do conjunto de propriedades Informações Públicas do Active Directory para o conjunto de propriedades Informações do Exchange. Por padrão, os RUSes do Exchange 2000 e do Exchange 2003 não têm os direitos necessários para gravar no conjunto de propriedades Informações do Exchange. Na vida real, isso significa que, se você executar primeiro a extensão de esquema do Exchange 2007, danificará os RUSes do Exchange 2000 e do Exchange 2003 porque eles não conseguirão carimbar nenhum recipiente novo! (Caso você queira ler mais sobre conjuntos de propriedades, visite nosso blog em msexchangeteam.com.)

Desse modo, é muito importante que você execute a opção /pl antes que o esquema seja estendido para o Exchange 2007. Você também deve verificar se essa alteração será replicada em todos os domínios que tenham contêineres do Exchange 2000 ou do Exchange 2003 (assim os RUSes existirão para esses domínios). Se novos domínios forem adicionados à floresta posteriormente e você precisar colocar RUSes do Exchange 2000 e do Exchange 2003 neles, deverá executar a opção /pl nesses domínios também.

Falando nisso, ao executar uma opção /pl pela primeira vez, tudo será muito mais simples se você executá-la com uma conta que tenha direitos de Administração de Empresa. Em seguida, a instalação do domínio raiz identificará quais domínios precisam ter a /pl executada e a executará em todos. Se você não estiver usando uma conta de Administração de Empresa, precisará executar a opção /pl usando uma Administração do Domínio para cada domínio individualmente. Felizmente, a documentação do Exchange 2007 apresenta todos os requisitos de permissões.

E, por último, você perguntou se não poderíamos ter dado um nome mais longo a essa opção. Tente repetir /PrepareLegacyExchangePermissions três vezes seguidas:

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

Pensamos em chamá-la de /Prepare-LegacyExchangePermissionsWOW­ThisIsaReallyLongname, mas então optamos por /PrepareLegacyExchangePermissions, que é um nome mais curto e amigável.

Falando sério, nós simplesmente inventamos um nome. Mas você pode usar /pl, que é muito menor. É verdade. Eu juro!

KC Lemson é gerente de experiência do usuário do Exchange Server. Ela gasta seu tempo livre esperando emails que lhe digam onde deve investir a poupança-educação de seus filhos.

Nino Bilic, responsável técnico, está ocupado no controle de quantos jogos de Halo ele consegue escapar durante um dia de trabalho típico.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..