Problème de montage lecteur reseau avec %USERNAME% dans chemin [Résolu/Fermé]

Signaler
Messages postés
23
Date d'inscription
dimanche 6 janvier 2008
Statut
Membre
Dernière intervention
30 décembre 2013
-
Messages postés
23
Date d'inscription
dimanche 6 janvier 2008
Statut
Membre
Dernière intervention
30 décembre 2013
-
Bonjour,
Bon je ne sais pas pourquoi mon précédent post à disparu.
Je poste la réponse:

Bon, le choix d'utiliser un gpo + script vient du fait que c'est la première mise en place de montage de lecteurpar l'AD plutôt que manuellement pour mes 200 users et ce durant une migration de serveur de fichier.
Il a fallut que je récupère les mappages déja montés en dur par les users puis que je retraite tout ça pour affecter les nouveau partage sur le nouveau serveur de fichier.

- le réseau n'a pas bien fini de "monter", et le script se lance. (il faut vérifier un paramètre de GPO : "attendre le réseau blablabla...."
Mes autres lecteurs dans le même script se montent bien, donc le reseau fonctionne au momment du lancement du script.

- le login script doit être lancé pour des utilisateurs et non des machines (comprendre "contexte utilisateur" et non contexte "machine" : la GPO est-elle liée à une OU comprenant des utilisateurs ou des machines ?). Ce point est une très bonne piste.
Ma gpo UTILISATEUR, est lié à une OU contenant des utilisateurs et lance un script d'ouverture de session:
voici mon script:
net use * /delete /y
for /f "delims=" %%a in (\\serveurfic\montages\%USERNAME%.txt) do %%a

Où "\\serveurfic\montages" contient un fichier texte pour chaques utilisateurs, avec comme nom de fichier, le SamAccountname dans l'AD.

contenu d'un fichier txt:
net use W: \\serveurfic\xxx /PERSISTENT:YES
net use X: \\serveurfic\yyy /PERSISTENT:YES
net use Y: \\serveurfic\users\%USERNAME% /PERSISTENT:YES
Les lecteur W: et X: se montent bien, mais pas le Y: => "erreur type 55"




3 réponses

Messages postés
3011
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
12 novembre 2020
403
Effectivement j'ai aussi le souci avec le forum, je voies pas les posts à jour à tous les coups etc ...


