Pianificare la ricerca per indicizzazione e la federazione (SharePoint Server 2010)

Articolo
03/05/2017

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

Prima che gli utenti finali possano utilizzare la funzionalità di ricerca di contenuti nell'organizzazione in Microsoft SharePoint Server 2010, è necessario sottoporre a ricerca per indicizzazione o a federazione il contenuto che si desidera rendere disponibile per l'esecuzione di ricerche da parte degli utenti. La pianificazione della ricerca per indicizzazione o della federazione prevede le attività seguenti:

Pianificare le origini di contenuto
Pianificare le inclusioni di tipi di file e filtri IFilter
Pianificare l'autenticazione
Pianificare i connettori
Pianificare la gestione dell'impatto della ricerca per indicizzazione
Pianificare le regole di ricerca per indicizzazione
Pianificare le impostazioni di ricerca gestite a livello di farm
Pianificare la federazione

Pianificare le origini di contenuto

Un'origine di contenuto è un insieme di opzioni che è possibile utilizzare per specificare il tipo di contenuto in cui viene eseguita la ricerca per indicizzazione, gli URL in cui eseguire tale ricerca, nonché il livello di estensione e la programmazione della ricerca stessa. L'origine di contenuto predefinita è Siti di SharePoint locali e può essere utilizzata per specificare la modalità di esecuzione della ricerca per indicizzazione nell'intero contenuto di tutte le applicazioni Web associate a una determinata applicazione del servizio di ricerca. Per impostazione predefinita, per ogni applicazione Web in cui viene utilizzata una certa applicazione del servizio di ricerca, SharePoint Server 2010 aggiunge l'indirizzo iniziale del sito principale di ogni raccolta siti all'origine di contenuto predefinita.

Per alcune organizzazioni l'utilizzo della sola origine di contenuto predefinita è sufficiente a soddisfare i requisiti di ricerca, ma per molte organizzazioni sono necessarie origini di contenuto aggiuntive. Pianificare ulteriori origini di contenuto quando è necessario:

Eseguire la ricerca per indicizzazione in diversi tipi di contenuto, ad esempio siti di SharePoint, condivisioni file e dati business.
Eseguire la ricerca per indicizzazione in alcuni contenuti con programmazioni diverse da quelle di altro contenuto.
Limitare o aumentare la quantità di contenuto in cui viene eseguita la ricerca per indicizzazione.
Impostare priorità diverse per eseguire la ricerca per indicizzazione in siti diversi.

In ogni applicazione del servizio di ricerca è possibile creare fino a 500 origini di contenuto e ognuna di queste origini può contenere fino a 500 indirizzi iniziali. Per mantenere l'amministrazione il più agevole possibile, è consigliabile limitare il numero delle origini di contenuto create.

Pianificare l'esecuzione della ricerca per indicizzazione in tipi diversi di contenuto

Per ogni origine di contenuto è possibile eseguire la ricerca per indicizzazione in un solo tipo di contenuto. Ciò significa che è possibile creare un'origine di contenuto che includa gli indirizzi iniziali dei siti di SharePoint e un'altra origine di contenuto che includa gli indirizzi iniziali delle condivisioni file. Non è invece possibile creare un'origine di contenuto che includa gli indirizzi iniziali sia di siti di SharePoint che di condivisioni file. Nella tabella riportata di seguito sono elencati i tipi di origini di contenuto che è possibile configurare.

Utilizzare questo tipo di origine di contenuto	Per questo contenuto
Siti di SharePoint	Siti di SharePoint della stessa farm o di farm di Microsoft SharePoint Server 2010, Microsoft SharePoint Foundation 2010 o Server di ricerca 2010 Microsoft diverse Siti di SharePoint della stessa farm o di farm di Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3,0 o Server di ricerca 2008 Microsoft diverse Siti di SharePoint di farm di Microsoft Office SharePoint Portal Server 2003 o Windows SharePoint Services 2.0 Nota Diversamente da quanto accade per l'esecuzione della ricerca per indicizzazione nei siti di SharePoint in SharePoint Server 2010, SharePoint Foundation 2010 o Search Server 2010, il crawler non è in grado di eseguire automaticamente la ricerca per indicizzazione in tutti i siti secondari di una raccolta siti di versioni precedenti di Prodotti e tecnologie SharePoint. Quando pertanto si esegue la ricerca per indicizzazione in siti di SharePoint di versioni precedenti, è necessario specificare l'indirizzo iniziale di ogni sito principale e l'URL di ogni sito secondario da sottoporre a tale ricerca.
Siti Web	Altro contenuto Web dell'organizzazione non disponibile in siti di SharePoint Contenuto presente in siti Web su Internet
Condivisioni file	Contenuto nelle condivisioni file dell'organizzazione
Cartelle pubbliche di Exchange	Contenuto di Microsoft Exchange Server
Note di Lotus Notes	Messaggi di posta elettronica archiviati nei database di Lotus Notes Nota A differenza di tutti gli altri tipi di origini di contenuto, l'opzione relativa a un'origine di contenuto Lotus Notes non viene visualizzata nell'interfaccia utente finché non viene installato e configurato il software necessario appropriato. Per ulteriori informazioni, vedere Configure and use the Lotus Notes connector (SharePoint Server 2010).
Dati business	Dati business archiviati in applicazioni line-of-business

