none
Mapper un lecteur réseau en fonction d'un groupe AD RRS feed

  • Question

  • Bonjour,

    J'ai trouvé ce script pour mapper des lecteurs réseaux en fonction des groupe AD d'un utilisateur.

    Cela fonctionne très bien mais je voudrais pouvoir affecter la lettre du lecteur réseau disponible automatiquement (remplacer/modifier la partie "Map network drives" dans le script plus bas

    j'ai trouvé un truc comme ca qui affecte la lettre d'un lecteur reseau disponible mais je suis novice en powershell et je pense que des Pro, spécialiste pourrait m'aider

            
    *************************************************************************
    $share
    ="\\Server\Share"$drvlist=(Get-PSDrive -PSProvider filesystem).Name Foreach ($drvletter in "DEFGHIJKLMNOPQRSTUVWXYZ".ToCharArray()) { If ($drvlist -notcontains $drvletter) { $drv=New-PSDrive -PSProvider filesystem -Name $drvletter -Root $sharebreak } }
    *************************************************************************

    SCRIPT CI-DESSOUS FONCTIONNANT BIEN : 

    # ====================================================
    # Queries user account in AD for user group membership
    # ====================================================

    $strName = $env:username

    function get-GroupMembership($DNName,$cGroup){

    $strFilter = "(&(objectCategory=User)(samAccountName=$strName))"

    $objSearcher = New-Object System.DirectoryServices.DirectorySearcher
    $objSearcher.Filter = $strFilter

    $objPath = $objSearcher.FindOne()
    $objUser = $objPath.GetDirectoryEntry()
    $DN = $objUser.distinguishedName

    $strGrpFilter = "(&(objectCategory=group)(name=$cGroup))"
    $objGrpSearcher = New-Object System.DirectoryServices.DirectorySearcher
    $objGrpSearcher.Filter = $strGrpFilter

    $objGrpPath = $objGrpSearcher.FindOne()

    If (!($objGrpPath -eq $Null)){

    $objGrp = $objGrpPath.GetDirectoryEntry()

    $grpDN = $objGrp.distinguishedName
    $ADVal = [ADSI]"LDAP://$DN"

    if ($ADVal.memberOf.Value -eq $grpDN){
    $returnVal = 1
    return $returnVal = 1
    }else{
    $returnVal = 0
    return $returnVal = 0

    }

    }else{
    $returnVal = 0
    return $returnVal = 0

    }

    }

     

    # ====================================================
    # Map network drives
    # ====================================================


    $result = get-groupMembership $strName "nom_du_groupe_ad"
    if ($result -eq '1') {
    $(New-Object -ComObject WScript.Network).RemoveNetworkDrive("H:");
    $(New-Object -ComObject WScript.Network).MapNetworkDrive("H:", "\\monserveur\monpartage");
    }


    $result = get-groupMembership $strName "nom_du_groupe_ad"
    if ($result -eq '1') {
    $(New-Object -ComObject WScript.Network).RemoveNetworkDrive("L:");
    $(New-Object -ComObject WScript.Network).MapNetworkDrive("L:", "\\monserveur\monpartage");
    }

    ====================================================
    ====================================================

    mercredi 8 septembre 2021 14:10

Toutes les réponses

  • Bonjour,

    Au risque de vous décevoir, cette méthode n'est pas la plus optimisée. Si l'objectif est juste de mapper des lecteur réseau en fonction de groupe AD, je vous recommande des GPO avec la partie préférence. 

    Vous avez les explications ici :

    Using Group Policy Preferences to Map Drives Based on Group Membership - Microsoft Tech Community


    Merci de marquer comme reponses les interventions qui vous ont ete utile.

    mercredi 8 septembre 2021 16:48
  • Le script, c'est une vieille méthode, mais ca marche encore. Les GPO sont une autre méthode plus à la mode.

    Par contre le fait d'affecter une lettre aléatoire peut poser problème. Si certains utilisateurs mettre des liens dans des fichiers excel (par exemple) sur d'autres fichier et que le lien utilise le chemin mappé et que chaque personne à une autre lettre, il peut y avoir quelques désagrément...


    mercredi 8 septembre 2021 19:30
  • merci de votre réponse, j'ai deja utilisé cette methode mais je ne suis pas convaincu car en sélectionnant "utiliser le 1re disponible" lettre du lecteur, il ecrase les lecteur deja mappé sur la session de l'utilisateur.

    de plus, je souhaite que les lecteurs reseau mappé utilisent les 1re lettres disponibles et que tous les lecteurs se suivent au niveau de la nomenclature (F,G,H,I.....)

    mercredi 8 septembre 2021 19:31
  • Oui tout a fait, c'est mon cas de figure :(
    mercredi 8 septembre 2021 21:39
  • bonjour Azalee78

    comme l'on écrit Philippe Barth et Matteu31400, le mapping par logonscript est une méthode obsolète,qui tombe en désuétude, et ne devrait plus être utilisée.

    J'apporte un élément en plus : Un logonScript s'exécute au Logon (que ce soit un logonscript attaché au compte utilisateur ou un logonscript dans une GPO) et seulement là. Mise à jour d'un logonscript, ... il faut attendre le prochain logon pour voir le résultat. GPO ... c'est au prochain rafraichissement de la GPO (je ne parle pas des GPOs avec logonscript, cette partie ne s'exécute qu'au logon même si d'autres parties sont rafraichies).

    Au final : tu mets en place/corriges quelque chose, il y aura toujours des utilisateurs qui râleront (à juste titre) car ils ne verront pas ce que tu as fait (ils n'ont pas encore ré-ouvert leur session et cela les emm...), il y en aura d'autres qui ne savent pas la différence entre fermer et verrouiller une session. Bref des incidents (qui en fait n'en sont pas vraiment, mais qu'il faut traiter), et une insatisfaction perçue (même si ce n'est pas une insatisfaction justifiée) est une insatisfaction dont on te tiendra rigueur. 

    Avec ce que présenté (GPO mapping lecteur réseau avec ciblage client), pas ce soucis. Les GPOs se rafraichissent toutes les 90 min plus ou moins 30 minutes par défaut.

    Il y a cependant une autre voie qui permettrait de s'affranchir du pb évoqué par Philippe Barth concernant les lettres de lecteur et qui n'a pas été évoquée : Mise en oeuvre d'un DFS-N de domaine avec de l'ABE (Acess Based Enumeration)

    Je passe les détails techniques (il y a des tonnes de tuto sur le net facile à trouver, y compris en français).

    Je ne vais décrire que le principe.

    • DFS-N avec x partages DFS.
    • Mappage de la racine DFS - et uniquement la racine DFS - via GPO. Tout le monde la même lettre de lecteur.Mais avec l'ABE, tout le monde ne voit pas la même chose dans cette racine DFS. Chacun ne voit que ce auquel  il a accès. Untel peut voir que 10 répertoires partagés et publiés dans le DFS, et untel peut en voir 20 car il est membre de plus de groupes donnant l'accès.

    Fini les users avec xx lettres de lecteur mappés. Un seul et unique pour tous. Fini le casse-tête pour trouver une lettre de lecteur qui ne soit pas déjà prise, il n'y en a qu'une.

    Avantage de cette solution :

    • Pas vraiment difficile à mettre en oeuvre, je dirais même facile (la seule réelle difficulté est la réflexion à se faire sur l'organisation DFS-N).
    • By-design plus le pb évoqué par Philippe concernant une lettre de lecteur identique mais un contenu différent.
    • Amélioration de la tolérance de panne (si implémentation de DFS-R) et dans certains cas de la qualité de service (avec DFS-R, si les liens WANs ne sont pas terrible et que le placement des serveurs est judicieux bien entendu)
    • coût : pas plus cher en matériel si pas de tolérance de panne (on s'appuie sur l'existant).

    Nota : DFS-N est un espace de publication (il faut le voir comme ça), les données restent là où elles sont actuellement sur le ou les serveurs de fichiers. Les utilisateurs accèdent cependant à ces données partagées non pas par \\serveur\partage mais par \\MonDomaine\dfsRoot\

    • Impact sur les utilisateurs : néant. Cela ne changent rien pour eux.

    Je t'engage donc à lire quelques tuto sur la mise en oeuvre d'un DFS-N afin de te faire une idée de la chose si tu ne connais pas.

    Cordialement

    Olivier

    jeudi 9 septembre 2021 05:41
  • comme l'on écrit Philippe Barth et Matteu31400, le mapping par logonscript est une méthode obsolète,qui tombe en désuétude, et ne devrait plus être utilisée.

    J'ai jamais dit que c'est  obsolète, mais que c'est ancien. La roue est une invention ancienne, elle n'est pas obsolète pour autant.

    Si tu as des scripts en place et qu'il fonctionne, il n'y a pas de raison de perdre du temps à tout changer pour des GPO.

    c'est au prochain rafraichissement de la GPO (je ne parle pas des GPOs avec logonscript, cette partie ne s'exécute qu'au logon même si d'autres parties sont rafraichies).

    Selon les paramètres dans la GPO, il faut tout de même fermer et rouvrir la session. Si on te demande quand cela va s'appliquer avec une GPO, c'est dans les deux heures. Pour un script tu es en mesure de donner le moment précis ou il sera exécuté : à l'ouverture de session. Il y a des avantages et des inconvénients à chacun... 


    jeudi 9 septembre 2021 19:07
  • Bonjour,

    Il est préférable d'utiliser GPO pour le lecteur MAP au lieu de scripts pour mieux contrôler les paramètres et faciliter le dépannage.
    Je voudrais suggérer de cocher l'option "UTILISER" si elle remplace d'autres lettres de lecteur, vous pouvez également utiliser les lettres de pilote de l'ordre décroissant comme X, Y, Z

    Veuillez consulter l'article Microsoft ci-dessous basé sur le GPO du lecteur MAP.
    https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/using-group-policy-preferences-to-map-drives-based-on-group/ba-p/395918

    Si la réponse vous a été utile, n'oubliez pas de voter pour ou d'accepter comme réponse.
    lundi 13 septembre 2021 15:41
  • Afin de compléter la réponse déjà très complète d'olivier., j'ajouterai :

    Impact sur les utilisateurs : néant. Cela ne changent rien pour eux.

    Petit note d'attention pour les néophytes du DFS : il y a un impact non-négligeable pour les utilisateurs. tout d'abord, vous passerez d'un mapping multi-lecteur à un mapping mono-lecteur. Ensuite, le chemin d'accès sera différent (on passe de \\serveur\Share à \\domain\dfs). Ces modifications ont un impact sur les documents existants ainsi que sur les applications : les liens (symbolique ou explicite) qui font référence à l'ancienne nomenclature (\\serveur\share\fichier, ou lettre:\chemin\fichier) ne seront plus valide... Et cela peut représenter un énorme travail de fond pour vos utilisateurs de les mettre à jour ! 

    En revanche, une fois ce travail fait, vous y gagnez sur le long terme - en particulier, lorsqu'il sera temps de changer le serveur pour une migration ou si vous souhaitez mettre en place une réplication de fichiers entre sites.


    mardi 14 septembre 2021 06:19
  • Excellent complément Loic !

    Concernant les 3 dernières lignes, c'est effectivement le gros intérêt : Pouvoir faire des tâches administratives telles que changer les données de serveurs, déplacer les données d'un serveur à un autre emplacement ... sans impact utilisateur (le path DFS ne change pas). 

    Attention à ne pas confondre DFS de domaine (ce dont on parle) et DFS de serveur (intérêt très limité).

    Concernant l'impact utilisateur lors de l'implémentation. On peut diminuer celui-ci avec une communication utilisateur, très en avance. Un tableau présentant PathShareActuel ==> PathDFScible peut permettre à des utilisateurs de mettre à jour leurs documents (ex. fichier excel avec un lien vers \\serveur\share\fichier deviendra \\Domain\DFS\Share\fichier). Il est évident que dans les grandes organisations cela ne se fera pas sans impact (il y aura toujours un fichier ou un autre dont les liens externes n'auront pas été modifiés).

    Après, dans le run, Les liens DFS restent une constante, même si les fichiers sont physiquement déplacés sur un autre serveur.

    Enfin dernier point concernant l'arborescence des partages  DFS. Elle doit être soigneusement réfléchit, sous peine de devoir la changer par la suite et avoir les mêmes impacts que lors de l'implémentation ou lors de la migration des données avec des partages classiques.

    Le mot clé pour la réussite d'un tel projet, s'il n'est pas difficile à mettre en œuvre techniquement, est "Préparation". Contrairement à ce que je dis souvent 80% de préparation, 20% de réalisation, là on pourrait dire 95% de préparation - com' comprise - et 5% de réalisation.

    cordialement

    Olivier

    mardi 14 septembre 2021 08:21
  • Bonjour,

    J'ai reçu un mail avec une réponse que je ne vois plus affichée mais qui indiquer qu'un -or ne fonctionnait pas dans cette ligne de code :

    elseif ($Groups -contains "DOMAIN\groupead_01" -or "DOMAIN\groupead_05")

    C'est tout à fait normal.

    Il faut la remplacer par celle ci d'un point de vue syntaxe powershell

    elseif ($Groups -contains "DOMAIN\groupead_01" -or $Groups -contains "DOMAIN\groupead_05")



    Merci de marquer comme reponses les interventions qui vous ont ete utile.

    lundi 20 septembre 2021 19:30
  • Bonjour,

    Voici ma proposition

    try
    {
        # Récupère la liste des groupes AD (appartenance directe) de l'utilisateur courant
        $AdGroups = (New-Object System.DirectoryServices.DirectorySearcher("(&(objectCategory=User)(samAccountName=$($env:username)))")).FindOne().GetDirectoryEntry().memberOf -replace '^CN=([^,]+).+$','$1' | Sort-Object
    }
    catch
    {
        Exit 100
    }
    
    
    $shareGroupName = "Mon Groupe AD"
    $sharePath = "\\Server\Share"
    $shareLetter = "DEFGHIJKLMNOPQRSTUVWXYZ"
    
    # Si le chemin n'est pas déjà mappé et que l'utilisateur appartient au groupe
    if ((Get-SMBMapping).RemotePath -notcontains $sharePath -and $AdGroups -contains $shareGroupName)
    {
        # Liste les lecteurs utilisés, ajout des lecteurs mappés pouvant être "Unavailable" (non visible par Get-PSDrive ou Win32_LogicalDisk)
        $UsedLetters = @(Get-PSDrive -PSProvider FileSystem | ForEach-Object {$_.Name + ":"}) + @((Get-SmbMapping).LocalPath)
        
        # Pour chaque lettre permise
        foreach($letter in ($shareLetter.ToCharArray()))
        {
            # Si la lettre n'est pas utilisée
            if ($UsedLetters -notcontains "${letter}:")
            {
                Write-Host "${letter}: -> $shareName" -NoNewline
                try
                {
                    # Connection du lecteur
                    $null = New-PSDrive -PSProvider FileSystem -Name $letter -Root $sharePath -Persist -Scope Global
                    Write-Host "`tOK" -ForegroundColor Green
                }
                catch
                {
                    Write-Host "`tKO" -ForegroundColor Red
                }
                # Quitte la boucle
                break
            }
        }
    }

    jeudi 7 octobre 2021 07:31
  • @ericlm128

    Un script, même en PS, n'est pas la solution la plus adaptée pour map des lecteurs réseaux.

    Sinon dans le script ci-dessus qq bricoles :

    • Dommage d'avoir collé des variables "Hard-coded" au milieu du code ($ShareGroupName et consorts), à remonter en début de script.
    • Pô bon d'avoir utilisé Write-Host, .... pour un script sensé s'exécuter via un logon Script, donc pas en mode interactif. Il n'y a pas de Host dans ce cas, préférer Write-Output, Write-Warning, Write-Error, ... si on veut loguer dans un fichier bien entendu, sinon aucun intérêt.

    cordialement

    Olivier

    jeudi 7 octobre 2021 10:19
  • Bien sur ce script est un jet (qui est fonctionnel) pour répondre à la demande de Azalee78, je ne pense pas en avoir vu d'autre ?

    Je pense que l'emplacement des variables et l'usage des Write-Host sont parfait pour qu'il puisse le tester et ajouter d'autres lecteurs à mapper (comme son premier exemple). Une fonction aurait aussi peut être été la bien venue, un en-tête avec SYNOPSIS, DESCRIPTION, une gestion d'erreur plus fine...

    Je laisse Azalee78 remettre en forme si besoin.

    Mis à part le débat sur "c'est bien" ou "c'est pas bien" de le faire par script je pense que le demandeur est toujours en attente. Tu me diras si la GPO peut choisir un lecteur comme le besoin énoncé à savoir prendre la première lettre de disponible parmi un choix.

    Si besoin je te laisse améliorer le script, il est la pour le partage.

    jeudi 7 octobre 2021 18:06
  • pas d'offense ! 

    Mes commentaires ne reprenaient que ce qu'aurait sorti le https://github.com/PowerShell/PSScriptAnalyzer

    Effectivement, une GPO ne permettrait pas de régler la question de la lettre de lecteur. Cependant, Est-ce réellement un besoin réel ou un besoin "de confort" ? J'ai exposé plus haut dans ce thread, quelques éléments, comme nombre de lettres limitées, ... et un solution pour limiter le nombre de lettres à une et unique lettre (DFS + ABE).

    Je dis toujours que quand on a un besoin, on ne doit pas l'exprimer en terme technique, mais en objectif à atteindre. Pourquoi ? Simplement parce que si on dit "je veux ceci, je veux cela", on bride la solution à une seule ... qui n'est pas nécessairement la plus avisée pour atteindre l'objectif (en fait) recherché.

    C'est pourquoi, souvent, je cherche à savoir le besoin "réel" qui se cache derrière une demande. Une fois, ce dernier obtenu, il me semble plus évident de proposer une ou plusieurs solutions présentant avantages/inconvénients.

    Les exigences ne doivent pas être techniques, cependant il peut y avoir ce qu'on nomme des "contraintes" qui elles limitent/imposent un cadre technique.

    Pour revenir à un cas proche du présent cas, la demande aurait pu être "je souhaiterais savoir qu'elle est la méthode la plus appropriée pour mapper des lecteurs réseaux à des utilisateurs, selon leur appartenance à tel ou tel groupe". Les contraintes pourraient être "Postes dans et hors domaine, dans réseau d'entreprise, Hors réseau d'entreprise, mais postes gérés, environnement full non-windows, ...".

    La dernière réponse de Azalee78 est en date du 8/09, et ce thread est toujours ouvert, mais il est fort possible qu'il n'ait pas vu la solution que tu lui as proposé, ce qui est dommage en soit, et qu'il ai déjà répondu à son besoin. 

    Olivier

    vendredi 8 octobre 2021 04:34