Origini delle operazioni di I/O su disco di Exchange
Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Ultima modifica dell'argomento: 2010-05-31
I ruoli del server Microsoft Exchange Server 2007 sono Trasporto Hub e Trasporto Edge (denominati collettivamente server di trasporto), nonché Accesso client, Messaggistica unificata e Cassette postali. Ciascun ruolo del server presenta requisiti di archiviazione, backup e ripristino diversi, in parte perché svolgono funzioni distinte:
I server Trasporto Hub e Trasporto Edge recapitano:
La posta in arrivo e in uscita dall'organizzazione.
La posta in arrivo e in uscita dai server Cassette postali.
Messaggi della segreteria telefonica inviati dai server Messaggistica unificata.
I server Accesso client sono server dei protocolli client per Exchange e forniscono i protocolli Outlook Web Access, Exchange ActiveSync, Outlook Anywhere e altri protocolli Internet.
I server Messaggistica unificata forniscono Outlook Voice Access e il supporto per i fax in arrivo.
Nei server Cassette postali, che rappresentano il nucleo di Exchange Server, vengono archiviate le cartelle pubbliche e le cassette postali degli utenti.
Per il cluster delle cassette postali, o cluster a copia singola (SSC, single copy cluster), viene utilizzato il servizio cluster in una configurazione attiva/passiva del disco condiviso.
La replica continua consente di inviare i file di registro a una posizione alternativa, che può essere un server autonomo in cui viene utilizzata la replica continua locale (LCR, local continuous replication), un cluster in cui viene utilizzata la replica continua cluster (CCR, cluster continuous replication), oppure un server remoto in cui viene utilizzata la replica continua di standby (SCR, standby continuous replication).
Ruolo server Cassetta postale
Il ruolo del server Cassette postali Exchange 2007 è il ruolo del server principale in base al quale vengono creati tutti gli altri ruoli del server. Dopo aver determinato il profilo delle cassette postali, che include la capacità e le operazioni di I/O (Input/Output) dell'utente al secondo, è possibile iniziare a pianificare la distribuzione. In genere, il numero di utenti definito per un server di Exchange si basa su un equilibrio che consente di impedire un collo di bottiglia dell'hardware e di eseguire allo stesso tempo il backup e il ripristino dei dati in base al contratto di servizio (SLA, service level agreement).
Per la corretta distribuzione di Exchange 2007, è necessario valutare tre requisiti di archiviazione. Il primo è l'I/O transazionale, ovvero le prestazioni calcolate in termini di latenza per ogni operazione di I/O che deve essere soddisfatta dalla soluzione di archiviazione. Il secondo requisito è la velocità di backup e ripristino, ovvero la velocità di spostamento dei dati da e verso il supporto di backup. Il terzo requisito è la capacità, ovvero la disponibilità di spazio sufficiente nel supporto di backup di destinazione e nella configurazione RAID specificata per i LUN (Logical Unit Number) di produzione.
Per ulteriori informazioni sul dimensionamento dei requisiti relativi all'I/O utilizzando i profili delle cassette postali, vedere Progettazione dell'archiviazione del server Cassette postali. Ad esempio, si supponga di specificare 3.000 utenti in un server con un profilo di 0,4 IOPS (I/O al secondo) con cassette postali da 2 GB. Il requisito delle prestazioni sarebbe 1.200 IOPS e sarebbe necessario assicurarsi di poter eseguire il backup e il ripristino di 6 terabyte di informazioni. Se il contratto di servizio prevede backup di 4 ore, si dovrebbe eseguire il backup di 1,5 terabyte di dati in un'ora, alla velocità di 417 MB al secondo. Se la soluzione in uso consente di eseguire il backup a una velocità massima di 300 MB al secondo, sarebbe necessario ridurre del 28% la dimensione delle cassette postali o il numero degli utenti.
La procedura consigliata in Exchange 2000 Server, su cui incidevano i limiti della memoria virtuale, consiste nell'aggiungere 5 database a un gruppo di archiviazione prima di creare altri gruppi di archiviazione. In Exchange Server 2003, tali limiti sono stati ridotti notevolmente e la procedura consigliata consiste nell'aggiunta di un gruppo di archiviazione per ogni nuovo database finché non viene creato il numero massimo di gruppi di archiviazione. Con Exchange 2007, la superificie di operazioni di I/O è stata ridotta in seguito ai miglioramenti apportati a Extensible Storage Engine (ESE), il modulo di gestione di database sottostante utilizzato da Exchange Server.
Principali miglioramenti di Extensible Storage Engine
Exchange 2007 consente di ridurre l'impatto dell'I/O globale relativo a Exchange Server in seguito a numerose modifiche chiave apportate alla progettazione di ESE:
Il sistema operativo e l'applicazione di Exchange Server a 64 bit consentono una cache del database di dimensioni notevolmente maggiori, da 900 MB a decine di gigabyte, a seconda della memoria totale del sistema.
Anche le operazioni di lettura del database traggono vantaggio dalle nuove e molteplici ottimizzazioni della cache. L'aumento della funzione di ricezione dell'I/O da 64 KB a 1 MB consente di ridurre ulteriormente l'I/O del disco e di eseguire, pertanto, operazioni di lettura e scrittura di I/O di dimensioni maggiori.
Non esiste alcun file di database di flusso e il file system installabile (IFS) è stato rimosso.
Trattandosi di un'applicazione a 64 bit, Exchange 2007 non presenta i limiti della memoria virtuale che caratterizzavano le versioni precedenti a 32 bit. I server Cassette postali Exchange 2007 sono in grado di supportare fino a 50 database e 50 gruppi di archiviazione ed è possibile aggiungere fino a 5 database a un gruppo di archiviazione. Ogni server Cassette postali Exchange 2007 tuttavia può disporre di un numero massimo di 50 database.
Ogni gruppo di archiviazione, che rappresenta l'unità di base per il backup e il ripristino, è in grado di creare un proprio registro delle transazioni separato. In assenza di pressione della cache, la quantità massima di dati che può essere scritta da ESE nel registro delle transazioni prima della scrittura nel database è una cache denominata profondità del checkpoint. L'utilizzo di un singolo database in un gruppo di archiviazione consente di allocare l'intera profondità del checkpoint nel database, aumentando la probabilità che vengano eseguiti più aggiornamenti delle pagine del database nella cache. Inoltre, verrà scritto nel database solo l'aggiornamento più recente, riducendo quindi le operazioni di I/O.
Componenti dei dati delle cassette postali di Exchange
Nella tabella seguente vengono descritte le attività del ruolo del server Cassette postali e i relativi impatti sulle operazioni di I/O del disco.
Attività del ruolo del server Cassette postali in Exchange 2007
Attività | Impatto dell'attività sull'I/O del disco |
---|---|
Database ESE (file EDB) |
Il server Cassette postali consente di archiviare tutta la posta in un database ESE. L'accesso al database ESE è causale e le dimensioni di pagina sono pari a 8 KB, anche se l'assegnazione dell'I/O può generare I/O di dimensioni maggiori. Per motivi di affidabilità e, in alcuni casi, di prestazioni, è necessario che il database si trovi su dischi che non contengono registri delle transazioni. |
File di registro delle transazioni (file LOG) |
Tutte le modifiche apportate al database vengono prima salvate nel registro delle transazioni, ovvero viene eseguita un'operazione di scrittura sequenziale nel disco. Le dimensioni delle operazioni di scrittura variano da 512 byte fino alle dimensioni del buffer di registro. |
Indicizzazione del contenuto |
L'indicizzazione del contenuto è un carico di lavoro casuale che deve essere collocato nello stesso LUN del database e che, in genere, rappresenta il 5% della dimensione del database. Poiché l'indicizzazione del contenuto viene eseguita in background e i messaggi vengono indicizzati al momento della ricezione, l'impatto sull'I/O del disco è minimo. |
Paging |
Se un processo richiede una pagina in memoria e il sistema non è in grado di individuarla nel percorso specificato, si verificherà un errore di pagina. Se la pagina è situata altrove nella memoria, si verificherà un errore di pagina di tipo software. Se la pagina deve essere recuperata dal disco, l'errore di pagina sarà di tipo hardware. La maggior parte dei processori è in grado di gestire molti errori di pagina di tipo software senza conseguenze. Gli errori di pagina di tipo hardware possono tuttavia causare ritardi significativi. Una frequenza costantemente elevata di paging del disco indica che la memoria è insufficiente. |
Conversione del contenuto |
Il metodo nativo di archiviazione dati in Exchange utilizza i messaggi MAPI incapsulati in TNEF (Transport Neutral Encapsulating Format). Consente di trasportare i messaggi MAPI via SMTP e fornisce messaggi MAPI ai client MAPI, come Microsoft Outlook. Per i client non MAPI è necessario che i messaggi siano in formato MIME. Questo formato richiede Exchange per eseguire un processo di conversione del contenuto dal formato TNEF/MAPI a MIME. La conversione della maggior parte del contenuto viene eseguita sui server Accesso client e Trasporto Hub. Tuttavia, le applicazioni legacy WebDAV (Web Distributed Authoring and Versioning), come Microsoft Entourage, accedono direttamente al server Cassette postali. In questo scenario, il processo di conversione del contenuto avviene direttamente sul server Cassette postali di Exchange 2007. Quando un client legacy WebDAV richiede dei dati che devono essere convertiti su un server Accesso client, l'accesso ai dati viene effettuato dal server Cassette postali di Exchange 2007 tramite la directory virtuale /Exchange (alcuni strumenti accedono alla directory virtuale /ExAdmin per l'accesso ai dati). I dati vengono convertiti nella directory Tmp del server Cassette postali, quindi inviati al server Accesso client. Il maggior utilizzo della directory Tmp spesso avviene dopo lo spostamento su un nuovo server degli utenti del client non MAPI. Questo comportamento si verifica perché il volume della conversione potrebbe essere notevole alla prima connessione alle cassette postali. Per migliorare le prestazioni, la directory Tmp non deve trovarsi sullo stesso LUN del file di paging o del sistema operativo. |
Manutenzione del database |
L'archivio informazioni di Exchange 2007 richiede una manutenzione in linea da eseguire a intervalli periodici su ciascun database. Le due attività che influiscono sull'I/O del disco sono l'eliminazione fisica dei messaggi e delle cassette postali antecedenti i criteri di mantenimento configurati e la deframmentazione in linea del database. Poiché il backup del database interrompe la deframmentazione in linea del database in corso, è necessario valutare attentamente la possibilità di fornire al backup e alla manutenzione del database intervalli di tempo esclusivi per completare le relative attività. |
Backup e ripristino |
Il processo di backup dei dati richiede la lettura dei dati dai volumi dei database e dei file registro transazioni. Questo ulteriore carico di I/O potrebbe rallentare i tempi di risposta degli utenti e dovrebbe pertanto essere evitato durante gli orari lavorativi. Il processo di recupero a caldo richiede che ESE riproduca tutti i file di registro delle transazioni. Di conseguenza, poiché il profilo di I/O risultante è un flusso di lettura in sequenza, le prestazioni del processo di ripristino miglioreranno se i file di registro delle transazioni vengono posizionati su un disco con elevata velocità di accesso sequenziale. Per risolvere questo problema, utilizzare la replica continua che consente di distribuire backup basati sul servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service) dalla copia attiva del database alla copia passiva del database. |
Azzeramento delle pagine di database eliminate |
Se la configurazione di un server Cassette postali prevede l'azzeramento delle pagine di database eliminate, ogni volta che si elimina un elemento dal database vengono eliminate più pagine di database. Exchange sovrascrive le pagine eliminate con zeri. Nella versione RTM (Release To Manufacturing) di Microsoft Exchange Server 2007, questa funzionalità viene eseguita solo durante un backup di flusso in linea e determina un aumento delle attività di I/O fisico su disco durante il backup. In Exchange Server 2007 Service Pack 1 (SP1), questa funzionalità può essere attivata durante il periodo di esecuzione della manutenzione in linea. |
Oltre all'accesso ai file di database, l'I/O su disco è determinato anche da altre attività. Nella tabella seguente vengono indicate tali attività e il loro effetto sull'I/O del disco.
Ulteriori attività che incidono sull'I/O del disco
Attività | Impatto dell'attività sull'I/O del disco |
---|---|
Numero di elementi in una cartella |
Con l'aumentare del numero di elementi nelle cartelle delle cassette postali principali, cresce anche il costo del disco fisico per l'esecuzione di alcune attività relative agli utenti di Outlook in modalità in linea. Quando si utilizza Outlook in modalità cache di Exchange, le indicizzazioni e le ricerche vengono eseguite nel client. Il primo ordinamento della cartella Posta in arrivo in base alla dimensione richiede la creazione di un nuovo indice e, di conseguenza, molte operazioni di I/O su disco. Ulteriori operazioni di ordinamento saranno invece molto meno onerose. Il numero di indici disponibili è fisso, quindi se gli utenti eseguono spesso l'ordinamento delle cartelle in base a criteri diversi è possibile che il limite venga superato e che l'I/O su disco aumenti di conseguenza. |
BlackBerry |
Per ulteriori informazioni su BlackBerry ed Exchange 2007, vedere la guida al benchmark delle prestazioni, nella pagina Web BlackBerry Enterprise Server for Microsoft Exchange nel sito Web di Research In Motion (RIM). Nota UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL) |
Cartelle pubbliche |
Se le cartelle pubbliche si trovano nel server, si verifica un aumento del carico I/O. Tuttavia, se nel server non esistono repliche del contenuto delle cartelle, la quantità di I/O dovuta al database di cartelle pubbliche è irrilevante rispetto alla quantità di I/O legata all'accesso alle cassette postali da parte degli utenti. |
Backup
Il backup delle cassette postali deve essere pianificato in modo accurato. Nelle seguenti sezioni vengono fornite alcune considerazioni relative ai backup di flusso in linea e basati sul servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service). In ogni soluzione è necessario conciliare variabili quali i costi, i tempi e l'affidabilità. La maggior parte degli amministratori definisce un intervallo di tempo per la manutenzione e la deframmentazione del database, nonché per la manutenzione del sistema operativo. Queste attività sono in conflitto con i tempi richiesti dal backup. È necessario pertanto prestare particolare attenzione per bilanciare il carico del backup, della manutenzione e della produzione. La presenza di cassette postali di dimensioni maggiori potrebbe impedire il completamento della strategia di backup completo giornaliero definita nel contratto di servizio. Una strategia comune per ridurre l'impatto di un backup completo notturno consiste nell'eseguire backup completi settimanali e backup differenziali giornalieri. Con questa strategia, è necessario ripristinare il backup completo e quindi l'ultimo backup differenziale.
Servizio Copia Shadow del volume
Per informazioni sulle caratteristiche fondamentali del servizio Copia Shadow del volume e sulle relative procedure consigliate per Exchange 2003, si consiglia di leggere Procedure consigliate per l'uso del servizio Copia shadow del volume con Exchange Server 2003 . Oltre alle informazioni contenute in questo articolo, è necessario considerare due principali aspetti relativi al servizio Copia Shadow del volume in Exchange 2007:
Cassette postali di dimensioni maggiori
Possibilità di eseguire il backup di una copia della replica continua locale e della replica continua cluster
Sebbene sia possibile eseguire i backup del servizio Copia Shadow del volume sui dati di produzione o su quelli della copia, si consiglia di eseguire un backup della copia e di evitare un impatto sui dischi fisici di produzione.
Con la replica continua cluster, Exchange 2007 consente di replicare i registri delle transazioni in un disco diverso sullo stesso server. Se si utilizzano cloni del servizio Copia Shadow del volume sulla copia, è necessario configurare l'archiviazione della copia su dischi fisici diversi, in modo tale che il funzionamento dei cloni e l'integrità del checksum non incidano sui dischi fisici di produzione. Se si utilizzano istantanee del servizio Copia Shadow del volume sulla copia, è necessario configurare l'archiviazione della copia su dischi fisici diversi, in modo tale che l'integrità del checksum e il successivo flusso su nastro non incidano sui dischi fisici di produzione.
Con la replica continua cluster, Exchange 2007 consente di replicare i registri delle transazioni in un server diverso. Questo server è un nodo del cluster, ma la copia di destinazione non viene mantenuta nell'archivio condiviso. Se si utilizzano cloni del servizio Copia Shadow del volume, è possibile eseguire l'integrità del checksum nella copia sul nodo passivo utilizzando dischi fisici diversi e isolando, di conseguenza, il processo di backup. Con le istantanee del servizio Copia Shadow del volume, l'integrità del checksum e il successivo flusso su nastro non incidono sui dischi fisici o sul server di produzione.
Backup di flusso in linea
Diversamente dai backup del servizio Copia Shadow del volume basati su hardware, in cui in genere i dati vengono spostati all'interno dell'applicazione di archiviazione, quando si utilizzano i backup di flusso, il server è responsabile dello spostamento dei dati. Il processo dell'integrità del checksum non incide sulle prestazioni perché ogni pagina viene controllata durante il backup. In caso di processi di backup contemporanei, la presenza di più flussi può sovraccaricare i limiti del supporto di backup, indipendentemente dal fatto che si tratti di un nastro collegato a un canale Fibre Channel o Gigabit Ethernet. Per molti clienti, l'intervallo di tempo per il backup definito nel contratto di servizio, diviso per la velocità al minuto del supporto di backup di flusso, limita la dimensione consentita per il gruppo di archiviazione. Ad esempio, se il contratto di servizio per il gruppo di archiviazione è di un'ora ed è possibile eseguire il backup di 100 MB al secondo, la dimensione massima per il gruppo di archiviazione è pari a 360 GB.
Server Accesso client
Il server Accesso client consente di ripartire il carico di molte attività del server Cassette postali che non presentano informazioni sullo stato (presupponendo che i ruoli siano installati in server fisici diversi) e fornisce uno spazio dei nomi unificato che consente agli utenti di fare riferimento a un singolo nome indipendentemente dal server Cassette postali in cui si trovano. I protocolli Internet, ad esempio IMAP4, POP3 e HTTP, vengono gestiti dal server Accesso client. Outlook Anywhere, ActiveSync, il servizio di individuazione automatica, il servizio Disponibilità e i servizi Web sono altri esempi di funzionalità gestite dal server Accesso client.
Nel server Accesso client si può verificare un collo di bottiglia dovuto alla CPU, alla memoria e alla rete, sebbene l'impatto delle operazioni di I/O del disco sia estremamente limitato. Il traffico Simple Mail Transfer Protocol (SMTP), un possibile aspetto rilevante per l'I/O del disco nei server front-end che eseguono Exchange 2003 e Exchange 2000, viene ora gestito esclusivamente dai server Trasporto Hub e Trasporto Edge.
Nella tabella seguente vengono descritte le attività del ruolo del server Accesso client e i relativi impatti sulle operazioni di I/O del disco.
Attività del ruolo del server Accesso client in Exchange 2007
Attività | Impatto dell'attività sull'I/O del disco |
---|---|
Registrazione del protocollo |
La registrazione del protocollo è un'operazione di scrittura sequenziale che, se abilitata, provoca problemi di prestazioni e utilizza lo spazio del disco per archiviare i registri. Se viene mantenuta una cronologia del protocollo scelto per la registrazione, è possibile verificare se il protocollo funziona come previsto o se sono presenti problemi di comunicazione, nonché identificare gli attacchi provenienti da Internet. |
Conversione del contenuto |
La conversione del contenuto per tutti i protocolli di Exchange 2007 viene eseguita nel server Accesso client. La conversione del contenuto WebDAV legacy, per i client di Outlook Web Access legacy, viene eseguita nel server Cassette postali Exchange 2003. Quando un client richiede dei dati che devono essere convertiti su un server Accesso client, l'accesso ai dati viene effettuato dal server Cassette postali Exchange 2003, quindi i dati vengono convertiti nella cartella TMP del server Cassette postali e inviati al server Accesso client. Per migliorare le prestazioni, la cartella TMP non deve trovarsi sullo stesso LUN del file di paging e del sistema operativo. |
Paging |
Se un processo richiede una pagina in memoria e il sistema non è in grado di individuarla nel percorso specificato, si verificherà un errore di pagina. Se la pagina è situata altrove nella memoria, si verificherà un errore di pagina di tipo software. Se la pagina deve essere recuperata dal disco, l'errore di pagina sarà di tipo hardware. La maggior parte dei processori è in grado di gestire molti errori di pagina di tipo software senza conseguenze. Gli errori di pagina di tipo hardware possono tuttavia causare ritardi significativi. Una frequenza costantemente elevata di paging del disco indica che la memoria è insufficiente. |
Lo scenario in cui l'I/O su disco rappresenta un potenziale problema per i server Accesso client prevede che l'utente utilizzi un client Internet per accedere ai dati della cassetta postale tramite il protocollo POP3 o IMAP4. Poiché il modulo di trasporto converte l'intera posta in arrivo in MAPI, un client POP3 o IMAP4 richiede la riconversione del contenuto in MIME (Multipurpose Internet Mail Extensions) prima di inviarlo al client. Tale conversione viene eseguita sul server Accesso client e, se la dimensione del messaggio supera i 64 KB, viene eseguita su disco. Se una percentuale consistente di utenti utilizza POP3 o IMAP4, la cartella temporanea in cui si verifica la conversione dovrà essere posizionata in un disco dedicato con velocità elevata.
Server di trasporto
I server Trasporto Hub e Trasporto Edge sono i server testa di ponte e gateway di Exchange 2007, la cui funzione primaria è l'invio e la ricezione della posta. In molte aziende, il server di trasporto viene distribuito in due gruppi:
Protezione dai virus e dalla posta indesiderata (server Trasporto Edge)
Routing (server Trasporto Hub)
La funzione principale del server Trasporto Edge consiste nel proteggere l'infrastruttura di Exchange dalla posta in arrivo contenente messaggi indesiderati o virus. Il server Trasporto Hub consente quindi di classificare la posta filtrata e di recapitarla al server Cassette postali corretto. L'impatto dell'archiviazione su questi server varia in base al numero di messaggi gestiti al secondo e alla dimensione media di tali messaggi.
Nella tabella seguente vengono descritte le attività dei server Trasporto Edge e Trasporto Hub e i relativi impatti sulle operazioni I/O del disco.
Attività dei ruoli del server Trasporto Edge e Trasporto Hub in Exchange 2007
Attività | Impatto dell'attività sull'I/O del disco |
---|---|
Database ESE (file mail.que) |
Il server Trasporto Edge e il server Trasporto Hub di Exchange 2007 archiviano la posta in un database ESE. L'accesso al database ESE è casuale e le dimensioni di pagina sono pari a 8 KB. Per motivi di affidabilità e, in alcuni casi, di prestazioni, è necessario che il database si trovi su dischi diversi rispetto ai registri delle transazioni. |
File di registro delle transazioni (file LOG) |
Tutte le modifiche apportate al database vengono prima salvate nel registro delle transazioni, ovvero viene eseguita un'operazione di scrittura sequenziale nel disco. Le dimensioni delle operazioni di scrittura variano da 512 byte fino alle dimensioni del buffer di registro. |
Registrazione del protocollo e registri di verifica messaggi |
La registrazione del protocollo e della verifica messaggi è un'operazione di scrittura sequenziale che, se abilitata, provoca problemi di prestazioni e utilizza lo spazio del disco per archiviare i registri. Se viene mantenuta una cronologia del protocollo scelto per la registrazione, è possibile verificare se il protocollo funziona come previsto o se sono presenti problemi di comunicazione, nonché identificare gli attacchi provenienti da Internet. |
Conversione del contenuto |
Nel server Trasporto Hub, la posta in arrivo da Internet viene convertita in formato MAPI prima del recapito. Questo processo di conversione del contenuto viene eseguito nella cartella TMP. Per migliorare le prestazioni, la cartella TMP non deve trovarsi sullo stesso LUN del file di paging e del sistema operativo. |
Paging |
Se un processo richiede una pagina in memoria e il sistema non è in grado di individuarla nel percorso specificato, si verificherà un errore di pagina. Se la pagina è situata altrove nella memoria, si verificherà un errore di pagina di tipo software. Se la pagina deve essere recuperata dal disco, l'errore di pagina sarà di tipo hardware. La maggior parte dei processori è in grado di gestire molti errori di pagina di tipo software senza conseguenze. Gli errori di pagina di tipo hardware possono tuttavia causare ritardi significativi. Una frequenza costantemente elevata di paging del disco indica che la memoria è insufficiente. |
Agenti |
La personalizzazione del server di trasporto viene eseguita tramite programmi, noti come agenti, eseguiti in un ambiente Common Language Runtime e attivati da un evento. Alcuni agenti registrano dati incidendo sulle prestazioni del disco e utilizzando lo spazio del disco per archiviare i registri. |
Server Messaggistica unificata
Per ulteriori informazioni sulla determinazione della dimensione dei server Messaggistica unificata, vedere Determining the Number of Users an Exchange 2007 Unified Messaging Server Can Support .
Nota
UNRESOLVED_TOKEN_VAL(exBlog)