Como monitorar e solucionar problemas com o uso de memória pool paginada no Exchange Server 2003 ou no Exchange 2000 Server

Traduções deste artigo Traduções deste artigo
ID do artigo: 912376 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

o tamanho ou o número de tokens de acesso do cliente pode ser o fator limitante o número de clientes que pode oferecem suporte a um servidor que está executando o Microsoft Exchange Server. Este artigo descreve como os tokens de segurança são alocados em um servidor Exchange para oferecer suporte a conexões de cliente. Além disso, este artigo contém sugestões sobre como monitorar e controlar o uso de memória token.

Cada token de acesso requer alguma memória de kernel do Microsoft Windows. A quantidade varia dependendo de vários fatores. Participação no grupo é um dos fatores mais importantes. O tamanho do token aumenta na proporção direta para o número de membros do grupo.

Os scripts que este artigo contém demonstram uma maneira para contar os tokens de segurança e gerar estatísticas sobre o número de grupos de segurança aos quais os usuários do Exchange pertencem. Essas informações podem ajudar a estimar o tamanho na memória os tokens de acesso estão associados esses usuários.

INTRODUÇÃO

Este artigo descreve como gerenciar proativamente e reduzir o uso de memória de pool paginável que é usada por conexões de cliente para um Exchange servidor. Você pode reduzir o uso de memória de pool paginada, controlando o tamanho e o número de tokens de acesso. Hotfix 912480 diretamente reduz o número de tokens de acesso de cliente usados por um cliente quando ele faz uma conexão para o Microsoft Exchange Server 2003 Service Pack 2 (SP2). O restante do artigo descreve como reduzir o tamanho de token de acesso. Além disso, este artigo descreve outros métodos que você pode usar para controlar, distribuir e otimizar conexões de cliente no contexto de tokens de acesso.

Um hotfix para o Exchange 2003 SP2 está disponível para otimizar o uso de tokens de cliente. Esse hotfix pode reduzir o consumo de memória de token que está relacionado ao clientes MAPI por até um terço. Você deve aplicar esse hotfix somente se estiverem ocorrendo paginável problemas de degradação de memória são causados por símbolo alocações. Para obter mais informações sobre o hotfix 912480, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
912480Um servidor do Exchange Server 2003 que hospeda muitas sessões de cliente do Outlook talvez fique sem memória pool paginada

Mais Informações

Tokens de acesso

Quando uma conta do Windows tenta acessar um Windows protegido recurso, um token de acesso é construído. O token de acesso é usado para determinar se o acesso deve ser concedido e quanto acesso deve ser concedido. Tokens são criados pelo servidor que hospeda o recurso. O servidor consulta os controladores de domínio apropriado para obter as informações de token.

O token de acesso consiste em várias partes de informações, mais notavelmente os identificadores de segurança (SIDs para a conta de usuário e os grupos de segurança aos quais a conta de usuário pertence). Depois que um usuário autentica para um servidor, os SIDs apropriadas estão associados com o usuário e participações em grupos do usuário são colocados em um token de acesso. Um SID é uma seqüência de números que identifica exclusivamente um objeto de segurança Windows ou um grupo de segurança. Para obter mais informações, consulte o documento "Security identificadores Technical Reference". Para exibir este documento, visite o seguinte site da Microsoft:
http://technet2.microsoft.com/windowsserver/en/library/a320b892-f678-490d-adf0-fb97984c2bd71033.mspx
Os SIDs são não mais segredo que os nomes de logon. Os SIDs são identificadores numéricos exclusivos que estão associados com nomes de objeto. O SID permanecerá o mesmo pelo tempo de vida de um objeto do Active Directory. Portanto, o SID pode ser usado para identificar um objeto, independentemente de se alterar outros atributos de objeto conclusivamente.

Cada recurso protegido em um servidor possui uma lista de controle acesso discricional (DACL) associada a ele. A DACL, lista os SIDs que são permitido ou negado acesso ao recurso.

