venerdì 18 agosto 2017

Centralino IP PBX su Windows - 3CX Phone System which links here: http://www.3cx.it/centralino/index.html

 

 

RSS Feed RSS Feed

Login

Newsletter Newsletter

Registrati

RisorseGuide e Articoli

 

27

Una copia di questo articolo la puoi trovare anche su Microsoft Technet. qui
 

Introduzione
Il seguente articolo analizza l'architettura di Active Directory per comprenderne il funzionamento e descrive una serie di tools che consentono di controllarne il buon funzionamento.

Le utility DCDIAG (Domain Controller Diagnostics Tool), NETDOM (Windows Domain Manager), PORTQRY (Port Query), NTDSUTIL e ADSIEdit (ADSI Edit) fanno parte dei support tools che sono contenuti nella cartella support/tools del CD di Windows Server 2003 oppure sul primo CD di Windows Server 2003 R2, in alternativa è possibile scaricarli al seguente link Windows Server 2003 Service Pack 1 32-bit Support Tools.

Sommario
- Diagnostica funzionalità rete
- Condivisioni Netlogon e Sysvol
- Verifica delle condivisioni Netlogon e Sysvol
- Global Catalog
- Verificare se il DC è stato eletto come Global Catalog
- Replica di Active Directory e Ruoli FSMO
- Verifica funzionalità Active Directory
- Verifica funzionalità replica con altri Domain Controller
- Verifica detenzione ruoli master
- Verifica della disponibilità dei ruoli master operazioni
- Servizio DNS
- Verifica funzionalità DNS del Domain Controller
- Struttura fisica di Active Directory
- Verifica dell'integrità del database di Active Directory

DIAGNOSTICA FUNZIONALITA' DI RETE
Un dominio Windows 2000/2003 è sempre identificato da due nomi:

- Nome DNS. E' il nome completo DNS o FQDN (Fully Qualified Domain Name) ed è limitato a 255 caratteri, 63 per ogni etichetta (label) e rappresenta il nome nativo del dominio.
- Nome NetBIOS. E' utilizzato per compatibilità con i sistemi pre-Windows 2000 ed è limitato a 15 caratteri. Coincide per default con i primi 15 caratteri della prima label del FQDN DNS del dominio.
Per verificare che la funzionalità dei servizi di rete su cui si basa Active Directory è possibile utilizzare l'utility NETDIAG (Network Connectivity Tester):

* Test del servizio DNS: NETDIAG /test:dns
* Test dell'elenco dei controller di dominio: NETDIAG /test:dclist
* Test del rilevamento dei controller di dominio: NETDIAG /test:dsgetdc
* Test di LDAP (Microsoft Lightweight Directory Access Protocol): NETDIAG /test:ldap
* Test dell'appartenenza al dominio: NETDIAG /test:member
* Per verificare la registrazione di NetBIOS, del servizio DNS e dei servizi utilizzare il seguente comando:

NETDIAG /debug

L' utility NETDIAG registra automaticamente l'output sul file NetDiag.log che viene creato nella directory di esecuzione consentendo di esaminare il risultato del test diagnostico in modo più agevole.

Per maggiori informazioni sull'utilizzo di NETDIAG si veda al seguente articolo della Knowledge Base Microsoft HOW TO: Utilizzare lo strumento Diagnostica di rete (Netdiag.exe) in Windows 2000.


CONDIVISIONI NETLOGON e SYSVOL
Nei Domain Controller (DC) Windows NT gli script di logon venivano memorizzati nella condivisione amministrativa NETLOGON (che corrisponde alla directory %SystemRoot%\System32\Repl\Import\Scripts), mentre nei DC Windows 2000/2003 risiedono in SYSVOL (che corrisponde alla directory %SystemRoot%\Sysvol). Dcpromo modifica il valore di registro che definisce il path della condivisione NETLOGON facendola puntare a %SystemRoot%\Sysvol\Sysvol\NomeDominio\Scripts per consentire l'operatività ai client Windows 9x e Windows NT.

Ogni modifica alla directory %systemroot%\SYSVOL su un qualunque DC viene replicata agli altri DC utilizzando il servizio Replica file (FRS) basato su RPC (Remote Procedure Call).

La struttura della condivisione SYSVOL è la seguente:

* Sysvol\Sysvol\NomeDominio\Policies (corrispondente alla directory %SystemRoot%\Sysvol\NomeDominio\Policies) che contiene i Group Policy Template (ADM templates)
* Sysvol\Sysvol\NomeDominio\Scripts (corrispondente alla directory %SystemRoot%\Sysvol\NomeDominio\Scripts) che contiene gli scripts


VERIFICA DELLE CONDIVISIONI NETLOGON E SYSVOL
Per verificare se il Domain Controller condivide Netlogon e Sysvol e che i privilegi di logon necessari alla replica siano impostati è possibile utilizzare l'utility DCDIAG:

DCDIAG /test:frssysvol




DCDIAG /test:netlogons




Per maggiori informazioni sulla condivione SYSVOL si veda il seguente articolo della Knowledge Base Microsoft: How to rebuild the SYSVOL tree and its content in a domain.


GLOBAL CATALOG
In ogni domino è necessario avere un Global Catalog (GC) server e per impostazione predefinita al primo DC del dominio è assegnato automaticamente tale ruolo. Il GC contiene una replica completa di tutti gli oggetti di directory nel dominio host e una parziale di tutti gli oggetti di directory in tutti i domini della struttura. Il compito principale del GC consiste nel fornire autenticazione per gli accessi. Inoltre, poiché contiene informazioni su tutti gli oggetti in tutti i domini dell'insieme di strutture, consente la ricerca di oggetti a livello generale indipendentemente dal dominio di appartenenza di ciascun utente e/o computer fornendo informazioni sulle ubicazioni in cui è possibile trovare l'oggetto evitando query inutili nei domini. E' possibile configurare un DC come GC e aggiungere GC ad un dominio per accelerare i tempi di risposta per le richieste di accesso e di ricerca.


VERIFICARE SE IL DC E' STATO ELETTO COME GLOBAL CATALOG
Per verificare se un DC è stato eletto come Global Catalog e se, una volta inserito il flag Global Catalog, sia i grado di accettare richieste sulla porta TCP 3268 è possibile utilizzare l'utility PORTQRY e controllare il valore di isGlobalCatalogReady sia TRUE.

portqry -n -e 3268 -p tcp




Per maggiori informazioni sull'utilizzo di PORTQRY si veda al seguente articolo della Knowledge Base Microsoft HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues.


REPLICA DI ACTIVE DIRECTORY E RUOLI FSMO
Il database di Active Directory non ha una struttura monolitica ma è organizzato in partizioni o naming context che identificano strutture gerarchiche di oggetti, ciascuna delle quali costituisce un'unità di replicazione indipendente. Le partizioni Active Directory possono essere di tipo generale oppure di tipo applicativo (Active Directory Partition ADP).

Le partizioni generali possono essere di tre specie:

* Schema Partition. Contiene la definizioni degli oggetti (attributi e classi) utilizzabili in Active Directory (user, group, computer, organizational unit, etc...) e delle regole di utilizzo. Esiste una sola Schema Partition per ogni ciascuna foresta.
* Configuration Partition. Contiene informazioni generali sulla struttura e la composizione di una foresta (site, subnet, partizioni che compongono la foresta, dc, etc...). Esiste una sola Configuration Partition per ogni ciascuna foresta.
* Domain Partition. Contiene informazioni sugli oggetti creati in ogni dominio (user, group, computer, organizational unit, etc...). Esiste una sola Domain Partition per ogni dominio appartenente alla stessa foresta.

Le informazioni della Schema Partition e della Configuration Partition sono comuni a tutti i domini della foresta e quindi verranno replicate a tutti i DC della foresta, mentre le informazioni della Domain Partition sono private del dominio e quindi verranno replicate solo ai DC dello stesso dominio.

Le partizioni applicative possono essere di due specie:

* ADP builtin. Sono quelle dedicate al DNS (DomainDnsZones e ForestDnsZones) create automaticamente all'atto della creazione del dominio, nel caso si scelga di installare e configurare il servizioDNS dal wizard Dcpromo.
* ADP custom o personalizzate. Possono essere create manualmente per ospitare informazioni riguardanti applicazioni integrate in Active Directory (AD-aware)

