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

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 »

Features rimosse da Exchange 2013 rispetto ad Exchange 2010

Scritto da Ivan Salvade' il 29 ottobre 2012

Ecco un elenco delle features più conosciute, presenti in Exchange Server 2010, ma che non troverete più in Exchange Server 2013 :

  • Il ruolo Hub è stato rimosso : tutte le sue funzionalità sono ora espletate dai servizi “Transport” e “Mailbox Transport” presenti sul ruolo Mailbox, e dal servizio “Front-End Transport” presente sul ruolo Client Access Server (CAS)
  • Il ruolo Unified Messaging è stato rimosso : le sue funzionalità sono ora espletate dal servizio “Unified Messaging”, che ha componenti presenti sia sul ruolo Mailbox che sul ruolo CAS
  • Il ruolo Edge è stato rimosso : i filtri anti-spam sono ora attivabili sul servizio Transport del ruolo Mailbox, e gestibili tramite Powershell 
  • Le console di gestione di Exchange 2010 “Exchange Management Console” (EMC) e “Exchange Control Panel” (ECP) sono state rimosse e sostituite dalla console unica “Exchange Administration Center” (EAC).  EAC è una console web, non è richiamabile dal menù Start del sistema operativo, ma tramite un link web nella forma https://nome_server_CAS/ecp se il collegamento proviene dall’interno della rete, o nella forma https://mail.contoso.com/ecp se il collegamento proviene dall’esterno.   Internet Explorer 8,9,10, Firefox 11, Safari 5.1 e Chrome 18 sono tutti browser supportati per l’apertura della console a piene funzionalità
  • Outlook 2003 non è più supportato : essendo ora obbligatorio l’uso del servizio Autodiscover per il collegamento ad Exchange 2013, Outlook 2003 non può più essere utilizzato, non rispettando tale prerequisito
  • L’accesso dei client Outlook tramite RPC over TCP non è più supportato : tutti gli accessi devono essere fatti tramite RPC over HTTP, e quindi Outlook Anywhere deve essere implementato in rete
  • In OWA 2013 sono rimosse le seguenti funzionalità :
    • supporto per S/MIME
    • controllo grammaticale (basato ora sulle funzionalità del browser)
    • la pagina di lettura non è più visualizzabile nella parte bassa dell’interfaccia
    • non è più possibile rispondere a mail spedite come allegati
  • Le Managed Folders non sono più supportate : è possibile usare solo i Retention Tags e le Retention Policies per attuare operazioni di pulizia nelle cassette postali
  • Gli strumenti “Exchange Best Practices Analyzer”, “Mail Flow Troubleshooter”, “Performance Monitor”, “Performance Troubleshooter” e “Routing Log Viewer” sono tutti stati rimossi.  Rimangono disponibili il “Visualizzatore Code” (Queue Viewer) e la tracciatura dei messaggi in entrata e uscita tramite “Message Tracking”
  • Share/Bookmark

Pubblicato in Exchange Server 2013 | Nessun commento »

Le novità del SP2 di Exchange 2010

Scritto da Ivan Salvade' il 9 dicembre 2011

Dal 5 dicembre 2011 è disponibile il SP2 di Exchange 2010.   Il Service Pack 2 contiene alcune features nuove, che richiedono l’aggiornamento dello Schema di Active Directory.  Inoltre contiene tutte le fix presenti negli Update Rollup da 1 a 6 precedentemente rilasciati per Exchange 2010 SP1.   Ecco le novità più interessanti :

Hybrid Configuration Wizard : utile per le aziende che sceglieranno di utilizzare uno scenario ibrido, dove alcune cassette postali saranno sui server interni e altre “nel cloud” in Exchange Online con Office 365.  Il wizard aiuta a semplificare la configurazione di questo scenario.  In Exchange 2010 pre-SP2, erano necessari circa 50 passaggi per realizzare uno scenario ibrido : ora gli step sono stati ridotti a 6!!    Il wizard configura automaticamente numerosi oggetti, tra cui :

  • Trust Federativo
  • Remote Domains e Accepted Domains
  • Mail Address Policies
  • Send e Receive Connector
  • Connettori Forefront inbound e outbound
  • MRSProxy (servizio proxy di replica cassette postali, utile per spostarle tra foreste)

