BarthVonRies Posté(e) le 2 janvier 2011 Partager Posté(e) le 2 janvier 2011 Bonjour à tous, et bonne année! Je dois remonter toute l'infra réseau de mon entreprise suite au départ de l'admin système (presta qui n'a pas été renouvelé ). Aujourd'hui, pour monter 5 lecteurs réseau et 4 imprimantes à la connexion, il faut entre 4 et 6 minutes avant d'avoir la main sur son poste, tout ça sans profils itinérants Donc, description de l'entreprise: Siège basé à Lyon, des consultants en presta dans toute la France (environ 40 salariés en tout). On héberge dans nos locaux une filiale de 6 salariés. On a pour le moment un seul domaine maboite.fr, tous les postes sont sous winxp. Il n'y a qu'un seul script de connexion en vbs pour tout le monde, qui teste des appartenances à des groupes afin de monter ou non des lecteurs réseaux, des imprimantes et configurer l'imprimante par défaut, à chaque démarrage. Un de nos clients souhaitant un dév fait sous Linux, il faut pouvoir autoriser des clients Ubuntu sur le domaine avec tous les lecteurs qui se montent. Je pensais faire: Serveur contrôleur de domaine maboite.lan sous Windows 2008 R2 (on est partenaire MS donc pas de souci pour les licences) Serveur contrôleur de sous-domaine filiale.maboite.lan, toujours sous Windows 2008 R2 Quelle version de Win2008 me conseilleriez-vous? Les utilisateurs de la filiale doivent pouvoir accéder à des partages réseaux et aux imprimantes de la société "mère". Sera-ce le cas dans cette configuration? J'avoue que je ne maîtrise pas du tout la partie AD (je suis plus admin linux d'habitude, et encore sans la partie domaine que je n'ai jamais gérée autrement qu'en théorie lors de mes cours il y a quelques années). Les postes clients étant sous différentes versions de windows et de linux, comment faire le script de connexion? J'ai pensé à Perl (qui testerait l'OS, et lancerait le script logon_winxp.pl ou logon_win7.pl ou logon_linux.pl suivant le résultat). Est-ce faisable? Merci de m'apporter vos retours d'expériences et conseils sur le sujet Lien vers le commentaire Partager sur d’autres sites More sharing options...
Amour Posté(e) le 3 janvier 2011 Partager Posté(e) le 3 janvier 2011 Je n'ai pas la réponse à vos questions, connaissant la partie domaine de Windows, et pour Linux je sais seulement y faire connecter des lecteurs réseaux à la main, mais si je peux donner au moins un conseil : Faites un maximum de tests en machines virtuelles... Lien vers le commentaire Partager sur d’autres sites More sharing options...
bg44 Posté(e) le 3 janvier 2011 Partager Posté(e) le 3 janvier 2011 Bonjour, Windows 2008 R2 est très bien Tu peux configurer tes mappages réseaux depsui des GPOs. mais ce ne sera actif que sur les PCs Windows... Une autre manière est dans faire tes mappages dans le fichier de logon. je te conseille le batch, pris nativement sous Windows. Il te faudra mettre le fichier dans le dossier NetLogon. Inscris simplement le nom du fichier dans les propriétés de l'utilisateur dans l'AD => lance dsa.msc et renseigne le nom du fichier (sans l'arborescence) dans l'onglet profil. Si tu veux utiliser un script PERL, il te faudra vraisemblablement indiquer le chemin de l'interpréteur PERL, à moins que tes machines Windows n'exécutent de façon auto ces scripts PERL. Pour les Linux, un montage SAMBA devrait faire l'affaire, bien que maitrise peu cette partie..... Sinon, concernant la lenteur, tu peux dans les GPOs faire en sorte que les PCs rendent la main avant que les sripts d'ouverture de session aient finis. La rapidité du mappage dépend aussi de la qualité de ta ligne, si tu as de FW ou autre équipements susceptibles de ralentir/bloquer des connexions SMB... => faut laisser passer le NetBios Lien vers le commentaire Partager sur d’autres sites More sharing options...
Higapeon Posté(e) le 3 janvier 2011 Partager Posté(e) le 3 janvier 2011 Inscris simplement le nom du fichier dans les propriétés de l'utilisateur dans l'AD => lance dsa.msc et renseigne le nom du fichier (sans l'arborescence) dans l'onglet profil. Mon dieu non ! Une GPO avec le script placé dedans ("Configuration utilisateur" - "Paramètres Windows" - "Script") et on ne risque plus d'oublier de le renseigner chez un User (ultra fréquent = /) A noter qu'un script renseigné par DSA ou propagé par GPO file la main direct sur le poste, et continue à s'appliquer en tâche de fond. Pour ce qui est des scripts pour le Linux, je n'en ai strictement aucune idée Est il absolument nécessaire de faire un sous domaine ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
bg44 Posté(e) le 3 janvier 2011 Partager Posté(e) le 3 janvier 2011 les sous domaines sont utiles pour de la sécurité : séparer des comptes utilisateurs par exemple ou faire de la délégation d'administration plus poussé.... Sinon cela peut être pour des raisons légales, juridiques ou administratives.... Le mieux est de ne pas en faire, et de gérer via des UO tes filiales : une forêt, un seul domaine et des UOs... Tu peux faire de la délégation d'admin sur certaines UO si besoin. Et avec le GPOs c'est plus simple tout gérer dans un domaine unique. Pour les scripts linux, tu peux peut être les lancer au boot des PC.. Lien vers le commentaire Partager sur d’autres sites More sharing options...
BarthVonRies Posté(e) le 4 janvier 2011 Auteur Partager Posté(e) le 4 janvier 2011 Merci à tous pour vos conseils Faites un maximum de tests en machines virtuelles... Le contrôleur de domaine sera lui-même une VM sur un serveur ESXi, donc on a pour le moment dégagé des machines afin de faire tous les tests nécessaires à la rédaction de procédures carrées avant mise en prod Windows 2008 R2 est très bien Tu peux configurer tes mappages réseaux depsui des GPOs. mais ce ne sera actif que sur les PCs Windows... Une autre manière est dans faire tes mappages dans le fichier de logon. je te conseille le batch, pris nativement sous Windows. Il te faudra mettre le fichier dans le dossier NetLogon. Inscris simplement le nom du fichier dans les propriétés de l'utilisateur dans l'AD => lance dsa.msc et renseigne le nom du fichier (sans l'arborescence) dans l'onglet profil. Je demandais quelle édition de 2008 R2 (Standard, SBS, DataCenter même si pour celle-là j'ai un doute?) Et aujourd'hui, tous les postes clients étant sous XP, c'est un .vbs qui est exécuté pour tout le monde avec des dizaines de tests (if groupe_plateau_1_impr_nb_default then mettre_imprimante_nb_plateau_1_par_defaut sur des dizaines de groupes ) Je cherchais à faire un script de logon qui soit "portable" d'où ma question concernant le perl. Sinon, je laisserai un batch (plus propre) et je mettrai probablement un appel à un script réseau (en bash) dans le /etc/profile des users linux, bien que je préfèrerais que tout soit géré au niveau du domaine. Pour les Linux, un montage SAMBA devrait faire l'affaire, bien que maitrise peu cette partie..... C'est ce qui va se passer Sinon, concernant la lenteur, tu peux dans les GPOs faire en sorte que les PCs rendent la main avant que les scripts d'ouverture de session aient finis. La rapidité du mappage dépend aussi de la qualité de ta ligne, si tu as de FW ou autre équipements susceptibles de ralentir/bloquer des connexions SMB... => faut laisser passer le NetBios On a du réseau 100MB/s en interne, aucun firewall d'activé (je sais c'est mal, je vais voir comment corriger ce problème). Les postes qu'on a ne disposant pas encore de cartes gigabit, on n'a pas prévu d'investir dans ce type d'infra pour le moment. Pour rendre la main avant la fin des scripts, on a un souci: tant que TrendMicro Officescan ne s'est pas initialisé, aucune conexion réseau n'est dispo et les postes perdent leur connexion si on tue le process (ça, ça paraît plus logique d'un point de vue sécurité). Les modèles de document Office étant hébergés sur le réseau, il faut que les scripts aient au moins monté les lecteurs avant de rendre la main (bon ok, aujourd'hui, c'est ce qui est fait en tout dernier, je dois les refaire pour les rendre plus ergonomiques pour les utilisateurs). les sous domaines sont utiles pour de la sécurité : séparer des comptes utilisateurs par exemple ou faire de la délégation d'administration plus poussé.... Sinon cela peut être pour des raisons légales, juridiques ou administratives.... Le mieux est de ne pas en faire, et de gérer via des UO tes filiales : une forêt, un seul domaine et des UOs... Tu peux faire de la délégation d'admin sur certaines UO si besoin. Et avec le GPOs c'est plus simple tout gérer dans un domaine unique. En fait, il est prévu à terme que la filiale déménage et devienne "indépendante" (pour le moment, les lecteurs réseau, imprimantes, etc sont partagés mais ce ne sera plus le cas). Et comme ils n'ont pas d'admin système en interne, le mieux est que je configure tout dès aujourd'hui, puisque je remonte toute l'infrastructure de zéro. Pour les scripts linux, tu peux peut être les lancer au boot des PC.. Hum, les lecteurs dépendant des droits de l'utilisateur, pas possible Merci de vos conseils, je vais faire mes tests! Lien vers le commentaire Partager sur d’autres sites More sharing options...
typhoon006 Posté(e) le 4 janvier 2011 Partager Posté(e) le 4 janvier 2011 Le contrôleur de domaine sera lui-même une VM sur un serveur ESXi, Généralement il est déconseillé d'avoir son contrôleur de domaine dans une VM... le DC doit rester une machine physique. Et aujourd'hui, tous les postes clients étant sous XP, c'est un .vbs qui est exécuté pour tout le monde avec des dizaines de tests (if groupe_plateau_1_impr_nb_default then mettre_imprimante_nb_plateau_1_par_defaut sur des dizaines de groupes ) Ca me parait bien dégueulasse tout ça.... tu ferais mieux de faire des OU dans ton AD, pour dispatcher tes users...et créer un script pour chaque OU qui ne tests plus rien mais s'occupe juste de monter tes lecteurs/imp Lien vers le commentaire Partager sur d’autres sites More sharing options...
bg44 Posté(e) le 4 janvier 2011 Partager Posté(e) le 4 janvier 2011 Bon courage et pour la version de W2k8, la standard est normalement suffisante. La SBS, c'est très particulier avec des mises à jour spéciales.....c'est malgré tout intéressant pour les petites structures (50 utilisateurs max, il me semble), car la messagerie et un moteur SQL sont intégrés. Lien vers le commentaire Partager sur d’autres sites More sharing options...
BarthVonRies Posté(e) le 4 janvier 2011 Auteur Partager Posté(e) le 4 janvier 2011 Le contrôleur de domaine sera lui-même une VM sur un serveur ESXi, Généralement il est déconseillé d'avoir son contrôleur de domaine dans une VM... le DC doit rester une machine physique. Et aujourd'hui, tous les postes clients étant sous XP, c'est un .vbs qui est exécuté pour tout le monde avec des dizaines de tests (if groupe_plateau_1_impr_nb_default then mettre_imprimante_nb_plateau_1_par_defaut sur des dizaines de groupes ) Ca me parait bien dégueulasse tout ça.... tu ferais mieux de faire des OU dans ton AD, pour dispatcher tes users...et créer un script pour chaque OU qui ne tests plus rien mais s'occupe juste de monter tes lecteurs/imp Ben en fait, en petite SSII, on mutualise comme on peut les ressources quand le patron refuse d'investir dans l'infra interne parce que ça rapporte rien donc le contrôleur de domaine sera en VM, on a pas le choix vu les ressources à dispo. Pour les UO, c'est prévu d'en faire, je n'ai pas encore attaqué cette partie de la réflexion... Lien vers le commentaire Partager sur d’autres sites More sharing options...
typhoon006 Posté(e) le 4 janvier 2011 Partager Posté(e) le 4 janvier 2011 Ben c'est une erreur. Tu constates actuellement que l'infra est bancale et au lieu de commencer par restructurer l'existant, tu commences directement par ajouter des choses. Restructurer ton AD c'est restructurer ton organisation pour faciliter l'ensemble des taches qui vont en découler comme la maintenance, les déploiements etc... De plus même si tu pars ensuite sur une nouvelle machine, t'as juste à migrer ton AD, donc tu ne perds pas de temps et c'est transparent vis à vis de tes utilisateurs. Ce n'est que mon avis, mais tu gagnerais en visibilité et tu réglerais tes problèmes de script qui font une tonne de vérifications pour monter trois lecteurs et deux imprimantes le patron refuse d'investir dans l'infra interne parce que ça rapporte rien un patron qui te dis ca, déjà il a rien compris.... tu peux lui expliquer, que si demain son infra se casse la gueule son activité se casse la gueule également, car il n'y aura plus aucune productivité dans son entreprise... Un patron ca pense en €€€€, ca lui rapporte rien ok (c'est faux mais bon), par contre si ca marche pas ca lui coûte beaucoup ... Dans ton argumentaire tu peux lui dire "A combien vous chiffrez l'inactivité, disons d'une heure, de l'ensemble de votre personnel ?" Là il va réfléchir je peux te l'assurer Je trouve quand même hallucinant qu'un patron de SSII pense comme ca ceci dit ... Edit : je suis un peu direct mais c'est pas méchant, c'est pour t'aider Lien vers le commentaire Partager sur d’autres sites More sharing options...
Higapeon Posté(e) le 5 janvier 2011 Partager Posté(e) le 5 janvier 2011 Ben en fait, en petite SSII, on mutualise comme on peut les ressources quand le patron refuse d'investir dans l'infra interne parce que ça rapporte rien donc le contrôleur de domaine sera en VM, on a pas le choix vu les ressources à dispo. Pour les UO, c'est prévu d'en faire, je n'ai pas encore attaqué cette partie de la réflexion... Il est conseillé d'avoir au moins 1 contrôleur en physique (comme en théorie on ne virtualise pas un serveur SQL ou un Exchange hébergeant des BAL). C'est un conseil, pas une obligation. Mais si c'est conseillé, c'est pas pour rien Sinon Typhoon006 a les bons arguments :) Tu peux balancer aussi que c'est le comble pour un client de constater que sa SSII n'est pas capable de maintenir son propre système informatique :) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.