Problème de montage lecteur reseau avec %NAME% dans chemin
Résolu lsda Messages postés 23 Date d'inscription Statut Membre Dernière intervention -
lsda Messages postés 23 Date d'inscription Statut Membre Dernière intervention - 30 déc. 2013 à 17:48
lsda Messages postés 23 Date d'inscription Statut Membre Dernière intervention - 30 déc. 2013 à 17:48
A voir également:
- Gpo lecteur mappé %name%
- Lecteur windows media - Télécharger - Lecture
- Lecteur pptx - Télécharger - Présentation
- Lecteur xml - Télécharger - Édition & Programmation
- Lecteur excel - Télécharger - Tableur
- Lecteur heic gratuit - Télécharger - Visionnage & Diaporama
3 réponses
Effectivement j'ai aussi le souci avec le forum, je voies pas les posts à jour à tous les coups etc ...
%name% 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 %name% 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 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 script pour ce groupe" ; alors pourquoi s'ennuyer à inclure tous les mappages dans un seul script ?)
Tu fais du 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 ...
%name% 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 %name% 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 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 script pour ce groupe" ; alors pourquoi s'ennuyer à inclure tous les mappages dans un seul script ?)
Tu fais du 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 ...
Ex: un nouvel 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 s dans le Groupe de Domaine Local, plutôt qu'un groupe de sécurité. c'est très rapide de rajouter ou supprimer des s d'un Groupe de Domaine Local depuis l'AD.
Le problème, pour reprendre ton exemple, c'est que je peut avoir des 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\%name%"
Donc j'ai changé mes point .txt par des .bat.
Je vais essayer de cre 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.
J'utilise le modèle agdlp mais à la différence que je met directement les s dans le Groupe de Domaine Local, plutôt qu'un groupe de sécurité. c'est très rapide de rajouter ou supprimer des s d'un Groupe de Domaine Local depuis l'AD.
Le problème, pour reprendre ton exemple, c'est que je peut avoir des 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\%name%"
Donc j'ai changé mes point .txt par des .bat.
Je vais essayer de cre 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.
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 appartient à "Domaine\Compta_R"
OU
Mapper Y: sur la ressource \\server\compta si 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 appartient à l'OU "OU_Compta\OU_s\domaine"
Et ce peu importe le groupe ... par contre si le 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 s 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 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 s de la compta ont accès à leur partage en ecriture quoiqu'il arrive.
DL_Compta_R
DL_Compta_W
GG_s_Compta (qui est membre de DL_Compta_W).
Tu fais un GPP, qui target uniquement GG_s_Compta pour ton lecteur mappé ....
Et pour en rajouter et aller plus loin, autant automatiser la gestion du groupe "GG_s_Compta" ... j'aimerai y ajouter tous les s de l'OU compta dans ce groupe : on utilise ce qu'on appelle des "shadow groups" (script qui tourne et qui inspecte les s 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 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 et hop ...
Tu mets en oeuvre "ABE" pour que les s ne voient pas les sous-dossiers auxquels ils n'ont pas accès et voila !
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 appartient à "Domaine\Compta_R"
OU
Mapper Y: sur la ressource \\server\compta si 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 appartient à l'OU "OU_Compta\OU_s\domaine"
Et ce peu importe le groupe ... par contre si le 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 s 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 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 s de la compta ont accès à leur partage en ecriture quoiqu'il arrive.
DL_Compta_R
DL_Compta_W
GG_s_Compta (qui est membre de DL_Compta_W).
Tu fais un GPP, qui target uniquement GG_s_Compta pour ton lecteur mappé ....
Et pour en rajouter et aller plus loin, autant automatiser la gestion du groupe "GG_s_Compta" ... j'aimerai y ajouter tous les s de l'OU compta dans ce groupe : on utilise ce qu'on appelle des "shadow groups" (script qui tourne et qui inspecte les s 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 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 et hop ...
Tu mets en oeuvre "ABE" pour que les s ne voient pas les sous-dossiers auxquels ils n'ont pas accès et voila !
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 s 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 à istrer 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 et hop ...
Tu mets en oeuvre "ABE" pour que les s 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 s 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
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 s 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 à istrer 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 et hop ...
Tu mets en oeuvre "ABE" pour que les s 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 s 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
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 ?
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...
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 ?
Pourquoi avoir un fichier .bat pour un chaque ?
Mais au moins tu enlèves la boucle ...
Globalement, pourquoi ne pas avoir le même script pour tout le monde ? avec tes commandes net use dedans ? (je suppose la réponse 'car mes s 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 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 es 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 , il faut revoir ta gestion dans sa globalité.
Ex: un nouvel 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 "s Compta" qui est paramétré pour avoir les droits d'accès au partage Compta ; tu ajoutes juste le nouvel à ce groupe et il a automatiquement les droits, sans modifier les ACLS/partages. (méthode "bien").
Donc ce groupe "s 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 de test ....