Bonjour,

On a démarré au 1er trimestre un projet de gestion des masters des postes de travail, car jusqu'alors, rien n'était, tout était fait visiblement au fur et à mesure. On a hérité non pas de vrais masters mais de plusieurs images de PC complètement construites sans cohérence, et pas adaptées aux besoins des utilisateurs.

Voici comment on l'envisage :

• la conception des masters (1)
• leur déploiement (2)
• leur mise à jour (3)
• reprise d'historique du parc (4)

Après quelques semaines, on a donc mis en place MDT et WDS, les deux fonctionnent bien : on obtient efficacement des masters sans erreur. On considère qu'on maîtrise techniquement les piliers (1) et (2) de notre petit projet.

Nous abordons donc les piliers (3) et (4), et plusieurs questions se posent à nous sur le plan organisationnel :
- doit-on faire une reprise d'historique du parc de postes de travail pour lesquels les masters ont été déployés avec un master conçu à la truelle ? Ou auriez-vous tendance à laisser "mourir" les PCs qui n'ont pas été bien conçu dès le départ ?
=> De ce point de vue-là, étant donné l'ancienneté d'une partie du parc et de son hétérogénéité en termes de modèles déployés, on ne se concentrera probablement que sur les quelques modèles les plus récents du parc et on laisserales autres qui sont de toute façon en fin de vie.

