Ricerche IT

Si consideri una rete aziendale con sedi distaccate, dove per i più svariati motivi, alcune applicazioni vengono utilizzate via Terminal Services su un server Windows Server 2003, utilizzando client Windows XP Professional o Windows Vista Business; in questo caso, è evidente che, quando si ha bisogno di stampare un qualsiasi documento, non è pratico mandare la stampa su una stampante presente nella sede principale, dovranno essere utilizzate le stampanti presenti nella sede distaccata.

Gestire le stampanti con Windows Server 2003 con abilitati i Terminal Services può essere una cosa piuttosto antipatica; perché le cose funzionino bene, è necessario che sul server sia installato il driver della stampante installato sul client, in più, per essere certi di non avere problemi, se possibile, sarebbe ancor meglio utilizzare per le stampanti i driver Microsoft, e non i driver dei vari produttori delle stampanti.

Microsoft ha migliorato le cose con Windows Server 2008, dove, se ho capito bene il tutto, abilitando i Terminal Services, il server invia la coda di stampa al client sotto forma di file XPS, che quindi viene stampato dal client utilizzando lo spooler ed il driver del client, eliminando il problema; non sono sicuro che le cose funzionino proprio così, ma non dovrei essermi allontanato troppo dal vero. Questo meccanismo prende il nome di Easy Print.

Tornando a Windows Server 2003, se per l’accesso ai servizi Terminal si utilizza un client Windows XP, è bene aggiornare il client RDP alla versione 6, quindi, bisogna fare i conti con le stampanti che si posseggono. Prendiamo ad esempio uno scenario in cui mi sono trovato ad operare: server Windows 2003 con abilitati i servizi Terminal, a cui accedono alcuni client con Windows XP (con client di servizi Terminal versione 6) tramite un collegamento geografico; questi client utilizzano una stampante HP LaserJet 2420 dn, cioè una stampante con un print server ed una unità fronte-retro.

In una situazione simile, è una scelta obbligata quella di permettere la stampa da applicazioni distribuite tramite Terminal Services sulle stampanti locali dei client, per cui, bisogna fare in modo che il server Terminal riconosca le stampanti locali dei client. Nel caso in oggetto, bisogna quindi, all’atto della connessione, assicurarsi che le risorse locali (in questo caso le stampanti) vengano mappate sul server, tramite un’impostazione raggiungibile dal client RDP cliccando su Opzioni, tab Risorse locali, dove è possibile scegliere quali risorse locali “traslare” sul server, come mostrato in Figura 1:

Fig. 1 - mappatura risorse locali su server

Nell’immagine si può notare l’impostazione di mappatura delle stampanti, abilitata cliccando sulla casella relativa; a questo punto, è possibile connettersi per verificare se la stampante verrà installata anche sul server.

Una volta effettuata la connessione, se andiamo nella cartella stampanti, possiamo notare che la stampante HP LaserJet 2420 non è stata installata; nel event viewer (e più precisamente nel log System), abbiamo un evento con id 1111 ed origine TermServDevices che ci segnala l’impossibilità di installare il driver della stampante poiché sconosciuto, come mostrato in figura 2.

Fig. 2 - evento 1111 TermServDevices

Ciò è normale, e dipende dal fatto che il driver della stampante non è un driver Microsoft ma HP, che quindi Windows Server 2003 non ha e non può installare.

Una prima soluzione a questo problema, può essere quella di installare sui client una stampante HP LaserJet che stampi con protocollo PCL e che possieda la possibilità di installare un’unità fronte-retro, come ad esempio la HP LaserJet 4100, utilizzando il driver Microsoft configurato con un’unità duplex per il fronte-retro. Così facendo, la stampante viene correttamente installata, come mostrato in figura 3

Fig. 3 - stampante HP 4100 installata

ed anche nel log degli eventi compaiono diversi eventi (con id 20, 15, 9 e 2) ed origine Print che indicano i vari passaggi di installazione della stampante. Provando a stampare su quella stampante, le stampe arrivano alla stampante HP 2420 perfettamente, peccato però che non funzioni il fronte-retro, che andrebbe impostato sulla stampante ad ogni sessione Terminal, poiché, per un motivo che non conosco, ad ogni sessione questa impostazione viene perduta; una scomodità inaccettabile. Un’altra soluzione potrebbe consistere nell’installazione del driver HP della stampante LaserJet 2420, ma anche in questo caso non funziona il fronte-retro, che è disponibile ma dà problemi in fase di stampa; perchè questo avvenga, non l’ho proprio capito, probabilmente un’incompatibilità del driver in ambiente Terminal Services.

A questo punto, la prima soluzione al problema consiste nell’accontentarsi del mancato funzionamento del fronte-retro, mentre la soluzione n. 2 è un attimino più professionale, e prevede l’installazione di un driver HP chiamato Universal Print Driver, un driver appunto “universale”, rilasciato da HP che permette di installare un unico driver compatibile con tutte le stampanti di rete HP LaserJet e con gran parte delle stampanti inkjet HP, e che prevede la possibilità di abilitare diverse funzioni tra le quali il fronte-retro.

Scaricato questo driver, il primo passo consiste nell’installazione di una stampante HP Universal Printing sui client. Se nella rete sono presenti più stampanti HP, conviene installare il driver della stampante in modalità dinamica, in modo tale da poter scegliere di volta in volta su quale stampante mandare le code di stampa, altrimenti è possibile installare il driver in modalità tradizionale, in cui verrà richiesta la porta di stampa e le altre solite informazioni. Tenere presente che in modalità dinamica, verranno ricercate esclusivamente stampanti in rete (o almeno, io non ho visto nessuna voce di menu in cui poter scegliere di installare una stampante attaccata direttamente al PC), ed inoltre, se nella rete abbiamo stampanti con un print server JetDirect, è possibile lanciare una rilevazione che troverà automaticamente queste stampanti. Scelta una modalità di installazione, ed installata la stampante, verrà creata nella cartella stampanti un oggetto chiamato “HP Universal Printing PCL 6″ sui client; nel caso in esame, la cosa migliore secondo me è installare la stampante in modalità dinamica, poiché la HP LaserJet 2420 possiede un print server JetDirect, ed è quindi ricercabile tramite il comodo tool in fase di installazione.