Pianificare le origini di contenuto per dati business

Le origini di contenuto dati business richiedono che le applicazioni che ospitano i dati siano specificate in un modello applicativo in un'applicazione del servizio di integrazione applicativa dei dati. È possibile creare un'origine di contenuto per eseguire la ricerca per indicizzazione in tutte le applicazioni registrate in tale servizio oppure creare origini di contenuto separate per eseguire la ricerca per indicizzazione nelle singole applicazioni.

Le persone che pianificano l'integrazione dei dati business in raccolte siti spesso non sono le stesse persone impegnate nel processo di pianificazione del contenuto globale. Includere pertanto amministratori delle applicazioni aziendali nei team di pianificazione del contenuto, in modo che possano consigliare come integrare i dati di tali applicazioni nel contenuto e come presentarli in modo efficace nelle raccolte siti.

Eseguire la ricerca per indicizzazione nel contenuto con programmazioni diverse

È necessario decidere se la ricerca per indicizzazione deve essere eseguita con maggiore frequenza in un determinato tipo di contenuto rispetto ad altri contenuti. Maggiore è il volume di contenuto da sottoporre alla ricerca per indicizzazione, maggiore è la probabilità che il contenuto provenga da archivi diversi. Il contenuto potrebbe non essere dello stesso tipo e potrebbe trovarsi in server di capacità diverse. Questi fattori rendono più probabile la necessità di aggiungere origini di contenuto per eseguire la ricerca per indicizzazione nei diversi archivi contenuti in base a programmazioni diverse.

I motivi principali per cui eseguire la ricerca per indicizzazione nel contenuto con programmazioni diverse sono i seguenti:

Necessità di bilanciare i periodi di inattività con quelli di massimo utilizzo
Necessità di sottoporre più frequentemente alla ricerca per indicizzazione il contenuto aggiornato più spesso
Necessità di eseguire la ricerca per indicizzazione nel contenuto disponibile nei server più lenti separatamente rispetto al contenuto presente nei server più veloci

In molti casi alcune di queste informazioni diventano note solo dopo avere distribuito SharePoint Server 2010 e averlo utilizzato per qualche tempo. In queste circostanze è necessario specificare le programmazioni per la ricerca per indicizzazione dopo che la farm viene inserita nell'ambiente di produzione. È comunque opportuno tenere conto di tali fattori durante la pianificazione, in modo da pianificare al meglio le programmazioni per l'esecuzione di tale ricerca in base alle informazioni di cui si dispone.

Nelle due sezioni seguenti vengono fornite ulteriori informazioni sull'esecuzione della ricerca per indicizzazione nel contenuto in base a programmazioni diverse.

Considerazioni per la pianificazione delle programmazioni relative alla ricerca per indicizzazione

È possibile configurare le programmazioni per la ricerca per indicizzazione in modo indipendente per ogni origine di contenuto, specificando inoltre quando eseguire le ricerche complete e quando eseguire quelle incrementali. Si noti che è necessario eseguire una ricerca per indicizzazione completa per una determinata origine di contenuto prima di poter eseguire una ricerca per indicizzazione incrementale. Se si sceglie una ricerca per indicizzazione incrementale per il contenuto di cui non è ancora stata eseguita la ricerca per indicizzazione, il sistema esegue comunque una ricerca per indicizzazione completa.

Nota

Poiché una ricerca per indicizzazione completa viene eseguita su tutto il contenuto che il crawler rileva e per cui dispone almeno dell'accesso in lettura, indipendentemente dal fatto che tale contenuto in precedenza sia stato o meno sottoposto a una ricerca di questo tipo, la procedura completa può richiedere molto più tempo rispetto alla procedura incrementale.

È consigliabile pianificare programmazioni di ricerca per indicizzazione in base alle considerazioni di disponibilità, prestazioni e larghezza di banda dei server che eseguono il servizio di ricerca e dei server di query.

Quando si pianificano programmazioni di ricerca per indicizzazione, tenere presenti le procedure consigliate seguenti:

Raggruppare gli indirizzi iniziali nelle origini di contenuto in base a disponibilità simili e un utilizzo generale delle risorse accettabile per i server che ospitano il contenuto.
Programmare ricerche per indicizzazione incrementali per ogni origine di contenuto nei periodi in cui i server che ospitano il contenuto sono disponibili e quando la richiesta delle risorse del server è limitata.
Scaglionare le programmazioni della ricerca per indicizzazione in modo da distribuire nel tempo il carico sui server della farm.
Programmare ricerche per indicizzazione complete quando necessarie per i motivi elencati nella sezione riportata di seguito. È consigliabile eseguire le ricerche per indicizzazione complete con minore frequenza rispetto a quelle incrementali.
Programmare l'esecuzione delle modifiche amministrative che richiedono una ricerca per indicizzazione completa poco prima della programmazione pianificata per le ricerche per indicizzazione complete. È ad esempio consigliabile programmare la creazione della regola di ricerca per indicizzazione prima della successiva ricerca per indicizzazione completa programmata, affinché non sia necessaria una ricerca per indicizzazione completa aggiuntiva.
Basare le ricerche per indicizzazione simultanee sulla capacità disponibile. Per ottenere prestazioni ottimali, è consigliabile scaglionare le programmazioni delle ricerche per indicizzazione nelle origini di contenuto. È possibile sviluppare nel tempo una strategia per la programmazione delle ricerche per indicizzazione man mano che si acquisisce familiarità con la durata delle ricerche per indicizzazione tipica per ogni origine di contenuto.

