Ivan Salvade’

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

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    novembre 2017
    L M M G V S D
    « gen    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Tag Cloud

Archivi per la categoria 'Exchange Server 2013' 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 »

Quante CAL servono al mio server Exchange 2013?

Scritto da Ivan Salvade' il 25 marzo 2014

Ogni tanto capita di dover sapere se siamo in regola con le licenze CAL di Exchange Server (per esempio se abbiamo acquistato sufficienti Standard o Enterprise CAL per coprire il nostro parco utenti e le numerose features avanzate che Exchange ci permette di utilizzare).

In Exchange 2010 c’era un comodo wizard grafico per raccogliere questo tipo di dati : dalla console di gestione, era sufficiente cliccare “Collect Organizational Health Data” (vedi Fig. 1) per ottenere i dati richiesti.

ex10health.jpg      Fig. 1 : clicca sulla foto per ingrandire

In Exchange 2013 il wizard grafico è stato rimosso, ma sono stati introdotti 2 nuovi comandi powershell per ricavare i dati voluti.

I comandi sono :

Get-ExchangeServerAccessLicense

Get-ExchangeServerAccessLicenseUser

Il primo comando ci mostra semplicemente il nome preciso delle licenze da ricercare nella vostra infrastruttura Exchange, mentre il secondo ci restituisce il conteggio preciso delle licenze CAL necessarie (sia Standard che Enterprise).

Ecco l’esecuzione dei due comandi in un ambiente di test.

L’ambiente di test comprende decine di utenti con mailbox con caratteristiche base (che necessitano quindi di Standard CAL), e 3 utenze con l’archiviazione personale attivata (che richiedono le Enterprise CAL).

In Fig. 2 ho eseguito un comando Get-ExchangeServerAccessLicense per mostrare il nome preciso delle licenze da ricercare :

cmd1.JPG

Fig. 2 (Clicca sull’immagine per aprirla in un’altra finestra)

In Fig. 3 ho eseguito un comando Get-ExchangeServerAccessLicenseUser, chiedendo di mostrarmi in maniera nominativa tutte le utenze che necessitano di una Standard CAL :

cmd2.JPG

Fig. 3 (Clicca sull’immagine per aprirla in un’altra finestra)

In Fig. 4 è riportato l’esito del precedente comando :

esitocmd2.JPG

Fig. 4 (Clicca sull’immagine per aprirla in un’altra finestra)

In Fig. 5 ho ripetuto lo stesso comando, chiedendo però di mostrarmi gli utenti che necessitano di una Enterprise CAL :

cmd3.JPG

Fig. 5  (Clicca sull’immagine per aprirla in un’altra finestra)

Se avessimo bisogno di eseguire un conteggio preciso delle licenze (quindi per numero e non per nome delle utenze), è possibile eseguire una “pipe” dei comandi precedenti al cmdlet “Measure-Object”, come mostrato in Fig. 6 :

meas-obj.JPG

Fig. 6 (Clicca sull’immagine per aprirla in un’altra finestra)

In questo modo ottengo il numero preciso delle licenze Standard ed Enterprise necessarie…. e da acquistare :-) …. altrimenti non sareste in regola con il licensing :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2013 | 1 Commento »

Rilasciato il SP1 per Exchange Server 2013

Scritto da Ivan Salvade' il 26 febbraio 2014

E’ stato rilasciato il 25 febbraio 2014 il Service Pack 1 per Exchange Server 2013.

Tra le novità più importanti segnalo :

  • reintroduzione del supporto S/MIME per OWA (usato con Internet Explorer 9 o successivi) : questo permette agli utenti che utilizzano OWA di spedire e ricevere mail criptate e/o firmate digitalmente
  • supporto completo all’installazione di Exchange 2013 su Windows Server 2012 R2, anche in presenza di un ambiente Active Directory con Domain Functional Level e Forest Functional Level già elevati a Windows Server 2012 R2
  • inserimento in console grafica (EAC) del logging dei comandi amministrativi eseguiti su Exchange 2013.  Sarà presente una voce ”Show Command Logging”, che permetterà di visualizzare anche real-time il log dei comandi eseguiti
  • reintroduzione del ruolo Edge!!!  (… non sono mai stato amante di questo ruolo :-) )
  • introduzione di un nuovo protocollo di comunicazione tra Outlook ed Exchange, chiamato MAPI over HTTP (MAPI/HTTP).  Questo protocollo è disabilitato per default, e potrebbe essere utilizzato solo da Outlook 2013 SP1 e da Exchange 2013 SP1.  I vecchi client devono ancora utilizzare RPC over HTTP, che comunque rimane tuttora il default
  • possibilità di creare un DAG senza un punto di accesso amministrativo (feature possibile grazie ad un Failover Cluster 2012 R2)

