Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Tag Cloud

Archivi per la categoria 'Exchange Server 2010' Categoria


Il restore di singole mail in Exchange 2010/2013 usando Windows Server Backup

Scritto da Ivan Salvade' il 4 agosto 2014

Non è facilissimo eseguire il restore di singole mail o singole mailbox, senza usare un software di backup di terze parti, o Data Protection Manager di Microsoft.

Ipotizzando che un certo utente abbia eseguito un “hard-delete” di alcune mail, e quindi non sia più in grado di recuperarle “autonomamente”, dovrà intervenire un amministratore per il recupero delle mail da un backup precedente.

Se non si dispone di software di backup professionali, l’unica alternativa è utilizzare Windows Server Backup (2008 R2 o 2012) del server Exchange.  Purtroppo il suo limite principale è quello di saper restorare solo interi database, e non direttamente singole mailbox o singole mail.

Quindi la strategia generale da seguire è la seguente :

  1. Identificare il backup da utilizzare per il recupero delle mail
  2. Eseguire il restore completo del/dei database su posizione alternativa
  3. Creare il Recovery Database in Exchange
  4. Eseguire il controllo di “corretto stato” del database restorato con Eseutil
  5. Montare il database restorato nel Recovery Database
  6. Utilizzare il comando Restore-Mailbox per ripristinare le mail cancellate
  7. Smontare ed eliminare il Recovery Database

Ecco ora i dettagli delle singole fasi.

Fase 1

Dovremo utilizzare un backup che siamo certi contenga le mail da recuperare.  In molti casi andrà bene quello del giorno prima, in altri casi bisogna opportunamente scegliere backup più vecchi.   Identificare il supporto corretto, ed “agganciarlo” (se già non lo è) al server Exchange (per esempio, potrebbe essere un disco USB o un disco su NAS mappato tramite iSCSI).

Fase 2

Windows Server Backup (quello presente in Windows Server 2008 R2 o Windows Server 2012), esegue il backup di Exchange a livello applicativo e a livello di volume, utilizzando il servizio VSS (Volume Shadow-Copy Service).  Questo significa che il backup sarà perfettamente consistente, grazie alla collaborazione tra Windows Server Backup e l’Exchange VSS Writer.  Però, non è possibile indicare a Windows Server Backup di backuppare solo un certo database o certe mailbox : in fase di backup, andranno selezionati tutti i volumi (interi) dove risiedono i database (.edb) e i logs di Exchange.

Questo si riflette anche nella fase di restore : non è possibile indicare di restorare solo un singolo database, ma verranno restorati tutti i DB contenuti nel backup.   Per le aziende che utilizzano un solo DB, questo non è un problema, ma per quelle che utilizzano più database, questo può rappresentare una grossa perdita di tempo.

Aprire Windows Server backup, e lanciare la procedura di restore.  Selezionare poi la data precisa del backup prescelto, utilizzando il calendario proposto dalla procedura : in grassetto sono evidenziate tutte le date per le quali esiste un backup da restorare (Fig. 1) :

exrest1.JPG      Fig. 1

Quindi si indica come elemento di restore le “Applicazioni” (se non dovesse essere disponibile la selezione, sicuramente il backup non è stato eseguito a regola d’arte e non è disponibile il restore applicativo con consistenza garantita dei database).  Fig. 2 :

exrest2.JPG      Fig. 2

Alla schermata successiva il wizard si accorge della presenza dei database (consistenti) di Exchange, e con il tasto “Visualizza Dettagli” è possibile visualizzarli.  Non è possibile restorare uno solo dei database (questo è uno svantaggio di Windows Server Backup rispetto ai software professionali). Fig. 3 :

exrest3.JPG      Fig. 3

Si devono restorare i database in un percorso alternativo (Fig. 4).  Si consiglia di utilizzare altri dischi interni del server Exchange (oppure provenienti da mappature iSCSI su NAS/SAN), sui quali ci sia sufficiente spazio per ospitare il restore di tutti i database.  Nel percorso utilizzato, dovrà essere successivamente creato il Database di Recupero (vedi passaggi successivi).

exrest4.JPG      Fig. 4

Fase 3

Si deve ora creare il Recovery Database, utilizzando il percorso indicato nella procedura di restore.  Nel Recovery Database verrà montato il database restorato (contenente le mail da recuperare), e da questo verranno estratte le mail necessarie con re-inserimento nel database di produzione (merge).

Per creare il Recovery Database è necessario utilizzare una linea di comando Powershell :

New-MailboxDatabase  -Name “RecoveryDB”  -Server FQDN_server_exchange  -EDBFilePath “X:\RecoveryDB\percorso_originale_file_edb”  -LogFolderPath “X:\Recoverydb\percorso_originale_logs”  -Recovery

Quindi, ipotizzando che il database originale avesse database e logs nei seguenti percorsi :

  • Server : “EXC.Adatum.com”
  • DB : ”F:\DB1\db1.edb”
  • Logs : “G:\LOGS1″

il precedente comando diventa :

New-MailboxDatabase  -Name “RecoveryDB”  -Server VAN-EX1.adatum.com  -EDBFilePath “X:\RecoveryDB\F_\DB1\db1.edb”  -LogFolderPath “X:\RecoveryDB\G_\LOGS1”  -Recovery

Nella seguente Fig. 5, ecco un esempio di esecuzione del suddetto comando, ipotizzando di avere un database iniziale di nome “Accounting” su un Mailbox Server “VAN-EX1.adatum.com”, con database “Accounting.edb” posizionato in “D:\AccountingDB” e i logs relativi posizionati in “C:\AccountingLogs” :

