Per disabilitare la posta in uscita di un utente Exchange lasciandogli la possibilità di inviare messaggi agli utenti interni procedere come segue: dal System Manager di Exchange –> Routing Groups –> Connettore SMTP. Nelle proprietà del connettore scegliere Delivery Restrictions e aggiungere l’utente nel box “reject message from”.

(Così vediamo se riesco a dimenticarmelo di nuovo).

Exchange Server non salva i dati direttamente nel suo database, bensì in una serie di transaction log che vengono consolidati successivamente. Nel caso il db si dovesse rovinare, questi log possono essere utilizzati per un disaster recovery, ma se questi file non vengono gestiti in maniera adeguata possono crescere a dismisura riempendo lo storage e compromettendo le prestazioni del server.

Ci sono alcune buone ragioni per usare il modello log-commit. Intanto il processo di scrittura delle transazioni su un log con successivo consolidamento è più efficiente e sicuro: scrivere in file piccoli – i log sono 5 mega ciascuno – è più veloce e meno critico che modificare un bestione da diversi giga; il commit può essere poi fatto con processi a bassa priorità e non in tempo reale, senza bisogno di attendere in coda ad altre eventuali altre attività di scrittura su database. Inoltre i transaction log prendono parte al backup di Exchange Server: in considerazione del fatto che non è possibile salvare un file aperto, se i dati fossero scritti direttamente sul db esso dovrebbe essere chiuso prima di poter effettuare il salvataggio, con la conseguente interruzione del servizio durante il processo di backup, che per server con parecchie mailbox può durare anche diverse ore. Nel momento del backup i log esistenti vengono consolidati, il db chiuso e salvato mentre il servizio continuerà ad essere disponibile, visto che le nuove transazioni verranno scritte su nuovi file di log. Nel caso di un ripristino del database, i logfile esistenti possono essere utilizzati per aggiornare il db alle ultime transazioni effettuate dopo il backup, che altrimenti andrebbero perse.

La quantità di file log continua a crescere finché il successivo backup non effettua un commit: ecco il motivo per cui è necessario fare regolarmente il backup con una applicazione Exchange aware, altrimenti lo storage continuerà a popolarsi di nuovi file finché il loro numero eccessivo non comincerà ad inficiare le prestazioni.

Per preservare lo spazio su disco, Microsoft dà la possibilità di abilitare il logging circolare (circular logging), che limita a 4 il numero massimo di file log che possono essere creati; raggiunta la soglia viene effettuato un parziale commit dei dati più vecchi; in questo modo non ci saranno mai più di 4 file log in un dato momento, pari a 20 megabyte. Per quanto possa sembrare una buona idea abilitarlo, in realtà non lo è affatto: c’è la possibilità di perdere dati tra un backup e l’altro, inoltre non è più possibile effettuare backup differenziali o incrementali. Del perché sia rischioso è facilmente comprensibile facendo due conti con numeri semplici ed esposizione volutamente semplificata.

Partiamo da un db con il circular logging abilitato e contenente, ad esempio, 1000 record. E facciamo l’ipotesi che altri 200 record siano nei log. Il backup consolida, e salva quindi 1200 record. Nell’intervallo tra un backup e l’altro vengono fatte transazioni per 500 record, di cui 1300 nel db e sempre 200 nei log (perché sono fissi a causa del circular logging attivato). Se a questo punto sono obbligato a ripristinare il backup mi troverò ad avere 1200 record del db che avevo salvato più i 200 dei log che non ho toccato. Risultato: ho perso transazioni per 100 record.

Se non sbaglio su Small Business Server il circular logging è abilitato per default, al contrario delle versioni “normali” di Exchange Server. Per controllare l’impostazione, che viene fatta a livello di Information Store, da System Manager si va in Administrative Groups -> Il vostro administrative group -> Servers -> il server -> l’information store. Clic con il tasto destro –> Properties e nella linguetta General si trova il checkbox “Enable circular logging”.

Nel caso servisse, si può effettuare l’operazione di consolidamento a mano, e vedremo in un prossimo post come fare.

(Stesse cose qui, un articolo in inglese che ho usato come traccia.)

Ora che ci penso è tipo la terza volta che devo risolvere il problema perché mi sono dimenticato di cosa avevo fatto le altre volte, ergo ne scrivo qui.