Ora bisogna installare il driver sul server, utilizzando una modalità diversa da quella usata sui client, poiché sul server non abbiamo bisogno di installare una stampante, è sufficiente installare il driver; per far questo, andare nella cartella stampanti, quindi cliccare sul menu File -> Server properties, quindi cliccare sulla scheda Drivers, cliccare poi sul pulsante Add, partirà il classico wizard di installazione del driver della stampante tramite il quale va installato il driver HP Universal Printing, in tal modo il driver è presente ma sul server non viene creata la stampante.

Compiuti questi passaggi, se effettuiamo la connessione al server Terminal, possiamo notare in figura 4 che è stata creata sul server la stampante HP Universal Printing PCL 6

Fig. 4 - stampante HP Universal Print

Tramite questa stampante, abbiamo la possibilità di stampare sulla stampante locale anche in fronte-retro, semplificando la gestione di altre eventuali stampanti HP e risparmiando quindi tempo e rotture di scatole. Bisogna dire però che questa modalità funziona solo con stampanti HP, e nemmeno con tutte, infatti ho avuto problemi con una multifunzione inkjet, che sarebbero oggetti anche utili in determinati contesti, ma che dal punto di vista dei driver rappresentano il Male.

Non ho ancora avuto esperienze con stampanti non HP su server Terminal, però mi sento di consigliare in casi simili, quando possibile, di utilizzare sempre driver Microsoft per evitare problemi.

Link e approfondimenti

Problematiche connesse alla migrazione di un Server Terminal

Stampanti supportate con Universal Print Driver in ambiente Citrix (documento PDF)

Si prenda in considerazione uno scenario in cui si ha un server Windows Server 2003 con i Terminal Services installati ed un client Windows, diciamo Windows 2000 Professional o Windows XP Professional; in uno scenario del genere, per un motivo che ancora non ho capito, per il semplice motivo che mi rifiuto di capire la perversa politica di licensing di Microsoft, può capitare saltuariamente che uno di questi client, all’atto della connessione al server Terminal, dia questo errore:

The remote session was disconnected because there are no Terminal Server client access licenses available for this computer

La soluzione a questo problema che ho trovato non è certamente elegante, ma funziona, e consiste nel cancellare la chiave del registro di configurazione

HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing

In questo “posto” vengono archiviate le informazioni relative alla licenza client per la connessione ad un server con i Terminal Services abilitati. Cancellando questa chiave, si cancella quindi la licenza client, per cui, ritentando la connessione, viene installata nuovamente la licenza client e si riuscirà ad accedere nuovamente al server via RDP.

Sito di riferimento

http://www.chicagotech.net/netforums/viewtopic.php?p=936

Su un server Linux, uno strumento indispensabile per l’amministrazione del server stesso è il server SSH, come OpenSSH, tramite il quale possiamo avere un accesso sicuro alla shell del sistema operativo, per poter amministratore comodamente il nostro server Linux.

In ambiente Windows, un accesso SSH non è una cosa indispensabile, risulta più utile avere un accesso via Remote Desktop per amministrare il server, allo stesso tempo però, può comunque avere un senso l’accesso SSH su server Windows, un po’ per determinate operazioni da svolgere via riga di comando, un po’ per poter scaricare o caricare file da o sul server attraverso SCP e SFTP, che possono diventare comodi soprattutto se ci connettiamo al server in remoto, via VPN, oppure se dobbiamo amministrare o trasferire dati da una macchina Linux ad una macchina Windows, in questo modo non saremo costretti ad utilizzare X oppure ad installare Samba per il trasferimento dati da/verso Windows.

Per quanto concerne il software che funge da server SSH, ne esistono diversi, e direi che più o meno tutti sono un’implementazione di SSH in ambiente emulato Cygwin; io ne ho provati due, Freesshd e CopSSH, che rispondono a due esigenze diverse, in particolare, Freesshd fornisce l’ambiente di shell di Windows, mentre CopSSH fornisce un sottoinsieme dei comandi presenti nella shell Bash di Linux.

Personalmente, tra un’implementazione completa della shell di Windows come quella di Freesshd (che appunto richiama direttamente l’interprete dei comandi di Windows, cmd.exe) ed una che (secondo le mie prove, che ammetto non essere state esaustive) risulta, all’atto pratico, avere una parte dei comandi Bash ed una parte dei comandi di Windows, come accade con CopSSH, preferisco Freesshd; tanto per fare un esempio, con Freesshd riesco a vedere i processi in esecuzione con il comando tasklist, cosa che non riesco a fare con Copssh.

Per poter utilizzare un server SSH su Windows, l’utente col quale faccio il logon al server deve obbligatoriamente consentire l’accesso interattivo al server, se così non è, va modificata l’opportuna policy (si tratta di policies diverse a seconda se il server è controller di dominio oppure no) sul server Windows, e questo può comportare qualche problema di sicurezza in più, cosa che secondo me rappresenta il vero svantaggio dell’avere attivo un server SSH su Windows. Entrambi i software hanno una procedura che permette di specificare quali utenti definiti sul server Windows possono accedere via SSH al server stesso, va da sé che, se vogliamo amministrare decentemente il server Windows, dovremo accedere allo stesso con un’utenza amministrativa, se invece necessitiamo del solo SFTP, è sufficiente abilitare l’utente all’accesso, dopodiché saranno le autorizzazioni impostate sulle cartelle del server Windows a stabilire le possibili azioni dell’utente.

Tornando a FreeSSHD, l’installazione del prodotto è decisamente banale, basta cliccare sempre su Avanti (Next); durante l’installazione verrà creato il servizio FreeSSHDService, in modo che il “demone” sia sempre attivo, quindi dovremo accedere alla configurazione del programma, cliccando col tasto destro sull’icona del programma posta nella systray e, scegliendo la voce Settings dal menu contestuale, è possibile gestire il server SSH, e soprattutto, è possibile abilitare o disabilitare l’accesso SSH agli utenti di Windows tramite la scheda Users, come mostrato in figura 1:

Figura 1 - Scheda Users di FreeSSHD

A questo punto, è sufficiente utilizzare un client SSH come Putty in ambiente Windows, o utilizzando il comando ssh in ambiente Linux/Unix, e collegandosi al server (finora ho provato solamente con nome utente e password, senza utilizzare certificati) si può testare il corretto accesso al server Windows.

