IT CAMPS : Migrer Windows Server 2003 vers un Datacenter Moderne

Etes-vous au courant que la fin de support de Windows Server 2003 est prévue pour 14 Juillet 2015 ?

Avez-vous déjà pensé à migrer vos serveurs Windows Server 2003 vers Windows Server 2008 R2, 2012 R2 ou éventuellement vers le Cloud ? ou au moins commencer l’étude de cette migration ?

Aujourd’hui, j’aimerais vous faire part d’un événement intéressant :

Microsoft IT CAMPS propose de nouvelles dates au sujet de la migration de Windows Server 2003 vers une nouvelle plateforme /Datacenter Moderne.

Inscrivez-vous rapidement !

Télécharger la brochure sur la migration de Windows Server 2003.

Enjoy your Migration :).

La console « Services.msc » est vide !

 

Ping everyone,

Petit retour d’expérience !

J’ai été sollicité par l’équipe d’Ingés RUN aujourd’hui chez le client chez lequel je suis en mission pour un problème sur la vue « Etendu » du snap-in « Services.msc », qui apparemment est vide !!

Ce problème a été constaté sur des postes de travail « physiques » Windows XP SP3 /Windows 7 mais aussi sur des serveurs « Virtuels » Windows Server 2003 /2008 ou encore 2008 R2.

Sous un Windows XP, le contenu de la vue « Etendu » ressemble à ça:

Il peut être lié à plusieurs choses mais généralement il parvient suite à un crash d’IE (récupération d’un mauvais correctif, mauvais upgrade d’IE …) mais aussi parce que certaines bibliothèque de liens dynamiques (DLL) soient endommagées.

La problème a été résolu en ré enregistrant certaines DLL, voir procédure ci-après :

Pour Windows XP /Windows Server 2003 (quelque soit le Service Pack)

Lancez l’invite de commande (cmd.exe) et saisissez les commandes suivantes (l’une après l’autre):

 regsvr32 jscript.dll 

 regsvr32.exe  mmcndmgr.dll

 regsvr32.exe vbscript.dll

Après l’exécution de chaque commande, un message s’affiche vous indiquant que la DDL spécifiée est bien enregistrée.

Par exemple, après l’exécution de la commande regsvr32 jscript.dll, le message suivant est affiché :

Si toutefois le problème persiste, c’est que d’autres DDL à part jscript, mmcndmgr et vbscript soient endommagées, dans ce cas là, je vous invite à télécharger et appliquer le Fix suivant que (heureusement :D) MS nous propose encore :

http://www.microsoft.com/fr-FR/download/details.aspx?id=44664

Note : ce Fix est appliquable uniquement à Windows XP & Windows Server 2003. N’oubliez pas de le télécharger dans la langue de votre OS sinon l’installation échouera.

Pour Windows 7 /2008 ou 2008 R2

Lancez l’invite de commande (cmd.exe) en tant qu’Administrateur et saisissez les commande suivantes (l’une après l’autre)

 regsvr32 jscript.dll 

 regsvr32.exe  mmcndmgr.dll

 regsvr32.exe vbscript.dll

Après l’exécution de chaque commande, un message s’affiche vous indiquant que la DDL spécifiée est bien enregistrée.

Par exemple, après l’exécution de la commande regsvr32 jscript.dll, le message suivant est affiché :

Si toutefois le problème persiste, c’est que d’autres DDL à part jscript, mmcndmgr et vbscript soient endommagées, dans ce cas là, je vous invite à télécharger et appliquer le Fix suivant :

http://www.microsoft.com/fr-FR/download/details.aspx?id=44621

Note : ce Fix est appliquable uniquement à Windows 7 SP1 & Windows Server 2008 R2. N’oubliez pas de le télécharger dans la langue de votre OS sinon l’installation échouera.

Enfin, notez que cette procédure (réenregistrement de DDL) a fonctionné dans 95% des cas, le problème a été résolu sur « uniquement » un des postes de travail posant problème (sous Windows 7 Pro) en désinstallant et réinstallant IE 9.

