Mon histoire commence par un problème de performance avec un serveur de fichiers comprenant presque 2TB de données et supportant presque 5000 utilisateurs.
Le serveur en question éprouve des problèmes qui causent la déconnections des clients lors des périodes de grande utilisation.
La solution envisagée pour palier au problème est la migration du serveur Windows 2003 32bits vers la version x64, qui promet une meilleure gestion de la mémoire, des disques, du réseau et des CPU.
Le défi de la migration réside dans le fait que la sécurité sur les données de ce serveur a été faite selon la méthode à la mode à l'époque de NT4, soit en utilisant des groupes locaux.
La méthode choisie consiste à copier les groupes locaux du serveur source (x86) au serveur destination (x64) à l'aide de l'outil "SecurCopy".
Les travaux en laboratoire ont sont faits sur un environnemnet virtuel. Suite à l'utilisation de l'outil "SecurCopy" pour copier les groupes d'un serveur à l'autre, le disque contenant les données est détaché du serveur source et attaché au serveur cible.
Avec cette procédure, nous nous attendions à un échec... mais ce ne fut pas le cas. La migration semble bien fonctionner.
En théorie, la copie des groupes locaux d'un serveur à l'autre permet d'obtenir à la destination des groupes portant le même nom, cependant, le nouvau serveur doit émettre de nouveaux sID pour ces groupes. De ce fait, les permissions (ACL) appliquées sur les données ne devraient pas être reconnues par le nouveau serveur.
Les permissions (ACL) sur le disque sont (contrairement à nos attentes) reconnues par le nouveau serveur. L'outil semble avoir copié les sID des groupes... fantastique... (incroyable?)
Maintenant... allons en production. Exécution de l'outil "SecurCopy", détachement du disque de données, attachement sur le nouveau serveur.... BANG ! aucun sID n'est reconnu par le nouveau serveur. DEUUUUUHHH ?????
Que s'est-il passé...???
Vous n'avez pas oublié que l'environnemnet de laboratoire était virtuel?... Les machine virtuelles utilisées étaient des "clones" générées à partir d'un gabarit commun, sans qu'une quelconque personnalisation machine n'ait été effectuée (sysprep, newsid).
Il semble donc que "SecurCopy" lirait le sID du serveur de destination et effectuerait un "restore" des sID originaux des groupes si les sID des deux serveurs concordent. Lorsque le sID est différent, il laisse Windows générer de nouveaux sID pour les groupes.
Hypothèse : pourrait-on utiliser newsid et spécifier le sID de l'ancien serveur ? Ça reste à confirmer.
En attendant, la méthodologie sera révisée... une solution moins "dangereuse" sera élaborée...
0 commentaires:
Publier un commentaire