Inside SharePointRisoluzione dei problemi di integrazione della messaggistica

Pav Cherny

Download codice disponibile in: SharePoint2008_08.exe(416 KB)

Indice

Approccio generale alla risoluzione dei problemi
Architettura di messaggistica SharePoint
Come ottenere informazioni diagnostiche
Trasferimento di messaggi in uscita
Trasferimento di messaggi in entrata
Gestione directory
Conclusioni

In un ambiente SharePoint ben progettato, gli information worker non devono modificare le proprie abitudini a livello di comunicazione o le routine di lavoro per collaborare. Anziché controllare manualmente i siti di collaborazione a intervalli regolari, con SharePoint è possibile ricevere documenti e altri tipi di informazioni, quali avvisi e promemoria, direttamente nelle cassette postali.

Gli utenti, inoltre, possono prendere parte a flussi di lavoro rispondendo a tali messaggi o inviando nuovi elementi, sotto forma di messaggi di posta elettronica, a elenchi e raccolte di documenti.

Tuttavia, l'integrazione di SharePoint® in un ambiente di messaggistica protetto crea alcune difficoltà e dà l'opportunità ai componenti diversi da SharePoint di avere un impatto sulla collaborazione basata su tale software. La sfida consiste nell'isolare ed eliminare in modo efficiente le cause principali dei problemi nell'ambiente integrato, ovunque si presentino.

Nel presente articolo, illustrerò l'integrazione della messaggistica SharePoint basata su una strategia di risoluzione dei problemi comprovata che fornisca rapidamente risultati. Il principio è individuare con efficienza l'area problematica, per scendere quindi nel dettaglio con procedure di risoluzione dei problemi specifiche e mirate.

In un'organizzazione di grandi dimensioni, la presenza di più fasi potrebbe richiedere, dopo una prima analisi generale, la consulenza di altri specialisti, in particolare se il problema riguarda componenti diversi da SharePoint. Nelle organizzazioni di piccole e medie dimensioni, invece, non è insolito che un unico amministratore IT debba risolvere i problemi di tutti i sistemi utilizzati. Ciò rende ancora più necessario l'utilizzo di approcci strutturati.

Al fine di fornire esempi pratici nell'articolo, sarà utilizzato un ambiente di test con Active Directory®, Exchange Server 2007 e WSS 3.0. Le istruzioni dettagliate per la creazione di questo ambiente, nonché gli strumenti per la risoluzione dei problemi trattati nell'articolo, sono inclusi nel materiale di accompagnamento disponibile nella sezione di scaricamento del codice del sito Web TechNet Magazine.

Approccio generale alla risoluzione dei problemi

La risoluzione dei problemi legati all'integrazione di messaggistica SharePoint richiede un approccio estremamente strutturato, forse più che in altri scenari di interoperabilità. Diversi fattori rendono complessa tale operazione.

È ovviamente necessario utilizzare tecnologie complesse e, mentre si è occupati a gestire problemi legati al trasferimento di messaggi, conversioni del formato dei messaggi, aspetti relativi alla sicurezza e problemi inerenti alla gestione di directory, alcuni messaggi di errore di SharePoint possono risultare poco chiari. Nei newsgroup in Internet sono presenti molti thread di discussione irrisolti e suggerimenti che possono portare sulla cattiva strada, come eseguire tutte le applicazioni Web sotto l'identità di pool di applicazioni per l'Amministrazione centrale di SharePoint al fine di rendere l'integrazione della messaggistica operativa.

Ma ci sono anche aspetti positivi. SharePoint è molto flessibile. Infatti, se si sa dove cercare, può fornire informazioni dettagliate per la risoluzione dei problemi. Con alcuni script di base, è possibile migliorare notevolmente l'efficienza nella risoluzione dei problemi.