Purtroppo, per un motivo che non sono ancora riuscito a capire, al primo tentativo viene restituito l’errore “Incoming packet was garbled on decryption” con Putty oppure l’errore “Bad packet length” su Linux, seguito da un numero; la cosa strana è che tentando una seconda volta, senza cambiare nulla, la connessione avviene senza nessun problema, se qualcuno sa o ha idea da cosa possa dipendere, farebbe cosa molto gradita scrivendolo nei commenti.

Una volta verificato il corretto accesso al server Windows, è possibile configurare anche SFTP, andando a specificare nella configurazione di FreeSSHD qual è la directory root SFTP del server Windows tramite la scheda SFTP, come mostrato in figura 2:

Figura 2 - Scheda SFTP di FreeSSHD

Ora non ci resta che testare il corretto funzionamento di una connessione SFTP; per Windows, si possono utilizzare due programmi, WinSCP (che a dispetto del nome consente anche la connessione SFTP) e FileZilla, il quale, oltre alle normali connessioni FTP, permette di stabilire connessioni SFTP basandosi sull’onnipresente Putty.

Questa configurazione, secondo le prove che ho potuto fare, funziona abbastanza bene, con alcuni difetti: per prima cosa, ho letto sul Web che FreeSSHD peccherebbe un po’ in stabilità, finora io non ho avuto problemi, ma non ne ho fatto un uso intensivo; secondariamente, per quanto riguarda SFTP, l’unica configurazione possibile riguarda la root directory accessibile dagli utenti, impedendo agli stessi di poter accedere alle cartelle di livello superiore, e ciò è positivo dal punto di vista della sicurezza, poiché in questo modo si possono abilitare diversi utenti che comunque non hanno la possibilità di gironzolare per il disco, però, allo stesso tempo, questa impostazione riguarda TUTTI gli utenti, per cui anche gli utenti con privilegi amministrativi, utilizzando SFTP, non possono operare ad un livello superiore rispetto alla home directory, anche se, in realtà, utilizzando Linux, è possibile superare questa limitazione utilizzando scp, per poterlo fare però bisogna conoscere il percorso esatto del file da prelevare; altra limitazione, la shell fornita per default da FreeSSHD è quella di Windows, per cui WinSCP non funziona in modalità SCP, funziona però perfettamente in modalità SFTP.

In conclusione, installare un server SSH su Windows, è utile, secondo me, solo in determinate occasioni, soprattutto se da client Linux dobbiamo accedere o condividere file con un server Windows, oppure può risultare utile su connessioni remote particolarmente lente, altrimenti, secondo me è più utile utilizzare Remote Desktop, utilizzabile anche da Linux tramite il pacchetto rdesktop.

La versione pacchettizzata di MySQL Server 5 per Linux Debian Etch 4.0 ha una caratteristica, non accetta connessioni sulla porta 3306 (la porta a cui risponde MySQL) se non da localhost, cioè sé stesso. Questo può essere un problema se vogliamo o dobbiamo tenere due macchine separate per un’applicazione (o sito) ed il relativo database.

La soluzione al problema è molto semplice, si tratta di commentare la seguente voce

bind-address = 127.0.0.1

presente nel file di configurazione di MySQL, /etc/mysql/my.cnf, dopodiché, dobbiamo abilitare uno o più utenti per poter connettersi in remoto su un particolare database utilizzando l’istruzione SQL GRANT:

GRANT ALL privileges ON testDB.* TO 'testUSR'@'192.168.0.3' IDENTIFIED BY 'testPWD'

così facendo, si abilita l’utente testUSR a connettersi al database testDB dall’host 192.168.0.3. A questo punto, è sufficiente far ripartire il demone di MySQL per abilitare la modifica effettuata al file my.cnf:

/etc/init.d/mysql restart

e questo è tutto.

Facendo riferimento al precedente articolo, che trattava la configurazione degli host virtuali in Apache su un sistema Debian, proseguiamo sulla stessa falsariga e vediamo come configurare in modo opportuno un server FTP che consenta una gestione separata dei diversi siti, impedendo nello stesso tempo agli utenti di girare per il file system e quindi di accedere ad aree della macchina che non competono loro; in questo articolo parlerò di ProFTPD, anche se nell’articolo precedente avevo citato vsftpd, purtroppo, nell’installazione in cui ho in funzione vsftpd, ho avuto alcuni problemi di cui non sono riuscito a capire l’origine, problemi che mi hanno costretto ad utilizzare un altro server FTP, ProFTPD appunto.

Ora dobbiamo configurare in modo opportuno ProFTPD in modo da avere due utenti distinti che gestiscano i due siti creati come descritto nell’articolo precedente, creando due siti FTP virtuali, con l’ausilio di un database dedicato su MySQL; installiamo quindi ProFTPD con il supporto per MySQL:

# apt-get install proftpd proftpd-mysql

Ora dovremo creare il database per ProFTPD, entrando in MySQL col comando:

$ mysql -u root -p

quindi, dopo aver inserito la password, creiamo il database proftpd col comando:

> CREATE DATABASE proftpd;

ed ora, creiamo l’utente MySQL proftpd, al quale diamo le autorizzazioni del caso al database proftpd:

> GRANT SELECT, INSERT, UPDATE, DELETE ON proftpd.* TO ‘proftpd’@'localhost’ IDENTIFIED BY ‘pwdProFTPD’;
> FLUSH PRIVILEGES;

dove, al posto di pwdProFTPD metteremo la password che più ci aggrada.

A questo punto, seguiamo le istruzioni contenute nel preziosissimo tutorial di Howtoforge, che spiega passo passo come realizzare un server FTP che permetta di definire dei virtual host, a cominciare dalle indicazioni su come creare un utente ed un gruppo di sistema per ProFTPD, per poi passare alle istruzioni su come creare le tabelle nel database MySQL riguardanti gli utenti e le ftpquotas (le quote di spazio riservato su disco per ogni utente), dopodiché, a pagina 2 della guida, viene spiegato quali righe aggiungere al file di configurazione /etc/proftpd/proftpd.conf per consentire a ProFTPD di utilizzare un database MySQL come supporto. In particolare, vediamo la riga SQLConnectInfo (in cui vanno inseriti i parametri di connessione al database), la quale, se utilizziamo un database MySQL configurato come descritto in precedenza, va scritta così:

SQLConnectInfo proftpd@localhost proftpd pwdproftpd

