Gestion des groupes Ferme RDS

Salut,

C'est cool les fermes RDS, mais c'est capricieux.
Aucun droit Admin Local pour les Users ne doit être permis.
Les mises à jour Software doivent être harmonisées sur tous les membres.

Dans l'idéal, il faudrait stocker les UPD dans 2 serveurs de fichiers différents, en réplication synchrone, dans le cas d'une infra montée en Cluster.

Et les stratégies de groupe sont indispensables.

- Mask Local Drives pour tous les Users sauf le groupe Domain Admin

- Map Share Folders

- Mount Printers

Et il y en a plein d'autres.
Bien-sûr, il faut appliquer par groupe de sécurité, jamais par User, même s'il n'y a qu'un seul User dans le groupe.

Il existe les GP-Preferences qui font ça bien.
Surtout grâce au "Ciblage au niveau de l'élément" (image ci-dessous), qui permet d'appliquer une stratégie selon de nombreux critères disponibles.
Security Group évidemment, mais aussi type de machine, site distant, plage horaire...

Bon courage.

Hello,

Effectivement les GPOs sont indispensables.

Par contre sur quels groupes appliquer ces GPOs ... je préconise de faire un groupe par application/publication.

1. Le groupe porte le nom de la publication en gros (G_RDS_APP_Notepad par ex), puis on imbrique le groupe de l'équipe en tant que membre de ce groupe de publication. Ne surtout pas cibler directement un groupe d'équipe.

2. Distinguer les groupes de publication des groupes de configuration/personnalisation des environnements Users sur cette ferme RDS (ex de config indiquée juste sur le post précédent).

Ne pas oublier de "Deny" l'application de certaines configurations de Hardening pour les administrateurs de la ferme RDS.

3. Dernier point essentiel, il faut absolument utiliser le "loopback processing" (je dirai même que c'est obligatoire).

Cela permet de configurer les environnements utilisateurs, en ciblant uniquement les machines de la ferme RDS.

Il faut utiliser dans la plupart des cas, le mode "Replace" pour les confs sur des fermes RDS (et Citrix en somme).

Si on n'utilise pasle loopback processing, cela va configurer les sessions des users peu importe la machine sur laquelle ils se connectent... et pour le coup c'est assez handicapant sur un poste de travail classique. (dans la mesure où on parle de profils RDS).

https://www.it-connect.fr/chapitres/gpo-loopback-processing/

@+

Bonjour et merci pour vos retours.

Vos informations sont bien utiles.

Cependant, ma question porte dorénavant sur la gestion des groupes RDS.

A savoir, doit-on faire des groupes par applications? par service? J'ai un peu de doute sur la façon de mettre en oeuvre cela pour être le plus pro possible.

merci!

Bonjour,

J'ai répondu en point 1.

1 Groupe par publication (publication = une application publiée).

Il est possible de publier la même application à plusieurs type de population ...

Surtout pas par service. Le groupe du Service sera ensuite membre des groupes des publications.

C'est le même principe que pour des partages, on créé toujours un groupe pour la ressource partagée et son type de droits (DL_NAS_SERVEUR1_DOSSIER1_Lecture par ex) , jamais le groupe d'équipe directement dans les ACLs du partage.