Le cassette postali di un database vengono messe in quarantena in un ambiente con System Center Operations Manager

Articolo originale pubblicato giovedì 28 giugno 2012

Aggiornamento 03/07/2012: la sezione Soluzione alternativa è stata estesa in modo da includere ulteriori dettagli.

Desideriamo richiamare la vostra attenzione su un problema che abbiamo notato di recente in CSS, per cui molte cassette postali nello stesso database delle cassette postali vengono messe in quarantena apparentemente senza alcun motivo. Controllando il registro delle applicazioni, troverete numerosi eventi 10018 con un testo contenente le informazioni seguenti.

Nome registro: Applicazione
Origine: MSExchangeIS
ID evento: 10018
Categoria attività: Generale
Livello: Errore
Descrizione:
La cassetta postale per l'utente <guid>: /o=Contoso /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserMailbox è stata messa in quarantena. L'accesso alla cassetta postale verrà limitato agli accessi amministrativi per le prossime 6 ore.

L'ID evento 5410 seguente verrà inoltre visualizzato nel registro eventi Microsoft-Exchange-Troubleshooters/Operational per ogni cassetta postale messa in quarantena dallo strumento di risoluzione dei problemi relativi allo spazio per database:

Nome registro: Microsoft-Exchange-Troubleshooters/Operational
Origine: Spazio database
ID evento: 5410
Livello: Avviso
Parole chiave: Classico
Descrizione:
Lo strumento di risoluzione dei problemi relativi allo spazio per database ha messo in quarantena la cassetta postale <guid> nel database <NomeDB>.

In tale evento è fondamentale l'ultima frase, ovvero "Lo strumento di risoluzione dei problemi relativi allo spazio per database". Negli ambienti in cui è stato distribuito System Center Operations Manager, per impostazione predefinita è attivo un monitoraggio per verificare lo spazio su disco libero per volumi di registri e database. Tale monitoraggio si avvale dello script di PowerShell Troubleshoot-DatabaseSpace.ps1, che viene fornito con Exchange 2010 per impostazione predefinita. Per ulteriori informazioni sullo script Troubleshoot-DatabaseSpace.ps1, leggere l'articolo seguente su TechNet:

Gestione della crescita del log di database mediante Script DatabaseSpace.ps1 Troubleshoot in Shell
https://technet.microsoft.com/en-us/library/ff477617.aspx

Il team di System Center Operations Manager ha di recente reso disponibile il Service Pack 2 per Exchange Management Pack. Tra le diverse modifiche, è stato rettificato un valore di timeout per l'esecuzione dello script. Prima del Service Pack, il valore di timeout era di 300 secondi e il monitoraggio era impostato per attivarsi ogni 5 minuti. Questo significava che, in molte organizzazioni di grandi dimensioni, virtualmente si verificava sempre il timeout dello script, che quindi non veniva mai completato. Dopo l'installazione dell'aggiornamento, il nuovo valore di timeout è di 1200 secondi. Il monitoraggio inoltre ora viene eseguito ogni ora anziché ogni 5 minuti. Come effetto di tale modifica, lo strumento di risoluzione dei problemi ora esegue in modo affidabile codice che non veniva eseguito prima dell'aggiornamento SP2. Lo strumento di risoluzione dei problemi ha quindi trovato un bug nel contatore PerfMon dell'archivio informazioni utilizzato dallo strumento stesso per determinare la frequenza di generazione dei byte di registro per il database (la frequenza PerfMon può superare 1,0E+19 byte/ora). Quando la frequenza oraria stimata per la generazione dei registri supera la capacità dello spazio su disco restante del volume del registro o del database, lo strumento di risoluzione dei problemi inizia a mettere in quarantena le cassette postali per impedire che tale generazione utilizzi tutto lo spazio disponibile, causando lo smontaggio del database. Tale situazione sembra verificarsi per lo strumento di risoluzione dei problemi quando il contatore PerfMon ha un valore bogus. Tale contatore viene aggiornato ogni minuto e non dovrebbe avere un valore bogus per più di 1 minuto. Questa condizione quindi non si verifica frequentemente, ma con un moderato grado di probabilità.

Quali sono gli effetti per l'utente?

Come spiegato nell'articolo su TechNet, la funzione principale dello script è quella di tenere traccia della frequenza di generazione del registro e di verificare lo spazio su disco libero per volumi di registri e database. Quando lo script viene eseguito, utilizza un contatore PerfMon di archiviazione per determinare tale frequenza e calcola se la frequenza corrente farà esaurire lo spazio su disco entro la soglia di ore impostata (l'impostazione predefinita è di 12 ore). In caso affermativo, facoltativamente inizierà a mettere in quarantena le cassette postali (fino a un massimo di 150 alla volta). Lo script quindi metterà facoltativamente in quarantena anche le cassette postali la cui percentuale di spazio su disco libero scende al di sotto del valore specificato. Il valore di percentuale predefinito è del 25%. Per mettere in quarantena le cassette postali quando si verifica una di queste condizioni, è necessario passare il parametro –Quarantine allo script.

