Monitoraggio della disponibilità elevata e della resilienza del sito

Articolo
05/13/2016

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2015-03-09

Per le operazioni quotidiane legate alle messaggistica è fondamentale assicurarsi che i server operino in modo affidabile e che le copie dei database siano integre. Per garantire la disponibilità e l'affidabilità dell'organizzazione di Microsoft Exchange Server 2010, è necessario controllare attivamente l'hardware, il sistema operativo Windows e i servizi di Exchange 2010. Il monitoraggio proattivo, unito alla manutenzione preventiva, consente di identificare potenziali errori prima che un problema grave interferisca con il funzionamento dell'organizzazione di Exchange.

Il monitoraggio dell'organizzazione di Exchange implica il controllo regolare dei problemi relativi ai dati e ai servizi. In genere, il monitoraggio include un sistema di notifiche che invia avvisi al verificarsi dei problemi. Windows Server 2008 ed Exchange 2010 includono diversi strumenti e servizi che permettono di garantire il funzionamento corretto e ininterrotto dell'organizzazione di Exchange. Di seguito sono riportati i principali vantaggi derivanti dal monitoraggio giornaliero:

Conformità ai requisiti dei contratti di servizio
Garanzia del completamento corretto di specifiche attività di amministrazione, ad esempio le operazioni di backup giornaliere
Rilevamento e soluzione dei problemi, riguardanti ad esempio il servizio di messaggistica o la disponibilità dei dati

In un'organizzazione di Exchange 2010 le procedure, le responsabilità e i ruoli coinvolti nelle operazioni devono essere formalizzati. È importante comprendere la connessione tra procedure operative efficaci e l'integrità di un'infrastruttura. Procedure e processi operativi accurati e ben documentati consentono di assicurare che tutti i componenti dell'ambiente organizzativo su cui si basa Exchange siano gestiti in modo efficace ed efficiente.

Exchange 2010 include diversi strumenti, script e funzionalità predefinite utilizzabili come parte del normale monitoraggio proattivo quando Exchange è configurato per la disponibilità elevata o per la resilienza del sito. I principali cmdlet di monitoraggio per la disponibilità elevata e la resilienza del sito sono Get-MailboxDatabaseCopyStatus e Test-ReplicationHealth. Oltre a fornire cmdlet in grado di eseguire funzioni di monitoraggio e segnalare lo stato, Exchange 2010 dispone anche di un nuovo flusso del registro eventi che utilizza le capacità del canale Crimson in Windows Server e gli script predefiniti in grado di raccogliere e analizzare dati da questi canali di eventi.

È possibile utilizzare i dettagli in questo argomento per monitorare l'integrità e lo stato delle copie del database delle cassette postali per i gruppi di disponibilità del database.

Sommario

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Registrazione degli eventi del canale Crimson

Script CollectOverMetrics.ps1

Script CollectReplicationMetrics.ps1

Script CheckDatabaseRedundancy.ps1

Cmdlet Get-MailboxDatabaseCopyStatus

È possibile utilizzare il cmdlet Get-MailboxDatabaseCopyStatus per visualizzare le informazioni sullo stato delle copie del database delle cassette postali. Questo cmdlet consente di visualizzare informazioni su tutte le copie di un particolare database, informazioni su una specifica copia di un database su un server specifico, oppure informazioni su tutte le copie del database su un server. Nella seguente tabella sono descritti i possibili valori per lo stato di una copia del database delle cassette postali.

Stato della copia del database