ese1.JPG    Fig. 5  (clicca sulla foto per ingrandirla)

Nella Fig. 5 è chiaramente visibile il warning “This database must be brought into a clean shutdown state before it can be mounted”.  Lo stato di “Clean shutdown” è raggiungibile con la procedura della prossima Fase 4.

Fase 4

Il Database appena restorato potrebbe essere in uno stato “non corretto” (per esempio con alcuni logs non ancora applicati al database).  Questo stato “sporco” non consentirebbe il suo montaggio nel database di recupero.

Bisogna allora utilizzare l’utility “Eseutil” per controllare lo stato ed eventualmente riparare il database.

La sintassi Eseutil per il controllo del database è il seguente (posizionare il prompt dei comandi nel preciso percorso dove risiede il database) :

Eseutil /mh  nome_database.edb 

In Fig. 6 è riportata l’esecuzione del suddetto comando sul database “Accounting.edb” appena restorato, con l’indicazione di “Dirty Shutdown” (a causa del log 39 mancante, in questo esempio) :

ese2.JPG     Fig.6  (clicca sulla foto per ingrandirla)

La sintassi di Eseutil per la riparazione del database (Soft Recovery) in caso di “Dirty Shutdown” è il seguente (posizionare il prompt dei comandi nel preciso percorso dove risiede il database) :

Eseutil /R Exx /i /d /l:percorso_dove_risiedono_i_Logs (Exx può essere E00, E01, E02, E03….  prefisso dei logs del database interessato)

In Fig. 7 ecco l’esecuzione del suddetto comando, ipotizzando che i logs si trovino nel percorso “C:\AccountingLogs”, e quindi indicando tale percorso al comando con il parametro “/l”.  In caso di database e logs nello stesso percorso, tale parametro poteva essere omesso :

ese3.JPG     Fig. 7  (clicca sulla foto per ingrandirla)

In Fig. 8 è stato rieseguito il comando “Eseutil /mh” per confermare la correzione dello stato in “Clean Shutdown” :

ese4.JPG     Fig. 8  (clicca sulla foto per ingrandirla)

Fase 5

Si monta ora il database restorato nel Database di Recupero.  Il comando powershell per l’operazione è il seguente :

Mount-Database “RecoveryDB   (usare il nome del vostro database di recupero)

Nella console grafica di Exchange di Fig. 9, si nota ora il database di recupero correttamente montato :

ese5.JPG     Fig. 9

Fase 6

Ora è necessario identificare, nel database di recupero,  le mail da restorare ed eseguirne il ripristino nel database di produzione.   Anche qui, non esiste un wizard grafico che possa eseguire la procedura, ma siamo costretti a ricorrere a comandi di powershell.

Se si utilizza Exchange 2010 RTM, l’unico comando disponibile sarebbe : Restore-Mailbox

Da Exchange 2010 SP1 in poi, diventa disponibile anche il comando New-MailboxRestoreRequest .   Ufficialmente, sarebbe quest’ultimo il comando da utilizzare, mentre Restore-Mailbox assumerebbe lo stato “deprecato”.

In realtà, Restore-Mailbox è sempre funzionante, ed è dotato della possibilità di estrarre mail dal Recovery Database in base ad intervalli di tempo (per esempio, estrarre e recuperare tutte le mail tra il 10 aprile 2014 e il 10 maggio 2014) : questa operazione non è (stranamente!) nelle capacità del comando New-MailboxRestoreRequest.

Entrambi i comandi hanno comunque parecchi parametri che permettono di localizzare mail all’interno del database di recupero, in base a diverse condizioni impostabili (es. per tipo di elemento, per data, per cartella, per parole contenute nelle mail, ecc.). Consiglio di analizzare tali parametri consultando l’help in linea dei due comandi ai seguenti link :

http://technet.microsoft.com/it-it/library/bb125218(v=exchg.141).aspx

http://technet.microsoft.com/it-it/library/ff829875(v=exchg.141).aspx

Ecco allora un esempio di linea di comando per recuperare mail in base ad intervalli di tempo :

Restore-Mailbox   -Identity nome_mailbox_da_recuperare   -RecoveryDatabase nome_recovery_database   -StartDate 04/10/2014   -EndDate 05/10/2014

Prima di eseguire in produzione il comando precedente, se ne possono testare gli esiti utilizzando il parametro “-ValidateOnly“.  Ecco l’esecuzione in Fig. 10, dove ipotizzo di voler ripristinare le mail tra il 10 aprile e il 10 maggio di un’utenza esemplificativa (tale “Michiyo”) :

ese6.JPG     Fig. 10 (clicca sulla foto per ingrandire)

Se gli esiti della simulazione sono soddisfacenti, si può eseguire il comando in produzione.  L’esempio delle Figg. 11 e 12 esegue il ripristino delle mail dell’utenza Michiyo, comprese tra il 10 aprile e il 10 maggio 2014.  Ricordo che le mail restorate vengono “unite” a quelle già presenti in produzione, che quindi non vengono perse.  E’ attivo per default anche il controllo dei duplicati, in modo che le mail già esistenti in produzione non vengano ripristinate.

ese7.JPG     Fig. 11 (clicca sulla foto per ingrandire)

ese8.JPG     Fig. 12 (clicca sulla foto per ingrandire)

Fase 7

Una volta terminata l’operazione di restore, è possibile smontare ed eliminare il database di recupero.