Una volta stabilita la configurazione ibrida, saranno disponibili in questa modalità parecchie features, tra cui :

  • condivisione dei calendari tra utenti interni e utenti nel cloud
  • spostamento delle cassette postali interne verso il cloud, mantenendo i profili utente di Outlook e la configurazione dei files .ost
  • tracciatura dei messaggi che fluiscono tra rete interna e cloud
  • uso dei Mailtips
  • uso dell’acrchiviazione di mail vecchie, sia per utenti interni che del cloud
  • redirezione opportuna di OWA verso le mailbox interne o quelle nel cloud
  • criptazione del flusso di mail tra rete interna e cloud con TLS

“Address Book Policies” : caratteristica molto attesa, permette di implementare facilmente la “Address List Segmentation”, molto complicata in precedenti piattaforme.  Cos’è?  In breve, è la possibilità di far comparire ad ogni utente (o a gruppi di utenti) Global Address List, Address List, Offline Addres Books o Room Address List opportunamente scelte per loro.   La situazione di default prevederebbe che ogni utente possa vedere nel proprio client di posta tutte le Address List create in Exchange.

Un’organizzazione potrebbe avere diverse address list create.  Per esempio :

  • 5 diverse Global Address List (GAL1, GAL2, GAL3, GAL4, GAL5)
  • 15 diverse Address List customizzate (AL1….AL15)
  • 4 diverse Offline Address Book (OAB1, OAB2, OAB3, OAB4)
  • 3 diverse Room Address List (RL1, RL2, RL3)

In una “Address Book Policy” io posso inserire una qualunque combinazione delle precedenti address list (per esempio la GAL2, le Address List 3,7 e 8, la OAB3, e la RL2), e associare la Address Book Policy a qualunque utente da me scelto, utilizzando il comando “Set-Mailbox” con il parametro “-AddressBookPolicy”.   A quel punto l’utente, nel proprio client di posta, potrà visualizzare solo le Address List dichiarate dalla Address Book Policy.    E’ un requisito essenziale che l’utente abbia la sua cassetta postale sul server Exchange 2010 con il SP2 installato.

“Cross-Site Silent Redirection di OWA” : si tratta di una rifinitura alla tecnica di redirezione di OWA già presente in Exchange 2007 e Exchange 2010 RTM e SP1.

Prima del SP2 di Exchange 2010, in uno scenario in cui ci sono due server CAS installati in due siti diversi, se un utente si collega con OWA al CAS sbagliato (cioè a quello nel sito dove non risiede la sua mailbox), l’utente può essere “proxato” o “redirezionato” al corretto CAS del corretto sito a seconda della compilazione (o meno) dell’attributo “ExternalURL” nelle proprietà della virtual directory di OWA (usare il comando “Get-OWAVirtualDirectory” per la verifica).

Se l’attributo ExternalURL non è compilato sul CAS del corretto sito, allora il CAS del sito sbagliato esegue una “proxata” verso il CAS del sito corretto.

Se l’attributo ExternalURL è compilato sul CAS del corretto sito, allora il CAS del sito sbagliato esegue una “redirection”, cioè propone all’utente di utilizzare direttamente l’URL del sito corretto, contenente la sua mailbox.

Visivamente, questo si traduce in una finestra web che riporta l’avviso “Usare il seguente link per aprire la cassetta postale con le migliori prestazioni“, e sotto l’avviso viene indicato (ed è cliccabile) lo URL corretto. L’utente può cliccare il link, ma in Exchange 2007 e 2010 fino al SP1 viene presentata nuovamente l’interfaccia di autenticazione, e l’utente deve inserire ancora le proprie credenziali per autenticarsi al nuovo server CAS. Questo risultava scomodo per gli utenti.

La “Cross-site Silent Redirection” del SP2 copre proprio questa lacuna : ci offre un meccanismo che rende automatica l’autenticazione in una redirezione cross-site, a patto che entrambi i server CAS utilizzino il metodo di autenticazione “Forms-Based Authetication” (ma è il default), e a patto che la prima connessione sia realmente ricevuta da un server CAS (e non da un Proxy come TMG, per intenderci).  Addirittura l’utente è direttamente rediretto al CAS corretto senza dover cliccare il link corretto, come avveniva in precedenza.

La tecnica si implementa utilizzando il comando “Set-OWAVirtualDirectory” con il nuovo parametro “-CrossSiteRedirectType” che può avere due valori : “Manual” (comportamento analogo alle precedenti piattaforme) e “Silent” (redirezione automatica).