Stato della copia del database	Descrizione
Failed	La copia del database delle cassette postali è nello stato Failed quando non è stata sospesa e non è in grado di copiare o rieseguire i file di registro. Se lo stato è Failed e la copia non è sospesa, il sistema controlla periodicamente se il problema che ha causato l'impostazione dello stato Failed per la copia è stato risolto. Una volta rilevata la risoluzione del problema, a condizione che non vi siano altri problemi, lo stato della copia diventa automaticamente Healthy.
Seeding	La copia del database delle cassette postali, l'indice del contenuto per la copia del database delle cassette postali o entrambi gli elementi sono sottoposti a seeding. Al completamento del seeding, lo stato della copia cambia in Initializing.
SeedingSource	La copia del database delle cassette postali è utilizzata come origine per l'operazione di seeding della copia del database.
Suspended	La copia del database delle cassette postali è nello stato Suspended a seguito della sospensione manuale della copia del database da parte di un amministratore che ha eseguito il cmdlet Suspend-MailboxDatabaseCopy.
Healthy	La copia del database delle cassette postali esegue correttamente la copia e la riesecuzione dei file di registro, oppure ha completato correttamente la copia e la riesecuzione di tutti i file di registro disponibili.
ServiceDown	Il servizio Replica di Microsoft Exchange non è disponibile o è in esecuzione sul server che ospita la copia del database delle cassette postali.
Initializing	La copia del database delle cassette postali è nello stato Initializing quando è stata creata una copia del database, quando il servizio Replica di Microsoft Exchange è in fase di avvio o è stato appena avviato, e durante le transizioni dallo stato Suspended, ServiceDown, Failed, Seeding, SinglePageRestore, LostWrite o Disconnected a un altro stato. Quando la copia è in questo stato, il sistema verifica che il database e il flusso di registro abbiano uno stato coerente. Nella maggior parte dei casi, lo stato della copia rimane Initializing per circa 15 secondi, ma in ogni caso non deve rimanere tale per più di 30 secondi.
Resynchronizing	La copia del database delle cassette postali e i suoi file di registro vengono confrontati con la copia attiva del database per verificare eventuali divergenze tra le due copie. La copia rimane in questo stato fino a quando non sono state rilevate e risolte tutte le divergenze.
Mounted	La copia attiva è online e sta accettando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Mounted.
Dismounted	La copia attiva è offline e non sta accettando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Dismounted.
Mounting	La copia attiva sta per diventare online e non sta ancora accettando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Mounting.
Dismounting	La copia attiva sta per diventare offline e sta terminando le connessioni dei client. Solo la copia attiva della copia del database delle cassette postali può assumere lo stato Dismounting.
DisconnectedAndHealthy	La copia del database delle cassette postali non è più connessa alla copia del database attiva ed era nello stato Healthy quando si è verificata la perdita della connessione. Questo stato rappresenta la copia del database rispetto alla connettività alla copia del database di origine. Può essere segnalato durante gli errori di rete del gruppo di disponibilità del database tra la copia di origine e la copia del database di destinazione.
DisconnectedAndResynchronizing	La copia del database delle cassette postali non è più connessa alla copia del database attiva ed era nello stato Resynchronizing quando si è verificata la perdita della connessione. Questo stato rappresenta la copia del database rispetto alla connettività alla copia del database di origine. Può essere segnalato durante gli errori di rete del gruppo di disponibilità del database tra la copia di origine e la copia del database di destinazione.
FailedAndSuspended	Gli stati Failed e Suspended sono stati impostati contemporaneamente dal sistema in quanto è stato rilevato un errore la cui risoluzione richiede esplicitamente l'intervento dell'amministratore. Un esempio è il caso in cui il sistema rileva una divergenza irreversibile tra il database delle cassette postali attivo e una copia del database. A differenza dello stato Failed, il sistema non controlla periodicamente se il problema è stato risolto e non esegue il ripristino automatico. Deve intervenire un amministratore per risolvere la causa dell'errore prima che la copia del database possa passare a uno stato di integrità.
SinglePageRestore	Questo stato indica che sulla copia del database delle cassette postali si è verificata un'operazione di ripristino della singola pagina.

Il cmdlet Get-MailboxDatabaseCopyStatus include anche un parametro ConnectionStatus, che restituisce i dettagli sulle reti di replica in uso. Se si utilizza questo parametro, nell'output dell'attività vengono compilati due campi di output aggiuntivi, IncomingLogCopyingNetwork e SeedingNetwork.

Esempi di Get-MailboxDatabaseCopyStatus

Negli esempi riportati di seguito viene utilizzato il cmdlet Get-MailboxDatabaseCopyStatus. In ciascun esempio i risultati vengono inviati al cmdlet Format-List affinché siano visualizzati in formato elenco.

Con questo esempio vengono restituite le informazioni di stato per tutte le copie del database DB2.

Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List

Con questo esempio viene restituito lo stato per tutte le copie del database sul server di cassette postali MBX2.

Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List

Con questo esempio viene restituito lo stato per tutte le copie del database sul server di cassette postali locale.

Get-MailboxDatabaseCopyStatus -Local | Format-List