Giunti qui, dobbiamo inserire gli utenti nel database MySQL, in particolare nella tabella ftpuser (ho tralasciato volutamente la parte riguardante le quote disco); la guida presente su Howtoforge è fatta molto bene, ma ha il difetto di inserire le password degli utenti in chiaro nella tabella del database, cosa che comporta problemi di sicurezza, per cui, dovremo per prima cosa cambiare una direttiva nel file di configurazione di ProFTPD, per poi utilizzare un’istruzione SQL INSERT diversa da quella riportata su Howtoforge. Il primo passaggio, come detto, consiste nel modificare la direttiva SQLAuthTypes, impostandola in questo modo:

SQLAuthTypes Crypt Plaintext

che significa che le password degli utenti definiti nel database MySQL devono essere criptate, altrimenti l’utente non riuscirà ad autenticarsi su ProFTPD. Ora , dopo aver fatto ripartire il demone proftpd, passiamo all’inserimento vero e proprio degli utenti nel database proftpd in MySQL, in cui dobbiamo prestare attenzione ad indicare la home directory su cui verrà rimbalzato l’utente che si autentica su ProFTPD; in particolare, facendo riferimento all’articolo riguardante l’hosting virtuale con Apache, creeremo un utente chiamato u_webtest con password p_webtest (password insicura, utilizzata per comodità) e home directory /var/www/webtest, quindi creeremo un altro utente chiamato u_webprova con password p_webprova e home directory /var/www/webprova:

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webtest’, ENCRYPT(’p_webtest’), 2002, 2002, ‘/var/www/webtest’, ‘/sbin/nologin’, 0, ”, ”);

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webprova’, ENCRYPT(’p_webprova’), 2003, 2003, ‘/var/www/webprova’, ‘/sbin/nologin’, 0, ”, ”);

Da notare che per inserire la password è stata usata la funzione di MySQL ‘ENCRYPT’, la quale utilizza la chiamata di sistema crypt() presente sul sistema operativo, quindi di fatto utilizza lo stesso metodo di cifratura utilizzato da Linux per cifrare le password degli utenti di sistema. Ora, rimangono da impostare i permessi sulle directory dei due siti web, per far sì che gli utenti FTP possano scrivere al loro interno, dando l’autorizzazione in scrittura all’utente ftpuser creato in precedenza:

# chown -R ftpuser:www-data /var/www/webtest
# chown -R ftpuser:www-data /var/www/webprova
# chmod -R 775 /var/www/webtest
# chmod -R 775 /var/www/webprova

Arrivati fin qui, dobbiamo solamente utilizzare un client FTP per testare la funzionalità del nostro server FTP, e, se tutto è andato bene, dovremmo essere pronti per utilizzare il nostro ProFTPD.

Se un server Linux Debian viene utilizzato come server Web, è abbastanza probabile che questo ospiti più siti, ed è piuttosto comune che questi siti vengano gestiti da persone diverse, che debbono avere quindi un accesso FTP dedicato per poter caricare i file del proprio sito, e magari poter avere l’accesso al proprio database MySQL tramite PhpMyAdmin, facendo in modo che gli operatori non vadano a gironzolare su directory o database non di loro competenza.

In questo primo articolo (il prossimo tratterà della configurazione del server FTP vsftpd), darò per scontato che siano già installati (tramite il solito apt) Apache2, PHP5, MySQL; ipotizziamo quindi di dover creare due siti, webtest.it e webprova.it, e creiamo le relative directory:

# mkdir /var/www/webtest
# mkdir /var/www/webprova

Ora, create le directory, dobbiamo configurare gli host virtuali in Apache. Apache2, in Debian, consente la configurazione degli host virtuali inserendo un file di configurazione per ogni host virtuale che si intende creare nella directory /etc/apache2/sites-available, per cui, andremo a creare i due file per i due domini:

# touch /etc/apache2/sites-available/webtest.it
# touch /etc/apache2/sites-available/webprova.it

A questo punto, creati i file vuoti, vanno editati con questi contenuti:

File /etc/apache2/sites-available/webtest.it

NameVirtualHost *:80
<VirtualHost *:80 >
ServerAdmin webmaster@webtest.it
ServerName www.webtest.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webtest
<Directory "/var/www/webtest">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
</VirtualHost>

File /etc/apache2/sites-available/webprova.it

<VirtualHost *:80 >
ServerAdmin webmaster@webprova.it
ServerName www.webprova.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webprova
<Directory "/var/www/webprova">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webprova.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webprova.it.log combined
</VirtualHost>

Ora i due siti sono configurati con impostazioni "normali", vediamo il loro significato:

NameVirtualHost *:80
Serve per definire su quale interfaccia di rete e su quale porta deve rimanere in ascolto l’host virtuale Apache, in questo caso rimane in ascolto su tutte le interfacce sulla porta 80

<VirtualHost *:80 >
Identifica l’apertura della sezione relativa alla configurazione dell’host virtuale, l’indicazione successiva a VirtualHost (*:80) deve essere identica a quella della direttiva NameVirtualHost

ServerAdmin webmaster@webtest.it
Indica l’indirizzo e-mail dell’amministratore del dominio

ServerName www.webtest.it
Rappresenta il nome FQDN del sito, è fondamentale scrivere bene questa voce altrimenti il nostro sito non sarà visibile

DirectoryIndex index.html index.php
Esprime l’ordine di ricerca di determinate pagine Web rappresentanti la home page quando viene fatta da un browser una richiesta del tipo www.webtest.it/ o www.webtest.it/test/, se in queste directory non esiste una pagina chiamata index.html o index.php (o qualsiasi altro nome file indicato nella direttiva DirectoryIndex), Apache restituirà un errore 403 Forbidden se usiamo la direttiva "Options -Indexes" (come effettivamente faremo), oppure, se questa direttiva non viene utilizzata, visualizzeremo i files presenti nella directory

DocumentRoot /var/www/webtest
Indica la directory in cui sono posizionati i file del nostro sito

<Directory "/var/www/webtest">
Identifica l’inizio della configurazione delle autorizzazioni per la directory del sito

Order Deny,Allow
Allow from all
Queste due righe stanno ad indicare che il sito è visibile a tutti

