Le document Setup de la base Desktop Project contient les paramètres nécessaires à la mise en oeuvre des projets, tant au niveau des administrateurs pour les actions à réaliser côté serveurs (création des répliques, changement dans le NAB, modification des LCA) que des Agents Project X s'exécutant sur les postes des utilisateurs (choix des paramètres utilisateurs à changer).
Pour créer un document de Setup, il convient de se placer dans la vue Administration / Projet setup de la base Desktop Project et de cliquer sur le bouton
.
Le document Setup doit exister dans la base Desktop Manager Project en un seul exemplaire. Il est définit par un nom unique (Setup Name).

Son contenu est séparé en 4 onglets, 1 par projet (Local Replica Mode, Change Mail Server, Move Database) et 1 pour la gestion pour les agents d'administration (Automatic Actions)
Project 1 : Local Replica Mode
Ce premier projet permet de créer une réplique local de la BAL de l'utilisateur et de forcer l'utilisation du mode local repliqué. Ceci nécessite d'importante modification au niveau du poste client.

: La réplique locale de la boite aux lettres de l'utilisateur peut être créée dans le même sous répertoire que la boite aux lettres sur le serveur, soit dans un répertoire dédié que l'administrateur doit préciser dans le champ "Folder Name". Si ce champ est laissé vide, la boite aux lettres sera répliqué à la racine du répertoire data de Notes.
: Chiffrement ou pas de la base en local.
: Il est possible de définir si le système doit créer une réplique local du Dircat dans le même processus que pour la boite aux lettres.
: De la même manière que pour la réplique local de la BAL, il est possible de définir pour le Dircat son emplacement en local. Soit avec le même chemin que sur le serveur soit dans un chemin défini par l'administrateur. Si le champ est laissé à vide la réplique sera créée à la racine du répertoire Data de Notes.

Cet étape du projet va créer une réplique local de la boite aux lettres de l'utilisateur ( avec le Dircat si cela a été configuré avec les options ci-dessus).
: Formule (de type @Formula) pour lister les documents sites à modifier dans le carnet d'adresse local de l'utilisateur pour configurer le mode local repliqué. Par défaut, tous les documents sites vont être activés en mode local répliqué.
: Liste des valeurs qui peuvent être modifiées lors de la mise en place du mode local repliqué. Comme il est probable que l'on ne veuille pas modifier toutes les options modifiables, il faut commencer par sélectionner les options que l'on souhaite modifier, en cochant la case correspondante dans la colonne Enforce.

Cette étape permet d'attendre que la réplique locale soit effective.
: Ratio permettant de déterminer quand les répliques locales sont effectives par rapport aux bases du serveur.

Lors de cette étape, l'outil va configurer le poste de l'utilisateur pour activer l'utilisation de la réplique locale de la boite aux lettre.
: Formule (de type @Formula) pour lister les documents sites à modifier dans le carnet d'adresse local de l'utilisateur pour activer le mode local repliqué. La formule par défaut rétourne tous les documents sites (Locations) de tout le monde ("" et "*") ou pour l'utilisateur courant (@UserName).
: Liste des valeurs qui peuvent être modifiées dans les document sites des utilisateurs pour activer le mode local repliqué de leur boite aux lettres. Comme il est probable que l'on ne veuille pas modifier toutes les options modifiables, il faut commencer par sélectionner les options que l'on souhaite modifier, en cochant la case correspondante dans la colonne Enforce.
: Liste des Users Preferences qui pouvant être modifiées ou activé lors de l'activation du mode local répliqué sur les postes clients.

A la fin du processus de création du mode local répliqué, il est possible de définir si les fiches utilisateurs qui ont été traité ici, sont à reprendre dans le projet 2 (Project 2 : Change Mail Server).
: Cette option, si elle est cochée, va permettre à la fin du projet Project 1 : Local Replica Mode, de passer les fiches utilisateurs en "Step 0" du projet Project 2 : Change Mail Server.
Project 2 : Change Mail Server
Le but de se projet consiste à créer une réplique de l'ancien serveur vers le nouveau serveur, de rediriger le poste de l'utilisateur vers le nouveau serveur et rendre l'ancienne base administrable que par les administrateur.


