Bonjour,
 
Nous possédons, dans notre entreprise, une architecture client-serveur : XP/2003 Server.
Afin de satisfaire la demande d'un client, nous devons mettre en place plusieurs comptes utilisateurs différents (logins et mdp) mappés sur un seul et même profil itinérant (situé sur notre DC). J'ai bien indiqué le même chemin UNC pour accéder au profil sur tous les utilisateurs dans l'AD.
Tous les utilisateurs possèdent les droits en lecture/écriture sur le partage et sur les sécurités NTFS.
J'arrive à me loguer sans aucun soucis avec un compte utilisateur mais lorsque je me logue avec un autre, celui-ci retrouve une partie seulement du profil.
 
Les fichiers ou dossiers créés avec un autre compte sont bien là mais le fond d'écran est absent (fond bleu et il m'est impossible de le modifier), aucun thème n'est appliqué (le "thème modifié" est en place par contre il m'est possible de le changer), le menu contextuel proposant la création de nouveaux documents ne propose plus que 2 choix ("Nouveau dossier" ou "Nouveau raccourci" ) au lieu des 5 ou 6 choix habituellement disponible (comme si certaines applications n'étaient pas détectées (Bloc-notes, porte-documents, etc...).
Enfin, dernier point étrange mais pas des moindres, le clavier est en Qwerty... Et inutile de chercher à le passer en Azerty, ce dernier n'est tout bonnement pas installé (il faut aller le rajouter manuellement dans le panneau de configuration > options régionales et linguistiques, etc...).
 
Bref, si quelqu'un a déjà eu un problème similaire et sait comment le régler, je suis preneur.
De même, si quelqu'un a déjà eu à configurer ce type d'environnement (plus que curieux je vous l'accorde) où plusieurs comptes utilisateurs doivent pointer sur un seul et même profil itinérant... Parce que cette manipulation, bien que réalisable techniquement ne me paraît pas viable.
 
Cordialement,
 
YLK

Non ça ne doit pas marcher, le ntuser.dat étant locké sur la première session

Qu'entends tu par "locké" ? Je ne l'ai pas converti en ntuser.man, rien n'est donc verrouillé a priori...

quand ton profil est ouvert sur une machine, le fichier est utilisé et ne peut donc pas être utilisé par une autre machine

C'est justement là le soucis, même en fermant la session, et en ouvrant une autre, le problème est toujours le même...

C'est pas un profil obligatoire du coup où à la fin tu renommes le ntuser.dat en ntuser.man ?

En réalité, j'ai déjà testé les deux... Que le profil soit obligatoire ou non (ntuser.dat ou ntuser.man) le même problème survient.
Et ce, même si je me logue avec un compte puis le déconnecte avant de loguer un second...

j'apporte une précision.
Tu peux ouvrir un profil itinérant sur X pc... je le fait actuellement.
 
Les fichiers ne sont pas lockés... bizarre ce que dit YLK.
Prenons l'exemple : tu as un utilisateur toto itinérant.
 
Toto se connecte pour la premier fois sur PC 1. Le systeme va aller cherché si le profil existe sur le serveur. Si il existe, il copie le fichier en local sur PC1 sinon il en créait un dossier toto sur le serveur et en local.
 
Si toto s'est déjà connecté sur PC1, il va regardé si des fichiers nouveaux existent sur le serveur. Si il y en, alors il les récupères.
 
Par contre tu vas être confronté aux problèmes suivant :  
Si l'utilisateur toto paramètre le clavier en Azerty sur PC 1, il ferme sa session, les paramètres se copient sur le serveur.
Si aprés l'utilisateur toto du PC2 (qui a le clavier par exemple en qwerty), ferme sa session, alors il va écraser le paramètre du PC1...  
 
Donc en fait pour paramétré tout le monde de la même façon alors il faut faire fermer, la session de tout les utilisateurs du même nom. Ouvrir une seule session est changé les paramètres.
 
Mais par expérience, j'ai abandonné l'idée du profil itinérant pour le compte utilisateur de l'atelier par exemple et travail plutot par GPO.

PsYKrO_fred, je crois que tu ne semble pas avoir saisi le fond du problème.
Le but n'est pas de savoir s'il est possible d'ouvrir un même profil itinérant sur plusieurs PC via le même compte utilisateur... Pour ça, j'étais déjà au courant.
Ce que je cherche à faire moi c'est ouvrir un même profil itinérant sur différents postes via plusieurs comptes utilisateurs différents.
En fait, plusieurs comptes de l'AD ont pour chemin de profil le même chemin UNC pointant vers un unique dossier de profil itinérant.
Et là, ça se complique...
 
Mais merci quand même de ton intervention.

C'est qu'il y a une erreur lors de la création du profil alors, tu fais quoi comme manip ?

je penses pas que cela soit possible et excuse moi de sortir du contexte mais j'en vois pas l’intérêt...

@ akizan :

Encore une fois, techniquement c'est possible (il suffit d'indiquer le même chemin de profil pour tous les users) mais je te rejoints sur le fait qu'il n'y a pas de réel intérêt (mis à part un gain de place sur le serveur et une maintenance censée être facilitée peut-être) mais comme on dit : le client est roi, alors on ne cherche pas le pourquoi du comment, et on tente de s'exécuter, dans la mesure du possible...

@ gregsk8 :
 
Pour créer le profil, au premier utilisateur créé dans l'AD, je spécifie le chemin de profil sur le serveur (chemin UNC de type \\FQDN_du_serveur\Partage\Profil_Unique).
A la première ouverture de session, le profil "Profil_Unique" est créé sur le serveur.
Pour tous les autres utilisateurs, il suffit d'entrer le même chemin de profil lors de la création de leur compte dans l'AD et bien entendu, veiller à leur donner les droits en lecture/écriture sur le dossier du profil (par simplicité, j'ai même accordé un contrôle total à tous les utilisateurs pointant sur le profil unique).
Bref, l'ouverture de session fonctionne à merveille avec tous les comptes mais seul le premier compte bénéficie d'une interface "complète" les autres voient leur interface amputée des quelques gênes citées au premier post...

Des idées ?

Ok je comprends.
en fait, faudrait trouver l'argument technique sur le fait que ça ne peut  
pas fonctionner car ce n'est pas prévu pour cette utilisation.
 
sinon pour faire avancer le truc, sur un PC qui a le profil amputé, y a t il des messages spécifique dans l'event viewer ?
as tu regardé la taille du NTUSER.DAT pour vérifier si la copie de la ruche se faisait à 100% ou pas ? (en comparant avec le PC qui a un profil ok)
Car si le fichier fait la bonne taille, y a un autre souci.
 
ou mieux, tu fais un export des 2 ruches des 2 PC et tu fais un compare de l'ensemble voir ce que ça donne

Pas de message d'erreur particulier dans les logs, le NTUSER.DAT est forcément de taille égale (puisque rapatrié du même profil sur le serveur). Une comparaison des registres serait trop longue et minutieuse et ne me servirait qu'à une chose : Prouver que cette pratique ne se fait pas.
 
Bref, je vous remercie tous de vos avis qui me conforte dans mon idée ; cette méthode ne s'utilise pas et le client se pliera aux exigences techniques qu'on lui soumettra (à savoir un profil itinérant propre à chaque compte utilisateur).
 

bah ok il est de la même taille, dans ce cas, tu donnes l'exemple du fond d'écran qui ne se charge pas.
Sur le PC amputé, si tu regardes la clé de registre Wallpaper, la chaine de celui-ci doit donc être correcte (en théorie) par rapport au PC qui se charge bien.
- Si la clé est correcte et que le wallpaper n'est pas chargé = problème intéressant.
- Si la clé n'est pas correcte, il y a un problème de chargement de ruche !?
 
Rhooo Comparaison = winmerge, ça prend 2 minutes maxi !

Les chaînes seront forcément différentes puisque l'un charge le fond l'autre pas (et après vérification, il s'avère même que l'un possède la chaîne, l'autre ne l'a tout bonnement pas...).
Bref, il est évident que la ruche se charge mal, cela ne me donne pas la solution au fait qu'elle ne se charge pas (ou pas complètement tout du moins).

Et à dire vrai, je préfère autant passer par les voies normales de l'utilisation d'un profil itinérant (un profil = un utilisateur) que de perdre un temps fou à configurer tant bien que mal quelque chose qui n'a même pas été développé pour fonctionner comme ça (et qui pourrait donc aboutir, après des chemins tortueux et du bricolage douteux, à des résultats peu stables)...

Des outils de comparaison, j'en connais des tonnes, open source ou pas d'ailleurs, mais là, le temps n'est plus à leur utilisation.

Je te remercies encore akizan du mal que tu te donnes pour essayer de solutionner ce problème mais je pense qu'il se pose car cette utilisation des profils itinérants n'a tout simplement pas été prévue et ne fonctionnera donc pas.
Je me suis désormais résigné à simplement exposer ce fait à mon client et parfois la meilleure des solutions, c'est encore d'expliquer (en argumentant) en quoi il est bon de procéder autrement pour mettre en place une solution.

Bonjour dans un domaine Windows tout objet de l'annuaire est associé à un SID identifiant unique. C'est également le cas de certain fichier du profil de l'utilisateur.  
Avec un profil itnérant certain élément comme le registre utilisateur est associé aux SID par les permissions NTFS positionné sur la notion de propriétaire. Un seul compte avec un SID spécifique peux être propriétaire d'un profil donc impssible d'utiliser les profils itinérants pour plusieurs utilisateurs avec login différent.
Le profil itinérant permet à un même compte utilisateur d'utiliser plusieurs poste différent.
Si tu veux avoir les mêmes raccourcis sur plusieurs poste fait un script d'ouverture de session qui les copie.
Si tu veux uniformiser d'autre paramètre il faut utiliser les stratégies de groupes.
 

Merci pour ta réponse très complète et détaillée phil255.
J'ai cependant du nouveau. Un de mes collègues technicien a eu la brillante idée de tester de reloguer un compte non-fonctionnel en le passant dans le groupe "Administrateurs du Domaine" au préalable.
Miracle, cela fonctionne à merveille. Chaque compte (avec login différent) faisant partie du groupe "Admins du Domaine" et pointant vers un même chemin de profil arrive à charger parfaitement le profil itinérant... Et ce, que le profil soit chargé par un autre compte ouvert sur une autre machine ou pas.
C'est donc que la manipulation est réalisable...
Cependant, un paramètre (des accès insuffisants en écriture sur certains fichiers du profil peut-être) doit empêcher cette manipulation à de simples utilisateurs du domaine.
 
De nouvelles idées ?

Tu va quand même pas mettre tes comptes utilisateurs en ADMIN du DOMAINE ???!!!
Même toi en tant qu'utilisateur tu devrai avoir un compte utilisateur et un compte d'administration pour les opérations spécifiques.
Oui tu n'as plus de problème de droit en mettant admin du domaine puisqu'il a tous les droits sur le domaine, il a forcément les droits sur les fichiers système et du registre utilisateur.
 
Après cela ce n'est plus la peine de vouloir faire de la sécu.

Je reprends vu que visiblement tu n'as pas saisi ma demande...

Comme je le disais, nous avons procédé à un TEST (j'ai pourtant clairement utilisé ce mot dans mon message non ?) pour vérifier si les profils utilisateurs étaient, comme chaque objet de l'AD, associé à un SID unique... Si tel était le cas, admin ou pas, plusieurs comptes sur un même profil auraient du aboutir au même résultat. Or, il s'avère que cela fonctionne. On en vient donc à la conclusion que c'est au niveau d'un accès sur le serveur que se fait la restriction pour les utilisateurs (vu que les admins ne sont pas soumis à cette restriction et que cela fonctionne).
Il n'est donc aucunement question d'attribuer des droits admins (quels qu'ils soient d'ailleurs...) aux utilisateurs de l'entreprise...
Si tu préfère, notre but était d'éliminer certaines pistes et d'affiner (ou de mieux cibler) la source du blocage.
Encore une fois, nous procédons pour le moment à des essais en environnement virtuel et nous ne réalisons pas ces essais sans filet, en prod...

Alors des pistes qui pourraient expliquer quel est exactement le noeud du problème ?

La différence c'est dans les droits ACL(onglet sécurité ) dans les doc, cela marche avec admin par ce que c'est un compte qui a des entrée spécifique. Mais le profil itinérant c'est pour récupérer le profil d'un utilisateur même s'il change d'ordi. Ce n'est pas prévue et ce n'est pas propre comme utilisation.  
 Regarde sur les ntuser.* entre autre

Compare les droits dans les sécurité.

Je n'ai pas eu le temps de finir ce matin,
Dans un profil :
- les héritages sont cassés à plusieurs endroits
- le champ propriétaire qui est un des éléments de l'onglet sécurité à son importance, mais il ne peut y avoir qu'un propriétaire pour un élément, ce n'est pas une liste.
- cela marche avec le compte administrateur car il a déja les bonnes entrées.
 
Enfin si tu veux quand même tenter ta chance et en dehors du fait que ce n'est pas propre, n'oublie pas que le profil  est copié du poste vers le serveur lors de fermeture de session, je ne testerai pas l'option ou tout le monde ferme sa session en même temps.
 
Si tu veux que tout les utilisateurs ai le même raccourci fait un script et une copie de fichier.
Si tu veux garantir que des clé de registre sont bien positionnées utilise une GPO.
 
Je ne vois pas trop le résultat que tu veux obtenir

 
voila voila
Maintenant c'est vrai que tu apportes des arguments concrets sur pourquoi c'est naze de faire comme ça

@ akizan :
 

 
Tout est dit... Et si tu avais été plus loin dans ta lecture du sujet plutôt que de t'arrêter aux seul post où je te réponds, tu t’apercevrais qu'après maints efforts pour tenter de satisfaire le client (car pour info, sache que c'est le but malgré tout, à la base), j'en suis venu à conclure que cette manipulation serait irréalisable et que j'exposerai simplement ce fait au client (en argumentant clairement, si si je t'assure, je sais faire...).
 
Mais bref, depuis (encore une fois, c'est dans la suite du sujet que tu ne semble pas avoir lu), nous avons trouvé de nouvelles pistes pour dénouer la situation et il semblerait même que ce qui me paraissait irréalisable il y a peu soit tout à fait faisable.
 
@ pill255 :
 
Tu étais sur une bonne piste. J'ai moi aussi pensé tout de suite aux ACL sur les sécurités NTFS (ainsi qu'à la notion de propriété du dossier, etc...). C'est donc ce que je me suis empressé de vérifier et de modifier en conséquence (sur le dossier parent avec propagation des héritages et droits de propriété sur les conteneurs et objets enfants).
Bref, tout était dans les conditions optimales pour fonctionner... Mais non, ça ne marchait toujours pas.
 
En réalité, j'ai trouvé LA solution fonctionnelle (je confirme donc que cela fonctionne à merveille et est tout à fait dans les attributions de Win Server 2003).
 
En fait, suite à la création d'un utilisateur dans l'AD (sans lui avoir spécifié de chemin de profil itinérant pour le moment), il faut ouvrir ce compte "modèle" sur un poste client, configurer l'environnement comme on le souhaite, le fermer et ouvrir une session Admin (sur ce même poste). Il suffit ensuite de copier le profil local de l'utilisateur sur un partage réseau (autorisé en contrôle total pour tout le monde) préalablement créé sur un serveur. Il est important, lors de la copie, de bien spécifier l'autorisation d'utilisation pour tout le monde.
Le profil sera donc maintenant sur le serveur avec toutes les sécurités correctement paramétrées. Il faut ensuite rendre le profil obligatoire en modifiant le ntuser.dat en ntuser.man (ce qui est préférable lorsque plusieurs utilisateurs utilisent le même profil, sinon, le dernier à se déloguer sauvegardera sa propre configuration du profil et pourrait donc gêner son utilisation par les autres utilisateurs).
Il suffira ensuite d'aller dans l'AD et de spécifier le chemin UNC de ce profil dans l'onglet "Profil" de tous les utilisateurs devant utiliser ce profil. Et voilà, ça fonctionne !
 
En réalité, en procédant de la sorte, le compte administrateur utilisé lors de la copie du profil vers le serveur sera utilisé pour la notion de propriété du dossier (et ses sous-dossiers et fichiers enfants) et donc chaque utilisateur pourra ouvrir le profil sans soucis de droits sur la propriété du profil.
 
Bref, le problème est désormais résolu, après de nombreuses explorations de pistes fournies par les participants à ce sujet ou par mon collègue technicien (merci Manu) !
Merci donc à vous, merci à lui (sans qui je n'aurais pas pu mettre en place cette solution) et j'espère que ce sujet servira à d'autres techniciens et administrateurs pour exploiter toutes les possibilités que nous offrent nos architectures AD !
 
 
P.S : phil255, pour info, il est peu probable que tous les utilisateurs arrivent à se déloguer en même temps (même en essayant de le faire volontairement, un ordre de clôture des sessions est automatiquement appliqué au niveau du serveur, même si elle est invisible pour les utilisateurs) et donc peu probable qu'une sauvegarde de plusieurs profils se fasse en même temps... Ceci dit, en laissant un profil non verrouillé (ntuser.dat) il est en effet gênant que le dernier user à se déloguer sauvegarde sa config au dépend des configs des autres users... D'où l'intérêt (l'obligation ?) d'utiliser les profils obligatoires (ntuser.man).
 
Encore merci à tous !
 
 
EnJoY !

je répondais à phil255...

Autant pour moi dans ce cas.

Je comprend que le client est roi, j'ai passé 12 ans en société de service et voila 1 an que je suis sur un poste fixe en entreprise,
mais le client ne sait pas tout,  
Si on accepte tout sans rien dire on a pas fait notre boulot de conseil, et après on se retrouve dans des situations ou on ne peut plus faire de migration car on est dans un cas hors norme (ce sera de toute facon de ta faute puisque tu as laissé faire).
C'est un peu le pb du monde Windows, c'est le monde ou chacun réinvente une utilisation tel qu'elle n'a pas été prévue.
C'est pour cela que je dois me casser la tête avec des éditeurs d'appli sur pourquoi il doit pas mettre ses fichiers d'ini dans le dossier Windows, pourkoi mettre tout les comptes admin du dom pour faire tourner une appli c'est ridicule. Mais comme dit mon fournisseur : oui mais ca marche, et la il a pas tord.
 
Je suis content pour toi que tu ai pu trouver une solution a cette requète. J'espère juste qu'il ne te demandera pas de te jeter sous un train, car la tu seras bien obliger de lui dire que son idée est stupide.
 
Pour moi conseiller de ne pas faire un truc hors norme ca fait aussi parti du boulot

Comme je l'ai dit plus haut, notre boulot consiste en effet à prévenir le client lorsqu'il demande la mise en place d'une solution irréalisable.
Mais je suis technicien avant tout, et lorsqu'on me pose une colle sur quelque chose dont j'ignore la faisabilité, j'aime relever le défi et me pencher sur la question avant de répondre que ce n'est pas faisable.
 
Après quelques (longues) recherches et tests, il s'avère que cette action est réalisable et même totalement dans le cadre de ce qu'autorise nativement Windows Server 2003 (si tu n'y crois toujours pas, va faire un tour ici).
La mise en place de cette solution ne relève donc pas du "bidouillage" hors-norme et est donc tout à fait stable et viable, ce qui n'est pas le cas du projet de se jeter sous un train...
 
Apprendre un peu plus tous les jours dans mon métier, voilà ce qui motive mes choix. Et le temps perdu à résoudre un problème lorsqu'il se pose pour la première fois me permettra d'en gagner s'il se repose à l'avenir...
 
Après, à chacun sa vision du métier et du travail bien fait.
 
A bon entendeur...

Ok j'ai compris ce que tu as fait,
merci pour le lien

Pas de soucis.