“Mini versione di OWA” :   molto simile a OMA (Outlook Mobile Access) di Exchange 2003, è un client OWA ridotto, adatto per essere usato su sistemi operativi mobili.   Le funzionalità fornite sono quelle base, e cioè :

  • accesso a mail, calendari, contatti, attività, liste degli indirizzi
  • accesso alle sottocartelle di posta
  • composizione, replica e inoltro dei messaggi
  • creazione e modifica di attività, contatti e elementi di calendario
  • gestione delle richieste di riunione
  • settaggio delle risposte automatiche

Per accedere al mini OWA, si utilizza lo stesso URL per accedere all’OWA completo, aggiungendo “oma” in fondo all’URL.  Esempio :

https://webmail.azienda.com/owa/oma

“Mailbox replication Service”prima del SP2, se si volevano spostare delle cassette postali verso un’altra foresta, bisognava attivare il servizio MSRProxy, e per farlo si era costretti a modificare manualmente il file Web.config presente sui server CAS.   Ora l’attivazione di questo servizio è possibile eseguirla dalla linea di comando “Set-WebServicesVirtualDirectory” con il nuovo parametro “-MRSProxyEnabled”.   Ecco un esempio :

Set-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -MRSProxyEnabled $True

“Mailbox Auto Mapping” :   Outlook 2007 e 2010 collegati ad Exchange 2010 SP1 erano in grado di rilevare, tramite Autodiscover, tutte le cassette postali per cui un utente aveva un Full Access, e di presentare di conseguenza tutte quelle cassette postali nell’interfaccia grafica di Outlook.   Se un utente aveva Full Access su parecchie mailbox, questo causava estrema lentezza nell’apertura di Outlook.

Ora, nel SP2, l’auto mapping può anche essere disattivato se vi trovate nella casistica precedente.  Il comando è :

Remove-MailboxPermission -Identity Ivan -User ‘Paolo’ -AccessRight FullAccess -InheritanceType All -Automapping $false

Questo comando dà all’utente Paolo il Full Access sulla mailbox di Ivan, ma disattiva l’Automapping.   Quindi, quando Paolo aprirà il suo Outlook, non vedrà la cassetta postale di Ivan configurarsi ed apparire automaticamente.

Buon Service Pack nuovo!!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | Nessun commento »

Rilasciato il Service Pack 2 di Exchange 2010

Scritto da Ivan Salvade' il 5 dicembre 2011

Il team di sviluppo di Exchange 2010 ha comunicato poco fa il rilascio del tanto atteso Service Pack 2.

Seguirà a breve un post con l’illustrazione delle novità più importanti del service pack.

Intanto, ecco alcuni link per i download :

Download del SP2 (in 13 lingue) :   http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28190

Le novità del SP2 :  http://technet.microsoft.com/en-us/library/hh529924.aspx

Release Notes :   http://technet.microsoft.com/en-us/library/hh529928.aspx

I prerequisiti :   http://technet.microsoft.com/en-us/library/bb691354.aspx

La procedura di aggiornamento al SP2 (ipotizzando un’installazione tipica con i ruoli MB, Hub, CAS sullo stesso server) richiede tra i 50 e gli 80 minuti.

E’ sufficiente lanciare “Setup.exe” dalla cartella in cui si è estratto il service pack.  Vengono controllati tutti i pre-requisiti, viene aggiornato lo schema di Active Directory, vengono aggiornati i ruoli, i language pack, la console di amministrazione.

Un nuovo pre-requisito del SP2 è il componente “IIS 6 WMI Compatibility” : va installato dal Server Manager prima di procedere all’installazione del SP2, altrimenti il wizard si ferma e ne chiede l’installazione.

La versione di Exchange 2010 dopo l’installazione del SP2 diventa : 14.02.0247.005 (in formato conciso, Version 14.2 Build 247.5).

Buon download e buon testing !!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | Nessun commento »

Firme personalizzate e disclaimer in Exchange 2010

Scritto da Ivan Salvade' il 4 ottobre 2011

Exchange Server 2010 ci permette di aggiungere alle mail, tramite le Transport Rules, i disclaimer aziendali (cioè le liberatorie, o avvisi di non responsabilità) e le firme personalizzate degli utenti (quelle che molto spesso si lasciano inserire personalmente agli utenti dai loro Outlook, senza averne quindi un controllo centralizzato).

Sia i disclaimer che le firme possono essere ottimamente personalizzati, in quanto Exchange 2010 ci permette di utilizzare le seguenti caratteristiche al loro interno :

  • Testo semplice
  • Testo formattato con i tag HTML o con gli stili CSS
  • Immagini
  • Attributi in Active Directory degli utenti
  • Separatori di linea

