none
AD -> Nouveau site (physique) RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour à tous,

    Nous avons un nouveau site physique à l'autre bout de la planète ...

    Je souhaite leurs mettre un serveur AD mais je suis un peu perdu, Sur ce qui pourrait correspondre le mieux ; nouveau site AD, sous domaine, RODC ... 

    Ici on est sur des serveurs 2012 R2 ,niveau de la  foret - > 2012 

    Merci d'avance pour vos réponses.

    Anthony

    jeudi 11 février 2016 15:49
    |

Réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Hello

    OK alors vise un contrôleur de domaine "classique" et oublie un RODC".
    A moins que tu aies des boîtiers pour gérer le DNS, ce contrôleur de domaine devra aussi avoir les rôles DNS.

    L'avantage c'est que tu n'auras pas besoin d'un "monstre".

    J'imagine que ton site distant (appelons le "site B") aura son propre plan d'adressage réseau (subnet)
    Il faudra le "déclarer" au niveau de ton Active Directory

    Exemple:

    Et après tu devras

    1. "déclarer" ton contrôleur de domaine, pour qu'il l'associe au "siteB"
    2. associer le subnet de ton site distant, pour éviter que les requêtes AD "fassent l'aller-retour entre le siteB et ton site principal.

    (exemple: au niveau AD, il "voit" plein de subnets)

    Florent

    PS: N'oublie pas que cela te partagera seulement les ressources AD (pour authentification).
    Pas de "magie" : messagerie, partages réseau, etc... ne sont pas concernés.
    mardi 16 février 2016 11:08
    |

Toutes les réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Hello

    Tu dois te poser une série de questions (simples):

    > Est-ce que les utilisateurs seront dans le même domaine que ceux du site "principal" ?
    Si oui : même domaine.

    > Doivent-ils être "autonomes" en cas de panne/inaccessibilité du site principal ?
    Si oui : pas de RODC

    > Quelle est la latence entre les deux sites ?
    > Combien d'utilisateurs, en tout ?
    > Les utilisateurs du site distants utiliseront-ils des ressources du site principal ? (Remote Desktop, Share, Imprimantes, Exchange, Dynamics CRM ou AX, SharePoint, etc...)
    Si Oui : ce sera plus simple de les avoir dans le même domaine que le site principal.

    Mais surtout :

    > A quel point te sens-tu "à l'aise" de gérer un sous-domaine, un autre domaine (avec sa relation d'approbation, sa fédération) ?
    > Connais-tu les limitations d'un contrôleur de domaine "Read-Only" vs "un classique tout normal" ?
    > Es-tu (enfin) à l'aise aussi avec les redirections DNS, les zones DNS ?

    Si la réponse à l'une de ces 3 questions est "non", alors va sur un contrôleur de domaine "normal" avec un nouveau site AD (correspondant à ton sous-réseau du site distant, afin que les ressources du site distant s'adressent d'abord au contrôleur de domaine du site distant plutôt que ceux du site principal)

    Florent




    jeudi 11 février 2016 16:24
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Merci pour ta réponse, 

    Oui il devront être un minimum autonome en cas de pannes chez nous çela doit fonctionner làbas  ... Les utilisateurs existes déja sur notre AD . 

    Pour les users environs 20 ... 


    Anthony

    jeudi 11 février 2016 16:29
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Et les interconnexions entre les sites ? 

    Comment les utilisateurs utilisent les ressources ? ou sont hébergé leurs messagerie ? intranet ? application ? sur le site local ou le site principale ?

    jeudi 11 février 2016 18:52
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Hello

    OK alors vise un contrôleur de domaine "classique" et oublie un RODC".
    A moins que tu aies des boîtiers pour gérer le DNS, ce contrôleur de domaine devra aussi avoir les rôles DNS.

    L'avantage c'est que tu n'auras pas besoin d'un "monstre".

    J'imagine que ton site distant (appelons le "site B") aura son propre plan d'adressage réseau (subnet)
    Il faudra le "déclarer" au niveau de ton Active Directory

    Exemple:

    Et après tu devras

    1. "déclarer" ton contrôleur de domaine, pour qu'il l'associe au "siteB"
    2. associer le subnet de ton site distant, pour éviter que les requêtes AD "fassent l'aller-retour entre le siteB et ton site principal.

    (exemple: au niveau AD, il "voit" plein de subnets)

    Florent

    PS: N'oublie pas que cela te partagera seulement les ressources AD (pour authentification).
    Pas de "magie" : messagerie, partages réseau, etc... ne sont pas concernés.
    mardi 16 février 2016 11:08
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour Florent,

    Je te remercie pour ta réponse (trés complète) !! :)

    Je vais faire comme ça. 

    Bonne journée et merci encore.

    Anthony

    mardi 16 février 2016 11:13
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Hello,

    Concernant les différents points évoqués : 

    Pour quelle raison mettre un DC sur le site ? 

    - Nombre d'utilisateur

    - Bande passante

    - Topologie d'interconnexion (routage direct avec un site central ou positionnement "derriere" un site secondaire

    Si le LAN du site distant est sur un sous réseau indépendant : il faut créer un site AD. Pour optimiser la synchronisation il sera peut être nécessaire de préciser un partenaire de réplication.

    S'il n'y a aucun correspondant informatique sur site, un RODC permettra de sécuriser l'installation

    Bon courage

    JF BERENGUER MVP System Center Operations Manager MCSE, MCT, MCSA messaging, NEXTEC SYSTEMS http://actelia.spaces.live.com/

    mardi 16 février 2016 22:21
    |