Come monitorare e risolvere i problemi relativi l'utilizzo di memoria di riserva di paging in Exchange Server 2003 o in Exchange 2000 Server

Traduzione articoli Traduzione articoli
Identificativo articolo: 912376 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

la dimensione o di un numero di token di accesso client può essere il fattore limitante nel numero di client che un server che esegue Microsoft Exchange Server in grado di supportare. Questo articolo viene descritto come il token di protezione vengono allocati su un server di Exchange per supportare le connessioni client. Inoltre, in questo articolo contiene suggerimenti su come monitorare e controllare l'utilizzo della memoria token.

Ogni token di accesso richiede memoria del kernel Microsoft Windows. La quantità varia in base a diversi fattori. L'appartenenza al gruppo è uno dei fattori più importanti. La dimensione del token aumenta in proporzione diretto al numero di appartenenze.

Gli script in questo articolo sono illustrano un modo per contare i token di protezione e generare statistiche sul numero di gruppi di protezione a cui appartengono gli utenti di Exchange. Questa informazioni è possibile stimare le dimensioni in memoria dei token di accesso associati a tali utenti.

INTRODUZIONE

Viene descritto come gestire in modo proattivo e di ridurre l'utilizzo della memoria di riserva di paging che è utilizzata dalle connessioni client a un Exchange server. È possibile ridurre l'utilizzo di memoria del pool di paging controllando la dimensione e il numero di token di accesso. Hotfix 912480 riduce direttamente il numero di token di accesso client che vengono utilizzati da un client quando stabilisce una connessione a Exchange Server 2003 Service Pack 2 (SP2). Il resto dell'articolo viene descritto come ridurre la dimensione del token di accesso. Inoltre, in questo articolo vengono descritti altri metodi che è possibile utilizzare per controllare, distribuire e ottimizzare le connessioni client nel contesto di token di accesso.

Un hotfix per Exchange 2003 SP2 è disponibile per ottimizzare l'utilizzo di token del client. Questo aggiornamento rapido (hotfix) può ridurre il consumo di memoria di token che è correlato ai client MAPI tramite fino a un terzo. È applicare questo aggiornamento rapido (hotfix) solo se il pool di paging non si verificano problemi di esaurimento della memoria che sono causati dal token di allocazioni. Per ulteriori informazioni sull'aggiornamento rapido (hotfix) 912480, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
912480Un server di Exchange Server 2003 che ospita numerose sessioni client di Outlook potrebbe essere esaurito memoria del pool di paging

Informazioni

Token di accesso

Quando un account di Windows tenta di accedere a un Windows protetto viene creata la risorsa, un token di accesso. Il token di accesso viene utilizzato per determinare se deve essere concesso accesso e il livello di accesso deve essere concessa. I token vengono generati dal server che ospita la risorsa. Il server interroga controller di dominio appropriato per ottenere le informazioni token.

Il token di accesso è costituito da tipi diversi di informazioni, in particolare l'ID di protezione (SID per l'account utente e per i gruppi di protezione a cui appartiene l'account utente). Dopo che un utente esegue l'autenticazione a un server, i SID appropriati associati con l'utente e le appartenenze dell'utente vengono inseriti in un token di accesso. Un SID è una stringa di numeri che identifica univocamente un identità di protezione Windows o un gruppo di protezione. Per ulteriori informazioni, vedere il documento "Security Identifiers Technical Reference". Per visualizzare questo documento, visitare il sito di Web di Microsoft:
http://technet2.microsoft.com/windowsserver/en/library/a320b892-f678-490d-adf0-fb97984c2bd71033.mspx
I SID non sono segreto ulteriori rispetto a nomi di accesso. I SID sono univoci identificatori numerici associati con i nomi degli oggetti. Il SID rimane lo stesso per la durata di un oggetto di Active Directory. Di conseguenza, il SID utilizzabile per conclusively identificare un oggetto indipendentemente da se modificare altri attributi di oggetto.