Smontaggio ed eliminazione possono essere eseguiti con l’unico comando :

Remove-MailboxDatabase   -Identity “RecoveryDB”

Ricordare di eliminare a mano logs e DB dalle cartelle del database di recupero : questo non viene eseguito in automatico.

Buon restore!!!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010, Exchange Server 2013 | Nessun commento »

Limitare l’uso di RAM su Exchange Server 2010

Scritto da Ivan Salvade' il 20 ottobre 2013

By design, in Exchange Server 2010 il servizio Information Store (store.exe) tende ad occupare quanta più memoria possibile sul server.

Questo è accettabile : l’uso della RAM, piuttosto che del paging su disco, non fa altro che migliorare le performance del server Exchange.

Però ho notato alcuni casi in cui l’utilizzo di RAM da parte di Exchange è addirittura eccessivo : in un caso limite, addirittura, la completa assenza di RAM libera sul server, causava il non corretto funzionamento del servizio “User Profile Service”, responsabile, tra le altre cose, delle fasi di logon e logoff degli utenti.  Il problema era grave, in quanto non era più possibile un logoff ordinato dell’utenza amministrativa, neanche dopo aver comandato un restart del server.   Il brutale workaround era quello di spegnere e riaccendere fisicamente il server.

In casi come questo, diventa necessario intervenire sul sistema, espandendo fisicamente la RAM del server, oppure limitandone l’utilizzo da parte di Store.exe.

Tecnicamente, la RAM usata da Store.exe è in gran parte dedicata al “Database Cache” : più è alta la cache del database, minori sono le operazioni di lettura sul database, e maggiore è il numero di database supportabili da Exchange.

La grandezza della Database Cache è indicati dai seguenti contatori di performance (rilevati su Exchange 2010 SP3), che riporto, per comodità di consultazione, sia in lingua italiana che inglese :

  • Database di MSExchange\Dimensione Cache del Database (MB) (Information Store)
  • Database di MSExchange\Dimensione Effettive della Cache del Database (MB) (Information Store)
  • MSExchange Database\Database Cache Size (MB) (Information Store)
  • MSExchange Database\Database Cache Size Effective (MB) (Information Store)

Il primo dei due contatori indica la dimensione della cache del database, così come ”comandata” dal default di sistema o da opportuni parametri di configurazione (che vedremo tra poco).

Il secondo dei due contatori indica l’effettiva dimensione della cache del database.

Ecco un esempio di monitoraggio dei due contatori, su un server Exchange 2010 SP3 con 24 GB di RAM, e la cache del database impostata tra 3 e 4 GB :

cache1.jpg      Fig. 1 : monitoraggio dei parametri (clicca sulla figura per ingrandire)

I parametri di configurazione della Database Cache si trovano in Active Directory, e sono gestibili tramite Adsi Edit.  Bisogna collegarsi alla Configuration Partition di Active Directory, e posizionarsi nel seguente nodo :

CN=InformationStore,CN=NomeServerMailbox,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=NomeOrganizzazione,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Dominio,DC=SuffissoDominio

Nelle proprietà dell’oggetto “CN=InformationStore”, troveremo i seguenti attributi :

  • MSExchESEParamCacheSizeMin
  • MSExchESEParamCacheSizeMax

Questi due parametri sono per default non impostati (<Not Set>) : questo significa che Store.exe gestirà in maniera completamente dinamica il consumo di RAM.  Quindi, salvo situazioni di richiesta di memoria da parte di altre applicazioni, è lecito attendersi che Store.exe espanda progressivamente il suo consumo di RAM, fino ad occupare tutta quella disponibile sul server.

E’ però possibile compilare questi parametri con opportuni valori, per garantire un controllo ottimale della grandezza della cache del database.

I valori devono essere assolutamente multipli di 32k (ovvero 32768 bytes), in quanto Exchange 2010 lavora con pagine di RAM da 32k (a differenza di Exchange 2007, che lavorava con pagine di RAM da 8k).

Esistono delle soglie minime (sotto le quali non bisogna assolutamente scendere) e delle soglie di default.  Sono riportate al seguente articolo TechNet :

http://technet.microsoft.com/en-us/library/ee832793.aspx

Rispettando le soglie stabilite dall’articolo, vediamo ora come è possibile regolare in maniera personalizzata la dimensione della cache.

Innanzitutto bisogna sempre lavorare su valori multipli di 32k.

Si decide a quanti Gb si vuole limitare l’uso della cache, si trasforma il valore in Kb, e si divide per 32 (ricordando che 1 GB=1024 Mb, e 1 Mb=1024 Kb).

Quindi, supponendo di voler limitare la cache a 8 Gb, il calcolo è il seguente :

8 Gb X 1024 = 8192 Mb X 1024 = 8.388.608 Kb / 32 = 262.144 (questo è il numero di pagine di RAM da 32 Kb da indicare ad Exchange).

Ora bisogna capire come impostare questo valore nei due parametri MSExchESEParamCacheSizeMin e MSExchESEParamCacheSizeMax.

N.B. : una volta modificati i parametri, bisogna sempre eseguire un restart del servizio “Microsoft Exchange Information Store” (”Archivio Informazioni di Microsoft Exchange”). Non serve un restart dell’intero server.

Lo scopo del mio esempio è impostare la grandezza della cache del database in modo che non superi gli 8 GB circa di RAM.