Motivi per eseguire una ricerca per indicizzazione completa

Tra i motivi per cui l'amministratore di un'applicazione del servizio di ricerca esegue una ricerca per indicizzazione completa vi sono i seguenti:

È stato installato un aggiornamento software o un Service Pack nei server della farm. Per ulteriori informazioni, vedere le istruzioni per l'aggiornamento software o il Service Pack.
Un amministratore dei servizi condivisi di Microsoft Office SharePoint Server 2007 o l'amministratore di un'applicazione del servizio di ricerca di SharePoint Server 2010 ha aggiunto una nuova proprietà gestita. La ricerca per indicizzazione completa è necessaria perché tale proprietà diventi immediatamente effettiva. Se non si desidera che la nuova proprietà gestita diventi immediatamente effettiva, non eseguire una ricerca per indicizzazione completa.
Per reindicizzare le pagine ASPX nei siti di Windows SharePoint Services 3,0 o Microsoft Office SharePoint Server 2007.

Nota

Il crawler non è in grado di individuare modifiche alle pagine ASPX in siti di Windows SharePoint Services 3,0 o Office SharePoint Server 2007. Per questo motivo le ricerche per indicizzazione incrementali non determinano la reindicizzazione di visualizzazioni o home page quando vengono eliminati singoli elementi di elenco. È consigliabile eseguire periodicamente ricerche per indicizzazione complete dei siti che contengono file ASPX per garantire che queste pagine vengano reindicizzate.
Per risolvere errori consecutivi nelle ricerche per indicizzazione incrementali. Nei rari casi in cui in una ricerca per indicizzazione incrementale si verifica un errore per cento volte consecutive a qualsiasi livello di un archivio, il sistema rimuove il contenuto interessato dall'indice.
Sono state aggiunte, eliminate o modificate regole di ricerca per indicizzazione.
Per ripristinare un indice danneggiato.
L'amministratore dell'applicazione del servizio di ricerca ha creato uno o più mapping di nomi server
Sono state modificate le credenziali dell'account utente assegnato all'account predefinito di accesso al contenuto oppure è stata modificata una regola di ricerca per indicizzazione

Il sistema esegue una ricerca per indicizzazione completa anche quando viene richiesta una ricerca per indicizzazione incrementale nelle circostanze seguenti:

Un amministratore della ricerca ha interrotto la ricerca per indicizzazione precedente.
È stato ripristinato un database del contenuto oppure l'amministratore di una farm ha scollegato e ricollegato un database del contenuto.

Nota

Se si esegue Office SharePoint Server 2007 con l'aggiornamento dell'infrastruttura per Microsoft Office Server o SharePoint Server 2010, sarà possibile utilizzare l'operazione restore dello strumento da riga di comando Stsadm per decidere se il ripristino di un database del contenuto determini o meno una ricerca per indicizzazione completa.
Dall'applicazione del servizio di ricerca non è mai stata eseguita una ricerca per indicizzazione completa del sito.
Il registro delle modifiche non contiene voci per gli indirizzi sottoposti a ricerca per indicizzazione. Senza tali voci non è possibile eseguire ricerche per indicizzazione incrementali.

È possibile modificare le programmazioni dopo la distribuzione iniziale in base alle prestazioni e alla capacità dei server della farm e dei server che ospitano il contenuto.

Limitare o aumentare la quantità di contenuto sottoposto a ricerca per indicizzazione

Per ogni origine di contenuto, è possibile specificare quanto ampiamente eseguire la ricerca per indicizzazione negli indirizzi iniziali. È inoltre possibile specificare il comportamento della ricerca per indicizzazione modificando le relative impostazioni. Le opzioni che è possibile scegliere per una determinata origine di contenuto variano in base al tipo di origine di contenuto selezionato. La maggior parte delle opzioni determina tuttavia quanti livelli della gerarchia vengono sottoposti a ricerca per indicizzazione da ciascun indirizzo iniziale. Si noti che questo comportamento viene applicato a tutti gli indirizzi iniziali di un'origine di contenuto specifica. Se in alcuni siti è necessario eseguire la ricerca per indicizzazione a livello più profondo, è possibile creare ulteriori origini di contenuto che includano tali siti.

È possibile utilizzare le opzioni di impostazione della ricerca per indicizzazione per limitare o la quantità di contenuto da sottoporre alla ricerca per indicizzazione. Le opzioni disponibili nelle proprietà di ogni origine di contenuto variano in base al tipo di origine di contenuto selezionato. Nella tabella riportata di seguito sono descritte le procedure consigliate per configurare le opzioni di impostazione della ricerca per indicizzazione.