Ogni risorsa protetta su un server dispone di un elenco di controlli accesso discrezionale (DACL), (DACL) che associato. L'elenco DACL Elenca i SID di cui è consentito o negato l'accesso alla risorsa.

Quando un utente tenta di accedere a una risorsa protetta, l'elenco dei SID nel token di accesso dell'utente viene confrontato con l'elenco dei SID nell'elenco DACL della risorsa. Se un SID nel token di corrisponde a un SID nell'elenco DACL della risorsa, viene concesso l'accesso appropriato. Non è possibile determinare il numero di gruppi di protezione a cui un account utente appartiene contando il numero di gruppi elencati nel Membro di proprietà dell'oggetto utente in modo affidabile. Ciò è dovuto quattro seguenti fattori:
  • nidificazione dei gruppi

    Nei domini in modalità originale Microsoft Windows 2000 o domini di Windows Server 2003 modalità funzionale gruppi possono essere nidificati più flessibile rispetto a domini a modalità mista. Quando un gruppo viene aggiunto al token dell'utente, i SID dei gruppi nidificati vengono inoltre aggiunti.
  • appartenenza ai gruppi universali

    Se il dominio dell'account utente è in modalità mista, i gruppi universali non verranno aggiunto al token di accesso. Non appena il dominio a cui appartiene viene convertito in modalità nativa o in una delle modalità funzionale di Windows Server 2003, le appartenenze a gruppi universali verranno aggiunti al token.
  • SIDHistory

    È possibile che vengono migrati da domini Microsoft Windows NT 4.0 o di altri domini di Active Directory che account presentino molti appartenenze nei relativi attributi SIDHistory. Per ulteriori informazioni su SIDHistory, visitare il sito di Web di Microsoft:
    http://technet.microsoft.com/en-us/library/Bb727125.aspx
    SIDHistory è disponibile solo per domini di account utente che sono già in modalità nativa o in modalità funzionale di Windows Server 2003. Se il dominio dell'account utente è in modalità mista, i gruppi di SIDHistory verranno ignorati. In pratica, questi gruppi non devono esistere.
  • gruppi locali di dominio

    Se una risorsa protetta è ospitata in una modalità nativa o di un dominio in modalità funzionale Windows Server 2003, gruppi locali di dominio nel dominio di risorse a cui appartiene l'account utente verranno aggiunto al token. Si supponga, ad esempio, che un utente nel dominio A tenta di accedere a una risorsa in dominio b. In modalità nativa o in modalità funzionale di Windows Server 2003, tutti i gruppi locali di dominio nel dominio B, a cui appartiene l'utente verranno aggiunto al token di accesso. Gruppi locali di dominio in un dominio a cui appartiene l'utente non verranno aggiunto al token generato da un server in dominio b. Infatti locale gruppi di dominio dal dominio sono irrilevante per il dominio b.

Token di copie

Token di accesso di un utente è memorizzati sul server nella memoria del kernel pool di paging. In qualsiasi momento, sono probabilmente presenti da più copie di token ciascun utente in memoria. Ad esempio, se un client esegue il mapping una condivisione su un server basato su Windows Server 2003 utilizzando il comando NET USE , due copie di token dell'utente verranno conservate sul server per supportare questa connessione.

Ciascuna applicazione client che si connette a un server di Exchange è probabile che genera più copie del token utente, a seconda dell'applicazione e la configurazione.

È disponibile una quantità limitata di memoria del pool di paging. Pertanto, è un limite al numero di connessioni client può mantenere un server nello stesso momento. In un server basato su Windows che dispone di più di 1 gigabyte (GB) di memoria fisica installata, la memoria di riserva di paging massima è di circa 350 megabyte (MB). Questo importo può essere diminuito di regolazione della memoria in favore di altre risorse che potrebbero essere in più breve di approvvigionamento.

Suggerimenti di ottimizzazione di memoria per un server Exchange su larga scala prevedono l'utilizzo del / 3 GB opzione boot.ini. Questo riduce la memoria di paging massima a meno di 250 MB. In questo contesto, è presente un server di Exchange su larga scala che è quello che gli host migliaia di cassette postali e che ha più di 1 GB di RAM installata.