Quando um usuário tenta acessar um recurso protegido, a lista de SIDs no símbolo de acesso do usuário é comparado com a lista de SIDs na DACL do recurso. Se um SID no token corresponder a um SID na DACL do recurso, será concedido acesso apropriado. Você confiável não pode determinar o número de grupos de segurança aos quais uma conta de usuário pertence contando o número de grupos que estão listados na propriedade De membro do objeto de usuário. Isso é devido a quatro fatores a seguir:
  • aninhamento de grupo

    Em domínios de modo nativo do Microsoft Windows 2000 ou domínios de modo funcional do Windows Server 2003, grupos podem ser aninhados com mais flexibilidade que nos domínios de modo misto. Quando um grupo é adicionado ao token do usuário, os SIDs dos grupos aninhados também são adicionados.
  • membros de grupos universais

    Se o domínio de conta de usuário estiver no modo misto, os grupos universais não serão adicionados ao símbolo de acesso. Assim que o domínio ao qual pertence a conta é convertido em modo nativo ou um dos modos de funcionais Windows Server 2003, participações de grupos universais serão adicionadas ao token.
  • histórico SID

    Contas que são migradas de domínios do Microsoft Windows NT 4.0 ou de outros domínios do Active Directory podem ter muitos membros do grupo em seus atributos SIDHistory. Para obter mais informações sobre o histórico SID, visite o seguinte site:
    http://technet.microsoft.com/en-us/library/Bb727125.aspx
    Histórico SID está disponível somente para domínios de conta de usuário que já estão no modo nativo do Windows 2000 ou em modos funcionais do Windows Server 2003. Se o domínio de conta de usuário estiver no modo misto, grupos de histórico SID serão ignorados. Na prática, esses grupos não devem existir.
  • grupos de domínio local

    Se um recurso protegido estiver hospedado em um modo nativo do Windows 2000 ou o domínio de modo funcional do Windows Server 2003, grupos local de domínio no domínio de recurso ao qual a conta de usuário pertence serão adicionados ao token. Por exemplo, suponha que um usuário no domínio A tenta acessar um recurso no domínio B. No modo nativo do Windows 2000 ou em modos funcionais do Windows Server 2003, todos os grupos locais de domínio no domínio B ao qual pertence o usuário serão adicionados ao símbolo de acesso. Grupos locais de domínio em um domínio ao qual pertence o usuário não serão adicionados ao token que é gerado por um servidor no domínio B. Isso ocorre porque o domínio local grupos do domínio A são irrelevante para domínio B.

Cópias de token

Token de acesso do usuário é armazenado no servidor na memória do kernel de pool paginável. A qualquer momento, é provável que ser várias cópias do token de cada usuário na memória. Por exemplo, se um cliente mapeia um compartilhamento em um servidor baseado no Windows Server 2003 usando o comando NET USE , duas cópias do token do usuário serão mantidas no servidor para oferecer suporte a esta conexão.

Cada aplicativo cliente que se conecta a um servidor Exchange é provável que gerar várias cópias do token do usuário, dependendo do aplicativo e sua configuração.

Há uma quantidade finita de memória de pool paginada disponível. Portanto, há um limite para o número de conexões de cliente que pode manter um servidor ao mesmo tempo. Em um servidor baseado no Windows que tenha mais de 1 gigabyte (GB) de memória física instalada, a memória máxima de memória paginável é aproximadamente 350 megabytes (MB). Esse valor pode ser reduzido por ajuste de memória em favor de outros recursos que podem ser em menor de alimentação.

Recomendações de ajustes de memória para um servidor Exchange em larga escala incluem o uso do / 3 GB Boot.ini. Isso reduz a memória máxima de memória paginável para menos de 250 MB. Nesse contexto, um servidor Exchange em larga escala é aquele que hosts milhares de caixas de correio e que tem mais de 1 GB de RAM instalada.

