Migration des comptes et des autorisations

serveur NT autonome à  serveur Win2K autonome, de DC (domain controller) NT à  serveur Win2K autonome, de NT DC à  Win2K DC, ou de serveur NT autonome à  Win2K DC.

De serveur NT autonome à  serveur Win2K autonome. La méthode classique de migration d’un serveur autonome à  un autre passe par l’utilisation de divers outils pour migrer séparément les comptes et le contenu (avec des autorisations NTFS). Premièrement, on utilise un outil comme Addusers, que l’on peut trouver dans le Microsoft Windows 2000 Server Resource Kit, pour exporter la base de données utilisateur dans un fichier texte. Ensuite, on importe le fichier texte dans le nouveau système, créant ainsi un ensemble identique de noms d’utilisateurs et de groupes sur le serveur Win2K. Cependant, Addusers ne migre pas les mots de passe et il faut donc ajouter un mot de passe pour chaque compte utilisateur, puis demander aux utilisateurs de changer ce mot de passe à  leur prochaine connexion (logon) – un travail administratif fastidieux. De plus, les nouveaux comptes, bien que portant des noms identiques à  ceux des comptes originaux, ont de nouveaux SID – ce qui complique sérieusement la sécurité après migration du contenu du serveur Web et des autorisations NTFS associées. L’outil Robocopy du kit de ressources peut copier le contenu et les autorisations NTFS associées du serveur Web, sur tout le réseau. Bien que Robocopy puisse être défaillant lors de la copie de gros fichiers, il fait dans l’ensemble du bon travail et copie fidèlement les sites originaux que les autorisations NTFS utilisent pour référencer les comptes utilisateurs et groupes. Mais, comme Addusers a donné de nouveaux SID à  ces comptes, les autorisations NTFS sont inopérantes sur le nouveau serveur. Des outils similaires, comme IIS Export Utility d’Adsonline, rencontrent également cette difficulté. Il existe un outil qui règle le problème des sites conflictuels : Secure Copy de Small Wonders Software. Ce produit copie le contenu entre deux serveurs autonomes et reproduit les comptes utilisateurs et groupes locaux sur le serveur cible d’une manière qui laisse les autorisations NTFS intactes. (Pour lire une présentation de ce produit, voir l’article de Joshua Orrison, « Server Consolidation Software », http://www.win2000-mag.com, InstantDoc ID 20652.)

De NT DC à  serveur Win2K autonome. On peut voir la migration comme une occasion de transférer l’implémentation IIS d’un DC à  un serveur autonome. Déplacer des comptes de domaine NT sur un serveur Win2K autonome suit essentiellement la même procédure que celle de la migration d’un serveur membre NT à  un serveur Win2K autonome et elle propose le même choix d’outils (c’est-à -dire, Addusers ou Secure Copy). Toutefois, Secure Copy ne peut pas migrer des groupes globaux sur un serveur membre comme des groupes locaux. Attention : vous serez surpris si vous pensez pouvoir migrer les comptes de domaine NT 4.0 sur Win2K DC, puis exécuter DCPROMO pour supprimer AD (Active Directory) et former ainsi les comptes transférés en comptes locaux. Les comptes utilisateurs AD ne convertissent pas les comptes utilisateurs locaux quand on rétrograde un Win2K DC en un serveur autonome.

De NT DC à  Win2K DC. Je vous déconseille de configurer le nouveau serveur Web comme un Win2K DC strictement, afin de pouvoir utiliser AD à  des fins de migration. En revanche, si vous envisagez déjà  d’utiliser IIS sur un Win2K DC, vous pouvez bénéficier de la réplique AD pour déplacer les comptes utilisateurs et groupes, gardant ainsi intactes les autorisations NTFS pour le contenu migré. Pour procéder ainsi, il faut joindre le Win2K DC au domaine de NT DC. Les utilisateurs et les groupes NT se répliqueront automatiquement. On peut aussi utiliser un outil de migration AD d’un fournisseur comme NeIQ, FastLane Technologies, BindView ou Aelita Software. Ces outils sont conçus pour intégrer une structure de domaine NT 4.0 dans un réseau de type AD. L’ADMT (Active Directory Migration Tool) de Microsoft offre aussi des moyens de base pour migrer les utilisateurs et les groupes NT 4.0 sur un Win2K DC. Mais ADMT ne migre pas les mots de passe. Pour plus d’informations sur cet outil, voir les articles de Microsoft, « How to Set Up ADMT for Windows NT 4.0 to Windows 2000 Migration » (http://support/micro-soft.com/support/kb/articles/q260/8/71.asp) et « Active Directory Migration Tool Overview » (http://www.microsoft.com/windows2000/techinfo/planning/ activedirectory/admt.asp).

De serveur NT autonome à  Win2K DC. Supposons maintenant que le serveur Web original fonctionne en dehors d’un domaine, mais que l’on veuille le migrer sur un Win2K DC. Pour bénéficier de tous ces outils de migration AD intéressants ou réplication AD, il faut que le serveur source soit un DC (ou bien, il faut que les comptes soient basés sur un domaine). Si seulement il existait un moyen de transformer ce serveur autonome NT 4.0 en un DC. Tout MCSE sait bien que Microsoft ne soutient pas une telle promotion – mais elle n’en est pas pour autant impossible. On peut utiliser Upromote d’Algin Technology pour convertir le serveur NT 4.0 en un DC dans un domaine à  machine unique, puis utiliser une stratégie de réplication ou un outil de migration AD. Bien entendu, en cas de problèmes résultant de cette méthode, il ne faudra pas compter sur l’aide de Microsoft.