Se non si utilizza il / 3 GB opzione, è probabile che servizi di Exchange Server dovrà essere riavviato periodicamente per deframmentare memoria virtuale. Commerciali disattivare la memoria di riserva di paging del kernel per la memoria dell'applicazione è un valido compromesso. Tuttavia, questo compromesso significa che è necessario monitorare attentamente l'utilizzo di memoria del pool di paging. Per ulteriori informazioni sulla regolazione della memoria per Exchange Server, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
815372Come ottimizzare l'utilizzo della memoria in Exchange Server 2003
Inoltre, visualizzare la sezione "Ruling Out memoria associati a problemi" del foglio "Troubleshooting Exchange Server 2003 Performance" bianco. Per visualizzare questo white paper, visitare il seguente sito Web Microsoft (informazioni in lingua inglese):
http://technet.microsoft.com/en-us/library/4b012bda-8711-4617-9239-f3527de884a3.aspx
Token del client sono in genere il consumer di singolo più grande di memoria di paging su un server di Exchange. Se il token dell'utente medio è grande, il consumo di memoria di pool di paging è probabile che diventare un collo di bottiglia importante per la scalabilità di Exchange Server.

Come calcolare la dimensione dei token

Dimensione in byte dei token accesso può essere stimati utilizzando la seguente formula:
[numero 12 x dei diritti utente] + [token overhead] + [numero x 44 delle appartenenze a gruppi] = token dimensione in byte
  • I diritti utente sono diritti ad esempio "Accesso locale"o "accesso al computer dalla rete". I diritti di utente che vengono aggiunti a un token di accesso sono i diritti utente sono configurati sul server che ospita una risorsa protetta. La maggior parte degli utenti sono probabile che disporre di diritti solo due o tre server di Exchange. Gli amministratori potrebbero essere decine di diritti utente. Ogni diritto utente richiede 12 byte memorizzarlo nel token.
  • Token overhead include più campi quali token di origine, l'ora di scadenza e informazioni di rappresentazione. Per un tipico dominio utente non dispone di accesso speciale o restrizioni, è probabile essere compresa tra 400 e 500 byte token overhead. In genere, stima 500 byte per i diritti utente e token di overhead è più che sufficiente.
  • Ogni l'appartenenza al gruppo, il gruppo SID viene aggiunto al token con altri 16 byte per informazioni e gli attributi associati. La dimensione massima possibile per un SID è di 68 byte. Tuttavia, è raro per un SID da questo di grandi dimensioni. In Windows Server 2003 e nelle versioni precedenti di Windows, il SID per un utente o un gruppo tipico è 28 byte di lunghezza. Di conseguenza, ogni gruppo di protezione a cui un utente appartiene in genere aggiunge 44 byte a dimensione token dell'utente.

Allocazione di memoria token

Un token è inferiore a 4 kilobyte (KB), la quantità di memoria del kernel viene allocata per il esattamente è ciò che è necessario tenere il token. Si consideri ad esempio, un utente tipico che appartiene a gruppi di protezione 30. Utilizzando la formula di menzionato nella sezione "calcolo delle dimensioni del token", token dell'utente sarà di circa 1,820 byte (44 byte x 30 gruppi + 500 byte di sovraccarico = 1,820).

Ma, se un token è leggermente maggiore di 4 KB (4.096 byte), la quantità di memoria allocata per la copia salterà a esattamente 8 KB (8.192 byte). Se un token è leggermente maggiore di 8 KB, l'allocazione di memoria verrà passa esattamente 12 KB. Di conseguenza, ogni volta che le dimensioni di token supera uno di questi limiti di 4 KB critici, è presente un cambiamento improvviso l'utilizzo di memoria del pool di paging.

In genere, un utente che appartiene ai gruppi di protezione più di 80 sarà vicino o supererà il limite di 4 KB. Di conseguenza, l'utente richiede un token di 8 KB. Se un utente appartiene a gruppi più 170, il token è probabile che richiedono di 12 KB e così via.

