IACA

Version 10. Auteur A. Sayer


Documentation >Multisite


Plusieurs sites dans un domaine


Présentation

Votre domaine comporte plusieurs serveurs répartis dans des lieux géographiques (sites) différents. Vous allez pouvoir séparer les dossiers personnels suivant les sites. Cela va par exemple permettre aux utilisateurs d'un site d'avoir leur dossier personnel sur le serveur ou les serveurs de leur site. Le trafic réseau restera local au site. Cela n'empêchera pas à ces utilisateurs d'ouvrir la session sur un ordinateur d'un autre site, mais dans ce cas le trafic réseau entre sites ralentira certainement les accès.

Si un utilisateur change de site, IACA pourra le déplacer de son ancien site vers le nouveau, il ne perdra pas son travail.

Si par exemple vous voulez que les dossiers personnels des élèves et des professeurs soient sur des serveurs différents, vous pouvez traiter votre établissement comme deux sites. Le site des professeurs contiendra les professeurs ainsi que les ordinateurs habituellement utilisés par eux. Le site des élèves contiendra les élèves ainsi que les ordinateurs habituellement utilisés par eux.

La création des utilisateurs de tous les sites se fera sur un serveur et sera automatiquement répliquée vers les autres serveurs du domaine.

A l'intérieur d'un site qui possède plusieurs serveurs, vous pouvez mettre en place DFS et profiter de la répartition de charge et de la tolérance de passe comme pour IACA Pro.

Licence Multisite

La version standard et la version Pro fonctionnent avec un site. Le site se nomme "Site par défaut".

Pour pouvoir créer un site supplémentaire dans IACA vous devez disposer d'une licence Multisite. Voir la rubrique "Commander" et "Bon de commande" pour les tarifs.


Site au sens IACA et site au sens Microsoft

Microsoft permet de créer des sites et de répartir les serveurs et les stations dans les différents sites. Ceci est utile lorsque la liaison réseau entre les sites est lente. La réplication entre les serveurs de différents sites est plus lente qu'entre serveurs d'un même site. La gestion des sites au sens Microsoft se fait en utilisant "Sites et services Active Directory".

Il n'est pas nécessaire pour IACA de définir des sites au sens Microsoft et de répartir vos serveurs dans ces sites. Vous pouvez laissez tous vos serveurs dans le site "Premier-Site-par-défaut" et placez avec IACA vos serveurs dans des sites différents (sites au sens IACA).


Créer un nouveau site

Dans IACA, allez dans "Sites" et "Ajouter un site". Vous êtes alors invité à saisir le nom du site et indiquer le type de site que vous voulez créer. Deux types de site sont proposés. Prenez le temps de bien choisir car il serait difficile de changer de type ensuite.

Choix du type de site

Site de type normal

Un tel site contient un ou plusieurs serveurs, des ordinateurs et des utilisateurs. Le site "Site par défaut" est un exemple de site de type normal.

Ce type de site est bien adapté lorsque les utilisateurs de ce site viennent essentiellement sur les ordinateurs de ce site. Si un utilisateur d'un autre site vient sur un ordinateur de ce site alors il accèdera à son dossier personnel qui se trouve sur un serveur du site auquel il appartient. Cela génèrera du trafic réseau entre les deux sites.

Si vous possédez plusieurs serveurs dans ce site, vous pouvez utiliser DFS pour répliquer les différents dossiers de iaca entre les serveurs de ce site. Vous ne devez pas utiliser DFS pour répliquer les dossiers de iaca de ce site avec les dossiers correspondants d'un autre site.

Vous aurez ensuite à indiquer un nom court pour ce nouveau site. Le choix du nom court est important car il sera utilisé dans les noms de groupe du site afin de ne pas risquer d'entrer en conflit avec les groupes des autres sites.

Site de type annexe

Il s'agit d'un site qui dépend pour les utilisateurs d'un site maître (un site de type "normal").

