none
DFS et cibles de dossiers RRS feed

  • Discussion générale

  • Bonjour

    je souhaiterai avoir quelques précisions concernant les cibles de dossiers DFS mais je ne trouve pas d'infos dans la documentatioon technet

    j'ai actuellement une infrastructure DFS que je souhaite réorganiser. beaucoup de mes racines disposent de dossiers communs mais ne sont pas totalement identiques. 

    j'ai donc regroupé ces dossiers communs dans une racine cachée pour utiliser ce chemin ensuite dans la définition des dossiers dans les différentes racines de mes utilisateurs. sauf que quand je veux rajouter ladite cible dans un dossier existant, je me retrouve avec des erreurs de type "demande non supportée"

    par conséquent, je me pose la question de savoir si ce type de configuration est possible ou non

    mercredi 5 février 2020 10:00

Toutes les réponses

  • Bonjour Benoit Segonnes,

    Veuillez consulter l'article ci-dessous, ainsi que les articles associés.
    Présentation de réplication DFS

    Merci d'avance pour votre retour.

    Cordialement,

    Biliana

    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votreproblème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 6 février 2020 09:05
  • Bonjour

    ca ne répond absolument pas à ma question mais elle est peut etre mal posée.

    j'ai une racine DFS \\contoso.com\racine1 spécifique à un groupe d'utilisateurs spécifique

    j'ai une racine DFS \\contoso.com\racine2$ cachée regroupant l'ensemble des répertoires communs à tous mes utilisateurs dans plusieurs dossiers

    dans \\contoso.com\racine1, j'ai créé plusieurs dossiers. je souhaite que la cible de certains dossiers soit \\contoso.com\racine2$\dossierX

    est-ce une configuration supportée? car quand j'ajoute ce type de cible à un dossier déjà existant, l'opération échoue à l'étape "validez les modifications" avec l'erreur suivante: "impossible d'ajouter la cible de dossier. cette demande n'est pas prise en charge"
    à l'inverse, je peux ajouter ce type de cible lors de la création d'un dossier

    jeudi 6 février 2020 10:52
  • Bonjour Benoit Segonnes,

    Veuillez consulter l'article ci-dessous, ainsi que l'ensemble des articles associés. Vérifiez s'il ne s'agit pas d'autorisations de gestion, si votre scénario ne dépasse pas les limitations.
    Déploiement d’espaces de noms DFS

    Merci d'avance pour votre retour.

    Cordialement,

    Biliana

    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votreproblème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 6 février 2020 11:44
  • Bonjour Benoit,

    Je pense qu'il y a quelques éléments conceptuel concerant le focntionnement du DFS qui téchappent.

    DFS-N est juste un espace de présentation. Chaque cible (Folder Target) pointe sur un répertoire ou plusieurs si plusieurs serveurs cibles (typiquement  \\server\share\répertoire)

    tu dis que tu as [...regroupé ces dossiers communs dans une racine cachée pour utiliser ce chemin ensuite dans la définition des dossiers ...]. Si tu parles de regroupement dans le DFS-N ça ne marche pas comme ça.

    Un exemple pour illustrer

    RootDFS

    --- RH <=== Ceci n'est pas un partage DFS mais juste un répertoire traversé

           ----RH Only ===> Folder Target \\server\share$\RHDir\RHOnly         (acces : Groupe AD RH : Modifier)

           ----CommunRH ===> Folder Target \\server\share$\RHDir\Commun (acces : Groupe AD RH : Modifier -  Groupe AD Utilisateurs du domaine : Lecture)

    ---- Production ===> Folder Target \\server\share$\ProdDir (acces : Groupe AD Prod : Modifier -  Groupe AD)

    Les Folder Targets sont nécessairement différents sinon tu as le message d'erreur rencontré.

    Comment s'en sortir ? Met en place ABE (Access Based Enumeration) : un utilisateur ne verra que ce auquel il a accès.

    Les accès ? Ca se gère via les permissions NTFS.

    Un membre du groupe RH  verra

    RH

     ---- RHOnly

     --- RHCommun

    Un membre du groupe AD Prod verra

    RH

     --- RHCOmmun

    Prod

    Cordialement

    Olivier

    jeudi 6 février 2020 12:08
  • conceptuellement, j'etais bien au point ^^

    en fait, ce que je cherche a faire pour le moment c'est que mon folder target ne soit pas un partage sur un serveur mais vers un dossier présenté par une autre racine.

    dans le principe

    \\contoso.com\racine1\folder1 -> \\server1\share1;\\server2\share1
    \\contoso.com\racine1\folder2 -> \\contoso.com\racine2\folderA

    avec \\contoso.com\racine2\folderA -> \\serverA\shareA;\\serverB\shareA

    sachant que je me retrouverai à terme à avoir pointer vers des racines dans une foret différente.
    néanmoins, dans une certaine mesure, le principe d'énumération basé sur l'acces pourrait m'etre utile


    jeudi 6 février 2020 12:51
  • Bonjour,

    [...mon folder target ne soit pas un partage sur un serveur mais vers un dossier présenté par une autre racine...]

    ==> Je ne pense pas que cela soit faisable directement. En revanche rien, à ma connaissance, n'interdit d'avoir

    DFS1 ---> Share ==> \\server1\share

    et

    DFS2 ---> Share (nom peut etre différent) ==> \\server1\share

    car DFS-N est juste un espace de présentation.

    Attention cependant si tu as du DFS-R derriere pour sync en cas de Multi-Target Folders sur un même share. Je pense qu'il ne fait pas mettre la réplication DFS-R des 2 côtés.

    Penches-toi sur l'ABE ça peut t'aider à résoudre ta problématique.

    Je pense d'expérience qu'il fait également dissocier la présentation (DFS-N) de l'arborescence physique sur les serveurs. Pour le physique, c'est conditionné par Espace disque disponible, problématiques des noms longs (et oui, ça subsiste encore dans les vieux environnemnts), gestion des permissions NTFS, et un peu d'organisation pragmatique. POur le DFS-N, le desgin est plutôt dépendnt de l'organisation de l'entreprise et on doit viser une certaine pérennité dans le temps.

    Rappel : Quand on change une arbo DFS-N ==> Impact utilisateurs en vue (ex. : "le lien dans mon fichier excel vers un autre document ne marche plus". Cause : le lien DFS n'est plus le même)

    Olivier

    jeudi 6 février 2020 13:21
  • Rappel : Quand on change une arbo DFS-N ==> Impact utilisateurs en vue (ex. : "le lien dans mon fichier excel vers un autre document ne marche plus". Cause : le lien DFS n'est plus le même)

    c'est bien la le problème ^^
    le but définitif de mettre en place ce genre d'architecture est de n'avoir qu'un seul point de paramétrage pour chaque partage publié dans un espace de nom DFS, associé à la redondance et la selection de site que fournit le système.

    admettons que dans une foret A, j'ai une racine qui dispose d'un dossier pointant sur un partage d'une foret B, lui même publié dans un espace DFS sur la foret B. le fait de faire pointer l'ensemble des racines accedant à ce partage sur cet espace DFS ne m'oblige pas à reconfigurer l'ensemble des racines dans les forets A et B, mais seulement l'espace de nom dans lequel est publié le partage. ce qui en soit est un gain de temps d'administration non négligeable lors d'une migration par exemple

    jeudi 6 février 2020 14:39