Options -Indexes
Come indicato in precedenza, questa opzione permette di visualizzare un errore 403 di accesso negato se si digita un indirizzo del tipo www.webtest.it/test/ ed in questa directory non esiste un file chiamato con uno dei nomi file indicati nella direttiva DirectoryIndex; se non si specifica questa opzione, sarà visibile il contenuto dell’intera directory, cosa da evitare.

ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
ErrorLog fornisce un percorso per il file di log contenente le segnalazioni di errore che incontra Apache, mentre LogLevel indica la verbosità delle operazioni di logging attraverso un sistema di livelli, di cui "warn" è uno dei più bilanciati; CustomLog identifica la posizione del file di log che registra gli accessi al sito Web.

Giunti qui, andiamo a creare i file di log che abbiamo specificato nei file di configurazione dei virtual hosts:

# touch /var/log/apache2/access.webtest.it.log
# touch /var/log/apache2/webtest.it.log
# touch /var/log/apache2/access.webprova.it.log
# touch /var/log/apache2/webprova.it.log

dopodiché, bisogna abilitare i siti virtuali, e ciò è possibile tramite il comando a2ensite, il quale crea dei link simbolici nella cartella /etc/apache2/sites-enabled/ che puntano ai file di configurazione creati in precedenza nella cartella /etc/apache2/sites-available/:

# a2ensite webtest.it
# a2ensite webprova.it

ciò è necessario poiché nel file di configurazione di Apache (/etc/apache2/apache2.conf) vi è una direttiva che include i file presenti nella cartella /etc/apache2/sites-enabled/.

Ora non rimane altro che riavviare Apache ed avremo i nostri virtual hosts funzionanti.

Giunti qui, rimane da fare un’unica cosa, cioé installare e configurare PhpMyAdmin per poter gestire il proprio database MySQL tramite sito Web. Per installare PhpMyAdmin, possiamo utilizzare il comando

# apt-get install phpmyadmin

dopodiché, dobbiamo creare un alias su ogni sito sul quale vogliamo rendere disponibile PhpMyAdmin; l’alias si rende necessario poiché l’installazione di PhpMyAdmin viene effettuata nella directory /usr/share/phpmyadmin, per cui, o si fa l’alias, oppure si copia la directory phpmyadmin nella directory del sito, ma ciò non conviene, poiché:

1. è un’operazione che dovremmo ripetere per ogni aggiornamento di PhpMyAdmin
2. nel caso di più host virtuali che utilizzano PhpMyAdmin, dovremmo ripetere la copia per ogni host virtuale che utilizza PhpMyAdmin

per cui, è bene utilizzare un alias per ogni virtual host, che mappi una directory virtuale (ad esempio, /phpmyadmin) per ogni host virtuale che utilizza PhpMyAdmin. Configurare l’alias è molto semplice, prendendo ad esempio i file di configurazione dei due domini citati precedentemente, basta aggiungere questa riga dopo l’istruzione DocumentRoot:

Alias /phpmyadmin /usr/share/phpmyadmin

quindi, dopo aver chiuso e salvato il/i file di configurazione, basta far ripartire Apache per poter utilizzare PhpMyAdmin, la cui configurazione esula dagli scopi di questo articolo; in ogni caso, tenere presente che, se PhpMyAdmin è configurato con un livello di sicurezza ‘cookie’, nome utente e password richiesti per entrare in PhpMyAdmin, non sono altro che gli utenti definiti in MySQL, per cui, bisogna fare attenzione alle autorizzazioni che si assegnano ai vari database, onde evitare che certi utenti possano accedere a database non di loro competenza.

Link di riferimento
Gestione Moduli e Virtual Hosts di Apache2 su Debian e Ubuntu
HowTo: Configurazione dei Virtual Hosts (alias) con Apache2 su Debian ETCH

ExMerge è un’utilità fornita da Microsoft, che consente di esportare o importare, da o verso Exchange, cassette postali in formato .PST. Questa utility è utile soprattutto quando è necessario spostare le cassette postali da un server Exchange ad un altro server Exchange, oppure se si vuole fare un “backup dei poverelli” delle cassette di posta, utile se per fare il salvataggio di Exchange abbiamo solo NTBackup, che fa il backup dell’Information Store ma non delle singole caselle di posta.

Per utilizzare ExMerge, dobbiamo assicurarci di non avere nella nostra organizzazione cassette postali superiori ai 2GB; se queste esistono, è necessario ridurre le loro dimensioni, dopodiché, è possibile scaricare ExMerge dal sito Microsoft, file che quindi va scompattato, per poi copiare i file ExMerge.exe e ExMerge.ini nella cartella degli eseguibili dell’installazione di Exchange, “c:\Percorso-Cartella-Installazione-Exchange\bin”. Prima di poter eseguire l’utility però, bisogna compiere alcuni passi preliminari:

1. creare e/o modificare un utente che abbia accesso alle cassette postali con i privilegi “Send as” e “Receive as”
2. fermare, se necessario, il servizio SMTP per non ricevere ed inviare messaggi di posta durante la fase di esportazione/importazione
3. effettuare un salvataggio completo dell’Information Store, per poterlo ripristinare in caso di problemi

Il passaggio n. 1 consiste nella creazione di un utente, che chiameremo ExMerge, che possa accedere alle cassette postali di tutti gli utenti con i privilegi “Send as” e “Receive as”. Per creare l’utente, utilizzare la console “Active Directory Users and Computers”, e da qui rendere l’utente appartenente al gruppo Administrators (già presente di default in ogni installazione di Windows Server 2003), dopodiché, delegare l’amministrazione dell’organizzazione Exchange all’utente ExMerge andando su System Manager, quindi cliccare col tasto destro sul nome dell’organizzazione Exchange e selezionare la voce “Delegate Control”, che apre un wizard, da lì aggiungere l’utente ExMerge agli utenti che già hanno la possibilità di amministrare Exchange, avendo cura di assegnargli il ruolo “Exchange Full Administrator”, quindi terminare il wizard confermando le scelte effettuate. A questo punto, bisogna fare i conti con le impostazioni predefinite di Exchange Server 2003, che per gli utenti facenti parte di un gruppo amministrativo (come appunto il gruppo Administrators), nega l’autorizzazione “Send As” e “Receive As” sul (o sui) Mailbox Store, per cui, bisogna impostare in modo esplicito le autorizzazioni “Send As” e “Receive As” sul Mailbox Store per l’utente ExMerge, oppure creare un gruppo di protezione specifico per gli utenti che vogliamo abilitare a questo compito, e delegare a questo gruppo l’amministrazione di Exchange. In questo caso, avendo bisogno di un unico utente, possiamo evitare di creare un gruppo di protezione.