Un site annexe ne contient pas d'utilisateur. Il utilise les utilisateurs du site maître dont il dépend. Il contient un ou plusieurs serveurs et des ordinateurs.

Ce type de site est bien adapté lorsque les utilisateurs se déplacent beaucoup entre le site maître et le site annexe. Si la connexion est lente entre les deux sites, il se peut que DFS mette un peu de temps pour répliquer. Cela peut être gênant si l'utilisateur passe très rapidement d'un site à l'autre.

Les utilisateurs sont définis dans le site maître. Les dossiers personnels et les dossiers Classes doivent exister sur au moins un serveur de ce site et être liés par DFS avec les dossiers correspondants du site maître. Si vous utilisez, DosSup vous devez le lier avec le DosSup du site maître.  Si vous utilisez Depose il n'est pas obligatoire de lier ce dossier avec celui du site maître.

Attention : Le dossier Parciaca du site annexe ne doit pas être répliqué avec le dossier Parciaca d'un autre site. Vous pouvez cependant utiliser DFS pour lier les dossiers Parciaca entre les serveurs d'un même site.

Un site de type annexe n'a pas de nom court.

Un site de type normal peut avoir plusieurs sites annexes. Un site annexe ne peut être annexe que d'un site normal.

Site de type "Sans serveur"

Il s'agit d'un site contenant des utilisateurs et des groupes. Les utilisateurs n'ont pas de dossier personnel, ni de dossier classes... Il n'y a pas non plus de dossier Parciaca pour gérer les stations. 

Création du site

En validant, le fichier Domaines.xml est mis à jour et un dossier au nom du site est créé dans C:\Windows\SYSVOL\Domain\IACA.

Dans IACA, vous pouvez voir trois entrées pour ce site : "Computers", "Servers" et "Users".

Computers

Lorsqu'un utilisateur ouvre la session sur une station, le client IACA commence à l'aide du fichier Domaines.xml par déterminer à quel site appartient la station. En fonction du site, il connaît les serveurs et leurs rôles. Il accède alors au fichier Parcs.ini d'un serveur du site et recherche ensuite dans ce fichier à quel sous-parc appartient la station.

Le volet "Computers" comporte deux parties :

Critères déterminant l'appartenance des stations au site

Comme les stations ne sont plus toutes dans un seul site, vous devez indiquer pour chaque site les critères permettant à IACA de savoir à quel site appartient chaque station.

Lorsqu'un seul site est utilisé le critère est * afin d'indiquer que toutes les stations sont dans le même site. Avec plusieurs sites ce paramétrage ne convient pas.

Placez-vous sur "Computers" du "Site par défaut" et utilisez le bouton "Modifier" afin de corriger les critères.

Supprimez l'étoile dans "Nom des stations" et indiquez le critère qui caractérise les ordinateurs du "Site par défaut". Aidez-vous des boutons "?" en particulier celui correspondant au Chemin LDAP vous indique comment ajouter ou supprimer un chemin LDAP.

Pour le deuxième site, indiquez le critère qui caractérise les ordinateurs de ce site. Comme un ordinateur ne peut pas appartenir à deux sites, il appartiendra au premier site qui convient même si d'autres sites placés après ont des critères qui conviendraient.

Il est possible d'utiliser plusieurs critères pour définir un site, il suffit alors qu'un des critères corresponde pour que la station soit considérée comme appartenant au site.

Exemple :

Dans "Utilisateurs et Ordinateurs Active Directory" vous créez une OU que vous nommez "Stations" puis dans cette OU vous créez une OU "Site par défaut" et une autre "Site 2". Vous placez les ordinateurs du site par défaut dans l'OU Site par défaut et les ordinateurs du deuxième site dans l'OU Site 2.
Vous pouvez alors indiquer pour le premier site le chemin LDAP qui pourrait ressembler à
OU=Site par défaut,OU=Stations,DC=mondomaine,DC=priv
Et pour le deuxième site
OU=Site 2,OU=Stations,DC=mondomaine,DC=priv

