PI Services

Problématique

Dans certains projets d’infrastructure il est nécessaire de disposer d’un stockage accessible à travers le réseau de type NAS ou SAN. C’est notamment le cas lors de la mise en place de clusters (Hyper-V, Filers, anciennes version d’Exchange…).

Dans notre cas il s’agissait de simuler un cluster Exchange 2003 au sein d’un environnement de maquettage Hyper-V R2 SP1.

Le réseau de stockage dédié ou SAN Fiber Channel (Storage Area Network) nécessite une architecture matérielle adéquate généralement très onéreuse. Il est donc très rarement possible de pouvoir procéder à des tests sur ce genre de matériel.

Afin de simuler ce type de stockage, le composant Microsoft iSCSI Software Target 3.3 pour Windows 2008 R2 est une solution permettant de transformer un serveur en “périphérique de stockage” supportant la technologie iSCSI. Disponible depuis peu pour le grand public, ce logiciel était précédemment réservé aux éditions “Storage” de Windows Server (vendu uniquement avec du matériel).

Contexte de mise en œuvre

Cette procédure a été validée sur un environnement de maquette réalisé dans le cadre d’un projet de migration Exchange 2003 vers Exchange 2010 (30 000 boites aux lettres).

La fonctionnalité de cible iSCSI (iSCSI Target) a été implémentée sur un serveur Windows Server 2008 R2 SP1 dans le but de mettre à disposition un stockage partagé pour la restauration en maquette (P2V) de plusieurs clusters Exchange 2003.

Mise en place du serveur iSCSI sous Windows 2008 R2

Après avoir téléchargé le composant Microsoft iSCSI Software Target 3.3 , l’installation peut avoir lieu.

Installation de la fonctionnalité de cible iSCSI

	L’installation commence par décompresser ces fichiers dans un dossier ici nommé ISCSI et stocké sur le bureau.
	Une fois la décompression faite, une page Internet est affiché dans les différents liens, la partie “Install the software” contient le lien pour Windows Server.
	Après avoir cliquer sur le lien, le logiciel se télécharge…
	et se lance après validation avec le bouton “Run”
	L’installation à proprement parler se lance en cliquant sur suivant.
	Le contrat EULA est à valider afin de continuer.
	La fonctionnalité propose le choix de l’emplacement d’installation
	et de participer au programme d’amélioration de l’expérience utilisateur.
	L’installation est prête, il ne reste qu’à cliquer sur “Install”.
	L’installation de la fonctionnalité cible iSCSI s’exécute.

La configuration du stockage

	Il faut maintenant configurer une cible iSCSI ainsi que des LUN (Logical Unit)
	La première action consiste à vérifier les propriété du serveur iSCSI.
	Il est conseillé de dédier une interface au réseau de stockage. et de vérifier qu’elle soit la seule à être active en ce qui concerne la cible iSCSI.
	Après cette vérification, la création d’une cible iSCSI peut commencer
	Le nommage de la cible iSCSI se fait à ce niveau. Il est important de mettre un nom en adéquation avec l’utilisation de cette ressource.
	La définition des clients ayant accès à cette ressources se renseignent directement durant la création.(Mode Advanced)
	Il est possible d’identifier les clients (ou Initiator) pour cette ressource à partir de l’une des informations suivantes: IQN Nom DNS Adresse IP Adresse MAC
	Lors de l’ajout de plusieurs clients pour une même cible, le warning suivant prévient d’éventuels problèmes si l’application ou le système d’exploitation ne sait pas exploiter cela correctement.
	Ici , les deux clients apparaissent bien.
	Dans le cas de clients multiples, la liste n’apparait que dans le mode avancé.
	Une fois la cible iSCSI configuré, il est intéressant d’aller modifier, dans ses propriétés, son IQN afin d’identifier plus facile cette ressource sur le réseau de stockage. IQN pour iSCSI Qualified Name

