Bonjour !
 
Voila nous sommes en train d'étudier le passage à AD dans notre structure.
 
Il s'agirait de gérer 8000-10000 étudiants et les salles informatiques (1000 postes au départ) qui vont avec. Actuellement nous utilisons un SI et outils libres, mais nous en atteignons clairement les limites depuis des années Résultat peu d'expertise microsoft Pénalisant.
 
Nous sommes donc plusieurs entités sur un même site géographique. Chaque entité possède au moins 1 informaticien. Après recherches et tests, nous avons abandonné le mono foret-multi domaines qui n'apporte que des complications et ne renforce pas la sécurité.
 
Nous partons donc sur un mono domaine, mono foret avec délégation d'OU. Chaque composante aura son OU et pourra la gérer (et ses sous-OU). Il faut aussi absolument qu'elle puisse déployer/gerer leurs images systèmes (et paquets app-v dans un futur proche), IE garder de l'autonomie.
 
Il y a aura bien sur des admin centraux.
 
La nomenclature des comptes, des mots de passe a été validée déjà.
 
Alors schéma 1 (à l'arrache ) :
 
TOUS les DC sont dans une réseau central. Les OU (entités) viennent taper dedans mais ne communiquent pas entre elles. Chacune peut avoir son serveur MDT (quid de multiples sscm dans un domaine unique au passage ?)
 

 
Schéma 2 :
 
On "économise" la structure centrale. Chaque OU/entités possède un DC, et les DC/subnets communiquent entre eux totalement (on ouvre les vlans). Idem chaque OU doit pouvoir être autonome sur sa gestion d'image, inventaire, applications.
 

 
Qu'en pensez vous ?
 
Voila si vous avez des idées, ou suggestions    
Merci

Dans tous les cas il faut que tous les postes puissent être capable de joindre tous les DC.
 
Pour MDT tu peux avoir plusieurs serveurs, indépendant ou lié.
Pour SCCM tu peux faire de la délégation, faire du primaire/secondaire, à voir la granularité qu'il te faut.
 
 
Et dis toi juste que AD et MDT/SCCM c'est complètement indépendant (enfin moins pour SCCM mais qd même)

Je savais que tu répondrais
 
J'ai déjà testé wds/MDT2010 en fait, ca marche bien. Par contre les ing. Microsoft me conseille très fortement SCCM car j'ai l'optique d'utiliser App-v en fonction du poste de travail (et ZTI, à moindre niveau). Je suis un peu réticent sur SCCM car j'ai l'impression d'une bonne usine à gaz...
 
Concernant le schéma 1 ou 2, que conseillerais tu ? Centraliser les DC dans un sous réseau, ou les éclater/decentraliser dans chaque entité ?

Pour le schéma 1 ou 2, j'aurais tendance à préférer le 2ème pour une question d'accessibilité du service. Si tu met tout dans ton lan "dédié", si le lien réseau pète, plus d'AD dispo. Là tu réparties.
 
Après ça faut voir si :
- l'emplacement des dc est sécure
- la maintenance des dc dans cette configu peut se faire par tes équipes "centrales"
- les firewall en place
 
 
Pour wds/mdt vs sccm il faut bien prendre en compte ceci : SCCM va gérer le cycle de vie de ton poste de travail (et de tes utilisateurs). Tu vas faire de l'inventaire, du patch management, du déploiement d'appli au cours de la vie du poste et plein d'autre choses que tu peux faire avec MDT.
 
Ca n'a pas le même cout (après peut être que les CAL SCCM sont déjà inclus dans votre contrat comme dans pas mal de boites).
 
SCCM est une usine à gaz, c'est à peu pres vrai et demande des connaissances que peut être tes équipes locales n'auront pas. Je sais pas ce que vous utilisez pour le moment pour gérer le poste de travail une fois qu'il est déployé.
 
Au niveau déploiement d'OS pur, MDT ou SCCM ou SCCM+MDT c'est pareil, la différence est que dans un cas tu utilises des packages SCCM et dans l'autre les sources sont sur ton serveur MDT.
 
Si tu fais du  App-V soit tu actives la fonctionnalité de SCCM R2 (ou R3) soit tu installes une infra de streaming app-v ou sinon tu déploies les msi app-v avec le client en mode autonome. On fait souvent ce dernier cas sur des clients qui ont déjà une infra de déploiement d'appli mais qui ne veulent pas SCCM ni avoir une nouvelle infra spécialement pour App-V.

Concernant les DC, oui il y a des locaux techniques, et une équipe centrale. On va rédiger une charte d'utilisation de toute facon (formation des admin, serveurs qui tiennent la route, délégation des ou...)
 
Pour le firewall, je ne sais même pas si ca vaut le coup de positionner des ACL entre les vlans/subnets (réseau privé de toute façon). Ptet pour empêcher les ports souvent utilisés par les virus. A voir.
 
 
On va avoir une licence campus (donc SA partout déjà), je regarderai pour les cal SCCM. Si c'est compris, pourquoi pas, sinon ca sera sans.
 
 
Disons que pour gérer le poste de travail après le déploiement.. ben heu.. c'est un peu le GROS problème qu'on a avec les outils libres.  
 
On a bien OCS pour l'inventaire et un peu de WPKG... mais ca se limite là. En pratique, on refait une image complète avec les nouveaux logiciels (en mode bloc, donc ultra monolithique) tous les ans, qu'on redéploie sur les salles. Autant dire qu'il n'y a pas vraiment de suivi... d'ou ma volonté d'utiliser app-v.
 
Concernant App-V, je pense que le mode streaming ou Msi conviendrait bien (combiné avec les gpo). Nous avons besoin de déployer plutot en fonction des salles que suivant les utilisateurs. Peut on mixer le mode standalone avec le "Full Infrastructure mode" d'appv ?
 
En gros, on déploie sur une salle l'application 1 en msi (adobe par exemple), et à coté, pour tous les utilisateurs on streams l'appli 2 (firefox) avec les raccourcis utilisateurs ? [edit : oui selon l'IPD 4.6 !]

Pour le mixage je ne sais pas. Tu peux avoir des ordis en indep et des ordis en streaming mais je ne sais pas si tu peux déployer des applis en indep qd ton client est configuré pour faire du streaming.
 
App-v ne va pas t'enlever le "non suivi" de tes postes (même si en mode streaming tu as qd même le suivi de tes applis déployés).

Il y a pas mal de logs pour suivre le déploiement d'après ce que j'ai vu.
 
Ensuite, on a quand meme du Wsus et de l'Endpoint derrière pour les postes (nagios pr les serveurs)
 
Ce qui ne va pas du tout actuellement, c'est le processus de creation et gestion des images (1 config = 1 image) et le déploiement des appli.  
 
J'espère que mdt, appv et AD resoudront ce pb. Je suis toujours réticent pour sccm. Bien sur je suis preneur de toutes les solutions

Des nouvelles
 
Alors l'idée du schéma 1 (tout centraliser) est écartée définitivement.
 
 
On se rapproche du schéma 2 (1 DC dans chaque composante).
 
Par contre, il y a aussi l'idée de laisser 1 DC par composante (voir 2 pour le backup en particulier le DHCP) et de mettre 1 ou 2 DC dans une zone centrale accessible par toutes les composantes. Est ce vraiment nécessaire ?
 
En fait, la question est de savoir comment répartir les roles FSMO pour avoir une infra optimisée (10 000 comptes users) et résistantes aux pannes (1 foret, 1 domaine) ?. Je n'ai pas le recul pour çà :x et l'IPD ne donne que des indications génériques.

Tous les DC doivent être accessibles par tous les clients. En avoir un en central avec les rôles FSMO oui c'est mieux. Encore mieux est d'en avoir 2 et de splitter les rôles FSMO entre les 2. Après c'est loin d'être obligatoire et tu devrais pouvoir t'en passer.
 
Pour le DHCP tu as pas 10000 solutions, soit du clustering (=no si ils sont dc, soit du 80/20 ou 60/40 mais le backup peut être en central si besoin et celui en central est backup pour tt le monde)

Si je comprends bien dans le cas de 2 DC centraux et d'1 DC par composante (avec 1 domaine et 1 foret) :
 
DC central 1 réseau 1 : - maitre de noms ; catalogue global ; controleur schéma
DC central 2 réseau 1 : - maitre Rid ; maitre infra ; maitre PDC
       - DC composante 1 réseau 2 : aucun role FSMO mais sert de backup et gère le DHCP + Un serveur supplémentaire hébergeant WDS/MDT/WSUS.
       - DC composante 2 réseau 3 : idem
 
C'est bien cela ?
 
Tous les DC communiquent entre eux sur une ligne sure.
 
Concernant les clients, est il nécessaire que les clients de la composante 1 communique avec le DC de la composante 2 ? Une communication vers le site central ne suffit elle pas ? A moins bien entendu, qu'un DC d'une composante prenne un rôle FSMO.
 
merci
 
       

1000 postes sur 3 classes C ?

 
C'est bien ça .
 
 
Et oui c'est mieux si ils y ont accès même si normalement ils peuvent vivre sans.
 
Après tu peux voir mais si tu as 2 sites centraux tu as donc un minimum de redondance et tu peux virer tes dc dans chaque sites. Faut voir le réseau.

 
C'était à titre indicatif On va partir sur un /14 pour palier à tous les besoins et souhaits de chaque site.
 

 
 
 
Une question toute simple car j'ai un doute Dans un mono domaine, mono foret, seul le PDC émulator (1 serveur) se charge de l'authentification des clients ? Les autres DC (dans les composantes par exemple) sont strictement passifs ou se chargent également d'authentifier les clients ?

tous les dc authentifient. Le PDC emulator est celui qui est interrogé pour savoir si le mdp a changé