Exchange Queue & ATimeout di OWA, risoluzione dei problemi relativi ai cmdlet e altro ancora

KC Lemson and Nino Bilic

D Di recente abbiamo eseguito la migrazione da Exchange Server 2003 a Exchange Server 2007. Stiamo ricevendo lamentele a proposito dei timeout di OWA (Outlook® Web Access) per gli utenti con restrizioni che hanno selezionato l'opzione "Computer privato" all'accesso a OWA 2007. Quale comando di Exchange Management Shell si deve utilizzare per verificare il timeout dei computer privati?

R È necessario prima di tutto ricordare il funzionamento di alcune opzioni, spiegando i motivi dell'esistenza di una selezione separata per i computer privati e i computer pubblici (vedere la Figura 1) e illustrando i diversi comportamenti di queste opzioni. L'intenzione delle opzioni è fornire all'utente un modo per specificare in Exchange il livello di protezione necessario. Se si accede a OWA utilizzando un chiosco pubblico in un aeroporto, ad esempio, oppure utilizzando il computer di casa. L'amministratore di Exchange può decidere di trattare i due tipi di sessione in modo diverso. L'amministratore può, ad esempio, rendere più rapidi i timeout delle sessioni autenticate per i computer pubblici (una questione di minuti) rispetto ai computer privati (fino a un massimo di tre giorni). L'amministratore può configurare anche le altre impostazioni in modo diverso in base alla scelta dell'utente. Può, ad esempio, impostare l'accesso alle librerie di documenti Sharepoint® e ai file condivisi di Windows® in modo che sia consentito solo in caso di accesso privato. È ovvio che l'efficacia della funzionalità dipende dalla scelta dell'opzione giusta da parte dell'utente. Se gli amministratori hanno motivo di ritenere che gli utenti non sempre sceglieranno l'opzione giusta, possono comunque impostare i medesimi valori di timeout e delle altre configurazioni per entrambe le opzioni.