Nell'esempio riportato di seguito viene illustrato il quanto sia importante per monitorare e controllare dimensione token client medio. Si consideri un sito Exchange 2003 Service Pack 2 in cui tutti i client utilizza Microsoft Office Outlook 2003 in modalità cache di server. Un tipico client modalità cache comporta sette o otto copie di un token deve essere generato su un computer basato su Windows Server 2003. Se il token di client medio è esattamente 4 KB, ogni client in modalità cache richiede fino a 32 KB di memoria del pool di paging.

Nota L'aggiornamento rapido servizio Archivio informazioni Microsoft è descritto nella sezione "Introduzione" è in possibile di ridurre il numero di copie di token per ciascun utente della modalità cache per quattro o cinque anziché sette o otto. L'aggiornamento in questione da includere in Exchange Server 2003 Service Pack 3.

Se il server è configurato utilizzando il / 3 GB opzione, verrà circa 250 MB di memoria di riserva di paging allocata sul server. È consigliabile che il consumo di pool di paging tipica per il server deve essere più di 200 MB. È necessario riservare memoria sufficiente per picchi di carico del server. Se il consumo è in genere più di 220 MB memoria del pool di paging, è consigliabile intervenire immediatamente per ridurre il carico sul server.

Si supponga che 150 MB di memoria del pool di paging sia disponibile per il token del client di Exchange Server. Se ogni token del client è di 4 KB, il server può supportare comodamente più di 4.500 utenti concorrenti di modalità cache Outlook prima di utilizzare token diventerà un collo di bottiglia. Si noti che l'applicazione di aggiornamento rapido (hotfix) 912480 aumentare questo valore massimo per 7,300 gli utenti della modalità cache. Se dimensione token per passare a 8 KB, il numero massimo di client dovrebbe ridursi per metà, indipendentemente da se è stato applicato l'hotfix 912480.

Nota Se Outlook 2003 viene eseguito in modalità in linea, in genere verrà copie di token di tre o quattro, per ogni client indipendentemente da se è stato applicato l'hotfix 912480.

Sintomi di esaurimento della memoria kernel

In caso di risorse di memoria del kernel per esaurimento, il server diventa lento o rifiuta le richieste aggiuntive e le connessioni. Improvvisamente applicazioni potrebbero non riuscire. Inoltre, tenta di connettersi al server interessato può restituire l'errore 1450, "Risorse di sistema insufficienti". In casi estremi, il server potrebbe essere visualizzato un messaggio di errore in una schermata blu e smettere di rispondere.

Inoltre, potrebbero essere registrati nel Registro di sistema i seguenti eventi:

ID evento: 2019
Origine: SRV
Descrizione: Il server Impossibile allocare dal sistema non di paging del pool perché il pool era vuoto.

ID evento: 2020
Origine: SRV
Descrizione: Il server Impossibile allocare dal pool di paging del sistema, in quanto il pool è vuoto.

ID evento: 2000
Origine: SRV
Descrizione: Chiamata del server a un servizio di sistema non riuscita in modo imprevisto.

Se una carenza di memoria di riserva di paging è temporanea, è possibile che il server probabilmente verrà ripristinato. Applicazioni possono essere piuttosto flessibile a temporaneo insufficienza di memoria. Nessuna applicazione, tuttavia, possibile eseguire sempre se non sono soddisfatte le richieste di risorsa critica. Se la carenza di memoria di pool di paging dura molto lungo, è probabile attivare i colli di bottiglia CSS. In tal caso, il server avrà probabilmente essere riavviato per rendere funzionale nuovamente.

Sotto carico standard, è necessario circa 50 MB di memoria di paging disponibile. Se hai è inferiore a 30 megabyte liberi, è consigliabile intervenire immediatamente per ridurre il carico sul server.

