PI Services

La préparation de l’annuaire Active Directory pour le déploiement du service pack 2 d’Exchange Server 2010 est tout à fait classique.

Mise à jour du schéma Active Directory

Dans un premier il faut déployer les extensions de schéma Echange Server 2010 SP2 à l’aide de la commande setup.com /PrepareSchema.

Remarque : Cette opération effectue des modifications sur la partition de schéma de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Schema Admins”.

Les extensions de schéma du service pack 2 intègrent de nouvelles classes et de nouveaux attributs. Parmi ces nouveaux attributs il y a notamment 5 nouveaux attributs nommés extensionCustomAttribute1 à extensionCustomAttribute5. Ces attributs supplémentaires peuvent être utilisés pour stocker des propriétés supplémentaires sur les objets destinataires (boîtes aux lettres, groupes, contacts…). Ils sont utilisables avec les commandes PowerShell suivantes :

- Set-DistributionGroup
- Set-DynamicDistributionGroup
- Set-Mailbox
- Set-MailContact
- Set-MailPublicFolder
- Set-RemoteMailbox

Pour aller plus loin au sujet de ces nouveaux attributs vous pouvez consulter l’article suivant sur le blog de l’équipe Exchange :

http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx

Ainsi que le document de référence sur les extensions de schéma Exchange Server (document mis à jour suite à la sortie du SP2) :

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5401

Pour vérifier que le schéma a bien été mis à jour il suffit de vérifier la valeur de l’attribut rangeUpper sur la classe ms-Exch-Schema-Version-Pt à l’aide d’un outil comme ADSIEdit (ou via une requête de type dsquery par exemple).

Suite à la mise à jour du schéma, la valeur de l’attribut rangeUpper passe de 14728 (version Exchange 2010 SP1) à 14732 (version Exchange 2010 avec SP2).

Mise à jour de l’organisation Exchange

L’étape suivante consiste à mettre à jour l’organisation Exchange 2010 à l’aide de la commande setup.com /PrepareAd (dans cet exemple l’organisation se nomme PIServices).

Remarque : Cette opération effectue des modifications sur la partition de configuration de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Enterprise Admins”.

Pour valider la propagation des modifications apportées à la partition de configuration sur les différents contrôleurs de domaine le plus simple consiste à affichez les propriétés de l’organisation Exchange via ADSIEdit.

L’attribut objectVersion de l’organisation passe de 13214 (Exchange 2010 SP1) à 14247 (Exchange 2010 SP2).

Mise à jour des domaines

Il faut enfin mettre à jour chaque domaine de la forêt Active Directory à l’aide de la commande setup.com /PrepareDomain.

Remarque : Cette opération effectue des modifications sur la partition de domaine du domaine concerné et par conséquent nécessite l’utilisation d’un compte membre du groupe “Domain Admins” dans le domaine concerné.

Suite à l’application du service pack 2 d’Exchange 2010 la valeur de l’attribut objectVersion sur l’objet CN=Microsoft Exchange System Objects présent à la racine du domaine passe à 13040 (cette valeur est identique à celle du SP1 d’Exchange 2010).

Déploiement du service pack 2 sur l’ensemble des serveurs

Une fois l’annuaire préparé et les modifications propagées sur l’ensemble des contrôleurs de domaine il est conseillé de mettre à jour les serveurs Exchange 2010 dans l’ordre suivant :

• Serveurs CAS
• Serveurs HUB
• Serveurs Mailbox
• Serveurs UM

Remarque : les serveurs Edge étant situés en workgroup ils peuvent être patchés en parallèle.

Si la haute disponibilité est déployée sur l’environnement il faudra bien sur déployer le package successivement sur chaque nœud en pensant bien à isoler le nœud en train d’être patché (mode “drain” sur les serveurs CAS et/ou HUB en load balancing matériel ou NLB, mode maintenance sur un nœud appartenant à un DAG).

Le déploiement du patch sur un serveur nécessite que les outils d’administration Exchange 2010 (console MMC et Powershell) soient fermés. De plus les services tiers accédant aux services Exchange (agent de sauvegarde, agent antivirus dédié à Exchange…) doivent également être arrêtés.

Si certains services ou outils bloquent le déploiement du Service Pack alors une fenêtre équivalent à celle-ci s’affichera à l’issue de test des prérequis.

Attention, pas retour d’expérience, le service pack 2 peut mettre jusqu’à 1h, voir 1h30 pour se déployer sur certaines configurations.

Parmi les nouveautés de Windows Server 2008 R2 et au niveau du composant Active Directory on trouve les comptes de services gérés (Managed Service Accounts).