Con questo esempio vengono restituiti lo stato, il log shipping e le informazioni di rete di seeding per il database DB3 sul server di cassette postali MBX1.

Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List

Per ulteriori informazioni sull'uso del cmdlet Get-MailboxDatabaseCopyStatus, vedere Get-MailboxDatabaseCopyStatus.

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

È possibile utilizzare il cmdlet Test-ReplicationHealth per visualizzare le informazioni sullo stato di replica continua delle copie del database delle cassette postali. Il cmdlet può essere utilizzato per controllare tutti gli aspetti dello stato di replica e riesecuzione per fornire una panoramica completa di uno specifico server di cassette postali in un gruppo di disponibilità del database.

Il cmdlet Test-ReplicationHealth è progettato per il monitoraggio preventivo della replica continua e della pipeline di replica continua, della disponibilità di Active Manager e dell'integrità e dello stato del Servizio cluster, del quorum e dei componenti di rete sottostanti. Può essere eseguito in locale o in modalità remota su qualsiasi server di cassette postali in un DAG. Il cmdlet Test-ReplicationHealth esegue i test elencati nella seguente tabella.

Test del cmdlet Test-ReplicationHealth

Nome del test	Descrizione
ClusterService	Verifica che il Servizio cluster sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
ReplayService	Verifica che il servizio Replica di Microsoft Exchange sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
ActiveManager	Verifica che l'istanza di Active Manager in esecuzione sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) sia in un ruolo valido (primario, secondario o autonomo).
TasksRpcListener	Verifica che la chiamata di procedura remota (RPC) delle attività sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
TcpListener	Verifica che il listener della copia del registro TCP sia in esecuzione e raggiungibile sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
DagMembersUp	Verifica che tutti i membri del gruppo di disponibilità del database siano disponibili, in esecuzione e raggiungibili.
ClusterNetwork	Verifica che tutte le reti gestite dal cluster sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) siano disponibili.
QuorumGroup	Verifica che il gruppo di cluster predefinito (gruppo di quorum) sia in uno stato integro e online.
FileShareQuorum	Verifica che il server di controllo, la directory di controllo e la condivisione configurata per il gruppo di disponibilità del database siano raggiungibili.
DBCopySuspended	Controlla se le copie del database delle cassette postali sono nello stato Suspended sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
DBCopyFailed	Controlla se le copie del database delle cassette postali sono nello stato Failed sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
DBInitializing	Controlla se le copie del database delle cassette postali sono nello stato Initializing sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
DBDisconnected	Controlla se le copie del database delle cassette postali sono nello stato Disconnected sul membro del gruppo di disponibilità del database specificato, o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database.
DBLogCopyKeepingUp	Verifica che la copia del registro e l'ispezione da parte delle copie passive dei database sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) siano in grado di tenere il passo dell'attività di generazione del registro sulla copia attiva.
DBLogReplayKeepingUp	Verifica che l'attività di riesecuzione per le copie passive dei database sul membro del gruppo di disponibilità del database specificato (o sul server locale se non è specificato alcun membro del gruppo di disponibilità del database) sia in grado di tenere il passo dell'attività di ispezione e copia del registro.

Esempio di Test-ReplicationHealth

Con questo esempio viene utilizzato il cmdlet Test-ReplicationHealth per verificare lo stato della replica per il server di cassette postali MBX1.

Test-ReplicationHealth -Identity MBX1

Cmdlet Get-MailboxDatabaseCopyStatus

Registrazione degli eventi del canale Crimson

Windows Server 2008 include due categorie di registri eventi: i registri Windows e i registri applicazioni e servizi. La categoria dei registri di Windows include i registri eventi disponibili nelle versioni precedenti di Windows: applicazioni, protezione e sistema. Include inoltre due nuovi registri: il registro dell'installazione e il registro ForwardedEvents. I registri di Windows sono progettati per archiviare gli eventi delle applicazioni legacy e gli eventi relativi all'intero sistema.

I registri applicazioni e servizi sono una nuova categoria di registri eventi. Questi registri archiviano gli eventi di una singola applicazione o di un singolo componente, anziché gli eventi che possono avere un impatto sull'intero sistema. Questa nuova categoria di registri eventi è definita canale Crimson di un'applicazione.