Viene allocata in modo statico la memoria di pool di paging durante Windows avvio. Il pool non può essere aumentato senza riconfigurare e riavviare il server. La quantità di memoria di paging disponibile dipende da diversi fattori. Questi fattori sono opzioni di avvio, ad esempio / USERVA e / 3 GB , le impostazioni del Registro di sistema e RAM fisica.

Come ridurre la dimensione del token di accesso utente

È possibile utilizzare le seguenti tre strategie per ridurre la dimensione dei token:
  • Ridurre il numero di gruppi di protezione a cui appartiene ogni utente.
  • Host server di Exchange in un dominio diverso dagli utenti che si connettono al server di Exchange.

    Questa strategia può ridurre il di token dell'utente per la rimozione di gruppi locali di dominio per il dominio di account utente dal token presentata al server di Exchange. Questo funziona perché gruppi locali di dominio da un dominio non vengono mantenuti nel token generato su un server in un dominio diverso.
  • Quando possibile, convertire i gruppi di protezione in gruppi di distribuzione.

    Token di dimensione viene aumentata di appartenenza a gruppi di protezione, non i gruppi di distribuzione. Gli utenti possono appartenere a migliaia di gruppi di distribuzione che non incidono sulle dimensioni del token. Se non viene utilizzato un gruppo per negare o concedere l'accesso alle risorse, dovrebbe essere un gruppo di distribuzione non un gruppo di protezione.

Come ridurre il numero di token di accesso in memoria sul server

Non appena sono riduzione delle dimensioni token tipica al pratico minimo, il passaggio successivo consiste nel gestire il numero di connessioni simultanee che vengono inviate al server. È possibile gestire il numero di connessioni simultanee tramite i metodi seguenti:
  • Consente di limitare i client non autorizzati e le applicazioni.

    Ogni client potrebbe rendere più connessioni al server. Inoltre, i client diversi effettuare diverso numero di connessioni in base a una vasta gamma di fattori. Non potrebbe essere anche un elenco completo di tutti i client connettersi al server. Gli utenti possono installare aggiuntivi di Outlook che ulteriori connessioni. Gli sviluppatori è possono eseguire applicazioni che rendono il numero di connessioni o che non vengono arrestati connessioni quando sono al termine. Di conseguenza, è necessario analizzare quali tipi di client connettersi il server e i tipi di effetti hanno sull'utilizzo di memoria del kernel. Per ulteriori informazioni, vedere la sezione "visualizzare le dimensioni di allocazione token".
  • Rimuovere l'archivio di cartelle pubbliche dal server. Quindi indirizzare i client alle cartelle pubbliche su un server diverso.

    Questa azione Elimina cartella pubblica le connessioni effettuate dai client.
  • Consente di rimuovere specifiche cartelle pubbliche che per il numero di connessioni client.

    Buoni candidati per la rimozione sono la disponibilità di Schedule + cartella e la Rubrica non in linea. I client devono effettuare altre connessioni a queste cartelle quando pianificare appuntamenti o scaricare la Rubrica.
  • Aggiungere le repliche di accesso molto cartelle pubbliche per distribuire il numero di client che si connettono tra più server.
  • Installare server di cartelle pubbliche dedicato per eliminare tutte le connessioni cartelle pubbliche dai server cassette postali.
  • Distribuire agli utenti di connessione pesante in modo uniforme tra più server. Gli utenti di connessione pesante sono probabilmente quelli che dispongono di più computer o dispositivi e quelli che gli utenti mobili.
  • Distribuire gli utenti con i token di protezione di grandi dimensioni su più server.
  • Applicare l'hotfix 912480 per l'ottimizzazione di token. Per ulteriori informazioni sull'aggiornamento rapido (hotfix) 912480, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
    912480Un server di Exchange Server 2003 che ospita numerose sessioni client di Outlook potrebbe essere esaurito memoria del pool di paging

Come monitorare la memoria di paging su un server di Exchange

In genere, è necessario 50 MB di memoria di pool di paging disponibile disponibile nel server tipico condizioni di carico. Inoltre, è necessario 30 MB carichi di picco.