Eseguirò tre prove, con relativi campionamenti dei contatori detti in precedenza :

  1. Impostare solo il parametro MSExchESEParamCacheSizeMax
  2. Impostare entrambi i parametri uguali
  3. Impostare MSExchESEParamCacheSizeMax in modo che sia superiore a MSExchESEParamCacheSizeMin

Prova 1 : impostare solo il parametro MSExchESEParamCacheSizeMax  al valore 262.144

Ecco in Fig. 2 l’impostazione del parametro MSExchESEParamCacheSizeMax a 262.144 (cioè 8 GB di RAM di limite), lasciando il parametro MSExchESEParamCacheSizeMin non impostato :

cache2.jpg   Fig. 2 : un solo parametro impostato

Ed ecco in Fig. 3 l’esito del monitoraggio dei contatori, dopo un restart del servizio Information Store e un periodo di almeno 20 minuti per l’assestamento dei valori :

cache3bis.jpg    Fig. 3 : clicca per ingrandire

Si nota come entrambi i parametri si attestino intorno ai 14 GB, cioè più o meno al valore massimo raggiungibile su questo server.  In questa situazione, quasi tutti i 24 GB di RAM totali del server risultano in uso.   Non è quindi ciò che si voleva.

Prova 2 : impostare entrambi i parametri allo stesso valore

Ecco in Fig. 4 l’impostazione di entrambi i parametri al valore 262.144 (cioè 8 GB di RAM di limite) :

cache4.jpg Fig. 4 : parametri con lo stesso valore

Ed ecco in Fig. 5 l’esito del monitoraggio dei contatori, dopo un restart del servizio Information Store e un periodo di almeno 20 minuti per l’assestamento dei valori :

cache5bis.jpg   Fig. 5 (clicca per ingrandire)

In questo caso si nota come entrambi i parametri si attestino intorno ai 2 GB di RAM, che rappresentano all’incirca la dimensione minima possibile della cache del database su un server Exchange.   Quindi, anche in questo caso non abbiamo raggiunto i risultati previsti.

Prova 3 : impostare MSExchESEParamCacheSizeMax ad una valore superiore rispetto a MSExchESEParamCacheSizeMin

Ecco in Fig. 6 l’impostazione di MSExchESEParamCacheSizeMax a 262.144 (cioè 8 GB di RAM) e di MSExchESEParamCacheSizeMin ad un valore inferiore : 229.376 (cioè 7 GB di RAM) :

cache6.jpg Fig. 6 : msExchESEParamCacheSizeMax con valore superiore

Ed in Fig. 7 il solito esito del monitoraggio dei contatori, dopo un restart del servizio Information Store e un periodo di almeno 20 minuti per l’assestamento dei valori :

cache7.jpg      Fig. 7 : clicca per ingrandire

Questa volta si nota che la dimensione comandata della cache si assesta intorno ai 7 GB (il parametro MSExchESEParamCacheSizeMin) e quella effettiva intorno ai 9 GB (circa 1 GB oltre il valore del parametro MSExchESEParamCacheSizeMax) : questa grandezza massima, però, lasciando lavorare per parecchie ore il server Exchange, si attesterà mediamente intorno agli 8 GB previsti, come mostrato in Fig. 8 :

cache7b.jpg      Fig. 8 : clicca per ingrandire

Con questi settaggi raggiungiamo finalmente i risultati voluti, cioè la regolazione della cache del database tra due ben precisi valori (tra 7 e 8 GB, nel mio esempio).

La conclusione è quindi questa :  non è sufficiente compilare solo il parametro MSExchESEParamCacheSizeMax (come alcuni articoli su Internet riportano), ma devono essere compilati entrambi i parametri, ed in modo che MSExchESEParamCacheSizeMax sia superiore a MSExchESEParamCacheSizeMin.  Qualunque altra combinazione dei due parametri non porta ai risultati voluti.

Buona regolazione!!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | 2 Commenti »

Bloccare lo spam interno (dal proprio dominio di posta) in Exchange Server

Scritto da Ivan Salvade' il 7 ottobre 2013

Questo articolo si applica a : Exchange Server 2007, 2010, 2013

Capita spesso di ricevere mail di spam, dove l’indirizzo di posta del mittente rappresenta un’utenza vostra interna (es. Nomeutente@NomeVostroDominioDiPosta ) o addirittura rappresenta voi stessi (cioè ricevete spam da voi stessi!!!).

Questo capita perché gli spammer sono riusciti ad eseguire lo spoofing del vostro indirizzo di posta (o di quello di altre persone nella vostra azienda), inserendolo poi nelle intestazioni SMTP delle mail di tipo spam che essi lanciano.

Con i software antispam professionali, tipicamente, ci si difende agevolmente da questo tipo di spam.  Ma per chi vuole utilizzare esclusivamente i filtri antispam nativi (o altre impostazioni) di Exchange 2007/2010/2013, la difesa non è così immediata.

L’impostazione di default dei server Exchange è quella di ricevere qualunque mail proveniente dai cosiddetti “Domini Accettati” (”Accepted Domains”), inseriti nella configurazione del trasporto.  E il vostro dominio pubblico di posta è sicuramente configurato come ”Dominio Accettato”.  Inoltre, il Connettore di Ricezione che riceve mail da Internet è sicuramente configurato a non richiedere l’autenticazione ai mittenti delle mail (giustamente), altrimenti non si riceverebbero più mail dal mondo intero!

I Connettori di Ricezione di Exchange, però, hanno numerose altre autorizzazioni particolari, che si possono vedere e modificare solo con comandi di powershell.