Figura 1** I tipi di sessione pubblica e privata del computer consentono di impostare valori diversi per timeout e altre configurazioni **(Fare clic sull'immagine per ingrandirla)

L'opzione in questione è stata ereditata da Exchange 2003, quando è stata introdotta per la prima volta in OWA autenticazione basata su moduli (nota storica: la prima implementazione di autenticazione basata su moduli è stata progettata in parte da una brillante program manager. Non rivelerò la sua identità, ma si può dire che poi ha trovato fama e fortuna scrivendo un articolo bimestrale per TechNet Magazine).

L'impostazione viene effettivamente memorizzata nel Registro di sistema, ma poiché Windows PowerShell™ è dotato di un'interfaccia per l'aggiornamento del Registro di sistema, è possibile configurare questa impostazione utilizzando Exchange Management Shell. Nell'esempio seguente il timeout viene impostato a 1440 minuti, o a un giorno, quando gli utenti scelgono l'opzione di computer privato durante l'accesso:

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

Poiché l'impostazione è nel Registro di sistema, è ovviamente possibile aggiornare la chiave utilizzando regedit, scegliendo:

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

In ogni caso è necessario riavviare IIS per consentire a OWA di accettare la nuova impostazione. A tal fine è possibile scegliere Start | Esegui ed eseguire il comando iisreset /noforce.

D Incoraggiamo tutti i dipendenti che utilizzano i client MAPI di Outlook completi ad archiviare gli elementi non urgenti nei file delle cartelle personali (.pst). Tuttavia, gli elementi archiviati non sono disponibili quando gli utenti accedono a Outlook Web Access da casa. È possibile rendere disponibili i file .pst tramite l'interfaccia di OWA?

R Purtroppo OWA non supporta l'accesso ai file .pst. OWA è stato progettato e costruito per essere un client esclusivamente online. Il lavoro per garantire che non restasse alcuna traccia dei dati personali sul computer locale è stato enorme. Sono stati inclusi anche funzionalità come il meccanismo di chiusura di sessione protetta presentato per la prima volta con Exchange 2003 e WebReady Document Viewing di Exchange 2007, che garantisce l'eliminazione dal disco rigido delle copie degli allegati memorizzate nella cache. Dunque l'accesso ai file .pst da OWA non si addice allo scopo prefisso di creare un client esclusivamente online e semplice da distribuire.

Ciò detto, l'uso dei file .pst è in generale uno scenario interessante che è opportuno approfondire. L'autunno scorso abbiamo incontrato un cliente che aveva utenti con quote della cassetta postale di circa 200 MB e quasi ogni utente utilizzava almeno uno, se non più, file .pst. Poiché l'organizzazione si era dotata di un criterio di gestione che consentiva di ripulire e sostituire i computer degli utenti con uno sforzo minimo, a tutti gli utenti veniva richiesto di memorizzare i file .pst su una condivisione di rete. La condivisione di rete veniva, a propria volta, inserita in un backup da un sistema centralizzato.

Per iniziare, sono già noti dei problemi relativi all'accesso ai file .pst da condivisioni di rete. Così come OWA è stato progettato per essere un client online,. i file .pst sono stati creati per la memorizzazione locale. Qualunque sia il livello di funzionalità e la velocità, la rete è soggetta a latenza e ad altri problemi che rendono di difficile gestione l'archiviazione remota dei dati (a cui devono per di più accedere più utenti contemporaneamente).

Inoltre, l'organizzazione aveva definito delle quote della cassetta postale piuttosto ridotte (noi dobbiamo ritenerci dei veri privilegiati con una cassetta di posta aziendale di circa 2 GB) perché non si desiderava tenere tutti quei dati in Exchange, che avrebbe altrimenti dovuto sostenere la responsabilità del backup di tutti i dati. Ancora, con gli utenti che memorizzavano i dati in file .pst su una condivisione di rete sottoposta a backup, gli amministratori non risparmiavano né tempo né lavoro. Anzi, se possibile, il carico di lavoro aumentava a causa di una varietà di fattori, come: nessuna archiviazione a istanza singola su più file .pst; costi di helpdesk correlati ai problemi con i file .pst (come password dimenticate e inaffidabilità della di rete in generale); difficoltà nell'eliminazione dei messaggi nei file pst dopo un attacco di virus; difficoltà di individuazione dei messaggi nei file .pst in caso di questioni di natura legale; overhead per la gestione di un sistema di backup diverso e cosí via.

È dunque necessario considerare con attenzione tutti i costi correlati alle decisioni di configurazione. Si potrebbe scoprire che i costi si sommano e che un'altra configurazione potrebbe in definitiva rappresentare una scelta migliore.

D Ho un problema con un comando di Exchange Management Shell. Non funziona, come mai?

R Non è possibile rispondere a questa domanda, ma si può dire che per ottenere la migliore assistenza in questi casi è possibile utilizzare il cmdlet incorporato in Windows PowerShell denominato start-transcript, per registrare i comandi che si eseguono e i risultati che si ottengono. In tal modo sarà possibile incollare i dettagli esatti in un messaggio e-mail, un post di un blog o di un forum.

Aprire una sessione Exchange Management Shell e digitare start-transcript, come nella Figura 2. Exchange Management Shell inizierà a registrare automaticamente tutti i comandi eseguiti in un file di testo simile a quello illustrato nella Figura 3 (la posizione del file di testo viene indicata dall'applicazione). Per interrompere la registrazione, è sufficiente digitare stop-transcript.

Figura 2** Utilizzo del cmdlet start-transcript per registrare i comandi utilizzati e i rispettivi risultati  **(Fare clic sull'immagine per ingrandirla)

Figura 3** Windows PowerShell salva una copia dei comandi utilizzati in un file .txt **(Fare clic sull'immagine per ingrandirla)

Un elenco completo dei comandi utilizzati e dei risultati ottenuti sarà di grande aiuto a chi dovrà risolvere il problema. Ma prima di condividere il registro con qualcuno che non si conosce, è bene controllare ed eliminare gli eventuali riferimenti a dati riservati.

D Ho notato che durante l'installazione di Exchange 2007 viene creata una nuova unità organizzativa nel dominio radice. È denominato Gruppi di protezione di Microsoft Exchange e contiene cinque nuovi gruppi di protezione di Exchange 2007. È possibile spostare questi gruppi in un'altra unità organizzativa? E in un altro dominio?

R Questa domanda fa riferimento ai cinque gruppi di protezione universale (USG) che vengono creati nel dominio radice durante la fase di preparazione di Active Directory. I gruppi in questione sono:

• Exchange Organization Administrators
• Exchange Recipient Administrators
• Exchange View-Only Administrators
• Exchange Servers
• ExchangeLegacyInterop

Ai tempi di Exchange 2000 e 2003, la possibilità di spostare i gruppi di protezione predefiniti (Exchange Domain Servers ed Exchange Enterprise Servers) era limitata. È più preciso affermare che l'operazione di spostamento era possibile, ma il processo comportava alcuni problemi (per ulteriori informazioni, vedere support.microsoft.com/kb/260914). In pratica le possibilità erano molto limitate.

Con Exchange 2007 le cose sono cambiate. I cinque gruppi predefiniti possono essere spostati. È possibile spostarli in un'altra unità organizzativa entro lo stesso dominio o in un altro dominio.

Qualora si "perdesse" uno dei cinque gruppi e non si ricordasse più la sua posizione, ovvero l'unità organizzativa o il dominio, è sempre possibile controllare il valore dell'attributo otherWellKnownObjects nel contenitore seguente:

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

Quando si spostano i gruppi, la rispettiva posizione viene aggiornata in questo attributo che consente di scoprire in qualsiasi momento la posizione dei gruppi. Utile, vero?

D ho trovato un gruppo di protezione globale denominato "Exchange Install Domain Servers" nel dominio. A cosa serve?

R È probabile che esistano delle schede in Active Directory®. Esisterà un gruppo Exchange Install Domain Servers in ogni dominio con il server Exchange 2007 installato. Il gruppo viene creato nell'unità organizzativa Oggetti di sistema di Microsoft Exchange (MESO). Se si esamina questo gruppo, si noterà che viene impostato come membro del gruppo Exchange Servers del dominio radice, che è un gruppo di protezione universale.

In breve, Exchange Install Domain Servers è un gruppo utilizzato per risolvere potenziali scenari di lunghi cicli di replica di Active Directory quando si esegue l'installazione di Exchange 2007 in uno dei domini figlio. Si immagini, ad esempio, di disporre di un dominio radice denominato Root, di un dominio figlio denominato Child e di un dominio figlio di Child denominato Grandchild (lo schema dei nomi denota come sempre una grande fantasia! Le nostre password sono ancora più imprevedibili).

Per preparare l'installazione di Exchange 2007 in questa organizzazione, è necessario prima di tutto estendere lo schema e preparare il dominio Root. In tal modo si creano i cinque USG illustrati nella risposta precedente.

Si immagini quindi di dover eseguire l'installazione nel dominio Grandchild. Per consentire l'avvio dei servizi di Exchange 2007 nel dominio locale, l'installazione inserisce un account computer per il computer di Exchange 2007 nel gruppo Exchange Servers del dominio Root. Poiché ci si trova nel dominio Grandchild, la replica dell'appartenenza del gruppo Exchange Servers potrebbe richiedere del tempo.

Exchange Servers è un gruppo universale e l'appartenenza viene replicata in tutta la foresta. A causa della potenziale latenza della replica, è possibile che l'installazione nel dominio Grandchild non riesca ad avviare i servizi, poiché le autorizzazioni potrebbero non essere state ancora replicate al momento della fine dell'installazione. È per questo motivo che alla prima installazione di un server di Exchange 2007 in un dominio, nel dominio locale viene creato il gruppo Exchange Install Domain Servers.

Durante l'installazione, l'account computer di Exchange viene posizionato come membro di tale gruppo. L'appartenenza al gruppo garantisce ai servizi autorizzazioni sufficienti per l'avvio al termine dell'installazione, anche se l'appartenenza al gruppo Exchange Servers non è stata ancora replicata dal dominio Root. Si noti, tuttavia, che la replica nel dominio locale è di solito più veloce della replica tra domini.

D Nella documentazione di Exchange 2007 si afferma che è necessario eseguire l'installazione con l'opzione /PrepareLegacyExchangePermissions, anche prima di estendere lo schema per Exchange 2007. Perché? E il nome dell'opzione non vi sembra un po' troppo lungo?

R Fa sempre piacere sapere che gli utenti leggono la documentazione prima di eseguire l'installazione. Piaciuta?

/PrepareLegacyExchangePermissions (o /pl per brevità) è un'opzione che, espressamente, attribuisce ai Servizi aggiornamento destinatari (RUS) di Exchange 2000 e 2003 le autorizzazioni necessarie per scrivere nelle proprietà di informazioni di Exchange e informazioni personali. Durante il processo di estensione dello schema di Exchange 2007, alcuni attributi (come gli indirizzi proxy) vengono spostati dalla proprietà dalle informazioni pubbliche di Active Directory alla proprietà delle informazioni di Exchange. Per impostazione predefinita, i RUS di Exchange 2000 e 2003 non detengono i diritti di scrittura per la proprietà delle informazioni di Exchange. Nella realtà, questo significa che se si eseguisse l'estensione dello schema di Exchange 2007 prima, si comprometterebbero i RUS di Exchange 2000 e 2003 perché non potrebbero contrassegnare alcun nuovo destinatario. Per leggere ulteriori informazioni sulle proprietà, è possibile visitare il nostro blog all'indirizzo msexchangeteam.com.

È quindi molto importante eseguire l'opzione /pl prima dell'estensione dello schema per Exchange 2007. È inoltre necessario accertarsi che la modifica venga replicata su tutti i domini con destinatari di Exchange 2000 o 2003 (con i RUS per tali domini). Se in un secondo momento vengono aggiunti altri domini alla foresta e si rende necessaria anche l'aggiunta dei RUS di Exchange 2000 o Exchange 2003, l'opzione /pl dovrà essere eseguita anche in questi domini.

A questo proposito è opportuno notare che, per la prima esecuzione di un'opzione /pl, è preferibile utilizzare un account con diritti Enterprise Admin. Quindi l'installazione dal dominio radice individuerà i domini per cui è necessario eseguire l'opzione /pl ed eseguirà l'opzione su tutti i domini individuati. Se non si utilizza un account Enterprise Admin, sarà necessario eseguire l'opzione /pl utilizzando un account Domain Admin per ciascun dominio. Per fortuna, nella documentazione di Exchange 2007 sono descritti tutti i requisiti di autorizzazione.

Infine, a proposito della lunghezza del nome, Basta provare a pronunciare tre volte in rapida successione /PrepareLegacyExchangePermissions:

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

Avevamo anche pensato di utilizzare un nome un po' più lungo, tipo /PrepareLegacyExchangePermissionsWOWQuestoSìCheÈUnNomeLungo, ma alla fine abbiamo optato per il più breve e semplice /PrepareLegacyExchangePermissions.

Ormai è fatta, ma è sempre possibile utilizzare la forma abbreviata /pl. E giuriamo che non è uno scherzo!

KC Lemson è User Experience Manager per Exchange Server. Nel tempo libero aspetta di ricevere messaggi e-mail in cui le consiglino dove investire i fondi scolastici dei ragazzi

Nino Bilic, Technical Lead per Exchange Server, è impegnato a compilare statistiche sul numero di partite di Halo che riesce a fare durante una normale giornata di lavoro

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