Per questo tipo di origine di contenuto	Se la situazione è pertinente	Utilizzare questa opzione di impostazione della ricerca per indicizzazione
Siti di SharePoint	Si desidera includere il contenuto del sito stesso e non si desidera includere il contenuto disponibile nei siti secondari o si desidera eseguire la ricerca per indicizzazione nel contenuto dei siti secondari in base a una programmazione diversa	Solo il sito di SharePoint di ogni indirizzo iniziale
Siti di SharePoint	Si desidera includere il contenuto del sito stesso -oppure- Si desidera eseguire la ricerca per indicizzazione in tutto il contenuto nell'indirizzo iniziale in base alla stessa programmazione	Tutto il contenuto nel nome host per ogni indirizzo iniziale
Siti Web	Il contenuto disponibile nei siti collegati probabilmente non è pertinente	Solo nel server di ogni indirizzo iniziale
Siti Web	Il contenuto pertinente si trova solo nella prima pagina	Solo la prima pagina di ogni indirizzo iniziale
Siti Web	Si desidera limitare l'estensione della ricerca per indicizzazione nei collegamenti negli indirizzi iniziali	Personalizzata - specificare il livello di pagine e i passaggi tra server Nota È consigliabile iniziare con un numero ridotto in un sito molto ben connesso. Specificare più di tre livelli di pagine o più di tre passaggi tra server significherebbe eseguire una ricerca per indicizzazione in tutta Internet.
Condivisioni file Cartelle pubbliche di Exchange	Il contenuto disponibile nelle sottocartelle non è probabilmente pertinente	Solo la cartella di ogni indirizzo iniziale
Condivisioni file Cartelle pubbliche di Exchange	Il contenuto nelle sottocartelle è probabilmente pertinente	La cartella e tutte le sottocartelle di ogni indirizzo iniziale
Dati business	Tutte le applicazioni registrate nell'archivio dei metadati BDC includono contenuto pertinente	L'intero archivio dei metadati BDC
Dati business	Non tutte le applicazioni registrate nell'archivio dei metadati BDC includono contenuto pertinente -oppure- Si desidera eseguire la ricerca per indicizzazione in alcune applicazioni con una programmazione diversa	Applicazioni selezionate

Altre considerazioni per la pianificazione delle origini di contenuto

Non è possibile eseguire la ricerca per indicizzazione negli stessi indirizzi iniziali utilizzando più origini di contenuto nella medesima applicazione del servizio di ricerca. Se ad esempio si utilizza una determinata origine di contenuto per eseguire la ricerca per indicizzazione in una raccolta siti e in tutti i relativi siti secondari, non sarà possibile utilizzare un'origine di contenuto diversa per eseguire la ricerca per indicizzazione in uno di tali siti secondari separatamente in base a una programmazione diversa.

Oltre che dalle programmazioni della ricerca per indicizzazione, la decisione di raggruppare gli indirizzi iniziali in un'unica origine di contenuto o di creare ulteriori origini di contenuto dipende in modo significativo da considerazioni relative all'amministrazione. Gli amministratori spesso apportano modifiche che aggiornano una determinata origine di contenuto. La modifica di un'origine di contenuto richiede una ricerca per indicizzazione completa nell'archivio contenuti specificato nell'origine stessa. Per semplificare l'amministrazione, organizzare le origini di contenuto in modo tale che il relativo aggiornamento, le regole di ricerca per indicizzazione e le programmazioni della ricerca siano agevoli per gli amministratori.

Pianificare le inclusioni di tipi di file e filtri IFilter

Il contenuto viene sottoposto a ricerca per indicizzazione solo se l'estensione del nome di file pertinente è inclusa nell'elenco di inclusioni di tipi di file e se un filtro IFilter che supporta tali tipi di file è installato nel server di indicizzazione. Durante l'installazione iniziale vengono inclusi automaticamente diversi tipi di file. Durante la pianificazione delle origini di contenuto nella distribuzione iniziale determinare se il contenuto che si desidera sottoporre a ricerca per indicizzazione utilizza tipi di file non inclusi. Se i tipi di file non sono inclusi, sarà necessario aggiungere tali tipi di file nella pagina Gestisci tipi di file durante la distribuzione e accertarsi che un filtro IFilter sia installato e registrato per supportare quei tipi di file.

Se invece si desidera escludere determinati tipi di file dalla ricerca per indicizzazione, è possibile eliminare l'estensione del tipo di file dall'elenco delle inclusioni dei tipi di file. In questo modo, i nomi di file con tale estensione verranno esclusi dalla ricerca per indicizzazione. Per un elenco dei tipi di file e dei filtri IFilter installati per impostazione predefinita, vedere File types and IFilters reference (SharePoint Server 2010).

Pianificare l'autenticazione

Quando il crawler accede agli indirizzi iniziali elencati nelle origini di contenuto, è necessario che venga autenticato dai server che ospitano tale contenuto e che disponga dell'accesso a questi server. Questo significa che l'account di dominio utilizzato dal crawler deve avere almeno le autorizzazioni di lettura per il contenuto.

Per impostazione predefinita, il sistema utilizza l'account di accesso predefinito al contenuto. In alternativa, è possibile utilizzare le regole di ricerca per indicizzazione per specificare un account di accesso al contenuto diverso da utilizzare durante la ricerca per indicizzazione in contenuti particolari. Indipendentemente dall'utilizzo dell'account di accesso predefinito al contenuto oppure di un account diverso specificato da una regola di ricerca per indicizzazione, l'account di accesso al contenuto utilizzato deve disporre delle autorizzazioni di lettura per tutto il contenuto di cui viene eseguita la ricerca per indicizzazione, altrimenti il contenuto non verrà sottoposto a ricerca per indicizzazione, non verrà indicizzato e non sarà disponibile per le query.