Ora eseguire, se necessario, il passaggio numero 2 e fermare il servizio SMTP, per impedire che vengano spediti e ricevuti ulteriori messaggi di posta, che in una fase di migrazione o ripristino possono incasinare per bene le cose, e che comunque possono essere perduti al termine di questa fase. Non rimane altro da fare che effettuare un salvataggio dell’Information Store, o tramite un software di backup o semplicemente copiando il contenuto della cartella mdbdata (o comunque della cartella in cui è posizionato il database delle mailbox di Exchange).

A questo punto, è possibile far partire ExMerge, non con un doppio click ma cliccando col tasto destro sull’eseguibile selezionando la voce “Run as”, quindi specificare l’utente ExMerge appena creato e cliccare Ok. Ora possiamo scegliere tra due modalità, la modalità “One Step”, che esegue un salvataggio dello store ed un ripristino su un altro server in un unico passaggio - e la modalità “Two Step”, che consente di effettuare l’esportazione e l’importazione delle cassette postali in due fasi distinte, utile se vogliamo fare un backup o un restore delle cassette postali sullo stesso server Exchange.

In questo caso, vediamo la modalità Two Step: dopo aver scelto questa voce, viene richiesto se effettuare lo Step 1 (esportazione) o lo Step 2 (importazione), quindi, dopo aver scelto di fare l’esportazione delle cassette postali, specificare il server Exchange dal quale si vogliono estrarre le cassette di posta, indicando anche il Domain Controller del dominio per velocizzare le operazioni, tenere presente però che il DC va indicato con attenzione se ci troviamo in un ambiente multidominio, poiché verranno esportate solamente le cassette postali facenti parte del dominio a cui appartiene il DC indicato nella casella “Domain Controller (DC) Name”

Giunti fin qui, ExMerge richiede quali cassette di posta vogliamo esportare (nel nostro caso tutte), quindi, una volta selezionate le mailbox che ci interessano, andiamo avanti e selezioniamo l’impostazione della lingua di default (nel nostro caso Italiano) e selezioniamo, per maggior sicurezza, anche il flag “Use last mailbox login locale”, che consente di utilizzare l’impostazione della lingua utilizzata su una determinata casella durante l’ultimo accesso alla stessa.

Ora dobbiamo selezionare la cartella di destinazione in cui salvare i file .PST delle mailbox, quindi, fatto questo, possiamo procedere con l’estrazione vera e propria, la cui durata dipende ovviamente dal numero di caselle di posta e dal loro “peso”. Finita l’esportazione, è possibile controllare il file ExMerge.log per verificare che non vi siano stati errori in questa fase. Se tutto è andato bene, avremo una sorta di backup di tutte le cassette di posta della nostra organizzazione, che sono ripristinabili in ogni momento, con il vantaggio, a differenza di un salvataggio generico dell’Information Store, che possiamo effettuare il restore anche della singola casella postale.

Il restore di una cassetta di posta può essere fatto sempre con ExMerge, e sempre con le stesse modalità descritte in precedenza, tranne che per la scelta dello Step, infatti per effettuare un ripristino deve essere scelto lo Step 2, come mostrato nella figura sottostante:

La cosa a cui dobbiamo prestare attenzione in questa fase, è la modalità di importazione o ripristino della cassette di posta, infatti, quando ci viene richiesto il server Exchange sul quale vogliamo ripristinare le mailbox, è bene, prima di andare avanti, premere il pulsante “Options” e indicare con che modalità avviene il ripristino.

Dall’immagine precedente, è possibile vedere che nella scheda “Import procedure” ci viene richiesto come ripristinare gli elementi della cassetta postale; trattandosi di un ripristino, la cosa più probabile è che si vogliano sovrascrivere gli elementi già presenti, opzione attivabile cliccando su “Replace existing data in target store”, anche se la scelta da effettuare dipende sempre dal contesto nel quale ci troviamo. Ora è possibile proseguire seguendo i passi svolti in precedenza, facendo attenzione a selezionare la cartella sorgente dalla quale pescare i file .PST salvati in precedenza, dopodiché è possibile procedere con il restore vero e proprio. Se tutto è andato bene, avremo ripristinato le nostre cassette di posta, in ogni caso, è sempre bene verificare tramite il file di log (ExMerge.log) che non vi siano stati errori non bloccanti.

E’ importante ricordare che il formato del file .PST creato da ExMerge è quello di Outlook 97-2002, per cui, viene a mancare il supporto ai file con dimensioni superiori ai 2GB, come accennato in precedenza; ho avuto un’esperienza del genere, la quale mi ha insegnato che ExMerge non ha apparentemente problemi a creare file .PST maggiori di 2GB, ma poi, quando si tenta di ripristinare la cassetta postale salvata, viene restituito un errore generico che ci informa che l’importazione del file PST non è andata a buon fine, quindi, spulciando il log di ExMerge (il file ExMerge.log, presente nella cartella in cui abbiamo salvato ExMerge.exe, l’eseguibile dell’utilità) troviamo questa riga:

Error configuring message service (MSPST MS) (UNKNOWN ERROR) (CMapiSession::CreateEMSPSTProfile)

Da questa piccola disavventura, si può trarre l’insegnamento che, in caso di utilizzo di ExMerge, è bene verificare, prima di lanciarlo, che le cassette postali di Exchange non superino i 2GB di dimensione; ancor meglio sarebbe utilizzare delle mailbox quota che impediscano di avere cassette postali più grandi di una certa dimensione, ma questo non sempre si può fare, purtroppo molta gente continua ad utilizzare la posta elettronica in modo improprio, tenendo nella propria casella di posta migliaia di messaggi semplicemente temendo la remota possibilità che servano in un imprecisato futuro.

Link di riferimento:
http://blogs.ugidotnet.org/alexblog/articles/24659.aspx (bell’articolo su ExMerge)
http://support.microsoft.com/kb/292509 (impostazione di un gruppo di protezione per l’utilizzo di ExMerge, io ho usato una strada leggermente diversa)
http://technet.microsoft.com/it-it/library/aa997470(EXCHG.65).aspx (strategie e procedure consigliate per ExMerge)