Se você não usar o / 3 GB opção, é provável que os serviços do Exchange Server terão que ser reiniciado periodicamente para desfragmentar a memória virtual. Comerciais Desativar pool paginado memória do kernel para memória de aplicativo adicional é uma compensação vale a pena. No entanto, essa compensação significa que você deve monitorar o uso de memória de pool paginada mais de perto. Para obter mais informações sobre ajuste de memória para o Exchange Server, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
815372Como otimizar o uso de memória no Exchange Server 2003
Além disso, veja a seção "Problemas de controle sem limite de memória" papel "Troubleshooting Exchange Server 2003 desempenho" em branco. Para visualizar este documento em branco, visite o seguinte site:
http://technet.microsoft.com/en-us/library/4b012bda-8711-4617-9239-f3527de884a3.aspx
Cliente tokens são geralmente o consumidor único maior de memória paginável em um servidor do Exchange. Se o token de usuário médio for grande, o consumo de memória paginável provavelmente se tornar um gargalo importante para escalabilidade do Exchange Server.

Como calcular o tamanho de token

Tamanho de token de acesso em bytes pode ser estimado usando a seguinte fórmula:
[x 12 o número de direitos de usuário] + [símbolo sobrecarga] + [44 x número de membros do grupo] = token tamanho em bytes
  • Direitos de usuário incluem direitos como "Fazer logon local"ou "acesso a este computador pela rede". Os direitos de único usuário que são adicionados a um token de acesso são os direitos de usuário que são configurados no servidor que hospeda um recurso protegido. A maioria dos usuários do Exchange Server serão provável que somente duas ou três direitos de usuário no servidor do Exchange. Os administradores podem ter dezenas de direitos de usuário. Cada direito de usuário requer 12 bytes armazená-lo no token.
  • Token de sobrecarga inclui vários campos, como a origem token, tempo de expiração e informações de representação. Para um usuário típico de domínio que não tem acesso especial ou restrições, é provável que estar entre 400 e 500 bytes token sobrecarga. Normalmente, a estimativa de 500 bytes para direitos de usuário e sobrecarga de token é mais do que suficientes.
  • Cada associação de grupo adiciona o grupo SID para o símbolo juntamente com 16 bytes adicionais para atributos associados e informações. O tamanho máximo possível para um SID é 68 bytes. No entanto, é raro para um SID ser essa grande. No Windows Server 2003 e em versões anteriores do Windows, o SID típico para um usuário ou um grupo é 28 bytes de comprimento. Portanto, cada grupo de segurança aos quais um usuário pertence normalmente adiciona 44 bytes ao tamanho de token do usuário.

Alocação de memória de token

Se um token for menor do que 4 quilobytes (KB), a quantidade de memória do kernel que está alocada para ele é exatamente o que é necessário para armazenar o token. Por exemplo, considere um usuário típico que pertence a grupos de segurança 30. Usando a fórmula que é mencionada na seção "Como calcular o tamanho de token", token deste usuário será cerca 1,820 bytes (500 bytes de sobrecarga + 44 bytes x 30 grupos = 1,820).

Mas se um token for mesmo ligeiramente maior do que 4 KB (4.096 bytes), a quantidade de memória é alocada por cópia saltará para exatamente 8 KB (8.192 bytes). Se um token for mesmo ligeiramente maior do que 8 KB, a alocação de memória saltará para exatamente 12 KB. Portanto, sempre que os tamanhos de token cruza dentre esses limites de 4 KB críticas, há um salto repentino no uso de memória de pool paginada.

Geralmente, um usuário que pertence a grupos de segurança mais de 80 será próximo ou irá ultrapassar o limite de 4 KB. Portanto, o usuário exigirá um token de 8 KB. Se um usuário pertencer a mais de 170 grupos, o token de provavelmente exigir 12 KB e assim por diante.

O exemplo a seguir ilustra como é importante para tamanho de token de monitor e o controle cliente médio. Considere um Exchange 2003 Service Pack 2 servidor no qual todos os clientes usam o Microsoft Office Outlook 2003 no modo de cache. Um cliente de modo em cache típico faz com que sete ou oito cópias de seu token a ser gerado em um computador com Windows Server 2003. Se o token de cliente médio é exatamente 4 KB, cada cliente no modo em cache requer até 32 KB de memória de pool paginada.

Observação O hotfix de serviço do Microsoft Exchange Information Store descrita na seção "Introdução" pode reduzir o número de cópias de token para cada usuário de modo em cache para quatro ou cinco em vez de sete ou oito. Esse hotfix está programado para ser incluída no Microsoft Exchange Server 2003 Service Pack 3.

