Partager via

WSUS 2 est mort, vive WSUS 3

  • Article

Technorati Tags: WSUS

Chacun devrait le savoir, WSUS 2.0 SP1 ne sera plus supporté à partir de la fin Avril 2009, tout comme la version 3.0 (RTM = SP0). Reste donc WSUS 3.0 SP1 aussi appelé WSUS 3.1.

Plus d’informations sur la fin du support sur la page FAQ du produit : https://technet.microsoft.com/en-us/wsus/bb980625.aspx

Q. When does support end for WSUS 2.0?

A. Support for WSUS 2.0 has already ended. WSUS 2.0 SP1 support will end April 2009 (two years after WSUS 3.0 was released).

 

Nous allons voir comment procéder à la migration d’un serveur WSUS 2.0 vers WSUS 3.1

La migration vers WSUS 3.1 se fait en lieu et place de la version déjà installée contrairement au passage de SUS 1.0 vers WSUS 2.0. Sur le papier tout doit se faire sans problème, mais pour peu que votre WSUS ait un peu de vécu, on n’est pas à l’abris d’un petit problème. La procédure qui va suivre va nous permettre de faire l’opération de migration même en cas de pépin.

Tout d’abord, préparons le terrain en téléchargeant les prérequis et quelques outils qui pourront se réveler utiles !

Prérequis:

Outils supplémentaires:

 

Installons les 2 versions des “API Samples and Tools” et le WSUSMigrationImport dans le répertoire WSUSMigrate\WSUSMigrationImport des API v3 (cette version corrige le problème décrit dans l’article https://support.microsoft.com/kb/945348)

Par mesure de précaution, nous allons sauvegarder la base de données SQL sur laquelle est basé WSUS. Un simple backup des fichiers de la base avec NTBackup suffit. Les 2 fichiers à sauvegarder sont SUSDB.MDF et SUSDB_LOG.LDF. Cela permettra un retour arrière si nécessaire.

Sauvegarder vos paramètres de synchronisation (proxy, source des mises à jour, classifications, produits, langues …) sur le support de votre choix (papier, document word, capture écran)

Après la ceinture, les bretelles … Nous allons exporter les approbations et les groupes WSUS (les 2 sont liés) dans un fichier .xml, si jamais il fallait repartir d’une installation “from scratch” cela évitera de revalider les mises à jour une par une en rejouant automatiquement ces approbations. Lancer la commande suivante :

%Program Files%\Update Services API Samples and Tools\WSUSMigrate\WSUSMigrationExport\wsusmigrationExport groupapprobations.xml

Une fois l’export terminé, la migration en temps que telle peut commencer. La bonne pratique consiste à lancer le setup d’installation de WSUS 3.1 par la ligne de commande pour lui ajouter le paramètre /g (qui signifie : upGrade)

WSUSSetup_30SP1_x86.exe /g

La migration commence, et devrait normalement aboutir correctement. Sauf que la vie est parfois injuste et que le setup peut s’arrêter avant la fin. Dans ce cas, une installation propre ou “from scratch” est obligatoire. Désinstaller la version 2.0, le moteur de base de données si vous utilisez MSDE ou wMSDE car la version 3 est basée sur WIDB (Windows Internal DataBase). Garder seulement le “Content” ce qui épargnera le retéléchargement des binaires des mises à jour. Une fois le serveur débarassé de la version précédente, installer la version 3.1. A la fin de l’installation, l’assistant de configuration s’ouvre et vous demande de remplir les champs nécessaires à son fonctionnement (Proxy, Source des données, Classifications et Produits à synchroniser, Langues à prendre en charge …). Synchroniser le serveur afin de récupérer le catalogue des mises à jour que vous souhaitez déployer sur votre parc. Lorsque le serveur a fini sa synchronisation, que toutes les mises à jour de chacun des produits et des classifications sont bien présentes, vous pouvez alors réimporter les groupes et les approbations. Pour cela, utiliser la commande suivante (celle téléchargée sur Codeplex) :

%Program Files%\Update Services API Samples and Tools\WSUSMigrate\WSUSMigrationImport\wsusmigrationImport groupapprobations.xml All None

Lorsque la magie de la commande a fini d’opérer, vous avez un serveur WSUS 3.1 prêt à distribuer les mêmes mises à jour aux mêmes clients que votre ancien WSUS 2.

Les clients devront effectuer leur cycle de détection avant de réapparaitre dans la console. Au bout de 2 ou 3 jours, l’ensemble du parc devrait s’être réinscrit.

Le cas SQL Server 2005 …

Certains d’entre vous auront peut être effectué un déplacement de la base de données de WSUS vers la version complète de SQL afin de bénéficier des outils d’administration ou pour pouvoir déporter la base sur une autre machine.

Le guide d’opérations de WSUS décrit la marche à suivre (https://technet.microsoft.com/en-us/library/cc708558.aspx), sauf qu’il y a un petit manque. Cette démarche ne modifie pas les informations dans le registre et a pour conséquence de bloquer la migration de WSUS vers la version 3 (ou vers le SP1 pour ceux qui sont déjà en 3.0) . Le setup ne peut plus se connecter à la base de données avec ces informations. En modifiant les valeurs de registre suivantes sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup on peut rétablir la situation :

Base de données =>
Valeurs de Registre ll V

wMSDE

Windows Internal DataBase

SQL Server 2005 Local

SQL Server 2005 Remote

WmsedInstalled

 1 0 0 0

wYukonInstalled

0

1

0

0

SqlInstanceIsRemote 

0

0

0

1

Après avoir ajusté vos valeurs de registre, la migration doit s’effectuer correctement.

 

GaetanB – Windows Core Support Engineer