Ricorderete che su WSS/SPS 2003 era necessario indicare, attraverso la Central Administration, se un certo elemento (es. un virtual directory IIS) estraneo a SharePoint era da escludere dai percorsi gestiti da WSS.

Se ad esempio il sito web di WSS era http://miosito e, operando attraverso IIS, si aggiungeva una virtual directory o una semplice directory sul file system del front-end corrispondente a http://miosito/dir, e all’interno della directory si collonacavo pagine o applicazioni web estranee a SharePoint… il comportamento dell’ISAPI Filter di WSS era quello di considerare il “/dir” come un pezzo di SharePoint, ricercandolo così all’interno del DB dei contenuti, con il risultato di non trovarlo e restituire l’errore 404, Page not found.

Era quindi necessario specificare, attraverso la Central Administration di SharePoint, che “/dir” è un percorso escluso (attraverso i Managed Path). Ed in questo modo SharePoint evitava di intercettare/elaborare le richieste dei contenuti “/dir”, lasciando che si occupasse di essi il buon IIS.

Oggi su WSS 3.0 (ma anche su MOSS 2007) non esiste più la possibilità di definire dei percorsi esclusi. E’ possibile definire, attraverso i nuovi Managed Path, due tipologie di inclusioni (explicit e wildchar), ma nessuna exclusion.

Come fare quindi a evitare che WSS interpreti per proprio un percorso che non c’entra nulla con SharePoint (come ad esempio una qualsiasi applicazione web che si vuole ospitare sullo stesso server)?
Semplice. Basta creare, lato IIS, la directory (vituale o meno), e non fare altro. SharePoint 2007 non si comporta più come la versione 2003, e non sottintende più ogni elemento come un proprio contenuto. Del resto non c’è più il vecchio ISAPI Filter, colpevole del precedente comportamento 🙂