none
Déplacer répertoires "Home Directory" RRS feed

  • Question

  • Bonjour,

    Je dois déplacer, sur un nouveau serveur, l'intégralité de mon dossier contenant tous les "home_directory" des utilisateurs de l'AD

    Je sais modifier en PowerShell la varaible "HomeDirectory" de tous les utilisateurs, en revanche je ne sais pas comment faire en sorte que les droits suivent les dossiers.
    Quand on modifie manuellement le HomeDirectory d'un utilisateur, ça nous demande si on veut changer les droits, comment faire la même chose en PowerShell ?

    Merci

    mardi 10 septembre 2019 12:29

Réponses

  • je te conseille plutôt d'utiliser robocopy comme cela exit les pb

    je viens de tester ceci

    $source = "C:\temp\test"
    $Destination = "c:\temp3"
    $what = @("/COPYALL", "/B",  "/SEC",  "/MIR")
    $options = @("/R:0", "/W:0", "/NP")
    $log = @("/Log+:c:\temp\logrobo.log")
    $RoboArgs = @($Source, $Destination, $what, $options, $log)
    &robocopy @RoboArgs

    A executer en RunAsadmin.

    Si tu veux un fichier de log par user, modifies le nom dufichier logRobo-$User.log

    Oliv

    mardi 10 septembre 2019 15:45