La création de la réplique sur le nouveau serveur se fait via une requête AdminP.
: La réalisation des requêtes AdminP pouvant être programmées, la création des requêtes AdminP via Desktop Manager Project peut l'être aussi. Le nombre de création peut être limité aussi par l'administrateur.
: Ratio déterminant que la réplique sur le nouveau serveur est valide. Une fois que la base sur le nouveau serveur aura atteint le ratio de l'ancienne base par réplication la fiche utilisateurs passera à l'étape suivante.
: La migration vers un nouveau serveur peut sous entendre la suppression de l'ancien serveur. Une réplique locale du Dircat avec l'ancien serveur peut être présente sur les postes des utilisateurs. L'administrateur peut demande au process lors de l'étape 3 de modifier cette réplication pour qu'elle s'effectue avec le nouveau serveur en indiquant le chemin du Dircat sur le nouveau serveur. Forcer une réplication permet d'enregistrer le nom du nouveau serveur dans le journal de réplication local du Dircat. Ainsi si l'option "Tout serveur disponible ; essayez d'abord le dernier réussi" est active, la prochaine réplique s'effectuera avec le nouveau serveur.
: En cochant cet option, le process ajoutera l'icône du carnet d'adresse du nouveau serveur sur l'espace de travail des utilisateurs.
: Forcer la réplication une fois avec le nouveau serveur, permet d'enregistrer dans le journal de réplique le nom du nouveau serveur. Ainsi, si l'option "Tout serveur disponible ; essayez d'abord le dernier réussi" est active dans le replicateur, c'est avec le nouveau serveur que la prochaine réplique s'effectuera.
: On va ici déterminer la liste des documents sites à modifier avec une requête de type @Formula. La première formule est pour les documents location pour lesquels il faut renseigner le champ MailFile avec le chemin de la base mail du serveur de destination, donc pas forcément les documents sites de type "Local", mais plutot ceux de type "On Server". Puis la seconde formule pour modifier les champs serveurs des document. La liste des champs des documents sites où l'on veut mettre le nouveau serveur, et la liste des champs des documents sites que l'on veut vider. La formule par défaut rétourne tous les documents sites (Locations) de tout le monde ("" et "*") ou pour l'utilisateur courant (@UserName).

L'icône vers la boite aux lettres du nouveau serveur a été ajouté dans l'epace de travail de l'utilisateur. La fiche du carnet d'adresse de l'utilisateur a été mise à jour. A cet étape, le système désactive la réplication de la boite aux lettres sur l'ancien serveur, toutes les entrées de la LCA sont mises en droit Lecteur puis les groupes d'administrateur renseignés dans les documents de Server Setup concernant la migration en cours seront ajoutés en tant que gestionnaires et la structure de l'ancienne est modifier pour qu'à son ouverture l'utilisateur soit redirgier vers la boite aux lettres du nouveau serveur.
: Formule de redirection permettant lors de l'ouverture de la boite aux lettres sur l'ancien serveur de rediriger l'utilisateur vers le nouveau serveur.
Project 3 : Move Database


: La réalisation des requêtes AdminP pouvant être programmées, la création des requêtes AdminP via Desktop Manager Project peut l'être aussi. Le nombre de création peut être limité aussi par l'administrateur.
: Formule de redirection permettant lors de l'ouverture de l'application sur l'ancien serveur de rediriger l'utilisateur vers le nouveau serveur.
Project 4 : Clean-Up Workspace


: Temps maximum de traitement pour vérifier s'il faut supprimer l'icône et la suppression de l'icône.
: Liste des serveurs dont il faut supprimer les icônes dans l'espace de travail.
: Liste des bases du nouveau serveur à ajouter (names, log.nsf, admin4.nsf), ce sont des bases standard système que l'on ne migre pas.
: Liste des bases à supprimer si elles sont présentes dans l'espace de travail de l'utilisateur.
Automatic Actions


: Activation, fréquence, date du dernier lancement, date du dernier arrêt et le temps d'éxecution des agents permettant certaines actions dans la base Desktop Project :
- Accelerate Multi-configuration Users : Pour le projet Change Mail Server, l'agent va analyser les documents utilisateurs qui sont avant l'étape de modification du carnet d'adresse (2 > New Mail Database replica fully replicated, Waiting for NAB Update) ou avant l'étape de désactivation de la réplique sur les anciens serveurs (4 > Notes configuration has been updated, Waiting for User selection to disable old Mail database) et dont ces utilisateurs auraient déjà franchis ces étapes via un autre poste (et donc un autre document user). Dans ces cas la, l'agent force le passage aux étapes suivantes des documents concernés puisqu'il n'est pas nécesaire de remodifier le carnet d'adresse ou de redésactiver la réplique de la messagerie sur l'ancien serveur.
- Process Delayed AdminP Requests : Pour les projets Change Mail Server et Move Database, cet agent réalise les requêtes AdminP qui ont été programmées via le document de setup global.
- Refresh Status : Cet agent permet d'automatiser les actions "Refresh Status" qui sont manuelles dans les projets Change Mail Server et Move Database lors des étapes qui nécessitent la comparaison des tailles des bases entre les anciens serveur et le nouveau serveurs. Si les bases ont atteintes le quota renseigné dans le document de Setup global alors l'agent passe les documents concernants ces bases automatiquement à l'étape suivante.
Back to Top
Commentaires
0 commentaire
Cet article n'accepte pas de commentaires.