Se o servidor é configurado usando o / 3 GB opção, haverá cerca de 250 MB de memória de pool paginável alocada no servidor. Recomendamos que o consumo típico de memória paginável para o servidor deve ser mais de 200 MB. Você deve reservar memória suficiente para picos de carga do servidor. Se paginada consumo geralmente é mais de 220 MB de memória de pool, você deve tomar medidas imediatas para reduzir a carga no servidor.

Pressupor que 150 MB de memória de pool paginada esteja disponível para tokens de cliente do Exchange Server. Se cada token de cliente 4 KB, o servidor pode confortavelmente suporte mais de 4.500 usuários simultâneos de modo em cache Outlook antes de usar token se tornará um afunilamento. Observe que a aplicação de hotfix 912480 aumentaria esse máximo para os usuários de modo em cache 7,300. Se tamanho de token fosse saltar para 8 KB, o número máximo de clientes deve ser reduzido pela metade, independente da hotfix 912480 foi aplicada.

Observação Se o Outlook 2003 é executado no modo online, normalmente haverá três ou quatro cópias token para cada cliente independente da hotfix 912480 foi aplicada.

Sintomas de degradação da memória do kernel

Se recursos de memória kernel estiverem próximo ao esgote, o servidor se torna lento ou recusa solicitações adicionais e conexões. Aplicativos podem falhar inesperadamente. Além disso, tentativas de conexão com o servidor afetado podem retornar erro 1450, "Recursos de sistema insuficientes". Em casos extremos, o servidor pode exibir uma mensagem de erro em uma tela azul e parar de responder.

Além disso, os seguintes eventos podem ser registrados no log do sistema:

IDENTIFICAÇÃO de evento: 2019
Origem: servidor
Descrição: O servidor não pôde alocar do sistema não-paginável porque a memória estava vazia.

IDENTIFICAÇÃO de evento: 2020
Origem: servidor
Descrição: O servidor não pôde alocar memória o paginável do sistema porque estava vazia.

IDENTIFICAÇÃO de evento: 2000
Origem: servidor
Descrição: Chamada do servidor para um serviço do sistema falhou inesperadamente.

Se uma insuficiência de memória paginável é transitória, o servidor provavelmente irá recuperar. Aplicativos podem ser um pouco resistentes a temporária insuficiência de memória. No entanto, nenhum aplicativo pode executar para sempre se solicitações de recursos críticos não são satisfeitas. Se a falta de memória paginável durar muito tempo, é provável que disparar afunilamentos em cascata. Nesse caso, o servidor provavelmente terá que ser reiniciado para torná-lo funcional novamente.

Sob carga padrão, deve haver aproximadamente 50 MB de memória pool paginada disponível. Se você tiver menos de 30 megabytes livres, você deve tomar medidas imediatas para reduzir a carga no servidor.

Memória de pool paginável é alocada estaticamente durante Windows inicialização. O pool não pode ser aumentado sem reconfigurar e reiniciar o servidor. A quantidade de memória pool paginada disponível depende de vários fatores. Esses fatores incluem opções de inicialização como / USERVA e / 3 GB , configurações do Registro e RAM física.

Como reduzir o tamanho de tokens de acesso do usuário

Você pode usar três estratégias a seguintes para reduzir o tamanho de token:
  • Reduza o número de grupos de segurança para o qual cada usuário pertence.
  • Hospeda servidores Exchange em um domínio diferente de usuários que se conectam a servidores do Exchange.

    Essa estratégia pode reduzir o tamanho de tokens de usuário de remoção de grupos de domínio local para o domínio de conta de usuário do token é apresentado ao servidor do Exchange. Isso funciona porque o domínio local grupos de um domínio não são mantidos no token é gerado em um servidor em um domínio diferente.
  • Quando possível, converta grupos de segurança para grupos de distribuição.

    Tamanho de token é aumentado pela participação em grupos de segurança, não grupos de distribuição. Os usuários podem pertencer a milhares de grupos de distribuição que não afetam o tamanho de token. Se um grupo não estiver sendo usado para negar ou conceder acesso a recursos, ele deve ser um grupo de distribuição, não um grupo de segurança.

Como reduzir o número de tokens de acesso na memória no servidor