Il primo obiettivo di questa operazione consiste nel capire il problema da affrontare, identificando l'area in cui si trova e i componenti interessati. È inoltre possibile tentare di riprodurre il problema in configurazioni di sistema differenti ed esaminare i file di registri basati su testo e dei registri eventi di Windows®. Tuttavia, ciò può risultare difficile, in quanto alcuni problemi si verificano solo sporadicamente. In ogni caso, più accurata è la riproduzione di un problema, più rapida sarà l'identificazione e l'eliminazione della relativa causa. Un altro obiettivo importante, spesso trascurato, consiste nel documentare tutte le modifiche e le correzioni di configurazione e nell'assicurarsi che siano applicate a tutti i sistemi rilevanti nell'ambiente, ad esempio su tutti i server front-end di una Web farm.

Architettura di messaggistica SharePoint

Quando si deve affrontare un problema legato all'integrazione di messaggistica, prima di tentare di risolverlo, è consigliabile prepararsi una tazza di tè o caffè ed esaminare l'architettura dell'integrazione di messaggistica SharePoint. In caso contrario, si rischierebbe di correggere il problema o il componente sbagliato. Ad esempio, un errore di accesso negato che impedisca la creazione di un oggetto di contatto in Active Directory non indica esclusivamente che è necessario correggere le autorizzazioni di accesso al suo interno, come si vedrà in seguito.

In ogni caso, è fondamentale comprendere il ruolo di ciascun componente coinvolto nell'integrazione di messaggistica e la modalità con cui i singoli componenti interagiscono tra loro. Nella Figura 1 sono illustrati i componenti rilevanti in uno scenario di connettività SharePoint-Exchange, argomento trattato approfonditamente nelle sezioni seguenti.

Figura 1 Architettura dell'integrazione di messaggistica SharePoint (fare clic sull'immagine per ingrandirla)

Come ottenere informazioni diagnostiche

Uno degli strumenti più importanti per la risoluzione dei problemi è la disponibilità di informazioni diagnostiche affidabili. Lo strumento per eccellenza è il registro eventi di Windows. Tra le altre funzioni, è possibile controllare il livello di dettaglio con cui SharePoint scrive nel registro eventi di Windows sui server Web, utilizzando l'Amministrazione centrale di SharePoint (nella pagina Operazioni, all'interno della sezione Registrazione e report, fare clic su Registrazione diagnostica). È possibile specificare l'evento meno critico che dovrà essere riportato nel registro eventi e nel registro di traccia. Il registro di traccia (posizionato, per impostazione predefinita, in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) è molto utile se si ricercano informazioni di basso livello, ma può riempirsi molto rapidamente, pertanto è bene utilizzare questa funzione con parsimonia.

Un altro metodo per ottenere informazioni diagnostiche consiste nell'attivare il debug per l'applicazione Web interessata configurando il relativo file web.config, come illustrato nel documento pdf sulla configurazione di applicazioni Web nel materiale di accompagnamento. SharePoint consente di visualizzare informazioni di traccia dettagliate direttamente nell'interfaccia utente. Un vantaggio di questo approccio è la possibilità di visualizzare le informazioni di errore rilevanti senza dover analizzare megabyte di dati. Uno svantaggio è la necessità di modificare la configurazione di sistema dell'applicazione Web. Non dimenticare di eseguire il backup del file web.config originale e di ripristinare la configurazione iniziale una volta terminata la risoluzione dei problemi.

È inoltre possibile configurare il servizio SMTP per la scrittura di informazioni di elaborazione dettagliate nel registro del protocollo SMTP (in Gestione IIS, sulla scheda Generale, selezionare la casella di controllo Consenti registrazione attività). Accertarsi di installare il modulo di registrazione ODBC, anche se non si prevede di utilizzarlo, con la funzionalità del servizio SMTP, come illustrato nel documento pdf relativo all'integrazione della messaggistica SharePoint nel materiale di accompagnamento. In caso contrario, il servizio SMTP non scriverà il registro di protocollo. Per impostazione predefinita, il registro di protocollo SMTP si trova in %SystemRoot%\System32\LogFiles\SmtpSvc1. Si tratta di un file di testo che consente di analizzare la comunicazione SMTP in dettaglio e di determinare se un messaggio ha lasciato il server SharePoint.