È facile determinare quanta memoria di riserva di paging è attualmente in uso. Consente di visualizzare Windows Task Manager di paging utilizzo nell'area di Memoria del kernel la scheda prestazioni . È inoltre possibile monitorare l'utilizzo di memoria del pool di paging nel tempo al contatore Memoria\byte del pool di paging in Monitor di sistema Windows.

Un server di Exchange è configurato per l'utilizzo di / 3 GB opzione di avvio avranno una dimensione di memoria di riserva di paging massima possibile di circa 250 MB. Inoltre, è possibile che questo server avrà un massimo di non--pool di memoria di paging di almeno 128 MB. Senza il / 3 GB passare, i massimi sono 350 MB di memoria di riserva di paging e 256 MB di memoria di riserva non di paging.

Di conseguenza, un tipico Exchange su larga scala server deve utilizzare più di 200 MB di paging di pool di memoria in condizioni normali. Utilizzo di memoria di riserva di paging di oltre 220 MB richiede attenzione immediata.

Se si è all'interno di questi limiti e il server è segnalazione di errori correlati a esaurimento della memoria di riserva di paging, è probabile che l'allocazione di memoria del pool di paging iniziale sia inferiore a quello previsto. Questo può essere causato da richieste di hardware, dal driver di periferica, oppure si pool allocazione di memoria maggiore di paging per la regolazione della memoria che riduce iniziale. Configurazioni di memoria di grandi dimensioni, ad esempio, più di 4 GB di RAM fisica, sono la causa più comune di questo problema.

Ogni byte di RAM fisica installata in un server richiede memoria del kernel per indirizzare e gestirlo. Il più RAM installata, lo spazio di indirizzo del kernel ulteriori deve essere riservato per il. Spazio di indirizzi può essere preso in prestito dalla memoria di riserva di paging per soddisfare questa richiesta.

Si consiglia di non installare più di 4 GB di RAM fisica in un server dedicato a cui è in esecuzione Exchange Server 2003. Server consentirà l'utilizzo efficiente di fino a 4 GB di RAM. Tuttavia, Exchange Server non sfrutterà di RAM anche se è disponibile. Server che supportano la funzionalità di scelta rapida memoria Aggiungi può provocare notevoli riduzioni nella disponibilità di memoria del pool di paging. Anche se è installato più di 4 GB di RAM, spazio di indirizzi può essere riservato per l'importo massimo teorico di hot-add RAM che può essere installato.

È possibile utilizzare un debugger del kernel per visualizzare le dimensioni della memoria di paging iniziale e altre allocazioni di memoria del kernel.

importante Comandi che possono essere utilizzati durante un sessione di debug di kernel possono causare problemi del sistema diventi instabile o l'arresto. Si consiglia di arrestare tutti i servizi di Exchange Server prima che si avvia un kernel sessione di debug e il riavvio del server dopo la sessione.

Impostazione di un tradizionale kernel sessione per Windows 2000 di debug è un'attività complessa. Questa operazione richiede in genere un computer aggiuntivo, cavi specializzati e un riavvio del server.

In alternativa, l'utilità LiveKD di Sysinternals può essere utilizzato per avviare un kernel sessione dalla console del server di debug. LiveKD non richiede il riavvio del server. Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
894067Lo strumento prestazioni non mostra correttamente le voci tabella pagine di sistema disponibile disponibile in Windows Server 2003
Per Windows Server 2003, il debugger del kernel KD supporta il debug direttamente dalla console di server senza hardware o preparazione particolare. Per ottenere gli strumenti di debug per Windows, il seguente sito Microsoft Web:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Avviare il debugger utilizzando il comando KD.EXE - KL . Eseguire quindi il ! vm comando per visualizzare la memoria di paging massima. Ad esempio, eseguire i seguenti comandi:
KD.EXE - KL
! VM

Come visualizzare le dimensioni di allocazione token