Autre exemple :

Vous placez les ordinateurs dans des OU qui correspondent aux salles (ou aux sous-parcs). Vous aurez alors peut-être besoin de plusieurs chemins LDAP pour la définition de chaque  site.

Définition des sous-parcs pour ce site

A l'intérieur de chaque site, les stations seront regroupées en "sous-parcs". Vous pouvez éventuellement utiliser les mêmes noms de sous-parc dans plusieurs sites.

Servers

Chaque site doit posséder au moins un serveur. Au moins un serveur de chaque site doit être contrôleur de domaine. Le programme IACA doit être installé sur un moins un contrôleur de domaine de chaque site.

Indiquez pour chaque serveur les rôles et les dossiers hébergés.

Users

Chaque site de type normal possède sa propre liste d'utilisateurs. On veillera à ne pas avoir un même utilisateur présent dans les fichiers de deux sites.

Changer un utilisateur de site

Supposons que l'utilisateur A est actuellement dans le site "Site1" et que cet utilisateur n'est plus dans les fichiers à utiliser lors de l'importation du site "Site 1" mais qu'il est maintenant dans les fichiers à utiliser lors de l'importation du site "Site 2".

Cet utilisateur va être déplacé, pour cela il suffit de faire l'importation et la mise à jour des comptes des deux sites. Peu importe dans quel ordre.

Si vous commencez par importer et mettre à jour le site "Site 1"

Lors de l'importation et de la mise à jour des comptes du site "Site 1", l'utilisateur A est désactivé. Ne le supprime pas.

Lors de l'importation et de la mise à jour des comptes du site "Site 2"., l'utilisateur A est déplacé (avec son répertoire personnel) et n'est plus désactivé.

Si vous commencez par importer et mettre à jour le site "Site 2"

Lors de l'importation et de la mise à jour des comptes du site "Site 2"., l'utilisateur A est déplacé (avec son répertoire personnel).

L'importation et la mise à jour des comptes du site "Site 1" n'est pas nécessaire.

En résumé

Lorsque des utilisateurs sont déplacés dans les fichiers à utiliser lors de l'importation parce qu'ils ont changé de site (par exemple des élèves de collège qui entrent au lycée ou qui changent de collège), il suffit de faire l'importation et la mise à jour des comptes des sites sans se préoccuper de l'ordre des sites. Attendez cependant que la mise à jour des comptes d'un site soit terminée avant de de faire l'importation et la mise à jour des comptes d'un autre site.


Administrateur de site

Utilisez au moins la version 10.46 de IACA.

Il est possible de donner des droits réduits aux administrateurs des sites. Lorsqu'un administrateur de site utilise IACA, il peut :

Voir les arborescences Compteurs, Servers et Users de tous les sites.

Accéder à "Définir les sous parcs" et avoir un accès complet aux sous-parcs de son site.

Créer des utilisateurs standards.

Vous pouvez les créer dans Active Directory ou à l'aide de IACA.

Attention, ces utilisateurs ne doivent pas avoir les droits d'administrateur. Prévoyez un compte par personne qui jouera le rôle d'administrateur de site. Si une personne agit sur plusieurs sites, elle n'a besoin que d'un compte. Choisissez des noms qui ne risquent pas d'être utilisés ailleurs. Par exemple l'administrateur du site Victor Hugo pourrait s'appeler ADMSITEHUGO. 

Si vous souhaitez créer ces utilisateurs avec IACA, placez-vous sur le site par défaut et allez dans "Définir la liste des fichiers à utiliser lors de l'importation". Ajoutez une table de type "Utilisateurs particuliers". La table pourrait par exemple s'appeler ADMINSITES et contenir ADMSITE1, ADMSITE2.... Il serait également possible d'utiliser les comptes Admin1, Admin2...
Faites l'importation et la mise à jour des comptes. Attention les mots de passe doivent être masqués pour ces comptes, en effet les administrateurs de sites peuvent voir tous les mots de passe non masqués.