Assim que você tenha reduziu o tamanho token típico para o mínimo prático, a próxima etapa é gerenciar o número de conexões simultâneas que são feitas para o servidor. Você pode gerenciar o número de conexões simultâneas, usando os seguintes métodos:
  • Restringir aplicativos e clientes não autorizados.

    Cada cliente pode fazer várias conexões para o servidor. Além disso, os clientes diferentes fazem números diferentes de conexões com base em uma grande variedade de fatores. Talvez você não ainda tenha uma lista completa de todos os clientes que se conectar ao servidor. Os usuários podem instalar suplementos do Outlook que fazem conexões adicionais. Os desenvolvedores podem executar aplicativos que fazer muitas conexões ou que não são desligados conexões quando elas estiverem concluído. Portanto, você deve analisar que tipos de clientes se conectar ao servidor e quais tipos de efeitos que eles têm no uso de memória do kernel. Para obter mais informações, consulte a seção "Como exibir alocação token de tamanhos de".
  • Remova o armazenamento de pasta pública do servidor. Em seguida, direcione clientes para pastas públicas em um servidor diferente.

    Esta ação elimina conexões de pasta pública que são feitas por clientes.
  • Remova pastas públicas específicas que conta para muitas conexões de cliente.

    Bons candidatos à remoção são Schedule + Free/Busy pasta e o catálogo de endereços offline. Os clientes devem fazem conexões adicionais para essas pastas quando eles agendar compromissos ou baixar o catálogo de endereços.
  • Adicione réplicas de pastas públicas muito acessadas para distribuir o número de clientes que se conectam a eles em vários servidores.
  • Instale servidores de pasta pública dedicado para eliminar todas as conexões de pasta pública de servidores de caixa de correio.
  • Distribua uniformemente pesado conexão os usuários em vários servidores. É provável que sejam aqueles que têm vários computadores ou dispositivos e aqueles que são os usuários móveis os usuários de conexão pesado.
  • Distribua os usuários que têm tokens de segurança grandes em vários servidores.
  • Aplica o hotfix 912480 para a otimização do token. Para obter mais informações sobre o hotfix 912480, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
    912480Um servidor do Exchange Server 2003 que hospeda muitas sessões de cliente do Outlook talvez fique sem memória pool paginada

Como monitorar a memória paginável em um servidor do Exchange

Geralmente, você deve ter 50 MB de memória de pool paginável livre disponível em típica do servidor carregar condições. Além disso, você deve ter 30 MB livre em cargas de pico.

É fácil determinar quanta memória de pool paginável atualmente está sendo usada. Gerenciador de tarefas exibe paginada uso de pool na área de Memória Kernel na guia desempenho . Você também pode monitorar o uso de memória de pool paginada com o tempo com o contador Memória\bytes de pool paginável no Monitor do sistema Windows.

Um servidor Exchange está configurado para usar o / 3 GB opção de inicialização terá um tamanho de memória máximo do pool paginado possíveis de cerca de 250 MB. Além disso, esse servidor terá um máximo de não-paginável--memória de pool de 128 MB. Sem o / 3 GB alternar, os valores máximos são 350 MB de memória de pool paginada e 256 MB de memória de pool não paginável.

Portanto, uma típica Exchange em larga escala servidor deve usar mais de 200 MB de memória paginável memória de pool em condições normais. Uso de memória de pool paginável de mais de 220 MB requer atenção imediata.

Se você estiver dentro desses limites, e o servidor está relatando erros relacionados a degradação da memória paginável, é provável que a alocação de memória paginável inicial seja menor que o esperado. Isso pode ser causado por hardware demandas, por drivers de dispositivo, ou por ajuste de memória que reduz inicial paginada alocação de memória de pool ainda mais. Configurações de memória grande, por exemplo, mais de 4 GB de RAM física, são a causa mais comum desse problema.

Cada byte de RAM física instalada em um servidor requer alguma memória de kernel para endereçar e gerenciá-lo. Quanto mais RAM instalada, mais espaço de endereço do kernel deve ser reservado para ele. Espaço de endereço pode ser emprestado da memória de pool paginado para atender a essa demanda.