La corretta gestione dell’ora dei sistemi è molto importante in una rete con un dominio Active Directory, poiché il protocollo di autenticazione predefinito, Kerberos, richiede che l’ora di server e client sia sincronizzata, pena la possibile mancata autenticazione del client, il quale non sarà quindi in grado di fruire dei servizi erogati dal/dai server.

In primis, è buona norma configurare il domain controller che svolge il ruolo di master operazioni PDC in modo tale che prenda l’ora da un riferimento esterno; utilizzando il protocollo Network Time Protocol (NTP), il controllore di dominio sincronizza l’ora, tramite il servizio "Ora di Windows" (W32Time) , con uno o più server NTP, accessibili tramite la rete Internet. Per sincronizzare il controllore di dominio con una o più fonti esterne, è possibile utilizzare la metodica descritta in un precedente articolo. Il passo successivo riguarda la sincronizzazione dei client: se si tratta di postazioni Windows XP e, direi (ma non ho ancora avuto esperienza diretta), Windows Vista, che sono iscritte nel dominio, l’ora sarà sincronizzata automaticamente per impostazione predefinita, prendendo come riferimento il domain controller in questione. Lo stesso avviene per server membri e controller di dominio Windows 2003. Il protocollo utilizzato per questo tipo di sincronizzazione non è NTP ma NT5DS.

In alcuni casi, è possibile che il domain controller non riesca a sincronizzarsi con il/i server NTP, in tal caso, bisogna cercare di capire come mai questo avviene. Il primo passo da seguire, è verificare se non esiste già un’applicazione che utilizza la porta UDP 123, con il comando:

netstat -noa | find "123"

Se ci viene restituita una riga in cui compare un’applicazione che utilizza la porta UDP 123, bisogna segnarsi il PID (Process ID) del processo in questione (ad esempio, 4127), quindi, si utilizza il comando tasklist per identificare quale processo sta utilizzando la porta 123:

tasklist | find "4127"

e così sapremo quale applicazione utilizza la porta 123.

Se invece non risulta nessuna applicazione che utilizza la porta UDP 123, dovremo cercare di capire che avviene durante la sincronizzazione dell’ora. A tal fine, si può abilitare la registrazione del debug del servizio Ora di Windows, andando ad aggiungere alcuni parametri nella chiave del registro di sistema

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Questi parametri consistono nell’aggiunta di nuovi valori stringa chiamati FileLogSize, FileLogName e FileLogEntries, i cui dati valore sono indicati nella relativa pagina della Knowledge Base Microsoft. Dopo aver aggiunto questi valori, riavviare il servizio Ora di Windows col comando

net stop w32time && net start w32time

quindi digitare il comando

w32tm /resync

per forzare la sincronizzazione dell’ora. Fatto ciò, bisogna aprire con un editor di testo il file specificato precedentemente nel parametro FileLogName del servizio Ora di Windows, che ci mostrerà le varie operazioni svolte durante la sincronizzazione, sperando che ciò ci sia d’aiuto per risolvere i problemi di sincronizzazione dell’ora.