La categoria dei registri applicazioni e servizi include quattro sottotipi: amministrazione, operativo, analitico e debug. Gli eventi nei registri di amministrazione sono di particolare interesse se si utilizzano i record del registro eventi per la risoluzione dei problemi. Gli eventi nel registro di amministrazione forniscono una guida sulla modalità di risposta agli eventi. Gli eventi nel registro operativo sono altrettanto utili, ma richiedono una maggiore interpretazione. I registri di amministrazione e di debug non sono di facile comprensione per gli utenti. I registri analitici (che per impostazione predefinita sono nascosti e disabilitati) archiviano gli eventi che analizzano un problema; al loro interno viene spesso registrato un elevato volume di eventi. I registri di debug sono utilizzati dagli sviluppatori durante il debug delle applicazioni.

Exchange 2010 registra gli eventi relativi ai canali Crimson nell'area dei registri applicazioni e servizi. È possibile visualizzare questi canali eseguendo la procedura descritta di seguito:

Aprire Visualizzatore eventi.
Nell'albero della console, accedere a Registri applicazioni e servizi > Microsoft > Exchange.
Sotto Exchange, selezionare un canale Crimson: HighAvailability o MailboxDatabaseFailureItems.

Il canale HighAvailability contiene gli eventi relativi all'avvio e all'arresto del servizio Replica di Microsoft Exchange e ai diversi componenti eseguiti all'interno del servizio Replica di Microsoft Exchange, ad esempio Active Manager, l'API di replica sincrona di terze parti, il server RPC delle attività, il listener TCP e il writer del servizio Copia Shadow del volume (VSS). Il canale HighAvailability è utilizzato anche da Active Manager per registrare gli eventi relativi al monitoraggio del ruolo Active Manager e agli eventi di azione del database, ad esempio un'operazione di installazione del database e di troncamento del registro, e per la registrazione di eventi relativi al cluster sottostante a un gruppo di disponibilità del database.

Il canale MailboxDatabaseFailureItems è utilizzato per registrare eventi associati a qualsiasi errore che influisce su un database delle cassette postali replicato.

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectOverMetrics.ps1

Exchange 2010 include nella cartella Scripts uno script chiamato CollectOverMetrics.ps1. CollectOverMetrics.ps1 legge i registri eventi dei membri del gruppo di disponibilità del database (DAG) per raccogliere informazioni sulle operazioni del database (ad esempio i montaggi, gli spostamenti e i failover del database) in un intervallo di tempo specifico. Per ogni operazione, lo script registra le informazioni seguenti:

Identità del database
Ora di inizio e di fine dell'operazione
Server su cui il database è stato montato all'inizio e alla fine dell'operazione
Motivo dell'operazione
Se l'operazione ha avuto esito positivo, inclusi i dettagli sull'errore se l'operazione non è riuscita

Lo script scrive queste informazioni nei file CSV con un'operazione per riga. Lo script scrive in un file CSV separato per ciascun gruppo di disponibilità del database (DAG).

Lo script supporta parametri che consentono di personalizzarne il comportamento e l'output. Ad esempio, è possibile limitare i risultati a un sottoinsieme specificato utilizzando i parametri Database o ReportFilter. Solo le operazioni che corrispondono a tali filtri saranno incluse nel rapporto HTML di riepilogo. I parametri disponibili sono elencati nella tabella seguente.

Parametri dello script CollectOverMetrics.ps1