La lunghezza massima del testo digitato nella Transport Rules è di 5000 caratteri, comprensivi di qualungue tag HTML o stile CSS.   E’ possibile creare 2 transport rule, una che appone le firme e una che aggiunge il disclaimer, oppure configurare tutto in una sola.

L’utilità di poter utilizzare gli attributi di Active Directory nel testo della Transport Rule, è proprio quella di poter far generare ad Exchange le firme personalizzate degli utenti.  Ecco la lista completa degli attributi utilizzabili per le firme, in stretto ordine alfabetico :

  • City
  • Company
  • Country
  • CustomAttribute1 - CustomAttribute15
  • Department
  • DisplayName
  • Email
  • FaxNumber
  • Firstname
  • HomePhoneNumber
  • Initials
  • LastName
  • Manager
  • MobileNumber
  • Notes
  • Office
  • OtherFaxNumber
  • OtherHomePhoneNumber
  • OtherPhoneNumber
  • PageNumber
  • PhoneNumber
  • POBox
  • State
  • Street
  • Title
  • UserLogonName
  • ZipCode

N.B. : i “Custom Attribute” da 1 a 15 sono assegnati a tutti gli utenti di Active Directory, una volta che si installa Exchange 2010 nella rete.   Sono visibili nella console di Exchange, nel tab “General” delle proprietà delle Mailbox di un utente, per gli utenti dotati di una mailbox;   mentre, per gli utenti senza mailbox, sono visibili in Adsiedit.msc oppure nel tab “Attribute Editor” nelle proprietà degli utenti, una volta attivata la visualizzazione delle “Advanced Features” nella console “Active Directory Users and Computers”.    Nell’”Attribute Editor”, i Custom Attributes sono visualizzati come “ExtensionAttribute1..15″.    Sono utilizzabili per assegnare agli utenti ulteriori attributi customizzati, a scelta degli amministratori.   Questi attributi possono poi essere usati per eseguire ricerche mirate, o, nel nostro caso, per formattare a piacimento le firme personali nelle mail.

Vediamo come effettuare la creazione di una Transport Rule che inserisca in automatico le firme personali degli utenti, limitatamente alle mail in uscita verso Internet.

Naturalmente, se si decide di utilizzare Exchange per inserire le firme, si dovrebbe vietare agli utenti di poterlo fare personalmente nel proprio Outlook.  La disattivazione delle firme di Outlook è impostabile con dei semplici settaggi di Group Policy, una volta importati nelle vostre GPO i Template Amministrativi di Office, e nella giusta versione (Office 2003, o 2007, o 2010, o tutti).

Si lancia il wizard di creazione della Transport Rule nella sezione “Organization Configuration\Hub Transport” della console di Exchange (Fig. 1) :

1tr.JPG   Fig. 1

Si imposta come condizione quella di intercettare solo le mail in uscita verso Internet (Fig. 2) :

2tr.JPG   Fig. 2

Si sceglie come azione “Append disclaimer text and fallback to action if unable to apply”, inserendo nella finestra “Disclaimer text” l’opportuna sintassi formattata HTML e contenente gli attributi di Active Directory scelti (Fig. 3) :

3tr.JPG   Fig. 3

Si completa il wizard di creazione.  Notare il riassunto finale, che riporta per intero la sintassi HTML (Fig. 4) :

4tr.JPG   Fig. 4

Riporto anche qua sotto, per intero, il codice di esempio inserito nella Transport Rule :

<hr>
<br>
<b>%%DisplayName%%</b><br>
<font size=2>
%%Department%%<br>
%%Company%%<br>
%%Street%%<br>
%%zipcode%%  %%city%%<br>
%%State%%  -   %%CustomAttribute2%%<br>
%%CustomAttribute1%%<br>
%%email%%<br>
Tel   : %%Phone%%<br>
Fax : %%Fax%%
<br>
<hr>
</font>

E’ un esempio di formattazione HTML con utilizzo di alcuni attributi di Active Directory (gli attributi devono sempre essere indicati col simbolo %% inserito prima e dopo il loro nome).