Sul server Trasporto Hub che comunica con il servizio SMTP, è inoltre possibile attivare la registrazione protocollo nella configurazione di connettore di invio e di ricezione (vedere il documento pdf sull'integrazione della messaggistica SharePoint). Per seguire il percorso dei messaggi nell'ambiente Exchange Server 2007 attraverso i server Trasporto Hub e i server Cassette postali, è possibile utilizzare molti altri strumenti, quali il rilevamento messaggi, il visualizzatore code e la traccia della pipeline. Per informazioni dettagliate sulla risoluzione di problemi relativi al flusso di posta in Exchange Server 2007, consultare l'articolo "Problemi di trasporto e flusso di posta" all'indirizzo go.microsoft.com/fwlink/?LinkID=120145.

Sui controller di dominio Active Directory, è possibile ottenere informazioni dettagliate sulla risoluzione dei problemi attivando la registrazione diagnostica per l'accesso a directory e altre categorie, impostando le relative voci di registro in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Il valore 0x0 per una categoria indica che saranno registrati solo gli eventi critici, mentre il valore 0x5 rappresenta tutti gli eventi, incluse le informazioni di debug. L'utilizzo di un livello di registrazione superiore a 0x3 può ridurre le prestazioni del server e causare il rapido riempimento del registro eventi di Windows. Quando si eseguono operazioni normali, tutti i valori devono essere impostati su 0x0.

Durante la risoluzione dei problemi, raccogliere informazioni diagnostiche dettagliate su server SharePoint, Exchange e Active Directory può consentire di individuare in modo rapido e affidabile l'area interessata. Inoltre, possono risultare utili strumenti per la risoluzione dei problemi aggiuntivi, quali gli strumenti TCP/IP (ping, tracert, telnet e così via) e Network Monitor, in quanto gran parte delle comunicazioni tra questi sistemi avviene tramite la rete di computer. Microsoft® Network Monitor 3.1 è disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=120143.

Trasferimento di messaggi in uscita

Risorse

• Sito Web Prodotti e tecnologie SharePoint
• Windows SharePoint Services TechCenter
• Centro per sviluppatori di Windows SharePoint Services
• Blog del team Prodotti e tecnologie Microsoft SharePoint

Una volta dotati di registri eventi, registri di traccia, registri di protocollo, registri per il rilevamento di messaggi e tracce di rete, è possibile passare alla risoluzione dei problemi relativi all'integrazione di messaggistica SharePoint. Per iniziare, sarà analizzata la parte più semplice, il trasferimento di messaggi in uscita. SharePoint supporta il trasferimento di messaggi in uscita in diverse configurazioni e non richiede un servizio SMTP locale sui server Web. Tuttavia, in uno scenario di integrazione di messaggistica completa, la configurazione consigliata prevede l'utilizzo del servizio SMTP locale. Nella Figura 2 sono illustrati i componenti principali dello scenario.

Figura 2 Trasferimento di messaggi in uscita (fare clic sull'immagine per ingrandirla)

Questo scenario di messaggistica comprende quattro fasi: SharePoint deve trasferire il messaggio al servizio SMTP, il servizio SMTP deve elaborarlo, il server Trasporto Hub deve ricevere il messaggio ed Exchange Server 2007 deve trasferirlo alla destinazione finale.

Se SharePoint non riesce a trasferire il messaggio al servizio SMTP, in genere sarà visualizzato un errore nell'interfaccia utente, poiché l'invio di una notifica tramite posta elettronica non è possibile. La causa può essere la mancata esecuzione del servizio SMTP. In alternativa il registro di protocollo SMTP potrebbe comunicare che il servizio SMTP ha rifiutato il tentativo di invio con il codice di errore 550 (L'azione richiesta non è stata eseguita: cassetta postale non disponibile), il quale indica che il problema interessa il servizio SMTP.

Per verificare che non si tratti di un problema relativo a SharePoint, è possibile utilizzare uno script di base (vedere SMTP.vbs nel materiale di accompagnamento) per inviare un messaggio di test tramite SMTP con le stesse informazioni su mittente e destinatario. Se si tratta di un problema relativo al servizio SMTP, lo script non avrà esito positivo. In effetti, questo script potrebbe fornire utili indizi sulla causa principale del problema, che purtroppo non è possibile ottenere da SharePoint neppure se il debug è attivo, come illustrato in Figura 3.

Figura 3 Inoltro dei messaggi impossibile (fare clic sull'immagine per ingrandirla)

Concedendo al server Web le autorizzazioni di inoltro nella configurazione del servizio SMTP e riavviando quest'ultimo, è possibile risolvere il problema di invio dei messaggi SharePoint. Ora il messaggio può raggiungere il servizio SMTP e la domanda seguente è se il servizio SMTP può eseguire il routing al server Trasporto Hub.

Se il messaggio rimane nella cartella della coda, il servizio SMTP non è in grado di contattare il server Trasporto Hub. Questo si verifica perché il servizio Microsoft Exchange Transport non è in esecuzione oppure a causa di un problema di configurazione o comunicazione di rete. Il client Telnet consente di verificare in modo rapido e semplice se è possibile connettersi alla porta di destinazione di un connettore di ricezione configurato per la comunicazione interna.

Non si tratta necessariamente della porta TCP 25. Infatti, se il servizio SMTP utilizza questa porta, è possibile trasferire i messaggi al connettore di ricezione predefinito per i server Trasporto Hub, configurato in modo da bloccare l'invio di messaggi anonimi. In questo caso, sarà visualizzato un messaggio nella cartella di ricezione (arrestare il servizio Windows SharePoint Services Timer; in caso contrario, il messaggio scomparirà dopo alcuni secondi). Il file del messaggio è una notifica sullo stato del recapito indicante che il messaggio è stato rifiutato con "Codice diagnostica: smtp;530 5.7.1 Il client non è stato autenticato".

Per risolvere il problema, occorre creare un connettore di ricezione dedicato per i server SharePoint. Poiché i server SharePoint sono sistemi interni, selezionare l'opzione di autenticazione con protezione esterna. In tal modo, non è necessario concedere autorizzazioni estese all'account di ACCESSO ANONIMO. Inoltre, valutare l'utilizzo di IPsec per proteggere la comunicazione tra i server SharePoint e il server Trasporto Hub.

Se i messaggi lasciano la cartella di coda SMTP e i registri del protocollo SMTP sul server SharePoint e sul server Trasporto Hub (verificare la cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indicano che il trasferimento è stato eseguito correttamente, è possibile considerare l'operazione terminata, a patto che Exchange Server 2007 riesca a eseguire il routing del messaggio alla destinazione. Come accennato in precedenza, utilizzare gli strumenti per la risoluzione dei problemi di flusso della posta inclusi in Exchange Server 2007 per verificare eventuali cause nel caso in cui i messaggi non raggiungano i destinatari Exchange. In questa fase informazioni inesatte sui destinatari, filtri antispam e restrizioni di dimensione dei messaggi possono impedire la consegna finale.

Trasferimento di messaggi in entrata

Nella direzione opposta il trasferimento dei messaggi è un po' più complesso, poiché i potenziali problemi sono meno evidenti. Ad esempio, nella documentazione sui prodotti SharePoint, si consiglia di configurare i record MX in DNS per i domini di posta elettronica SharePoint, per favorire il routing errato dei messaggi in un'organizzazione Exchange.

Exchange Server 2007 utilizza connettori di invio con spazi di indirizzi associati per il trasferimento dei messaggi. Potrebbe quindi instradare i messaggi SharePoint ai server Trasporto Edge per il trasferimento tramite Internet, anche se i server SharePoint dell'utente sono interni. Per il trasferimento di messaggi interni, preferire l'utilizzo di connettori di invio con spazi degli indirizzi dettagliati e specificare i server SharePoint che eseguono il servizio SMTP come smart host nella configurazione dei connettori (vedere il documento pdf sull'integrazione della messaggistica SharePoint nel download complementare). Stabilire una tipologia di routing ben definita con server di testa di ponte dedicati garantisce che il trasferimento di messaggi da Exchange a SharePoint avvenga in modo affidabile.

Al fine di verificare che i messaggi giungano ai server SharePoint, arrestare il servizio Windows SharePoint Services Timer. I messaggi si accumuleranno nella cartella di ricezione, poiché è il servizio Timer a elaborarli e a collocare i file di allegati in raccolte documenti associate agli indirizzi di posta elettronica dei destinatari, come indicato nella Figura 4. Se i messaggi non raggiungono la cartella di ricezione, utilizzare il visualizzatore code sul server Trasporto Hub per verificare se Exchange esegue correttamente il routing. Quindi, analizzare i problemi relativi alla comunicazione di rete che potrebbero impedire al server Trasporto Hub di comunicare con il servizio SMTP sul server SharePoint.

Figura 4 Trasferimento di messaggi in entrata (fare clic sull'immagine per ingrandirla)

Quando si riavvia il servizio Timer, i messaggi vengono rimossi dalla cartella di ricezione. Tuttavia, se gli allegati dei messaggi non vengono inseriti nelle raccolte di destinazione, sebbene SharePoint indichi nel registro eventi di Windows che l'elaborazione è stata eseguita correttamente, significa che Exchange ha inviato i messaggi in formato RTF. Per esaminare questo problema, arrestare nuovamente il servizio Timer, inviare un altro messaggio con un allegato dal client Outlook® in uso, quindi, una volta presente nella cartella di ricezione, aprirlo in Blocco note. A questo punto, ricercare la stringa "winmail.dat". Se è presente, Exchange Server invia i messaggi nel formato sbagliato.

Per SharePoint, infatti, gli allegati di messaggi devono essere codificati nei formati MIME o UUENCODE. Inoltre, nel registro eventi di Windows, SharePoint non visualizza problemi di elaborazione legati a winmail.dat (vedere Figura 5). Semplicemente, gli allegati dei file non saranno visualizzati nella raccolta documenti. Utilizzare Blocco note come strumento per la risoluzione dei problemi ed eliminare i problemi di formattazione configurando una definizione di dominio remoto in Exchange Management Console per il dominio di posta elettronica SharePoint. In corrispondenza dell'opzione Formato del messaggio originale inviato come allegato al rapporto del journal, per Formato RTF di Exchange, selezionare Never use (Mai).

Figura 5 Elaborazione di messaggi winmail.dat (fare clic sull'immagine per ingrandirla)

Gestione directory

Uno degli eventi più utili del servizio Timer è il 6873, il quale indica che si è verificato un errore durante l'elaborazione di un messaggio di posta elettronica in entrata a causa di un alias sconosciuto. Ciò accade se un utente Exchange specifica un indirizzo di posta elettronica SharePoint non corretto durante l'invio di messaggi, ad esempio una raccolta documenti inesistente.

È possibile ridurre al minimo l'impatto di questo problema configurando il servizio di gestione directory nelle impostazioni dei messaggi di posta elettronica in entrata nell'Amministrazione centrale di SharePoint per la creazione di oggetti destinatario per le raccolte documenti abilitate alla posta in Active Directory. Gli utenti Exchange potranno quindi selezionare comodamente dalla rubrica gli oggetti destinatario con informazioni relative all'indirizzo corrette.

Tuttavia, in questo modo, si apre una nuova area di tematiche legate alla risoluzione dei problemi. In una configurazione di sistema protetta basata sul principio del privilegio minimo, il servizio di gestione directory non opera correttamente, in quanto questa funzionalità ha requisiti di autorizzazione elevati sul server Web. Per di più, quando nella documentazione del prodotto (ad esempio technet.microsoft.com/library/cc262947.aspx) viene suggerito di concedere all'account del pool di applicazioni dell'Amministrazione centrale il diritto di "creare, eliminare e gestire gli account utente" nell'unità organizzativa specificata per gli oggetti destinatario SharePoint in Active Directory, la situazione è sopravvalutata.

Il servizio di gestione directory crea oggetti di contatto e gruppo, pertanto, l'account del pool di applicazioni di Amministrazione centrale richiede il controllo completo sugli oggetti di questo tipo in tale unità organizzativa, ma non necessita di autorizzazioni amministrative per gli account utente. Se si configura il servizio di gestione directory in una Web farm come indicato e si tenta di abilitare alla posta una raccolta documenti, sussistono buone probabilità che si verifichi un errore di "Accesso negato".

Le informazioni dell'errore indicano problemi relativi all'autorizzazione di Active Directory e gli amministratori SharePoint non esitano ad assegnare il controllo completo relativo all'unità organizzativa SharePoint a tutti gli utenti. Tuttavia, questo indebolisce la sicurezza di Active Directory, oltre a non risolvere il problema.

Una risoluzione dei problemi strutturata prevede che venga dapprima localizzata l'area interessata e poi siano applicate modifiche della configurazione adeguate. Seguendo questo approccio, se si verifica il registro eventi di Windows sul controller di dominio e si esegue una traccia della comunicazione di rete tramite Network Monitor, si potrà scoprire che SharePoint non accede ad Active Directory quando si verifica questo problema. Quindi, è improbabile che eventuali modifiche alla configurazione di Active Directory risolvano il problema che, in effetti, si verifica sul server SharePoint.

Purtroppo, ottenere ulteriori informazioni utili su questo problema di autorizzazione è estremamente difficile. SharePoint, infatti, non registra ulteriori informazioni nel registro eventi di Windows. Tuttavia, se si attiva il debug di SharePoint, è possibile visualizzare lo stack di chiamate (come illustrato nella Figura 6), il quale suggerisce che il servizio di gestione directory utilizza il metodo CreateContact di un servizio Web SharePoint. L'SDK SharePoint indicherà che si tratta del servizio Web di integrazione di messaggi di posta elettronica (<WSS_server>:<admin_port>/_Vti_bin/SharepointEmailWS.asmx).

Figura 6 Output del debug

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

Ora è utile esaminare SharepointEmailWS.asmx in un browser Web per visualizzare l'elenco di operazioni supportate. È possibile vedere il metodo CreateContact: facendo clic sul relativo collegamento, saranno visualizzati i messaggi SOAP da inviare a questo servizio Web per creare un contatto in Active Directory. Questa informazione è molto utile, poiché consente di creare uno strumento per la risoluzione dei problemi basato su script (vedere SharepointEmailWS.vbs nel materiale di accompagnamento) per operare al di fuori dell'interfaccia utente SharePoint, semplificando la definizione di diversi account utente durante l'esecuzione dei test. Nella Figura 7 sono indicate le informazioni visualizzate se si esegue lo script utilizzando l'account del pool di applicazioni di Amministrazione centrale (sinistra) e l'account di amministratore SharePoint (destra).

Figura 7 Due diversi errori di "Accesso negato" (fare clic sull'immagine per ingrandirla)

I messaggi di errore sono diversi. Entrambi i messaggi indicano che l'accesso è negato, ma l'errore sulla sinistra indica un problema di elaborazione, mentre quello sulla destra no. Quindi, qual è la differenza tra gli account del pool di applicazioni e l'account di amministratore SharePoint?

L'amministratore SharePoint è un amministratore locale sul server SharePoint, mentre gli account di pool di applicazioni non lo sono. Aggiungere gli account di pool di applicazioni della propria applicazione Web al gruppo di amministratori locali e riavviare il server risolve il problema, ma questa non è una novità. Considero inaccettabile la gestione di account di pool di applicazione con privilegi di amministratore sui server Web di produzione.

Perché un account di pool di applicazioni richiede queste autorizzazioni elevate? Di nuovo, è lo script a fornire la risposta. Se si concedono a tutti gli utenti autorizzazioni di amministratore locale sul server Web a scopo di verifica, si scoprirà che gli account di pool di applicazioni possono utilizzare il servizio Web di integrazione della posta elettronica, mentre l'accesso continua a essere negato a tutti gli altri account, inclusi gli amministratori SharePoint. Ciò significa che il servizio Web di integrazione dei messaggi di posta elettronica utilizza la configurazione del pool di applicazioni come base per le decisioni sul controllo dell'accesso.

La configurazione del pool di applicazioni fa parte della metabase IIS (o il file applicationHost.config in IIS 7.0) e l'accesso alla metabase è limitato agli amministratori locali per impostazione predefinita. Per fortuna, è possibile concedere l'accesso alla metabase ad account non amministrativi utilizzando il Metabase Explorer contenuto negli strumenti del Resource Kit IIS 6.0. Su IIS 7.0 è ancora più semplice concedere il controllo completo al file applicationHost.config. È sufficiente eseguire i comandi seguenti:

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

Per riassumere, al fine di creare oggetti di contatto in Active Directory, il pool di applicazioni di Amministrazione centrale richiede il controllo completo sugli oggetti di contatto e gruppo nell'unità organizzativa di destinazione. Anche gli account di pool delle applicazioni Web richiedono un accesso completo alla metabase sui server SharePoint nella Web farm. A questo punto, è possibile creare oggetti di contatto utilizzando l'interfaccia utente SharePoint.

Ma non è finita qui. La creazione di oggetti destinatario in Active Directory è solo una metà dell'operazione di integrazione delle directory. L'altra metà consiste nel generare attributi destinatario relativi a Exchange e nell'aggiornare rubriche basate su server. Ad esempio, se si aggiorna l'elenco di indirizzi globale sul proprio server Exchange utilizzando il comando di Exchange Management Shell Update-GlobalAddressList "Elenco indirizzi globale predefinito", sarà possibile trovare nuovi oggetti destinatario per le raccolte documenti SharePoint all'interno della rubrica Outlook. Tuttavia, l'invio di messaggi a questi destinatari genererà report di mancata consegna a causa delle informazioni sull'indirizzo non corrette, come illustrato nella Figura 8.

Figura 8 Impossibile recapitare il messaggio a una raccolta documenti (fare clic sull'immagine per ingrandirla)

L'acronimo IMCEAEX significa Internet Mail Connector Encapsulated Address for Exchange (indirizzo di connettore di posta elettronica Internet incapsulato per Exchange) e indica un indirizzo di destinatario diverso da Exchange incapsulato in un formato che il precedente connettore di posta Internet Exchange è in grado di gestire. Tuttavia, oggi vengono utilizzati Exchange Server 2007 e connettori di invio nativi basati su SMTP.

Il punto è che il servizio Web di integrazione di posta elettronica SharePoint non scrive gli attributi dell'indirizzo che Exchange Server 2007 richiede per il trasferimento dei messaggi, Il servizio scrive solo gli attributi relativi a nome, cognome, nome visualizzato e indirizzo di destinazione (e, facoltativamente, l'msExch­RequireAuthToSendTo), ma non imposta un nome alternativo di posta, oppure indirizzi proxy o DN Exchange legacy, e non associa l'oggetto destinatario a un criterio sui destinatari Exchange.

Per risolvere questo problema, utilizzare il cmdlet Get-Mailbox in Exchange Management Shell al fine di ottenere tutti gli oggetti destinatario con un indirizzo di destinazione che indichi il dominio di posta elettronica SharePoint. Quindi, inviare l'output al cmdlet Set-MailContact per attivare i criteri destinatario come segue:

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

In alternativa, utilizzare Exchange Management Console e selezionare la casella di controllo "Aggiorna automaticamente indirizzi in base al criterio dell'indirizzo di posta elettronica" nelle proprietà dell'oggetto di contatto.

WSS 3.0 e MOSS 2007 supportano l'integrazione di messaggistica completa per l'abilitazione di avvisi e notifiche basati su messaggi di posta elettronica, flussi di lavoro e invio di documenti. La corretta configurazione dei sistemi non è un compito facile, ma l'integrazione dei messaggi può aumentare la produttività. In particolare, occorre assicurarsi che entrambi i trasferimenti di messaggi in entrata e in uscita funzionino correttamente. Inoltre, accertarsi che l'integrazione delle directory funzioni adeguatamente.

Non sempre i messaggi di errore SharePoint sono intuitivi o informativi. Tuttavia, ho illustrato diversi metodi per approfondire i problemi di integrazione, localizzare le cause principali ed eliminarle in modo sicuro senza mettere in pericolo la protezione dei server SharePoint.

Pav Cherny è un esperto IT e un autore specializzato in tecnologie Microsoft per la collaborazione e le comunicazioni unificate. Le sue pubblicazioni includono white paper, manuali di prodotti e libri su amministrazione del sistema e operazioni IT. Pav è Presidente di Biblioso Corporation, un'azienda specializzata in servizi di localizzazione e documentazione gestita.

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