none
Come modificare una origine di contenuto per utilizzare STS3S invece che STS3.

    Question

  •  Da un sacco di tempo avevo una serie di registrazioni relative all'ID Event 2424 e 2436 oltre a molti altri problemi di indicizzazione sul server SharePoint 2007 ma, dato che il server funzionava lo stesso, e non avevo tempo non ci ho mai dato troppo peso.

     Ora mi sono messo dietro a cercare di capire l'origine del problema e dovrei averlo individuato ma non riesco a risolvere.

     Il messaggio di errore relativo all'evento 2436 è il seguente:

     Impossibile eseguire la ricerca per indicizzazione dell'indirizzo iniziale <sts3://portalesharepoint.dominio.it/contentdbid={d66e6a5a-c74d-4047-909f-50663b0075dc}>.
    Contesto: applicazione 'File dell'indice della ricerca nel server di ricerca', catalogo 'Search'
    Dettagli:
        Risposta HTTP non riconosciuta durante il tentativo di eseguire la ricerca per indicizzazione su questo elemento. Verificare che sia possibile accedere all'elemento utilizzando il browser.   (0x80041204)

     Diversamente da quanto si trova cercando in rete il messaggio è giusto nel senso che, se ho capito bene, io non ho un'origine STS3 che possa essere indicizzata in quanto il sito sharepoint risponde solo in https e le eventuali chiamate http sono reindirizzate al protocollo https. Il servizio di ricerca dovrebbe al limite tentare l'indicizzazione utilizzando semmai l'indirizzo iniziale sts3s :// portalesharepoint.dominio.it /contentdbid={d66e6a5a-c74d-4047-909f-50663b0075dc} ma non ho trovato dove modificare queste impostazioni.

     

     Come posso capire a cosa corrisponde esattamente quel GUID?

     Perchè mi viene registrato l'errore solo su quello specifico GUID e non su tutto il sito?

     Da dove si possono modificare le impostazioni del servizio ricerca relative a quel protocollo?

    Monday, February 21, 2011 2:21 PM

Answers

  • Effettivamente ci metto del mio... :D

    Ricapitolando:

    Sul server sharepoint ci sono in funzione il portale predefinito creato dall'installazione (inutilizzato), due applicazioni di produzione e un'altra applicazione che accoglie i siti personali.

     Uno di questi portali, il principale, deve rispondere esclusivamente in https ed è stata creata l'applicazione web assegnandogli originariamente un AAM uguale al binding https su cui avrebbe dovuto rispondere il sito. Peccato che lo stesso URL fosse stato assegnato anche al binding http del portale creato dall'installazione, generando quindi un pò di confusione.

     Non contenti, per inesperienza principalmente, invece che rimuovere semplicemente il portale creato dall'installazione ed aggiustare gli AAM è stato creato in IIS un redirect permanente dall'URL associato al binding http allo stesso URL https. Praticamente agli URL http:// portalesharepoint.dominio.it ed https :// portalesharepoint.dominio.it corrispondevano due applicazioni diverse e per evitare che gli utenti finissero erroneamente sul portale http invece che eliminarlo, aggiustare gli AAM e creare un semplice sito IIS di redirect è stato usato il sito associato al portale sharepoint inutilizzato per creare il redirect permanente che rimandava dal portale http al portale https.

    Questa è l'ìdea che mi sono fatto:

     Questo redirect, rendeva di fatto l'applicazione http:// portalesharepoint.dominio.it inaccessibile via browser (generando l'errore 2436). L'errore 2424 (che inizialmente aveva un messaggio diverso) è dovuto al fatto che il protocollo sts3 tentando di indicizzare il portale http:// portalesharepoint.dominio.it riceveva in realtà risposta dal portale https :// portalesharepoint.dominio.it ottenendo ovviamente una risposta http non valida. Disabilitando il redirect, formalmente si è sistemato tutto e gli errori sono scomparsi.

     

     

     Tralasciando il resto, che sono principalmente elucubrazioni, il sunto è che gli errori sono stati provocati da un uso improprio degli AAM e da un redirect creato in IIS tra i siti associati a due applicazioni distinte registrate in sharepoint con due diversi AAM a cui corrisponde però lo stesso host header, generando i problemi di accesso ed indicizzazione da parte del motore di ricerca di sharepoint.

     Quello che ti chiedo ora di confermarmi, è se esistono motivi per cui è meglio non eliminare il portale creato in fase di installazione dall'installer di sharepoint se non è utilizzato oppure se posso andare tranquillo. Come avrai capito, non ho molta esperienza e non vorrei che eliminando quell'applicazione saltasse qualche improbabile concatenamento.

    Tuesday, March 01, 2011 12:21 AM

All replies

  • Credo questo post ti possa aiutare: http://blogs.msdn.com/b/joelo/archive/2007/06/14/i-m-indexing-and-i-only-get-errors.aspx
    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Monday, February 21, 2011 9:35 PM
  •  I sintomi sono simili e così ad occhio sembra il mio caso ma non riesco a capire quindi come risolvere.

     

     La mia situazione è questa:

     Ho installato il server sharepoint 2007 std su una singola macchina, poi ho creato dalla Central Administration tre nuove applicazioni (in aggiunta a quella di default, che non è utilizzata): Due sono portali ed una è la raccolta dei siti personali.

     Il portale principale (portalesharepoint.dominio.it ) deve essere raggiungibile solo via https quindi ho impostato sul sito relativo un bindings http (senza host header ma non dovrebbe essere un problema) sulla porta 8001, un binding https sulla 443 e da IIS Manager impostato "Require SSL" per impedire l'accesso dalla porta 8001.

     Per far si che gli utenti che hanno l'abitudine di scrivere solo portalesharepoint.dominio.it nella barra del browser vengano rediretti al corretto sito https ho poi creato un redirect permanente dal portare creato di default dall'installazione di sharepoint (che possiede due bindings http "portalesharepoint.dominio.it " e "servername " entrambi sulla porta 80) al mio portale https. Mi risulta che questo giochino sia l'unico modo per fare una cosa del genere, sbaglio?

     Il servizio ricerca quindi, va a tentare una connessione tramite protocollo sts3 all'host portalesharepoint.dominio.it e non riesce a raggiungerlo, probabilmente a causa del redirect, considerando che gli AAM dovrebbero essere a posto.

     L'unica soluzione è quindi togliere le estensioni sharepoint dal portale di default utilizzato solo per il redirect, corretto? In modo che venga escluso il sito con binding http e host header portalesharepoint.dominio.it dalla ricerca di sharepoint...

     

    Tuesday, February 22, 2011 3:22 PM
  • Fai quanto descritto qui: http://support.microsoft.com/kb/896861 come è spiegato all'interno dell'articolo che ti ho girato.


    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Wednesday, February 23, 2011 7:37 AM
  • Ok, ero convinto di averlo già fatto ma mi ero perso la parte di "DisableStrictNameChecking " e avevo applicato solo la parte "BackConnectionHostNames ".

     Stanotte riavvio il server e domani ti faccio sapere. Grazie dell'aiuto!!

    Wednesday, February 23, 2011 9:41 AM
  • Niente da fare, nesun cambiamento. Sempre i medesimi errori ogni 5 minuti.

     Se tolgo le esensioni sharepoint al portale predefinito creato dall'installazione (sempre al fine di escludere il sito con quell'host header dall'indicizzazione) e non elimino il sito sharepoint se ne ha a male??

    Thursday, February 24, 2011 1:20 PM
  • Hai provato a disabilitare il loopback anche ? Trovi le istruzioni sempre qui: http://support.microsoft.com/kb/896861


    Giuseppe Marchi - SharePoint MVP
    www.peppedotnet.it
    www.dev4side.com
    www.sharepointcommunity.it
    Twitter: @PeppeDotNet
    Thursday, February 24, 2011 6:44 PM
    Moderator
  •  Sì, sì. Fatto tutto. Mi mancava solo la key relativa al DisableStrictNameChecking , il resto lo avevo fatto.

     Ma non credo sia un problema di risoluzione... Provo a disabilitare il redirect fino a domattina, vediamo se stanotte ci sono ancora registrazioni di errore.

     

     EDIT:

     Sono un pollo!!! I problemi sono quasi sicuramente due, uno dipendente dal redirect e l'altro da un AAM sbagliato.

     Ho rimosso il redirect ed effettivamente gli errori 2424 e 2436 nel registro eventi sono scomparsi entrambi. Venivano registrati puntualmente ogni 5 minuti mentre disabilitando il redirect per circa 20 minuti non ne ha registrato nessuno perchè, gustamente, l'applicazione sharepoint adesso è accessibile. Allora ho provato a rimuovere dal sito IIS creato dall'installazione di sharepoint tutti gli host header per i bindings http, lasciandolo solo il sito attivo sulla porta 80 (avrei anche potuto arrestarlo forse) ed ho poi creato un altro sito solo IIS (quindi senza estensioni sharepoint) sempre sulla porta 80 ma con gli host header dell'applicazione sharepoint, applicando il redirect a quest'ultimo sito.

     Dopo i canonici 5 minuti, nel registro eventi è comparso di nuovo l'errore 2424 ma questa volta solo quello: il problema di indicicizzazione relativo all'errore 2436 è quindi scomparso perchè l'applicazione sharepoint, seppure non bindata ad un host header, ancora risponde sull'indirizzo IP del server cui corrisponde la risoluzione dell'AAM assegnato all'applicazione ed è quindi raggiungibile ed indicizzabile.

     L'errore 2424 riporta ora il seguente errore:

    Log Name:      Application
    Source:        Windows SharePoint Services 3 Search
    Date:          25/02/2011 0.30.01
    Event ID:      2424
    Task Category: (3)
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      servers-sharepoint.dominio.priv
    Description:
    Impossibile avviare l'aggiornamento. Le origini di contenuto non sono accessibili. Correggere gli errori e riprovare a eseguire l'aggiornamento.

     

    Questo è ovviamente dovuto al fatto che il sito a cui risponde l'host header (e l'AAM!!) portalesharepoint.dominio.it cui faceva riferimento l'errore 2436 iniziale non è ora realmente un sito sharepoint ma non normale sito IIS senza contenuti cui accedere. E' stato quindi fatto anche un errore in fase di installazione del server, assegnado un AAM sbagliato a questa applicazione inutilizzata.

     In teoria, eliminando il portale inutilizzato oppure cambiando completamente gli AAM assegnati a questo portale dovrebbe sparire anche quest'ultimo errore.

     C'è un motivo ufficiale/ufficioso per non rimuovere il portale creato di default dall'installazione di sharepoint?? E' un sito che non mi serve...

     

     Verificando bene gli AAM anche delle altre applicazioni a questo punto dovrei poter ripristinare senza errori anche il loopback e lo strictname, vero?

    Thursday, February 24, 2011 11:58 PM
  • E' molto difficile seguirti! Puoi ricapitolare quanto hai fatto?


    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Monday, February 28, 2011 10:35 PM
  • Effettivamente ci metto del mio... :D

    Ricapitolando:

    Sul server sharepoint ci sono in funzione il portale predefinito creato dall'installazione (inutilizzato), due applicazioni di produzione e un'altra applicazione che accoglie i siti personali.

     Uno di questi portali, il principale, deve rispondere esclusivamente in https ed è stata creata l'applicazione web assegnandogli originariamente un AAM uguale al binding https su cui avrebbe dovuto rispondere il sito. Peccato che lo stesso URL fosse stato assegnato anche al binding http del portale creato dall'installazione, generando quindi un pò di confusione.

     Non contenti, per inesperienza principalmente, invece che rimuovere semplicemente il portale creato dall'installazione ed aggiustare gli AAM è stato creato in IIS un redirect permanente dall'URL associato al binding http allo stesso URL https. Praticamente agli URL http:// portalesharepoint.dominio.it ed https :// portalesharepoint.dominio.it corrispondevano due applicazioni diverse e per evitare che gli utenti finissero erroneamente sul portale http invece che eliminarlo, aggiustare gli AAM e creare un semplice sito IIS di redirect è stato usato il sito associato al portale sharepoint inutilizzato per creare il redirect permanente che rimandava dal portale http al portale https.

    Questa è l'ìdea che mi sono fatto:

     Questo redirect, rendeva di fatto l'applicazione http:// portalesharepoint.dominio.it inaccessibile via browser (generando l'errore 2436). L'errore 2424 (che inizialmente aveva un messaggio diverso) è dovuto al fatto che il protocollo sts3 tentando di indicizzare il portale http:// portalesharepoint.dominio.it riceveva in realtà risposta dal portale https :// portalesharepoint.dominio.it ottenendo ovviamente una risposta http non valida. Disabilitando il redirect, formalmente si è sistemato tutto e gli errori sono scomparsi.

     

     

     Tralasciando il resto, che sono principalmente elucubrazioni, il sunto è che gli errori sono stati provocati da un uso improprio degli AAM e da un redirect creato in IIS tra i siti associati a due applicazioni distinte registrate in sharepoint con due diversi AAM a cui corrisponde però lo stesso host header, generando i problemi di accesso ed indicizzazione da parte del motore di ricerca di sharepoint.

     Quello che ti chiedo ora di confermarmi, è se esistono motivi per cui è meglio non eliminare il portale creato in fase di installazione dall'installer di sharepoint se non è utilizzato oppure se posso andare tranquillo. Come avrai capito, non ho molta esperienza e non vorrei che eliminando quell'applicazione saltasse qualche improbabile concatenamento.

    Tuesday, March 01, 2011 12:21 AM
  • Ciao Matteo,

    puoi tranquillamente eliminare o semplicemente *stoppare* il sito creato di default. 


    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Tuesday, March 01, 2011 12:34 AM
  • Arrestare semplicemente il sito non funziona, nel senso che nel registro eventi rimane l'errore di origine inaccessibile.

    Grazie del supporto!

    Tuesday, March 01, 2011 8:09 AM
  • Si beh ... ovviamente devi eliminare il binding!!
    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Tuesday, March 01, 2011 3:02 PM
  • Confermo, risolto.

     Grazie dell'aiuto!!!

    Wednesday, March 02, 2011 5:39 PM