Utilisation des profils errants (sans IACA):
exemple du réseau ZOLARC (2000-2001)

I. Quelques raisons d'utiliser les profils errants:

Pour le réseau du lycée Zola, la stratégie que j'ai choisie repose fondamentalement sur les profils errants.  De façon simplifiée, voici les raisons de ce choix :
NB: les postes de travail de ce réseau ont tous Win NTworkstation comme OS, ce qui simplifie la gestion de ces profils par rapport à un réseau hétérogène (WinNT + Win95/98) ou sous Win95/98 uniquement.

A. D'un point de vue de l'utilisateur:

1. le profil errant permet de stocker l'ensemble des caractéristiques propres à un utilisateur: bureau, menu démarrer, paramètres internet (favoris, caractéristiques du compte de mail...), lecteurs réseau...
   
   
2. les utilisateurs du réseau doivent pouvoir utiliser indifférement  tous les postes de travail disponibles dans l'établissement sans avoir à (re)configurer leur environnement à chaque changement de poste
   
   
3. les profils errants étant stockés de façon centrale (cad sur un serveur), chaque fois qu'un utilisateur ouvre une session de travail sur un poste, son profil est transféré du serveur vers le poste en question => l'utilisateur retrouve donc l'ensemble des paramétrages de son profil
   
   
4. si l'utilisateur modifie, au cours de sa session de travail, les paramètres de son profil (par ex la couleur du bureau), à la fermeture de cette session les nouveaux paramètres seront mis à jour dans son dossier de profil sur le serveur => à la prochaine ouverture de session il disposera de son profil avec les paramètres modifiés

De ce fait les utilisateurs ont réellement l'impression de toujours etres "chez eux" qq soit le poste de travail qu'ils utilisent.

B. D'un point de vue de l'administrateur réseau (sous Win NT)

1. L'utilisation des profils errant permet de ne pas surcharger le dossier systéme winnt\profiles des postes de travail: en effet, la stratégie système "ordinateur par défaut" (fichier ntconfig.pol sur le CPD) permet d'imposer que la copie du profil de l'utilisateur, transféré du serveur vers le dossier winnt\profiles du poste utilisé, soit effacée lorsque l'utilisateur quitte sa session.
   Par conséquent, si 200 utilisateurs utilisent un même poste, à la place d'avoir 200 dossiers de profils (environ 4 Mo chacun => 800 Mo !!)) stockés dans winnt\profil de cet ordi (si on utilise des profils locaux ou des profils errants non-effacés) , il n'en existe que 3: celui de l'utilisateur en cours de session, celui de l'utilisateur par défaut (Default User) et celui imposé à tous les utilisateurs (All User)
   
   
