Question [AD] Problème suppression user groupe

Richard Lazaro écrit:

Perso, j'aime pas installer les cmdlet Quest car cela \"dégrade\" le système et certains clients peuvent l'interdire.

Il s'agit d'un snappin. Je serai intéressé de savoir quelle \"dégradation\" entraine l'installation de ces Cmdlets sur un poste ou un serveur d'administration ?

J'ai déjà vécu des \"blocages clients\" sur certains choix ou certaines techno, trop souvent sans vraiment que cela soit argumenté... C'est parfois dommage et souvent frustrant

Je trouve qu'il est préférable de savoir jouer avec ADSI plutôt que les cmdlet Quest.

Je suis d'accord sur le fait qu'il faut savoir se servir de ADSI.

Mais avouons que cela peut apporter pas mal de simplifications dans l'administration d'un AD.

Après, dans un environnement en 2008 R2, il n'y en a clairement plus besoin.

Pour info, un article sur ce sujet .

En fait, je trouve cette discussion très intéressante !

@ +

Matthew<br><br>Message édité par: Matthew BETTON, à: 9/05/12 19:05

Je n'ai pas le même jeu de donné que cette personne mais dès que j'ai du temps, je fais le bench en ajoutant l'ADSI.

Pour Quest, le problème est que tu installe un software sur une machine. Alors soit c'est pour une intervention ponctuelle et ils veulent bien de faire une VM.

Sinon, les grands groupes utilisent les RFC et donc ... ça devient la merde pour un petit changement. Ils preferent donc ne pas le faire.

Intégrité des postes en gros.

Richard Lazaro écrit:

Sinon, les grands groupes utilisent les RFC et donc ... ça devient la merde pour un petit changement. Ils preferent donc ne pas le faire.

Intégrité des postes en gros.

J'ai avancé l'idée de mettre powershell v3 à la Roadmap de cette année par exemple après avoir une RFC justement... j'ai pris un gros Point de non retour. Alors imagine si je demandais à valider le module de Quest sur tous les datacenter

C'est pour ça que je suis d'accord sur le fait d'utiliser un maximum les outils \&quot;natifs\&quot; et donc que je préfère de part ce fait Windows 2008R2 pour faire joujou en powershell !

@+

Richard Lazaro écrit:

Je n'ai pas le même jeu de donné que cette personne mais dès que j'ai du temps, je fais le bench en ajoutant l'ADSI.

Pour Quest, le problème est que tu installe un software sur une machine. Alors soit c'est pour une intervention ponctuelle et ils veulent bien de faire une VM.

Sinon, les grands groupes utilisent les RFC et donc ... ça devient la merde pour un petit changement. Ils preferent donc ne pas le faire.

Intégrité des postes en gros.

Si c'est juste pour une RFC c'est bien dommage.

Moi j'adore les RFC Cela permet d'être carré.

Ce n'est pas le premier client pour qui je travaille et en règle générale, nous pouvons installer ce genre d'outils au moins sur un ou des serveurs d'admin (TSE ou ferme RDP). Effectivement il s'agit souvent de machines virtuelles. Je ne vois pas comment faire de la production sans ce type de moyen à disposition... Et dans le RUN, il faut savoir gagner du temps (sans non plus mettre la production en l'air : mais là, je ne vois pas où est le problème).

Pour la petite histoire, je me suis vu refuser une fois l'installation et l'activation de WinRM, pour des raisons de sécurité.... J'avais pourtant bien argumenté (domaine, kerberos, possibilité de ne laisser que le listner https, etc...). Finalement, cela ressemblait plus à \&quot;la peur de l'inconnue\&quot;, car je n'avais pas eu de réelle argumentation.

@+
Matthew

Deplus, passer par l'ADSI permet d'éviter un prérequis et donc une source d'erreur

Bonsoir,

Richard Lazaro écrit:

Deplus, passer par l'ADSI permet d'éviter un prérequis et donc une source d'erreur

Pour de l'administration, de l'exploitation de tous les jours je ne trouve pas utile d'avoir à re développer des scripts, fonctions ou Cmdlets.

Tout dépend du contexte.

Aujourd'hui, par exemple, mon responsable m'a demandé de lui exporter la liste des comptes d'ordinateurs récents avec certains attributs, dans un csv. La ligne m'a pris 5 secondes à saisir.

Idem pour recopier les membres d'un groupe dans un autre groupe. Une ligne, un pipe et hop.

Nous n'avons pas à déployer le pré requi sur tous les postes d'admin. Le mien suffit.

Pour un script évolué, je serai plutôt de ton avis : éliminer les pré requis.

Aussi, s'il s'agit vraiment d'un problème de pré requi, cela peut se tester dans le script

S'il s'agit de pré requi, dans ce cas le problème peut être le même si tu développes des modules : il faudra les déployer sur toute machine sur laquelle sera exécuté le script. Il est vrai qu'il n'y aura pas besoin d'installer un package. Mais ici on parle d'un snappin, pas d'un logiciel qui apporte ou met à jour des DLL dans le répertoire system32 ou bien modifie des paramètres système dans le registre...

Bref, encore une fois, je pense que cela dépend du contexte d'application.

J'aimerai toujours pouvoir profiter des architecture dernier cri, mais tous les clients ne sont pas encore passé à 2008 R2 (!). Alors nous nous adaptons

@ +

Matthew