Exchange Queue & ARuoli Trasporto Edge e Hub, computer virtuali e altro ancora

KC Lemson and Nino Bilic

Nel numero di maggio 2007 di Exchange Queue & A sono stati illustrati i problemi correlati all'archiviazione dei file .pst nelle condivisioni di rete. Il team addetto alla gestione delle prestazioni di Windows Server ha di recente avviato un blog in cui ha trattato

questo argomento esplorandone tutti i dettagli tecnici; è consigliabile pertanto accedere al collegamento. A questo punto, è possibile passare alle domande.

D È necessario distribuire il ruolo del server Edge se si intende distribuire Microsoft Exchange Server 2007?

R No, la distribuzione di Exchange Server 2007 non implica la necessità di distribuire il server Edge. È possibile utilizzare un singolo computer su cui eseguire contemporaneamente programmi antispam e antivirus e i ruoli del server di base (ad esempio Cassette postali, Accesso client e Trasporto Hub) che accettano i messaggi di posta elettronica per il proprio dominio.

D Quali sono le differenze tra i ruoli del server Trasporto Edge e Trasporto Hub? Quali sono gli svantaggi se non si distribuisce il server Edge?

R Lo scopo principale del ruolo Hub è instradare la posta all'interno dell'organizzazione e applicare i criteri aziendali a tali messaggi. Con il ruolo Hub, le regole di trasporto sono basate sugli oggetti di Active Directory®: utenti, liste di distribuzione e così via. Il ruolo Hub consente inoltre di aggiungere dichiarazioni di non responsabilità ai messaggi o ai messaggi del journal inviati a gruppi di utenti in quanto è probabile che si desideri basare tali regole sull'appartenenza ad Active Directory. Potrebbe essere necessario ad esempio inserire nel journal tutti i messaggi inviati a DLOfUsersOnLitigationHold o aggiungere dichiarazioni di non responsabilità alla posta in uscita inviata da DLOfMembersOfLegalTeam. Sebbene sia possibile eseguire agenti antispam sul server hub, tali agenti non sono attivati per impostazione predefinita e pertanto sarà necessario installarli manualmente eseguendo lo script install-antispamagents disponibile nella directory \scripts sul server.

Lo scopo principale del ruolo Edge è instradare la posta in arrivo e in uscita dall'organizzazione ed eseguire la pulizia di tali messaggi (antivirus, antispam, filtro contenuto o filtro allegati e così via). Quando si installa un server Edge, viene attivata la funzionalità antispam. Una delle funzionalità uniche del ruolo Edge è rappresentata dal fatto che non è necessario che tale ruolo venga aggiunto a un dominio Windows®; può essere eseguito in un'installazione di Windows Server® autonoma che non fa parte di un dominio Windows, ma può essere comunque gestito come parte dell'organizzazione di Exchange 2007 nella foresta aziendale.

Questo è particolarmente vantaggioso in una rete perimetrale nel caso in cui si desideri utilizzare il server in un gruppo di lavoro o si disponga di una foresta separata progettata esplicitamente per i computer inclusi nella rete perimetrale. Per praticità, i server Edge distribuiti in questa situazione possono eseguire la pulizia di tutti i messaggi e il routing della posta tra la rete aziendale e Internet, ma nello stesso tempo possono essere gestiti secondo modalità coerenti con le altre operazioni di amministrazione dei sistemi di Exchange 2007.

Su un server Edge, le regole di trasporto sono basate su indirizzi SMTP, non su oggetti Active Directory; è tuttavia possibile utilizzare naturalmente gli indirizzi SMTP delle liste di distribuzione o degli utenti in Active Directory. Nella maggior parte dei casi, le regole di trasporto del ruolo Edge sono basate su un sottoinsieme delle regole di trasporto del ruolo Hub, fatta eccezione per l'azione di quarantena, che è disponibile solo sui server Edge.

Alcune funzionalità dei server Edge sono inoltre esposte tramite agenti non disponibili sul server Trasporto Hub: rimozione di allegati e riscrittura di indirizzi. Per rimozione degli allegati si intende la capacità di eliminare in modo selettivo allegati potenzialmente pericolosi con estensioni come .exe e .com. L'agente di riscrittura degli indirizzi consente di riscrivere le intestazioni dei messaggi di posta elettronica in modo che, anche se il dominio e gli indirizzi del proxy SMTP predefiniti negli account utente sono ad esempio @contoso.com, i messaggi in uscita per Internet risultano provenienti da @northwindtraders.com. Inoltre, poiché i server Edge eseguono il routing solo in base al dominio o allo spazio degli indirizzi, se si condivide lo stesso spazio di indirizzi SMTP tra Exchange e un altro sistema di posta elettronica, sarà necessario eseguire il routing sul server Hub o eseguirlo insieme all'agente di riscrittura degli indirizzi sul server Edge.