Plusieurs applications SQL Server et IIS reposent sur des services qui doivent parfois être démarrés avec des comptes de domaines pour des besoins spécifiques. L’administration de ces comptes, de leurs mots de passe ainsi que des SPN peut s’avérer complexe et peut affecter la disponibilité de l’application.

L’utilisation des comptes de services gérés réduit la charge administrative quant à la gestion des mots de passe et des SPN (nom principal de service) tout en assurant la disponibilité de ces applications et réduisant les risques lié à la modification des mots de passe.

Pré-requis

Pour pouvoir utiliser les comptes de services gérés :

- Les ordinateurs hébergeant les applications à configurer doivent être équipés de Windows Server 2008 R2 ou Windows 7,

- Les domaines dont le niveau fonctionnel est Windows Server 2008 R2 supportent nativement la gestion automatique des mots de passe et des SPN,  

- Si le domaine n’est pas au niveau fonctionnel Windows Server 2008 R2 mais que le schéma Active Directory a été mis à jour au niveau Windows Server 2008 R2 les comptes de services gérés peuvent être utilisés, la gestion automatique des mots de passes de ces comptes sera possible mais pas la gestion automatique des SPN

- Pour utiliser les comptes de services gérés dans des domaines Windows Server 2008, Windows Server 2003 ou des domaines mixtes il faut tout d’abord procéder aux actions suivantes :

           1- Exécuter adprep /forestprep au niveau de la forêt AD

           2- Exécuter adprep /domainprep dans chaque domaine où on souhaite utiliser le comptes de services gérés

           3- Avoir un contrôleur de domaine Windows Server 2008 R2 ou Windows Server 2008 avec Active Directory Management Gateway Service ou Windows Server 2003 avec Active Directory Gateway Service, Active Directory Management Gateway Service permet l’utilisation des commandes PowerShell nécessaires à la gestion des comptes de services gérés

- Pour utiliser les commandes PowerShell nécessaires à l’administration des comptes de services gérés au niveau des ordinateurs clients sur lesquels les applications doivent être configurées on doit avoir installé le Framework .NETainsi que le module Active Directory pour Windows PowerShell

Installation des pré-requis sur Windows Server 2008 R2

1. Démarrer la console Server Manager

1. Sélectionner Features puis cliquer sur Add Features   

1. Sélectionner  .NET Framework 3.5.1 Features

1. Sélectionner  Active Directory module for Windows PowerShell sous Remote Server Administration Tools |  Role Administraion Tools | AD DS and AD LDS Tools

1. Cliquer sur Next

1. Cliquer sur Install

1. Redémarrer le serveur si nécessaire

Installation des pré-requis sur Windows 7

1. Télécharger Remote Server Administration Tools for WIndows 7
2. Installer la mise à jour
3. Ajouter les fonctionnalités .NET Framework 3.5.1 et le module Active Directory module for Windows PowerShell
4. Redémarrer l’ordinateur

Création et configuration d’un compte de service géré

• Ouvrir une invite PowerShell  Active Directory

• Créer le compte de services en exécutant la commande suivante :

New-AdServiceAccount <Nom Du Compte>  -AccountPassword (ConvertTo-SecureString –AsPlainText “<mot de passe>” –Force) –Enabled $true –Path “CN=Managed Service Accounts,DC=<Domain Name>,DC=COM”

• Associer le compte de service à l’ordinateur client en exécutant la commande suivante :

Add-ADComputerServiceAccount –Identity <Nom Ordinateur> –ServiceAccount <Nom du compte>

• Installer le compte de service sur l’ordinateur client (cette commande soit être exécutée sur le poste qui utilisera le compte de service géré)

Install-ADServiceAccount –Identity <Nom du compte>

• Vérifier que le compte de service à été bien affecté au compte de la machine au niveau Active Directory en explorant les propriétés de l’objet ordinateur en question avec ADSI Edit et en cherchant l’attribut msDS-HostServiceAccount   

Utilisation du compte de service

Nous allons maintenant utiliser un compte de service géré pour démarrer le services SQL Server Reporting Services au niveau d’un serveur Windows Server 2008 R2.

• Double cliquer sur le service SQL Server Reporting Services au niveau de la console Services 

• Au niveau de l’onglet Log On cocher This account et cliquer sur Browse afin de localiser le compte de service, ou taper le nom du compte au format <Nom du Domaine>\<Nom du compte>$ , laisser le mot de passe vide et cliquer sur Apply puis sur Ok     

Attention : si vous tapez le nom du compte à la main il faut ajouter un $ à la fin. 

  
• Démarrer ou redémarrer le service

• Vérifier que le service a bien démarré malgré la fait que le mot de passe n’a pas été saisi !

Pour plus de détails, vous pouvez consulter les articles suivants :

• Service Accounts Step-by-Step Guide
• Managed Service Accounts

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)