È consigliabile selezionare un account di accesso al contenuto predefinito con l'accesso più ampio alla maggior parte del contenuto sottoposto a ricerca per indicizzazione e utilizzare altri account di accesso al contenuto solo quando, per motivi di sicurezza, sono necessari account di accesso al contenuto distinti.

Per ogni origine di contenuto pianificata, identificare gli indirizzi iniziali a cui non è possibile accedere tramite l'account di accesso al contenuto predefinito e pianificare l'aggiunta di regole di ricerca per indicizzazione per tali indirizzi iniziali.

Importante

Verificare che l'account di dominio utilizzato come account predefinito di accesso al contenuto o qualsiasi altro account di accesso al contenuto non sia lo stesso account di dominio utilizzato da un pool di applicazioni associato a un'applicazione Web sottoposta a ricerca per indicizzazione. Ciò può causare l'indicizzazione e la ricerca per indicizzazione nel contenuto non pubblicato dei siti di SharePoint e di versioni secondarie dei file (cronologia) nei siti di SharePoint.

Un'altra considerazione importante è che il crawler deve utilizzare lo stesso protocollo di autenticazione del server host. Per impostazione predefinita, il crawler esegue l'autenticazione mediante NTLM. È possibile configurare il crawler per l'utilizzo di un protocollo di autenticazione diverso, se necessario.

Se si utilizza l'autenticazione basata sulle attestazioni, assicurarsi che l'autenticazione di Windows sia attivata per qualsiasi applicazione Web in cui eseguire la ricerca per indicizzazione.

Pianificare i connettori

Tutto il contenuto in cui viene eseguita la ricerca per indicizzazione richiede l'utilizzo di un connettore (indicato come gestore di protocollo nelle versioni precedenti) per accedere al contenuto stesso. SharePoint Server 2010 offre connettori per tutti i protocolli Internet comuni. Se tuttavia si desidera eseguire la ricerca per indicizzazione in contenuto che richiede un connettore non installato con SharePoint Server 2010, è necessario installare il connettore personalizzato o di terze parti prima di eseguire la ricerca per indicizzazione in tale contenuto. Per un elenco dei connettori installati per impostazione predefinita, vedere Default connectors (SharePoint Server 2010). Per informazioni su come installare i connettori, vedere Installare i connettori (SharePoint Server 2010).

Pianificare la gestione dell'impatto della ricerca per indicizzazione

La ricerca per indicizzazione nel contenuto può ridurre notevolmente le prestazioni dei server che ospitano il contenuto. L'impatto su un determinato server varia in base al carico gestito dal server host e alla disponibilità di risorse del server (in particolare CPU e RAM) sufficienti a rispettare le condizioni dei contratti di servizio per un utilizzo normale o di punta.

Le regole di impatto del crawler consentono agli amministratori della ricerca di gestire l'impatto del crawler sui server sottoposti a ricerca per indicizzazione. Per ogni regola di impatto del crawler, è possibile specificare un URL singolo o utilizzare i caratteri jolly nel percorso URL per includere un blocco di URL a cui viene applicata la regola. Sarà quindi possibile indicare quante richieste simultanee di pagine vengono effettuate all'URL specificato o decidere di richiedere un solo documento per volta e attendere tra una richiesta e l'altra un numero di secondi scelto.

Le regole di impatto del crawler riducono o aumentano la velocità con cui il crawler richiede il contenuto a un determinato indirizzo iniziale o intervallo di indirizzi iniziali (detto talvolta nome di sito). Una regola si applica a tutte le regole di contenuto nell'applicazione del servizio di ricerca e le frequenze di richiesta si applicano per componente di ricerca per indicizzazione. Nella tabella riportata di seguito sono elencati i caratteri jolly che è possibile utilizzare nel nome di sito quando si aggiunge o si modifica una regola di impatto del crawler.

Carattere jolly da utilizzare	Risultato
* come nome del sito	Applica la regola a tutti i siti.
. come nome del sito	Applica la regola a siti con punti nel nome.
*.nome_sito.com come nome del sito	Applica la regola a tutti i siti del dominio nome_sito.com (ad esempio, *.adventure-works.com).
*.nome_dominio_primo_livello come nome del sito	Applica la regola a tutti i siti che terminano con un nome di dominio di primo livello specifico, ad esempio .com oppure .net.
?	Sostituisce un solo carattere in una regola. Ad esempio, *.adventure-works?.com corrisponde a tutti i siti dei domini adventure-works1.com, adventure-works2.com e così via.

È possibile creare una regola di impatto del crawler che si applichi a tutti i siti all'interno di un particolare dominio di primo livello. Ad esempio, la regola per *.com verrà applicata a tutti i siti Internet con gli indirizzi che terminano con .com. Ad esempio, un amministratore di un sito portale può aggiungere un'origine di contenuto per samples.microsoft.com. La regola per *.com si applica a questo sito, a meno che non si aggiunga una regola di impatto del crawler specificamente per samples.microsoft.com