Utilizzando questo codice, la firma sarà composta da :

  • Una linea di separazione (tag <hr>) per staccarsi dal corpo della mail
  • Il nome completo dell’utente in grassetto (tag <b>)
  • In carattere più piccolo (font size=2) le seguenti informazioni :
    • Dipartimento di appartenenza (o carica ricoperta in azienda)
    • Nome Azienda
    • Indirizzo
    • Codice postale e Città
    • Provincia (%%state%%) e nazione (inserita nel CustomAttibute2)
    • Sito web aziendale (inserito nel CustomAttribute1)
    • Indirizzo di posta
    • Telefono
    • Fax
  •  Una ulteriore linea di separazione, per staccarsi dall’eventuale successivo disclaimer da inserire

Ovviamente, tutti gli attributi utilizzati nelle variabili devono essere opportunamente compilati nelle proprietà di tutti gli utenti : se Exchange trova qualcuno degli attributi non compilati, lascerà in bianco la relativa variabile nella firma personalizzata, e questo può comportare effetti estetici indesiderati.

Nelle figure seguenti, ecco i vari attributi compilati nelle proprietà degli utenti (Figg. 5,6,7) :

attribprinc1.JPG   Fig. 5

attribprinc2.JPG   Fig. 6

custattr.JPG   Fig. 7

In Fig. 8 ecco invece l’estetica della firma, una volta eseguito un tentativo di spedizione da un client di posta :

editofinale.JPG   Fig. 8

Si può procedere anche all’aggiunta del disclaimer al di sotto della firma di ogni utente, dopo la seconda linea di separazione.  Nel mio esempio, utilizzerò una seconda transport rule dedicata allo scopo, con priorità più alta rispetto alla precedente.

Procedo con la creazione (Fig. 9) :

1dsc.JPG   Fig. 9

La Transport Rule filtrerà sempre le mail destinate all’esterno dell’organizzazione (Fig. 10) :

2dsc.JPG   Fig. 10

Si sceglie sempre come azione “Append disclaimer text and fallback to action if unable to apply”, inserendo nella finestra “Disclaimer text” l’opportuna sintassi formattata HTML (Fig. 11).   L’azione “fallback to wrap” impostata per default, controlla la casistica in cui la transport rule potrebbe non riuscire ad inserire il disclaimer nella mail, per esempio quando la mail è firmata digitalmente.  In quel caso, il disclaimer è inserito in una sorta di involucro (”wrap”) allegato alla mail :

3dsc.JPG   Fig. 11

La transport rule è creata (Fig. 12) :

4dsc.JPG   Fig. 12

Riporto qua sotto il testo formattato HTML, puramente esemplificativo, inserito nella transport rule :

<HTML>
<h6>
<BODY>
<P>Le informazioni contenute in questo messaggio e gli eventuali allegati sono riservati e destinati esclusivamente ad uno o più specifici destinatari sopra indicati.
</P>
</BODY>
</h6>
</HTML>

Questo semplice codice inserisce il testo del disclaimer in un unico paragrafo, utilizzando un formato di carattere molto piccolo e simil-grassetto (quello garantito dal tah HTML <h6>).

Regolare la priorità della nuova transport rule in modo che risulti superiore a quella che aggiunge la firma personalizzata (altrimenti firme e disclaimer risulterebbero invertiti nelle mail!) (Fig. 13) :

5dsc.JPG   Fig. 13

Ecco il nuovo risultato dopo l’invio di una mail di prova (Fig. 14) :

provafir-disc.JPG   Fig. 14

In conclusione, segnalo anche due importanti limitazioni a cui, per ora, è soggetta questa tecnica.  Mi aspetto migliorie da parte del team di sviluppo di Exchange, almeno nel prossimo Service Pack 2 :

  1. Exchange non è in grado di riconoscere se una firma o un disclaimer sono già stati inseriti in una mail.  Ciò comporta che, in una serie di mail “andata e ritorno” facenti parte di una discussione, firma e/o disclaimer saranno inseriti nelle mail in uscita ad ogni risposta dell’utente interno
  2. Exchange aggiunge firme e/o disclaimer in fase di trasporto, cioè quando la mail è già in fase di routing verso l’esterno.  Per questo motivo, quando ci troviamo nella casistica del punto 1, l’ulteriore “bruttezza” estetica è che firma e/o disclaimer saranno aggiunti sempre in fondo alle mail : quindi avremo tutti i corpi delle mail nella parte superiore del quadro di lettura, e tutte le firme e/o disclaimer nella parte inferiore.