Ecco un comando esemplificativo per visualizzare tutte le autorizzazioni assegnate ad un normale Connettore di Ricezione configurato per ricevere posta da Internet :

Get-ReceiveConnector “Nome Connettore” | Get-AdPermission | Ft User,AccessRights, ExtendedRights -Autosize

La particolare autorizzazione che ci interessa è la “MS-Exch-SMTP-Accept-Authoritative-Domain-Sender” assegnata all’identità speciale “Anonymous Logon”.  Questa autorizzazione permette a qualunque persona non autenticata (quindi anche agli spammer) di collegarsi al Connettore di Ricezione in oggetto, di dichiarare il vostro dominio di posta nell’intestazione SMTP “Mail From:”, e di essere comunque accettati.

Questa autorizzazione è assegnata ad un Connettore di Ricezione, quando esso è impostato a ricevere da Internet.

Ecco le autorizzazioni di “Anonymous Logon” su un connettore senza accesso anonimo :

rcv1.jpg   Fig 1 : se il connettore non ha l’accesso anonimo…

rcv2.jpg

Fig 2 :…. ecco quali sono le autorizzazioni di Anonymous Logon

Ecco invece come si presentano le autorizzazioni di “Anonymous Logon” su un connettore con l’accesso anonimo attivato :

rcv3.jpg   Fig. 3 : se il connettore ha l’accesso anonimo…

rcv4.jpg

Fig. 4 : …. ecco la presenza dell’autorizzazione “MS-Exh-SMTP-Accept-Authoritative-Domain-Sender”

Se un client di posta non autenticato tentasse ora di spedire mail insererendo un indirizzo di posta interno sia come mittente che come destinatario, gli esiti sarebbero questi (mail accettata!) :

rcv5.jpg

Fig. 5 : mail accettata

Il trucco per bloccare questo tipo di mail provenienti dall’esterno, sta nel rimuovere l’autorizzazione “ms-exch-smtp-accept-authoritative-domain-sender” ad “Anonymous Logon”.  Il comando per eseguire la rimozione è il seguente :

Get-ReceiveConnector “Nome Connettore” | Get-AdPermission -User “NT Authority\Accesso Anonimo” | Where {$_.ExtendedRights -Like “MS-Exch-SMTP-Accept-Authoritative-Domain-Sender”} | Remove-AdPermission