2. Le stockage des dossiers de profils sur un serveur permet de modifier le profil d'un utilisateur de façon simplifiée: supposons par exemple que je souhaite qu'un prof soit le créateur/responsable HTML pour sa matière => il doit donc disposer d'un raccourci vers le logiciel Dreamweaver.exe (stocké sur un serveur) sur son bureau:
   • Si le profil est errant, il suffit de créer ce raccourci dans le sous-dossier bureau du profil de l'utilisateur stocké sur le serveur (une seule opération)
   • Si le profil est local, il faut créer ce raccourci dans tous les sous-dossiers bureau du profil de l'utilisateur cad sur tous les postes de travail qu'il utilise (donc n opérations, n étant égal au nombre de poste sur lesquels à travaillé l'utilisateur, il est concrètement quasi impossible de réaliser cette mise à jour)

II. Optimisation de l'utilisation des profils errants:

L'utilisation des profils errants peut / doit être associée avec 2 autres outils: le dossier All User centralisé, les scripts de connexion.

A. Le dossier profiles\All User centralisé:

• Le dossier All User défini les caractéristiques du profil qui sont attribuées à tous les utilisateurs de la machine (par ex la présence d'une icone de raccourci vers le dossier personnel de l'utilisateur sur son bureau, l'organisation du menu démarrer ...)
  
  
• La stratégie système (fichier ntconfig.pol) permet d'imposer l'importation des sous-dossiers bureau et menu démarrer depuis un serveur.
  
  
• De ce fait, si l'administrateur désire modifier le bureau ou le menu démarrer commun à tous les utilisateurs du réseau (par exemple pour rajouter un nouveau raccourci vers un programme qui vient d'être installé), il n'aura qu'à rajouter le raccourci sur le bureau et dans le menu démarrer du dossier All User du serveur (1 opération)
  
  
• Si le menu All User n'est pas centralisé, il lui faudra faire cette modification sur tous les postes de travail (n opérations, n étant égal au nombre de postes de travail du réseau, il est concrètement quasi impossible de réaliser cette mise à jour)

 

B. Les scripts d'ouverture de session:

Il s'agit d'un petit fichier batch (xxx.bat) qui se lance automatiquement lors de l'ouverture de session d'un utilisateur. Chaque utilisateur peut être affecté (ou non) d'un script.
Le script crée (entre autre) des lecteurs réseau vers les dossiers de travail auxquels l'utilisateur à accès:

Par exemple, lorsqu'un prof de Lettres responsable HTML ouvre une session, il doit pouvoir accéder simplement aux dossiers suivants: son dossier personnel, son dossier de matière (commun à tous les profs de Lettres) et le dossier de stockage des pages HTML de Lettres:

• Son script d'ouverture de session va donc créer 3 lecteurs réseaux vers ces 3 dossiers, ce qui facilitera leur accès par l'utilisateur.
• On peut ensuite compléter cette connexion par un raccourci sur le bureau.
• Cela permet également d'utiliser des partages cachés (Lettres$ par ex) pour que l'utilisateur soit connecté au partage mais que celui ci ne soit pas visible pour les autres utilisateurs.

En général l'administrateur crée un script par groupe d'utilisateur: tous les utilisateurs du groupe lancent le même script à l'ouverture de leur session => par ex tous les élèves auront les mêmes lecteurs réseaux connectés.

C. Combinaison des scripts et de All User centralisé:

Une utilisation judicieuse des lettres attribuées aux lecteurs réseaux par le script, associée à un dossier All User centralisé permet d'adapter automatiquement le profil de l'utilisateur à sa (ses)  fonction(s).
Ca sent l'usine à gaz !, prenons un exemple concret:

• Tous les scripts profs créent un lecteur réseau W: vers le dossier de matière (Lettres, SVT, Histoir-Geo... en fonction de la matière de l'utilisateur).
  Pour les élèves, le script connecte W:  au dossier travailClasses qui contient un dossier par classe.
  Pour les documentalistes, le script connecte W: au dossier travailCDI partagé entre tous les membres du groupe CDI.
  (notez que dans les 3 cas le lecteur connecté est W:, c'est stratégique pour la suite!)
  
  
• Le dossier All User centralisé contient un raccourci vers W: sur le bureau de l'utilisateur, quelque soit son groupe (prof, élève ou documentaliste)
  
  
• On obtient donc le résultat suivant en fonction du type d'utilisateur:
  • chaque prof qui ouvre une session dispose sur son bureau d'un raccourci vers le dossier qu'il partage avec ses collègues de matière
  • chaque élève dispose sur son bureau d'un raccourci vers le dossier travailClasse par lequel il peut accéder au sous-dossier de sa classe
  • chaque documentaliste dispose sur son bureau d'un raccourci vers le dossier travailCDI

Conclusion:

En résumé, pour l'administrateur d'un réseau pédagogique, si la gestion des profils errants semble au premier abord complexe voire superflue, elle s'avère vite une option alternative à la configuration manuelle de tous les profils locaux des postes lors du moindre changement dans les profils des utilisateurs.

L'utilisation de stratégies de profils adaptées (dossier All User centralisé et scripts de connexion) complète avantageusement les profils errants. A la condition d'être suffisament rigoureux, on peut donc aller relativement loin dans la personnalisation des environnement de travail des utilisateurs, sans avoir à créer des profils personnalisés individuels.

Pour conclure j'irais même jusqu'à poser la "contre-question": comment peut on utiliser autre chose que des profils errants dans un réseau pédagogique?