Uno dei possibili utilizzi dell’Asus eeepc (il nuovo subnotebook di Asus con schermo da 7"), è quello di avere un pratico gingillo da portare sempre con sé e da utilizzare, se necessario, per brevi operazioni di amministrazione su server Linux (tramite ssh) o su server Windows, connettendosi con rdesktop su quei server Windows Server 2003 su cui è abilitato Remote Desktop.

Rdesktop è un’utilità già presente sull’installazione predefinita dell’eeepc, che consente appunto di connettersi ad un qualsiasi computer Windows con attivo il servizio RDP; la particolarità di rdesktop presente su eeepc è che… non funziona. Per essere più precisi, rdesktop non ha alcun problema in sé, ma se lanciamo dal terminale il comando:

$ rdesktop -a 16 -f nomeserver

cercando di connetterci ad un server Windows Server 2003, ci viene presentata la schermata di login dove, se inseriamo nome utente e password, ci butta fuori dando un errore "segmentation fault" nella finestra del terminale.

La ragione di quest’errore, è che, per impostazione predefinita, X.org montato sull’eeepc funziona con una profondità di colore di 16 bit, per cui bisogna modificare quest’impostazione lanciando da terminale il comando:

$ sudo kwrite /etc/X11/xorg.conf

e andando a modificare il valore della voce "DefaultDepth", portandolo da 16 a 24. Salvare il file modificato, quindi riavviare X, ad esempio con la combinazione di tasti (brutale ma veloce) CTRL+ALT+BACKSPACE, e, da una finestra di terminale, dare di nuovo il comando:

$ rdesktop -a 16 -f nomeserver

quindi immettere nome utente e password, ed amministrare il proprio server Windows Server 2003 alla risoluzione di 800×480 pixel, non comodissima ma utilizzabile per periodi non troppo lunghi.

Windows Server 2003 R2 integra ed estende le funzionalità di Distributed File System (d’ora in poi DFS), il componente che permette di gestire file system distribuiti tra più host in una rete Windows. In particolare, quest’articolo tratta della creazione di uno spazio dei nomi DFS su due server domain controller (d’ora in poi DC) Windows Server 2003, della creazione di cartelle e relative sottocartelle, in modo da avere più share distribuite su due server, situati su due diverse LAN e nei relativi siti Active Directory (d’ora in poi AD), LAN connesse tra di loro tramite un collegamento geografico a bassa velocità; la situazione viene mostrata in figura 1:

Figura 1

Il primo DC è DCServer, che ha indirizzo IP 172.16.1.1 sulla rete 172.16.1.0/24, il secondo DC è Coriolis, che ha indirizzo IP 192.168.1.10 sulla rete 192.168.1.0/24; ognuno dei due server funge da Global Catalog per il proprio sito AD di appartenenza.

In breve, un namespace (spazio dei nomi) DFS consente di avere più cartelle condivise su più server che fanno parte di un unico contenitore, il namespace appunto, che sarà accessibile dagli host del dominio secondo una struttura che viene impostata dall’amministratore di rete; così facendo, gli utenti di rete non dovranno preoccuparsi di sapere su quale server è situata una risorsa condivisa, semplicemente, l’unica cosa che dovranno conoscere è la struttura del namespace, che diventa l’unico "repository" logico dell’intera struttura dati aziendale; nella situazione descritta all’inizio dell’articolo, si noterà la differenza tra cartelle residenti sulla propria LAN e le cartelle residenti sul server remoto, unicamente in funzione della velocità di accesso alle cartelle stesse, dove ovviamente il browsing delle cartelle poste sul server remoto sarà notevolmente più lento. Si comprenderanno meglio questi concetti una volta messo in funzione lo spazio dei nomi DFS.

Per attivare DFS, bisogna installare sui due server il ruolo "File Server", utilizzando lo strumento "Manage your server" che si apre dopo il logon e che è accessibile anche andando su Start -> Programs -> Administrative Tools; cliccare ora su "Add or remove a role", cliccare su Next e, nella lista dei ruoli, selezionare la voce "File Server", dopodiché cliccare due volte su Next; a questo punto compare un ulteriore wizard, "Add File Server Role Wizard", cliccare su Next e selezionare il ruolo (relativo al File Server) "Replicate data to and from this server", che installa il servizio "DFS Replication", come mostrato in figura 2.

Figura 2

Il servizio DFS Replication è una novità introdotta con Windows Server 2003 R2 che consente di replicare i file tra due o più server in presenza di link di rete a bassa velocità, tipici delle WAN. In questo articolo non verrà trattato in dettaglio DFS Replication (che sarà oggetto di un articolo a parte), si sappia che uno spazio dei nomi DFS non necessita obbligatoriamente di DFS Replication, il quale a sua volta non necessita di uno namespace DFS; DFS replication e i namespace DFS comunque sono studiati per integrarsi senza problemi, anzi, molto spesso si utilizzeranno insieme, se si ha l’esigenza di creare uno spazio dei nomi DFS. Giunti qui, cliccare su Next e completare l’installazione del ruolo; tenere presente che per installare il ruolo File Server con DFS Replication è necessario avere a disposizione il CD 2 di Windows Server 2003 R2, che verrà richiesto durante l’installazione.

Una volta fatte queste operazioni su entrambi i server, posizionarsi sul server che ospiterà il namespace (che prende l’ovvio nome "namespace server") e creare lo spazio dei nomi DFS andando sulla console di gestione del servizio da Start -> Programs -> Administrative Tools -> DFS Management; aperta la console MMC, creeremo un nuovo spazio dei nomi basato su dominio, pertanto, nella colonna di destra cliccare sulla voce "New Namespace…", si aprirà l’immancabile wizard, in cui dovremo scegliere il server che fungerà da "namespace server", in questo caso DCServer, andare avanti e dare un nome allo spazio dei nomi, ad esempio "Cartella", che rappresenta la condivisione radice, che "conterrà" (dal punto di vista logico) tutti i dati che rientrano nel namespace DFS; fatto questo, cliccare su Next e lasciare selezionata la voce "Domain-based namespace", che indica la creazione di uno spazio dei nomi basato su dominio, quindi andare avanti e cliccare sul pulsante Create e poi sul pulsante Close per completare la creazione del namespace DFS. Ora bisogna aggiungere il secondo DC nell’ambito del namespace, quindi selezionare nella colonna di sinistra lo spazio dei nomi "\\terminus.lan\Cartella", e cliccare sulla colonna di destra (pannello Actions) la voce "Add Namespace Server…" ed aggiungere il server Coriolis nella casella "Namespace server", infine cliccare su Ok per aggiungere Coriolis come server dello spazio dei nomi per il namespace "\\terminus.lan\Cartella", come indicato in figura 3, dove è possibile osservare che i due server sono su due siti AD diversi.

Figura 3

Creato il namespace, ora bisogna creare la struttura delle sottocartelle del namespace appena creato, sottocartelle che, in questa particolare casistica, risiederanno ognuna solamente su un server, visto che al momento non verrà presa in esame la replica dei dati tra i diversi server facenti parte dello spazio dei nomi. Su entrambi i server, abbiamo una cartella condivisa che prende il nome "Dati", in cui sono situati i dati dell’organizzazione, accessibili secondo la classica formula \\nomeserver\nomecondivisione, che nei due casi descritti diventa \\dcserver\dati e \\coriolis\dati; ora vedremo come poter creare due sottocartelle del namespace, in modo tale che le due risorse condivise siano raggiungibili passando sempre dallo spazio dei nomi, secondo la formula \\terminus.lan\cartella\dati_dcserver e \\terminus.lan\cartella\dati_coriolis. Per creare una cartella dipendente dallo spazio dei nomi, cliccare sulla colonna di sinistra sul namespace \\terminus.lan\cartella quindi cliccare sulla voce "New Folder…" presente nel pannello di destra Actions, si aprirà la finestra di creazione della nuova cartella, in cui bisogna specificare il nome della cartella, nel nostro caso dati_dcserver, quindi cliccare sul pulsante Add… per aggiungere la destinazione cartella (folder target), che nel nostro caso sarà \\dcserver\dati; ripetere ora gli stessi passaggi per creare la cartella dati_coriolis con destinazione cartella \\coriolis\dati. è possibile che all’atto della creazione della cartella ci venga proposto un messaggio in cui è sconsigliata la creazione di una cartella che ha come destinazione una cartella già esistente, noi possiamo comunque ignorare il messaggio e confermare l’operazione. Ora l’interfaccia di DFS Management avrà l’aspetto mostrato in figura 4:

Figura 4

Ora questa struttura di cartelle sarà disponibile su tutti i computer del dominio, a prescindere dalla LAN di appartenenza, infatti, se digitiamo il percorso \\terminus.lan\cartella (corrispondente, come noto, al namespace creato in DFS Management) da vari host presenti sia sul sito "Rete192", sia sul sito "Rete172", avremo una finestra simile a quella mostrata in figura 5:

Figura 5

Da questa finestra, è possibile vedere su quale server sono residenti le due cartelle (anche se il nome delle cartelle spiega tutto) cliccando col tasto destro su una cartella e selezionando la voce Proprietà, dove è presente la scheda DFS, che mostra appunto qual è il percorso "reale" della cartella.

Come indicato in precedenza, se da un host qualsiasi appartenente alla LAN 172.16.1.0/24 sfogliamo e cerchiamo di accedere ai dati presenti nella cartella dati_coriolis, avremo una velocità d’accesso limitata dalla banda disponibile sul collegamento in WAN. Per ovviare a questo problema, è consigliabile utilizzare il meccanismo di replica che in Windows Server 2003 prende il nome "Replica DFS", che sarà oggetto di un prossimo articolo.