Différences

Ci-dessous, les différences entre deux révisions de la page.

--- aspcitrix:update_version_medialog [2018/11/09 15:57]
didier [__Chronologie theorique :__]
+++ aspcitrix:update_version_medialog [2021/02/18 22:48] (Version actuelle)
@@ Ligne 4: / Ligne 4: @@
 ===== __Chronologie theorique :__ =====
-en cas de maj 100% manuelle, passer directement à l'étape USERS et ACCES (1).
+en cas de maj 100% **manuelle**, passer directement à l'étape USERS et ACCES (1).
 On peut également profiter d'une partie automatique, dans ce cas il faudra uniquement faire manuellement les points mis en gras dans les étapes ci dessous.
-pour pour pouvoir lancer la partie automatique. il faut se connecter en bureau a distance sur la machine TLCONV15 en tant qu'utilisateur 'migrateur'. sur le bureau il y a un raccourci vers le dossier e:\update352.
+pour pour pouvoir lancer la partie **automatique**, on peut le faire en 'live' ou procedé par planification en tache schedulé (cfr daily update et ses commentaire).  \\
-On pourra y lancer le fichier script update352.cmd en renseignat l'alias du client que l'on va migrer m(pas case sensitive ;) .
+pour cela il faut se connecter en bureau a distance sur la machine TLCONV15 en tant qu'utilisateur 'tldomain\migrateur'.
+Sur le bureau il y a un raccourci vers le dossier e:\update352.
+En **live**, on pourra y lancer le fichier script update352.cmd, le script demandera l'alias du client que l'on va migrer, en cas de multifiliale, le script va regarder dans customer_addon et fera toutes les filiales répertoriées dans cette table. (le script d'upgrade de la base sera repris a un endroit équivalent a \\tlconv15\DiskE\Update360\scripts_sql\tout 3a6 pour bin+00.sql, donc il est bon de s'assurer que celui correspond au script officiel sur le tlserv2)
+En cas d'utilisation de la tache **scheduler** il faudra créer un fichier texte au format "update_list[Date au formatYYYYMMDD].txt qui contiendra les alias client à migrer.
+plus d'information sur le script sur le drive : https://drive.google.com/open?id=1PDX9rHugKs0rE_pTMUlSQTRMVYaI82XNy69ZqHjns7s
 ==== Users et accès (1) ====
   * **prévenir le service IT que l'on va travailler sur un client précis, car des avertissements d'erreurs sur la NON accessibilité de la base du client vont apparaitre sur Nagios.**
-  * **désactivation (disable) des users dans l'active directory (tladfs1), pour éviter des reconnexions des users durant la phase d'upgrade**
+  * désactivation (disable) des users dans l'active directory (tladfs1), pour éviter des reconnexions des users durant la phase d'upgrade
-  * **faire un logoff des users recalcitrants encore connectés sur le farm (prog TLMC sur tlxadmin)**
+  * faire un logoff des users recalcitrants encore connectés sur le farm (prog TLMC sur tlxadmin)
   * désactivation (stop) des accès externes via des sites web (arrêt service iis - application pools - sur le tlwi1 et tlwi2)
@@ Ligne 32: / Ligne 39: @@
   * **contrôler avec beyond compare que tout les fichiers du tladfs1 sont plus récents que ceux du tladfs2 pour notre client (\\tladfs1\e$\Share1\MediaLog\ML_TLLIB\Fil_version\Bin <--> \\tladfs2\e$\Share2\MediaLog\ML_TLLIB\Fil_version\Bin).  Attention aussi il ne peut pas y avoir de dossier schemacache (a supprimer s'il existe)).  S'il y a des fichiers plus récent sur le tladfs2, alors les écraser avec ceux du tladfs1, sinon durant la nuit le tladfs2 écrasera les bons fichier du tladfs1 ...).**
   * Si le client va travailler le même jour après notre upgrade  \\
-     - **il faut mettre à jour toutes les machines virtuelles du farm, via le programme TLMC sur le tlxadmin, menu TOOLS - Maj bin Man.**
+     - il faut mettre à jour toutes les machines virtuelles du farm, via le programme TLMC sur le tlxadmin, menu TOOLS - Maj bin Man.
      - il faut supprimer les directory shemacache sur tout les tlxa... (exemple : \\tlxa222\e$\ML_Internet\ML_Program Server\ML_Ecrivainpub\fil_001\Bin\schemacache).  On peut savoir quel tlxa en regardant dans le fichier logid.log du client sur le tlfs1 (\\tlfs1\DATABASES\ml_ecrivainpub\Fil_001\Others).  on y voit sur quel serveur le client s'est connecté depuis le matin, ce qui a engendrer la création du schemacache)
@@ Ligne 45: / Ligne 52: @@
   * modifier le champ CUS_MLVERSI dans le record avec le cus_id du client dans la table CUSTOMERS( base e:\databases\tlcustomers\tlcustomers.fdb sur tldbs7)
   * **Activer certains programme externes qui peuvent être nouveaux avec la version pour notre client (exemple la mise à jour de la date de publication lors du passage de la 3.5.1 a la 3.5.2)**
-  * **Lors du passage en 3.5.2 , ne pas oublier d'ajouter le client pour la mise à jour de la date de publication sur le tlworks1 qui se situe sur e:\tools\all\updatedatepub  , il suffit de lancer l'application, sélectionner l'alias de base de données, définir le type de client ( BEFR, BENL ou NL ) et d'ajouter le client.  On peut manuellement faire une initialisation du client si nécessaire sinon elle se fera automatiquement au prochain démarrage.**
+  * Lors du passage en 3.5.2 , ne pas oublier d'ajouter le client pour la mise à jour de la date de publication sur le tlworks1 qui se situe sur e:\tools\all\updatedatepub  , il suffit de lancer l'application, sélectionner l'alias de base de données, définir le type de client ( BEFR, BENL ou NL ) et d'ajouter le client.  On peut manuellement faire une initialisation du client si nécessaire sinon elle se fera automatiquement au prochain démarrage.