É recomendável instale mais de 4 GB de RAM física em um servidor dedicado à execução de Exchange Server 2003. Exchange Server irá fazer uso eficiente de até 4 GB de RAM. No entanto, Exchange Server não irá tirar proveito de RAM adicional mesmo se ele estiver disponível. Servidores que oferecem suporte o recurso acesso de memória adicionar também podem causar reduções significativas na disponibilidade de memória de pool paginável. Mesmo se mais de 4 GB de RAM estiver instalado, o espaço de endereço pode ser reservado para o máximo teórico de hot-add RAM que pode ser instalado.

Você pode usar um depurador de kernel para exibir o tamanho da memória de pool paginada inicial e outras alocações de memória do kernel.

importante Comandos que podem ser usados durante uma sessão de depuração do kernel podem fazer com que o sistema ficar instável ou parar. É recomendável que você interrompa todos os serviços do Exchange Server antes de iniciar uma sessão de depuração do kernel e reiniciar o servidor após a sessão.

Configurando uma sessão para o Windows 2000 de depuração do kernel tradicional pode ser uma tarefa complexa. Esta tarefa normalmente exige um computador extra, cabeamento especializados e uma reinicialização do servidor.

Como alternativa, o utilitário LiveKD da Sysinternals pode ser usado para iniciar uma sessão do console de servidor de depuração do kernel. LiveKD não requer que você reinicie o servidor. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
894067A ferramenta desempenho não mostra com precisão as entradas de tabela de página de sistema livre disponíveis no Windows Server 2003
Para o Windows Server 2003, o depurador de kernel KD oferece suporte de depuração diretamente de console do servidor sem preparação especial ou hardware. Para obter as ferramentas de depuração para Windows, visite o seguinte site:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Inicie o depurador usando o comando KD.EXE - KL . Em seguida, execute o ! vm comando para exibir a memória máxima de memória paginável. Por exemplo, execute os seguintes comandos:
KD.EXE - KL
! VM

Como exibir os tamanhos de alocação de token

Outlook não é o cliente só pode se conectar a um Exchange Server banco de dados. Suplementos do Outlook, mecanismos de pesquisa da área de trabalho que incluem email pesquisa funcionalidade, mensagens instantâneas clientes, e aplicativos personalizados podem todos fazer conexões adicionais e fazer com que a geração de token de cópias adicionais.

Você pode verificar o efeito de um cliente ou aplicativo usando o utilitário Poolmon.exe em um ambiente de laboratório. Para fazer isso, execute as seguintes etapas:
  1. Gerar um laboratório isolado organização do Exchange.
  2. Instale o Poolmon no servidor Exchange. Para obter mais informações sobre como configurar Poolmon.exe, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
    177415Como usar o Monitor do pool de memória (Poolmon.exe) para solucionar problemas de memória kernel vazamentos
  3. Executar Poolmon.exe com o / iToke opção ( Poolmon /iToke ). Observe que o / iToke parâmetro diferencia maiúsculas de minúsculas. Isso irá configurar Poolmon.exe para exibir somente as alocações de token. Você também pode usar esse comando em um servidor de produção para exibir alocações de token total em tempo real.
  4. Configure uma conta de usuário do Active Directory semelhante à que o usuário típico do Exchange Server em seu ambiente. Ou seja, configure uma conta de usuário que tem um número equivalente de membros do grupo de segurança, um perfil permissões semelhantes e assim por diante.
  5. Faça logon no Exchange Server como o usuário de teste com os aplicativos de cliente e configurações que você deseja testar. Aguarde alguns minutos após o logon para o aplicativo cliente para carregar e estabilizar completamente.
  6. Sai do aplicativo cliente quando você observar a alteração no token bytes em Poolmon.exe. Talvez você precise fazer essa várias vezes para obter uma leitura precisa de quantos bytes são liberados quando você sai do cliente. Outras alocações de token podem ser criadas ou destruídas ao mesmo tempo durante o teste.
Observação Se você alterar a conta de usuário, como, adicionando ou excluindo membros do grupo de segurança, você deve fazer logoff da conta do Windows e, em seguida, logon novamente antes que essas alterações serão refletidas no token de acesso.