Toutes les réponses

  • Bonjour JeanClaude,

    Comme tu le sais, quand tu paramètre un homedir pour un compte utilisateur dans l'AD, le répertoire est créé (vide bien entendu) avec les Acls qui vont bien. Cependant, quand le dit homeDir existe, et bien l'AD va se contenter de l'utiliser sans y toucher. 

    Personnellement, je m'y prendrais comme suit : une boucle Foreach ($User in $Users) avec $Usersma liste de compte à traiter (get-content fichier .txt, import-csv, query AD, ...)

    1- relève (Get) la conf des HomeDir de tes users (ça c'est pour le retour arrière) dans un fichier (avantmodif.csv)

    2- copie $User.HomeDirPath vers \\Nouveauserveur\partage\ (là tu prends ce que tu veux, Copy-Item, robocopy, ...). Naturellement la copie doit se faire avec les ACLs.

    3- ensuite tu modifies (Set-AdUser) le compte utlisateur. L'AD voit que le répertoire existe, et ne fait rien de plus.

    4- relève (Get) la conf des HomeDir de tes users (ça c'est pour la preuve) dans un fichier (aprèsmodif.csv)

    Attention : modifier le path des HomeDir quand le susers ne sont pas connectés. Ca ce n'est pas réellement un pb, on peut planifier un script de nuit par ex. d'autant plus que la modif AD est très très rapide. En revanche la copie des  HomeDir risque de durer des plombes (pour peu que tu es masse d'util;isateurs et force volumétrie). Je conseillerais alors dans ce cas de couper en 2 scripts. Le premier ne ferait que les tâches 1 et 2. Le second ferait 2 (synchro ça sera plus rapide.Pour ça robocpy est idéal) , 3 et 4.

    Test tout ceci sur un compte de test.

    > param le HomeDir dans l'AD (le HomeDir est créé). Colle y manuellement qq fichiers dedans

    > fais ton robocopy source destination param (une copie initiale puis une sync, autant la jouer lazy à fond et reprendre la même commandline pour la copie initiale et la sync finale)

    > modifies le HomeDir du compte en PS, et check le résultat.

    Oliv

    mardi 10 septembre 2019 13:15
  • Merci pour la réponse complète, c'est exactement ce que je souhaitais faire mais je n'arrive pas à déplacer les dossiers en conservant les ACLS, quoique je fasse je perds les droits de l'utilisateurs (tous les autres droits sont conservés en revanche)

    J'utilise la commande copy-item pour copier les dossiers

    mardi 10 septembre 2019 14:03
  • je te conseille plutôt d'utiliser robocopy comme cela exit les pb

    je viens de tester ceci

    $source = "C:\temp\test"
    $Destination = "c:\temp3"
    $what = @("/COPYALL", "/B",  "/SEC",  "/MIR")
    $options = @("/R:0", "/W:0", "/NP")
    $log = @("/Log+:c:\temp\logrobo.log")
    $RoboArgs = @($Source, $Destination, $what, $options, $log)
    &robocopy @RoboArgs

    A executer en RunAsadmin.

    Si tu veux un fichier de log par user, modifies le nom dufichier logRobo-$User.log

    Oliv

    mardi 10 septembre 2019 15:45
  • Super ça marche bien

    Merci

    mercredi 11 septembre 2019 09:39
  • Bonjour,

    Je reviens sur ce post car je suis confronté à un souci.

    J'ai déplacé les dossiers de l'ancien serveur 2008 (partage Windows) vers le nouveau serveur 2016 (partage DFS) en conservant les droits.

    J'ai modifié le home directory de mes utilisateurs avec la commande suivante :

    $users = Get-ADUser -Filter * -SearchBase "OU=TOTO,DC=Mondomaine,DC=local"
    $users | ForEach-Object {
    $homeDirectory = '\\Mondomaine.local\users\' + $_.SamAccountName;
    Set-ADUser -Identity $_.SamAccountName -HomeDirectory $homeDirectory -HomeDrive U;}

    Le HomeDirectory est bien actualisé dans le profil des utilisateurs mais le lecteur U n'apparait pas.
    En revanche si je fais une GPO "mappages de lecteurs" le lecteur U remonte bien.

    Pour que le lecteur remonte correctement sans utiliser le mappage, il faut que j'ouvre le profil utilisateur, que je fasse une modifie sur le home directory (j'enlève une lettre et je la remet),
    ensuite je clique sur "Appliquer", ça me dit que le dossier de base existe déjà et me demande si je veux que l'utilisateur ait le contrôle total. Je clique sur "Oui" et à partir de là le lecteur remonte correctement

    En gros, est-ce possible avec mon script powershell de dire que l'utilisateur doit avoir le controle total de son dossier ? ou une autre manip

    Merci d'avance

    mardi 22 octobre 2019 06:46
  • Oui il est possible d'ajouter les droits avec PowerShell :

    $usershare = nom du partage contenant les dossiers

    $userlogin = nom du dossier de l'utilisateur

    $userShare = $UserUNCShare + "\" + $UserLogin
    
    #Ajout du control totale à l'utilisateur
    $userAccess=New-Object security.AccessControl.FileSystemAccessRule($u,"FullControl",3,0,"Allow")
    
    $userAcl=Get-Acl -Path $userShare
    $userAcl.addAccessRule($userAccess)
    
    Set-Acl -Path $userShare $userAcl

    mardi 22 octobre 2019 07:08
  • Bonjour Jean-Claude :-)

    tu peux suivre ce script

    https://community.spiceworks.com/topic/314410-changing-user-s-home-directory-and-creating-home-folder-using-powershell

    Perso, je n'aime pas jouer avec les Acls avec Set-Acl (je trouve ça d'un chi...), je préfèrer largement utliser les cmdlets du module NTFSSecurity. Aussi simple que le GUI.

    Add-NTFSAccess -Path $homeDirectory -Account $Domain\$_.SamAccountName -AccessRights Modify -AccessType Allow -AppliesTo ThisFolderSubfoldersAndFiles

    Ajoute juste cette ligne dans ta boucle foreach (n'oublie pas d'installer et d'importer le module NTFSSecurity avant tout ça).

    Il n'est pas absolument nécessaire que l'utilisateur ait les permissions FullControl, Modify suffit largement ... à moins que tu tiennes absolument à ce que des petits malins transforme leur HomeDir en partage ou supprime les accès System ou Admin (Oui, je sais, que quand on le fait en mode GUI, ça met FullControl, et ça me fait hurler depuis des années.).

    Tu trouveras facilement des exemples de fonctionnement des cmdlets du module NTFSSecurity sur le Net

    Olivier

    mardi 22 octobre 2019 07:22
  • Perso, je n'aime pas jouer avec les Acls avec Set-Acl (je trouve ça d'un chi...), je préfèrer largement utliser les cmdlets du module NTFSSecurity. Aussi simple que le GUI.

    NTFSAcess nécessite l'installation d'un module supplémentaire, contrairement à Set-ACL.

    Par contre, Set-ACL S'applique à tous les objets et pas juste les permissions NTFS et ne nécessite pas de module supplémentaire. Il est donc plus simple de transposer les scripts ailleurs. 

    http://www.pbarth.fr/node/294

    des petits malins transforme leur HomeDir en partage

    Depuis leur poste de travail, il crée un partage sur le serveur dans le dossier en question ? 

    mardi 22 octobre 2019 13:34
  • Depuis leur poste de travail, il crée un partage sur le serveur dans le dossier en question ?

    @Philippe : Tout simplement en ajoutant un autre compte dans la liste de contôle d'accès de leur HomeDir. Si tu savais combien de fois j'ai vu ça. Certes, ce n'est pas le HomeDir (typiquement \\serveur\User$\$UserName%) qui est partagé mais le parent et encore en partage caché quand c'est bien fait. Mais caché ou non, quand tu connais le chemin et que tu as les Acls qui vont bien, tu passes. Et quand il y a plus d'un utilisateur, ce n'est plus un répertoire personnel mais un partage.

    Concernant Get-Acl et Set-Acl, ta position se défend et je la respecte, mais ce n'est pas pour autant la position que je retiens dans les nombreux environnements dans lesquels j'ai et je continue à travailler. Si tu te passes des modules externes, même si les dits modules n'apportent en fait qu'une amélioration de la facilité d'utilisation, tu te brides. Et puis comment faire sans les modules spécifiques PS constructeurs (VMware, PureStorage, Lenovo xClarity, Dell OpenManage, Azure ...) ? On continue à travailler comme il y a 20 ans, en mode GUI, sans tracabilité, en mode unitaire, sans garantie de respect des règles internes (à commencer par les conventions de nommage). Bien obligé de les utiliser. Je ne mets en "prod" que des modules dont la peinture est sêche (NTFSSecurity, EZLog, PSWindowsUpdate, SysInfo plus quelques autres en nombre très limité). Déjà faire adopter le scripting comme moyen de travail à un admin windows, c'est loin d'être gagné d'avance, alors si en plus il faut leur faire utiliser des cmdlets par vraiment intuitives ... je ne suis pas sorti de l'auberge.

    Pas encore convaincu ? Je te le vends ainsi alors : tu dois réaliser un audit sur les permissions NTFS appliquées aux HomeDir (on va commencer petit), tu as 3 min pour faire ton rappor au patron de la DSI. 

    # Partage racine des Home Dir

    $HomeRoot = "\\serveur\Users$" # Collecte des permissions NTFS sur le partage racine $result = Get-NTFSAccess -Path $HomeRoot # collecte de tous les HomeDir $HomeDirs = Get-ChildItem -Path $HomeRoot -Directory $Date = Get-Date -Format "yyyy-MM-dd" # pour timestamper nom du fichier de sortie # récupération des permissions NTFS sur tous les HomeDirs $result += foreach ($HomeDir in $HomeDirs) { # on exclue les permissions hérités du parent, ce ne sont que des groupes d'administration (pas d'accès utilisateur) Get-NTFSAccess -Path $HomeDir.fullName -ExcludeInherited # on a donc - normalement récupéré qu'une seule entrée correspondant à l'utilisateur propriétaire } # Au choix $result | ogv # ou $result | Export-Csv -Path "$PSScriptRoot\NTFS-HomeDir-au$Date" -Encoding UTF8 -Delimiter ";" -NoTypeInformation Invoke-Item -Path "$PSScriptRoot\NTFS-HomeDir-au$Date"

    Facile à lire, facile à comprendre, facile à utiliser.
    d'un seul coup d'oeil, si on a sur un HomeDir plus d'un utilisateur, il a coui... dans le potage, et il va y avoir des coups de fusil qui vont partir.

    Tu peux faire la même chose avec Get-Acl, mais est-ce réellement aussi simple à construire et à  comprendre ? Pour toi, je n'en doutes pas, mais en est-il autant de tous les membres de l'équipe d'admin ? Oui, car il y a une équipe, j'avais oublié ce point.  Loin d'être garanti ça ! Quand tu bosses avec des personnes qui ont déjà du mal à comprendre les 4 lignes ci-dessus si je ne mets pas plus de commentaires que de code, va leur dire de comprendre Get-Acl et d'utiliser pour leur propre compte ces quelques lignes. Pas moyen ! Le boulot, ça sera toujours pour ta pomme parce qu'ils "savent pas comment on fait". Ils sauront bien d'ailleurs aller pleurer auprès du patron pour que cela toi qui t'y colle même si tu as du taf par dessus la tête par ailleurs.

    J'arrête là parce que je m'énerve tout seul - et c'est pô bon pour mon coeur :-) - pas après toi, mais après cette situation que je vis au quotidien depuis 20 ans. On aura bien l'occasion un jour d'échanger sur nos retours d'expérience mutuels. Un des Leitmotivs : "Je suis un feignant pas un un fainéant".


    mercredi 23 octobre 2019 11:47
  • Bonjour,

    Merci à vous deux d'avoir pris le temps de répondre et d'argumenter. Je vais suivre vos recommandations et faire comme l'indique Oliv TheFrog….pas envie de me faire engueuler si je repose une question plus tard :) :)
    Je n'avais jamais pensé que des utilisateurs pourraient partager leur lecteur perso, je vais vérifier avec le petit script (que j'ai compris malgré mes très faibles connaissances en code)

    Si je peux abuser, j'aimerais bien savoir quelles sont vos recommandations à propos de ces lecteurs perso car je voudrais faire ça correctement. J'ai créé un espace DFS mais je ne suis pas certain d'avoir mis les bons droits de sécurité, ni les bons droits de partage.

    Est-ce qu'il existe des documents pour les bonnes pratiques ?

    Merci d'avance

    jeudi 24 octobre 2019 08:14