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

Installation d’une application sous Terminal Server / Remote Desktop Server et Fonctionnement des Shadow Keys

Philippe Lafeil — Tue, 14 May 2013 22:18:09 GMT

Installer une application sous Terminal Server n’est pas anodin. En effet, le serveur étant multi-utilisateurs, il faut que l’application soit capable d’être utilisée simultanément par plusieurs utilisateurs. Il faut donc clairement séparer les données et paramètres communs, de ce qui ne l’est pas. Si l’application n’a pas été écrite en tenant compte de cela, les risques de plantage sont garantis.

1. Le principe

Pour éviter ces situations, et gérer malgré tout le plus grand nombre d’applications, les différentes versions de Terminal Server font appel à un module de compatibilité, TS Compatibility, qui doit être activé à chaque installation. Cette activation se fait lors du basculement du serveur en mode « Installation » et se termine lorsque le serveur bascule de nouveau en mode « Exécution ».

En mode « Installation », selon les applications qui sont exécutées, un travail de surveillance sera effectué automatiquement ou pas. Ce qui détermine cette surveillance est la présence du flag TSAWARE ou non, dans l’entête du fichier exécutable de l’application. Pour les applications « TSAWARE », le serveur fera confiance à l’application pour gérer correctement ses paramètres et données. Pour toutes les autres applications, une capture des modifications des clés de registre, ainsi que des fichiers INI dans C:\Windows sera effectué.

2. Gestion des fichiers INI

Une copie des fichiers INI modifiés sera effectué vers un répertoire « Windows » crée dans le profil de l’utilisateur. Une modification de la variable d’environnement %WINDIR% permettra de pointer vers ce répertoire. Ainsi, si l’application référence les fichiers INI en se basant sur la variable d’environnement %WINDIR%, elle ne s’apercevra pas de la substitution et fonctionnera normalement. Dans le cas contraire, elle ouvrira la voie à tous les conflits de paramètres entre utilisateurs.

3. Gestion des clés de régistres – Les Shadow Keys

Les modifications de clés de registre provenant de HKEY_CURRENT_USER ou de HKEY_USERS\.DEFAULT seront dupliquées vers HKEY_LOCAL_MACHINE\Software\[Wow6432Node\]Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. Ces clés de sauvegarde sont appelées les Shadow Keys. Ainsi, lorsqu’un utilisateur se connectera, selon que les clés de l’utilisateur seront plus récentes ou non que les Shadow Keys correspondantes, ces dernières seront recopiées dans le profil utilisateur.

4. Les TimeStamp

Pour déterminer s’il faut mettre à jour les clés de registre du profil utilisateur, une comparaison entre 2 TimeStamp est réalisée. A chaque Shadow Keys créée, un 1^er TimeStamp contenant l’heure de cette modification est écrit dans HKEY_LOCAL_MACHINE\Software\[Wow6432Node\]Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times\LatestRegistryKey. Cette valeur pourra ainsi être comparée au 2^ème TimeSTamp, qui contient l’heure de la dernière synchronisation entre profil utilisateur et Shadow Keys. Ce TimeSTamp est stocké pour chaque utilisateur dans HKEY_CURRENT_USER\Software\[Wow6432Node\]\Microsoft\Windows NT\CurrentVersion\Terminal Server\LastUserIniSyncTime.

Une fois la recopie démarrée, il faut savoir qu’elle n’est pas réalisée « en aveugle ». En effet, seules les clés ayant été récemment modifiées dans la Shadow Keys seront recopiées. Pour faire le tri, une nouvelle comparaison de TimeStamp est réalisée, mais cette fois avec l’attribut caché affecté à chaque clé de registre. Cet attribut caché est appliqué uniquement sur les clés, et non sur les valeurs. Ainsi donc, seules les clés contenant de réelles modification récentes seront recopiées, et dans ce cas, avec l’intégralité de leurs valeurs.

5. Cas des fermes de serveurs

Ce mécanisme pourrait être parfait, s’il n’y avait pas une petite complication : l’ajout d’un serveur TS/RDS dans une ferme de serveurs déjà existante. En effet, pour ce nouveau serveur, le TimeStamp des Shadow Keys étant forcément plus récent que celui des profils utilisateur, la synchronisation, et donc l’écrasement des clés du profil utilisateur se fera à chaque connexion d’un nouvel utilisateur de ce serveur. C’est la raison pour laquelle il est recommandé, lors de l’ajout d’un nouveau serveur qui contient des applications non TSAWARE native, de modifier la date système de celui-ci lors de l’installation des applications, afin qu’il ait une date d’installation équivalente aux autres serveurs. A la fin de l’installation, ce serveur pourra reprendre la date courante.

6. Conclusion

En conclusion, le fonctionnement des Shadow Keys a été imaginé à l’origine uniquement pour permettre à des applications mal écrites de fonctionner quand même sur un Terminal Server. Aujourd’hui, les éditeurs de logiciel sont à même d’écrire des applications certifiées TSAWARE, évitant ainsi les complications liées au Shadow Keys. Ce mécanisme devrait donc disparaitre avec le temps.