%username% ne peut pas être interprété dans une boucle for à la volée ... c'est un problème connu dans batch ;)
(c'est dans le 'do' que la variable %username% ne sera pas interprétée).
Ce n'est pas un problème lié à ton script, mais du langage ... les variables ne sont pas interprétées à la volée dans des boucles/blocs avec des brackets.
Le bloc de commandes sera d'abord interprété avant les variables, d'où l'erreur.

-

Par contre mon avis est que : tu te mets des batons dans les roues avec une boucle pour parser un .txt pour chaque user et voir quels sont les points de montage à mapper....
C'est simplement pas comme cela qu'il faut procéder ...

Si demain je dois ajouter un partage, ou changer la lettre de lecteur de tous les utilisateurs ; je dois modifier chaque .txt pour tout le monde ...
=> Ingérable, inexploitable.

Ensuite pour l'appartenance à un groupe, comment dissocier tel ou tel groupe ?
(si la réponse est "j'ajoute une GPO avec un autre login script pour ce groupe" ; alors pourquoi s'ennuyer à inclure tous les mappages dans un seul login script ?)

Tu fais du login script à la NT4 ici.

Plusieurs solutions :

- tu n'utilises pas de boucle 'for' pour lister tes commandes 'net use'.
- tu utilises un autre langage qui sait mettre des variables à la volée dans des brackets : soit VBS , soit Powershell.

- Tu utilises les GPP (et là on fait de l'Active Directory) : je te conseille cette méthode.
Tu pourras aussi utiliser l'appartenance à des groupes pour donner des lecteurs mappés automatiquement sans toucher un quelconque fichier texte ou script ...


1
Merci

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

CCM 65492 internautes nous ont dit merci ce mois-ci

Messages postés
23
Date d'inscription
dimanche 6 janvier 2008
Statut
Membre
Dernière intervention
30 décembre 2013

Ne connaissant pas le VBS, j'aimerai rester sur du batch.

Pour powershell, Je pourrais me pencher sur un script de remplacement plus tard.

"- tu n'utilises pas de boucle 'for' pour lister tes commandes 'net use'. "
Comment puis-je lister les commande sans une boocle for?
Faut-il obligatoirement que je transforme les fichier txt en bat et que je lance le toto.bat à partir du script de login?

Je vais voir aussi du coté des gpp...
Ce qui me gène pour le moment avec les gpp c'est comment injecter tout mes partages existant dans une/des gpp(s) rapidement?
Si il faut scripter ça pour renseigner les gpp, je n'ai plus le temps pour le faire...
Messages postés
3011
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
12 novembre 2020
403
Comment puis-je lister les commande sans une boocle for?
Pourquoi lister depuis un fichier texte au départ ?

Faut-il obligatoirement que je transforme les fichier txt en bat et que je lance le toto.bat à partir du script de login?
Pourquoi avoir un fichier .bat pour un chaque user ?
Mais au moins tu enlèves la boucle ...

Globalement, pourquoi ne pas avoir le même loginscript pour tout le monde ? avec tes commandes net use dedans ? (je suppose la réponse 'car mes users ont des partages différents à cause des groupes auxquels ils appartiennent ... ce qui fait que ta méthode n'est pas adéquate, car tu ne check jamais l'appartenance à un groupe, c'est juste manuel ; si tu as oublié de modifier ton fichier texte, et même si le user a les accès grâce au groupe, il aura pas son point de montage...)

S'ils ont les mêmes shares, alors un seul et même script pour tout le monde et hop ...

-

S'ils ont accès à des shares différents car ils appartiennent à des groupes différents, il faut gérer l'appartenance (filtrage par groupe) au niveau de la GPO.

-

Ce qui me gène pour le moment avec les gpp c'est comment injecter tout mes partages existant dans une/des gpp(s) rapidement?
GPP = clic de souris, pas scriptable à ma connaissance.
Tout dépend de ce que tu entends par "partages existants" , c'est surtout comment tu gères les accès à ces partages ; si tu passes par des groupes alors c'est vite fait ... un gpp ça prend 5 clics par point de montage, tu en as pour 30 secondes pour chaque ...

Si tu gères tout au niveau user, il faut revoir ta gestion dans sa globalité.

Ex: un nouvel user vient d'arriver à la compta, tu dois modifier le partage Compta pour ajouter les droits à cet utilisateur = méthode "pas bien", car tu es obligé de modifier les ACLS.

Par contre si tu as un groupe "Users Compta" qui est paramétré pour avoir les droits d'accès au partage Compta ; tu ajoutes juste le nouvel user à ce groupe et il a automatiquement les droits, sans modifier les ACLS/partages. (méthode "bien").

Donc ce groupe "Users Compta" sera celui utilisé dans les GPPs pour monter le lecteur de la compta ... si tu n'appartiens pas à ce groupe, le lecteur n'est pas mappé ....


Par contre , faire des tests = on ne touche pas la production ; on fait des tests sur une OU particulière avec un user de test ....
Messages postés
23
Date d'inscription
dimanche 6 janvier 2008
Statut
Membre
Dernière intervention
30 décembre 2013

Ex: un nouvel user vient d'arriver à la compta, tu dois modifier le partage Compta pour ajouter les droits à cet utilisateur = méthode "pas bien", car tu es obligé de modifier les ACLS.

J'utilise le modèle agdlp mais à la différence que je met directement les users dans le Groupe de Domaine Local, plutôt qu'un groupe de sécurité. c'est très rapide de rajouter ou supprimer des users d'un Groupe de Domaine Local depuis l'AD.

Le problème, pour reprendre ton exemple, c'est que je peut avoir des user de la compta qui devront avoir accès à des partages particuliers, mais pas d'autre utilisateur du même service de la compta.
Donc si je devais suivre ta logique, avec le modele agdlp, il faudrait que je crée un groupe pour chaque partage et que je mette ce groupe membre du GDL.
à ce moment là je pourrais appliquer la GPP plus finement par partage.

Pour les tests, c'est ce que je fais déjà ;-)

Bon, suite à la limitation du batch, j'ai réussit à lancer un .bat par utilisateur en faisant un call "\\serverfic\%username%"
Donc j'ai changé mes point .txt par des .bat.

Je vais essayer de creuser la piste des gpp mais ca risque de me faire créer un groupe de securité en plus pour chaque partage.
Amoins qu'on puisse filtrer sur des groupe de domaine local???

En tout cas, merci pour ton aide.
Messages postés
3011
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
12 novembre 2020
403
Donc tu fais de l' ADLP ; mais comme tu n'avais pas abordé le sujet plutot, je faisais que des suppositions.

Il me semble que la portée (scope) du groupe lui importe peu lors de la création du GPP.
Toutefois, il m'avait semblé lire que certains GPP ne s'appliquaient pas lorsque des stations faisaient parti d'un Groupe de domaine Local, et que la GPP utilisait ce groupe.Il faut voir avec quelques tests pour confirmer ...

Dans les deux cas, Groupe de Domaine Local ou Groupe Global, il s'agit de groupe de sécurité. (même commentaire pour les groupes universels).
C'est la portée qui jouera dans des infras avec plusieurs domaines/forests.

-

Donc tu n'es pas obligé de créer un groupe global pour faire le target des GPPs, toutefois ça reste à confirmer, je n'ai pas d'infra de tests pour le faire.

-

Autre point, disons que tu as deux groupes : Compta_R (lecture) et Compta_W (pour écriture/lecture).
Dans ton GPP, tu peux mettre plusieurs conditions (ET/OU...):
Mapper Y: sur la ressource \\server\compta si user appartient à "Domaine\Compta_R"
OU
Mapper Y: sur la ressource \\server\compta si user appartient à "Domaine\Compta_W"

-

Autre possibilité : on fait le targetting (filtre) par rapport à la structure des OUs :
Mapper Y: sur la ressource \\server\compta si user appartient à l'OU "OU_Compta\OU_users\domaine"
Et ce peu importe le groupe ... par contre si le user n'est pas membre d'un des groupes de la compta, il aura pas le montage ... ça va foirer car pas de droits sur les datas. (Limitation : si tu gères ton arborescence basée sur les services ; ça ne s'applique pas à tout le monde donc ...)

-

Avec ta méthode, ce qui est dommage, c'est que l'appartenance à un groupe ne te permet pas automatiquement d'avoir le point de montage associé.
Tu es obligé de modifier tes logins scripts pour ajouter le lecteur mappé en plus de l'ajouter à un groupe. Alors qu'au final tu peux faire d'une pierre deux coups...

-

Autre question, si un user a uniquement l'accès juste en Lecture au partage, a t il réellement besoin d'avoir un lecteur mappé ?

-

Le modèle AGDLP, exemple :
J'ai 3 groupes, et on considère que les users de la compta ont accès à leur partage en ecriture quoiqu'il arrive.
DL_Compta_R
DL_Compta_W
GG_Users_Compta (qui est membre de DL_Compta_W).

Tu fais un GPP, qui target uniquement GG_Users_Compta pour ton lecteur mappé ....
Et pour en rajouter et aller plus loin, autant automatiser la gestion du groupe "GG_Users_Compta" ... j'aimerai y ajouter tous les users de l'OU compta dans ce groupe : on utilise ce qu'on appelle des "shadow groups" (script qui tourne et qui inspecte les users d'une OU et qui les ajoute au groupe ciblé ....)
ça ne marche uniquement si tu as une arborescence basée sur les services...
Tu créés juste le user dans l'OU Compta et il a automatiquement ses droits sur le serveur, et son lecteur mappé ... sans aucune autre intervention...

Limitations : plus on appartient à des groupes, plus le ticket Kerberos est gros, on peut arriver à avoir des problèmes d'authentification dans certains cas. (cherche TokenSize sur le net si tu es curieux)

-

Dernier point, pourquoi créer un partage pour chaque "service" ?
Alors qu'un seul dossier partagé serait suffisant, avec les sous-dossiers de chaque service en dessous (en cassant l'héritage pour garantir l'étanchéité) ....

Tu montes un seul lecteur pour tout le monde et basta ...
Tu montes un second lecteur pour le dossier user et hop ...

Tu mets en oeuvre "ABE" pour que les users ne voient pas les sous-dossiers auxquels ils n'ont pas accès et voila !


Messages postés
23
Date d'inscription
dimanche 6 janvier 2008
Statut
Membre
Dernière intervention
30 décembre 2013

Merci pour toutes ces infos!
Faudra que je creuse ces gpp!

Avec ta méthode, ce qui est dommage, c'est que l'appartenance à un groupe ne te permet pas automatiquement d'avoir le point de montage associé.
Tu es obligé de modifier tes logins scripts pour ajouter le lecteur mappé en plus de l'ajouter à un groupe. Alors qu'au final tu peux faire d'une pierre deux coups...

Je suis bien conscient de ce que ça impose, mais à l'usage cela reste au moins très simple à mettre en place en cas d'ajout de nouveau partages et à modifier. Et comme je ne serais pas le seul à administrer cela, il faut que je mette en place quelques chose d'abordable par des personnes qui sont moins familier que mois à l'AD et au scripts.

Tu montes un seul lecteur pour tout le monde et basta ...
Tu montes un second lecteur pour le dossier user et hop ...

Tu mets en oeuvre "ABE" pour que les users ne voient pas les sous-dossiers auxquels ils n'ont pas accès et voila !


J'avais pensé à ta solution, mais d'une part mes users sont plutôt flaimards, donc l'accès directe à leur partages est demandé. Et d'autre part j'avais lu que "ABE" avait tandance à faire ralentir du fais de la vérification des droits our la visibilité des répertoires.

Merci pour tout