Outlook non è il solo client può connettersi a un Exchange Server database. I componenti aggiuntivi di Outlook, motori di ricerca desktop che includono la posta elettronica cercare funzionalità, i client di messaggistica immediata e applicazioni personalizzate tutti rendere connessioni aggiuntive e causare la generazione di copie aggiuntive di token.

È possibile verificare l'effetto di un client o un'applicazione con l'utilità di Poolmon.exe in un ambiente di laboratorio. Per effettuare questa operazione, attenersi alla seguente procedura:
  1. Generare un laboratorio isolato l'organizzazione di Exchange.
  2. Installare Poolmon nel server di Exchange. Per ulteriori informazioni su come configurare Poolmon.exe, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
    177415L'utilizzo di Memory Pool Monitor (Poolmon.exe) per la memoria del kernel di risoluzione dei problemi
  3. Eseguire Poolmon.exe con il / iToke opzione ( Poolmon /iToke ). Si noti che il / iToke parametro viene fatta distinzione tra maiuscole e minuscole. In questo modo Poolmon.exe per visualizzare solo le allocazioni token verrà configurato. È inoltre possibile utilizzare questo comando su un server di produzione per visualizzare il totale di allocazioni token in tempo reale.
  4. Configurare un account utente di Active Directory simile all'utente di Exchange Server tipico in ambiente. Configurare un account di utente che abbia un numero equivalente di appartenenza ai gruppi di protezione, un profilo di simili autorizzazioni e così via.
  5. Accedere al server come l'utente test con le applicazioni client e le configurazioni che si desidera eseguire il test. Attendere alcuni minuti dopo l'accesso per l'applicazione client completamente carica e stabilizzazione.
  6. Uscire dall'applicazione client quando si nota la modifica di byte del Poolmon.exe token. Potrebbe essere necessario eseguire questa più volte per ottenere una lettura accurata di quanti byte vengono rese disponibili quando si chiude il client. Altre allocazioni token possono anche essere creati o eliminati nello stesso momento durante il test.
Nota Se si modifica l'account utente, ad esempio aggiungendo o eliminando l'appartenenza a gruppi di protezione, è necessario disconnettersi l'account di Windows e quindi riaccedere prima di queste modifiche si rifletteranno nel token di accesso.

Come controllare l'appartenenza ai gruppi

Script di esempio riportato di seguito contengono parametri della riga di comando e istruzioni all'inizio di ogni script. È possibile incollare gli script nel blocco note e quindi salvarli come file vbs. Non salvare i file come file con estensione txt.
  • Lo script Groups.vbs consente di stampare i nomi di account utente server delle cassette postali e i gruppi di protezione a cui appartengono. Inoltre, la stampa contiene una colonna separata che elenca i gruppi di SIDHistory. È possibile limitare lo script a un singolo server Exchange o per ottenere un report per più server di Exchange, utilizzare un carattere jolly.

    Nota Non è possibile utilizzare un carattere jolly (*) per accedere a tutti i server di Exchange. È necessario fornire almeno un nome parziale del server. Ad esempio, è possibile utilizzare una stringa che è simile al seguente:
    EXCH - HQ *
  • Lo script Groups_statistics.vbs consente di visualizzare basati su testo istogramma che mostra quanti utenti appartengono a 50 gruppi, 60 gruppi, 70 gruppi e così via. Questo consente di determinare la dimensione di token Media probabile che per gli utenti.
Vedere "How calcolare la dimensione dei token" e "Token di allocazione della memoria" sezioni per dettagliate informazioni sulle dimensioni di token.

Script

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

I prodotti di terze parti che in questo articolo viene descritto sono forniti da produttori indipendenti. Microsoft non rilascia alcuna garanzia, implicita o di altra natura, relativa alle prestazioni o all'affidabilità di questi prodotti.

Proprietà

Identificativo articolo: 912376 - Ultima modifica: venerdì 16 novembre 2007 - Revisione: 2.4
Le informazioni in questo articolo si applicano a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange 2000 Server Standard Edition
Chiavi: 
kbmt kbhowto kbinfo KB912376 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 912376
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

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