Il processo di replica di Active Directory mantiene allineate le Directory Partition dei DC tramite una tipologia multimaster incrementale che consente di effettuare modifiche su qualsiasi DC e far sì che questo fornisca agli altri DC soltanto le differenze rispetto all'ultima sincronizzazione avvenuta. Per minimizzare i conflitti dovuti a modifiche dello stesso oggetto su DC diversi Active Directory implementa la replica a livello di singolo attributo, I DC, infatti, a seguito di una modifica aggiornano lo stamp associato all'attributo che è compostato da un Version Number (incrementato ad ogni modifica), un Timestamp (data e ora della modifica) e da un Server GUID (contenente il GUID del DC su cui è avvenuta la modifica). Nella comparazione degli stamp si considera il Version Number maggiore, nel caso ugualianza si considera il Timestamp maggiore e se anche il Timestamp è uguale si valuta il Server GUID.

Allo scopo di evitare conflitti di replica non risolvibilit tramite la comparazione degli stamp, Active Directory introduce l'amministrazione centralizzata di alcune operazioni, in altre parole alcune attività possono essere eseguite esclusivamente a seguito dell'autorizzazione data dal DC in possesso del ruolo associato alla specifica tipologia di operazione. Tali ruoli sono definiti flexible o Floating Single Master Operations (FSMO) in quanto è possibile spostare un ruolo assegnandolo ad un altro DC.

I ruoli FSMO sono cinque:

* Schema Master. Lo Schema Master è l'unico DC della foresta che possiede una copia i scrittura della Schema Partition (ciò significa che la modifica dello schema può essere seguita da un qualunque DC, ma prevede la connessione diretta con lo Schema Master).
* Domain Naming Master. Il Domain Naming Master è unico nella foresta e viene contattato quando è necessario creare un dominio per verificare che non sia già stato definito e ottenere un identificatore GUID univoco. Il Domain Naming Master è responsabile anche dell'autorizzazione alla cancellazione di un dominio, della validazione durante le operazioni di modifica dei nomi di dominio tramite il tool RENDOM.EXE e della creazione e cancellazione di una Application Directory Partition.
* Relative Identifier Master. Il Relative Identifier Master è unico nel dominio ed è responsabile della distribuzione dei pool contenenti le sequenze univoche dei Relative ID (RID) ai DC del dominio. I RID sono utilizzati dai DC durante la creazione degli oggetti Security Principal (User, Group o Computer) per attribuirgli identificativi Security ID (SID) univoci.
Il Relative Identifier Master si occupa anche di autorizzare lo spostamento di un oggetto in un altro dominio, tramite ad esempio l'Active Directory Migration Tool, per evitare che lo stesso oggetto possa essere spostato in due domini diversi.
I DC del dominio ricevono un pool di 500 RID dal Relative Identifier Master e quando la quantità disponibile raggiunge circa le 100 unità il DC contatterà il Relative Identifier Master per ottenere un nuovo pool.
Un SID è composto da 4 elementi S-1-5-Y1-Y2-Y3-Y4:
- S-1 che indica la revisione del SID (al momento è in uso la 1)
- 5 che definisce l'autorità di emissione del SID (5 indica Windows NT, 2000 o 2003 Server, per i well know SID si utiliza 0 o 1)
- Y1-Y2-Y3 è la porzione del domain SID (uguale per tutti i Security Principal del dominio)
- Y4 rappresenta il relative ID del dominio.
PDC emulator. il PDC emulator è unico nel domino e viene utilizzato come fonte di replica (master-slave) degli update della Domain Partition verso i BDC NT nel caso in cui il livello funzionale del dominio sia Windows server 2003 Interim o Windows 2000 Mixed Mode. il PDC emulator viene inoltre contattato da client precedenti Windows 2000 su cui non è installato l'Active Directory client durante la fase di cambio password degli account e per offrire piena compatibilità verso essi.
Il PDC emulator assolve anche la funzionalità di Domain Master Browser e indipendetemente dal livelo funzionale del dominio ha i seguenti compiti:
- Diminuire il tempo di convergenza nei cambi password.
- Essere la fonte di sincronizzazione del Windows Time Service (in una foresta i DC di un dominio usano il PDC emulator del proprio dominio come time source e a loro volta i PDC emulator dei vari domini della foresta usano come time source il PDC emulator del Forest Root Domain il quale può essere sincronizzato su un time server esterno tramite il comando net time \\servername /setsntp:TimeServer).
- Essere utilizzato di default dallo snap-in di creazione o modifica di un Group Policy Object.
- Autorizzare il raise del livello funzionale del dominio.
Infrastructure Master. l'Infrastructure Master è l'unico DC nel domino che ha il compito di mantenere aggiornata la relazione GUID-SID-DN degli utenti/gruppi definiti nei domini esterni a quello di appertenenze dell'Infrastructure Master, ma utilizzati anche nei gruppi del suo dominio (phantom record). In caso di modifica del Distinguished Name (DN) (per es. spostamento nel domino) o del SID (per es. spostamento in altri domini) di tali utenti/gruppi la visualizzazione dei membri dei gruppi che li contengono non deve produrre incoerenze. Per ottenere tale risultati l'Infrastructure Master verifica e aggiorna periodicamente eventuali differenze tra il proprio database locale di phantom record e le informazioni nei Global Catalog server.