Parametro	Descrizione
DatabaseAvailabilityGroup	Specifica il nome del gruppo di disponibilità del database da cui si desidera raccogliere le metriche. Se questo parametro viene omesso, viene utilizzato il gruppo di disponibilità del database di cui è membro il server locale. I caratteri jolly possono essere utilizzati per raccogliere informazioni da più gruppi di disponibilità del database e creare i relativi rapporti.
Database	Fornisce un elenco dei database per cui è necessario generare il report. Sono supportati i caratteri jolly, ad esempio `-Database:"DB1","DB2"` o `-Database:"DB*"`.
StartTime	Specifica la durata del periodo di tempo su cui creare il rapporto. Lo script raccoglie solo gli eventi registrati durante questo periodo. Di conseguenza, lo script può acquisire record di operazioni parziali (ad esempio, solo la fine di un'operazione all'inizio del periodo o viceversa). Se non viene specificato né StartTime né EndTime, lo script assumerà come valore predefinito le ultime 24 ore. Se viene specificato un solo parametro, il periodo sarà 24 ore, con inizio o fine all'ora specificata.
EndTime	Specifica la durata del periodo di tempo su cui creare il rapporto. Lo script raccoglie solo gli eventi registrati durante questo periodo. Di conseguenza, lo script può acquisire record di operazioni parziali (ad esempio, solo la fine di un'operazione all'inizio del periodo o viceversa). Se non viene specificato né StartTime né EndTime, lo script assumerà come valore predefinito le ultime 24 ore. Se viene specificato un solo parametro, il periodo sarà 24 ore, con inizio o fine all'ora specificata.
ReportPath	Specifica la cartella utilizzata per archiviare i risultati dell'elaborazione degli eventi. Se il parametro viene omesso, viene utilizzata la cartella Scripts. Quando è specificato, lo script prende un elenco di file CSV generati dallo stesso script e li utilizza come dati di origine per generare un rapporto HTML di riepilogo. Il rapporto è analogo a quello generato con l'opzione -GenerateHtmlReport. I file possono essere generati in più gruppi di disponibilità del database in molti orari diversi o anche in orari sovrapposti e lo script ne unirà tutti i dati.
GenerateHtmlReport	Specifica che lo script raccoglie tutte le informazioni registrate, raggruppa i dati per tipo di operazione, quindi genera un file HTML che include le statistiche di ogni singolo gruppo. Il rapporto comprende il numero totale di operazioni in ogni gruppo, il numero di operazioni non riuscite e le statistiche del tempo impiegato in ciascun gruppo. Il rapporto contiene anche un'analisi dei tipi di errori che hanno causato le operazioni non riuscite.
ShowHtmlReport	Specifica che il rapporto HTML generato deve essere visualizzato in un browser Web subito dopo la generazione.
SummariseCSVFiles	Specifica che lo script legge i dati dai file CSV esistenti precedentemente generati dallo script stesso. I dati vengono quindi utilizzati per generare un rapporto di riepilogo simile a quello generato dal parametro GenerateHtmlReport.
ActionType	Specifica il tipo di azioni operative prese in considerazione dallo script. I valori validi per questo parametro sono `Move`, `Mount`, `Dismount` e `Remount`. Il valore `Move` si riferisce ai momenti in cui il database cambia il server attivo, a causa di spostamenti controllati o di failover. I valori `Mount`, `Dismount` e `Remount` si riferiscono ai momenti in cui il database cambia il proprio stato di montaggio senza spostamento in altro computer.
ActionTrigger	Specifica quali operazioni amministrative devono essere prese in considerazione dallo script. I valori validi per questo parametro sono `Admin` o `Automatic`. Le azioni Automatico sono quelle eseguite automaticamente dal sistema (ad esempio, un failover quando un server passa alla modalità offline). Le azioni Admin sono le azioni eseguite da un amministratore utilizzando Exchange Management Shell o Exchange Management Console.
RawOutput	Specifica che lo script scrive i risultati che avrebbero dovuto essere scritti nei file CSV direttamente con il flusso di output, come nel caso di write-output. Tali informazioni possono quindi essere reindirizzate ad altri comandi.
IncludedExtendedEvents	Specifica che lo script raccoglie gli eventi che mostrano i dettagli di diagnostica del tempo impiegato per montare i database. L'operazione potrebbe richiedere molto tempo se il registro eventi dell'applicazione sui server è molto grande.
MergeCSVFiles	Specifica che lo script raccoglie tutti i file CSV contenenti i dati relativi a ciascuna operazione e li unisce un unico file CSV.
ReportFilter	Specifica che deve essere applicato un filtro alle operazioni utilizzando i campi visualizzati nei file CSV. Questo parametro utilizza lo stesso formato dell'operazione `Where`, in cui ogni elemento è impostato su `$_` e restituisce un valore booleano. Ad esempio: `{$_DatabaseName -notlike "Mailbox Database*"}` può essere utilizzato per escludere i database predefiniti dal rapporto.

Esempi di CollectOverMetrics.ps1

Con questo esempio vengono raccolte le metriche per tutti i database corrispondenti a DB* (che include un carattere jolly) nel gruppo di disponibilità del database DAG1. Dopo la raccolta delle metriche, viene generato e visualizzato un report in formato HTML.

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport

Negli esempi seguenti vengono dimostrate le modalità di filtraggio del rapporto HTML di riepilogo. Nel primo viene utilizzato il parametro Database, che prende un elenco di nomi dal database. Il rapporto di riepilogo contiene quindi solo i dati relativi a questi database. Nei due esempi successivi viene utilizzata l'opzione ReportFilter. Nell'ultimo esempio vengono filtrati tutti i database predefiniti.

CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectReplicationMetrics.ps1

CollectReplicationMetrics.ps1 è un altro script per le metriche di integrità incluso in Exchange 2010. Questo script fornisce una forma attiva di monitoraggio, in quanto raccoglie le metriche in tempo reale durante l'esecuzione dello script. CollectReplicationMetrics.ps1 raccoglie i dati dai contatori di prestazioni relativi alla replica del database. Lo script raccogli i dati relativi ai contatori da più server Cassette postali, scrive tutti i dati del server in un file CSV e può riportare diverse statistiche per tutti i dati (ad esempio, il periodo di tempo in cui una copia non è riuscita o è stata sospesa, la lunghezza media della coda di riesecuzione o di copia o la quantità di tempo in cui le copie non soddisfacevano i criteri di failover).

I server possono essere specificati singolarmente o per interi gruppi di disponibilità del database. Lo script può essere eseguito per raccogliere i dati e creare il rapporto o può essere eseguito solo per raccogliere i dati o solo per creare il rapporto dei dati già raccolti. È possibile specificare la frequenza con cui i dati devono essere campionati e la durata complessiva di raccolta dei dati.

I dati raccolti da ogni server vengono salvati in un file denominato CounterData.<ServerName>.<TimeStamp>.csv. Se lo script non è stato eseguito con il parametro DagName, il rapporto di riepilogo verrà salvato in un file denominato HaReplPerfReport.<DAGName>.<TimeStamp>.csv o HaReplPerfReport.<TimeStamp>.csv.

Lo script avvia i processi PowerShell per raccogliere i dati da ogni server. Questi processi vengono eseguiti per l'intera durata di raccolta dei dati. Se si specifica un gran numero di server, l'operazione può richiedere una notevole quantità di memoria. La fase finale del processo, in cui i dati vengono elaborati in un rapporto di riepilogo, può richiedere anche del tempo per l'elaborazione di grandi quantità di dati. È possibile eseguire la fase di raccolta su un computer, quindi copiare i dati altrove per l'elaborazione.

Lo script CollectReplicationMetrics.ps1 supporta parametri che consentono di personalizzarne il comportamento e l'output. I parametri disponibili sono elencati nella tabella seguente.

Parametri dello script CollectReplicationMetrics.ps1

Parametro	Descrizione
DagName	Specifica il nome del gruppo di disponibilità del database da cui si desidera raccogliere le metriche. Se questo parametro viene omesso, viene utilizzato il gruppo di disponibilità del database di cui è membro il server locale.
DatabaseNames	Fornisce un elenco dei database per cui è necessario generare il report. Sono supportati i caratteri jolly, ad esempio `-DatabaseNames:"DB1","DB2"` o `-DatabaseNames:"DB*"`.
ReportPath	Specifica la cartella utilizzata per archiviare i risultati dell'elaborazione degli eventi. Se il parametro viene omesso, viene utilizzata la cartella Scripts.
Duration	Specifica il tempo di esecuzione del processo di raccolta. I valori standard sono compresi tra una e tre ore. Le durate magggiori devono essere utilizzate solo con intervalli lunghi tra un campione e l'altro oppure come serie di processi più brevi eseguiti dalle attività pianificate.
Frequency	Specifica la frequenza di raccolta delle metriche dei dati. I valori standard sono 30 secondi, un minuto o cinque minuti. In circostanze normali, intervalli più brevi di questi non visualizzeranno modifiche significative tra ogni campione.
Servers	Specifica l'identità dei server da cui raccogliere le statistiche. È possibile specificare qualsiasi valore, inclusi caratteri jolly o GUID.
SummariseFiles	Specifica un elenco di file CSV per generare un rapporto di riepilogo. Questi file sono denominati CounterData.<CounterData>* e sono generati dallo script CollectReplicationMetrics.ps1.
Mode	Specifica le fasi di elaborazione eseguite dallo script. È possibile utilizzare i seguenti valori: `CollectAndReport` Questo è il valore predefinito. Questo valore indica che lo script deve sia raccogliere i dati dai server che elaborarli per creare il rapporto di riepilogo. `CollectOnly` Questo valore indica che lo script deve solo raccogliere i dati e non creare il rapporto. `ProcessOnly` Questo valore indica che lo script deve importare i dati da un insieme di file CSV ed elaborarli per creare il rapporto di riepilogo. Il parametro SummariseFiles viene utilizzato per fornire allo script l'elenco dei file da elaborare.
MoveFilestoArchive	Specifica che lo script deve spostare i file in una cartella compressa dopo l'elaborazione.
LoadExchangeSnapin	Specifica che lo script deve caricare i comandi di Exchange. Questo parametro è utile quando è necessario eseguire lo script dall'esterno di Exchange Management Shell, ad esempio in un'attività pianificata.