Migration des utilisateurs et groupes locaux depuis Windows Server 2003 vers Windows Server 2008 R2

 

Note : cette procédure s’applique aussi à des serveurs faisant parti d’un domaine Active Directory

Dans un « Groupe de travail », aucune gestion centralisée des comptes utilisateurs et des groupes n’est possible.

En effet, ces derniers sont créés et stockés localement sur chaque serveur et gérés depuis l’outil « Utilisateurs et groupes locaux » : lusrmgr.msc

Dans un groupe de travail et dans le cas d’une migration d’un ou plusieurs serveurs exécutant Windows Server 2003 vers Windows Server 2008 R2, la migration des comptes utilisateurs et groupes locaux est un élément à prendre en compte afin que les utilisateurs locaux puissent continuer à avoir accès au(x) serveur(s) après l’upgrade en Windows Server 2008 R2.

Je vous présente à travers cet article la procédure de migration des utilisateurs et groupes locaux depuis Windows Server 2003 vers Windows Server 2008 R2 en utilisant la fonctionnalité Windows « Outils de migration de Windows Server » fournit avec Windows Server 2008 R2.

Important : Framework .Net v2.0 & PowerShell v1.0 (ou toutes versions ultérieurs) sont des pré requis pour cette migration, à vérifier ou à installer éventuellement sur le serveur source exécutant Windows Server 2003. De plus, notez que Windows Server 2003 doit avoir au moins le SP1 pour supporter Windows PowerShell v1.0. Donc commencez par installer le SP1 de Windows Server 2003 si ce n’est pas déjà fait.

Nous allons effectuer cette migration depuis un serveur source nommé « SRV2003 » exécutant Windows Server 2003 SP1 vers un serveur de destination nommé « SRV2008R2 » exécutant Windows Server 2008 R2.

Les deux serveurs sont dans un Groupe de travail.

Sur mon serveur source « SRV2003« , j’ai les comptes utilisateurs et groupes locaux suivants :

Le serveur de destination « SRV2008R2 » est fraîchement installé, aucun compte utilisateur ni groupe local n’est présent pour l’instant :

Etapes de migration

1. Depuis le serveur de destination « SRV2008R2 », ouvrez l’Invite de commande en tant qu’Administrateur et saisissez la commande suivante pour installer la fonctionnalité « Outils de migration de Windows Server »:

Servermanagercmd -i Migration

Note : vous pouvez aussi utiliser le Gestionnaire de serveur pour ajouter /installer cette fonctionnalité Windows 

Dès que l’installation est terminée, cliquez sur Démarrer, ensuite Outils d’Administration et vérifiez que le dossier Outils de migration de Windows Server est ajouté :

1. Maintenant, nous allons utiliser l’outil SmigDeploy.exe (outil fournit avec la fonctionnalité qu’on vienne d’installer) pour créer /générer un dossier de déploiement pour le serveur source, ce dossier contiendra les outils nécessaires qui vont nous permettre d’effectuer la migration des comptes utilisateurs et groupes locaux vers le serveur de destination.

Pour ce faire, commencez par créer et partager un dossier depuis le serveur source :

-> Ouvrez l’invite de commande depuis SRV2003 et saisissez les commandes suivantes pour créer et partager le dossier de déploiement « Migration » :

Mkdir C:\Migration

Net Share Migration=C:\Migration

-> Saisissez ensuite (depuis la même invite de commande) : Start /w C: 

Pour accéder à la partition C: hébergeant le dossier de déploiement que vous venez de créer et partager.

-> Faites un clic droit sur le dossier Migration ensuite sélectionnez Propriétés et enfin cliquez sur l’onglet Partage

-> Cliquez sur Autorisations et cochez l’autorisation « Modifier » pour Tout le monde, cliquez ensuite sur Appliquer ensuite OK.