Création de LUN (Unité Logique de stockage)

	La cible iSCSI étant défini, il faut créer les LUN. Ils sont sous formes de fichiers .vhd..
	La création commence par la définition du nom et de l’emplacement du futur LUN.
	Le paramétrage de la taille se fait en Mo. Le disque dur crée est un disque dur de taille fixe. Pour information: si un disque virtuel dur de taille fixe de 10Go est stocké dans un disque virtuel dynamique ce dernier ne grossi pas que de quelques Mo. (dans le cas présent <100 Mo)
	Le LUN peut être affecté à une seule cible iSCSI.

Le stockage a été crée et affecté à une cible iSCSI. Il reste maintenant à installer et configurer la partie client appelé “Initiator”.

Mise en place de l’initiateur iSCSI (partie cliente)

Installation du client iSCSI

	La partie MPIO ne sera pas implémenté dans ce scénario, il n’est pas nécessaire de l’installer. MPIO pour Multi Path Input/Outpout MPIO : Technologie permettant à un système de bénéficier de plusieurs chemins d’accès en lecture/écriture sur un périphérique de stockage. Plus d’info sur les nouveautés apportés par 2008 sur le MPIO : http://technet.microsoft.com/fr-fr/library/dd878505(WS.10).aspx

Configuration du client iSCSI (iSCSI Initiator)

	La configuration par défaut donne un nom complexe à l’initiateur. Il peut être utile de le changer afin de renseigner son utilité.
	Le nom du client iSCSI a été changé pour cluster-e2k3-node01
	Dans l’onglet discovery, la connexion avec la cible va être défini (Target Portals)
	La cible iSCSI est désignée par son adresse IP.
	Dans l’onglet “Targets” , le bouton “Log on” permet de mettre cette connexion en automatique afin de ne pas couper l’accès aux données suite à un redémarrage.

Initialisation et formatage du disque.

	Une fois la connexion active, le système détect un nouveau disque.
	Il est nécessaire de l’initialiser
	Le nouveau disque dur se comporte comme un disque local.

Conclusion

Au niveau de ce billet nous avons pu mettre en place un serveur de stockage utilisant la technologie iSCSI de manière simple. C’est un composant essentiel à plusieurs solutions de clustering disponible dans des produits comme Exchange (avant 2010), SQL Server, Hyper-V R2 …

Pour améliorer la configuration, il serait intéressant de creuser le sujet de la sécurisation de ces flux de données et donc d’étudier la mise en œuvre de l’authentification entre les parties clientes et serveur iSCSI.

Peut être le sujet d’un nouveau post …

Symptôme

Suite au déploiement d’une architecture OCS 2007 R2 composée de plusieurs serveurs (typiquement un serveur front-end déployé dans le réseau local associé à un serveur Edge situé en DMZ), les erreurs suivantes peuvent se produire si l’un des serveurs ou les deux exécutent Windows Server 2008 R2 :

Voici le détail de chacune des deux erreurs :

Explication

Ces erreurs sont dues à un problème “connus” avec OCS 2007 R2 et Windows Server 2008 R2 autour de la fonction InitializeSecurityContext de la couche TLS.

Ces erreurs empêchent toute communication TLS entre les serveurs et entraînent donc des disfonctionnement au sein d’OCS (le protocole SIPs étant utilisé par défaut).

Résolution

Pour résoudre ces problèmes, il faut installer un correctif sur l’ensemble des serveurs OCS 2007 R2. Ce correctif est disponible sur demande à l’adresse suivante :

• http://support.microsoft.com/kb/975858/en-us

Suite à l’installation, les serveurs doivent être redémarrés.

Lorsqu’un serveur Windows 2008 ou 2008 R2 est membre d’un domaine, il arrive parfois que l’on ai besoin d’ouvrir une session avec un compte local.

Dans ce cas, il est nécessaire de spécifier le nom du serveur devant le login :

<SERVEUR>\<login>

Voici une astuce permettant d’éviter la saisie du nom du serveur : utiliser le point à la place :

.\<login>