La casistica del punto 1 potrebbe essere alleviata chiedendo alla transport rule di controllare se in una mail viene inserito davanti al soggetto il termine “R:” (ciò che un client di posta in lingua italiana inserisce in automatico quando rispondete ad una mail), e in quel caso di omettere l’inserimento di firma e/o disclaimer.   La soluzione è comunque poco significativa, in quanto potrebbe portare a dei falsi positivi (per esempio nel caso di inserimento “voluto” da un utente del termine “r:” nel soggetto di una mail);  inoltre, per le aziende multinazionali con client di posta in diverse lingue, sarebbe ulteriormente scomodo.

Ulteriori piccole limitazioni e la mancanza di un facile wizard dedicato alla creazione di firme e/o disclaimer, possono ancora far preferire ad un’azienda l’utilizzo di software di terze parti dedicato allo scopo.

Vi avviserò in futuri post di eventuali migliorie della tecnica implementate dal team di sviluppo :-)

Stay tuned!!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | 13 Commenti »

Event ID 2937 MSExchange ADAccess in Application Log

Scritto da Ivan Salvade' il 14 maggio 2011

Nell’Application Log di un server Exchange 2010 possono comparire ripetuti Warning con codice evento 2937 e come sorgente il componente “MSExchange ADAccess”.   Questo componente è il “Directory Service Access”, i cui compiti sono sommariamente spiegati in quest’altro mio articolo recentemente pubblicato :

http://ivansalvade.it/2011/03/12/come-interpretare-levent-id-2080-su-exchange-server-2010/

Un esempio di questo tipo di Warning è riportato nella seguente illustrazione :

snag-0000.jpg

Il problema è causato da un’errata compilazione dell’attributo utente “HomeMTA” (è un attributo di tutti gli utenti in Active Directory), che viene fatto puntare ad un oggetto cancellato da Active Directory.

Questo attributo è visualizzabile utilizzando un editor Ldap avanzato come AdsiEdit, oppure, in un Domain Controller Windows Server 2008, utilizzando il tab “Attribute Editor” nelle proprietà di un utente, nello strumento “Active Directory Users and Computers” (devo aver attivato le “Advanced Features” nel menù “View” della console di gestione).

L’attributo è evidenziato in giallo nella seguente illustrazione :

snag-0003.jpg

Questo problema può capitare in diversi scenari :

  • quando si eseguono migrazioni di cassette postali tra diversi server Exchange
  • quando si restorano utenze e cassette postali da un archivio di backup
  • quando si eseguono modifiche degli attributi degli utenti dalla console di Exchange, mentre è in corso una replica di Active Directory (questa evenienza è piuttosto rara)

L’attributo HomeMTA può essere aggiornato attraverso un semplice comando di Exchange Management Shell, e questo può agire su un singolo utente o su tutti gli utenti :

Per aggiornare un singolo utente :

Get-Mailbox nomeutente | Update-Recipient

Per aggiornare tutti gli utenti :

Get-Mailbox | Update-Recipient

Una volta eseguito il comando, l’attributo HomeMTA appare correttamente impostato, come illustrato nella seguente figura :

snag-0002.jpg

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | Nessun commento »

Come interpretare l’Event ID 2080 su Exchange Server 2010

Scritto da Ivan Salvade' il 12 marzo 2011

Exchange Server 2010 è composto da parecchi servizi che richiedono un accesso costante ai servizi di Active Directory.  Esiste un componente che ha il compito di ottimizzare le comunicazioni tra i vari servizi di Exchange e Active Directory : il DSAccess (Directory Service Access), rappresentato dalla DLL “DSAccess.dll”, presente in “C:\Program Files\Microsoft Exchange Server\V14\Bin”.

Il compito principale di DSAccess è quello di tenere continuamente traccia della topologia di Active Directory, e comunicare eventuali variazioni ai servizi di Exchange.  In particolare, DSAccess si occupa di :

  • venire a conoscenza di cambiamenti nella struttura dei Siti di Active Directory
  • venire a conoscenza dell’aggiunta o rimozione di Domain Controller
  • venire a conoscenza dell’aggiunta o rimozione dei Global Catalogs
  • venire a conoscenza del cambiamento di indirizzo IP di Domain Controller e Global Catalogs
  • venire a conoscenza di Domain Controller o Global Catalogs non più operativi

DSAccess esegue questi controlli ogni 15 minuti, oppure al restart del servizio “Microsoft Exchange Active Directory Topology” (MSExchangeADTopology) o del servizio “Microsoft Exchange System Attendant” (MAD.exe).