L’installazione del SP1 richiede un aggiornamento dello schema Active Directory.

E’ possibile aggiornare un Exchange 2013 già installato, senza problemi ai database o alle configurazioni, utilizzando il seguente comando :

Setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms

A questo link trovate le Release Notes :

http://technet.microsoft.com/en-us/library/jj150489(v=exchg.150).aspx

Ed ecco il link per il download diretto di Exchange 2013 SP1 :

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

Entro 30 giorni circa, il SP1 sarà disponibile anche tramite Windows Update.

Buon aggiornamento…  (magari, come sempre, aspettate un attimino :-)  )

  • Share/Bookmark

Pubblicato in Exchange Server 2013 | Nessun commento »

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 »

Il poster di Exchange Server 2013

Scritto da Ivan Salvade' il 25 giugno 2013

E’ disponibile il mega-poster dell’architettura di Exchange 2013.  Lo potete scaricare al seguente link :

http://aka.ms/Ex2013ArchitecturePoster

Il poster è stato realizzato con il solito accattivante formato grafico, ed è stampabile su carta di dimensioni 90X60 cm circa.

Nel poster sono illustrate le architetture dei seguenti componenti :

  • ruolo Mailbox
  • ruolo CAS
  • Transport Service, Front-End Transport Service e Maibox Transport Service
  • protocolli di accesso client
  • DAG
  • Managed Availability
  • integrazione con Unified Messaging, Lync e SharePoint

Sarà, da me, ampiamente utilizzato durante la tenuta del MOC 20341 (corso Microsoft ufficiale sui servizi core di Exchange Server 2013), in programma a Milano presso la sede di Pipeline, dal 8 al 12 luglio :-)

Buono studio :-)

  • Share/Bookmark

Pubblicato in Cafè, Exchange Server 2013 | 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 »

Aprire Exchange Admin Center (EAC) in scenari di coesistenza

Scritto da Ivan Salvade' il 19 maggio 2013

Attenzione ad un comportamento “curioso” del Exchange Admin Center di Exchange 2013, in scenari di coesistenza con server Exchange 2010.

Ricordo che EAC in Exchange 2013 è ora una console web, richiamabile utilizzando un URL del tipo :

https://nome_server_CAS/ecp

Nel caso in cui abbiate appena installato un server Exchange 2013 in un’organizzazione Exchange 2010 già esistente, il richiamo del precedente URL, loggati con la vostra utenza amministrativa, potrebbe portare alla comparsa dell’Exchange Control Panel (ECP) di Exchange 2010 invece che della console EAC 2013, come ci si potrebbe aspettare.

Questo comportamento è by design, ed è dovuto al fatto che la vostra cassetta postale risiede ancora in un database posizionato sul server Exchange 2010.

In questo caso, è comunque possibile accedere al nuovo EAC indicando, nel URL di richiamo,  la precisa versione della console desiderata (versione 15).

L’URL da utilizzare diventa quindi il seguente :

https://nome_server_CAS/ecp?ExchClientVer=15

Se dovesse sussistere l’esigenza contraria (cioè la volontà di collegarsi a ECP pur avendo la propria cassetta postale già migrata in un database Exchange 2013), l’URL da utilizzare sarebbe il seguente :

https://nome_server_CAS/ecp?ExchClientVer=14

  • Share/Bookmark

Pubblicato in Exchange Server 2013 | Nessun commento »

Rilasciato il CU1 per Exchange Server 2013

Scritto da Ivan Salvade' il 23 aprile 2013

E’ stato rilasciato (già dal 2 aprile 2013) il primo Cumulative Update (CU1) per Exchange 2013 : è il primo grosso aggiornamento rilasciato dopo l’introduzione del nuovo modello di Servicing per Exchange 2013 (vedi qui).

Il Build Number per Exchange 2013 CU1 è il seguente : 15.0.620.29