Lancez cette fois ci l’Invite de commande depuis le serveur de destination SRV2008R2 et saisissez les commandes suivantes :

-> Pour accéder au dossier contenant l’outil de migration SmigDeploy.exe

cd %windir%\System32\ServerMigrationTools

-> Pour générer le dossier de déploiement pour le serveur source.

Note : mon serveur source SRV2003 (Windows Server 2003 SP1) est en version x32 donc je vais utiliser la valeur X86 avec le paramètre Architecture :

SmigDeploy.exe /package /architecture X86 /os WS03 /path \ \SRV2003\Migration

 Si votre OS Windows Server 2003 est en version x64, remplacez la valeur X86 par X64.

-> Enfin, vous pouvez constater que le dossier \ \SRV2003\Migration contient désormais un dossier nommé « SMT_ws03_x86 »

3. Nous devons maintenant terminer la configuration du dossier de déploiement sur le serveur source en inscrivant certaines Cmdlettes PowerShell, lancez l’invite de commande depuis SRV2003 saisissez :

cd C:\Migration\SMT_ws03_x86

SmigDeploy.exe

Après l’exécution de SmigDeploy.exe, une fenêtre de Windows PowerShell s’ouvre automatiquement :

Si par erreur vous avez fermé la fenêtre PowerShell, lancez Le module PowerShell des outils de migration de Windows Server :           ->Cliquez sur le menu Démarrer, ensuite Outils d’administration et enfin Outils de migration de Windows Server et cliquez sur Outils de migration 

Nous allons utiliser le paramètre Export-SmigServerSetting pour exporter tous les comptes utilisateurs et groupes locaux.

J’ai créé le dossier suivant C:\Migration\Export, ce dernier recevra le fichier exporté (.mig).

-> Depuis la fenêtre PowerShell ouverte, saisissez la commande suivante :

Export-SmigServerSetting -User All -Group -Path \SRV2003\Migration\Export -Verbose

Vous êtes invité à renseigner un mot de passe pour encrypter le fichier de migration qui sera généré :

Après avoir renseigné le mot de passe, une phase de collection des données démarre

Quand l’export est effectué, le résultat suivant apparaît :

Après l’export, un fichier nommé « srvmig.mig » est généré dans C:\Migration\Export

1. Nous arrivons à la dernière étape qui consiste tout simplement à importer le fichier de migration généré précédemment « srvmig.mig » contenant tous les comptes utilisateurs et groupes locaux du serveur source dans le serveur de destination (Windows Server 2008R2)

-> Depuis SRV2008R2, Cliquez sur le menu Démarrer, ensuite Outils d’administration et enfin Outils de migration de Windows Server et lancez Outils de migration de Windows Server en tant qu’Administrateur

-> Saisissez la commande suivante :

Import-SmigServerSetting -User Enabled -Group -Path \SRV2003\Migration\Export -Verbose

Vous êtes invité à renseigner le même mot de passe spécifié au moment de l’export

Après avoir renseigné le mot de passe, une phase de collection des données démarre

Après l’import, le résultat suivant apparaît :

Notez que si des comptes utilisateurs ou de groupes présents sur le serveur de destination portent le même nom que les comptes utilisateurs ou groupes exportés depuis le serveur source, ces derniers ne seront pas migrés, c’est le cas pour le compte Administrateur.

Enfin, cliquez sur Démarrer ensuite Exécuter et saisissez Lusrmgr.msc, vérifiez que vos comptes utilisateurs et groupes locaux sont bien migrés :

 

Vérifiez aussi les appartenances des comptes utilisateurs aux groupes :

Important : Les comptes utilisateurs locaux migrés ont « par défaut » les propriétés suivantes :

==> L’utilisateur doit changer le mot de passe à la prochaine ouverture de session

==> Le compte est désactivé

Donc n’oubliez pas de réactiver les comptes utilisateurs après la migration.

J’espère que cet article pourra vous être utile.