Como fazer auditoria participações em grupos

Os exemplos de script a seguir contêm parâmetros de linha de comando e as instruções na parte superior de cada script. Você pode colar os scripts no bloco de notas e, em seguida, salvá-los como arquivos .vbs. Não salve os arquivos como arquivos .txt.
  • O script Groups.vbs imprime nomes de conta de usuário de caixa de correio Exchange Server e os grupos de segurança aos quais eles pertencem. Além disso, a impressão contém uma coluna separada que lista os grupos de SIDHistory. Você pode restringir o script a um único servidor Exchange ou obter um relatório para vários servidores do Exchange usando um caractere curinga.

    Observação Você não pode usar um caractere curinga (1) para acessar todos os servidores do Exchange. Você deve fornecer pelo menos um nome de servidor parcial. Por exemplo, você pode usar uma seqüência de caracteres que é semelhante a seguinte:
    EXCH - HQ *
  • O script Groups_statistics.vbs fornece uma exibição com base em texto histograma que mostra quantos usuários pertencem a 50 grupos, grupos de 60, 70 grupos e assim por diante. Isso pode ajudar você a determinar o tamanho de token médio provavelmente para usuários.
Consulte "Como calcular o tamanho de token" e "Token alocação de memória" seções para detalhadas informações sobre tamanhos de token.

Scripts

Groups.vbs
'==============================================================================
' NAME: Groups.vbs
' AUTHOR: Kyryl Perederiy, Microsoft IT, MACS Engineering
' DATE  : 12/15/2005
' COMMENT: The script runs through all mailbox enabled user objects in the 
' forest and calculates the number of security groups and groups in SID 
' history for each object. User objects can be filtered by Exchange home server.
' PARAMETERS: <output file> <GC Domain Controller> <Domain Naming Context> [<Exchange Server(s)>]
' EXAMPLE: CSCRIPT groups.vbs groups.tsv EXCH-DC-01 dc=root,dc=company,dc=com EXCH-MBX-*
' Version 1.0
'==========================================================================
On Error Resume Next
Set strArgs = WScript.Arguments
Set fso = CreateObject("Scripting.FileSystemObject")
Set fileStream = fso.OpenTextFile(strArgs(0), 2, True, TristateTrue)
fileStream.WriteLine "DN	Mail	Domain	Login	Server	GRP	SIDHISTORY"

Count=0
DCS = strArgs(1) ' Domain Controller
strDomainNC = strArgs(2) ' Domain Naming Context for the forest
strFilter = "(&(mail=*)(objectCategory=person)(objectClass=user)" &_
			"(msExchHomeServerName=*" & strArgs(3) & "))" 'Mail users search filter

Set oConnection = CreateObject("ADODB.Connection") ' Setup the ADO connection
Set Com = CreateObject("ADODB.Command")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "ADs Provider"
Set Com.ActiveConnection = oConnection ' Create a command object on this connection
Com.CommandText = "<LDAP://" & DCS & ":3268/" & strDomainNC & ">;" &_
					strFilter & ";distinguishedName,mail,sAMAccountName," &_
					"msExchHomeServerName,SIDHistory,homeMDB;subtree"

' Set search preferences
Com.Properties("Page Size") = 1000
Com.Properties("Asynchronous") = True
Com.Properties("Timeout") = 120 ' seconds
set oRecordSet = Com.Execute

oRecordSet.MoveFirst

While Not oRecordset.Eof

	Count=Count+1
	DN = oRecordset.Fields("distinguishedName").Value
	Mail = oRecordset.Fields("mail").Value
	Server = oRecordset.Fields("msExchHomeServerName").Value
	Server = Mid(Server,InStrRev(Server,"=")+1)
   	Domain = Split(DN,",DC=")
	Login = UCase(Domain(1)) & "\" & oRecordset.Fields("sAMAccountName").Value
	
	set oDirObject = GetObject("LDAP://" & DCS & "/" & replace(DN,"/","\/"))

	' tokenGroups is a computed attribute that contains the list of SIDs 
	' due to a transitive group membership expansion operation on a given user
	oDirObject.GetInfoEx ARRAY("tokengroups"),0 
	
	' Size of the array correspond to the number of groups
	GROUPS = ubound(oDirObject.GetEx("tokengroups"))+1

	If IsNull(oRecordSet.Fields("SIDHistory").Value ) Then 
		SIDHIST = "0" 
	Else 
		SIDHIST = ubound(oDirObject.GetEx("sidhistory"))
	End If

	WScript.Echo Count & CHR(9) & DN & CHR(9) & GROUPS
	fileStream.WriteLine _
		DN & CHR(9) &_
		Mail & CHR(9) &_
		UCase(Domain(1)) & CHR(9) &_
		Login & CHR(9) &_
		Server & CHR(9) &_
		GROUPS & CHR(9) &_
		SIDHIST & CHR(9)

	oRecordset.MoveNext