De cette manière, Windows va considérer qu’il s’agit d’une ouverture de session locale. Le nom du serveur sera même affiché (pratique lorsque l’on connait que l’IP du serveur !)

Voilà, j’espère que cette astuce vous sera utile.

Pré-requis et architecture

Parmis les pré-requis à la mise en place de DirectAccess, un serveur Web répondant en HTTPS est nécessaire. Ce serveur, nommé NLS pour Network Location Server, ne doit pas être joignable depuis l'extérieur. En effet, sa seule et unique fonction est de permettre aux postes clients sous Windows Seven de détecter correctement leur emplacement réseau :

• Si le serveur NLS est accessible, alors le poste client sait qu'il est connecté à l'intérieur du réseau de l'entreprise (dans ce cas, le poste ne tente pas de se connecter à l'aide des technologies DirectAccess)
• Si le serveur NLS est inaccessible, alors le poste client sait qu'il est connecté à l'extérieur (dans ce cas, le poste tente de se connecter à l'aide des technologies DirectAccess)

Le but du serveur NLS n’est pas d’afficher un site Web complexe mais juste de répondre à une simple requête HTTP encapsulé dans du SSL. En ce qui concerne le contenu de cette page, il n'y a pas de pré-requis particulier (une page HTML vide, ou bien la page par défaut de IIS 7.5 peut tout à fait être utilisée!). Pour héberger le "rôle" NLS, Microsoft conseille de respecter les préconisations suivantes :

• Utiliser un serveur dédié (même si il est tout à fait envisageable de réutiliser un serveur Web existant)
• Mettre en place un site Web hautement disponible

La mise en place de la haute disponibilité sur le rôle NLS est extrêmement importante ! En effet, si le serveur NLS tombe, tous les postes de travail situés en LAN pour lesquels DirectAccess est configuré, penseront qu'ils sont à l'extérieur de l'entreprise (car le NLS ne sera pas joignable) et tenteront alors de se connecter en IPv6 à la passerelle DirectAccess ce qui perturbera leur connexion au réseau de l'entreprise !

Si l'on respecte à la lettre les préconisations de Microsoft, la mise en oeuvre du rôle NLS implique donc l'utilisation de deux serveurs Web avec équilibrage de charge réseau (load balancer matériel ou NLB). Afin de minimiser les coûts en matériel, il est tout à fait possible de virtualiser les serveurs Web sous Microsoft Hyper-V R2 et d'activer le NLB entre les deux machines virtuelles pour fournir la haute disponibilité.

Dans la suite de ce billet, vous trouverez la procédure complète mettre en place cette configuration (ferme de machines virtuelles NLS en NLB). La petite subtilité étant l'usage d'une version Core de Windows Server 2008 R2 ce qui permet de réduire encore plus l'utilisation en ressources matérielles sur les serveurs Hyper-V tout en minimisant la maintenance.

Déploiement de 2008 R2 en version core

Une fois l'installation du système en version Core réalisée dans les deux machines virtuelles, et une fois le mot de passe du compte Administrator défini, une invite de commande telle que celle-ci s'affiche :

Une série de commande va permettre de mettre en place le serveur Web IIS 7.5.

Pour commencer la commande sconfig (nouveauté de 2008 R2), permet d'effectuer une configuration rapide (nom de la machine, jointure au domaine, configuration TCP/IP).

Je ne détaille pas cette partie qui ne devrait pas poser trop de soucis. En cas de doute vous pouvez vous référer à la documentation sur Technet ( http://technet.microsoft.com/en-us/library/ee441254(WS.10).aspx). Pour les amateurs de l'invite de commande, il est également possible d'exécuter ces différentes opérations à l'aide de netsh (cf. : http://technet.microsoft.com/en-us/library/ee441257(WS.10).aspx).

Une fois ces différentes opérations effectuées on peut envisager d’activer le bureau à distance pour avoir une administration plus souple.

Mise en place du rôle IIS 7.5 sur 2008 R2 en version core

Une fois le système correctement configuré, le rôle serveur Web doit être installé.

Remarque : Dans un premier temps, seuls les composants basiques de IIS sont déployés afin de pouvoir disposer d'un site (enfin une page ;-) ) complètement statique.

Une nouvelle commande est apparue dans 2008 R2 pour installer les rôles et fonctionnalités offerte par la version core :

dism /online /enable-feature /featurename:IIS-WebServerRole

Pour faciliter l’administration du site, il faut activer la prise de contrôle à distance au travers de la console d’administration Internet Information Service (IIS) Management et le WAS :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Attention cela ne suffit pas, il faut aussi autoriser l’administration à distance par MMC en ajoutant la clé de registre suivante :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

La dernière étape consiste à démarrer le service de management et à modifier son type de démarrage en automatique pour qu'il se lance à chaque démarrage de la machine :

sc config wmsvc start= auto

net start wmsvc

Une fois ces étapes réalisées, le site Web par défaut de IIS doit être visible en saisissant http://<IP-SERVEUR> et le rôle IIS du serveur Core peut être configuré à distance à la console MMC graphique !

Installation du certificat et passage en HTTPS

Pour avoir accès au site en HTTPS il reste deux choses à faire. La première consiste à installer le certificat contenant la clé privée en ligne de commande :

certutil –importPFX  “C:\certificat.pfx”

Lors de son exécution la commande certutil nécessite la saisie du mot de passe pour valider l’import du PFX.

Une fois le certificat importé dans le magasin de certificat de l'ordinateur, il faut configurer IIS de manière à ce qu'il le prenne en compte. Pour cela, vous pouvez utiliser la console IIS Management depuis un poste distant. Il faut cliquer sur le site Web par défaut, puis sur Bindings, et enfin sélectionner le certificat voulu dans la liste déroulante (dans cet exemple le certificat se nomme "PI Services Secure Access").

A l'issue de cette étape, le site Web par défaut doit être accessible en saisissant l'URL https://<IP-SERVEUR>.

Mise en place du NLB entre les deux machines virtuelles

Remarque : Avant d'entamer la configuration du NLB sur les deux machines virtuelles, vérifiez que l'option enable spoofing of MAC address est bien activée dans les propriétés de la carte réseau sur les deux machines virtuelles (cette option se configure avec la console MMC Hyper-V Manager). Cette option est apparue avec Hyper-V R2 et permet le bon fonctionnement du NLB au sein des machines virtuelles.

Pour mettre en place le Network Load balancing, il faut commencer par installer la fonctionnalité sur chacun des serveurs de la ferme. Pour cela, saisissez la commande suivante :

Dism /online /Enable-Feature /FeatureName:NetworkLoadBalancingHeadlessServer

Une fois la fonctionnalité installée, le plus simple est d'utiliser la console Network Load Balancing Manager depuis un poste client pour configurer le cluster (la console doit être exécutée avec les "crédentials" d'un compte possédant les droits administrateur sur les serveurs Web).

Pour créer un nouveau cluster, il faut effectuer un clic droit sur Network Load Balancing Clusters, sélectionner New, puis se laisser guider par l’assistant :

Il est possible d'affiner la configuration de la ferme NLB en précisant les ports TCP et UDP sur lesquels l'équilibrage de charge sera actif. Dans l'exemple ci-dessous, deux règles activent l'équilibrage de charge sur les ports 80 TCP et 443 TCP (seul l'équilibrage de charge sur le 443 est nécessaire à DirectAccess).

Pour ajouter un nouveau membre à la ferme NLB, il faut effectuer un clic-droit sur le cluster existant, sélectionner Add Host to Cluster, puis préciser l'adresse IP du deuxième serveur Web.

Une fois le second noeud ajouté et le cluster correctement convergé, il faut vérifier que le site Web est accessible en HTTPs via l'adresse IP virtuelle du cluster (saisir https://<adresse-IP-virtuelle> dans un navigateur).

La dernière étape consiste à créer une entrée dans le DNS pour pointer vers l'adresse IP virtuelle. Cette entrée DNS doit correspondre au FQDN du certificat précédemment importé (par exemple NLS.PISERVICES.FR).

Une fois l'entrée DNS créée, vérifiez que le site Web est accessible via l'URL https://nls.piservices.fr. Aucune erreur de certifiat ne doit s'afficher dans le navigateur !

Remarque : Il est possible de tester le cluster en mettant en pause l'une des deux machines virtuelles (via la console MMC Hyper-V Manager) !

A partir de cet instant la ferme de serveurs NLS est pleinement opérationnelle !

Mise en place d'une page Web dynamique sur la ferme NLS

Pour faciliter le dépannage lors de la mise en place de DirectAccess, il est souvent nécessaire de connaitre l'adresse IP utilisée par le poste de travail pour accéder au serveur NLS. Cela permet de déterminer quelle technologie de transition a été utilisée (6to4, Teredo, ISATAP, NAT64...).

Pour cela il suffit de modifier la configuration de la page par défaut des serveurs NLS afin d'afficher l’IP du client. Dans cet exemple, le langage ASP.net est utilisé.

Pour pouvoir héberger une page en ASP.net des composants supplémentaires doivent être installé sur les serveurs. Tout d’abord, il faut installer les Framework .NET 2 et 3 :

dism /online /enable-feature /featurename:NetFx2-ServerCore

dism /online /enable-feature /featurename:NetFx3-ServerCore

Les fonctionnalités ISAPI et ASP.NET doivent également être installées sur le rôle IIS :

dism /online /enable-feature /featurename:IIS-WebServerRole

dism /online /enable-feature /featurename:IIS-ISAPIFilter

dism /online /enable-feature /featurename:IIS-ISAPIExtensions

dism /online /enable-feature /featurename:IIS-NetFxExtensibility

dism /online /enable-feature /featurename:IIS-ASPNET

Enfin il faut installer le WAS et le service de gestion :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService

dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Pour démarrer le service de management, le rendre automatique et autoriser la gestion à distance, il faut exécuter les commandes suivantes :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

sc config wmsvc start= auto

net start wmsvc

A présent le serveur est capable d’interpréter du code ASP.net, il est donc possible de créer une page ASPX. Dans l'exemple ci-dessous, une page default.aspx a été créée et le site a été reconfiguré pour l'utiliser en document par défaut :

Voici le résultat obtenu avec les méthodes permettant de récupérer les adresses IP (seul le "body" de la page est affiché) :

<body>
    <form id="form1" runat="server">
    <div>
        Nom du serveur :    <%= Request.ServerVariables["SERVER_NAME"]%><br />
        Adresse IP du serveur :     <%= Request.ServerVariables["SERVER_ADDR"]%><br />
        Adresse IP du visiteur :     <%= Request.ServerVariables["REMOTE_ADDR"]%>
    </div>
    </form>
</body>

N'hésitez pas à laisser un commentaire sur cette procédure si vous avez des éléments à ajouter ou des précisions à demander.

Commande sconfig et activation de Windows

Les versions Core de Windows Server 2008 R2 intègrent un nouvel utilitaire nommé sconfig. Cet utilitaire permet de simplifier les tâches de configuration usuelles (installation des mises à jour Windows Update, intégration dans un domaine, activation du bureau à distance, réglage de la date et de l’heure…) via un système de menus textuels.

Malheureusement sconfig n’intègre pas d’option pour activer le système d’exploitation. Pour cela il faut toujours utiliser le script slmgr.vbs présent dans “C:\Windows\System32”.

Procédure d’activation

Voici la procédure à suivre pour effectuer l’activation avec slmgr.vbs :

Dans un premier temps il est possible d’afficher l’état d’activation du serveur en saisissant les commandes suivantes :

• cd c:\Windows\System32
• slmgr.vbs –xpr

Dans notre exemple le système n’est pas activé car une date de fin est annoncée pour la période de grâce.

Pour insérer la clé de produit dans le système il faut ensuite saisir la commande suivante :

• slmgr.vbs –ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

Une fenêtre Windows Script Host doit apparaître suite à l’injection de la clé de produit. Pour débuter l’activation à travers Internet, la commande suivante doit être saisie :

• slmgr.vbs /ato

Si l’activation est réussie, le message suivant doit apparaître au bout de quelques secondes : “Product activated successfully”.

Suite à l’activation du serveur, la commande slmgr.vbs –xpr doit renvoyer le message suivant “The machine is permanently activated”.

Positionnement d’un serveur de proxy

Si l’accès au Web est conditionné par le passage à travers un serveur de proxy, celui-ci doit être renseigné au préalable avec la commande suivante :

• netsh winhttp set proxy <proxy-FQDN>:<proxy-port>

Dans le cas contraire une erreur de type “slui.exe 0x2a 0x80072EE2” ou “error: 0x80072EE2” se produit lors de la tentative d'activation.

Suppression d’une sauvegarde de type « Non Système » (Bare Metal Recovery).

Lancez une console PowerShell et affichez la liste des sauvegardes disponibles

Recherchez la sauvegarde à supprimer (creation time)

Copiez le Shadow Copy ID, puis lancez Diskshadow

Pour supprimez, tapez Delete shadows ID et collez l’ID.

Pourquoi synchroniser l’heure ?

Au sein d’un domaine Active Directory, tous les postes de travail et serveurs membre synchronisent leur horloge auprès du contrôleur de domaine ayant le rôle d’émulateur PDC (Primary Domain Controller) que joue le rôle de serveur de temps pour le domaine.

Le bon fonctionnement de certains protocoles comme Kerbros v5, utilisé pour authentifier les utilisateurs au sein du domaine et assurer l’accès aux ressources partagées, est fortement dépendant de la synchronisation horaire entre les machines.

En effet, la RFC 4120 stipule que le décalage acceptable entre deux hôtes est de l’ordre de 5 minutes environ.

Each host on the network MUST have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection.  The degree of "looseness" can be configured on a per-server basis, but it is typically on the order of 5 minutes.

C’est d’ailleurs cette valeur qui est positionnée par défaut depuis Windows 2000 sur le service Kerberos (cf. article KB837361 de la base de connaissance Microsoft).

Lorsque le décalage entre deux postes dépasse les 5 minutes, aucune authentification n’est possible via le protocole Kerberos. Ceci est particulièrement gênant lorsque la machine décalée correspond à un contrôleur de domaine ou à un serveur de fichiers.

Il convient donc de s’assurer que tous les postes et serveurs sont capables de joindre l’émulateur PDC et de mettre à jour leur horloge (lorsque cela n’est pas le cas, des erreurs W32Time sont générées par le service de temps Windows sur les postes de travail).

Il est également très important de synchroniser l’émulateur PDC avec une source de temps externe valide de manière à ce que l’heure propagée au sein du domaine soit la plus proche possible de l’heure exacte.

Or de trop nombreuses entreprises ne font pas attention à ce point qui n’est pourtant pas un détail car une juste synchronisation de l’horloge simplifie la vie des utilisateurs qui sont très friands de services Web où l’horodatage a une importance certaine (tweeter, myspace ou facebook pour ne pas les nommer).

D’un point de vue IT, la synchronisation de tous les équipements informatique (postes de travail, serveurs, mais aussi NAS, pare-feu et autres équipements réseau) auprès d’une seule et même source de temps permet de simplifier énormément les opérations de dépannage car les fichiers de logs sont alors parfaitement synchrones.

Quelle source de temps utiliser ?

Par défaut tout poste Windows est configuré pour synchroniser son horloge auprès du serveur “time.windows.com”.

De nombreux serveurs NTP “libres” sont accessibles en France et dans le monde (notamment les serveurs NTP des grandes universités françaises). De plus la plupart des FAI proposent à leurs clients un service de synchronisation de temps.

Il est néanmoins un projet qui se distingue de tous les autres par son ampleur : NTP Pool Project. Ce projet a pour objectif de proposer gratuitement un cluster de serveurs de temps gigantesque (1873 serveurs de temps à l’heure où j’écris ces lignes).

L’avantage de ce projet est qu’il propose également une configuration régionalisée par continent et par pays. Ainsi pour synchroniser votre PDC avec des serveurs de temps uniquement situés en France (env. 130 serveurs), il suffit de configurer le serveur pour pointer vers la liste de FQDN suivants :

• 0.fr.pool.ntp.org
• 1.fr.pool.ntp.org
• 2.fr.pool.ntp.org
• 3.fr.pool.ntp.org

Comment procéder ?

Pour reconfigurer l’horloge d’un poste sous Windows et notamment celle d’un émulateur PDC, les commandes suivantes peuvent être utilisées :

• La commande net time fonctionne sur un contrôleur de domaine Windows 2000, 2003 et Windows 2008 (cette commande est maintenant obsolète avec Windows Server 2008 R2)
• La commande w32tm doit impérativement être utilisée si le contrôleur de domaine exécute Windows Server 2008 R2

Avec la commande net time, voici la commande à saisir pour reconfigurer l’horloge du serveur de temps (PDC) vers le cluster “pool.ntp.org” français :

net time /setsntp:"0.fr.pool.ntp.org 1.fr.pool.ntp.org 2.fr.pool.ntp.org"

Pour vérifier la modification il est possible d’exécuter la commande net time /querysntp. Pour forcer la resynchronisation du PDC, il suffit de redémarrer le service de temps Windows (net stop w32time | net start w32time).

Sur un contrôleur de domaine Windows Server 2008 R2, la commande suivante doit être exécutée pour arriver au même résultat :

w32tm /config /update /manualpeerlist:"0.fr.pool.ntp.org,0x8 1.fr.pool.ntp.org,0x8 2.fr.pool.ntp.org,0x8 3.fr.pool.ntp.org,0x8" /syncfromflags:MANUAL

Cette commande doit être suivie des commandes suivantes pour que la configuration soit prise en compte et la resynchronisation initiée :

• w32tm /config /update
• w32tm /resync

Remarque : Il est également possible de le service de temps Windows pour forcer la resynchronisation (net stop w32time | net start w32time).

Les points à valider

Quelques points doivent être validés avant d’effectuer la modification sur l’émulateur PDC :

• Le port du protocole NTP doit être ouvert depuis l’émulateur PDC vers Internet (il s’agit du port UDP 123)
• Si le contrôleur de domaine est virtualisé, il convient de désactiver la synchronisation horaire entre la machine virtuelle et l’hôte physique (sinon l’heure synchronisée à travers le réseau sera toujours réécrite par celle de la machine hôte).

Voici un exemple pour un contrôleur de domaine (émulateur PDC) virtualisé avec Hyper-V 2.0 (version d’Hyper-V intégrée à Windows Server 2008 R2) :

 

Comment mettre à jour les clients ?

En ce qui concerne les postes membres du domaine, aucune opération manuelle n’est nécessaire, le service de temps Windows étant capable d’effectuer les mises à jour automatiquement.

Pour les postes configurés en groupe de travail, il convient d’exécuter la commande suivante, puis de redémarrer le service de temps Windows :

w32tm /config /update /manualpeerlist:"ntp.ad.lan,0x8"
/syncfromflags:MANUAL,DOMHIER

Remarque : Il est conseillé de créer une entrée DNS de type CNAME (alias) pointant vers l’émulateur PDC (par exemple ntp.domainead.local). Cela permet de pouvoir reconfigurer très simplement tous les postes de travail hors domaine en cas de bascule du rôle FSMO.

Dans le scénario idéal, tous les équipements réseau (commutateurs, routeurs, pare-feu, imprimantes réseau, bornes WiFi, serveurs NAS…) doivent également pointer vers le FQDN ntp.domainead.local de manière à assurer un horodatage cohérent.

Pour aller plus loin…

Quelques liens utiles pour aller plus loin :

• RFC 1305 sur le protocole NTP v3 (http://www.rfc-editor.org/rfc/pdfrfc/rfc1305.txt.pdf)
• RFC 4120 sur le protocole Kerberos v5 (http://www.rfc-editor.org/rfc/rfc4120.txt)
• Site du projet de pool NTP (http://www.pool.ntp.org/fr/use.html)
• Entrées de registre Kerberos sous Windows 2003 (http://support.microsoft.com/kb/837361/en-us)
• Lien Technet sur la synchronisation du PDC (http://technet.microsoft.com/en-us/library/cc784553(WS.10).aspx)

Parmi les nombreuses fonctionnalités cachées de Windows 7 on retrouve le GodMode, il s’agit en fait d’un dossier spécial permettant de personaliser divers réglages. Ce dossier est aussi accessible sous Windows 2008R2.

Pour cela, il faut créer un nouveau dossier et de le nommer

ModeDieu.{ED7BA470-8E54-465E-825C-99712043E01C}

Une icone similaire à celle du panneau de configuration apparait.

Pour les autres dossiers spéciaux : http://msdn.microsoft.com/en-us/library/ee330741(VS.85).aspx

La problématique

Lors de l’installation de Symantec Mail Security for Exchange 6.5 sur un serveur Exchange 2010, l’erreur suivante se produit :

Failed to enable ASP.NET web extensions. Installation will not continue.

L’explication

A l’heure actuelle Symantec Mail Security utilise encore des fonctionnalités héritées de IIS 6 (l’installeur à notamment besoin du script iisext.vbs).

Par défaut les composants de rétrocompatibilité IIS 6 suivants sont installés sur un serveur Exchange 2010 exécutant le rôle Hub, Mailbox, Cas ou Unified Messaging (seul le rôle Edge n’est pas concerné car il n’utilise pas IIS) :

• IIS 6 Metabase Compatibility
• IIS 6 Management Console

Cela n’est pas suffisant pour SMS qui nécessite également le composant IIS 6 Scripting Tools.

La Solution

La solution consiste tout simplement à installer les composants IIS 6 Scripting Tools et IIS 6 WMI Compatibility (le premier étant dépendant du second, les deux doivent être installés).

Cette opération peut être effectuée graphiquement via la console MMC Server Manager ou bien en console Powershell via la commande Add-WindowsFeature.

Pour plus d’informations sur les pré-requis nécessaires à Exchange 2010, vous pouvez consulter le lien suivant :

http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx

Cette solution est tirée de la note technique suivante, pour l’instant uniquement validée avec SMS 6.0 :

http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2008081210523154

La problématique

Lors de l’exécution de la commande Sysprep sur une machine virtuelle Windows Seven fraîchement installée, j’ai rencontré l’erreur suivante :

A fatal error occurred while trying to sysprep the machine.

Le sysprep était exécuté avec les options suivantes :

• /generalize
• /oobe
• /unattend

Suite à des recherches sur le site http://support.microsoft.com, j’ai localisé plusieurs articles traitant d’une problématique proche mais appliquées à Windows Vista. Aucune ne m’a été utile.

La solution

J’ai finalement trouvé la solution sur un forum Technet dont voici le lien :

http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/6208afb1-8f3e-4657-a618-0e4a52e9f546

Le problème semblerait venir du service “Windows Media Player Network Sharing Service” et à mon grand étonnement la désactivation de ce service (ou bien la suppression du processus associé : wmpnetwk.exe) a bel et bien résolu mon problème !

En proie au doute, j’ai ré-exécuté l’opération plusieurs fois sur la même machine (en utilisant un snapshot Hyper-V pour revenir en arrière) et ce tips semble bel et bien viable !

N’hésitez pas à laisser un commentaire ou un retour d’expérience si vous avez déjà été confronté à ce problème avec la commande sysprep de Windows 7 ou si ce billet vous a aidé !