Gli esiti dei controlli sono sempre riportati negli eventi informativi con codice 2080 e sorgente “MSExchange ADAccess”, che ripetutamente compaiono in Application Log.

img1320450000.jpg

I dettagli di questi eventi sono utili a diversi servizi di Exchange per avere informazioni sui Domain Controller presenti in rete.  I servizi che utilizzano DSAccess sono i seguenti :

  • Microsoft Exchange Active Directory Topology (MSExchangeADTopology - MSExchangeADTopologyService.exe)
  • Microsoft Exchange Information Store (MSExchangeIS - Store.exe)
  • Microsoft Exchange System Attendant (MSExchangeSA - Mad.exe)
  • Microsoft Exchange Forms-Based Authentication (MSExchangeFBA - Exfba.exe)

Altri servizi (non di Exchange) potrebbero utilizzare DSAccess (per esempio il servizio WWW, World Wide Web Publising Service).

Nella seguente figura, viene mostrata una schermata di Process Explorer (strumento della Sysinternals) dove si evidenziano tutti i processi che utilizzano DSAccess.dll.   La stessa informazione si potrebbe ottenere con il comando :

Tasklist -m DSAccess.dll

img1316000000.jpg

E’ molto utile saper interpretare gli eventi 2080, in particolare le stringhe alfanumeriche posizionate a destra dei nomi dei Domain Controller.  Ecco un esempio di evento :

snag-0001.jpg

In questa figura, DSAccess ha rilevato la presenza di 3 domain controller.  Ogni riga descrive le caratteristiche dei domain controller.  Ecco l’interpretazione :

  • dc.dominio : Nome server : nome del domain controller (oscurato nella figura)
  • CDG : Ruoli : indica se il domain controller può essere utilizzato come Configuration domain controller (C), normale domain controller (D), global catalog server (G). La presenza delle lettere indica la disponibilità della funzione, la presenza di un trattino (-) indica che il domain controller non dispone di quella funzione.  Nell’esempio della figura, tutti i domain controller hanno tutte e tre le funzioni
  • 1 : Abilitato : indica se il domain controller è abilitato (1) oppure no (0) ad essere interrogato dal server Exchange
  • 7 : Accessibilità : indica se il domain controller è raggiungibile con una connessione TCP, e a quali servizi e a quali porte. I valori possibili sono i seguenti :
    • 0 : non raggiungibile su nessuna connessione TCP 
    • 1 : raggiungibile come Global Catalog alla porta 3268
    • 2 : raggiungibile come domain controller alla porta 389
    • 3 : raggiungibile come Global Catalog (3268) e domain controller (389)
    • 4 : raggiungibile come Configuration domain controller alla porta 389
    • 5 : raggiungibile come Global Catalog (3268) e Configuration domain controller (389)
    • 6 : raggiungibile come domain controller e Configuration domain controller (389)
    • 7 : raggiungibile in tutti i suoi servizi
  • 7 : Sincronizzato : indica se il domain controller è sincronizzato in maniera completa con gli altri, relativamente ai servizi che è in grado di offrire. I valori possibili sono i seguenti :
    • 0 : non sincronizzato in nessun servizio 
    • 1 sincronizzato come Global Catalog
    • 2 : sincronizzato come domain controller
    • 3 : sincronizzato come Global Catalog e domain controller
    • 4 : sincronizzato come Configuration domain controller
    • 5 : sincronizzato come Global Catalog e Configuration domain controller
    • 6 : sincronizzato come domain controller e Configuration domain controller
    • 7 : sincronizzato completamente in tutti i suoi servizi
  • 1 : Supporto GC : indica se il domain controller è un Global Catalog (1) oppure no (0)
  • 0 : PDC : indica se il domain controller è un primary domain controller per il suo dominio (1) oppure no (0)
  • 1 : Diritto SACL : indica se il servizio DSAccess del domain controller ha le corrette autorizzazioni per leggere le SACL (System Access Control List) durante le interrogazioni ad Active Directory (1 = autorizzato, 0 = non autorizzato)
  • 1 : Dati critici : indica se DSAccess ha trovato il server Exchange nella Configuration Partition di Active directory sul domain controller indicato nella colonna “Nome Server” (1 = trovato, 0 = non trovato)
  • 7 : Netlogon : indica se DSAccess si è connesso con successo al servizio Netlogon del domain controller, relativamente ai servizi che il domain controller offre. I valori possibili sono :
    • 0 : connessioni a Netlogon non riuscite 
    • 1 connessione a Netlogon come Global Catalog
    • 2 : connessione a Netlogon come domain controller
    • 3 : connessione a Netlogon come Global Catalog e domain controller
    • 4 : connessione a Netlogon come Configuration domain controller
    • 5 : connessione a Netlogon come Global Catalog e Configuration domain controller
    • 6 : connessione a Netlogon come domain controller e Configuration domain controller
    • 7 : connessione a Netlogon con tutti i suoi servizi
  • 1 : Versione sistema operativo : indica se il domain controller sta eseguendo almeno Windows 2000 Server SP3 (requisito minimo per i server Exchange 2003 e successivi).  Valore 1 = sì, valore 0 = No