Un'altra importante considerazione riguarda la capacità o meno di un server Exchange 2007 di accedere direttamente a Internet (indipendentemente dal ruolo del server, Hub o Edge). In altre parole, Exchange 2007 è in grado di ricevere in qualche modo le connessioni alla porta 25 nel record MX del dominio. È possibile che si disponga già di un gateway SMTP, un viruswall o altra soluzione su Internet che accetta la posta per il dominio e la trasmette a Exchange all'interno della rete aziendale. Se si distribuiscono server Hub o Edge con connessione a Internet, è possibile sfruttare i vantaggi di una delle più ingegnose funzionalità di Exchange 2007: aggregazione dell'elenco indirizzi attendibili. Con l'aggregazione dell'elenco indirizzi attendibili, gli utenti che aggiungono mittenti al relativo elenco indirizzi attendibili in Microsoft Outlook® (operazione che in genere eseguono per i notiziari Internet o la posta elettronica inviata dai rivenditori) saranno in grado di propagare in maniera protetta tali elenchi ai ruoli Hub o Edge in modo che i messaggi provenienti da questi mittenti ignorino il filtro contenuto. Ovviamente, i messaggi considerati spam da un utente possono essere notiziari importanti per un altro, per cui gli elenchi indirizzi attendibili vengono aggregati in base a ciascun utente. Per ulteriori informazioni sulla modalità di funzionamento di questa funzionalità, consultare la documentazione di Exchange 2007.

Se si decide di eseguire una distribuzione in cui un server in esecuzione con il ruolo Hub accetta la posta elettronica Internet per il dominio, è bene tenere presenti alcune considerazioni. Assicurarsi innanzitutto di implementare una buona soluzione di filtraggio firewall o porta in modo che il server in uso riceva solo connessioni sulle porte necessarie, ad esempio la porta 25. Tenere presente inoltre che è necessario installare gli agenti antispam in quanto non sono installati né attivati per impostazione predefinita. Poiché lo scenario di distribuzione più comune del server Hub viene eseguito all'interno della rete aziendale, non sono consentite connessioni anonime; è necessario controllare il gruppo di autorizzazione AnonymousUsers sul connettore di ricezione della porta 25. Accertarsi inoltre di abilitare l'aggregazione dell'elenco indirizzi attendibili e pianificarne l'esecuzione a intervalli periodici in modo che, quando gli utenti aggiornano gli elenchi indirizzi attendibili nelle relative cassette postali, i messaggi inviati a tali utenti dai relativi elenchi Mittenti attendibili ignorino il filtro contenuto. Ulteriori dettagli sono disponibili sul nostro blog.

Nel seguente codice viene illustrato un comando AT che aggiorna tutte le cassette postali ogni giorno alle ore 23:00 su tutti i server utilizzando un file batch denominato SafeList.bat:

at 23:00 /every:M,T,W,Th,F,S,Su cmd /c 
“D:\SafeList.bat”

Nel seguente codice viene mostrato il contenuto del file SafeList.bat:

“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe” 
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command 
“get-mailbox | where {$_.RecipientType 
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”

Se occorre verificare il corretto funzionamento delle impostazioni, ulteriori informazioni sono disponibili nella documentazione di Exchange 2007.

D Dopo aver avviato l'immagine Virtual PC su cui risiede Exchange, si verificano problemi durante il tentativo di contattare la directory o il server LDAP. La connessione telnet al 389 non dà alcun problema e tutti i servizi funzionano in modo corretto. Perché?

R Anch'io ho avuto questo problema lo scorso anno in Tech•Ed. Avevo esportato una copia di Virtual PC da un computer in ufficio sul mio computer portatile con l'intenzione di utilizzarla per alcune dimostrazioni per i membri della stampa che stavano pubblicando articoli in coincidenza con l'avvio di Exchange 2007 Beta 2 il mese successivo.

Avevo eseguito un milione di demo del prodotto e, contando sull'affidabilità della build, avevo trascurato la fase di preparazione. Si può immaginare il sudore sulla mia fronte quando dopo avviato Virtual PC il lunedì mattina, poche ore prima del primo incontro, ho scoperto che il programma non era in grado di contattare un controller di dominio. Grazie all'alta concentrazione di persone tecnicamente qualificate, il problema fu identificato rapidamente.

Il problema verificatosi in Tech•Ed era il risultato dell'esecuzione di Virtual PC sul mio estremamente lento computer portatile. Il problema era il risultato di una race condition con DNS e Active Directory. Il server DNS sull'immagine era stato configurato per l'integrazione con Active Directory, ma a causa della sequenza i cui i servizi nell'immagine erano stati caricati (e alla mancanza di velocità del mio portatile), i servizi di directory necessari non si erano avviati quando il server DNS ha tentato di contattare Active Directory.

Questa situazione può verificarsi su qualsiasi server che abbia il controller di dominio ed Exchange sullo stesso computer (non deve essere un'immagine virtualizzata), ma può verificarsi con maggiore probabilità in un ambiente virtualizzato in cui vi sono rallentamenti aggiuntivi, in particolare con un portatile poco "muscoloso" come il mio.

Ho notato che un problema simile si verifica con immagini Virtual PC copiate tra due computer, in particolare quando uno dei due computer si trova in un rete differente. Se ci si è imbattuti in un problema di questo tipo, controllare l'indirizzo IP del sistema operativo nell'immagine; è possibile che disponga di un indirizzo IP non aggiornato della rete precedente. Aggiornarlo per ottenere un indirizzo IP dalla nuova rete e verificare se il problema si risolve.

Per evitare questi tipi di problemi in futuro, una possibile soluzione consiste nel configurare il server DNS sul sistema guest in modo che non supporti l'integrazione con Active Directory e nell'installare DNS sia sull'host che sul sistema guest. Configurare il sistema guest per l'inoltro all'host di record sconosciuti e, analogamente, configurare l'host per l'inoltro al server DNS appropriato di record sconosciuti. Quando l'immagine si avvia e tenta di aggiornare i record DNS, sarà meno soggetta a errori.

D Sembra che il processo di installazione di Exchange 2007 sia differente dall'installazione nelle versioni precedenti di Exchange. Come funziona il nuovo processo di installazione?

R Sì, in realtà il processo di installazione di Exchange 2007 prevede diverse fasi. Di seguito viene riportata una panoramica generale della modalità di funzionamento dell'intero processo.

Quando si esegue setup.exe per la prima volta, si avvia un processo che fornisce i collegamenti per la maggior parte dei prerequisiti che è necessario installare prima di avviare l'installazione dei ruoli del server effettivi. Una volta installati tutti i prerequisiti, è possibile fare clic sul collegamento per l'installazione di Microsoft Exchange (vedere la Figura 1).

Figura 1** Collegamento di installazione disponibile dopo che sono stati soddisfatti i prerequisiti generali **

Se si è eseguito setup.exe dalla rete e si è fatto clic sul collegamento di installazione, i file di installazione principali verranno copiati nella cartella %TEMP%\ExchangeServerSetup\ sul computer locale. Verrà quindi avviata l'Installazione guidata.

L'Installazione guidata mostrerà le diverse opzioni disponibili, come il contratto di licenza, la segnalazione errori e il tipo di installazione (che prevede la selezione dei ruoli del server che si desidera installare). Le pagine della procedura guidata variano in base alla presenza e allo stato dell'organizzazione di Exchange corrente (se disponibile).

Una volta completato il processo di installazione, verrà eseguito un controllo di conformità, in effetti una versione modificata di Microsoft Exchange Server Best Practices Analyzer (BPA), che, per impostazione predefinita, si connetterà a Internet per scaricare il file XML dei prerequisiti più recente. In tal modo sarà possibile aggiornare i prerequisiti periodicamente o risolvere eventuali problemi con cui il team di Exchange ha acquisito familiarità sin dal rilascio del prodotto. Una volta completato il controllo dei prerequisiti, sarà possibile verificare i risultati e procedere; in caso contrario, verranno visualizzati tutti i problemi che potrebbe essere necessario risolvere prima di continuare con l'installazione. Se il server non supera il controllo sei prerequisiti, la procedura guidata consentirà nella maggior parte dei casi di riprovare a eseguire il controllo.

Una volta superato il controllo dei prerequisiti, verrà reso disponibili il pulsante Installa che consentirà di avviare l'installazione di tutti i ruoli scelti in precedenza. Verranno copiati e installati solo i file per i ruoli selezionati.

Al termine del processo di installazione, sarà possibile avviare Exchange Management Console e applicare tutti gli aggiornamenti di Exchange 2007 eventualmente disponibili.

KC Lemson è User Experience Manager per Exchange Server. Il suo conto bancario online è stato temporaneamente sospeso.

Nino Bilic è Supportability Program Manager per Exchange Server. Ha aggiunto di recente un indirizzo di posta elettronica secondario alla sua carta di credito.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.