Whitelist di un dominio per il filtro contenuti di Exchange 2010

Ciao a tutti, un post molto veloce...


Questo script permette di aggiungere un dominio alla whitelist del filtro contenuti di Exchange 2010. Permette di DELEGARE questo compito a qualcun'altro, che magari non si intende di powershell, in quanto richiede il dominio da aggiungere in una simpatica finestrella con un input di testo, che può essere compilata da chiunque.

L'avevo scritto tempo fa per un exchange 2007 ed ora l'ho aggiornato per la nuova versione di questo meraviglioso server.

Leggendolo, inoltre, ci si spiega per sommi capi anche come richiamare oggetti visual basic da powershell (WOW!).

Per eseguirlo, basta trascinare il file (nominatelo con estensione ".ps1") nella console Exchange Management Shell e premere invio.

più che DIMEZZARE i tempi di backup di un DAG Exchange 2010 - livello medio

Ciao a tutti, mi è capitato di osservare qualche problemino strano sul backup di un DAG exchange 2010.

DAG (Database Access Group) è un sistema Exchange ad alta affidabilità che, mediante la replica dei database delle cassette postali su più servers, mantenendone attiva una sola copia, permette di ovviare ai problemi di un singolo server in maniera automatica e quasi trasparente per l'utente.
Questa tecnologia si basa "oscuramente" sul cluster di failover di Microsoft.
Dico "oscuramente" perchè non si ha il controllo di tutte le risorse del cluster, e ci si trova ad avere una gestione "splittata" tra le console di Exchange e quella di Failover Cluster.


Ho 4 servers di Exchange, 2 in un sito e 2 in un altro, geograficamente distante.
I software di Backup Cluster-aware e ExchangeVSS-aware permettono di fare il backup della soluzione Exchange senza preoccuparsi di quale sia il server attivo (e se sia online oppure offline per un guasto o una  manutenzione).
In poche parole, questi software si rivolgono all'IP del cluster, sia esso assegnato ad un nodo o ad un altro dei servers facenti parte del DAG (che sono automaticamente anche nodi del failover cluster).

Questa architettura può generare alcuni problemi di performance (ma anche di altra natura):

1- se il cluster group è sul server 1, nel sito primario, e il database delle cassette postali ATTIVO è sul server 2, sempre nel sito primario, il software di backup interroga il server1, chiedendogli di passare il database. Questo poi interroga il server 2.... con il risultato che l'agente del sw di backup sta girando inutilmente nel network-spazio.... praticamente il server del backup chiama server 1, che chiama server 2 ....

2- se il cluster group è addirittura girato su un nodo del sito SECONDARIO, il backup è forzato a passare dalla WAN.

nel caso 1 vedremmo le performances del nostro backup degradarsi anche del 300% o più, nel caso 2... probabilmente non basterebbe tutta la notte a terminare il backup e, se configurato bene, si auto-terminerebbe, fallendo.

Queste ( ed altre) cose possono succedere perchè il cluster group (che detiene l'indirizzo IP del DAG) NON è forzato ad attivarsi sul server che detiene la copia attiva del DB.



Del resto questo è logico, dato che i servers di exchange possono detenere più Database attivi su più servers. Potremmo anche avere un database attivo per ogni server con utenti che si connettono all'infrastruttura in base a quale sito e poi a quale database ospita la loro cassetta postale.
in questa condizione il server 1 deterrebbe la copia attiva di DB1 e le repliche di DB2 DB3 e DB4, il server 2 deterrebbe la copia attiva di DB2 e le replice di DB1, DB3 e DB4, e così via.

... se poi, come nel mio caso, il software di backup si crea un PROPRIO GRUPPO CLUSTER, con cui comunicare.... ...le cose si complicano non poco.


Ma torniamo a noi. Vediamo di "PETTINARE" la situazione.
Come fare in modo che l'agente di backup giri sullo stesso server che detiene la copia attiva del database delle cassette postali che vogliamo backuppare, in modo che i nostri backup siano sempre "scattanti"?


Powershell ha le risposte...