Wend

WScript.Echo "Total: " & Count & " users found on the server(s): " & strArgs(3)
Groups_statistics.vbs
'==========================================================================
' NAME: groups_statistics.vbs
' AUTHOR: Kyryl Perederiy, Microsoft IT, MACS Engineering
' DATE  : 12/15/2005
' COMMENT: The script runs through all mailbox enabled user objects in the 
' forest and calculates statistical distribution for group membership.
' PARAMETERS: <output file> <GC Domain Controller> <Domain Naming Context> [<ExchHomeServerName>]
' EXAMPLE: CSCRIPT groups_statistics.vbs groups_statistics.tsv EXCH-DC-01 dc=root,dc=company,dc=com EXCH-MBX-0*
' Version 1.0
'==========================================================================
On Error Resume Next
Dim GROUPS(100)
Set strArgs = WScript.Arguments
Set fso = CreateObject("Scripting.FileSystemObject")
Set fileStream = fso.OpenTextFile(strArgs(0), 2, True, TristateTrue)
fileStream.WriteLine "Groups" & CHR(9) & "Users"

Count=0
DCS = strArgs(1) ' Domain Controller
strDomainNC = strArgs(2) ' Domain Naming Context for the forest
strFilter = "(&(mail=*)(objectCategory=person)(objectClass=user)" &_
			"(msExchHomeServerName=*" & strArgs(3) & "))" 'Mail users search filter

Set oConnection = CreateObject("ADODB.Connection") ' Setup the ADO connection
Set Com = CreateObject("ADODB.Command")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "ADs Provider"
Set Com.ActiveConnection = oConnection ' Create a command object on this connection
Com.CommandText = "<LDAP://" & DCS & ":3268/" & strDomainNC & ">;" &_
					strFilter & ";distinguishedName,sAMAccountName;subtree"

' Set search preferences.
Com.Properties("Page Size") = 1000
Com.Properties("Asynchronous") = True
Com.Properties("Timeout") = 120 'seconds
set oRecordSet = Com.Execute

oRecordSet.MoveFirst

While Not oRecordset.Eof

	Count=Count+1
	set oDirObject = GetObject("LDAP://" & strArgs(1) & "/" &_
		replace(oRecordset.Fields("distinguishedName").Value,"/","\/"))
	oDirObject.GetInfoEx ARRAY("tokengroups"),0
	GRP = ubound(oDirObject.GetEx("tokengroups"))+1
	GROUPS(Int(GRP/10)) = GROUPS(Int(GRP/10)) + 1
	WScript.Echo Count & CHR(9) & oRecordset.Fields("sAMAccountName").Value & CHR(9) & GRP
	oRecordset.MoveNext
Wend
WScript.Echo "Total: " & Count & " users found"
WScript.Echo "See " & strArgs(0) & " for details..."
For i=0 to 100
	fileStream.WriteLine i*10 & CHR(9) & GROUPS(i)
Next

Os produtos de terceiros mencionados neste artigo são fabricados por empresas que são independentes da Microsoft. A Microsoft não oferece garantia, implícita ou não, em relação ao desempenho ou à confiabilidade desses produtos.

Propriedades

ID do artigo: 912376 - Última revisão: sexta-feira, 16 de novembro de 2007 - Revisão: 2.4
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange 2000 Server Standard Edition
Palavras-chave: 
kbmt kbhowto kbinfo KB912376 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 912376

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com