Enfin, afin que tout soit clair, voici une petite Foire Aux Questions :

Q: Ce mécanisme, est il toujours le même sous Remote Desktop Server 2012 ?

R: Oui. Ce mécanisme n’a pas changé depuis Windows Server 2003.

Q : Comment basculer en mode « Installation » puis en mode « Execution » ?

R : Pour basculer en mode « Installation », plusieurs méthodes sont possibles :

- Saisir la commande change user /install dans une invite de commande avec élévation de privilège.

- Depuis le panneau de configuration, faire Ajout/suppression de programme / Installer un nouveau programme

- Lancer l’installation d’un fichier MSI

- Exécuter un programme depuis la clé RunOnce au démarrage du serveur.

De la même façon, pour rebasculer en mode « Exécution », plusieurs méthodes :

- Saisir la commande change user /execute dans une invite de commande avec élévation de privilège

- Cliquer sur la boite de dialogue de « fin d’installation » du panneau de configuration

- Terminer l’installation d’un fichier MSI.

- Terminer l’installation du programme lancé depuis la clé RunOnce

Q : Pourquoi est-il particulièrement recommandé d’installer le rôle Terminal Service ou Remote Desktop Session Host en premier, avant d’installer toute autre application ?

R : Plusieurs bonnes raisons à cela.

- Si votre application est TSAWARE, mais ne peut pas détecter qu’elle s’installe sur un serveur TS/RDS, elle n’initialisera pas les bons paramètres, et risque même de ne pas installer les bon modules. Par exemple, les différentes versions de Microsoft Office, quand elles s’installent, n’installent pas les mêmes composants selon qu’elles sont sur un serveur TS/RDS ou sur toute autre type de machine.

- Si votre application n’est pas TSAWARE, le mécanisme des Shadow Keys ne pourra pas s’appliquer, et les risques de conflits lors de l’utilisation seront importants.

Q : Si j’ai installé plusieurs applications, et que je doive ajouter le rôle Terminal Service ou Remote Desktop Session Host sur mon serveur, que dois-je faire ?

R : Le plus simple est de commencer par désinstaller toutes les applications, redémarrer la machine, installer le rôle, redémarrer autant de fois que nécessaire, puis, installer de nouveau les applications, en basculant préalablement le serveur en mode « Installation ».

Q : Comment savoir si mon application contient le flag TSAWARE dans son entête ?

R : Il n’y a pas d’outil intégré au système permettant de vérifier cela. Toutefois, l’utilitaire dumpbin.exe, fournit avec les différentes versions de Visual Studio, le permet. Il suffit de l’exécuter avec le paramètre /headers pour afficher une liste des attributs de l’entête PE du fichier exécutable. L’attribut à chercher est : « Terminal Server Aware ».

Q : Pourquoi quand je modifie manuellement les clés de HKEY_CURRENT_USER, en mode installation, ces clés ne sont pas recopiées dans la zone Shadow Keys ?

R : Cela est très certainement dû au fait que l’outil que vous utilisez pour modifier ces clés manuellement, regedit.exe ou reg.exe, est par défaut flaggué comme étant TSAWARE. Les modifications ne sont donc pas surveillées par le serveur TS/RDS.

Q : Je voudrais utiliser le mécanisme des Shadow Keys pour modifier les profils des utilisateurs de mon serveur TS/RDS, mais les différents TimeStamp me compliquent la vie. Y aurait-il une façon simple de procéder ?

R : Oui, ne pas utiliser ce mécanisme, mais lui préférer une mise à jour par GPO.

Philippe

Windows Core Support Escalation Engineer

Garder un historique des logs cluster

Philippe Lafeil — Wed, 17 Oct 2012 00:40:23 GMT

Quand il arrive un incident sur un cluster, la majeure partie des informations nécessaires à l’explication se trouve dans les cluster logs. Cependant, il est fréquent que la période intéressante ne soit pas couverte par le cluster log. Pour pallier à ce désagrément, il est possible de créer une tâche programmée qui génèrera les cluster logs tous les jours, couvrant les dernières 24 heures.

De cette manière, si un incident arrive vous aurez toujours à votre disposition un historique de plusieurs semaines, voire de plusieurs mois en fonction de la quantité d’information que vous désirez garder.

Voici comment il est possible de s’y prendre.

1. Importer le script powershell ci-dessous dans le répertoire de votre choix (par exemple C:\Temp\ClusterLogs) sur un des nœuds du cluster

#####################################################################################

# ClusterLogCollector.ps1

# version 2.0

# Serge Gourraud

# This collects cluster logs and rename them according to the date

# - It must be run under administrator

# - It must be run a on a node of the cluster

# Versions

# v2.0 : Accept arguments

# v1.1 : Add 5 minutes to the 24h to make sure we don't lose a few lines

# v1.0 : First draft

# Incoming version 2.1 : Include diagnostics started with the –verbose switch