Il monitoraggio utilizzato da SCOM 2007 e versioni successive utilizza il parametro Quarantine per impostazione predefinita e non sono supportate opzioni per modificare tale comportamento perché il Management Pack è bloccato. Questo significa che, se lo spazio su disco libero per il database o il volume del registro di un database scende al di sotto del 25% E se la frequenza di generazione del registro viene calcolata allo scopo di utilizzare lo spazio su disco restante entro le successive 12 ore, gli utenti che presentano un utilizzo più intenso verranno messi in quarantena. Quando vi sono numerose cassette postali in un database, molte cassette postali possono essere messe in quarantena in un breve periodo di tempo.

Come è possibile procedere?

Il fatto di avere molte cassette postali in quarantena ovviamente non è un funzionamento auspicabile, in quanto causa interruzioni per i relativi utenti, anche se è sicuramente preferibile all'alternativa di avere l'intero database smontato per mancanza di spazio, condizione che causerebbe un'interruzione per tutti gli utenti del database. Benché sia possibile rilasciare manualmente le cassette postali messe in quarantena rimuovendone l'ID dal Registro di sistema , questa non è una soluzione ottimale perché, alla successiva esecuzione del monitoraggio, le stesse cassette postali verranno nuovamente messe in quarantena.

Le cassette postali in quarantena vengono identificate nel percorso seguente:

Hkey_Local_Machine\SYSTEM\CurrentControlSet\Services\MSexchangeIS\Servername\Private-<guidDB>\Quarantined Mailboxes\ {GUID cassetta postale}

Desideriamo farvi sapere che siamo consapevoli di tale situazione e che stiamo lavorando per implementare una correzione. Mentre lavoriamo per individuare il modo migliore per risolvere definitivamente il problema, vogliamo illustrarvi una soluzione alternativa che può essere implementata per impedire che le cassette postali vengano messe in quarantena. Nel frattempo, per evitare che ulteriori clienti incorrano nello stesso problema, abbiamo temporaneamente rimosso Exchange 2010 SP2 Management Pack dall'Area download.

Soluzione alternativa

Creare una sostituzione (Override) per disabilitare i monitoraggi che verificano lo spazio su disco libero. In questo modo si impedirà l'esecuzione del file Troubleshoot-DatabaseSpace.ps1.

Quando si creano sostituzioni, è consigliabile inserirle in un nuovo Management Pack specificamente per le personalizzazioni all'interno di System Center Operations Manager. Ciò consente di gestire in modo facile e rapido le sostituzioni o altre impostazioni personalizzate. Se non si dispone già di un Management Pack a tale scopo, è possibile crearne uno eseguendo i passaggi seguenti:

1. In Operations Console fare clic sul pulsante Amministrazione. Nel riquadro Amministrazione fare clic con il pulsante destro del mouse su Management Pack e quindi scegliere Crea Management Pack. Verrà visualizzata la procedura guidata Crea un Management Pack (Create a Management Pack).
2. Nella pagina Proprietà generali (General Properties) digitare un nome per il Management Pack in Nome (Name), il numero di versione corretto in Versione (Version) e una breve descrizione in Descrizione (Description). Fare clic su Avanti (Next) e quindi su Crea (Create).

Dopo avere designato un Management Pack per le sostituzioni, crearle per i 4 monitoraggi elencati di seguito:

In System Center Operations Manager passare al modulo Creazione e modifica e quindi a Monitoraggi in Oggetti Management Pack. I monitoraggi possono essere disabilitati impostando una sostituzione e scegliendo di disabilitare il monitoraggio per tutti gli oggetti della classe Spazio su disco logico copia database (DB) (For all objects of class: Database Copy DB Logical Disk Space), come illustrato di seguito:

Selezionare la casella di controllo accanto ad Attivato (Enabled) e quindi modificare il valore di sostituzione selezionando False:

Nella stessa finestra di dialogo Proprietà di sostituzione ricordarsi di selezionare il Management Pack designato per le personalizzazioni.

In questo momento, se si verifica il problema delle cassette postali messe in quarantena, l'opzione per disabilitare i monitoraggi rappresenta l'unica soluzione alternativa disponibile. Sappiamo che tale soluzione potenzialmente impedirà agli amministratori di ricevere avvisi quando lo spazio su disco è scarso, ma è sicuramente l'opzione migliore per ovviare al problema finché non viene rilasciata una vera correzione.

Notare che, quando lo spazio su disco del database è scarso, verrà comunque inviato un avviso se l'unità del registro delle transazioni coesiste con il database, in quanto viene generato da una regola diversa basata semplicemente su PerfMon.

Ben Winzenz, Kevin Carker

Questo è un post di blog localizzato. L'articolo originale è disponibile in Mailboxes on a database are Quarantined in an environment with System Center Operations Manager.