PI Services

Le blog des collaborateurs de PI Services

2008 R2 – Mise en place d’un serveur iSCSI

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

clip_image002_thumb3


L’installation commence par décompresser ces fichiers dans un dossier ici nommé ISCSI et stocké sur le bureau.

clip_image005_thumb1


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.

clip_image007_thumb1


Après avoir cliquer sur le lien, le logiciel se télécharge…

iSCSI-Instal03_thumb1
et se lance après validation avec le bouton “Run”
iSCSI-Install04_thumb3
L’installation à proprement parler se lance en cliquant sur suivant.
iSCSI-install5_thumb1
Le contrat EULA est à valider afin de continuer.
iSCSI-install6_thumb1
La fonctionnalité propose le choix de l’emplacement d’installation
iSCSI-install7_thumb3
et de participer au programme d’amélioration de l’expérience utilisateur.
iSCSI-install09_thumb3
L’installation est prête, il ne reste qu’à cliquer sur “Install”.
iSCSI-install10_thumb1
iSCSI-install11_thumb2
L’installation de la fonctionnalité cible iSCSI s’exécute.

La configuration du stockage

iSCSI-config01_thumb3
Il faut maintenant configurer une cible iSCSI ainsi que des LUN (Logical Unit)
iSCSI-config02_thumb2
La première action consiste à vérifier les propriété du serveur iSCSI.
iSCSI-config03_thumb2
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.
iSCSI-config04_thumb2
Après cette vérification, la création d’une cible iSCSI peut commencer
iSCSI-config05_thumb2  
iSCSI-config06_thumb4
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.
iSCSI-config07_thumb4
La définition des clients ayant accès à cette ressources se renseignent directement durant la création.(Mode Advanced)
iSCSI-config08_thumb2  
iSCSI-config09_thumb2


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
  • iSCSI-config11_thumb1  
    iSCSI-config12_thumb1
    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.
    iSCSI-config13_thumb1
    Ici , les deux clients apparaissent bien.
    iSCSI-config14_thumb1
    Dans le cas de clients multiples, la liste n’apparait que dans le mode avancé.
    iSCSI-config15_thumb2
    iSCSI-config16_thumb1
    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)

    iSCSI-disk01_thumb1
    La cible iSCSI étant défini, il faut créer les LUN. Ils sont sous formes de fichiers .vhd..
    iSCSI-disk02_thumb1  
    iSCSI-disk03_thumb2
    La création commence par la définition du nom et de l’emplacement du futur LUN.
    iSCSI-disk04_thumb1
    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)
    iSCSI-disk05_thumb1  
    iSCSI-disk06_thumb1
    Le LUN peut être affecté à une seule cible iSCSI.
    iSCSI-disk07_thumb1  

    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

    CLT2K3-01_thumb1
    CLT2K3-02bis_thumb2
    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
    CLT2K3-03_thumb1  
    CLT2K3-05bis_thumb1  

    Configuration du client iSCSI (iSCSI Initiator)

    CLT2K3-config01_thumb3
    La configuration par défaut donne un nom complexe à l’initiateur.
    Il peut être utile de le changer afin de renseigner son utilité.
    CLT2K3-config02_thumb1CLT2K3-config01_thumb4
    Le nom du client iSCSI a été changé pour cluster-e2k3-node01
    CLT2K3-config01-bis_thumb1
    Dans l’onglet discovery, la connexion avec la cible va être défini (Target Portals)
    CLT2K3-config03_thumb2
    La cible iSCSI est désignée par son adresse IP.
    CLT2K3-config07_thumb2  
    CLT2K3-config05_thumb1
    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.

    CLT2K3-format01_thumb
    Une fois la connexion active, le système détect un nouveau disque.
    CLT2K3-format02_thumb
    Il est nécessaire de l’initialiser
    CLT2K3-format03_thumb  
    CLT2K3-format04_thumb  
    CLT2K3-format05_thumb
    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 …

    OCS 2007 R2 – Echec des connexions TLS sous Windows Server 2008 R2

    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 :

    Event ID : 14428, Source : OCS Protocol Stack

    Event ID : 14428, Source : OCS Protocol Stack

    Voici le détail de chacune des deux erreurs :

    Log Name: Office Communications Server
    Source: OCS Protocol Stack
    Date: 23/12/2010 00:53:43
    Event ID: 14428
    Task Category: (1001)
    Level: Error
    Keywords:  Classic
    User:  N/A
    Computer: <FQDN du serveur OCS source>
    Description:
    TLS outgoing connection failures. Over the past 15 minutes Office Communications Server has experienced TLS outgoing connection failures 122 time(s). The error code of the last failure is 0x80004005 (Unspecified error) while trying to connect to the host “<FQDN du serveur OCS de destination>”.

     

    Log Name: Office Communications Server
    Source: OCS Protocol Stack
    Date: 23/12/2010 00:46:08
    Event ID: 14502
    Task Category: (1001)
    Level: Error
    Keywords: Classic
    User: N/A
    Computer: <FQDN du serveur OCS source>
    Description:
    A significant number of connection failures have occurred with remote server <FQDN du serveur OCS de destination>”. IP <Adresse IP du serveur OCS de destination>”. There have been 60 failures in the last 7 minutes. There have been a total of 60 failures.  The specific failure types and their counts are identified below.

    Instance count   - Failure Type
    60                
    80004005 

     

    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 :

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

    Windows 2008/2008R2 – Ouvrir une session localement

    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 !)

    image

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

    DirectAccess - Mise en place d'une ferme NLS en version Core virtualisée sous Hyper-V R2

    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 :

    Cmd

    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).

    sconfig 

    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.

    MMC-Remote-Management

    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").

    Binding

    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 :

     New-Cluster1 New-Cluster2

    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).

    New-Cluster-Rules

    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.

    New-Cluster-Membres

    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 :

    DefaultDocument

    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>

    NLS

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

    2008 R2 – Activer Windows sur une version Core de Windows Server 2008 R2

    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.

    image

    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

    image

    image

    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”.

    image

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

    image

    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.

    2008 R2 – Resynchroniser l’heure d’un domaine AD avec une source de temps externe

    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).

    image

    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) :

      image 

    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 :

    Le mode Dieu de Windows 7

     

    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.

    image

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

    SMS – Erreur à l’installation de Symantec Mail Security 6.5 sur un serveur Exchange 2010 sous 2008 R2

    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.

    image

    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.

    image

    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

    SYSPREP – Erreur lors de l’exécution d’un SYSPREP sous Windows Seven ou Windows Server 2008 R2

    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.

    image

    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 !

    image

    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é !