VERIFICA FUNZIONALITA' ACTIVE DIRECTORY
Tramite Dcdiag è possibile verificare la registrazione DNS di un controller di dominio, controllare che i descrittori di protezione (SID) nelle intestazioni del contesto dei nomi dispongano delle autorizzazioni appropriate per la replica, analizzare lo stato dei controller di dominio in un insieme di strutture o in un'organizzazione e così via. Per maggiori informazioni si veda il seguente link: Domain Controller Diagnostics Tool (dcdiag.exe).

DCDIAG /v /f:


VERIFICA FUNZIONALITA' REPLICA CON ALTRI DOMAIN CONTROLLER
Per verificare verificare la funzionalità replica con altri Domain Controller è possibile utilizzare l'utility DCDIAG:

DCDIAG /test:replications




VERIFICA DETENZIONE RUOLI FSMO
Per verificare quale server detiene i ruoli FSMO è possibile utilizzare l'utility NETDOM:

netdom /query fsmo




VERIFICA DISPONIBILITA' DEI RUOLI MASTER OPERAZIONI
Per verificare la disponibilità dei ruoli master operazioni è possibile utilizzare l'utility DCDIAG, controllandone la localizzazione tramite il test knowsofroleholders e la disponibilità e il corretto funzionamento tramite il test fsmocheck:

DCDIAG /s: /test:KNOWSOFROLEHOLDERS /verbose




DCDIAG /s: /test:FSMOCHECK




SERVIZIO DNS
Uno degli aspetti più importanti dell'implementazione di Active Directory è la sua filosofia "IP-centrica", nel senso che questa tecnologia si basa su alcuni standard del TCP/IP e in modo particolare sul servizio DNS che svolge le seguenti funzioni:

- Servizio di risoluzione dei nomi dei computer e/o domini in in indirizzi IP e viceversa.
- Servizio di registrazione dinamica (Dynamic DNS o DDNS) dei nomi dei computer (resource record di tipo address o RR di tipo A), degli indirizzi IP (RR di tipo pointer o RR di tipo PTR) e degli RR di tipo service location o RR di tipo SRV. Gli RR di tipo A e PTR vengono registrati da tutti i computer mentre gli RR SRV sono registrati solo dai DC.
- Definizione degli standard da adottare per la definizione dei nomi dei domini AD. DNS e AD condividono gli stessi namespace, ovvero la stessa gerarchia di domini, pertanto ad ogni dominio AD deve obbligatoriamente corrispondere un dominio DNS
- Servizio per la localizzazione (service location) dei DC Windows 2000/2003 che offrono servizi strategici ai client AD (LDAP Server, Kerberos Server, Global Catalog Server, etc...)