N.B. : nel precedente comando, l’identità speciale “Anonymous Logon” deve essere indicata esattamente come mostrato (cioè “NT Authority\Accesso Anonimo” se la lingua di installazione di Exchange è l’italiano, mentre deve essere indicata come “NT Authority\Anonymous Logon” se la lingua di installazione di Exchange è l’inglese.

Ecco l’esecuzione del comando :

rcv6.jpg

Fig. 6 : esecuzione del comando di rimozione dell’autorizzazione

Ed ecco ora il diverso comportamento per un client di posta non autenticato :

rcv7.jpg

Fig. 7 : mail rifiutata

Questa procedura riesce quindi a bloccare lo spam che utilizza indirizzi di posta interni “spoofati”.

Buon divertimento :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010, Exchange Server 2013 | 10 Commenti »

Conoscere i domain controller usati da Exchange

Scritto da Ivan Salvade' il 18 settembre 2013

E’ spesso utile conoscere i domain controller che un server Exchange sta utilizzando, in un certo momento.

Per esempio, durante una migrazione di Active Directory, durante la quale vengono installati nuovi domain controller, oppure vengono rimossi quelli vecchi, è utile sapere se Exchange ha già iniziato a contattare i domain controller nuovi.

Un comando di powershell utile a questo scopo è il seguente :

Get-ExchangeServer -Status | FL Name,Current*

Ecco l’esecuzione del comando in un ambiente con diversi server Exchange in esecuzione :

1.jpg      (Clicca sulla foto per ingrandire)

Il comando restituisce i domain controller utilizzati dai vari server Exchange.

Nella colonna “CurrentDomainControllers” sono riportati i domain controller utilizzati per eseguire le normali query LDAP a porta 389.

Nella colonna “CurrentGlobalCatalogs” sono riportati i domain controller con funzione di Global Catalog, utilizzati per eseguire query LDAP alla porta 3268.

Nella colonna “CurrentConfigDomainController” è riportato il domain controller scelto per eseguire letture e scritture sulla Configuration Partition di Active Directory : per esempio, la Configuration Partition di AD viene modificata in tutti i casi in cui si eseguono modifiche all’Organizzazione Exchange.

Ricordo che Exchange Server è in grado di gestire autonomamente il discovery dei domain controller, attraverso il proprio servizio DSAccess.  Quest’ultimo entra in esecuzione ogni 15 minuti circa, registrando nel log Applicazione gli eventi con codice 2080 contenenti l’elenco dei domain controllers trovati in rete.

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010, Exchange Server 2013 | Nessun commento »

Fixup per Exchange 2010 SP3 RU1

Scritto da Ivan Salvade' il 26 giugno 2013

E’ stato rilasciato il fixup per il problema delle mail accodate in Poison Queue su un server Exchange 2010 SP3 aggiornato al RU1, nello scenario in cui il server faccia uso di Transport Rules per l’inserimento di disclaimer e/o firme personalizzate in formato HTML.

Le spiegazioni sono disponibili nel mio articolo :

http://ivansalvade.it/2013/06/11/ci-risiamo-ru1-di-exchange-2010-sp3-con-problemi/

e nell’articolo Microsoft di pubblicazione del fixup :

http://support.microsoft.com/kb/2859596/en-us

  • Share/Bookmark

Pubblicato in Cafè, Exchange Server 2010 | Nessun commento »

Ci risiamo : RU1 di Exchange 2010 SP3 con problemi!!

Scritto da Ivan Salvade' il 11 giugno 2013

Aggiornamento del 25 giugno 2013 : leggere in calce all’articolo.

Ancora problemi per un Update Rollup di Exchange!!

Questa volta tocca al RU1 per Exchange 2010 SP3, rilasciato al pubblico il 29 maggio 2013.

Il problema capita in uno scenario particolare : alle aziende che utilizzano una o più Transport Rules per aggiungere alle mail in uscita il disclaimer e/o le firme personalizzate degli utenti (vedi qui come fare), con parte del contenuto formattato con tag HTML.

L’installazione del RU1 avviene senza problemi, ma non appena viene riavviato il servizio Exchange Transport, tutte le mail intercettate dalle predette Transport Rules vengono maldestramente “marcate” come dannose dal servizio di trasporto, e come tali non vengono inserite in Submission Queue ma redirette alla “Poison Queue” : questa è una speciale coda di Exchange usata per mantenere in stato ”Suspended” tutte le mail ritenute dannose per il sistema di posta.  La coda è visibile utilizzando lo strumento “Visualizzatore Code”.

Anche il tentativo di eseguire il Retry della coda non dà esito positivo, perché le mail vengono nuovamente riposizionate nella coda stessa, in quanto re-intercettate ancora dalle Transport Rules.

Il problema è grave perché praticamente tutte le mail dirette verso l’esterno vengono bloccate e sospese.  Inoltre i client Outlook presentano problemi di connessione al server Exchange.  Le mail in entrata da Internet, invece, vengono regolarmente ricevute.

Il problema mi è capitato oggi in piena produzione da un cliente, e questo ha causato 1 ora circa di fermo per le mail in uscita, il tempo di capire l’accaduto.

Il workaround temporaneo è stato quello di disabilitare le Transport Rules accennate sopra, facendo seguire un restart del Exchange Transport Service : la Poison Queue immediatamente si svuota, e tutte le mail vengono consegnate (naturalmente senza disclaimer e firme).

Se le mail in Poison Queue sono tante (come oggi nel mio caso, erano centinaia…), è utile utilizzare il seguente comando per eseguire un veloce Retry di tutti i messaggi :

Get-Message -Queue nome_server\Poison | Resume-Message

Il workaround definitivo è stata la disinstallazione ordinata del RU1 : avvenuta perfettamente, e senza necessità di riavviare il server Exchange.  Dopo la disinstallazione, riabilitare le Transport Rules : tutto torna alla normalità.

Poche ore dopo la comunicazione a Microsoft da parte mia, Ross Smith del team di sviluppo di Exchange ha ammesso il problema, promettendo un fixup.  La discussione è visibile nei commenti a questo post del team di sviluppo :

http://blogs.technet.com/b/exchange/archive/2013/05/29/released-update-rollup-1-for-exchange-server-2010-sp3.aspx

E’ la terza volta che un Update Rollup di Exchange crea problemi, anche grossi : la prima può capitare, la seconda… anche, la terza no!!

Errare è umano, perseverare è diabolico!!!  Microsoft, sveglia!!!!!!!!!!

Ritengo Exchange Server un grande prodotto, soprattutto Exchange 2010. Nei corsi che tengo, lo nomino spesso scherzosamente “trattore” : macina migliaia e migliaia di mail senza grossi problemi, non si ferma mai, qualche mio cliente si dimentica pure di averlo in rete, è molto stabile.

Non accetto che dei semplici Rollup Update (che è giusto vengano creati, sia chiaro…) mettano a repentaglio la stabilità di un sistema quasi perfetto!!!

Microsoft ha centinaia di server Exchange nella propria infrastruttura mondiale e presso i partner TAP : non è possibile non accorgersi di un problema così evidente in fase di test del Rollup!!!

Attendiamo ora il fixup. :-)

Aggiornamento del 25 giugno 2013 : Microsoft ha finalmente rilasciato un hotfix.   L’articolo che illustra la problematica e consiglia di chiedere l’hotfix a Microsoft, è il seguente :

http://support.microsoft.com/kb/2859596/en-us

L’hotfix deve essere usato solo da chi è effettivamente interessato dal problema

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | Nessun commento »

Modificare il banner di un connettore di ricezione in Exchange 2010/2013

Scritto da Ivan Salvade' il 30 maggio 2013

Il “Banner” (chiamato anche “SMTP Banner”) è quel messaggio di risposta che un server remoto di posta riceve quando si collega ad un connettore di ricezione configurato su un server Exchange.

Il banner di un certo server di posta è facilmente visibile con un Telnet alla sua porta 25 :

TELNET indirizzo_IP_o_FQDN_del_server 25

Nella sua risposta è visibile il banner, che può avere diverse forme e rendere disponibili diverse informazioni sul server stesso (a volte persino troppe, per la sicurezza).

Il banner di default che restituisce un server Microsoft Exchange è il seguente :

220 <FQDN_del_server_configurato_nel_connettore_di_ricezione> Microsoft ESMTP MAIL service ready at <data_odierna_e_ora_in_formato_24h> <fuso_orario_regionale>

Le informazioni più importanti restituite sono : il nome del server e la piattaforma (Microsoft in questo caso).