Per il contenuto all'interno dell'organizzazione in cui gli amministratori di sistemi di ricerca eseguono la ricerca per indicizzazione, è possibile coordinarsi con tali amministratori per impostare regole di impatto del crawler in base alle prestazioni e alla capacità dei server. Per i siti più esterni, il coordinamento non è possibile. Se il contenuto richiesto nei server esterni è eccessivo oppure le richieste sono troppo frequenti, è possibile che gli amministratori di tali siti limitino gli accessi futuri se le ricerche per indicizzazione utilizzano troppe risorse. Durante la distribuzione iniziale, impostare le regole di impatto del crawler in modo da ridurre al minimo l'impatto su altri server pur continuando a sottoporre a ricerca per indicizzazione una quantità di contenuto sufficiente con la frequenza appropriata per garantire un livello di aggiornamento dell'indice adeguato secondo quanto stabilito dal contratto di servizio. Quando la farm è in fase operativa, è possibile modificare le regole di impatto del crawler in base ai dati dei registri di ricerca per indicizzazione.

Pianificare le regole di ricerca per indicizzazione

Le regole di ricerca per indicizzazione si applicano a tutte le origini di contenuto nell'applicazione del servizio di ricerca. È possibile applicare tali regole a un determinato URL o insieme di URL per effettuare le seguenti operazioni:

Evitare la ricerca per indicizzazione in contenuto non pertinente escludendo uno o più URL. In questo modo vengono inoltre ridotti l'utilizzo delle risorse del server e il traffico di rete e viene aumentato il livello di pertinenza dei risultati della ricerca.
Eseguire la ricerca per indicizzazione nei collegamenti nell'URL senza includere l'URL stesso nella ricerca per indicizzazione. Questa opzione è utile per siti con collegamenti di contenuto pertinente quando la pagina dei collegamenti non contiene informazioni pertinenti.
Consentire la ricerca per indicizzazione in URL complessi. Questa opzione consente di eseguire la ricerca per indicizzazione in URL che contengono un parametro di query specificato con un punto interrogativo (?). A seconda del sito, questi URL potrebbero includere o non includere contenuto pertinente. Gli URL complessi reindirizzano spesso a siti non pertinenti ed è pertanto consigliabile consentire la ricerca per indicizzazione in URL complessi solo nei siti in cui il contenuto reso disponibile è sicuramente pertinente.
Attivare la ricerca per indicizzazione nel contenuto dei siti di SharePoint come pagine HTTP. Questa opzione consente al sistema di eseguire la ricerca per indicizzazione nei siti di SharePoint che si trovano dietro un firewall o in scenari in cui il sito sottoposto a ricerca per indicizzazione limita l'accesso al servizio Web utilizzato dal crawler.
Specificare se utilizzare l'account di accesso predefinito al contenuto, un account di accesso al contenuto diverso o un certificato client per la ricerca per indicizzazione nell'URL specificato.

Poiché la ricerca per indicizzazione nel contenuto implica l'utilizzo di risorse e larghezza di banda, è consigliabile includere una quantità di contenuto minore ma di sicura pertinenza piuttosto che una quantità maggiore ma non pertinente. Dopo la distribuzione iniziale, è possibile riesaminare la query e i registri di ricerca per indicizzazione, nonché modificare le origini di contenuto e le regole affinché diventino più pertinenti e includano più contenuto.

Pianificare le impostazioni di ricerca gestite a livello di farm

Diverse impostazioni gestite a livello di farm determinano le modalità di ricerca per indicizzazione nel contenuto. Prendere in considerazione le impostazioni di ricerca a livello di farm seguenti durante la pianificazione della ricerca per indicizzazione:

Indirizzo di posta elettronica contatto: la ricerca per indicizzazione nel contenuto influisce sulle risorse dei server sottoposti a ricerca per indicizzazione. Prima di poter eseguire la ricerca per indicizzazione nel contenuto, è necessario specificare nelle impostazioni di configurazione l'indirizzo di posta elettronica della persona dell'organizzazione che gli amministratori possono contattare nell'eventualità che la ricerca per indicizzazione influisca negativamente sui server. Tale indirizzo di posta elettronica viene visualizzato nei registri per gli amministratori dei server sottoposti a ricerca per indicizzazione, consentendo loro di contattare qualcuno se l'impatto sulle prestazioni e sulla larghezza di banda risulta eccessivo o nel caso in cui si verifichino altri problemi.

L'indirizzo di posta elettronica del contatto deve appartenere a una persona con le competenze e la disponibilità necessarie per rispondere rapidamente alle richieste. In alternativa, è possibile utilizzare un alias della lista di distribuzione strettamente monitorato come indirizzo di posta elettronica del contatto. Indipendentemente dal fatto che il contenuto sottoposto a ricerca per indicizzazione venga memorizzato o meno all'interno dell'organizzazione, la rapidità dei tempi di risposta è un fattore essenziale.
Impostazioni server proxy: è possibile scegliere se utilizzare un server proxy durante la ricerca per indicizzazione nel contenuto. Il server viene scelto in base alla topologia della distribuzione di SharePoint Server 2010 e all'architettura degli altri server dell'organizzazione. Probabilmente sarà necessario utilizzare un server proxy durante la ricerca per indicizzazione nel contenuto Internet. Per ulteriori informazioni su come configurare le impostazioni di tale server per la ricerca, vedere Configure farm-level proxy server settings (SharePoint Server 2010) e Configure proxy server settings for search (SharePoint Server 2010).
Impostazioni timeout: le impostazioni di timeout vengono utilizzate per limitare il tempo di attesa del sistema di ricerca durante la connessione ad altri servizi.
Impostazione SSL: l'impostazione SSL (Secure Sockets Layer) determina se il certificato SSL deve corrispondere esattamente per eseguire la ricerca per indicizzazione nel contenuto.