Per un client Windows 2000/XP/2003 membro di un dominio AD Windows 2000/2003 l'assenza o l'incorretta impostazione del server DNS comporta un declassamento del dominio AD da Windows 2000/2003 a semplice dominio Windows NT (eseguendo l'utility gpresult.exe per la determinazione del "Resultant Set Of Policy" il dominio di appartenenza appare infatti come "Domain Type: WindowsNT 4"). Su questi client configurati in modo errato il dominio AD Windows 2000/2003 verrà visto come un dominio Windows NT con un determinato nome NETBIOS che offre servizi di autenticazione NTLM e tutti i servizi nativi AD (autenticazione Kerberos, GPO, ricerche LDAP e/o ADSI, etc...) non saranno disponibili. Ovviamente queste considerazioni sono valide anchenel caso in cui il client sia configurato correttamente ma il servizio DNS non sia disponibile.


VERIFICA FUNZIONALITA' DNS DEL DOMAIN CONTROLLER
Per verificare verificare la funzionalità del DNS del Domain Controller è possibile utilizzare l'utility DCDIAG (il test diagnostico del DNS è stato introdotto con la versione di DCDIAG rilasciata con Windows Server 2003 SP1):

DCDIAG /test:DNS

Per l'esecuzione di ulteriori attività e controlli relativi al servizio DNS si faccia riferimento ai seguenti articoli della Knowledge Base Microsoft:

- How to reinstall a dynamic DNS Active Directory-integrated zone
- Troubleshooting Active Directory replication failures that occur because of DNS lookup failures, event ID 2087, or event ID 2088
- SRV Records Missing After Implementing Active Directory and Domain Name System


STRUTTURA FISICA DI ACTIVE DIRECTORY
Active Directory è basata su un database di tipo ISAM (Index as Sequential Access Method) gestito da un DBMS ESE (Extensible Storage Engine) noto anche col nome di Jet Blue (vi sono infatti due implementazioni separate delle Jet Api, chiamate Jet Blue e Jet Red e spesso il termina "Jet" viene utilizzato per riferirsi a Jet Red che è il DBMS utilizzato da Microsoft Access).

ESE è un componente introdotto con Windows 2000 che implementa un user-mode storage engine che gestisce i dati mediante un file binario. I dati saranno resi disponibili all'applicazione tramite Api mediante l'utilizzo di una DLL. Questo DBMS viene utilizzato da svariate applicazioni, come ad esempio Exchange e ADAM, in quanto offre buone performance ed un elevata scalabilità.

Il database di Active Directory è contenuto di default nella directory %SystemRoot%\NTDS e il cuore del DIB (Directory Infomation Base) è rappresentato dal file NTDS.DIT che viene creato dal comando dcpromo all'atto della promozione del server a DC utilizzando il modello %SystemRoot%\System32\ntds.dit.
Per la gestione dei log il DBMS ESE utilizza i file edb.log, edb*.log, res1.log e res2.log, mentre per la gestione del checkpoint utilizza il file edb.chk (per default la dimensione dei file di log è di 10 MB mentre quella del file di checkpoint è variabile).

Per conoscere la posizione del database NTDS.DIT e dei file log è possibile utilizzare l'utility NTDSUTIL:

1. Aprire il prompt dei comandi.
2. Digitare SET SAFEBOOT_OPTION=DSREPAIR e premere invio.
3. Digitare ntdsutil e premere invio.
4. Digitare files e premere invio.
5. Digitare info e premere invio per visualizzare le informazioni sul file di database e sui file di log.
6. Digitare quit e premere invio.
7. Digitare quit e premere invio per chiudere la sessione NTDSUTIL.





Quando viene eseguita un'operazione sul DC che avvia una scrittura sul database (creazione/cancellazione di un oggetto, modifica di un attributo di un oggetto o replica di oggetti e attributi da altri DC partner di replica) viene generata una transazione che contiene i dati e i meta-dati (numero di versione USN, il timestamp, il GUID del server su cui è stata generata la modifica). Una transazione è un'unità atomica di operazioni da eseguire su un database, ovvero devono essere portate a termine con successo tutte in caso contrario verrà ripristinata la situazione precedente all'esecuzione della transazione.

Le transazioni vengono immediatamente registrate in modo sequenziale nel file di log corrente (EDB.LOG) e quindi viene eseguita la modifica nella copia del database in memoria, ciò garantisce che le modifiche vengano eseguite anche nel caso di uno shutdown o di un crash immediatamente successivo.

Il DBMS ESE si occupa di di aggiornare il file NTDS.DIT con le transazioni contenute nei file log e aggiornando il contenuto del file di checkpoint (EDB.CHK) in modo che contenga la posizione sino a cui le operazioni di scrittura nel database sono state eseguite con successo (stato di committed della transazione).

Quando il file di log corrente (EDB.LOG) raggiunge la dimensione massima di default di 10.204 KB viene rinominato come EDBHHHHH.LOG (dove H è una cifra esadecimale) e viene creato un nuovo file EDB.LOG. Per una miglior ottimizzazione dello spazio su disco i file di log vengono gestiti tramite la modalità circular logging, che consiste nel sovrascrivere i log più vecchi in modo circolare cancellano i file non più necessari una volta eseguite le scritture sul database e aggiornato il file di checkpoint.

Per garantire la disponibiltà di spazio anche in situazioni di emergenza oper le normali operazioni di deframmentazione online, vi sono due file di riserva (RES1.LOG e RES2.LOG) della dimensione standard dei file log che vengono utilizzati nel caso in cui il sistema esaurisca lo spazio disponibile sul volume contenente il database.

I file EDBTMP.LOG e TEMP.EDB sono due file temporanei utilizzati da attività quali deframmentazione online, recovery, situazioni di emegenza derivati da sovraccarico, ecc.

Nel caso di chiusura anomala del sistema il DBMS ESE rileva l'esistenza di una situazione anomala controllando il log degli eventi e se l'ultimo record non corrisponde ad uno shutdown "normale", ESE riapplica il log segnalati nel file di checkpoint (EDB.CHK) notificandolo nell'Event Viewer tramite gli eventi NTDS ISAM 300, 301, 302. Nel caso di assenza del file di checkpoint (EDB.CHK) vengono riaplicate tutte le transazione contenute file di log.

VERIFICA DELL'INTEGRITA' DEL DATABASE DI ACTIVE DIRECTORY
Per verificare l'integrità del database di Active Directory è possibile utilizzare l'utility NTDSUTIL:

1. Riavviare il sistema.
2. Durante la fase di avvio premere F8.
3. Selezionare l'opzione Modalità ripristino servizi directory (solo controller domini Windows).
4. Selezionare il sistema operativo da avviare.
5. Autenticarsi tramite l'account Administrator con la password di "amministratore modalità ripristino servizi" specificata durante l'esecuzione di dcpromo.
6. Confermare il messaggio che indica che Windows è in esecuzione in modalità provvisoria.
7. Aprire il prompt dei comandi.
8. Digitare ntdsutil e premere invio.
9. Digitare files e premere invio.
10. Digitare integrity e premere invio per avviare il controllo di integrità
11. Digitare quit e premere invio.
12. Digitare sematic database analysis e premere invio.
13. Digitare go e premere invio per avviare il controllo semantico del database.
14. Digitare quit e premere invio.
15. Digitare quit e premere invio per chiudere la sessione NTDSUTIL.


Per l'esecuzione di ulteriori attività e controlli tramite l'utility NTDSUTIL si faccia riferimento ai seguenti articoli della Knowledge Base Microsoft:

- Utilizzo di Ntdsutil per gestire file di Active Directory dalla riga di comando in Windows Server 2003
- How to complete a semantic database analysis for the Active Directory database by using Ntdsutil.exe
- Deletion of Critical Objects in Active Directory in Windows 2000 and Windows Server 2003
- Rimozione di dati in Active Directory dopo un abbassamento di livello non riuscito di un controller di dominio
- Utilizzo dello strumento Ntdsutil.exe per assegnare o trasferire ruoli FSMO a un controller di dominio
- HOW TO: Cercare ed eliminare gli identificatori di protezione (SID) duplicati con Ntdsutil in Windows Server 2003
- Reimpostazione della password dell'account amministratore per la modalità ripristino servizi directory (DSRM) in Windows Server 2003
- How to restore deleted user accounts and their group memberships in Active Directory
- Mancato abbassamento di livello dei controller di dominio quando si utilizza l'Installazione guidata di Active Directory per forzare l'abbassamento di livello in Windows Server 2003 e in Windows 2000 Server


CONCLUSIONI
La diagnostica di Active Directory dovrebbe essere eseguita periodicamente soprattutto quando vengono eseguite modifiche corpose, prima di un backup del system state evitando così di salvare una versione non valida, ma soprattutto dopo il cambio di una Domain Controller (DC) per accertarsi che il processo di trasferimento sia andato a buon fine (a tal proposto si faccia riferimento alla guida Migrare un DC Windows2003 verso un nuovo server).

Per ulteriori approfondimenti si faccia riferimento al seguente articolo della Knowledge Base Microsoft How to verify an Active Directory installation.

(a cura di Ermanno Goletto - SysAdmin.it)


Scritto in: Guide e Articoli
AZIONI: E-mail | Permalink |
CONDIVIDI: del.icio.us   Facebook   Digg   Google   Live Bookmarks   Newsvine   StumbleUpon   Technorati   Yahoo   DotNetKicks
blog comments powered by Disqus

Copyright 2011 by SysAdmin.it