Guardiamo un’altra figura di esempio :

img1321220000.jpg

Questo è un tipico esempio in cui un domain controller (il terzo) non risulta raggiungibile, tipicamente perchè spento o non connesso alla rete.

Il servizio DSAccess è totalmente dinamico ed è in grado di garantire il failover : se un domain controller diventa per qualche motivo irraggiungibile, DSAccess riesce ad indirizzare il server Exchange verso un altro domain controller (o global catalog) disponibile.   Ciò è vero finchè si lasciano le impostazioni al loro default (ovvero, se si lascia gestire in automatico ad Exchange la topologia di Active Directory).

E’ possibile indicare ad Exchange di utilizzare “staticamente” dei domain controller di nostra scelta : in questo caso, però, se quei domain controller diventano irraggiungibili, non viene eseguito il failover verso altri.

Per impostare staticamente la lista di domain controllers da utilizzare, è possibile utilizzare uno o più dei seguenti comandi di EMS (Exchange Management Shell) :

  • Set-ExchangeServer -id “NomeServerExchange” -StaticDomainControllers DC1,DC2,DC3 (…)
  • Set-ExchangeServer -id “NomeServerExchange” -StaticConfigDomainController DC1    (solo un DC è utilizzzabile con questo parametro)
  • Set-ExchangeServer -id “NomeServerExchange” -StaticGlobalCatalogs GC1,GC2,GC3 (…)
  • Set-ExchangeServer -id “NomeServerExchange” -StaticExcludedDomainControllers DC1,DC2,DC3 (…)

Per visualizzare gli attuali domain controller utilizzati da Exchange, utilizzare il seguente comando :

Get-ExchangeServer -id “NomeServerExchange” -Status | FL

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | Nessun commento »

Exchange 2010 : come ricostruire un intero DAG

Scritto da Ivan Salvade' il 26 febbraio 2011

Il team di sviluppo di Exchange 2010 ha recentemente pubblicato un interessante articolo, che riporta l’esatta sequenza di procedure da implementare per recuperare un DAG (Database Availability Group) completamente perso.

Il DAG fornisce al vostro sistema di posta il recupero automatico da una serie di disastri che possono occorrere ai vostri server, allo storage, alla rete, e perfino ad un intero sito se il DAG è stato progettato in topologia Site-Resilient.

Però esistono casi in cui, pur avendo progettato una robusta soluzione DAG, non siete comunque protetti al 100% da qualunque possibile disastro.  La casistica più ”reale” è quella in cui siete dotati di un unico datacenter (unico sito), e il datacenter subisce un disastro naturale, per esempio un incendio, un’inondazione o qualunque altro evento che causi la perdita dell’intero DAG, che deve essere quindi ricostruito dall’origine.

L’articolo analizza proprio questa situazione, e ci guida step-by-step nella ricostruzione del DAG.  L’articolo si basa su alcuni prerequisiti di partenza :

  1. I server che componevano il DAG originale sono completamente persi e non recuperabili
  2. L’Active Directory è rimasta integra (o se così non fosse, deve essere recuperabile dal backup)
  3. Deve essere possibile recuperare in qualche modo le copie attive dei database di Exchange (per esempio dal backup o dai dischi dei server persi, se ancora leggibili)

Lo scenario analizzato prevede l’esistenza di due server Exchange in DAG, dove ogni server Exchange ospita la copia attiva di un certo database, mentre l’altro server Exchange ospita la corrispondente copia passiva.

Ecco il link per consultre l’articolo.

http://technet.microsoft.com/en-us/library/gg513521.aspx#PrepCNO

Buona lettura a tutti!

  • Share/Bookmark

Pubblicato in Exchange Server 2010 | Nessun commento »

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