Il servizio POP3 di Exchange Server rifiuta la connessione segnalando nome utente e/o password sbagliati; accedendo via telnet si scopre che la casella esiste, quindi il nome utente è corretto, ma la password viene rifiutata; se l’utente fosse sbagliato, Exchange segnalerebbe come inesistente la casella postale. Una volta accertato al di là di ogni dubbio (mai fidarsi dell’utente) che le credenziali sono corrette, possiamo attivare i log diagnostici per capire meglio cosa succede. Dalle proprietà del server Exchange, nel System Manager, andiamo alla linguetta “Diagnostic Logging”. L’ultima voce è il servizio POP3SVC, scegliamolo e nelle “Categories” attiviamo il log “Authentication” con “Logging Level” impostato su “Maximum” e confermiamo il tutto. Non ricordo se il servizio deve essere riavviato, nel dubbio se ve ne è la possibilità è meglio far ripartire tutto Exchange tramite il servizio “Microsoft Exchange System Attendant”.

A questo punto proviamo a fare un paio di accessi alla casella incriminata via POP3 e andiamo a controllare l’Event Viewer alla sezione Applicazione. TA-DA! l servizio POP3SVC ci segnala un paio di errori 1022; basta consultare il sito che dà un senso alla vita di un sistemista e trovare che: “This behavior occurs because the value in the User Logon Name (Pre-Windows 2000) box does not match the value in the Mailbox Alias box”.

Apriamo le proprietà dell’utente in “Active Directories User and Computer” e verifichiamo che effettivamente il “Mailbox Alias” è diverso dal “Logon Name”; modifichiamolo di conseguenza ed il problema è risolto.

Possiamo quindi bullarci alla macchinetta del caffè.

Dopo circa un’anno dall’installazione, scade il certificato di Exchange Server 2007. Outlook continua a funzionare, ma sul client (con Vista, su XP non ho verificato) appare un fastidioso messaggio che segnala come non più valido il certificato del server di posta.
Se, come spesso accade, il vostro certificato è self-signed, cioè non emesso da una autorità di certificazione (non lo avete pagato), è necessario prima generare una richiesta e poi emettere un nuovo certificato basato su quest’ultima.
La richiesta si genera dalla Management Shell di Exchange 2007, tramite il commandlet New-ExchangeCertificate. La sintassi non è complicatissima, comunque ho trovato questo strumento online che la genera per noi. Otterremo una cosa simile a:
New-ExchangeCertificate -GenerateRequest -Path c:\xxxx.csr -KeySize 1024 -SubjectName "c=IT, s=Italy, l=Genoa, o=Xxxxx S.p.A., cn=xxxx.yyyy.zzzz" -DomainName tttt.rrrr.vvvv -PrivateKeyExportable $True (inserite anche il nome DNS nel box Subject Alternative Names, se il server è pubblicato su Internet.)
Apriamo una Exchange Management Shell e incolliamo il comando, il quale genera la richiesta e la mette nel file c:\xxxx.csr.

A questo punto se non avete già un server CA (CAS: Certificate Authority Server) sulla vostra rete, lo dovete installare. Si fa tranquillamente dal Pannello di Controllo –> Installazione Applicazioni –> Installazione Componenti di Windows. Fatelo sul server Exchange 2007, è più comodo e passi successivi presumono che il server sia uno solo.

Terminata l’installazione, accedete a https://nomeserver/certsvr, cliccate Request a certificate, poi Advanced certificate request, poi Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file. Copiate il contenuto del file c:\xxxx.csr nel box Saved Request, selezionate Web Server in Certificate Template, e cliccate su Submit. Scaricate il certificato dalla schermata successiva e salvate il file .cer in c:\.

A questo punto, sempre dalla Management Shell di Exchange 2007, impartite il comando:

import-exchangecertificate -path c:\certnew.cer | enable-exchangecertificate -services iis

e premete invio.

Se tutto è andato a buon fine, potete controllare tramite la gestione di IIS che il certificato sia installato correttamente. Naturalmente il nostro server non è considerato attendibile come autorità di certificazione, il certificato va inserito nel repository delle fonti attendibili sul client. (Forse viene fatto automaticamente al reboot dei client.)

Aggiornamento: dopo poco tempo nell’application log è apparso l’errore 12014, ricorrente ogni mezz’ora circa; l’avviso lamenta la mancanza di un certificato che contenga il nome specificato nel campo FQDN del connettore SMTP in uscita. Ad una prima analisi sembra che ciò non sia vero, in realtà bisogna controllare il campo “Identificazione Personale” nei dettagli del certificato e annotare il relativo valore. Dopodiché tramite Management Shell di Exchange, impartire il seguente comando:

Enable-ExchangeCertificate -Thumbprint 3afd24627925332cd096f45eb5b4473c72526112 -Services "SMTP"

sostituendo il valore Thumbprint qui indicato con quello precedentemente annotato dai dettagli del certificato.

Memo veloce: nei log del message tracking di Exchange, che si attiva da Exchange System Manager –> tasto destro sul server –> Proprietà –> Scheda General –> Enable message tracking, c’è una colonna Event-ID. Il breakdown dei codici evento si trova qui.