#####################################################################################

# Checking arguments

param( [string]$Repository = "c:\temp",

[int]$History = 24,

[string]$Logfile = "Logging.txt",

[switch]$verbose = $false )

if ($Repository[-1] -eq "\"){

$LoggingFile = $Repository + $Logfile

}else {

$LoggingFile = $Repository + "\" + $Logfile}

# Adding 5 minutes to timespan to make sure we don't lose any data

$TimeSpan = $History*60+5

import-Module FailoverClusters

$ClusterLogCollection = Get-ClusterLog -Destination $Repository -TimeSpan $TimeSpan

# Get the current Date and Time

$Now = Get-Date

$strDateNow = [string]$Now.Year + "-" + $Now.Month + "-" + $Now.Day + "-" `

+ $Now.Hour + "h" + $Now.Minute

# Rename each item

if ($ClusterLogCollection.count -gt 0)

{

$strDateNow >> $LoggingFile

"Tracing for " + [string]$History + " hours" >> $LoggingFile

# Renaming items

foreach ($ClusterLog in $ClusterLogCollection)

{

$strDirectory = $ClusterLog.DirectoryName

$strName = $ClusterLog.Name

$strFullName = $ClusterLog.FullName

$strNewName = $strDateNow + "_" + $strName

Rename-Item -Path $strFullName -NewName $strNewName

$strNewName + " generated" >> $LoggingFile

}

else

{

"Failed to collect cluster logs today" >> $LoggingFile

}

Ce script accepte quatre arguments :

- Le répertoire ou stocker les logs

- La quantité d’infirmation à relever en heures

- Un fichier de log qui enregistre l’exécution des relevés

- Une option « verbose » non utilisée dans la version actuelle

2. Ensuite, autoriser l’exécution de scripts Powershell sur le serveur. Dans l’exemple nous choisissons la stratégie « Unrestricted », mais il est possible d’affiner d’avantage. Pour cela, se référer à l’aide en ligne de la commande Set-ExecutionPolicy.

3. Enfin créer une tâche planifiée qui lancera le script :

a. Lancer le Task Scheduler.

b. Dans le « Task Scheduler », créer une « Basic Task ».

c. Dans le menu « Create a Basic Task », entrer le nom de la tâche et une description qui permettent de l’identifier aisément, puis cliquer sur « Next ».

d. Dans le menu « Task Trigger », choisir une tâche journalière puis cliquer sur « Next ».

e. Dans le menu « Daily », choisir la fréquence et l’heure à laquelle tournera la première instance, puis cliquer sur « Next ».

f. Dans le menu « Action », choisir l’action « Start a program » puis cliquer sur « Next ».

g. Dans le menu « Start a Program » entrer le moteur de script « Powershell.exe » dans la case « Program/Script », et dans la case « Add arguments (optional) » entrer les arguments de façons à ce que le script soit lancé avec les options qui vous intéressent, puis cliquer sur « Next ».

Par exemple :

C:\Temp\ClusterLogs\ClusterLogCollector.ps1 -r C:\Temp\ClusterLogs -h 24 -l Logging.log

h. Dans le menu « Summary », cocher la case « Open the Properties dialog for this task when I click Finish », puis cliquer sur « Finish ».

i. Dans l’onglet « General », prendre soin de faire en sorte que :

i. La tâche soit exécutée même si personne n’est loguée

ii. La tâche soit exécutée sous privilèges élevés

iii. La tâche soir configurée pour Windows® 7, Windows Server^TM 2008 R2

j. Dans l’onglet « Triggers », vérifier que tout est conforme aux options choisies précédemment

k. Faites de même pour les onglets « Actions » et « Conditions »

l. Dans l’onglet « Settings », vérifier que les paramètres correspondent à votre environnement. La valeur de timeout par défaut est de 6h et pourrait être justifiée en fonction des autres tâches qui tournent, du nombre de nœud dans le cluster et de la bande passante de chacun.

m. Enfin, en cliquant sur « OK », vous devrez entrer vos credentials.

Conclusion

Au bout de quelques temps vous aurez l’inextinguible joie de découvrir un historique de cluster logs long comme le bras et dont le support est si friand !

Serge Gourraud

RemoteApp- comment faire du SSO avec Remote DesktopService 2008 R2

Philippe Lafeil — Mon, 30 Jan 2012 19:44:00 GMT

A travers cet article, je vais tenter d’expliquer comment mettre en place le SSO (Single Sign On) pour l’utilisation de RemoteApp publiées sous RDS 2008 R2.

Pour les besoins de l’explication, je vais partir du principe que l’infrastructure en place est la suivante :

- 1 domaine : core.lab

- 1 ferme de 2 serveurs RDSH

o RDSH1.core.lab

o RDSH2.core.lab

Le nom de la ferme est RDFARM.core.lab

- 1 RD Connection Broker : RDCB.core.lab

- 1 RD Web Access : RDWA.core.lab

- 1 RD Gateway : RDGW : RDGW.core.lab

La mise en place du SSO peut se décomposer en plusieurs phases :

1) Choix des certificats

2) Génération des certificats

3) Installation des certificats sur les différentes machines

4) Paramétrage des RD Session Hosts

5) Paramétrage du RD Connection Broker

6) Paramétrage du RD Web Access

7) Paramétrage du RD Gateway

8) Créations des GPOs

1. Choix des certificats

Un ou plusieurs certificats devront être générés.

Il y a besoin de certificat pour les éléments suivants :

- Chaque serveur RD Session Host

- Le serveur RD Connection Broker

- Le serveur RD Web Access

- Le serveur RD Gateway.

Les serveurs RD Session Hosts et le serveur RD Connection Broker devront partager le même certificat.

Les serveurs RD Web Access et RD Gateway peuvent chacun avoir un certificat différent.

En conclusion, il nous faut au maximum 3 certificats différents.

Le certificat des serveurs RD Session Host et du RD Connection Broker devra comporter les indications suivantes :

CN=RDFARM.core.lab

Le certificat du serveur RD Web Access devra comporter les indications suivantes :

CN=RDWA.core.lab

Le certificat du serveur RD Gateway devra comporter les indications suivantes :

CN=RDGW.core.lab

Il est possible de n’utiliser qu’un seul certificat pour tous ces serveurs.

Il faudrait alors soit utiliser un wildcard de type *.core.lab dans le Subject Name, soit référencer les différents noms utiles, dans les champs SAN (Subject Alternative Name) du certificat.

Il est à noter toutefois que seuls les clients RDC 6.1 et au-delà peuvent faire usage de ces possibilités.

Pour l’utilisation de Subject Alternative Name dans notre exemple, il faudrait renseigner :

Subject Name :

CN=RDFARM.core.lab

Subject Alternative Name :

DNS= RDFARM.core.lab

DNS= RDWA.core.lab

DNS= RDGW.core.lab

On retrouve le nom RDFARM.core.lab, aussi bien dans le Subject Name que dans le Subject Alternative Name.

Cette répétition est volontaire.

Pour la suite de cet article, je vais considérer que nous allons utiliser 3 certificats différents.

2. Génération des certificats

Pour générer nos certificats, il existe 2 possibilités :

- Utiliser une autorité de certification au sein du domaine Active Directory

- Acheter vos certificats auprès de société telles que VeriSign ™, Thawte ™, et autres…

Si l’ensemble des postes clients accédant à l’infrastructure visée sont sous contrôle de votre service informatique, vous pouvez vous contenter d’utiliser votre propre autorité de certification.

En effet, si ces postes sont dans la même forêt que l’autorité de certification, il y aura une approbation automatique de celle-ci.

Dans le cas contraire, ils devront être paramétrés pour approuver cette autorité de certification, et devront avoir un accès à la CRL (Certificate Revocation List) de celle-ci.

Pour créer vos propres certificats, je vous invite à consulter cet article.

3. Installation des certificats sur les différentes machines

Une fois les certificats créés, il faut les installer sur les différents serveurs concernés.

Dans notre exemple, il s’agit des serveurs et certificats suivants :

Serveur	Certificat
RDSH1.core.lab	RDFARM.core.lab
RDSH2.core.lab	RDFARM.core.lab
RDCB.core.lab	RDFARM.core.lab
RDWA.core.lab	RDWA.core.lab
RDGW.core.lab	RDGW.core.lab

Cela se fait de la manière suivante :

Depuis l’un des serveurs en question, lancer une MMC en élévation de privilège, faire« Add or Remove Snap-ins ».

Choisir le snap-in « certificate »

Sélectionner« Computer Account », puis « Local Computer »

Depuis le magasin « Personal », faire « All Tasks » puis« Import… »

Sélectionner le fichier en .pfx préalablement créé, saisir le mot de passe communiqué lors de l’export de la clé privée,

Sélectionner l’emplacement du certificat dans le magasin « Personal » et faire l’import.

A la fin de l’opération, vous devez voir le certificat dans la console.

Cette opération est à refaire pour chacun des serveurs précédemment cités, avec leur certificat respectif.

4. Paramétrage des RD Session Hosts

Sur les serveurs RD Session Hosts, il y a 2 choses à configurer :

- Le protocole RDP

- Les RemoteApp

Pour le protocole RDP, cela se passe au niveau de la MMC : « Remote Desktop Session Host Configuration ».

Ouvrir les propriétés de la connexion RDP-TCP, et dans l’onglet général, cliquer sur le bouton « Select » afin de sélectionner le certificat.

Mettre le certificat choisi en surbrillance, et cliquer sur « OK »

Le certificat sélectionné sera alors affiché.

Faire OK, pour appliquer les modifications.

Concernant les RemoteApp, ouvrir la MMC « RemoteApp Manager ».

Choisir le lien « Change » à coté de « Digital Signature Settings »

Cocher la case « Sign with a digital certificate » et cliquer sur le bouton « Change».

Choisir le certificat, et valider par « Ok »

Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :

Faire la même opération avec l’autre serveur RD Session Host de la ferme.

5. Paramétrage du RD Connection Broker

Sur le serveur RD Connection Broker, il y a 2 choses à configurer :

- Le protocole RDP

- Le certificat utilisé par le RD Connection Broker lui-même.

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

Pour le RD connection Broker, lancer la MMC « Remote Desktop Connection Manager ».

Puis, sélectionner l’option pour mettre à jour le certificat.

Cocher la case « Sign with a digital certificate » et cliquer sur le bouton «Select ».

Choisir le certificat, et valider par « Ok »

Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :

6. Paramétrage du RD Web Access

Sur le serveur RD Web Access, il y a 2 choses à configurer :

- Le protocole RDP

- Le certificat utilisé par le protocole HTTPS.

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

Pour le protocole HTTPS, lancer la MMC « Internet Information Services (IIS) Manager ».

Se positionner sur le « Default Web Site », puis sélectionner l’option de « Binding… ».

Sélectionner ensuite le protocole HTTPS, puis le bouton « Edit… »

Il ne reste plus qu’à sélectionner le certificat à employer, et à valider.

Un redémarrage du site Web est à prévoir.

7. Paramétrage du RD Gateway

Sur le serveur RD Gateway, il y a 2 choses à configurer :

- Le protocole RDP

- Le certificat utilisé par le protocole HTTPS.

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

Pour le protocole HTTPS, cette fois ci, on va passer par le « RD Connection Manager »

Lancer la MMC « RD Gateway Manager ».

Puis, sélectionner l’option pour mettre à jour le certificat.

Choisir ensuite l’import de certificat.

Sélectionner ensuite le bon certificat, puis cliquer sur le bouton « Import », puis valider par « OK ».

8. Créations des GPOs

Les GPOs à créer sont à mettre en place pour tous les postes clients qui souhaiteront exécuter des RemoteApp en faisant du SSO.

Dans notre exemple, j’ai créé une OU « Desktop » dans laquelle j’ai déplacé tous les postes utilisateurs.

Ensuite, depuis la MMC « Group Policy Management », il faut sélectionner l’OU en question, puis sélectionner « Create a GPO in this domain, and Link it here ».

Dans notre exemple, je l’ai nommée SSO for RDS.

Faire ensuite Edit

La MMC« Group Policy Management Editor » s’ouvre alors.

Aller dans« Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation »

Modifier le paramètre « Allow Delegating Default Credentials »

Selectionner« Enabled », puis cliquer sur le bouton « Show… »

Saisir ensuite le SPN pour les serveurs concernés.

Dans notre exemple , il faut saisir le nom de notre ferme.

Valider ensuite deux fois par « OK ».

Aller ensuite dans « Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Connection Client »

Le paramètre à modifier est « Specify SHA1 thumbprints of certificates representing trusted .rdp publishers »

Le « thumbprint »ou « empreinte » est à récupérer sur le certificat de la ferme.

Pour cela, depuis la console certificat, choisir le certificat RDFARM.core.lab, puis dans l’onglet « Details », récupérer les données du champ« Thumbprint »

Ces données sont à recopier, de préférence sans les espaces, pour éviter les« copier/coller » malheureux.

En effet, selon ce qui est sélectionné, des caractères non affichables peuvent être inclus dans le presse-papier, et ainsi corrompre les données.

Une fois ceci fait et validé, la configuration du SSO est terminée.

Pour que la GPO soit prise en compte, ne pas oublier de fermer la MMC « Group Policy Management Editor ».

9. Utilisation du site web RD Web Access

Une dernière chose est nécessaire pour que le SSO fonctionne correctement : il faut impérativement cocher la case “J’utilise un ordinateur privé” depuis le site RD Web Access.

Philippe

Windows Core Support Escalation Engineer

TechDays 2012 - Le support Core y sera aussi

GuillaumeD — Mon, 09 Jan 2012 15:23:54 GMT

A l’occasion des Microsoft TechDays 2012, j’aurais à nouveau le grand plaisir de présenter une session technique traitant du troubleshooting sur la technologie cluster.

Le teaser :

Comment identifier la cause réelle des problèmes impactant un cluster de basculement Windows. (SER402)

La majeure partie du temps, le service cluster subit les défaillances qui interviennent et réagit dans la mesure des moyens qui lui sont donnés. L'objectif de cette session est de comprendre comment utiliser les traces et outils de Windows pour identifier quel composant ou quel facteur a causé un dysfonctionnement au sein d'un cluster et comment mettre en place un plan d'action visant à anticiper d'éventuels futurs problèmes..

Guillaume

Windows Core - Sr Support Escalation Engineer

TechDays 2010 - Meilleures pratiques et retour d’expérience sur le cluster de basculement (Failover Clustering)

GuillaumeD — Fri, 19 Mar 2010 21:55:00 GMT

Cela fait quelques temps que nous peinons à poster des bulletins sur notre blog.

Je profite donc de l'occasion pour vous annoncer que les webcasts des TechDays 2010 sont disponibles.

En particulier la notre (nous ne sommes pas peu fiers Lionel et moi tout autant que Jérôme, notre acolyte d'un jour) qui concerne les meilleures pratiques autour du clustering :

Guillaume

Windows Core - Support Escalation Engineer

TechDays 2010 – Nous y serons aussi !

GuillaumeD — Wed, 06 Jan 2010 03:05:28 GMT

A l’occasion des Microsoft TechDays 2010, nous aurons le grand plaisir de présenter une session technique traitant des meilleurs pratiques et de notre retour d’expérience sur la technologie cluster.

Au menu, entre autres sujets, les nouveautés de Windows Server 2008 R2, comment mettre à jour votre cluster de Windows Server 2003 ou 2008 à Windows Server 2008 R2, comprendre l’outil de validation, les actions proactives à mettre en oeuvre pour assurer la stabilité du cluster, etc…

Le teaser :

Meilleures pratiques et retour d'expérience sur le cluster de basculement (Failover Clustering)

Le choix de la mise en place d'un cluster est guidé par le besoin de haute disponibilité mais il ne faut pas se laisser tromper par son apparente simplicité. Les ingénieurs support sont les premiers impliqués dans la gestion des incidents cluster. Venez profiter de notre retour d'expérience et de nos conseils concernant les bonnes pratiques et recommandations concernant la mise en place, le geo-clustering, l'upgrade ou l'exploitation d'une plateforme en cluster.

Nous serons pas moins de trois sur scène pour vous présenter cette session qui fait partie du parcours Windows 7 & Windows Server 2008 R2.

Guillaume

Windows Core Support Escalation Engineer

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 %

iSCSI reconnecting suite à un reboot

Lionel.T — Fri, 23 Oct 2009 08:25:08 GMT

J’ai rencontré un problème assez pénalisant en utilisant mes VMs Cluster sous Hyper-V :

Lors de chaque redémarrage de mes guest Windows 2008 pour faire des clusters virtuels, les connexions iSCSI restaient en état reconnecting. Je devais alors reconfigurer tous les initiators afin qu’ils puissent être de nouveau fonctionnel avec mon iSCSI Target.

J’ai utilisé une solution de contournement avec la clef de registre EnablePMTUDiscovery = 1 dans HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Maintenant, mes VMs se reconnectent correctement suite à leur reboot.

Note : Cette solution de contournement peut affecter les performances TCP et n’est valable que dans le cadre de testing…

Lien Technet

http://technet.microsoft.com/en-us/library/cc957539.aspx

La liste suivante décrit les paramètres que vous pouvez utiliser avec cette valeur du registre :

1 : Lorsque vous définissez EnablePMTUDiscovery sur 1, TCP tente de découvrir la taille de l'unité MTU (Maximum Transmission Unit ) ou la taille de paquet la plus élevée sur le chemin d'accès à un hôte distant. TCP peut éliminer la fragmentation sur les routeurs sur le chemin d'accès qui connecte des réseaux à différentes unités MTU, en découvrant l'unité MTU du chemin et en limitant les segments TCP à cette taille. Inversement, la fragmentation affecte le débit TCP.

0 : Nous vous recommandons de définir EnablePMTUDiscovery sur 0. Ainsi, une unité MTU de 576 octets est utilisée pour toutes les connexions qui ne sont pas des hôtes sur le sous-réseau local. Si vous ne définissez pas cette valeur sur 0, un attaquant peut forcer la valeur de l'unité MTU à une très petite valeur et ainsi surmener la pile.

Lionel

Windows Core Support Escalation Engineer

Faites le bon choix pour votre plateforme de virtualisation #2 : translation des adresses mémoire

GuillaumeD — Wed, 07 Oct 2009 23:29:00 GMT

Le premier bulletin de cette série traitera de la gestion de la mémoire.

La gestion de la mémoire est un facteur crucial au sein d’un système d’exploitable.

Dans le monde de la virtualisation, le mécanisme visant à gérer les allocations mémoire est d’autant plus complexe et coûteux qu’il faut prendre en compte deux niveaux de mémoire alors qu’un système traditionnel n’en a qu’un seul (d’un point de vue très simplifié).

Gestion de la mémoire sur un système classique

Sur un système Windows classique, il y a une notion de mémoire physique et une notion de mémoire virtuelle.

Le système alloue un espace mémoire au kernel et un espace mémoire au mode user dans ce que l’on appelle la mémoire virtuelle. Cette mémoire virtuelle est adressée dans la mémoire physique et la mémoire paginée (le pagefile).

Sur un système 32 bit, cet espace mémoire virtuel alloue par défaut 2GB au kernel et 2GB au mode user (avec le /3GB : 1GB pour le kernel et 3GB pour le mode user).

Sur un système 64 bit, la répartition est de 8TB pour le kernel et 8TB pour le mode user.

Dans les deux cas, même si la mémoire physique disponible est inférieure à 4GB.

Une partie du travail du Memory Manager est donc de traduire les adresses virtuelles en adresses physiques (qui se trouvent soit en mémoire physique soit dans le pagefile).

Gestion de la mémoire sur un système virtualisé

Sur un système où un hypervisor s’exécute, on retrouve un niveau de mémoire supplémentaire : la mémoire allouée aux machines virtuelles et vue par celles-ci comme de la mémoire physique.

Et c’est là où ça se complique un peu et où il est nécessaire d’utiliser tout un jeu d’acronymes barbares pour comprendre ce que doit assumer l’hypervisor:

SPA (System Physical Address Space) : l’espace d’adressage physique réel (en gros dans les barrettes de RAM)
GPA (Guest Physical Address Space) : l’espace d’adressage physique vu d’une machine virtuelle (dans la représentation qu’a la machine virtuelle de la mémoire physique qui lui est présentée par l’hypervisor)
GVA (Guest Virtual Address Space) : l’espace d’adressage virtuel d’une machine virtuelle (ou de l’hôte)

Ces espaces sont représentés d’une autre manière dans le schéma ci-dessous :

Dans cette situation, le système d’exploitation s’exécutant dans la machine virtuelle traduit les adresses mémoires virtuelles (GVA) en adresses mémoires “physiques” (GPA) et l’hypervisor va traduit les adresses “physiques” des pages mémoires (GPA) de la machine virtuelle en adresses physiques réelles (SPA).

Ce qui correspond au schéma ci-dessous :

La translation d’adresse GPA vers SPA est donc prise en charge par l’hypervisor. C’est une solution de translation d’adresse logicielle.

Dans le détail, le processeur maintient une liste de correspondance des adresses de la mémoire virtuelle (GVA) utilisées par les machines virtuelles avec la mémoire physique (SPA) dans ce qu’on appelle un Translation Looksaside Buffer (TLB). Lorsque la machine virtuelle tente d’accéder à une donnée ou une fonction qui est référencée par une adresse virtuelle mais que cette adresse virtuelle ne correspond à aucun contenu cela résulte en une faute de page (Page Fault). Cette faute de page est interceptée par l’hypervisor qui charge en mémoire la donnée ou la fonction et établit la translation d’adresse en spécifiant l’adresse physique dans la page TLB.

Comme on peut le comprendre, comme toute opération traitée par du logiciel, cette tâche de translation d’adresse est consommatrice en temps CPU. Bien plus que par du microcode embarqué dans du silicium.

C’est ce que nous appellons Second Level Address Translation (SLAT).

Prise en charge de la translation d’adresse par le CPU

J’en viens alors au premier avantage qu’apportent les nouvelles fonctionnalités d’AMD et d’Intel® : le déport de cette mécanique de l’hypervisor vers le CPU.

Pour Intel®, cette tâche est assurée par la technologie Intel VT Extended Page Tables
Pour AMD, c’est la technologie Rapid Virtualization Indexing (ou Nested Page Tables) qui assume ce rôle

Les deux fondeurs utilisent une terminologie différente mais le principe est le même, et cela permet de libérer l’hypervisor de cette tâche lui donnant plus de temps pour effectuer des actions plus importantes sinon plus utiles.

Cette fonctionnalité mise en oeuvre par les CPUs est supporté par Hyper-V v2 disponible avec Windows Server 2008 R2.

Ressources

KB555223 - RAM, Virtual Memory, Pagefile and all that stuff

Virtual Address Space

(WO/2007/073624) VIRTUAL TRANSLATION LOOKASIDE BUFFER (World Intellectual Property Organisation, en Anglais)

The very first independent Nested Paging Virtualization tests (Anandtech - AMD Nested Pagaing benchmark)

Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide, Part 2 (en Anglais) – Extended Page Tables, chapitre 25.2

AMD-V™ Nested Paging

Rapid Virtualization Indexing with Windows Server 2008 R2 Hyper-V

Guest Post: Intel Inside for Hyper-V Virtualization

PDC 2008: Virtualization, An overview of the hardware features that give rise to world-class virtualization and cloud computing

Guillaume

Windows Core Support Escalation Engineer

Cluster Checkpoint registry (Windows 2003)

Lionel.T — Tue, 06 Oct 2009 17:53:00 GMT

Objectif:

Nativement, le service Cluster maintient sa configuration en copiant sur tous les nœuds du Cluster la Hive Cluster. Cette Hive (une ruche en anglais) se situe dans HKLM\Cluster et contient tous les paramètres des ressources du Cluster. C'est-à-dire que les ressources utilisées dans le Cluster stockent leurs paramètres et propriétés dans cette Hive (@IP, nom du Network Name, chemin d’un File share , etc). On retrouve également une copie de cette Hive sur le disque du Quorum (Q:\MSCS) sous la forme d’un fichier CHKxxx.tmp.

Mais si une application clusterisée n’utilise pas la section HKLM\Cluster pour y stocker ses données, comment les autres nœuds peuvent recevoir ce contenu ?

Le registry Checkpointing dans un cluster a pour objectif de propager le contenu d’un bout de base de registre qui ne serait pas localisée dans HKLM\Cluster mais dans HKLM\Software, là où les applications enregistrent généralement leurs données.

Des fichiers 0000000x.CPT présents sur le disque du quorum représentent le contenu de base de registre qui sont à sauvegarder et donc a propager lorsque ces ressources basculent d’un nœud à un autre. Ils sont organisés comme suit :

ü 0000000x.CPT représente un checkpoint registry pour une ressource.

ü Il sont stockés sur le disque du Quorum comme ceci : Q:\MSCS\<GUID>\

Q : étant le disque du Quorum et MSCS le répertoire par défaut

<GUID> est le GUID de la ressource nécessitant un checkpoint registry et que nous retrouvons dans HKLM\Cluster\GUID.

Ce principe est utilisé par SQL ou des applications génériques par exemple.

Ressources en ligne:

How a Server Cluster Works: http://technet2.microsoft.com/WindowsServer/en/library/4aa0be73-ef61-4f9c-a071-b390278b47731033.mspx?mfr=true

Checkpointing http://msdn2.microsoft.com/en-us/library/aa367195.aspx

ClusterRecovery tool: http://www.microsoft.com/downloads/details.aspx?familyid=2BE7EBF0-A408-4232-9353-64AAFD65306D&displaylang=en

Knowledge Base:

Restore registry check points stop working after you restore a server cluster

http://support.microsoft.com/default.aspx?scid=kb;EN-US;307469

174070 Registry replication in Microsoft Cluster Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;174070

Règles relatives au checkpoint Registry

Lors de tout changement sur la clé de registre ‘Checkpointée’ et lorsque la ressource est en ligne, le service cluster stocke une copie de ce registre sur la ressource quorum.
Un changement fait sur une clé de registre ‘Checkpointée’ pendant que la ressource se trouve ‘Offline’ sera ré-écrasé par la précédente valeur stockée lorsque l’application passera ‘Online’
Si les ressources basculent sur un autre nœud, le service cluster restaure les valeurs de registre depuis les fichiers stockées sur le quorum vers le nouveau nœud avant de mettre en ligne la ressource concernée par le Checkpoint.
Si une ressource est supprimée, le Checkpoint est aussi supprimé mais pas les informations contenu dans le registre local.
Les Checkpoints sont inclus dans les backup créés par la function BackupClusterDatabase
Plusieurs instances de ressources sur différents nœuds doivent être manipulées avec attention. Par exemple, une ressource A[0] stocke une valeur data[0] dans un Checkpoint A sur le nœud 0. Une ressource A[1] stocke une valeur data[1] dans un Checkpoint A sur le nœud 1. Si la ressource A[1] basculent sur le nœud 0, le service Cluster remplacera data[0] par data[1] pour le checkpoint A. Si la ressource A[0] dépend de data[0], elle sera aussi en échec. Une solution à ce problème consiste à donner des noms différents de clef ‘Checkpointé’ sur les différents nœuds.

Lister les Checkpoints actuels du Cluster:

cluster . /checkpoints

Ajouter un Checkpoint au Cluster

cluster . resource "< Nom de la ressource >" /addcheckpoints:"\Software\...”

Supprimer un Checkpoint au Cluster

cluster . resource "< Nom de la ressource >" /removecheck :"\Software\...”

Mise en situation :

Imaginons que nous avons créé une application Client/Serveur ‘Onyone’ dont les données de registre sont stockées sous HKLM\Software\Onyone et HKLM\Software\Onyone2. Nous souhaitons la mettre dans un cluster sous forme d’application générique afin d’offrir aux utilisateurs une haute disponibilité.
Pour assurer la copie des clefs précédentes, nous allons ajouter à l’aide de la commande CLUSTER.EXE, deux checkpoints sur la ressource Network Name ‘Network Name DATA’ de cette application.

C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone"
Adding registry checkpoint 'SOFTWARE\Microsoft\onyone' for resource 'Network Name DATA'...

C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone2"
Adding registry checkpoint 'SOFTWARE\Microsoft\onyone2' for resource 'Network Name DATA'...

Regardons maintenant la prise en compte de ces commandes :

C:\>Cluster . resource /checkpoints
No resource name specified.

Listing registry checkpoints for all resources...

Resource             Registry Checkpoint
-------------------- --------------------------------------------------------
Quorum Disk          None

Cluster IP Address   None

Cluster Name         None

Disk P:              None

IP File Share        None

Network Name DATA    'SOFTWARE\Microsoft\onyone'

Network Name DATA    'SOFTWARE\Microsoft\onyone2'

File Share           None

Sur le disque du quorum, nous retrouvons dans le répertoire \MSCS (par défaut), un nouveau répertoire qui a été créé et ayant le GUID de la ressource concernée et contenant deux fichiers CPT :

Ce GUID est peut être retrouvé dans la clef HKLM\Cluster.

Lionel

Windows Core Support Escalation Engineer