Il nome del server viene rilevato dalle proprietà del Connettore di Ricezione (Receive Connector) configurato sull’Exchange (Fig.1 ).  Se non è mai stato configurato manualmente, esso si imposta per default sul FQDN del server (es. MioServer.MiodominioActiveDirectory), e questo naturalmente vuol dire rivelare al mondo il nome interno del server e del nostro dominio Active Directory.  Direi che non è il caso!!!

Come minimo, bisogna modificare il FQDN inserendo un nome DNS pubblico della vostra azienda (es. Mail.Azienda.com), oppure il FQDN associato ai record MX registrati sui DNS pubblici (Fig. 1).

Così facendo, il banner rivelerebbe ora solo il nome pubblico, ma lascerebbe ancora visibile la piattaforma del server di posta (cioè la dicitura “Microsoft ESMTP MAIL service ready at”).

In Fig. 1 si nota la compilazione del campo FQDN del connettore di ricezione di un server Exchange 2010.  Si nota anche l’output del comando Get-ReceiveConnector, con l’attributo FQDN opportunamente compilato, e l’attributo Banner di default vuoto.

banner1.jpg      Fig. 1 (clicca sulla figura per ingrandire)

Eseguendo il comando Telnet riportato all’inizio dell’articolo, si otterrebbe il seguente output :

banner3b.jpg     Fig. 2

E’ possibile configurare il banner in maniera totalmente personalizzata, in modo che vengano mostrate solo le informazioni da noi volute.   La possibilità esiste solo in Powershell, utilizzando il comando Set-ReceiveConnector.

Unico obbligo (dettato dalla RFC 2821) : quello che il banner inizi con 220 (codice di risposta SMTP che indica che il servizio è pronto).

Ecco un esempio di comando per inserire in Exchange 2010/2013 un banner di questo tipo : “220 Hello world

Set-ReceiveConnector “Nome_del_Connettore_di_Ricezione” -Banner “220 Hello world”

Ora il comando Telnet restituirebbe il seguente output :

banner4b.jpg     Fig. 3

Sono nascoste dal banner tutte le informazioni : nome del server (pubblico o privato, piattaforma, data/ora e fuso orario).

P.S. : il FQDN del server compare in ogni caso nel successivo step della comunicazione SMTP, dopo la spedizione del comando EHLO : quindi, pur avendo compilato l’attributo Banner con powershell, è sempre consigliato compilare anche l’attributo FQDN con il nome pubblico del vostro server di posta, per non rivelare all’esterno il nome interno privato.

  • Share/Bookmark

Pubblicato in Exchange Server 2010, Exchange Server 2013 | Nessun commento »

Rilasciato il RU1 per Exchange Server 2010 SP3

Scritto da Ivan Salvade' il 30 maggio 2013

Aggiornamento del 11 giugno 2013 : attenzione ad un bug presente nel RU1 per Exchange 2010 SP3.  Le spiegazioni sono nel seguente articolo :

http://ivansalvade.it/2013/06/11/ci-risiamo-ru1-di-exchange-2010-sp3-con-problemi/

—————————————————————————————————————————————————————————————————————————

Continua il rilascio degli Update Rollup di Exchange 2010.

Questa volta tocca al RU1 per Exchange 2010 SP3, scaricabile al seguente link (attenzione alla lingua) :

http://www.microsoft.com/en-us/download/details.aspx?id=39073

Il RU1 è grande circa 30MB, e aggiorna l’installazione di Exchange 2010 alla versione 14.03.0146.000.  Sarà a breve disponibile in automatico sui vostri server tramite Windows Update.

La sua installazione non richiede il riavvio dell’intero server, ma i servizi di Exchange necessari sono riavviati in automatico.

E’ installabile solo se sul vostro Exchange 2010 è già presente il SP3.  Non si installa su SP1 o SP2.

La descrizione completa dei bug risolti da questo RU1 è riportata qui :

http://support.microsoft.com/kb/2803727

Segnalo in particolare la risoluzione del seguente bug, cha accade durante la sincronizzazione di un IOS 6.1 collegato ad un Exchange 2010 pre-SP3/RU1 :

http://support.microsoft.com/kb/2814847

Buona installazione!! :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | 5 Commenti »

Evento 9688 su Exchange Server 2010

Scritto da Ivan Salvade' il 15 maggio 2013

Attenzione alla comparsa ripetuta, tipicamente durante le operazioni di manutenzione notturne, dell’evento 9688 nel log Applicazione di un server Exchange 2010.

L’errore è simile al seguente :

9688-exch.jpg      Fig. 1

Questo errore appare quando la dimensione logica del database si avvicina pericolosamente alla dimensione massima consentita.

In Fig. 1, la dimensione massima è stata fissata a 300 GB, e la dimensione logica (273 GB) è ormai prossima a quella soglia.

Come ben riportato dalla descrizione dell’evento, la dimensione logica del database equivale alla dimensione fisica del file .edb MENO lo spazio libero logico : quest’ultimo è rappresentato dagli spazi “bianchi” creati all’interno del database quando si eseguono cancellazioni.  Solo dopo una deframmentazione offline, gli spazi bianchi verrebbero totalmente azzerati.

Ecco le dimensioni massime pre-impostate sui database di Exchange 2010 :

  • Exchange 2010 Standard : 1024 GB
  • Exchange 2010 Enterprise : nessun limite
  • Exchange 2010 Standard (parte di SBS 2011) : 1024 gb

Esiste una chiave di registro per modificare la dimensione massima del database.  Il valore di registro si chiama :