Esempio di CollectReplicationMetrics.ps1

Nell'esempio seguente vengono raccolti i dati relativi a un'ora da tutti i server nel gruppo di disponibilità del database "DAG1", campionati a intervalli di un minuto, e viene quindi generato un rapporto di riepilogo. Viene inoltre utilizzato il parametro ReportPath, a causa del quale lo script posiziona tutti i file nella directory corrente.

CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath

Nell'esempio seguente vengono letti i dati da tutti i file che corrispondono a "CounterData*" e viene quindi generato il rapporto di riepilogo.

CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath

Cmdlet Get-MailboxDatabaseCopyStatus

Script CheckDatabaseRedundancy.ps1

Come indicato dal nome, l'obiettivo dello script CheckDatabaseRedundancy.ps1 è monitorare la ridondanza dei database delle cassette postali replicati con la convalida di almeno due copie configurate, integre e aggiornate e generare un avviso quando è presente solo una copia integra di un database replicato. In questo caso, vengono conteggiate entrambe le copie attiva e passiva per la determinazione della ridondanza.

Quando si installa il ruolo server Cassette postali, lo script CheckDatabaseRedundancy.ps1 viene automaticamente configurato da Exchange per essere eseguito come un'attività pianificata di nome Database One Copy Alert. Per impostazione predefinita, l'attività pianificata di nome Database One Copy Alert è configurata per essere eseguita ogni 60 minuti. Per modificare tale comportamenti e le impostazioni dell'attività pianificata, è possibile utilizzare l'utilità di pianificazione di Windows. Lo script è progettato per verificare innanzitutto l'appartenenza al gruppo di disponibilità del database. Pertanto, se il server Cassette postali non è membro del gruppo di disponibilità del database, lo script termina immediatamente.

Lo script può essere eseguito anche in modo interattivo dalla cartella scripts. Quando si esegue lo script in modo interattivo, è necessario specificare un nome di database o il nome di un membro del gruppo di disponibilità del database. Per specificare un database viene utilizzato il parametro MailboxDatabaseName e per specificare un membro del gruppo di disponibilità del database viene utilizzato il parametro MailboxServerName. Quando viene eseguito in modalità interattiva nella console, lo script esegue il controllo di ridondanza solo una volta e visualizza CurrentState (rosso o verde) sulla schermata.

Analogamente ad altri script e cmdlet, CheckDatabaseRedundancy.ps1 può anche essere eseguito in modalità di monitoragggio e può generare eventi con l'aggiunta del parametro MonitoringContext. L'attività pianificata creata da Exchange esegue lo script in modalità di monitoraggio. In tale modalità lo script può essere richiamato anche da una soluzione di monitoraggio, ad esempio Microsoft System Center Operations Manager (SCOM). In modalità di monitoraggio, lo script genera eventi con avvisi di colore rosso e verde nel registro eventi dell'applicazioni del server locale. Un evento con avviso di colore rosso (ID evento 4113) viene generato solo se il database è stato in modalità "rosso" per più di 20 minuti (non consecutivi, riferito alla durata) nell'esecuzione dello script della durata di un'ora e un evento di colore verde (ID evento 4114) quando il database è stato in modalità "verde" per 10 minuti consecutivi. Per impostazione predefinita, una volta generato un evento di colore rosso, l'evento continuerà a essere segnalato ogni 15 minuti.