Pianificare la federazione

Una ricerca federata prevede l'esecuzione simultanea di una query in più database o risorse Web con lo scopo di visualizzare una singola pagina dei risultati di ricerca per gli utenti finali. Quando si aggiunge una posizione federata, gli utenti finali possono cercare e recuperare il contenuto che non è stato sottoposto a ricerca per indicizzazione dai server nel sistema locale. Le posizioni federate consentono di inviare query a motori di ricerca remoti e feed, quindi il sistema formatta e fornisce i risultati agli utenti finali come se il contenuto federato facesse parte del contenuto sottoposto a ricerca per indicizzazione.

SharePoint Server 2010 supporta i tipi di posizioni federate seguenti:

Indice di ricerca su questo server. È possibile utilizzare come posizione federata qualsiasi sito locale o remoto dell'organizzazione che disponga di un server che esegue SharePoint Server 2010. Si supponga ad esempio che un sito di SharePoint in un server delle risorse umane dell'azienda sia l'unica origine disponibile per le informazioni sui contatti dei dipendenti. Anche se il sito non fa parte dell'ambito di ricerca per indicizzazione, è possibile configurare una posizione federata per il sito, in modo che gli utenti che avviano una ricerca dal sito Centro ricerche possano recuperare i risultati relativi alle informazioni sui contatti dei dipendenti che sono autorizzati a visualizzare. Si applicano le condizioni seguenti:
1. La posizione è impostata su Indice di ricerca su questo server.
2. Non è necessario alcun modello di query. SharePoint Server 2010 utilizza il modello a oggetti per inviare una query relativa a una posizione.
3. Viene utilizzata l'autenticazione server predefinita.
4. Le query di ricerca avanzata non sono supportate.
OpenSearch 1.0 o 1.1. È possibile utilizzare come posizione federata qualsiasi sito Web pubblico che supporti lo standard OpenSearch. Un esempio di una posizione di questo tipo è rappresentato da un motore di ricerca Internet quale Bing o da una pagina dei risultati di ricerca che supporta i protocolli RSS o Atom. Si supponga ad esempio di voler fare in modo che gli utenti che cercano nei siti interni informazioni tecniche di proprietà possano visualizzare anche informazioni correlate di siti Web pubblici. Se si configura una posizione federata per una query di ricerca Bing, verranno inclusi automaticamente per gli utenti i risultati della ricerca Web. Si applicano le condizioni seguenti:
1. Le query possono essere inviate a un motore di ricerca come URL, ad esempio http://www.example.com/search.aspx?q=TEST.
2. I risultati di ricerca vengono restituiti in formato RSS, Atom o in un altro formato XML strutturato.
3. Le funzionalità, i modelli di query e gli elementi di risposta relativi alla posizione fanno parte di un file di descrizione OpenSearch (con estensione osdx) associato alla posizione.
4. Le estensioni di OpenSearch specifiche di SharePoint Server 2010 supportano la possibilità di includere trigger e di associare codice XSL ai risultati di ricerca.
5. La scelta dei metadati da visualizzare nei risultati di ricerca è determinata dalla posizione OpenSearch.
Per ulteriori informazioni su OpenSearch, visitare il sito Web all'indirizzo https://www.opensearch.org/home.

Una query di ricerca viene inviata a una posizione federata sotto forma di parametri URL in un formato denominato modello di query. Il sistema quindi formatta e visualizza i risultati nel formato XML per gli utenti del sito Centro ricerche. Il formato XML viene visualizzato come testo leggibile in una web part della pagina dei risultati della ricerca. È possibile aggiungere e configurare le web part nella pagina dei risultati di ricerca come web part Risultati di ricerca federati, come web part Risultati federati principali o come web part Risultati di ricerca. Per impostazione predefinita, la pagina dei risultati di ricerca contiene tre web part Risultati di ricerca federati.

Prima di decidere se visualizzare o meno agli utenti i risultati di ricerca federati, considerare le domande seguenti:

Si desidera visualizzare risultati personalizzati per ricerche specifiche? Per garantire che la posizione federata restituisca risultati che soddisfano query specifiche, è possibile utilizzare le regole di trigger. Quando si crea una regola di trigger per una posizione federata, la web part associata alla posizione visualizza solo i risultati delle query utente corrispondenti al modello o al prefisso specificato.
È possibile utilizzare un URL per specificare quali risultati devono essere recuperati per una query Per creare una posizione federata, si deve specificare un modello di query, nel quale vengono combinati l'URL e i parametri necessari per inviare una query di ricerca e restituire i risultati in formato XML. Quando si aggiungono queste informazioni nel campo Modello query della pagina Aggiungi posizione federata, è necessario formattare correttamente la stringa (come illustrato nell'esempio nella pagina), altrimenti il provider dei risultati di ricerca non restituirà alcun risultato.
Gli utenti possono accedere ai collegamenti forniti dalla posizione federata? Se l'organizzazione concede solo un accesso limitato alle risorse Internet, l'utilizzo di un motore di ricerca in Internet come posizione federata potrebbe essere frustrante per gli utenti poiché sarebbero in grado di visualizzare solo alcuni dei risultati di ricerca.
L'autenticazione è obbligatoria? Se per la posizione federata è obbligatoria l'autenticazione, è necessario fornire le credenziali corrette. Molte posizioni federate, quali i motori di ricerca Internet, non richiedono credenziali.

Pianificare i tipi di autenticazione per la federazione

Per la ricerca federata sono disponibili diversi tipi di credenziali per l'autenticazione degli utenti, l'autenticazione per utente e l'autenticazione comune. Tenere tuttavia presente che per la raccolta delle credenziali è necessaria un'estensione della web part per i tipi di autenticazione non Kerberos nell'autenticazione per utente. Nella sezione relativa alle informazioni sull'autenticazione e le credenziali della definizione della posizione è necessario specificare il tipo di autenticazione per la posizione federata. L'autenticazione può essere di uno dei tipi seguenti:

Anonima

Non sono necessarie credenziali per connettersi alla posizione federata.
Comune

Ogni connessione utilizza lo stesso set di credenziali per connettersi alla posizione federata.
Per utente

Le credenziali dell'utente che ha inviato la query di ricerca vengono utilizzate per connettersi alla posizione federata.

Per i tipi di autenticazione comune e per utente, è inoltre necessario specificare uno dei protocolli di autenticazione seguenti:

Di base

L'autenticazione di base fa parte della specifica HTTP ed è supportata dalla maggior parte dei browser.

Security Note
I Web browser che utilizzano l'autenticazione di base trasmettono password non crittografate. Mediante il monitoraggio delle comunicazioni sulla rete, un utente malintenzionato può servirsi degli strumenti disponibili pubblicamente per intercettare e decodificare tali password. Non è pertanto consigliabile avvalersi dell'autenticazione di base, a meno che non si sia certi che la connessione sia sicura, come ad esempio nel caso di una linea dedicata o di una connessione SSL (Secure Sockets Layer).

I Web browser che utilizzano l'autenticazione di base trasmettono password non crittografate. Mediante il monitoraggio delle comunicazioni sulla rete, un utente malintenzionato può servirsi degli strumenti disponibili pubblicamente per intercettare e decodificare tali password. Non è pertanto consigliabile avvalersi dell'autenticazione di base, a meno che non si sia certi che la connessione sia sicura, come ad esempio nel caso di una linea dedicata o di una connessione SSL (Secure Sockets Layer).

Del digest

L'autenticazione del digest è basata sul protocollo HTTP 1.1 come definito nella specifica RFC 2617 disponibile sul sito Web del World Wide Web Consortium (W3C). Poiché tale autenticazione richiede la conformità a HTTP 1.1, non è supportata da alcuni browser. Se un browser non conforme a HTTP 1.1 richiede un file quando l'autenticazione del digest è attivata, la richiesta verrà rifiutata perché tale autenticazione non è supportata dal client. L'autenticazione del digest può essere utilizzata solo nei domini di Windows, funziona esclusivamente con account di dominio di Windows Server 2008, Windows Server 2003 e Microsoft Windows 2000 Server e può richiedere che gli account archivino le password come testo normale crittografato.
NTLM

I record utente vengono archiviati nel database SAM (Security Accounts Manager) o nel database di Active Directory. Ogni account utente è associato a due password, ovvero una compatibile con LAN Manager e una di Windows. Ogni password è crittografata e archiviata nel database SAM o nel database di Active Directory.
Kerberos (solo per il tipo di autenticazione per utente)

Utilizzando il protocollo Kerberos, una parte a un'estremità di una connessione di rete può verificare che la parte all'altra estremità sia l'entità che attesta di essere. Benché NTLM consenta ai server di verificare le identità dei relativi client, non consente ai client di verificare l'identità di un server né consente a un server di verificare l'identità di un altro server. L'autenticazione NTLM è pertanto adatta per un ambiente di rete in cui si presuppone che i server siano attendibili.
Basata su moduli

Un cookie di autenticazione basata su moduli non è altro che il contenitore di un ticket di autenticazione. Ogni richiesta passa il ticket come valore del cookie e il ticket viene utilizzato nel server per identificare un utente autenticato. L'autenticazione basata su moduli senza cookie tuttavia passa il ticket nell'URL in formato crittografato e viene utilizzata perché i browser client potrebbero bloccare i cookie. Tale funzionalità è stata introdotta in Microsoft .NET Framework 2.0.

Se nel proprio ambiente si utilizza l'autenticazione basata sulle attestazioni, assicurarsi che l'autenticazione di Windows sia inoltre attivata per qualsiasi origine di contenuto in cui eseguire la ricerca per indicizzazione. Per ulteriori informazioni sui metodi di autenticazione in SharePoint Server 2010, vedere Pianificare i metodi di autenticazione (SharePoint Server 2010).