Database Size Limit in GB (di tipo REG_DWORD) e, se non esistente, deve essere creato nella seguente posizione :

HKLM\System\CurrentControlSet\Services\MSExchangeIS\nome_server\Private-Database_GUID

Il GUID del database è reperibile con un semplice comando di powershell :

Get-MailboxDatabase nome_db | ft name,guid

La Fig. 2  mostra la compilazione della chiave di registro suddetta, con un valore pari a 500 GB :

regedit.jpg      Fig. 2   (clicca sulla foto per ingrandire)

Nell’esempio di Fig. 1, probabilmente, qualcuno era già intervenuto sulla chiave di registro, ponendo il suo valore a 300 GB.

E’ importante ricordare che, se la dimensione massima venisse raggiunta, il database si smonterebbe ad intervalli regolari : prevedere quindi un monitoraggio della dimensione del database.

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | Nessun commento »

Risultati contrastanti nelle ricerche multi-mailbox in Exchange 2010

Scritto da Ivan Salvade' il 3 aprile 2013

In Exchange 2010, esistono due modi per eseguire ricerche di mail nelle cassette postali :

  1. Tramite Exchange Control Panel (ECP)
  2. Tramite comando di powershell “Search-Mailbox”

Subito una precisazione :  se il comando powershell “Search-Mailbox” (o l’intera sezione di ricerca nel ECP) non dovessero essere disponibili, probabilmente il vostro account non è inserito nel gruppo “Discovery Management” in Active Directory.  E’ necessario far parte di questo gruppo per poter eseguire le ricerche in tutte le cassette postali.

Sia nella console grafica che nel comando powershell è possibile indicare precisamente i termini della ricerca. Per esempio, posso indicare :

  • cassette postali in cui eseguire la ricerca
  • intervallo di tempo
  • cassetta postale in cui far pervenire gli esiti della ricerca
  • livello di logging della ricerca (nessuno, base, avanzato)
  • parole e/o allegati da ricercare nelle mail
  • … altro ancora

Con il comando powershell, posso anche utilizzare il parametro “-DeleteContent” per cancellare automaticamente tutte le mail intercettate dalla ricerca (questo in ECP non è possibile).

In alcuni casi si può notare una discrepanza di risultati eseguendo una ricerca in ECP e in Powershell : per esempio, eseguendo la ricerca in ECP ottengo 100 mail, ed eseguendola in Powershell ne ottengo 360!

Nel 99% dei casi è stato impostato in maniera errata il parametro “-SearchQuery” nel comando “Search-Mailbox” : bisogna essere molto precisi nella sintassi.

Faccio un esempio.

Supponiamo di voler cercare in tutte le cassette postali le mail che contengono l’esatta frase “Io sono andato a casa“.

Se al motore di ricerca di Exchange voglio far trovare un’esatta frase nelle mail (nell’intero corpo), devo indicare quella frase tra apici : Io sono andato a casa.  Le parole non sono case-sensitive.

Impostando la ricerca nella facile console grafica del ECP, la ricerca potrebbe restituire 100 risultati : questo risultato è assolutamente affidabile.

In powershell, il comando per impostare tale ricerca potrebbe essere il seguente :

Get-Mailbox | Search-Mailbox -SearchQuery io sono andato a casa-Logonly -LogLevel Full -TargetMailbox pippo -TargetFolder Search

Questo comando analizza tutte le mail di tutte le mailbox, cerca nelle mail la frase “io sono andato a casa“, registra l’esito della ricerca in modalità Full (cioè indicherà l’esatto numero di mail con quella frase, e creerà anche un file CSV contenente le precise mail rintracciate), e posizionerà l’esito della ricerca nella cassetta postale “Pippo” in una cartella “Search”, dove il proprietario di “Pippo” (o chi ha autorizzazioni di accesso) potrà analizzare la ricerca.

Purtroppo, il comando suddetto probabilmente indicherà un numero di mail diverso da 100.  Come mai?

Il colpevole è il parametro “-SearchQuery” : in molti articoli Technet, è riportato che è sufficiente inserire la frase tra doppi apici per far ricercare ad Exchange la precisa frase.  Questo non è corretto.  Se inseriamo “io sono andato a casa” tra doppi apici, Exchange cercherà tutte le mail dove saranno presenti tutte le parole (c’è un AND sottinteso tra ogni parola e la successiva), ma anche in ordine sparso.  Quindi verranno intercettate pure le mail contenenti, per esempio, la frase “sono andato io a casa” (diversa da quella che effettivamente volevo ricercare).

Il trucco sta nell’inserire l’intero predicato di ricerca “io sono andato a casa” tra due ulteriori apici singoli !!

Quindi la sintassi corretta diventa la seguente :

Get-Mailbox | Search-Mailbox -SearchQuery ‘io sono andato a casa“‘ -Logonly -LogLevel Full -TargetMailbox pippo -TargetFolder Search

Ora l’esito della ricerca dovrebbe veramente restituire lo stesso risualtato (100) del ECP.

E’ importantissimo testare perfettamente la ricerca, soprattutto se la vostra intenzione è quella di cancellare le mail intercettate dalla ricerca (con il parametro “-DeleteContent”).  Un errato parametro “-SearchQuery”, potrebbe portare alla cancellazione non voluta di numerose mail : e a quel punto potreste recuperarle sono con un restore.

  • Share/Bookmark

Pubblicato in Exchange Server 2010, Exchange Server 2013 | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok