Windows Vista è ormai uscito da più di un anno; la curiosità insita nei programmatori avrà quasi certamente preso il sopravvento e, molto probabilmente, avrete installato Windows Vista.

Se non la avete fatto, peggio per voi ... e potete pure tralasciare la lettura di questo post perchè non vi serve assolutamente a niente.

Se invece avete installato Vista vi ritrovate con IIS aggiornato alla versione 7, che devo dire è veramente un gran bel gioiellino.

Non mi dilungo molto sui cambiamenti del nuovo web server Microsoft, sarebbero fuorvianti. Mi limito invece a quelle che sono le caratteristiche che ruotano attorno a quanto sto per scrivere. gli HttpHandler.

Un HttpHandler è del codice che - in base all'estenzione del file richiesto - si preoccupa di catturare la richiesta dalla coda di gestione ed eseguire / parsare il file secondo quanto l'handler è stato programmato, quindi restituirne l'output verso il context richiedente.

E' necessaria una premessa, che già il titolo dovrebbe portare all'attenzione dei programmatori più attenti. Mi riferisco alla modalità di esecuzione del worker process - ClassicMode - sopra menzionato.

Con l'introduzione di IIS 7, infatti, il nuovo server web ha subito dei profondi cambiamenti architetturali che in sintesi oggi ci offrono due modalità di esecuzione per l'Application Pool: il ClassicMode e l'Integrated Mode.

Fintanto che Windows 2008 non sarà ufficialmente commercializzato e adottato dagli hosting provider o installato sulla nostra macchina di produzione, purtroppo per noi il server web disponibile è ancora IIS6, che prevede solo la modalità ClassicMode.

Ne consegue che, allorquando decidiamo di sviluppare un nostro HttpHandler, e ovviamente lo testiamo con IIS 7, laddove avessimo la necessità di verificare che effettivamente il componente appena creato possa correttamente funzionare anche su IIS 6, prima di passarlo in produzione, dobbiamo testarlo nella modalità sopracitata.

Come fare?

Se abbiamo testato il componente su un sito web che girava in un Integrated Application Pool, dobbiamo per prima cosa dire al nostro sito di usare un Application Pool configurato con il ClassicMode.

Ovviamente non è tutto qui, magari.

Nella stragrande maggioranza dei casi, dato che con l'handler sarete andati a gestire una particolare vostra estenzione (ma questo succede anche se avete utilizzato una estenzione nota), mentre con IIS 7 è sufficiente mappare l'estenzione verso il vostro handler, con IIS 6 dovrete prima mappare l'estenzione sulla quale state lavorando affinchè passi per l'aspnet_isapi.dll (diversamente sarà IIS a prendersi in carico la richiesta e non sapendoci che fare con la vostra etenzione non mappata probabilmente vi restituirà una 404).

Sarà poi compito di Asp.Net fare il check dei vari handler installati e dirottare internamente la richiesta verso l'handler più appropriato.

E infine apportare una modifica al nostro file web.config per dire che quella determinata estenzione dovrà essere gestita dal nostro Handler (che dovrà, per IIS6 essere necessariamente un file compilato e messo nella Bin del nostro sito).

Con IIS 7, tutto questo non è necessario, l'Handler può essere direttamente una classe messa nella nostra App_Code e compilata al volo, che con una semplice mappatura che a questo punto cambierà di posizione (non più quindi in , ma in dove si specificherà a questo punto anche il path al quale il nostro handler deve rispondere) e tanto sarà sufficiente affinchè l'evento HttpApplication.MapRequestHandler possa dirottare la richiesta verso il nostro handler.

Approfondimenti

Per futura memoria di chi legge, ma anche per lo scrivente, lascio alcuni link utili sugli handler e sul life cycle di IIS 6 e 7:

1. ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0
2. ASP.NET Application Life Cycle Overview for IIS 7.0
3. Introduction to HTTP Handlers

Se vi trovate invece in panne con la migrazione di un Handler da IIS6 a ISS7, nel blog di Rick Strahl ci sono un paio di post interessanti:

1. Migrating an ASP.NET app to IIS 7
2. HttpModule and HttpHandler sections in IIS 7 web.config files

Dopo un precedente articolo sull'errore 404 lato SEO, oggi parlo dell'errore 404 lato ASP.Net e IIS. Il perchè bisogna configurarlo l'ho spiegato nell'articolo sopra citato, come configurarlo nell'ambiente Microsoft lo faccio ora.

Esistono due modi, complementari, per configurare l'errore 404 in ASP.Net /IIS6. Complementari perchè uno non esclude l'altro.

Data l'architettura del framweork, una volta che la richiesta giunge al server, questa a seconda dell'estenzione che il file richiesto ha, può subire un dirottamente all'interno della pipeline.

I file statici, quindi i file .htm e .html (ma anche i .css e tutte le immagin) verranno smistati automaticamente verso l'handler che si preoccupa di gestire i file statici (StaticFileModule), mentre i file con estenzione .aspx verranno gestiti dall'handler aspnet_isapi.

Dati questi due percorsi differenti, ne consegue che qualora venga inoltrata una richiesta per una risorsa non esistente sul server di destinazione, la risposta 404 procederà per due vie completamente distinte.

Quella dei file statici verrà inoltrata direttamente ad IIS, il quale ritornerà al client la pagina associata al codice di errore 404 configurata all'interno della proprietà del sito.

Di default viene restituita una pagina brutta e asettica come quella che si vede qui sotto, ma agendo nelle proprietà di configurazione del sito si può impostare un qualsiasi tipo di risorsa, anche appartenente ad un altro sito web.

Nel caso di una risorsa .aspx non trovata, le cose sono leggermente diverse.

A preoccuparsi di restituire una pagina d'errore è lo stesso framwork.

Ovviamente, di default, la gestione delle pagine non trovate non è abilitata, e nel caso viene mostrata una pagina d'errore (per alcuni) più criptica e sempre antiestetica.

Per poter abilitare la gestione delle pagine non trovate, in questo caso bisogna agire all'interno del file Web.Config, andando a creare, laddove non esista già, una sezione CustomErrors.

Un esempio può essere come quello qui sotto:

<customErrors mode="On">
    <errorstatusCode="404" redirect="404.html" />
customErrors>

In questo caso, il framework reindirizzerà la richiesta verso il file statico 404.html. Nulla vieta di mettere una pagina con estenzione .aspx che faccia del lavoro per noi, tipo mandare une e-mail all'amministratore del sito, piuttosto che registrare degli eventi in un file di log, ecc.

Medesimo discorso vale anche per la configurazione del Custom Error statico. Impostando una risorsa di tipo URL si può specificare un percorso assoluto e rimandare il tutto ad una pagina dinamica, con il vantaggio che si potrà creare una sola pagina e gestire in entrambe i casi il problema della risorsa non trovata.

La prima risposta di getto che probabilmente viene da dare è "Che ci vuole? Crei una nuova cartella e sposti il file li dentro o rinomini il file!".

Vero! Ma proviamo ad analizzare la cosa da un punto di vista dei motori di ricerca. Questi enormi indici, per quanto quotidianamente scandagliano milioni di siti web, continueranno a non conoscere le vostre modifiche fintanto che non ripasseranno sul vostro sito per reindicizzarne il contenuto.

Supponete ora che avete un sito web scarsamente aggiornato, e che questa scansione avvenga una volta al mese, e proprio ieri i motori di ricerca sono passati per il loro "giro". Cosa succederebbe per un mese? Che n visite che arrivano al vostro sito da quel link contenuto nella pagina del motore di ricerca andrebbero perse perchè la pagina richiesta non esiste più (Errore 404 Pagina non trovata).

Se avete implementato un sistema per restituire una pagina di errore amichevole, poco male. Il vostro utente capirà "nel bene o nel male" che il contenuto non esiste più. Ma Google o gli altri motori di ricerca? A seconda del codice di errore restituito (200 o 404, per maggiori informazioni leggete qui) i motori di ricerca potrebbero non accorgersi immediatamente (o magari non farlo per niente) di quello che è successo.

La cosa migliore a questo punto è quella di impostare una politica corretta di redirect fatta lato server, in modo da restituire un codice stato corretto ed informare il motore di ricerca del cambiamenteo attraverso il codice 301 - Pagina trasferita definitivamente.

In ambiente Microsoft, sotto IIS6, questo cambiamento è possibile effettuarlo nel seguente modo:

1. Aprire la console IIS, e quindi il sito web di interesse
2. Selezionare la risorsa (file o cartella) quindi fare tasto destro e proprietà
3. Nella sezione file, selezionare l'opzione su "A rederiction to a URL"
4. Marcare la casella "A permanent redirection on this resource"
5. Premere ok per uscire

Il punto 4 è fondamentale e fa la differenza nella restituzione del codice di errore tra il 301 (Moved permanently, accettato di buon grado dai motori di ricerca) e il 302 (Documento trovato, ma semplicemente mosso temporaneamente).

Il codice 301 viene visto dal motore di ricerca come un cambiamento, e di conseguenza senza altre variazioni da parte nostra, possiamo aspettarci che nel breve periodo il motore prima o poi aggiorni l'indice in automatico.

Ovviamente, per chi sta facendo attività di SEOing, è bene aggiornare la sitemap.xml (e sottometterla di nuovo nel caso di Google tramite i webmaster tools) e magari anche il robots.txt assicurandosi tempi più brevi e minori problemi.

Analogo discorso si potrebbe fare per lo spostamento dei domini, ma in questo caso ho avuto modo di notare e comunque di leggere anche di esperienze di "latenza" a livelli paurosi.

Internet Information Services (IIS) non è solo una piattaforma per ospitare siti web, è in alcuni casi anche un component essenziale per diversi altri prodotti Microsoft come Content Management Server, Exchange Server ecc. I processi di sviluppo che hanno investito questa piattaforma sin dalla sua versione 1.0 all’attuale 6.0 di Windows 2003 Server sono molteplici.
In particolare nell’ultima versione, considerate tutte le critiche mosse contro Microsoft circa sicurezza e stabilità del sistema, il team di sviluppo di IIS si è adoperato profondamente al fine di riscrivere completamente un nuovo server web che sopperisse le critiche mosse.

Un po’ di storia prima di proseguire

Fino ad IIS3 tutti i siti web hostati, compreso la stessa piattaforma giravano su di un unico processo chiamato inetinfo.exe.

Con IIS4 si è iniziato a pensare per la prima volta ad un modello che slegasse completamente la piattaforma dai servizi web. Risultato un processo di nome inetinfo.exe che gestiva il WWW e tanti siti web che potevano girare “tranquillamente” sotto la stessa macchina, con il vantaggio di poter essere avviati e fermati a piacimento senza per questo impattare le altre applicazioni. Svantaggio, nessun sito web poteva interagire con gli altri, e in fase di debug, tutto veniva spostato sotto il processo principale e quando il primo bug veniva alla luce, se questo mandava in crisi il processo, bisognava procedere nuovamente al riavvio del servizio (e tutti gli altri siti ignobilmente venivano spenti e riaccesi facendo perdere le sessioni di lavoro).

IIS5, avvento di ASP.net 1.0 e nuovo approccio alla programmazione dinamica (a memoria ricordo fosse il tardo 2000, primi del 2001). Piccole modifiche al server web e al suo modo di gestione ora denominato “pooled process” che consentiva di far girare diverse applicazioni in un processo separato chiamato dllhost.exe, realmente separatp dal core della piattaforma. Vantaggio indiscusso di poter riavviare, fermare, debuggare applicazioni in maniera totalmente indipendente, di poter assegnare all’applicazione un profilo di isolamento del processo (a scelta tra basso, medio e alto), cioè assegnare l’area di memoria condivisa dove poter lavorare. Questo il vero svantaggio, perché comunque, bene o male, tutte le applicazioni lavorano sotto un unico processo.

IIS 6.0 e ora ASP.net 2.0 / 3.0. Riscrittura totale del server web, un solo livello di isolamento del processo ora denominato “application pool”. Un processo che può essere creato ex-novo e per un numero “infinito” di applicazioni che possono ora girare in uno spazio realmente distinto o condiviso a seconda delle impostazioni date via console.

Perché la storia era necessaria

Non sono un fanatico dei libri, ma era necessario evidenziare i cambiamenti che ci sono stati nel passaggio tra IIS5 e IIS6 per affrontare il problema. Ma diamo un’occhiata alle immagini prima di proseguire oltre.

La prima immagine mostra un task manager di IIS5, 3 processi aspnet_wp.exe, uno per ogni istanza del frame work caricata.

Con IIS5 se il processo con la versione del framework richiesta non era attiva, veniva semplicemente caricata. Un piccolo stratagemma implementato da MS per permettere di far coesistere diverse versioni di framework senza troppe preoccupazioni per lo sviluppatore che per l’amministratore di sistema.

Con IIS6, invece, la storia è cambiata. Notate l’assenza di aspnet_wp.exe, e invece un prolificarsi di processi denominati w3wp.exe. Ognuno di quei w3wp.exe è un application pool distinto e separato nel quale possono giare più siti web (o anche uno solo) e una versione X del framework. In questo caso parlo al singolare. Si perché è impossibile che sotto ad un singolo application pool girino più versioni del framework.. Pena, la prima applicazione con il framework differente che inzierà a girare, ritornerà con un bell’errore di questo tipo.

Server Application Unavailable
The web application you are attempting to access on this web server is currently unavailable.  Please hit the "Refresh" button in your web browser to retry your request.
Administrator Note: An error message detailing the cause of this specific request failure can be found in the application event log of the web server. Please review this log entry to discover what caused this error to occur.

Questo avviene con un ordine non ben precisato. Mi spiego. Dato che l’application pool per default dopo 20 minuti di inutilizzo viene riciclato, è possibile che se il sito A che richiede la versione 1.1 del framework, non trovando un worker process attivo, ne carichi uno nuovo con quella versione del framework. Dopo pochi secondi arriva una nuova richiesta per il sito B. Stesso application pool, ma framework differente. Essendo l’application pool ancora attivo in memoria, il risultato è l’errore sopra mostrato.
Al successivo riciclo dell’application pool, potrebbe invece succedere l’esatto contrario. Ma l’errore non cambia e comunque nel registro degli eventi vi sarebbe sempre una traccia con la quale fare “debugging”. Infatti per problemi di questo tipo nell’event viewer viene aggiunta una entry con codice di errore 1062, come quella che si vede nell’immagine qui sotto.

Soluzione

Esistono due possibili soluzioni per questo genere di problema.

1) Soluzione non sempre praticabile, è quella di aggiornare la versione del framework per tutte le applicazioni. Non sempre possibile, perché alcuni componenti utilizzati magari non funzionano con una specifica versione, piuttosto che del managed code scritto, dato il cambio di alcune classi tra la versione 1.1 e la 2.0 del framework richiedono degli interventi sul codice.

2) Soluzione decisamente più sbrigativa, è quella di creare almeno un application pool diverso per ogni versione del framework che deve girare nel sistema e assegnare le varie applicazioni coerentemente con quanto detto.

Technorati Tags: IIS, Server Application Unavailable

Il motore FTP di IIS6 è stato notevolmente migliorato rispetto alle versioni precedenti. Che io ricordi configurarlo per un vero ambiente di hosting era un bagno di sudore e comunque le prospettive per una facile gestione erano estremamente lontane.

Non che oggi le cose siano cambiate poi molto. Sicuramente Microsoft potrebbe adoperarsi per implementare un servizio migliore che permetta una vera isolazione degli utenti, con possibilità di assegnare permessi a gruppi di utenti, e con l’aggiunta del quota management.

Di queste ultime tre caratteristiche, con l’introduzione di IIS 6, solo la prima è stata introdotta: addirittura prima di IIS 6, avere un FTP con il servizio Microsoft significava che un utente A dalla sua root poteva salire di un livello, vedere tutte le altre cartelle che erano presenti nella root generale del servizio (e magari se qualche permesso era sbagliato, entrare pure dentro ad una di queste cartelle e far danni).
Certo si potevano creare tanti FTP root quanti erano gli utenti, ma chi è ha tutti questi indirizzi IP da dare gratuitamente? Facile quindi immaginare perché in quasi tutti i servizi di hosting non si trovava – e ancora non si trova – quasi nessuno che utilizza il server FTP di Microsoft.

In merito al quota management (assegnazione dello spazio disco), anche qua il servizio è carente, anzi direi totalmente estraneo. Si può ovviare con un escamotage, utilizzando il servizio a livello “windows”. Passatemi quest’ultima affermazione. In quanto a gruppi di utenti, beh lasciamo stare. Qui forse bisogna aspettare l’arrivo di Longhorn. In realtà potrei vedere come funziona sotto Windows Vista. Presuppongo che il servizio sia lo stesso, ma d’altronde, questo mio articolo verte a voler mettere in piedi un servizio FTP con quanto MS mette a disposizione sul server e null’altro. E dato che l’attuale installazione di Windows 2003 mette a disposizione IIS6, limitiamoci solo ad IIS6 e null’altro.

Microsoft finalmente partorì la User Isolation.

Il funzionamento del server FTP di Microsoft è un peletto strano. Parte dal presupposto che:

1) Non esiste un utente FTP scisso dall’utente Windows, quindi per fornire accesso ad un sito FTP bisogna creare un account sul server o nel dominio, con appositi permessi ridotti (per il vostro bene);

2) Ad ogni utente FTP deve necessariamente corrispondere una cartella che abbia lo stesso nome dell’account;

3) La cartella (o home directory utente) deve avere lo stesso nome dell’account Windows che farà login;

Sembra che alla Microsoft hanno pensato che tutti gli utenti necessitassero di una cartella diversa e che ognuno dovesse custodire gelosamente i propri dati. Alla faccia quindi dei principi di collaborazione, di Team Foundation Server e di tutto il lavoro di gruppo in genere.

Commenti a parte, i punti 2 e 3 sono indispensabili, pena tutti gli account che fanno login si ritrovano confinati nella ROOT impostata per il servizio FTP, e se avrete sbagliato con la pianificazione della creazione delle cartelle, tutti potranno vedere tutto. Più avanti farò quindi un esempio di corretta configurazione del servizio FTP per un ambiente multiutente.

Quanto sopra, comunque, non è proprio quello che si chiama uno scenario da hosting. Ammessa e non concessa anche una corretta configurazione poi, fino ad IIS 5.0, non esisteva una vera isolazione utente, e quindi per quanto l’amministratore del server avesse creati all’account specifica per l’utente, ci si ritrova nello scenario poc’anzi descritto, ovvero l’utente semplicemente premendo il tasto “Folder up” del client FTP si ritrovava nella ROOT e da li poteva scorrazzare in giro per le cartelle all’interno del servizio FTP (i danni si potevano limitare con appositi permessi NTFS, ma almeno la visione era possibile per un motivo che spiegherò più avanti).

Questa cosa è stata risolta con IIS6 e la User Isolation: in pratica si tratta di un nuovo modello di configurazione per il servizio FTP (relativo ad uno specifico sito FTP – ricordo che si possono creare molteplici siti FTP sotto lo stesso server) che rende la home directory dell’utente la sua root, al di sopra della quale è impossibile andare.

Le altre due impostazioni disponibili sono “Do not isolate users” (che è il vecchio sistema di default fino ad IIS 5.0) e Isolate User Using Active Directory. Questi ultimi due, per quanto per il primo abbia dato accenno su cosa realmente faccia, non verranno trattati nel seguente articolo.

Attenzione: la scelta su come impostare il modo di isolazione la si può fare esclusivamente durante la creazione del sito FTP, e non la si può assolutamente cambiare a posteriori; pensate prima di agire.

Alcune configurazioni essenziali, altrimenti non si va avanti !!

Essenziale perché il servizio FTP di MS possa funzionare sono due aspetti importanti.

1) I permessi utente: ogni utente che accede ad uno specifico sito FTP deve avere almeno i permessi di Lettura e di Folder listing; pena errore 530 User ftp_adhoc cannot log in, home directory inaccessibile. Questo spiega perché era sempre possibile vedere tutto il contenuto delle varie cartelle fino ad IIS 5.0 e anche con IIS 6.0 se configurato in modalità “Do not isolate user”.

Consiglio pratico: create un gruppo di utenti, con i soli permessi di List e read, associateci tutti gli account windows che utilizzeranno il servizio FTP e assegnate a livello NTFS questo gruppo alla ROOT del sito FTP, facendo in modo da abilitare la propagazione dei permessi partendo dal padre, così che per ogni nuova cartella creata, sempre e comunque tutti gli utenti di quel gruppo avranno garantita la lettura (che sarà invece circoscritta dalla user isolation) .

2) Partendo da una data directory X che sarà per noi la Home Directory del servizio FTP o ROOT che dir si voglia, per creare una Home Directory specifica per l’utente in modalità Isolated user e fare in modo che quello sia il suo punto di partenza e non possa andare oltre, bisogna creare dentro la X una cartella denominata LocalUser e dentro a questa cartella create tante cartelle, una per ogni account Windows che farà login al servizio FTP.

Per intenderci quindi avremo una struttura di questo tipo:

C:\FTP <Home del server FTP>

C:\FTP\LocalUser\Public <Home directory per l’account anonymous qualora lo abilitiate>

C:\FTP\LocalUser\Test <Home directory per l’account test>

C:\FTP\Domain\Test <Dove al posto di domain ci deve essere scritto il nome del dominio, qualora il server sia appartenga ad un dominio o sia lui stesso un PDC>.

Un caso reale

Create un nuovo sito FTP e seguite il wizard. Per quanto riguarda i permessi da assegnare alla ROOT directory, indichiamo sia lettura che scrittura e non preoccupiamoci di questo, perché il servizio FTP verifica i reali permessi dell’account che si sta loggando prima a livello di FileSystem e poi a livello di servizio.

Mi spiego meglio: ipotizziamo di impostare a livello di servizio i permessi in lettura/scrittura per la ROOT ma nella scheda Security (permessi NTFS) della cartella X indichiamo solo quelli di lettura per l’account Test. Test in quella cartella non scriverà mai.

Dopo aver ultimato il wizard, create un gruppo di utenti per l’accesso FTP, un utente vero e assegnatelo al gruppo. Create la sua home directory come descritto nel paragrafo precedente.

Se avete seguito tutto fin qua descritto, vi ritroverete con un servizio FTP parzialmente utilizzabile. Perché? Beh, l’impossibilità di poter redirigere un utente su di uno specifico path, rende di fatto il servizio FTP come una specie di storage folder personale. Ma cosa succede se due account utente (perché utenti dello stesso sito) devono poter inserire/modificare/cancellare dati nella stessa directory?
Così come siamo questa cosa è impossibile. Impensabile di mettere lo stesso contenuto nelle due home directory. Chi sincronizzerebbe il contenuto e con che precedenza? Ma soprattutto perché far fare del lavoro inutile ad un software di terze parti?

La soluzione è quindi quella di fare in modo che due o più utenti vedano, una volta fatto il login, lo stesso contenuto. Come fare?

Assodato che ogni utente una volta fatto il login va comunque a finire nella sua home directory, bisogna fare in modo di creare un collegamento verso un altro specifico path.
Non si tratta di un collegamento windows, anche se il principio è lo stesso, ma bensì di uno JUNCTION o Symbolic Directory per chi lavora anche sotto Unix / Linux.

Con uno JUNCTION si vedrà quindi una cartella e non appena ci si muoverà al suo interno, di nascosto il sistema operativo ci catapulterà nel path fisico al quale è associato.

Qui bisogna quindi fare attenzione, perché sarà necessario impostare correttamente i permessi NTFS per le cartelle fisiche alle quali l’utente avrà accesso, impostando non solo permessi di lettura, ma anche quelli di scrittura e i permessi speciali per poter consentire di cancellare e creare directory. Non mettere questi permessi equivali ad avere un mezzo utente FTP.

 Così se avrete una cartella C:\FTPSites\LocalUser\Test\SitoWeb1 che punta a C:\WebSites\SitoWeb1, i permessi dovrete impostarli per quest’ultimo path.

Ne deriva che se un utente deve avere accesso a più siti, o a più directory, creeremo la cartella fisica C:\FTPSites\LocalUser\Test\ e al suo interno tante JUNCTION per le varie cartelle alle quali deve poter avere accesso, se invece l’utente ha un solo sito, addirittura la cartella Test (Stesso nome dell’account utente) potrà essere una JUNCTION.

Come creo queste Symbolic Directory (“Junction”)

Esistono due sistemi:

1) Scaricare il Resource Kit di Windows 2003 (20Mb e passa)

2) Utilizzare il tool di Rossinovich, Junction per l’appunto (Soli 41KB).

Ovviamente io opto per la seconda scelta.

Il tool funziona da riga di comando ed è estremamente semplice da utilizzare. Se con il prompt di Dos vi posizionate all’interno della cartella nella quale la vostra jucntion deve comparire, non dovrete far altro che scrivere: Junction <directory target>

La junction una volta create, per il sistema operativo, non sarà altro che una cartella normale, e di primo impatto, con le Risorse del computer non è possibile capire la differenza, che invece si evidenza da Prompt di MS-DOS.

Conclusione

Se avete fatto tutto bene, non resta che collegarvi al vostro server FTP di MS in modalità multiutente. Speriamo comunque che con la nuova versione di Windows Server, il supporto per tale servizio venga ulteriormente esteso e ampliato con il quota management e una migliore gestione degli accessi di gruppo. Magari se slegassero anche l’account windows dall’account FTP sarebbe il non plus ultra.

Ricercare problemi non è una cosa semplice, indipendentemente dall’ambiente in cui ci si trova. Oggi i programmatori accorti si sono resi conto che è necessario scrivere dei file di log per poter manifestare lo stato di errore, ma dal file a capirci qualcosa di acqua sotto i ponti ce ne passa. Specie se poi i file di log sono un ammasso di informazioni “accodate” e “relazionate” tra loro, ma che in un semplice file di testo diventano incomprensibili.

IIS7 , fortunatamente ha rivisitato un pochino questo sua parte, e in aggiunta al tradizionale file di log (il cosiddetto RAW Log) ha affiancato un elegante sistema di estrapolazione da questo file, che alla fine della storia niente altro che genera un file xml un po’ più ordinato, al quale, affiancando un file .xsl (XML Stylesheet Transformation file) generato in automatico dal server, si riesce a leggere in maniera decisamente più semplice il file.

Ma come fare per abilitare questo sistema di troubleshooting? Bisogna utilizzare il Failed Requests Tracing Setting – meglio conosciuto come FREB (perché prima il servizio si chiamava Failed Requests Event Buffering). Per la sua abilitazione ci sono diversi passaggi da dover eseguire. Iniziamo da principio.

Passo 1

Assicurarsi che il servizio di Tracing di IIS7 sia attivo (lo trovate sotto Control Panel, Program and Features, Turn Windows feature on, World Wide Web Services - Health and Diagnostics – Tracing)

Passo 2

Entrare nel pannello di amministrazione di IIS7 (La management console), quindi selezionare il sito web per il quale si vuole abilitare questa funzione, e sull’immediata destra fare click sulla voce “Failed Request Tracing”. Alla finestra di popup che si presenta, cliccare in alto sulla voce Enable. Il resto delle impostazioni si possono lasciare così come sono.

Questa parte serve in sostanza per comunicare al nostro server web che deve generare i log, cioè quel file di testo dove IIS scrive tutte le pagine richieste, l’IP del richiedente, lo stato di errore (200 pagina ok, 404 pagina non trovata, 500 errore, …). Questo è lo stesso file che viene utilizzato dai software di statistica per mostrare chi si connette al nostro sito.

C'è una cosa che mi sfugge. Il perchè abbiano chiamato questa feature come Failed Request Tracing, quando in realtà analizzando il file di log, lo stesso contiene come ho già detto, tutte quante le richieste avanzate al web server, con tutti i codici.

Passo 3

Configurare le eccezioni d’errore delle quali IIS deve tener traccia. Questo lo si può fare cliccando su Failed Request Tracing Rules e seguendo il wizard che compare facendo doppio click. La prima schermata consente di selezionare il contenuto che si vuole analizzare (in base alla sua estenzione). La seconda schermata richiede quale sia l’errore che di cui si vuole tenere traccia. Si deve necessariamente specificare un errore (almeno sul mio sistema non c’è stato verso di dire li voglio tutti).

Infine, terzo e ultimo passaggio, si configura il provider (cioè chi controllare) e la tipologia di errori (verbosity) da restituire. Se tutto è ok , potrete premere ok e ritrovarvi una nuova entry dentro alla lista.

Da questo momento in poi – limitatamente all’errore 500 (perché questo è stato richiesto) – all’interno della cartella %systemdrive%\inetpub\logs\FailedReqLogFiles\ (supponendo che stiamo parlando del default web server), sarà possibile trovare una serie di cartelle denominate W3SVC? Dove al posto del ? ci sarà un numero che altro non è che l’ID assegnato dal sistema quando si è creato un sito web. L’id del default web site è 1. All’interno di questa cartella si troveranno tanti file per ogni errore generato. Essendo dei file xml, doppio cliccandoci sopra, verrà aperto Internet Explorer e, in base al file freb.xsl contenuto nella cartella (e aggiunto in automatico dal sistema qualora questo non esista) si potrà leggere un file di analisi sufficientemente dettagliato.

In merito alla leggibilità c’è poi la possibilità di scaricare un nuovo template rilasciato direttamente dal Program Manager di IIS e disponibile qui.

Per applicare il file, basta semplicemente sostituire il file freb.xsl presente nella cartella sopra menzionata con quello presente nello zip.

Per ripristinare il file originale, invece, basta cancellare il file presente nella directory. Al successivo log, se mancante, il file verrà nuovamente rigenerato dal sistema.

N.B. I passi 2 e 3 lavorano assieme. Non è possibile far generare il file xml senza abilitare i raw logs.