Partager ses sous-répertoires dans un cluster Windows Server 2008 ou Windows Server 2008 R2

GaetanB — Fri, 27 Nov 2009 12:31:01 GMT

Tous les aficionados du cluster auront remarqué la disparition de la fonctionnalité pourtant très appréciée de partage automatique des sous-répertoires d’un partage clusterisé.

En dehors de la création manuelle de ces partages, point de salut.

Voilà une petite commande pour partager tous les sous-répertoires du répertoire courant.

FOR /F %i IN ('dir /b /a:d') DO net share %i=%CD%\%i

Si les partages doivent être cachés, la commande devient :

FOR /F %i IN ('dir /b /a:d') DO net share %i$=%CD%\%i

Explication :

dir /b /a:d renvoie la liste des répertoires contenus dans le répertoire courant

/b pour une liste simple et /a:d seulement les fichiers qui sont des répertoires (directory)

La boucle FOR va donc exécuter le code qui suit le DO pour chacune des entrées renvoyée par le dir

la commande net share permet le partage, on lui indique le nom du partage et le chemin d’accès complet au partage

%i ou %i$ sera le nom du partage (respectivement visible et caché), ce nom est le nom du répertoire lui même

%CD%\%i est la concaténation du chemin d’accès complet (répertoire actuel) et du nom du sous-répertoire à partager

Les 2 lignes de commandes citées devront être exécutées directement depuis l’invite de commande

Pour celles et ceux qui veulent inclure ces lignes dans un fichier .cmd ou .bat, voici la syntaxe à utiliser :

FOR /F %%i IN ('dir /b /a:d') DO net share %%i=%CD%\%%i

Si les partages doivent être cachés, la commande devient :

FOR /F %%i IN ('dir /b /a:d') DO net share %%i$=%CD%\%%i

le %i qui est la variable locale à notre commande doit avoir un double % pour être correctement interprétée

Le %CD% est une variable système et n’a donc pas besoin d’être doublé au niveau du %

WSUS 2 est mort, vive WSUS 3

GaetanB — Tue, 03 Feb 2009 15:31:00 GMT

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 : http://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:

WSUS 3.1 http://go.microsoft.com/fwlink/?linkid=93750
MMC 3.0 http://support.microsoft.com/kb/907265
.Net Framework 2.0 http://www.microsoft.com/downloads/details.aspx?familyid=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5
Report viewer 2005 http://www.microsoft.com/downloads/details.aspx?familyid=8A166CAC-758D-45C8-B637-DD7726E61367

Outils supplémentaires:

WSUS 2.0 API Samples and Tools http://download.microsoft.com/download/8/d/0/8d068114-bd66-4fde-a04c-aeaa9d1fe640/Update%20Services%20API%20Samples%20and%20Tools.EXE
WSUS 3.0 API Samples and Tools http://go.microsoft.com/fwlink/?LinkId=117680
WSUSMigrationImport http://www.codeplex.com/WSUS/Release/ProjectReleases.aspx?ReleaseId=18460

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 http://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 (http://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

wYukonInstalled

SqlInstanceIsRemote

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

GaetanB – Windows Core Support Engineer

C:\>Windows Internals - L'équipe Française de Support Windows_ : Gaetan

Partager ses sous-répertoires dans un cluster Windows Server 2008 ou Windows Server 2008 R2

WSUS 2 est mort, vive WSUS 3