- il nous semble indispensable (mais la réflexion n'est pas arrêtée) de maintenir à jour les masters, à la fois parce que les outils utilisés en interne (par tous les collaborateurs) reçoivent des mises à jour régulières de la part des éditeurs, et aussi parce que nous avons des applications métiers clients lourds qui elles aussi sont susceptibles d'évoluer (mais elles ne concernent qu'environ 20 postes).

Voici les différentes étapes de notre réflexion au fil des semaines, en fonction des contraintes rencontrées :

• Point de vue technique

- 1 master par modèle de PC,
- puis 1 master par product number étant donnée l'hétérogénéité du parc, on a environ 10 modèles de laptops et 5 modèles de desktops (sans compter les product numbers pas tous identiques).
- puis 1 master commun à tous les PC, en réaction à la réflexion menée juste avant qui démultipliaient le nombre de masters. On imaginait une souche applications/outils commune, et corriger les pilotes avec un DVD MDT + tous pilotes, à passer sur chaque PC déployé. Testé mais non approuvé, les soucis liés aux pilotes étaients parfois résolus, parfois pas.
=> En attendant d'avoir un parc plus homogène (le processus de commande a été amélioré en ce sens), on a repéré les modèles de PC les plus déployés dans les plus récents, et pour eux on estime qu'il est pertinent de faire un master. Pour les plus anciens ou les modèles "à la marge", on les traitera au cas par cas en fonction des allers et venues dans le stock.

• Point de vue fonctionnel

La réflexion "technique" ci-avant ne prend en compte que les problématiques liées aux drivers finalement. Pour les masters, il semble important d'y intégrer une composante fonctionnelle, pour bien séparer les environnements de travail sur le poste client. On a établi :
- que seuls 2 départements (IT, Finance) de notre client utilisent des applications métiers ou des logiciels spécifiques,
- dans les deux cas, ils ont soit des laptops, soit des desktops,
- mais ils ne sont pas tous des mêmes modèles évidemment, sinon ça serait trop simple.

Alors on imagine, dans un monde idéal où on aurait :
- 2 modèles de laptops (1 portable, et 1 ultraportable)
- 2 modèles de desktops (machine standard, machine un peu plus costaude pour des besoins spécifiques)

On aurait quand même 10 masters à gérer, soit 3 masters par modèle de PC (1 standard, 1 IT, 1 Finance), desquels on retire le spécifique IT et le spcifique Finance pour les ultraportables (1 standard et basta) car ils sont conçus pour les VIP, la mobilité etc... Mais pas pour bosser avec les applis maison.
Déjà, est-ce que vous estimez la démarche correcte ou on se complique vraiment la vie ?

En admettant qu'on tourne avec 10 masters (ce qui me paraît quand même beaucoup), comment faites-vous pour les maintenir à jour ? On pensait à des VM qu'on pourrait transformer en masters et inversement grâce à VM converter, ce qui permettraient d'avoir des machines en ligne 24/24, pour au moins prendre les mises à jour de WSUS (os, pack office) et des mises à jour manuelles ou par scripts pour les applis maisons.
Et vous, comment faites-vous ?

Ca fait beaucoup de questions, j'espère que le pavé n'est pas trop indigeste.

Ah ça c'est mon sujet . Ca fait quasi 2 ans que je fais du PdT et du MDT j'en ai bouffé.
 
Déjà, on parle de quel OS ? XP ou Win 7 ? Je vais te répondre en XP parce que c'est là où tu as le plus d'adhérence avec le matériel (pb de HAL, mass storage drivers).
 
Donc pour reprendre le sujet :
 
MDT est un produit gratuit permettant le déploiement d'OS bare-metal, la réinstallation d'un poste de travail et le remplacement de poste (poste A vers B). Il fait du one shot : pour lui une fois le poste déployer, il est dans la nature, on va pas gérer le cycle de vie du poste de travail avec (contrairement à un SCCM/Altiris/LanDesk/.... Par contre tu peux gérer le cycle de vie des masters.
 
Quelles sont tes contraintes ?
- Un poste qui s'installe en 1h30 est-ce un problème ?
- L’interaction avec un technicien ou tu veux du zero touch ?
- Des outils de chiffrement de disques complets incompatibles ?
 
Sur les master on retrouve 2 types de master : thick et thin.
Dans le master thin, tu vas retrouver une image wim contenant :
- l'OS,  
- les applis communs à tous (qui ne changent pas trop),
- qq middleware (genre .NET framework, une JVM sauf si vous considérez qu'elle change trop),  
- la configuration du système de base (qui pourra être étendue via GPO plus tard)
- la configuration du profil par défaut (via la méthode de CopyProfile)
- (sur XP, les drivers mass storage du parc entier mais ça MDT gère en interne)
 
Tu vas déployer en post install tes applis :
- par modèle de poste (je pense aux applis qui accompagnent les drivers souvent)
- par rôle dans l'entreprise (IT, Finance, VIP and co)
(- unitaires [propre à chaque personne] mais pour ça j'utiliserai plutôt l'outil de télédistribution que MDT qui fait plus du déploiement de masse)
 
Du coup tu as UNE seule image WIM et tu installes tout en post install par MDT. C'est LE scénario recommandé. Dans ce scénario, l'image WIM tu la mets à jour 1 à 2 fois par ans, et je considère que pour chaque WIM tu peux te permettre de mettre à jour le socle applicatif une fois si besoin (ou 2 si tu mets à jour la WIM une fois par an pk pas).  
 
Tu as aussi les images thick :
- Une image par type de profil (IT, Finance and co) contenant les applis
- Une image desktop, une image laptop (même si on évite ce scénario et rester au maximum hardware independant)
 
Le temps déploiement est réduit puisque tu embarques toutes les applis qui n'ont pas à s'installer. Cependant si tu modifies une appli tu dois refaire ton master.
 
 
Dans tous les cas, il faut éviter de faire un master par poste de travail. Sur XP tu arrives maintenant à limiter le nb de master. Cependant des fois tu as des problème de HAL différentes, de drivers mass storage foireux qui font que tu dois splitter ton master en 2.
 
 
MDT propose une base de données qui te permet de créer des profils types (IT, Finance) et tu y associes les applis à déployer. Pareil pour le make/model pour déployer les applis dépendantes du hardware.
 
Au niveau des drivers même, il faut essayer de bien qualifier pour chaque poste les drivers, ne pas installer les drivers d'un poste X sur un Y (MDT prend le dernier drivers, donc si il a le choix entre 1.1 et 1.2 il prendra un 1.2 même si tu as qualifié 1.1 pour ce modèle de poste). Il faut jouer sur MDT à créer des dossiers and co pour chaque type de poste pour chaque OS et y mettre le drivers et s'amuser sur le customsettings pour faire pointer la source de drivers au bon endroit http://www.the-d-spot.org/wordpres [...] -mdt-2010/
 
 
Concernant la création du master ce que je conseille pour éviter le maximum de problème :
- Utiliser un poste physique plutôt qu'une VM. Le poste (surtout sur XP) ne doit pas obligatoirement être le dernier cri mais plutôt le modèle le plus utilisé sur le parc. Perso je préfère un desktop pour éviter pleins de potentiels problèmes propres aux laptop (touchpad and co) mais si le parc c'est 80% d'un unique modèle de portable je pars dessus ...
- Désactiver dans le BIOS le maximum de chose : carte wifi, bluetooth, TPM, carte son, 2ème carte graphique and co, se mettre en IDE plutôt que AHCI
- Créer le master de manière automatique <<< permet de faire évoluer le master très facilement ==> tu copies la séquence de tache, ajoute les nouvelles applis etc. et zou tu lances ton process de build/capture et ton master est créé. Par contre ça impose un peu de boulot pour identifier les clé de registres, perso à faire sur le poste que tu aurais fait manuellement. Ca permet aussi d'auto documenter ton master.
 
 
Pour la gestion des mises à jour, sur XP bah tu peux pas utiliser le noeud de packages de MDT. En général selon les accès soit j'utilise la tache WSUS incluse dans MDT, soit je télécharge toutes les mises à jour en exe et j'ai un script qui lance les installs lors du build. Sur Win 7 j'utilise le noeud Packages (pour intégration offline) ou WSUS.
 
Concernant ta question des postes à refaire ou pas, je pense aussi que je referai que les postes assez récent. Avec USMT et la gestion du raffraichissement de poste, tu peux garder pas mal de paramètres et données utilisateurs. Par contre faudrait regarder si on peut restaurer sur XP (je fais quasi plus que des migrations Win 7 donc j'ai plus cette info en tête).
 
Voilà moi aussi c'est indigeste je pense mais si tu as des questions, n'hésite pas

Ah ouais purée c'est dense !
 
Bon je vais essayer de compléter et de te questionner point par point :
- On est en WinXP SP3
- petit question directement, on peut déployer beaucoup de choses par WSUS (je connais mal) ? Ou dès que c'est spécifique (non-Windows) il faut passer par un outil de télédistribution ?
- 1h30 pour installer un PdT c'est pas un souci
- pour l'interaction avec un technicien, elle me semble naturelle, autant pour la conception du master que pour le contrôle du déploiement du poste de travail "fini"
- les outils de chiffrement, je ne crois pas qu'on en ait à l'heure actuelle, enfin en tout cas je ne sais pas si c'est crypté par défaut sur les disques durs des laptops... En tout cas jusqu'à présent on n'a jamais eu de problème pour récupérer les données d'un disque dur en le branchant comme un périphérique externe avec un câble SATA USB
 
A propos des masters thick et thin, si j'ai bien compris, ce sont donc des conceptions différentes, non complémentaires. En gros, soit on va vers l'un, ou vers l'autre, mais pas les deux à la fois ? Parce que j'ai l'impression qu'on essaie de réfléchir aux deux à la fois en fait. On pensait plutôt thin au début, et maintenant thick, et c'est pour ça qu'on se pose tant de questions.
 
D'ailleurs, il y a des choses qu'on ne sait pas trop s'il est préférable de les mettre dans les masters ou de les déployer par GPO. Selon quels critères de réflexion on pourrait à ton avis faire le bon choix ? Je pense par exemple :
- certains paramètres du navigateur
- des trucs plus cosmétiques commes les fonds et économiseurs d'écran
- certains paramétrages des suites bureautique...
 

Qu'est-ce que tu mets à jour par exemple dans la WIM 1 à 2 fois par an ? Tout ou tu te limites à tout ce qui concerne l'OS ? Je me demande aussi si c'est utile de mettre à jour des drivers dans le cadre du cycle de vie d'un PC.
 
C'est intéressant d'avoir un feedback de la part de quelqu'un qui gère bien, le but serait d'avoir (en fonction de mon scope) quelle serait la solution qui apporterait le meilleur compromis en "temps passé vs. nécessité support".
 

Jusqu'à combien d'images de type thick tu estimes qu'il est intéressant de gérer à la fois ?
 
En fait, il faudrait que j'essaie de voir combien de PCs on déploie en moyenne par an (échange, création de nouveau poste engendrant une augmentation des effectifs, prêt, formation...) et combien de temps ça met de mettre à jour un master.
 
D'ailleurs tu fais comment pour gérer les mises à jour ? Est-ce que tu t'adosses à un outil du fabricant qui t'envoie des alertes sur les mises à jour importantes de ses drivers (par exemple) ? Ou c'est une règle où tu te fixes qu'à telle et telle période de l'année tu revoies tes masters pour voir s'ils sont bien à niveau ?
Je pense qu'il faut aussi qu'on arrive chez nous à centraliser la question de tout ce qui est mise à jour de logiciel, parce qu'on n'est averti qu'au fil de l'eau, on n'a pas vraiment de moyen d'anticiper.
 
 

Exact, on s'en est rendu compte. ^^
 
 

Notre parc est consitué en grande majorité de laptops, dans une proportion d'environ 90% laptops, 10% desktops. Et on n'a pas "un" grand modèle qu'on retrouve beaucoup plus que les autres. Ou alors si, 1 grand modèle pour les desktops, et plutôt 3-4 modèles de laptops en proportions équivalentes, les autres étant dans des proportions plus faibles (négligeables) ou des modèles trop anciens qu'on, à mon avis, n'a pas intérêt à gérer car arrivant en fin de cycle de vie.
Sur la base de ces informations, tu me donnerais plutôt matière à partir sur au moins 1 master générique desktop et 1 master générique laptop.
 
Sinon ok sur la méthode où tu désactives un max de choses pour rendre l'image la plus générique possible, on n'était pas encore rentré dans cette démarche à ce point là, merci, c'est intéressant. Par contre je n'ai pas compris la partie sur les clés de registre. A quelles exemples de clés fais-tu allusion ?  
 
 

Tu veux dire que tu fais appel au script en le rajoutant dans les applications MDT ? C'est pour voir si j'ai compris de travers ou pas. ^^
 

Intéressant aussi, ça permettrait d'alléger la charger liée à cette opération de reprise d'historique.
 

Ca va j'ai survécu. C'est céjà bien cool que tu aies pris le temps de faire une réponse aussi complète ! Merci !

Interessant ce post, perso je suis parti sur un système de clonage open source mais la problématique de gestion des masters est la meme. L'avantage c'est que la descente d'image est très rapide (moins de 3 minutes sur du Gb/s pour un master de 5Go) mais ca semble moins flexible que MDT. J'ai une image indépendante au niveau matériel (une seule pour une quinzaine de matériel différents) mais pas au niveau logiciel.
 
Si je comprends bien ton post Je@nb, MDT est capable d'installer un package d'applications après la descente d'une image ??? J'ignorais totalement cette fonctionnalité qui pourrait du coup remettre en cause pas mal de chose chez nous

 
WSUS ne gère que les MAJ Microsoft. Pour le reste c'est GPO (ca dépanne mais c'est pas top) ou outil spécifique de télédistribution.
 

 
De manière générale, tout ce qui est paramétrage doit de préférence être géré par GPO, c'est plus flexible dans le temps et tu peux surtout gérer les différences de profil.

A moi de répondre
 

 
- Via WSUS tu vas pouvoir déployer que les mises à jour Microsoft. Tu as un produit, qui s'appelle SCUP http://technet.microsoft.com/en-us [...] 47.aspxqui permet d'alimenter WSUS avec des bases externes, d'éditeurs mais je crois qu'il faut obligatoirement SCCM ou SCE pour pouvoir déployer après. Pour les autres éditeurs, soit tu remplaces l'exe d'install (pour nouveau déploiement), soit outil de télédis
 
- Master thick/thin, la conception est la même, c'est juste que dans l'un tu as X grosses images déployable rapidement, dans l'autre tu as 1 image légère déployable en plus de temps (temps d'install des applis quoi). Je pense qu'il faut rester sur du thin, après la question est de savoir quoi inclure dans l'image et quoi garder en dehors. J'aime bien mettre Office, son SP et ses updates dans l'image car déployé partout, j'aime bien mettre .Net, et des applis du style. Après mettre flash qui évolue constamment c'est pas la peine (sauf si vous avez UNE version de flash ou UNE version de JVM que vous devez utiliser dans ce cas pk pas). J'ai des clients qui font des thin et qui font des master enfants pour des filiales en thick prêtes à être installées rapidement (mais là c'est plus pour des grosses infras).
 
Pour l'histoire des GPO. Déjà GPO ça veut dire que tu forces l'utilisateur à un setting. Donc si le setting doit être libre mais préconfiguré alors il est intéressant de le mettre dans le master. Maintenant tu as les GPP qui permettent de pousser des préférences. C'est pas mal mais c'est vrai que perso avoir des GPP qui configurent 100 clés de registre, créent 4 dossiers, copient 20 fichiers je trouve pas ça top.
Tout le profil utilisateur j'essaie de le faire dans le master, si il y a forcage de paramètres alors GPO (voir GPO et master).
- paramètres du navigateur ==> qq options dans le master (favoris, accelerators, and co), d'autres par GPO (sécu, proxy and co)
- fonds et économiseurs d'écran ==> je préfère dans le master, certains le font en GPP et logon script
- suite bureautique (office ?) ==> première configuration dans le package, mais reprise dans une GPO avec les évolutions éventuelles)
 

 
Dans la WIM j'intègre les dernières mises à jour Windows, Office (si dans la wim), dernières version des middleware ou applis du socle, corrections de qq bugs de l'ancien master, mises à jour du thème si besoin and co.
Pour l'update des drivers, c'est assez compliqué sans vrais outils (déjà inventaire, ensuite pour les pousser). Les principaux éditeurs proposent un catalogue SCUP pour SCCM avec leurs drivers, c'est assez nouveau, c'est déjà ça ! Mais autant sur un serveur c'est pour moi primordial de mettre à jour BIOS/Firmware/Drivers, sur un PdT, mis à part problèmes rencontrés, j'évite. L'année dernière on avait des bugs sur un touchpad Dell, la mise à jour du drivers a résolu le truc. Donc oui on l'a passé mais je pense qu'il vaut mieux avoir un parc homogène.  
Après qd tu fais évoluer ton master (et non plus le PC), oui en général faire un tour des mises à jour dispo c'est pas mal.
J'essaie aussi de faire la configuration du BIOS via MDT, au moins t'es sur que ton BIOS est bien configuré (les techs oublient souvent qq options), protégé.
 
 

 
Le nb va surtout dépendre des différents métiers ou types de population. Pour moi il en faudrait pas plus de 5 et à partir de 3 c'est gros.
 
Pour les mises à jour des drivers non j'ai rien mais la plupart du temps les clients vont sur le site et regardent. Dell a un truc qui est pas mal, c'est les packs de drivers. Sont mis à jour de temps en temps (pas du tout sur les anciens mais bon ..) et tu as tout d'un coup. Pour les softs, j'utilise sur mon pc Secunia PSI qui me donne des infos sur les failles des logiciels installés (biensur j'ai pas un pc avec toute la DSL installée ). Sinon Updatechecker est pas mal. Mais en général c'est comme tu dis, qd on refait le master, on regarde ce qu'il y a de dispo. Sur certains softs sans impacts on met à jour, sur d'autres faut l'accord MOA.
 
On essaie aussi de versionner les master. Au moment de la création de la WIM tu mets une clé de registre qq part qui dit quelle version de WIM c'est, au moment du déploiement du poste, tu mets une clé qui identifie quel master tu déploies (master = wim + socle + persos post install). Et une fois que tu as créé un package dans MDT, un script ou autre tu le touches plus. Si modif tu recrées un package, une séquence de tache (si tu veux plus des anciennes tu les désactives) mais au moins ça permet de pouvoir déployer un ancien master au cas où. (Biensur au bout d'un moment tu nettoies ).
 
 

 
Moi je préfère partir sur un master tout court . Je le builderai sur le grand modèle desktop et validerai son fonctionnement sur les laptops aussi. Sinon sur un laptop mais à tester.
Pour les clés de registre, il y a des milliers d'exemples .
Comment tu crées ton master ?
Tu installes Windows XP SP3, installe manuellement les softs, personnalise l'explorateur, menu démarrer le bureau and co, puis tu lances la séquence de tache sysprep & capture ? ou
Tu as une séquence de taches qui installe Windows XP SP3 depuis les sources en automatique, installe automatiquement les logiciels de la wim, puis après tu configures ce que tu as à configurer à la main puis tu sysprep capture ?
Ou pareil que précédemment mais tu configures tout auto par script ?
 
C'est ce dernier point dont je parle.
Par exemple, le menu démarrer, tu veux cacher "Ma musique", "Mes images", afficher en petite icone and co. soit tu le fais à la main, soit tu le fais via clés de registre directement.
 
Ce qu'on essaie de faire, c'est que la fabrication du master soit automatique. Si demain tu dois faire une version 1.1 qui change qq trucs, tu prends ta version 1.0, tu tests tes nouvelles clés de registre. OK ça marche, tu crées une nouvelle appli MDT avec les modifs, tu copies ta séquence de tache build 1.0 en build 1.1, tu ajoutes la nouvelle appli, tu fais F12 les sources de XP SP3 descendent, les applis, les scripts, ton nouveau script, sysprep capture tout automatiquement. Tu as ta WIM 1.1.
Si tu fais manuellement, 1/ Ca va prendre du temps, 2/ Tu es pron aux erreurs de manip, 3/ Faut plus documenter (là la séquence de tache autodocumente ton master puisque tu vois direct ce qui est déployé, lancé pour construire ton master).
 

 
Oui, une appli MDT c'est juste une ligne de commande, tu mets un exe, un script ou autre il s'en fou
 

 
MDT c'est un séquenceur de tache. Une des tache c'est "descendre l'image" mais tu peux avoir dans la même séquence de taches, une fois revenu sur Windows, lancer des installs de soft, lancer des scripts (activation windows, par ex), jusqu'à la fin de la séquence de taches.
 
Après une fois que la séquence de taches est terminée. MDT connait plus le poste et ne va rien pouvoir installer. Par contre tu peux créer une séquence de tache qui ne fait QUE installer des softs (pas descendre d'OS) et via une méthode de ton choix, lancer la séquence de tache (plus en tête mais un truc du genre \\serveurmdt\deploymentshare$\scripts\LiteTouch.wsf /SkipTaskSequence:YES /TaskSequenceID:nomdetaTS )

C'est vrai finalement que de mettre à jour une GPO c'est plus simple que de mettre à jour X masters.
 

Intéressant aussi, je vais regarder ce qu'il est possible de faire.
 

OK vu, donc on va arrêter de se prendre la tête à imaginer X masters, on va en garder un thin avec tout ce qui est .NET Framework, Java, MSXML etc... Et en complément on va se configurer plusieurs profils dans MDT avec les applications à installer en fonction des utilisateurs.
Bon, c'est bien tout ça, ça m'éclaire !
 

Yes, j'y vois plus clair aussi, merci.
 
 

OK pour le principe, et tu me fais penser aussi qu'on n'a pas touché au bios je crois, un oubli. ^^
 
 

OK merci pour l'échelle (3 à 5 masters grand max). C'est pour ça que finalement je pense un pour les laptopos et un pour les desktop serait pas déconnant. Je ne connaissais pas Secunia, je vais voir aussi ce que ça donne.
 
 

Ah ça aussi c'est intéressant et en plus c'est le genre d'info que tu peux remonter dans ton inventaire pour voir si ton parc est homogénéisé ou pas... J'aime !
 
 

Pour le moment c'est la méthode 2 (MDT qui installe tout, puis sysprep et capture). C'est justement la méthode 1 qu'on voulait éviter car beaucoup trop coûteuse en temps !
 

Ces détails-là, on ne les a pas encore vraiment creusé, mais pour l'instant en fait on "attend" que les GPO dont on a convenus descendent, et pour nous ça fait la config, et de ce fait ça nous met à jour l'image qu'on recapture et qu'on réenregistre sur le serveur WDS.
 
Si je comprends bien, il faudrait qu'on connaisse les clés concernées, et qu'on les préconfigure plutôt que d'attendre que les GPO fassent le boulot pour nous.
 

Clairement, le but de la mise en place de MDT c'était bien d'en finir avec toute la config manuelle, qui pouvait prendre jusqu'à 3 jours...
 
 

OK on est d'accord ^^
 
Bon hé bien , je vois encore plus clair avec tout ça, du coup je me dis qu'on est quand même encore un peu loin du résultat final même si on a bien avancé. Les points qu'on doit bosser :
- convenir de n'avoir que 2 images thin (je pense que c'est le bon compromis pour nous)
- en complément, bien définir les profils dans MDT en fonction de notre population d'utilisateur, et ça à la limite, on peut peut-être se permettre d'en mettre plus que 3 comme je pensais au début, c'est juste des séquences de tâches finalement, donc je pense qu'à mettre à jour c'est moins long
- bien gérer les clés de registre avec par exemple le modèle de master, et puis tous les détails pour lesquels on aurait tendance à laisser le boulot aux GPO
- et puis enfin bien sûr, c'est un des gros boulots qu'il nous reste, c'est de documenter !
 
Merci beaucoup

Tu me fais un peu peur avec ton histoire de GPO .
 
Ton master qd tu le crées il faut qu'il soit en workgroup, pas en domaine !
 
Sinon, pas besoin de créer une séquence de tache par "profil". Dans MDT tu crées des bundles où tu mets tes applis par profil et tu as dans le wizard au niveau des applis à installer et tu demandes à tes techniciens de cocher tel ou ou tel profil.
 
Sinon tu utilises la BDD de MDT qui est pas mal aussi

 
edit du 01/08/2011 vers 19h00
 
Bon en fait je reprends : non ça va on est en workgroup, le sysprep on le fait quand on descend l'image.
 
Il nous manque toute la partie custo à faire sur le poste, on n'a pas du tout regardé les clés de registre & co.
 
En fait on part de tellement loin (dans le sens où c'était le chaos total), que nous sommes déjà content de pouvoir délivrer des PC sans erreur d'installation, même si sur le plan sécurité et customisation ils sont à la ramasse. Mais clairement, il nous reste du chemin à parcourir !
 

Yep pour le profil, là on s'est compris, c'est moi qui me suis mal exprimé.

Je me permet d'intervenir sur un point :

Utilisant Clonezilla, en faisant 1 image par type de machine (ça va, sur un parc de 200 machines hors serveurs, cela fait 4 types de machine), en ne faisant aucune distinction d'utilisation (pouf tout le monde possède le même environnement logiciel) cela permet de faire du zero touch avec une installation en 15 minutes maxi.
 
Après pour les mises à jour :
- pour Windows on laisse faire le WSUS
- pour les logiciels autres (Firefox, OpenOffice,...) utilisation d'OCS Inventory et de scripts de désinstallation puis d'installation -> sur ce point, si quelqu'un connaît sous Windows XP Pro/compatible 7 Pro, un logiciel en lignes de commande pour faire un nettoyage à la CCleaner, je suis preneur  
- pour les drivers, on "laisse mourir"
 
S'il y a un besoin d'un logiciel particulier, on installe après coup, et dans OCS on déclare tel {ensemble de machine} doit recevoir tel {logiciel}.

 
ICSweep ?

attention, troll
un master = ça ne sert à rien
Perso je ne vois pas d’intérêt à faire des master...

cool

Parfais pour les fichiers temporaires, mais rien pour la base de registre
(pas la peine de me proposer Regcleaner, il est assez peu performant )

Drapal  

Update
 
Notre serveur WDS est en place, nos masters sont finalisés, on les utilise, et on a repéré les premiers bugs (drivers cartes graphiques qui provoquent des BSOD). On les descend, on les corrige et on refait une capture, pour les postes déjà déployés on prend rdv avec les utilisateurs pour corriger en fonction de fichier d'inventaire qu'on entretient.
 
On a relativement peu d'applis métiers mais on a quand même pris en compte quelques clés de registre à paramétrer pour nos masters.
 
Les autres trucs auxquels on a aussi probablement besoin de faire des progrès c'est de mettre à dispo des petits utilitaires gratuits pour le quotidien, comme les logiciels permettant de faire des captures d'écran précises simplement, etc...
Et sur la sécurité de l'environnement, des trucs tout cons comme protégé le BIOS par un mot de passe, on ne fait pas à l'heure actuelle, mais on a la chance d'avoir des users très peu "bidouilleurs", alors on ne s'occupe pas de ça en priorité.
 
Prochains axes d'amélioration
 
En relation avec le cycle de vie des postes de travail, on va essayer de rationaliser les commandes pour diminuer progressivement le nombre de modèles de pc différents dans le parc (une 15aine à l'heure actuelle, sans compter les différents product numbers...) afin de réduire le nombre de masters à créer/entretenir.
 
On réfléchit aussi à un moyen de conserver des masters davantage à jour que ce qu'on propose à nos utilisateurs actuellement. En gros, on essaie de réfléchir à une solution pour éviter de descendre chaque masters tous les 3 ou 6 mois, descendre els derniers patches Windows, puis recapturer l'image ainsi mise à jour, car avec le nombre de masters qu'on a, c'est assez lourd.
On a trouvé quelque chose qu'il nous reste à tester : utiliser un ESX de petite taille, chaque master étant alors virtualisé pour rester "en ligne" sur la domaine, et pour recevoir ainsi les mises à jour déployées par WSUS. Les VM peuvent être ensuite converties avec vCenter Converter pour être descendues à nouveau sur les machines physiques.

ohhhh, déjà ca me plait déjà un peu mieux comme principe
super bonne idée à vous en tout cas.

Sympa l'idée et tout con en fait.
 
Par contre du WIM n'irait pas pour une telle utilisation ?

Pour des master Win 7 tu as avec MDT 2012 l'offline servicing intégré pour mettre à jour tes images directement. Je sais plus si ça s'intègre à WSUS par contre ou s'il faut mettre les maj soit même.

Qu'entends-tu par là ? En fait le principe c'est justement de ne pas avoir à gérer le format WIM, à l'éditer etc. Si j'ai pas compris ton message, ça peut arriver, n'hésites pas à détailler.
 

J'espère qu'un jour ils vont se résoudre à débloquer les budgets nécessaires à une migration vers Win7 (c'est un projet que j'aimerais beaucoup mener en plus).

A noter que l'utilisation d'une solution de virtualisation d'application "APPV pour mon cas" permet de faire gagner énormément de temps sur le déploiement avec MDT, Jean annonce 1H30 alors que moi j'annonce 17min pour un poste typé "bureautique+dev" sous Windows 7x64.
"OFFICE 2010 PRO - FIREFOX 9+PLUGIN- JAVA - ADOBE FLASH - READER - QUICKTIME - APPLI MAISON  " tous dans la bubulle , le reste des packages persistants reste déployé avec MDT , exemple le client APPV et les librairies visual C++, Eclipse  JAVA .
Le gain lors des mises à jours reste appréciable.
Les suites Adobe sont déployables facilement avec MDT (la CS5 est un vrai bonheur,intégration des MAJ dans le Package de déploiement), et la plupart des logiciels "opensource" peuvent être packager ou virtualisable via "APPV". Seul le temps de déploiement et le rythme des mises à jours vous fera choisir l'un ou l'autre.
Pour le moment la plupart des logiciels qui pose problème sont les suites "comptabilité"  , un bordel d'installation infinie . La effectivement le master prend tout son sens.

Dans ce cas, effectivement faire des masters pour du clonage

Je suis pas sûr qu'on se comprenne, l'idée c'est juste de maintenir à jour le socle (ou master "thin" ) pour garder un niveau constant (autant que possible) de patchage sur le parc. Après, ce master thin on le convertit, on le déploie, et on passe MDT dessus pour le personnalsier en fonction du profil utilisateur.
 
Bon, ça reste une idée pour le moment, on n'a pas encore mis en oeuvre.

Ça serait un beau projet effectivement  

 
Quand je pense qu'il yen a qui jure encore que par windows XP ça reste impressionnant ^^
 
 

Tout comme NT4 en son temps, puis 2000 Pro... quand on a un OS :
- stable
- avec un suivi assez long par Microsoft
- avec des logiciels qui ne réclament pas un Windows 7 pour être installé ou mis à jour (antivirus notamment)
- avec du matos dont il existe des drivers pour XP
Pourquoi changer ?
 
C'est comme ceux qui roulent dans de vieilles bagnoles qui ont 300.000 ou 400.000 bornes, tant que la carcasse tient, le moteur tourne, qu'on trouve des pièces, pourquoi acheter du neuf
 
Perso je préfère voir une boîte avec de l'XP Pro, plutôt que Vista Business ou du 7 Home Premium comme ça se fait parfois.

Mais malheureusement souvent les machines vont de paire avec l'os et là, pour xp, ça commence à faire vieux avec toutes les défaillances matériel que ça implique

Ceux qui roule en vieilles bagnoles c qu'il peuvent le plus souvent pas s'en payer une autre hein ^^
Quand tu roules dans une audi a6 , tu voudras surement pas  repartir avec une 205 par la suite . 200000 ou 400000km .

XP a fait son temps , un temps un peu long et il était vraiment temps qu'il soit pousser vers la sortie vu les rustines implémentées depuis qques années.

Quand tu roules dans une vieille merco ou BMW de la fin des années 90 ou les années 2000, tu vas pas repartir sur de la 308  

Ah bon ?  
Quoi comme défaillance matérielle ? Qui peut le plus peut le moins, que ce soit niveau processeur ou carte graphique il n'y a pas de changement.
La seule vraie raison qui peut pousser à partir d'XP pour du 7, c'est la RAM et donc la version 64bits de 7.

Malheureusement beaucoup de gens ayant longtemps travaillé sous XP/2003 ne parviennent pas à basculer sur la génération suivante (aussi bien pour des raisons humaines que techniques).

y'a quand meme pas mal de freins à la migration sur Seven : des progiciels incompatibles, des utilisateurs à former sur la nouvelle interface etc...

Pas plus que les précédents OS. Mais l'écart inhabituel entre XP et Vista a fait très mal.

La bonne nouvelle c'est qu'on descend enfin, lentement mais sûrement, au niveau des clés de registre dans la configuration de nos masters :
- pour un logiciel financier qui pose des problèmes d'install mais qui n'est plus supporté par l'éditeur, on a trouvé un moyen de contourner le problème en 'préinstallant' quelques clés,
- pour l'inclusion du logo en page de démarrage,
- pour faire que la touche tab du clavier permette dans la fenêtre de commandes ms dos de servir à la recherche/complétion des premiers caractères entrés,
...

Pour l'instant c'est une vision plutôt pratique et esthétique qu'on a mais on est encore loin de maîtriser les aspects sécuritaires ou véritablement de "tuning" des postes.

Quelles sont à votre avis les clés incontournables à prendre en compte pour aller vers plus de sécurité/qualité ?

Mis à part ça, on est en bonne voie pour renouveler 1/4 du parc de pc, ce qui va permettre de dégager des vieux trucs et de commencer l'effort de standardisation (ça devrait dégager grosso modo 5-6 modèles de pc pour en faire arriver 3 à la place, on y gagne).

Chose oh grandement utile (si un jour tu as l'occasion de passer dans une brigade de Gendarmerie, demande à voir l'écran d'accueil des machines sous Ubuntu)
 

ça il faut plutôt éplucher les recommandations de Microsoft par rapport ton environnement réseau, notamment si ces clés tu ne peux/veux les descendre par GPO.

N'est-ce pas ?
 
L'idée c'est simplement d'améliorer la qualité perçue, et puis ça fera plaisir à la Direction de la Communication (ils étaient contents déjà quand on avait inclus l'économiseur d'écran "corporate" ).
 

Je serais plutôt d'avis de les inclure directement dans les masters effectivement, bien qu'après il y ait un historique (PC déjà déployés) à reprendre par GPO/script. Ok je vais voir ce que propose MS, je n'étais tombé que sur des sites styles blog informatique...

Seul conseil... fait le plus simple et le plus standard possible.
Logo en page de démarrage aucune valeur ajoutée à l'entreprise.
Seul satisfaction personnelle de l'admin.

pas d'accord du tout, logo au démarrage, ça à selon moi l'effet psychologique que l'outil de travail appartient à l'entreprise et non au salarié. Les commerciaux ont par exemple la vilaine habitude de vouloir s'approprier le PC portable, "c'est leur PC". non non ! C'est le Pc de l'entreprise.
et ça fait plus "pro", +1 avec fookooflakman.
 
Par contre, oui je suis à mort pour le standard.

Le logo au démarrage, 95% des users s'en foutent royalement.
Dans ce cas, autant plutôt mettre un fond d'écran "par défaut" avec un verrouillage pour qu'un utilisateur ne puisse pas en changer, ça se fait uniquement par la base de registre.
 
Aujourd'hui j'ai installé une version "corporate maison" d'un Windows 7, qui nous a été fourni "tel quel" avec une doc simple, en gros clic clic français français french ( ) 20 minutes pour l'image et 15 redémarrages plus tard (1 logiciel installé = 1 redémarrage je ne savais pas qu'il fallait redémarrer pour installer 7Zip ou Outlook, enfin bon) pour au final avoir le mot de passe admin qui passe pas et une grosse erreur d'accès au domaine (alors que "d'après la doc" le système devait faire l'inscription au domaine tout seul)
Après inscription manuelle via le contrôleur de domaine secondaire que l'on a et une réinstallation du bouzin, ça fonctionne. Pour que cela "marche" sur un PC neuf, il me faudra donc 1h30.
 
Donc bon, je perdrais au final plus de temps à faire par un installateur "soit disant" automatisé et bourré "d'optimisation" du genre de l'écran d'accueil, que de partir d'un Windows nu pour le faire  
 
Du master oui, du master avec des soit-disantes optimisations non

 
Les best practices c'est de ne surtout pas bidouiller les clés de registre une par une pour obtenir un master    
C'est le meilleur moyen d'avoir un maximum d'emmerdes lors des migrations/mises à jour.
 
Quelques solutions :
- Centraliser au maximum la configuration via GPO/GPP pour faciliter la maintenance, le suivi des changements et l'audit.
A la rigueur passer par des GPO locales au niveau du master.
- utiliser des templates de sécurité
 
De même bricoler le registre pour avoir l'autocomplétion sur le cmd, ça me semble dangereux pour un intérêt dérisoire (à moins d'avoir des gens qui travaillent sous DOS toute la journée...)
 
Et le logiciel financier (donc très critique) bricolé car non supporté, c'est prendre de très gros risques (mais vous n'avez peut-être pas le choix...).
 
Je pense qu'il faudrait déjà vérifier la sécurité que vous pourriez mettre en place à un niveau global (par exemple personne n'a de droits administrateurs, stratégie de mot de passe pertinente, sécuriser les connexions NTLM...) avant de partir dans le détail.