Il CU1 è grande 1,3 GB (essendo un Full Refresh del prodotto) ed è disponibile in download, in tutte le lingue supportate, al seguente link :

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

I sistemi operativi base sui quali è supportato il CU1 sono i seguenti :

  • Windows Server 2012
  • Windows Server 2008 R2 SP1
  • Windows Server 2008 R2
  • Windows Server 2008 SP2 64bit
  • Windows 7 e Windows 8 64 bit (limitatamente agli strumenti di gestione)

Il CU1 introduce nuovi oggetti di Active Directory e modifiche ai ruoli RBAC e alle autorizzazioni nella Domain Partition di Active Directory.  Pertanto è necessario eseguire le operazioni di preparazione di Active Directory :

  • Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
  • Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
  • Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms (in ogni dominio che contiene cassette postali)

Prima di procedere con l’aggiornamento, leggere attentamente le Release Notes per il CU1, al seguente link :

http://technet.microsoft.com/en-us/library/jj150489(v=exchg.150).aspx

Dopo aver eventualmente implementato le verifiche/correzioni riportate nelle Release Notes, è possibile procedere all’aggiornamento con il comando :

setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms

(oppure lanciare il Setup.exe e seguire le istruzioni del wizard grafico)

Segnalo che Exchange 2013 CU1 è la minima versione di Exchange 2013 necessaria per mantenere un ambiente “on-premise” di coesistenza con le precedenti versioni supportate (Exchange 2007 SP3 RU10, Exchange 2010 SP3)

Buon aggiornamento a tutti :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2013 | Nessun commento »

Nuovo modello di Servicing per Exchange Server 2013

Scritto da Ivan Salvade' il 23 aprile 2013

Novità per quanto riguarda il patching dei server Exchange 2013.

In Exchange Server 2007 e 2010, Microsoft aveva deciso di rilasciare le patch attraverso i Rollup Update (RU) : questo permetteva di applicare gli updates installando singoli package (appunto, i Rollup Updates) meno frequentemente, consentendo alle aziende anche una miglior pianificazione delle fasi di aggiornamento.

In Exchange 2013, considerando le sempre più frequenti transizioni verso ambienti di Cloud e/o ibridi (mailbox mantenute sia in azienda che nel cloud), Microsoft ha deciso di distribuire gli aggiornamenti attraverso dei Cumulative Updates (CU) con cadenza trimestrale.

Ogni CU trimestrale verrà distribuito come Full Refresh di Exchange : in pratica è come se ogni CU fosse un piccolo Service pack.  I CU installabili sui vostri Exchange 2013 “on-premise” sono gli stessi che Microsoft utilizzerà su Exchange Online, per mantenere il massimo parallelismo tra le vostre reti e il cloud.

Eventuali patch di sicurezza saranno invece distribuite tramite packages indipendenti, che possono essere installati dopo un CU, oppure durante l’installazione stessa di un CU (ogni CU conterrà tutti i fixup di sicurezza disponibili fino a quel momento).

Vantaggi per le aziende :

  • installazione dei CU programmabile quattro volte all’anno
  • stessa cadenza anche per Lync Server e Sharepoint Server
  • parallelismo tra “on-premise” e Exchange Online
  • sicurezza che un CU sia già stato testato in Exchange Online, e quindi validato su milioni di utenze

Svantaggi (giudicate voi se lo sono realmente per la vostra realtà) :

  • i CU sono di maggiori dimensioni, essendo Full Refresh del prodotto
  • i CU possono richiedere aggiornamenti dello Schema di Active Directory; potrebbe anche essere necessario ri-eseguire un comando ”Setup /PrepareAD” per eventuali modifiche al sistema RBAC apportate dal CU
  • recupero più difficoltoso in caso di installazione fallita (ci potrebbe essere anche la necessità di dover reinstallare l’intero server, quindi assicurarsi di avere un backup recente disponibile, e procedere poi con un restore utilizzando la procedura “Setup.exe /m:RecoverServer”.  In ogni caso, i database e le code non vengono persi)
  • perdita di eventuali personalizzazioni nei files Web.config o nelle chiavi di registro dei server Exchange (ma questo accadeva anche prima, nelle installazioni dei Service Pack su precedenti versioni dei server Exchange)
  • Share/Bookmark

Pubblicato in Exchange Server 2013 | Nessun commento »

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