Inoltre, lo script dispone di alcune opzioni utili. Ad esempio, è possibile aggiungere il parametro ShowDetailedErrors per ottenere maggiori informazioni sugli errori verificatisi e aggiungere il parametro Verbose per ulteriori informazioni sulla risoluzione dei problemi. Lo script include anche il parametro SendSummaryMailTos utilizzabile per inviare un rapporto di riepilogo via posta elettronica a un elenco di indirizzi di posta elettronica specificati quando l'esecuzione dello script è terminata. Ciò consente all'amministratore di esaminare rapidamente i rapporti su base oraria per controllare se si sono verificati problemi di ridondanza. Se si utilizza la funzionalità di posta elettronica, sarà necessario includere il parametro SummaryMailFrom ogniqualvolta viene utilizzato il parametro SendSummaryMailTos.

Microsoft consiglia di eseguire lo script regolarmente nell'ambito delle normali operazioni di monitoraggio, utilizzando l'attività pianificata automatizzata o un sistema di monitoraggio quale SCOM. Per assicurarsi che la ridondanza del database non venga compromessa per lunghi periodi, eseguire lo script ogni 60 minuti. Lo script include un parametro denominato TerminateAfterDurationSecs che, se impostato su valori come -1 o 0 durante l'esecuzione dello script, può essere utilizzato per eseguire lo script una quantità infinita di volte.

Se non si utilizza una soluzione di monitoraggio come SCOM, è consigliabile consentire all'attività pianificata creata automaticamente di automatizzare e pianificare l'esecuzione dello script.

Nell'utilità di pianificazione di Windows Server 2008 SP2 si verificano dei problemi noti che possono determinarne l'arresto anomalo quando è stata pianificata un'attività di lunga durata. In Windows Server 2008 R2 questi problemi non esistono. Pertanto, se possibile, eseguire lo script da Windows Server 2008 R2. Se lo script non può essere eseguito da Windows Server 2008 R2 e viene eseguito da Windows Server 2008 SP2, è consigliabile apportare due modifiche. In primo luogo, anziché eseguire lo script con l'eliminazione temporanea incorporata di 60 minuti, eseguirlo ogni 5 minuti utilizzando i seguenti parametri:

CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

In secondo luogo, se possibile utilizzare SCOM per definire il comportamento di eliminazione temporanea (ad esempio, se si registrano 3 eventi con avvisi di colore rosso in un periodo di 20 minuti, viene generato un avviso; se si registra un evento con avviso di colore verde, lo stato CurrentState diventa di colore verde).

Se l'attività pianificata Database One Copy Alert viene modificata o rimossa, è possibile eliminarla e ripianificarla tramite il comando seguente:

schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY

Sostituire i parametri nello script precedente con i parametri che si desidera utilizzare. Nello script sono anche descritti i parametri aggiuntivi utilizzabili.

Quando si utilizza lo strumento della riga di comando schtasks per creare un'attività pianificata, l'opzione /TR può avere una lunghezza massima di 261 caratteri. Nell'esempio precedente questo limite viene superato. Se i parametri e i percorsi utilizzati determinano il superamento di 261 caratteri nell'opzione /TR, è necessario creare manualmente l'attività pianificata utilizzando l'applet utilità di pianificazione nel menu degli strumenti amministrativi. In alternativa, è possibile copiare e incollare il seguente XML in Blocco note, modificarlo in modo adeguato, salvarlo come file XML e importarlo utilizzando l'applet utilità di pianificazione.

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2010-05-11T15:55:47</Date>
    <Author>administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-05-11T15:55:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
    </Exec>
  </Actions>
</Task>

Cmdlet Get-MailboxDatabaseCopyStatus

Monitoraggio della disponibilità elevata e della resilienza del sito

Cmdlet Get-MailboxDatabaseCopyStatus

Stato della copia del database

Esempi di Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Test del cmdlet Test-ReplicationHealth

Esempio di Test-ReplicationHealth

Registrazione degli eventi del canale Crimson

Script CollectOverMetrics.ps1

Parametri dello script CollectOverMetrics.ps1

Esempi di CollectOverMetrics.ps1

Script CollectReplicationMetrics.ps1

Parametri dello script CollectReplicationMetrics.ps1

Esempio di CollectReplicationMetrics.ps1

Script CheckDatabaseRedundancy.ps1

Risorse aggiuntive