Autorisez ces utilisateurs à ouvrir une session sur les contrôleurs de domaine.

Cela se fait sans IACA. Allez dans "Gestion des stratégies de groupe"

Dans votre domaine, recherchez "Objects de stratégie de groupe". Faites un clic droit sur "Default Domain Controllers Policy" et choisissez "Modifier" (Ne confondez pas avec "Default Domain Policy").

"Configuration ordinateur" > "Paramètres Windows" > "Paramètres de sécurité" > "Stratégies locales" > "Attribution des droits utilisateurs".

Ajoutez ces utilisateurs (si ces utilisateurs sont par exemple dans le groupe ADMINSITES, mettez simplement ADMINSITES) à ces deux endroits :

"Autoriser l'ouverture de session par les services bureau à distance"

"Permettre l'ouverture d'une session locale".

Donnez le droit administrateur de site

Avec IACA, placez-vous sur un site et allez dans "Paramètres > Définir des administrateurs pour ce site". Donnez le nom de l'utilisateur. Par exemple ADMSITE1. Faites de même pour les autres sites.

Résultat

ADMSITE1 peut ouvrir la session sur n'importe quel contrôleur de domaine. Dans la pratique il utilisera essentiellement un serveur de son site.  Il n'a pas les droits d'administrateur et ne peut pas se donner ce droit. Il peut utiliser IACA pour créer, modifier, supprimer des sous-parcs dans son site.


Devoirs et EnvoiMsg

Ces programmes peuvent distribuer des documents ou des messages aux utilisateurs d'un site. Le site est déterminé par le serveur utilisé pour exécuter le programme. Voici un exemple pour aider à comprendre le fonctionnement :

Supposons que le professeur DUCHEF ait le droit de distribuer des devoirs aux élèves du "Site A" et du "Site B". Lorsque ce professeur souhaite distribuer des devoirs aux élèves du site A, il doit utiliser le dossier NETLOGON d'un serveur du "Site A" pour trouver et exécuter le programme Devoirs. Lorsqu'il souhaite distribuer des devoirs aux élèves du site B, il doit utiliser le dossier NETLOGON d'un serveur du "Site B" pour trouver et exécuter le programme Devoirs.

Si le professeur essaie de distribuer un devoir à un élève du site B alors qu'il utilise le programme Devoirs situé dans le dossier Netlogon d'un serveur du site A alors il recevra une erreur indiquant que le dossier personnel de l'élève n'a pas été trouvé.


Cas d'un domaine avec beaucoup de contrôleurs de domaine

Depuis la version 10.59 de IACA la création du fichier cache.ldap est faite par le service IACA sur les serveurs.

Si votre domaine contient plus de 5 contrôleurs de domaine modifiables (donc des DC et non des RODC) et qui sont serveurs IACA, vous pouvez optimiser le travail des services IACA qui tournent sur les serveurs.

Chaque service lit toutes les 5 minutes Active Directory et si un changement a eu lieu, met à jour le fichier Cache.ldap qui est dans Netlogon. La réplication des Netlogon permet à tous les contrôleurs de domaine de récupérer le fichier mis à jour.

Il n'est donc pas nécessaire que tous les contrôleurs de domaine fasse ce travail. Un seul pourrait suffire à condition qu'il ne soit jamais en panne ou trop occupé. Une bonne pratique consiste à laisser 4 ou 5 contrôleurs de domaine faire ce travail.

Si vous ne précisez rien, tous les contrôleurs de domaine feront ce travail. Pour indiquer qu'un contrôleur de domaine n'a pas ce travail à faire, vous pouvez avec IACA dans "Paramètres > Paramètres divers", volet "Divers" indiquer la liste des serveurs du site qui n'auront pas ce travail à faire.