 TechNet Magazine December 2007

TechNet Magazine December 2007

Communications: 16 nouvelles fonctionnalités d’Exchange Server 2007 Service Pack 1

Contrairement au service pack normal, Exchange Server 2007 Service Pack 1 offre beaucoup plus que de simples correctifs et mises à jour de sécurité. Voici un aperçu des fonctionnalités et capacités les plus importantes proposées par SP1.

Tony Smith Communications: Réplication continue de secours (SCR) dans Exchange Server 2007 Service Pack 1

La réplication continue de secours est l'une des fonctionnalités les plus intéressantes offertes par Service Pack 1. Découvrez comment cette fonctionnalité peut vous aider à améliorer la durée active, réduire les pertes de données et simplifier la maintenance et la rétention de messages électroniques.

Scott Schnoll Communications: Exécution d'Exchange avec Windows Server 2008

Vous vous préparez à exécuter Exchange sur Windows Server 2008 ? L'équipe de développement de Microsoft Exchange y travaille depuis quelque temps déjà et Paul Bowden va vous faire part de différents conseils et diverses leçons qui vous permettront de vous préparer.

Paul Bowden Communications: Déploiement de messagerie unifiée avec Exchange Server 2007

L'intégration de la messagerie vocale, des fonctionnalités de télécopie et de la messagerie électronique dans une boîte aux lettres unique peut sembler fastidieuse. En réalité, c'est plus simple que vous le pensez. Voici un guide de déploiement de la messagerie unifiée dans votre organisation.

Jeff Goodwin Sécurité: Guide d'investigation informatique de base

Familiarisez-vous avec des approches de l'inforensique simples et peu coûteuses pouvant être utilisées par les administrateurs pour les investigations de base.

Tom Cloward and Frank Simorjay Mise en réseau: Rapport de sécurité Microsoft

Microsoft réunit une grande quantité de données sur les menaces de sécurité auxquelles font face les utilisateurs d'ordinateurs. Découvrez un aperçu des tendances récentes, des performances des diverses versions de Windows, des régions du monde les plus concernées, et bien plus encore.

Tim Rains Mise en réseau: Dépistage des problèmes réseau insaisissables

L'un de vos ordinateurs décide tout à coup de ne plus communiquer avec le reste du réseau sans raison apparente. Les conseils suivants permettent de diagnostiquer et résoudre rapidement le problème.

Christopher Stoneff Note de l'éditeur: Que la conversation commence !

Joshua Hoffman Lettres: Les lecteurs ont la parole

Boîte à outils: Nouveaux produits pour les professionnels de l’informatique

Greg Steen Forum aux questions sur SQL&: Configuration de la mémoire, profilage des performances, définition du facteur de remplissage, et bien plus encore

Edited by Nancy Michell Coup de projecteur sur les utilitaires: Outil Microsoft Security Assessment Tool

Cet utilitaire gratuit et ce questionnaire électronique permettent aux organisations de taille moyenne d'identifier et d'éliminer les risques de sécurité liés au réseau.

Lance Whitney Le petit câbleur: Serveur NPS

Le service NPS (Network Policy Server) de Windows Server 2008 remplace le service IAS (Internet Authentication Service) utilisé dans Windows Server 2003 et propose de nombreuses améliorations allant de la possibilité d'appliquer les conditions nécessaires à l'intégrité d'un système, à de meilleures fonctionnalités de gestion

Joseph Davies Windows PowerShell: Approfondissez vos connaissances

Windows PowerShell offre de nombreuses fonctionnalités qui sont souvent négligées. En adoptant une approche méthodique de l'exploration des applets de commande de Windows PowerShell, vous découvrirez des fonctionnalités puissantes dont vous n'aviez même pas deviné l'existence.

Don Jones Hé, vous le scripteur !: WinRM, le retour

Le majordome est-il le meurtrier ? Était-ce dans l'office avec le chandelier ? Aucune de ces questions ne recevra de réponse ici. Mais après quatre longues semaines, les scripteurs sont de retour avec la 2e partie de leur série en deux épisodes sur WinRM.

The Microsoft Scripting Guys Vigilance sécurité: Stratégies de mots de passe de domaine de Windows

Jusqu'à présent, Windows n'autorisait qu'une seule stratégie de mot de passe par domaine. Windows Server 2008, cependant, permet aux administrateurs d'implémenter plusieurs stratégies de mot de passe, pour adapter des stratégies différentes à divers types d'utilisateurs.

Derek Melber Histoires de Bureau: Déploiement de Windows dans un monde virtuel

La virtualisation vous tente ? Si ce n'est pas le cas, il est encore temps de changer d'avis. Découvrez toutes les informations indispensables pour déployer des systèmes virtuels et les coulisses de la virtualisation.

Wes Miller Sur le terrain: Le futur fongible

L'informatique s'est « consumérisée » à mesure que la technologie et les perceptions de la vie personnelle ont fusionné avec la technologie et les perceptions de la vie professionnelle. Et les effets sur les entreprises et la vie personnelle sont très importants.

Romi Mahajan La vie secrète de Windows: Un joystick n'a pas besoin d'être un micro-ondes

Un regard sur la manière dont l'interface du joystick à retour de force DirectInput spécifie des forces périodiques, et quelques résultats imprévus.

Raymond Chen


 Communications: 16 nouvelles fonctionnalit&#233;s d’Exchange&#160;Server&#160;2007 Service Pack&#160;1
Communications Tony Smith

16 nouvelles fonctionnalités d’Exchange Server 2007 Service Pack 1
Vue d'ensemble:
  • Nouvelles fonctionnalités d'administration
  • Rôles de serveur améliorés
  • Messagerie unifiée améliorée

La plupart des administrateurs connaissent le processus de téléchargement et d'application des Services Packs pour serveurs et bureaux. Bien entendu, ces téléchargements proposent des correctifs et mises à jour de sécurité qui
contribuent à garder vos systèmes à jour. Parfois, cependant, un Service Pack peut inclure quelque chose d'autre. C'est le cas de la prochaine version de Microsoft® Exchange Server 2007 Service Pack 1 qui renferme de nouvelles fonctionnalités, aussi nombreuses qu'intéressantes.
Ce téléchargement, qui sera disponible sur go.microsoft.com/fwlink/?LinkId=91472, peut être utilisé à la fois pour exécuter une installation complète d'Exchange Server 2007 (avec toutes les mises à jour SP1 en place) et mettre à jour des installations existantes d'Exchange Server 2007. Bien qu'il puisse être installé sur Windows Server® 2003 SP1, SP2 et R2, Exchange Server 2007 SP1 est compatible avec la prochaine version de Windows Server 2008.
Le Service Pack 1 introduit de nombreuses fonctionnalités et améliorations qu'il m'est impossible de couvrir dans leur totalité dans ce bref aperçu. J'ai donc choisi de compiler une liste descriptive des changements les plus remarquables que vous pouvez utiliser pour améliorer votre environnement Exchange. Pour un examen détaillé de tous les changements, consultez le document « Nouveautés d'Exchange Server 2007 SP1 » sur technet.microsoft.com/bb676323.aspx.

Modifications apportées à la console de gestion Exchange
Le Service Pack 1 confère à la console de gestion Exchange, illustrée à la figure 1, des fonctionnalités nouvelles et pratiques. Pour commencer, la Boîte à outils, qui propose une collection d'outils de diagnostic, dépannage et récupération installés par défaut avec Exchange Server 2007, inclut désormais la Console de gestion des dossiers publics, un Éditeur de modèles de détails et l'Afficheur de journalisation de routage.
Figure 1 Console de gestion Exchange avec Service Pack 1
Figure 1 Console de gestion Exchange avec Service Pack 1
Vous pouvez utiliser la console de gestion Exchange, la Console de gestion des dossiers publics, l'Éditeur de modèles de détails et l'Afficheur des files d'attente pour exporter des listes du volet des résultats et du volet de travail. Les listes peuvent être exportées sous forme de texte séparé par une tabulation, texte séparé par une virgule, texte Unicode séparé par une tabulation et texte Unicode séparé par une virgule. Vous pouvez non seulement filtrer le volet des résultats dans la console de gestion Exchange, mais aussi les volets des résultats dans la console de gestion des dossiers publics, l'Éditeur de modèles de détails et l'Afficheur des files d'attente.
La console de gestion Exchange inclut plusieurs nouvelles interfaces de gestion (telles que la console de gestion des dossiers publics que j'ai mentionnée). J'aborderai ces fonctionnalités séparément dans cet article.

Prise en charge pour IPv6
La prise en charge pour Windows Server 2008 est accompagnée de la prise en charge pour Internet Protocol version 6 (IPv6). Bien sûr, elle exige qu'Exchange Server 2007 soit installé sur Windows Server 2008 avec les piles de protocole IPv6 et IPv4 activées. Si vous désactivez IPv4 avant l'installation, Exchange ne prendra pas en charge IPv6.
Vous pouvez entrer des adresses et plages IP au format IPv4 ou IPv6. Les rôles de serveur peuvent tous envoyer et recevoir des données provenant de périphériques, serveurs et clients utilisant des adresses IPV6, à l'exception du rôle de serveur de messagerie unifiée. Ceci est dû au fait que le rôle de la messagerie unifiée nécessite IPv4 en raison des restrictions liées à certains composants de téléphonie et de voix.

Interface utilisateur administrative POP3 et IMAP4
La console de gestion Exchange inclut une nouvelle interface utilisateur administrative pour la gestion de POP3 et IMAP4. Vous pouvez y configurer tous les paramètres de POP3 et IMAP4 pour votre serveur d'accès client, y compris les paramètres des ports, les paramètres d'authentification et les paramètres de connexion. La figure 2 affiche la boîte de dialogue de configuration des propriétés d'IMAP4 ; les mêmes options sont disponibles pour POP3.
Figure 2 Console de gestion Exchange pour POP3/IMAP4
Figure 2 Console de gestion Exchange pour POP3/IMAP4

Une gestion des boîtes aux lettres plus robuste
Les fonctionnalités de gestion des boîtes aux lettres dans la console de gestion Exchange prennent désormais en charge la création de boîtes aux lettres de type Bulk pour les comptes utilisateur existants. Entre temps, de nouveaux Assistants permettent aux administrateurs d'accorder ou supprimer des droits d'accès complets à une boîte aux lettres et vous permet de configurer des autorisations de type « Envoyer en tant que » pour une boîte aux lettres.

Nouvelles fonctionnalités pour la gestion de données de boîte aux lettres
Un administrateur peut désormais importer et exporter des fichiers .pst pour gérer les données des boîtes aux lettres. Vous pouvez également effectuer cette opération dans Exchange Management Shell à l'aide des cmdlets Import-Mailbox et Export-Mailbox, respectivement.
La gestion des enregistrements de messagerie (MRM) peut être appliquée aux dossiers par défaut gérés qui résident sur un serveur Exchange doté d'une licence d'accès client standard d'Exchange. (Notez que la gestion MRM des dossiers personnalisés gérés nécessite toujours une licence d’accès client Exchange Enterprise. Le nouveau paramètre RemoveManagedFolderAndPolicy, destiné à la cmdlet Set-Mailbox, supprime toute stratégie MRM d'une boîte aux lettres, supprime les propriétés MRM de tout dossier géré ayant été créé dans le cadre de la stratégie MRM qui a été appliquée à la boîte aux lettres et convertit tout dossier géré en dossier standard.
Les nouveaux compteurs de l’Analyseur de performances vous permettent de contrôler diverses informations sur la défragmentation en ligne, notamment la date d'exécution de la dernière défragmentation en ligne, sa durée et les tâches qu'elle a effectuées. Ces informations vous permettent d'optimiser votre intervalle de défragmentation en ligne.

Confirmation des effacements à distance
Exchange Server 2007 permet déjà à un administrateur ou à utilisateur d'émettre une commande d'effacement à distance pour effacer toutes les données utilisateur d'un périphérique mobile, ce qui représente une fonctionnalité de sécurité très pratique en cas de perte ou vol d'un périphérique. Avec le Service Pack 1, un message de confirmation est envoyé lorsque le périphérique reconnaît la commande d'effacement à distance. Si l'utilisateur émet la requête (par le biais d'Outlook® Web Access ou OWA), il recevra un message de confirmation. Si l'administrateur émet la requête (par le biais de la console de gestion Exchange), l'administrateur et l'utilisateur recevront tous deux un message de confirmation.

Un client OWA plus robuste
Le client de messagerie électronique Web propose de nombreuses améliorations qui garantissent une meilleure messagerie aux employés mobiles. Grâce à SP1, les utilisateurs d'OWA peuvent créer et modifier des listes de distribution personnelles ainsi que les règles côté serveur. En outre, les utilisateurs peuvent utiliser les fonctionnalités Corbeille et Récupérer les éléments supprimés.
Des commandes de déplacement et copie ont été ajoutées à l'interface utilisateur, ce qui permet aux utilisateurs de déplacer et copier des dossiers à l'aide du menu contextuel de la liste de dossiers. Les éléments individuels des dossiers de messages et des dossiers publics peuvent être également déplacés et copiés en cliquant avec le bouton droit de la souris dans la liste d'éléments ou en cliquant sur une icône de la barre d'outils.
Les utilisateurs d'OWA disposent également d'un accès complet aux dossiers publics sans avoir à utiliser le répertoire virtuel /public (et vous n'avez pas besoin d'un serveur principal Exchange 2003 pour cela). Et les capacités de recherche dans les dossiers publics sont prises en charge dans OWA.
Les capacités S/MIME permettent désormais aux utilisateurs de lire et composer des messages signés et chiffrés (voir figure 3). Il existe même une prise en charge CNG (cryptographie nouvelle génération) et une conformité Suite-B. L'interface utilisateur d'OWA peut, quant à elle, être personnalisée de sorte à intégrer en toute transparence des applications personnalisées.
Figure 3 Paramètres de messages S/MIME
Figure 3 Paramètres de messages S/MIME

Contrôle de la composition dans OWA Light
Outlook Web Access Light, version moins complexe d'OWA conçue pour fonctionner avec pratiquement tous les navigateurs Web, contrôle désormais l'activité pendant qu'un utilisateur compose une longue entrée de n'importe quel type (entrée de message ou de calendrier, par exemple) pour s'assurer que la session n'expire pas (causant une perte de données) pendant que l'utilisateur est en train de taper. De plus, les messages sont automatiquement enregistrés dans le dossier Brouillons si la session expire pour cause d'inactivité pendant que le formulaire de composition de message est ouvert.

Performances Direct Push améliorées
Direct Push fonctionne en établissant une connexion HTTPS entre un périphérique mobile et le serveur Exchange 2007. Avec Exchange 2007 SP1, la taille des en-têtes de requête et réponse HTTPS a été réduite, ce qui réduit la quantité de données envoyée et reçue par un périphérique mobile.

Gestion de dossiers publics
La nouvelle console de gestion des dossiers publics, illustrée à la figure 4, permet aux administrateurs de créer, configurer et maintenir des dossiers publics dans la console de gestion Exchange. Les listes d'adresses, les stratégies d'adresses de messagerie, les groupes de distribution dynamiques et les listes de distribution fonctionnent avec les dossiers publics. Lorsque vous prévisualisez des listes d'adresses, des stratégies d'adresses de messagerie, des groupes de distribution dynamiques et des destinataires de groupes de distribution, vous pouvez voir les dossiers publics inclus dans les critères d'appartenance au groupe.
Figure 4 Console de gestion des dossiers publics
Figure 4 Console de gestion des dossiers publics
La console de gestion des dossiers publics d'Exchange 2007 SP1 vous permet de configurer les droits administratifs des dossiers publics. Pour ce faire, vous pouvez utiliser soit la cmdlet Add-ExchangeAdministrator ou l'Assistant Ajouter un administrateur Exchange pour ajouter un utilisateur au rôle d'Administrateur des dossiers publics soit la cmdlet Add-PublicFolderAdministratorPermission pour accorder ou refuser des droits spécifiques aux dossiers publics.

Traitement et routage de messages amélioré
Déployés dans la forêt Active Directory®, les serveurs de transport Hub gèrent tous les flux de messages au sein de l'organisation, appliquent les règles de transport, appliquent les règles de journal et livrent les messages aux boîtes aux lettres des destinataires. Les messages envoyés à Internet sont transmis par le serveur de transport Hub au serveur de transport Edge sur le périmètre réseau. SP1 inclut des améliorations à ces rôles de serveur.
Exchange Server 2007 inclut une fonctionnalité de contrôle de ressources système appelée Back Pressure (contre-pression) et permettant aux serveurs de transport Hub et Edge de réagir face à une forte utilisation des ressources. Avec SP1, la quantité d'espace disque requise a été considérablement réduite (de 4 Go à 500 Mo).
La console de gestion Exchange de SP1 offre d'autres paramètres de configuration de transport. Et vous pouvez désormais configurer un espace d'adressage X.400 comme domaine faisant autorité (les adresses longues X.400 sont aussi prises en charge).
Le serveur de transport Hub prend en charge la mise en attente prioritaire. La priorité attribuée à un message par un utilisateur Outlook est traitée par le catégoriseur qui veille à ce que les messages envoyés avec une haute priorité reçoivent en fait un traitement de priorité et soient livrés plus rapidement que les messages non prioritaires.
Dans Exchange 2007 SP1, l'étendue d'un connecteur d'envoi Send à un simple site Active Directory est simplifiée par l'addition du paramètre IsScopedConnector dans les cmdlets Exchange Management Shell et la case du connecteur Scoped Send dans la Console de gestion Exchange. Lorsqu'un connecteur Send est défini, seuls les serveurs de transport Hub se trouvant dans le même site Active Directory que les serveurs sources du connecteur Send considèrent ce dernier dans les décisions de routage.

Amélioration de la synchronisation du serveur de transport Edge
Dans Exchange Server 2007 SP1, vous pouvez utiliser la cmdlet Start-EdgeSynchronization immédiatement pour commencer la synchronisation de données d'Active Directory au service Active Directory Application Mode (ADAM). Dans Exchange 2007 SP1, cette cmdlet prend en charge le paramètre Serveur, ce qui vous permet d'exécuter la cmdlet sur un ordinateur distant.
La cmdlet Test-EdgeSynchronization, cmdlet de diagnostic qui signale l'état de synchronisation des serveurs de transport Edge, est doté d'un nouveau paramètre qui vous permet de vérifier les résultats de synchronisation des utilisateurs individuels.

Clonage de l'objet TransportConfig
Les scripts de configuration clonée permettent aux administrateurs d'appliquer plus facilement une configuration cohérente lorsque plusieurs serveurs de transport Edge sont déployés dans leur environnement. Dans SP1, l'objet TransportConfig, qui contrôle les paramètres à l’échelle du serveur du rôle serveur de transport Edge, est désormais inclus dans les informations sur la configuration clonée. L'inclusion de cet objet simplifie considérablement les procédures de déploiement, sauvegarde et restauration de serveurs.

Amélioration de la messagerie unifiée
La messagerie unifiée représentait un composant très intéressant de la version initiale d'Exchange Server 2007. Le Service Pack 1 développe cette fonctionnalité en introduisant de nombreuses fonctions et améliorations. Certaines de ces fonctionnalités exigent qu'Office Communications Server 2007 soit déployé dans la même forêt Active Directory, mais plusieurs autres ne nécessitent pas Office Communications Server. Je ne couvrirai pas toutes les modifications apportées à la messagerie unifiée dans cet article, mais je jetterai un coup d'œil rapide sur les plus importantes. Si vous voulez en savoir plus sur la messagerie unifiée, consultez le document « Déploiement de messagerie unifiée avec Exchange Server 2007 » dans ce numéro de TechNet Magazine.
Je me pencherai tout d'abord sur certaines des fonctionnalités qui nécessitent Office Communications Server 2007. Il existe désormais une prise en charge des flux multimédia qui traversent les pare-feux et des messages vocaux haute fidélité. Une notification de transfert est envoyée lorsque le destinataire laisse un message vocal à l'aide de la fonction de transfert d'appel. Les utilisateurs peuvent accéder à Outlook Voice Access depuis Office Communicator 2007 sans entrer de PIN. Les messages électroniques de notification d'appels en absence et de notification de messagerie vocale sont intégrés à Office Communicator 2007 (voir figure 5). Et bien plus encore.
Figure 5 Notification de messagerie vocale dans Office Communicator
Figure 5 Notification de messagerie vocale dans Office Communicator
L'une des améliorations apportées à la messagerie unifiée qui ne nécessite pas Office Communications Server est la prise en charge du protocole SRTP (Secure Realtime Transport Protocol). La version initiale d'Exchange Server 2007 propose deux modes de sécurité : non sécurisé et sécurisé. Le mode sécurisé ne chiffre que le trafic du protocole SIP (Session Initiation Protocol) et le trafic RTP est non chiffré. Dans SP1, il existe trois modes : non sécurisé, sécurisé SIP et sécurisé. En mode sécurisé SIP, seul le trafic SIP est chiffré (le trafic RTP n'est pas chiffré). En mode sécurisé, le trafic SIP et le trafic RTP sont tous deux chiffrés. Vous pouvez également configurer la sécurité MTLS (Mutual Transport Layer Security) pour les plans de numérotation à l'aide de la console de gestion Exchange.
Les autres modifications incluent le nouvel Assistant Activer la messagerie unifiée que vous pouvez utiliser pour ajouter un SIP ou une adresse E.164 à un utilisateur, la configuration du type d'URI pour un plan de numérotation à l'aide de la console de gestion Exchange et la prise en charge de la Qualité de Service (QoS) par le biais de DiffServ utilisé pour le balisage du trafic multimédia.

Meilleure disponibilité
Le Service Pack 1 introduit de nouvelles fonctionnalités qui amélioreront la haute disponibilité de même que des améliorations des fonctionnalités de haute disponibilité existantes. Les nouvelles fonctionnalités étendent les scénarios dans lesquels vous pouvez atteindre une haute disponibilité des données et services pour vos rôles de serveur Exchange 2007. Les nouveaux scénarios permettent aux organisations de séparer les scénarios de haute disponibilité des scénarios de résilience de site et de déployer des configurations adaptées aux besoins spécifiques de l'organisation dans chaque zone séparée.
Pour commencer, la prise en charge accrue de Windows Server 2008 permet d'obtenir des clusters de basculement de plusieurs sous-réseaux et de prendre en charge les nouveaux modèles de quorum (témoin de partage de disques et fichiers). D'autres améliorations ont été apportées aux capacités de rapport et surveillance de clusters, et des fonctionnalités supplémentaires contribuent à renforcer la surveillance des environnements de réplication continue. Les améliorations liées aux performances incluent, quant à elles, une réduction d'E/S sur les disques qui contiennent des copies passives de groupes de stockage, un processus de copie de fichier journal plus rapide et un déplacement plus rapide des serveurs de boîtes aux lettres en cluster entre les nœuds.
Enfin, de nouveaux Assistants servant à améliorer les processus de gestion et configuration (voir figure 6) et de nouveaux contrôles d'interface utilisateur pour la gestion des serveurs de boîtes aux lettres en cluster ont été ajoutés, dont un nouvel onglet Serveur de boîtes aux lettres en cluster et une page de configuration CCR (réplication continue en cluster).
Figure 6 Assistant Gérer le serveur de boîtes aux lettres en cluster
Figure 6 Assistant Gérer le serveur de boîtes aux lettres en cluster

Réplication continue SCR (Standby Continuous Replication)
La réplication continue SCR (Standby Continuous Replication) utilise la même technologie d'envoi asynchrone et de relecture des journaux que celle utilisée par LCR (Réplication continue locale) et CCR (Réplication continue en cluster) pour offrir des options et configurations de déploiement supplémentaires. SCR est identique à LCR et CCR, mais il possède des caractéristiques uniques. Pour en savoir plus sur SCR, consultez l'article « Réplication continue SCR dans Exchange Server 2007 » de Scott Schnoll dans ce numéro de TechNet Magazine.

Conclusion
Exchange Server 2007 Service Pack 1 est donc plus que de simples mises à jour et correctifs de sécurité. Il introduit de nombreuses fonctionnalités et améliorations que vous pourrez bientôt utiliser. Je n'ai pas suffisamment d'espace pour couvrir toutes ces nouvelles fonctionnalités et améliorations, mais j'espère que cet article vous a donné une bonne idée de ce à quoi vous pouvez vous attendre. Pour plus d'informations sur les changements inclus dans le Service Pack 1 et sur les téléchargements, webcasts et forums de discussion, rendez-vous sur le TechCenter Exchange Server à l'adresse technet.microsoft.com/exchange.

Tony Smith est rédacteur technique principal pour l'équipe Exchange User Education et est spécialisé dans la messagerie unifiée. Avant de travailler pour Microsoft, Tony était ingénieur réseau, sous-traitant pour Microsoft et formateur certifié Microsoft. Il a également mené à bien plusieurs projets de rédaction technique pour Microsoft Learning, et a notamment écrit des livres et manuels de laboratoire.
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 Communications: R&#233;plication continue de secours (SCR) dans Exchange&#160;Server&#160;2007 Service Pack&#160;1
Communications Scott Schnoll

Réplication continue de secours (SCR) dans Exchange Server 2007 Service Pack 1
Vue d'ensemble:
  • Configuration de la réplication continue de secours
  • Importance de la redondance
  • Réduction des interruptions de service par SCR

Service Pack 1 contient de nouvelles fonctionnalités et améliorations pour Exchange 2007. Une de ces nouvelles fonctionnalités, la réplication continue de secours (SCR), est conçue pour offrir aux organisations la redondance intégrée au centre de données et la résilience de site. Comme son nom l'indique, la SCR est conçue
pour des scénarios qui utilisent ou permettent l'utilisation de serveurs de récupération de secours.
Si vous connaissez la version RTM (release to manufacturing) d'Exchange 2007, vous savez qu'elle offre la redondance intégrée au centre de données via ses fonctionnalités d'envoi de journaux et sa prise en charge des clusters de basculement Windows®. Dans la version RTM, la copie des journaux de transactions (connu officiellement sous le nom de réplication continue) est disponible sous deux formes : la réplication locale continue (LCR), comme illustré à la Figure 1 et la réplication continue en cluster (CCR), comme illustré à la Figure 2.
Figure 1 Réplication locale continue
Figure 1 Réplication locale continue
Figure 2 La CCR envoie les journaux vers un deuxième serveur dans un cluster de basculement Windows
Figure 2 La CCR envoie les journaux vers un deuxième serveur dans un cluster de basculement Windows
La réplication continue assure la disponibilité et la redondance des données en permettant aux administrateurs de mettre en service et de maintenir en ligne une deuxième copie de chaque base de données de boîtes aux lettres. Cette copie de la base de données représente une première ligne de défense contre les défaillances, les pertes ou la corruption d'une base de données de production. Au lieu de perdre votre temps à essayer de rechercher une bande de sauvegarde pour restaurer les données, une copie de la base de données peut être activée et transformée en base de données de production en quelques minutes.
SCR étend les scénarios dans lesquels vous pouvez obtenir une disponibilité des services et des données optimale pour votre organisation. Les nouveaux scénarios vous permettent de séparer les topologies haute disponibilité des topologies de résilience de site et vous permettent également de déployer des configurations adaptées aux besoins spécifiques de votre organisation pour chaque zone.
La version RTM d'Exchange 2007 offre la redondance intégrée au centre de données et la résilience de site, mais dans la mesure où la LCR et la CCR ne fournissent qu'une copie supplémentaire de chaque base de données, vous devez choisir entre la résilience et la redondance. Par exemple, considérons les fonctionnalités de disponibilité des services et des données offertes par la CCR. Le déploiement des nœuds actifs et passifs dans un centre de données unique fournit des services intégrés dans le centre de données et la disponibilité des données mais pas la résilience de site (puisque les deux nœuds se trouvent dans le même site physique). Le déploiement du nœud actif dans un centre de données et le nœud passif dans un deuxième centre de données vous offre la résilience de site, mais pas la disponibilité intégrée au centre de données (puisque le nœud passif, qui offre ces fonctionnalités, se trouve dans un deuxième centre de données).
Avec la SCR de Service Pack 1, la possibilité de créer des copies supplémentaires de chaque base de données signifie que la haute disponibilité et la résilience de site ne s'excluent pas mutuellement ; vous pouvez obtenir les deux. Vous pouvez par exemple associer la SCR à la CCR pour répliquer des groupes de stockage localement dans un centre de données principal (en utilisant la CCR pour la haute disponibilité) et à distance dans un centre de données secondaire ou de sauvegarde (en utilisant la SCR pour la résilience de site), comme illustré à la figure 3. Le deuxième centre de données contient un cluster autonome qui peut être activé et rapidement doté d'un serveur de boîtes aux lettres en cluster de remplacement dans un scénario de récupération de site.
Figure 3 CCR déployée dans le centre de données Redmond et SCR déployée dans le centre de données Quincy
Figure 3 CCR déployée dans le centre de données Redmond et SCR déployée dans le centre de données Quincy
La figure 3 illustre un déploiement d'entreprise avec deux centres de données, chacun avec son propre site Active Directory® : Redmond et Quincy. Le site Redmond se trouve dans le centre de données principal (production) et le site Quincy se trouve dans le centre de données secondaire (sauvegarde). La CCR est déployée à Redmond pour obtenir la redondance intégrée au centre de données. Avec les éléments d'infrastructure nécessaires pour Exchange 2007, les cibles SCR sont configurées sur un cluster autonome à Quincy pour obtenir la résilience de site. Ces éléments d'infrastructure supplémentaires, incluant les serveurs d'accès au client et de transport Hub, Active Directory et les serveurs DNS ainsi que l'accès à Internet, peuvent être des ressources dédiées ou non. Les ressources dédiées sont les ressources destinées à prendre en charge uniquement les utilisateurs du centre de données dans lequel elles résident. Les ressources non dédiées sont celles qui prennent en charge les utilisateurs du centre de données local ainsi que les utilisateurs d'autres emplacements. Vous devez décider si les ressources seront dédiées ou non, en fonction de ce qui est le plus avantageux pour votre organisation. Pour plus d'informations sur les ressources dédiées et non dédiées, consultez la rubrique « Site Resilience Configurations » du fichier d'aide d'Exchange Server 2007 à l'adresse technet.microsoft.com/bb201662.aspx. Notez également l'utilisation d'un nouveau type de quorum de jeu de nœud majoritaire. Dans Exchange Server 2007, la CCR utilise le quorum de jeu de nœud majoritaire avec témoin de partage de fichiers au lieu du nœud d'inscription traditionnel, comme vous pouvez le voir à la figure 3.
A la figure 4, un environnement CCR et SCR conçu avec la résilience à l'esprit offre plusieurs couches de redondance pour les boîtes aux lettres et les services hébergés sur le serveur EXCLUS1, protégeant ainsi les boîtes aux lettres contre les défaillances, petites, grandes voire irrémédiables.
Figure 4 Serveurs de boîtes aux lettres autonomes utilisant la SCR pour répliquer des groupes de stockage les uns sur les autres
Figure 4 Serveurs de boîtes aux lettres autonomes utilisant la SCR pour répliquer des groupes de stockage les uns sur les autres
Les petites et moyennes entreprises peuvent également tirer parti de la SCR. Une organisation peut par exemple déployer deux serveurs de boîtes aux lettres autonomes (EXMBX1 et EXMBX2) et utiliser la SCR pour répliquer certains ou tous les groupes de stockage d'un serveur de boîtes aux lettres vers un autre, comme illustré à la figure 4.
Dans cet exemple, EXMBX1 et EXMBX2 sont des serveurs de production avec cinq groupes de stockage actifs. Chaque groupe de stockage est une source SCR avec une cible SCR correspondante sur l'autre serveur. En cas de défaillance de stockage, lorsqu'un groupe de stockage actif configuré en tant qu'une source SCR est indisponible, la copie cible SCR peut être rapidement activée à l'aide de quelques tâches administratives dans Exchange Management Shell. Avec Microsoft® Office Outlook ® 2007, la portabilité de la base de données et les fonctionnalités Autodiscover d'Exchange 2007, le temps d'interruption de service en cas de perte de groupe de stockage actif (ou, de perte de plusieurs groupes de stockage actifs) pourrait se compter en minutes.

Sources et cibles SCR
Comme la LCR et la CCR, la SCR utilise également le concept de copies actives et passives d'un groupe de stockage, mais elles sont respectivement appelées sources et cibles SCR. Cependant, les sources et cibles SCR sont des copies de groupe de stockage. (Les groupes de stockage de récupération ne peuvent pas être activés pour la SCR).
Le point de départ pour la SCR (la source SCR) est tout groupe de stockage sur un serveur de boîtes aux lettres autonome ou sur un serveur de boîtes aux lettres en cluster dans un environnement CCR ou de cluster à copie unique. Veuillez noter que si la source SCR peut être un serveur de boîtes aux lettres en cluster, la SCR elle-même n'est pas une solution en cluster et ne nécessite pas le service de cluster de Windows. Le point de terminaison la pour SCR (la cible SCR) peut être soit un serveur de boîtes aux lettres autonome soit un nœud dans un cluster de basculement où le rôle de boîte aux lettres est installé mais où aucun serveur de boîtes aux lettres mis en cluster n'a été configuré dans le cluster.

Relations source et cible
Chaque groupe de stockage de source SCR peut avoir un nombre illimité de cibles SCR. Par exemple, une source peut avoir une cible qui réside dans le même centre de données que la source et une deuxième cible dans un centre de données distinct. Cependant, Microsoft recommande de ne pas utiliser plus de quatre cibles par source. Si vous décidez d'utiliser plus de quatre cibles, vous devez évaluer l'impact probable sur le serveur source SCR en termes de mémoire, de processeur et des ressources disque, et planifier en conséquence. Chaque ordinateur cible SCR peut avoir plusieurs serveurs source. Les ordinateurs source et cible doivent exécuter Service Pack 1 pour Exchange 2007. Le système d'exploitation doit être un système d'exploitation pris en charge par Service Pack 1 pour Exchange 2007 (par exemple, Windows Server® 2008 ou Windows Server 2003 SP2). Cependant, quel que soit le système d'exploitation utilisé, la SCR ne prend pas en charge plusieurs systèmes d'exploitation. Le système d'exploitation sur la source SCR doit correspondre au système d'exploitation sur toutes les cibles SCR pour cette source. Ainsi, si la source SCR exécute Windows Server 2003, toutes les cibles SCR pour cette source doivent également exécuter Windows Server 2003.
La SCR est disponible dans l'édition Standard d'Exchange 2007. Si un serveur de boîtes aux lettres en cluster d'un environnement SCC ou CCR est utilisé en tant que source SCR, l'édition Enterprise d'Exchange 2007 est nécessaire. Chaque cible SCR prend en charge au maximum 50 instances (50 groupes de stockage répliqués) lorsqu'elle utilise Exchange 2007 Enterprise Edition et au maximum 5 instances lorsqu'elle utilise Exchange 2007 Standard Edition.
Les cibles SCR doivent également satisfaire certaines exigences. Tout d'abord, les ordinateurs source et cible doivent se trouver sur le même domaine Active Directory, bien qu'ils puissent être dans les mêmes sites Active Directory ou dans des sites Active Directory différents. De plus, les chemins d'accès au fichier journal et au fichier de la base de données sur la source et toutes ses cibles doivent correspondre à chaque groupe de stockage répliqué avec la SCR. Enfin, lorsqu'un nœud ou un serveur est configuré en tant que cible SCR, vous ne pouvez pas mettre la LCR en service pour le groupe de stockage sur l'ordinateur cible SCR. Vous ne pouvez pas non plus ajouter de serveur de boîtes aux lettres en cluster au cluster de basculement de secours.

Comparaison de la SCR avec la CCR et la LCR
La SCR (comme illustré à la figure 5) utilise la même technologie de relecture et de copie des journaux de transactions que celle utilisée par la LCR et la CCR pour offrir de nouvelles options et configurations de déploiement. Comme avec la LCR et la CCR, les groupes de stockage mis en service pour la SCR ne peuvent pas contenir plus d'une base de données. De même, la SCR ne peut pas être utilisée pour une base de données de dossiers publics s'il existe plus d'une base de données de dossiers publics dans l'organisation Exchange.
Figure 5 La SCR copie les journaux de transactions sur un autre serveur ou sur un nœud passif d'un cluster de basculement
Figure 5 La SCR copie les journaux de transactions sur un autre serveur ou sur un nœud passif d'un cluster de basculement
L'un des différences clés avec la SCR réside dans le fait qu'elle prend en charge plusieurs cibles par groupe de stockage, tandis que la LCR et la CCR ne prennent en charge qu'une seule cible (la copie passive). Autre différence clé : contrairement à une copie CCR ou LCR, vous ne pouvez pas sauvegarder une copie SCR. Lorsque vous utilisez la SCR, les en-têtes de base de données pour les cibles SCR sont mis à jour et les fichiers journaux sont tronqués lorsque les sauvegardes prises en charge sont effectuées sur le groupe de stockage source SCR (ou, dans le cas de la CCR et de la LCR, lorsque les sauvegardes sont effectuées sur les copies actives ou passives du groupe de stockage source SCR).
Comme avec la LCR et la CCR, la copie des journaux de transaction avec la SCR est continue et utilise un modèle d'extraction. Dès qu'un nouveau fichier journal est fermé et est nommé avec le numéro de fichier journal de séquence nouvelle génération, le Service de réplication Microsoft Exchange s'exécutant sur l'ordinateur cible SCR extrait les fichiers journaux de transactions fermés de l'ordinateur source SCR, les inspecte et les valide, puis les transfère vers leur dossier de fichiers journaux de groupes de stockage correspondants sur l'ordinateur cible SCR.

Délai d'attente de relecture
Une fois les fichiers journaux copiés sur l'ordinateur cible SCR, la SCR exécute une opération que la LCR et la CCR n'effectuent pas. Au lieu de relire immédiatement les fichiers journaux dans la copie de la base de données, la SCR applique un délai de relecture prédéfini de 50 fichiers journaux et 24 heures. La SCR vous permet également de spécifier un délai supplémentaire au delà de ces délais prédéfinis. Le délai de relecture est utile dans de nombreux scénarios. Par exemple, en cas de corruption logique d'une base de données active, un délai peut prévenir la corruption logique de la base de données cible SCR.
Le délai de relecture contrôlé par l'administrateur est défini à l'aide d'un paramètre appelé ReplayLagTime, qui dicte la durée d'attente du service de réplication d'Exchange avant la relecture des fichiers journaux copiés sur l'ordinateur cible SCR. Le format est Jours.Heures:Minutes:Secondes et la valeur par défaut est 24 heures. Le paramètre admissible maximum pour cette valeur est sept jours. Le paramètre admissible minimum est zéro seconde. La définition de cette valeur sur zéro seconde supprime tout délai dans l'activité de relecture du journal au-delà du délai par défaut de 50 fichiers journaux.
Outre le paramètre ReplayLagTime, Exchange dispose d'un délai prédéfini et codé en dur de 50 fichiers journaux, quelle que soit la valeur du paramètre ReplayLagTime. Pour déterminer le moment où un fichier journal doit être relu, Exchange utilise le paramètre ReplayLagTime le plus important ou x fichiers journaux, où x = 50. Il s'agit d'une garantie supplémentaire contre la nécessité de réamorçage d'un groupe de stockage dans les situations où une source SCR qui utilise la réplication continue (par exemple, un serveur de boîtes aux lettres en cluster dans un environnement CCR) rencontre un basculement et où un ou plusieurs groupes de stockage doi(ven)t être mis en ligne à l'aide de l'applet de commande Restore-StorageGroupCopy. (Le réamorçage est le processus permettant d'utiliser les API de sauvegarde en continu ESE (Extensible Storage Engine) pour mettre en ligne une copie de la base de données source SCR sur l'ordinateur cible SCR). En retardant l'activité de relecture sur les cibles SCR, lorsqu'un basculement avec perte se produit pour une source SCR, la nécessité de réamorcer les copies SCR sera limitée vu que la nature de la perte de données sur la source SCR rapproche les deux copies dans le temps.

Délai de troncation
Dans la version RTM d'Exchange 2007, les règles sont appliquées dans un environnement de réplication continue. Par conséquent, un fichier journal n'est pas supprimé à moins qu'il ait été sauvegardé et relu dans la copie de la base de données. Lorsque vous utilisez la SCR, cette règle est modifiée. La SCR (qui introduit le concept de copies de base de données multiples) permet aux fichiers journaux d'être tronqués sur l'ordinateur source SCR dès qu'ils sont inspectés par tous les ordinateurs cibles SCR. La troncation de journaux au niveau du serveur source SCR n'attend pas la relecture de tous les journaux dans les cibles SCR du fait que les copies cibles SCR peuvent être configurées avec des délais de relecture importants pour les journaux.
Vous pouvez également ajouter un délai supplémentaire à la troncation de journaux à l'aide d'un nouveau paramètre appelé TruncationLagTime, qui spécifie la durée d'attente du service de réplication d'Exchange (au format Jours.Heures:Minutes:Secondes) avant la troncation des fichiers journaux copiés sur l'ordinateur cible SCR et relus dans la copie de la base de données. La période commence dès que les fichiers journaux ont été relus avec succès dans la copie de la base de données. Le paramètre admissible maximum pour cette valeur est sept jours, tandis que le paramètre minimum est zéro seconde, bien que zéro seconde élimine en fait tout délai dans l'activité de troncation des journaux.
Dans un environnement SCR, un thread d'arrière-plan s'exécute toutes les trois minutes pour déterminer si un fichier journal doit être tronqué. Si la séquence de génération de fichier journal n'a pas atteint le point de vérification du fichier journal pour le groupe de stockage et que le fichier journal est plus ancien que les paramètres ReplayLagTime + TruncationLagTime, un fichier journal de la cible SCR sera tronqué.
Dans un environnement LCR ou CCR étendu avec SCR, un fichier journal de la cible SCR sera tronqué si les quatre critères suivants sont satisfaits : le fichier journal a été sauvegardé, la séquence de génération du fichier journal n'a pas atteint le point de vérification du fichier journal pour le groupe de stockage, la copie passive du groupe de stockage est dans un état permettant la troncation du fichier journal et toutes les cibles SCR ont inspecté le fichier journal.

Mise en service et gestion de la SCR
La SCR est mise en service à l'aide de l'applet de commande Enable-StorageGroupCopy dans Exchange Management Shell, mis à jour dans SP1 avec certains nouveaux paramètres. Comme décrit ci-dessus, les paramètres ReplayLagTime et TruncationLagTime vous permettent de contrôler une partie du comportement des cibles SCR. Un autre paramètre, SeedingPostponed, peut être utilisé pour ignorer l'amorçage initial de la cible SCR. Dans certaines situations, il peut être utile de différer l'amorçage. Par exemple, disons que la base de données du groupe de stockage qui est mise en service pour la SCR fait 100 Go. Vous ne souhaiterez peut-être pas que 100 Go de données traversent le réseau pendant les heures de production maximale. Le paramètre SeedingPostponed vous permet de mettre immédiatement la SCR en service et d'exécuter une tâche d'amorçage ultérieurement. Lorsque vous êtes prêt, vous pouvez amorcer manuellement la cible SCR à l'aide de l'applet de commande Update-StorageGroupCopy.
Bien que les paramètres mentionnés ci-dessus soient facultatifs, un paramètre d'Enable-StorageGroupCopy est nécessaire pour la SCR : StandbyMachine. Il spécifie le nom de l'ordinateur qui contiendra la cible SCR. La valeur de ce paramètre est définie dans le cadre de la valeur pour l'attribut msExchStandbyCopyMachines du stockage mise en service pour la SCR. L'attribut msExchStandbyCopyMachines est une chaîne unicode de plusieurs valeurs ajoutée au schéma Active Directory lorsqu'Exchange 2007 SP1 est introduit dans l'organisation Exchange, ce qui est une des raisons pour lesquelles SP1 nécessite une mise à jour du schéma pour Active Directory.
Le paramètre StandbyMachine est central à la SCR. Plusieurs applets de commande ont été mises à jour dans SP1 pour utiliser ce paramètre pour la mise en service et la gestion des cibles SCR. Les applets de commande mises à jour sont décrites à la figure 6.
Figure 6 Applet de commande qui utilise le paramètre StandbyMachine (Close Figure 6)

Cmdlet | Description
Disable-StorageGroupCopy | Met hors service une cible SCR pour un groupe de stockage.
Get-StorageGroupCopyStatus | Détermine l'intégrité actuelle de la cible SCR.
New-StorageGroup | Crée un nouveau groupe de stockage mis en service pour la SCR sans devoir mettre la SCR en service séparément à l'aide de l'applet de commande Enable-StorageGroupCopy.
Restore-StorageGroupCopy | Met la SCR hors service et rend la base de données cible SCR viable pour le montage avec une opération Mount-Database dans le cadre d'une procédure de récupération.
Resume-StorageGroupCopy | Utilisé pour reprendre la réplication continue pour un groupe de stockage pour lequel la SCR est suspendue.
Suspend-StorageGroupCopy | Interrompt l'activité de réplication continue pour un groupe de stockage mis en service pour la SCR.
Update-StorageGroupCopy | Utilisé pour amorcer ou réamorcer un groupe de stockage cible SCR.

Activation des cibles SCR
La SCR offre une ou plusieurs copies à jour des données, qui peuvent être utilisées si les données d'origine sont perdues ou deviennent inutilisables. Le processus consistant à prendre une copie cible SCR et à effectuer un redéploiement en tant que base de données de production est connu sous le nom d'activation. L'activation survient dans le cadre d'un processus de récupération, qui prendra la forme d'une portabilité de la base de données ou d'une des deux options de récupération d'installation (/m:RecoverServer pour récupérer un serveur autonome ou /RecoverCMS pour récupérer un serveur de boîtes aux lettres en cluster).

Comment utiliser la SCR
Voyons comment une entreprise fictive pourrait utiliser la SCR et la portabilité de la base de données pour récupérer d'une défaillance de base de données de boîtes aux lettres. Lorsque la base de données de production s'avère endommagée, l'administrateur active la base de données SCR à l'aide de la portabilité de la base de données.
L'organisation a déployé Exchange 2007 avec SP1 et a décidé d'utiliser la SCR pour fournir une copie d'un groupe de stockage sur un serveur de boîtes aux lettres distant. Les serveurs de boîtes aux lettres cible et source se trouvent dans le même site Active Directory et sont configurés pour utiliser les serveurs DNS intégrés à Active Directory. L'intervalle de réplication Active Directory est défini sur 15 minutes.

Mise en service de la SCR et préparation de la récupération
La SCR est configurée pour que les fichiers journaux des transactions soient répliqués pour un groupe de stockage unique, SG1, qui contient une base de données unique, MBX1. Les chemins pour les fichiers de groupe de stockage et le fichier de base de données sont C:\SG1 et C:\SG1\MBX1.EDB. Dans le cas présent, EXMBX1 est la source SCR et EXMBX2 la cible SCR. Voici la configuration que vous obtenez :
Enable-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
Après la mise en service de la SCR, l'intégrité et l'état de la SCR pour SG1 ont été vérifiés à l'aide de l'applet de commande Get-StorageGroupCopyStatus :
Get-StorageGroupCopyStatus EXMBX1\SG1
-StandbyMachine EXMBX2
Pour gagner du temps lors du processus d'activation de la cible SCR, EXMBX2 est préconfiguré avec un groupe de stockage, SG1PORT et une base de données, MBX1PORT, qui seront utilisés dans le cadre des opérations de portabilité de la base de données. SG1PORT et MBX1PORT sont séparés du groupe de stockage et des fichiers de base de données de la cible SCR. Par conséquent, les chemins pour SG1PORT et MBX1PORT sont configurés avec un chemin temporaire qui n'entre pas en conflit avec les chemins de la cible SCR. SG1PORT et MBX1PORT seront uniquement utilisés comme objets de portabilité de la base de données. Les fichiers de groupe de stockage et de base de données réels pour SG1PORT ne sont pas nécessaires. De ce fait, l'administrateur démonte MBX1PORT et supprime tous les fichiers du groupe de stockage. Les objets de la base de donnés et du groupe de stockage restent dans Active Directory parce qu'ils seront utilisés ultérieurement pour la portabilité de la base de données lors du processus de récupération.

Activation et récupération
Une entrée du journal des événements d'applications indique que la base de données de la source SCR est physiquement endommagée. Comme la SCR a été mise en service pour SG1, vous devez effectuer une activation manuelle de la base de données de la cible SCR pour SG1 et utiliser la portabilité de la base de données pour restaurer la disponibilité des données. L'activation de la copie cible SCR commence par le démontage de MBX1 dans SG1 à l'aide de l'applet de commande suivante :
Dismount-Database EXMBX1\SG1\MBX1
La base de données cible SCR est ensuite rendue viable pour le montage et les boîtes aux lettres initialement présentes sur MBX1 sont rapatriées vers MBX1PORT.
Le processus consistant à mettre la SCR hors service et à rendre la base de données cible SCR viable pour le montage implique l'exécution de l'applet de commande Restore-StorageGroupCopy. Cette tâche marque la base de données du groupe de stockage comme montable et fournit un rapport sur la perte de données, le cas échéant, entraînée par le montage de la base de données dans le groupe de stockage. Elle vérifie également la présence de tous les fichiers journaux produits par la copie active du groupe de stockage dans l'emplacement du fichier de groupe de stockage de la copie passive. Si un fichier journal est absent, l'opération tentera également de le copier. L'applet de commande suivante est utilisée pour rendre la base de données cible SCR viable pour le montage :
Restore-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
Dans cet exemple, les fichiers journaux du groupe de stockage source SCR sont disponibles pour la copie. Si ces fichiers ne sont pas disponibles (par exemple, parce que l'ordinateur source SCR est en panne), le paramètre Force doit être ajouté à la tâche Restore-StorageGroupCopy. Sinon, Restore-StorageGroupCopy tentera toujours de se connecter à la source SCR pour copier tout fichier journal manquant et si la source SCR n'est pas disponible, la tâche Restore-StorageGroupCopy échouera et la base de données ne sera pas rendue viable pour le montage. L'ajout du paramètre Force indique à la tâche Restore-StorageGroupCopy que les fichiers sources ne sont pas disponibles. Dans ce cas, elle ignore la tentative de connexion et rend la base de données cible SCR viable pour le montage.
Une fois la commande Restore-StorageGroupCopy exécutée, l'administrateur doit vérifier que la base de données est dans un état d'arrêt correct. Si la base de données est dans un état d'arrêt incorrect (voir technet.microsoft.com/aa996757.aspx), elle doit être arrêtée correctement. Si le préfixe du fichier journal pour le groupe de stockage (par exemple, E00 ou E01) est le même pour la source SCR (EXMBX1\SG1) et le groupe de stockage sur la cible SCR (SG1PORT) qui sera utilisé pour la portabilité de la base de données (EXMBX2\SG1PORT), il n'est pas nécessaire d'exécuter Eseutil en mode de récupération. L'opération de montage de la base de données finale amènera la base de données à un état d'arrêt correct après la relecture de tous les fichiers journaux copiés. Si la base de données est dans un état d'arrêt incorrect, le mode de récupération (Eseutil /r) des utilitaires de la base de données d'Exchange Server (Eseutil) doit être exécuté sur la base de données.
Une fois la base de données arrêtée correctement, vous pouvez exécuter deux commandes qui mettent à jour Active Directory avec les nouveaux emplacements pour les fichiers de groupes de stockage et le fichier de base de données. Ces commandes modifient les chemins pour SG1PORT et MBX1 de leurs chemins originaux aux chemins pour le groupe et la base de données de stockage montés (SG1 PORT et MBX1PORT) :
Move-StorageGroupPath EXMBX2\SG1PORT
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT
-EdbFilePath C:\SG1\MBX1PORT.EDB
–ConfigurationOnly
Le paramètre –ConfigurationOnly doit être inclus dans les commandes mentionnées ci-dessus pour que seuls les paramètres de configuration pour ces objets soient mis à jour dans Active Directory. Aucune donnée ni aucun fichier n'est déplacé(e) ou ne doit être déplacé(e) parce que la SCR a déjà copié les données vers C:\SG1 sur EXMBX2.
L'étape suivante consiste à configurer la base de données (MBX1PORT) pour l'autoriser à être écrasée lors d'une opération de restauration. Cette opération peut être effectuée en sélectionnant la case à cocher pour le paramètre « Cette base de données peut être écrasée par une restauration » dans les propriétés d'objet de base de données de la console de gestion Exchange ou à l'aide de la commande suivante dans Exchange Management Shell :
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT
-AllowFileRestore:$true
Après avoir configuré la base de données pour qu'elle s'autorise à être écrasée, l'étape suivante consiste à monter la base de données à l'aide de la commande suivante :
Mount-Database EXMBX2\SG1PORT\MBX1PORT
Après le montage de la base de données, les boîtes aux lettres hébergées sur la base de données source SCR (SG1\MBX1) doivent être rapatriées pour pointer vers MBX1PORT sur EXMBX2. Il vous suffit d'exécuter l'applet de commande Get-Mailbox et de diriger les résultats vers l'applet de commande Move-Mailbox. Pendant ce processus, il est important que la Surveillance du système Exchange et les boîtes aux lettres système ne soient pas incluses dans les résultats de l'applet de commande Get-Mailbox qui est redirigé vers l'applet de commande Move-Mailbox. Ces objets de boîtes aux lettres n'ont pas besoin d'être rapatriés et ne doivent pas l'être. La commande suivante est exécutée pour rapatrier toutes les boîtes aux lettres des utilisateurs et exclure les boîtes aux lettres système :
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|
ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly
-TargetDatabase EXMBX2\SG1PORT\MBX1PORT
À ce stade, l'accès client à MBX1PORT est désormais possible. Cependant, le fait que les utilisateurs puissent effectivement accéder à leurs boîtes aux lettres après qu'elles aient été déplacées de XMBX1\SG1\MBX1 vers EXMBX2\SG1PORT\MBX1PORT dépend de la latence de réplication d'Active Directory. En fonction du nombre de serveurs d'annuaire, la mise à jour peut prendre un certain temps pour se propager dans l'environnement. De plus, les méthodes d'accès au client sont importantes. Les clients de messagerie exécutant Outlook 2007 et les clients n'utilisant pas Outlook auront accès à la boîte aux lettres de l'utilisateur une fois les serveurs d'annuaire utilisés par le serveur d'accès au client de l'utilisateur mis à jour avec les nouveaux chemins. Les clients de messagerie exécutant Outlook 2003 et les versions précédentes nécessiteront la mise à jour du profil de messagerie de l'ordinateur de l'utilisateur avec le nouveau nom du serveur.

Etapes finales
Une fois que les clients peuvent accéder à leurs boîtes aux lettres et à leurs données de boîtes aux lettres, l'étape finale consiste à établir la redondance en remettant la SCR en service. Il faut pour cela supprimer tous les groupes de stockage et tous les fichiers de base de données restants d'EXMBX1. Une fois les fichiers supprimés, les chemins pour EXMBX1\SG1\MBX1 peuvent être transférés à un emplacement temporaire et EXMBX1 peut devenir une cible SCR d'EXMBX2.

Scott Schnoll est rédacteur technique principal au sein de l'équipe Exchange Server chez Microsoft, et responsable du contenu pour Exchange Server 2007. Avant de rejoindre Microsoft, Scott a écrit Exchange Server 2003 Distilled (Addison-Wesley Professional, 2004) et était le principal auteur d'Exchange 2000 Server: The Complete Reference (McGraw-Hill/OsborneMedia, 2001).


 Communications: Ex&#233;cution d'Exchange avec Windows&#160;Server&#160;2008
Communications Paul Bowden

Exécution d'Exchange avec Windows Server 2008
Vue d'ensemble:
  • Configuration de Windows Server 2008
  • Conseils et astuces de configuration.
  • Découvrez votre environnement Exchange

Au sein de l'équipe de développement d'Exchange de Microsoft, mon rôle est de définir l'emploi du temps, le rythme et les priorités. Chez Microsoft, ma fonction officielle est responsable de la publication. Ce poste correspond au titre de responsable de projet technique dans les autres entreprises. Comme toute personne qui a travaillé
à ce poste le sait, pour livrer un bon produit à temps les connaissances, les compétences, le travail et le respect de l'équipe sont indispensables. Lorsque vous devez travailler avec une équipe très compétente et talentueuse, la crédibilité ne s'acquiert pas du jour au lendemain, elle doit être méritée.
L'une des façons de faire ses preuves consiste à exécuter sa boîte aux lettres sur un serveur de « Dogfood », un serveur de production exécutant une version préliminaire d'Exchange. Il s'agit d'un environnement fluide sur lequel nous mettons le système à niveau vers les nouvelles versions d'Exchange toutes les deux ou trois semaines. Ce type d'installation nous permet de tester le logiciel dans un environnement réel avec une véritable interaction humaine. Nous exécutons même nos boîtes aux lettres sur les versions de test les plus récentes. J'ai fait cette expérience et je vais vous la raconter.

Préparation à la mise en place de « Longhorn »
À la fin de 2006, alors que nous venions de publier Exchange Server 2007, un nouveau système d'exploitation pointait à l'horizon : Windows Server® sous le nom de code « Longhorn ». Alors que nous commencions à élaborer nos plans pour le premier Service Pack de la nouvelle plate-forme d'Exchange, il est devenu évident que les calendriers d'Exchange et Windows® étaient sur plus ou moins sur la même voie et que « Longhorn » (maintenant appelé Windows Server 2008) serait phénoménal. Nous avons alors décidé de concevoir Exchange Server 2007 SP1 pour Windows Server 2003 et Windows Server 2008. La prise en charge d'une application d'entreprise sur plusieurs versions de Windows implique un gros effort de coordination et de planification. Par exemple, Exchange fonctionne en étroite collaboration avec IIS et Windows Server 2008 inclut une nouvelle version, IIS 7.0.
Je me rappelle ma première installation de Windows Server 2008 dans mon laboratoire, fin décembre 2006. Deux choses en particulier sont restées gravées dans mon l'esprit : la première est la rapidité d'installation et la deuxième, que les outils de gestion, bien que très différents par rapport à Windows Server 2003, étaient très intuitifs.
Dans nos principaux laboratoires, l'installation de Windows Server 2008 prend environ le tiers du temps nécessaire pour Windows Server 2003. L'une des principales raisons de cette performance réside dans le fait que de nombreux composants sont désormais facultatifs et ne sont pas configurés de façon standard. C'est une avancée considérable, dans la mesure où ceci réduit la surface d'attaque de l'ordinateur et la complexité. Personne n'aime être encombré par des modules superflus. L'inconvénient type de ce type d'installation est que vous devez insérer le disque chaque fois que vous souhaitez ajouter des composants supplémentaires. Mais avec Windows Server 2008, tous les fichiers sont copiés dans un dossier SxS (côte à côte). La configuration des composants requis s'effectue ensuite à l'aide de l'outil Gestionnaire de serveur. Le système d'exploitation détermine alors les fichiers à copier sans intervention de votre part.
À ce stade, il est important de mentionner le terme « Server Core ». Il s'agit d'un mode de Windows Server 2008 qui permet d'installer le strict minimum du système d'exploitation. Dans ce mode, vous interagissez généralement avec la console du serveur par l'intermédiaire de la ligne de commande. L'Explorateur Windows n'est même pas installé. Ce mode convient parfaitement aux serveurs d'infrastructure, tels que les contrôleurs de domaine et les serveurs DNS. Cependant, vous ne pouvez pas exécuter n'importe quel type d'application dans ce mode. Exchange utilise le code géré de façon intensive, ce qui l'empêche de prendre en charge les installations Server Core.

Configuration d'Exchange
J'adore prendre les supports Windows Server 2008 et Exchange Server 2007 SP1 et les l'installer à partir de zéro sur un nouvel ordinateur, sans téléchargement supplémentaire ou condition préalable à satisfaire. La meilleure façon de configurer une installation Windows Server 2008 pour Exchange est d'utiliser l'outil ServerManagerCmd. J'ai créé un fichier de réponse XML, illustré à la figure 1, qui installe le nombre strictement nécessaire de composants du système d'exploitation pour permettre à Exchange de s'installer et s'exécuter sur Windows Server 2008. Une fois le nouveau système d'exploitation installé, j'exécute la commande suivante pour arrêter le système :
Figure 1 Fichier de réponse ServerManagerCmd pour Exchange (Close Figure 1)
<!-- ServerManagerCmd Answer File compatible with Windows Server 2008        -->
<!-- Usage: ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration
    Action="Install"
    xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: Install PowerShell 1.0 feature -->
    <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA: Install LDIFDE and other directory tools like LDP and ADSIEdit -->
    <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Install the Web Server role with additional child components -->
    <Role Id="Web-Server"/>
    <RoleService Id="Web-Metabase"/>
    <RoleService Id="Web-Lgcy-Mgmt-Console"/>
    <RoleService Id="Web-Basic-Auth"/>
    <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: Install the three authentication types for OWA, GZip compression, plus Outlook Anywhere support -->
    <RoleService Id="Web-ISAPI-Ext"/>
    <RoleService Id="Web-Digest-Auth"/>
    <RoleService Id="Web-Dyn-Compression"/>
    <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Install Active Directory Lightweight Directory Services (previously known as ADAM) -->
    <Role Id="ADLDS"/>

    <!-- UM: Install the Windows Media Player components -->
    <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
Lorsque cette opération est terminée et que le système a redémarré, vous disposez de tout ce dont vous avez besoin pour installer les rôles Exchange tels que Boîte aux lettres, Accès client, Transport Hub, Transport Edge et Messagerie unifiée.
Une autre astuce utile consiste à utiliser ServerManagerCmd avec l'option –query. Cette commande affiche la liste complète des rôles et des services, et indiquer ceux qui sont configurés (indiqués par le texte vert à la figure 2).
Figure 2 Énumération des rôles et des services d'Exchange
Figure 2 Énumération des rôles et des services d'Exchange
Mais revenons à notre sujet. Nous avons passé les premiers mois de 2007 en laboratoire pour identifier les modifications requises pour obtenir d'excellentes performances sous Windows Server 2008. S'il y a une chose à retenir, c'est que vous pouvez toujours installer et tester un logiciel en laboratoire, la vraie mesure de la qualité s'effectue dans les déploiements réels en situation, avec de véritables utilisateurs. Et c'est exactement pourquoi nous testons nos produits au quotidien dans des conditions réelles où ils doivent être fonctionnels. La version bêta 3 de Windows Server 2008, en avril 2007, a marqué un tournant : il était temps de passer à la phase pratique et de passer au déploiement de production.
J'étais assis et je regardais au-dessus de l'épaule de l'un des membres de l'équipe pendant le déploiement du premier jeu de serveurs Exchange sous Windows Server 2008. L'installation d'Exchange s'est déroulée facilement et les services ont tous démarré. Tout ce qui nous restait à faire était de déplacer une boîte aux lettres et de voir si elle fonctionnait correctement. Je me suis porté volontaire. J'ai une boîte aux lettres de 2 Go et, 26 minutes plus tard, elle fonctionnait, envoyant des messages électroniques avec Exchange sous Windows Server 2008. Succès !

Principaux enseignements
Depuis cette première installation sous Windows Server 2008, nous avons affiné la configuration pour nous assurer que tout serait bien prêt pour le grand jour. Nous avons dû prendre un certain nombre de décisions clés en cours de route.
Installation Vous pouvez utiliser Exchange Server 2007 SP1 en tant que mise à niveau de la version d'origine d'Exchange Server 2007, ce que j'appelle Exchange 2007 RTM (release to manufacturing), ou vous pouvez prendre un nouvel ordinateur et installer directement Exchange Server 2007 SP1. Ceci est important dans la mesure où vous ne pouvez pas installer Exchange Server 2007 RTM sur un ordinateur qui exécute Windows Server 2008.
Mises à niveau Vous pouvez effectuer une mise à niveau de remplacement du système d'exploitation de Windows Server 2003 SP2 vers Windows Server 2008, cependant un certain nombre de composants doivent être désinstallés au préalable. C'est notamment le cas de Windows PowerShell™. Celui-ci est au cœur même de la gestion d'Exchange ; l'installation d'Exchange elle-même repose sur Windows PowerShell. Pour cette raison, nous ne pouvons pas prendre en charge les mises à niveau de remplacement du système d'exploitation lorsqu'Exchange est déjà installé. Pour de nombreuses personnes, cela signifie qu'il faudra installer Windows Server 2008 sur un nouvel ordinateur, puis installer Exchange Server 2007 SP1.
IPv6 Exchange est conçu pour tirer parti de plusieurs nouvelles fonctionnalités de Windows Server 2008. Par exemple, IPv6 est installé par défaut, et deux serveurs Exchange qui s'exécutent sur le nouveau système d'exploitation utiliseront automatiquement IPv6 pour communiquer entre eux. Les interfaces de la console de gestion d'Exchange acceptent également les plages d'adresses IPv6. Il existe toutefois une exception : Exchange nécessite une liaison des adresses IPv4 à chaque interface réseau.
Contrôleurs de domaine en lecture seule Une modification quelque peu radicale pour les déploiements Active Directory® réside dans la notion de contrôleur de domaine en lecture seule (ou serveur global de catalogue). Celui-ci permet aux entreprises de déployer un serveur Active Directory qui reçoit une réplication unilatérale et n'a pas la possibilité de répliquer les modifications. Cela peut être utile dans le cas des filiales ou des bureaux distants où la sécurité physique ne peut pas être garantie. Malheureusement, Exchange Server 2007 SP1 ne permet pas d'exploiter un contrôleur de domaine en lecture seule et nécessite un accès à une partition en écriture standard d'Active Directory.

Votre environnement Exchange
Exchange et ressources Windows Server
  • TechCenter Windows Server 2008
  • TechCenter Exchange Server
  • Centre d'évaluation TechNet
  • Laboratoires virtuels Windows Server 2008

Quand il s'agit de choisir le niveau du système d'exploitation pour votre déploiement, vous avez la possibilité d'exécuter différentes configurations, comme illustré à la figure 3.
Figure 3 Matrice d'environnement Exchange (Close Figure 3)

Version d'Exchange | Système d'exploitation du serveur | Contrôleur de domaine
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
Vous devrez également réfléchir aux déploiements de versions mixtes. Vous pouvez exploiter conjointement différentes versions d'Exchange et de Windows. Par exemple, vous pouvez déployer Exchange Server 2007 SP1 sur Windows Server 2008 sur les serveurs d’accès client et leur permettre d'accéder à Exchange Server 2007 RTM sur les serveurs de boîte aux lettres Windows Server 2003.
Vous devez tenir comptes de quelques nuances avec les versions plus anciennes d'Exchange et de Windows Server 2008 - Active Directory. Si vous disposez d'Exchange Server 2003 SP2 ou une version plus récente, vous pouvez déployer et utiliser les contrôleurs de domaine de Windows Server 2008 dans votre environnement. Cependant, si Exchange 2000 est toujours déployé, vous pourrez soit retarder le déploiement des contrôleurs de domaine Windows Server 2008 sur le site d'Active Directory où ces serveurs Exchange résident, soit coder les paramètres Directory Service Access (DSAccess) en dur de sorte qu'Exchange 2000 ne tente pas d'utiliser les contrôleurs de domaine Windows Server 2008.

Conclusion
Nous avons fait tout notre possible pour faire fonctionner correctement Exchange 2007 SP1 sur les plates-formes Windows Server 2003 et Windows Server 2008. Dans Exchange, nous nous efforçons d'offrir une plus grande souplesse de déploiement et des scénarios favorisant la collaboration. Je pense que vous serez agréablement surpris par la facilité et la rapidité à laquelle vous pouvez déployer Exchange sous Windows Server 2008. Vous découvrirez également des améliorations des performances et de l'évolutivité en coulisses, telles qu'une évolutivité nettement supérieure des serveurs d'accès client pour les clients d'Outlook Anywhere.
Windows Server 2008 offre une plate-forme capable de prendre en charge de futures innovations dans l'espace de messagerie. Vous ne serez pas déçu.

Paul Bowden est responsable de programme principal au sein de l'équipe Exchange Server. Il consacre le plus clair de son temps libre à reconfirmer ses informations de compte PayPal sur demande.


 Communications: D&#233;ploiement de messagerie unifi&#233;e avec Exchange&#160;Server&#160;2007
Communications Jeff Goodwin

Déploiement de messagerie unifiée avec Exchange Server 2007
Vue d'ensemble:
  • Principes fondamentaux de téléphonie
  • Considérations sur la conception d'une messagerie unifiée
  • Migration de vos utilisateurs

Vous avez donc décidé de déployer la messagerie unifiée d'Exchange Server 2007 dans votre environnement. Vous avez installé un rôle de serveur de messagerie unifiée, vous l'avez intégré à votre PBX existant, et maintenant vous et 10 autres employés avez des messages vocaux, électroniques et de télécopie enregistrés dans Exchange. Auparavant, vous
auriez pu considérer cela comme un succès majeur. Mais comment pensez-vous déployer ces mêmes fonctionnalités pour des milliers d'abonnés, répartis sur plusieurs sites, sans affecter l'activité de l'entreprise ?
J'espère que cet article vous aidera. Je l'ai écrit pour vous aider à comprendre le déploiement de la messagerie unifiée dans votre environnement et pour démystifier les concepts de téléphonie associés à un tel déploiement. Si vous avez besoin d'aide pour l'installation, la configuration ou les fonctionnalités de messagerie unifiée d'Exchange Server 2007, consultez l'encadré « Ressources relatives à la messagerie unifiée » à la fin de cet article. Microsoft a également identifié des entreprises comme Spécialistes de la messagerie unifiée pour aider ses clients en matière de conseil, de conception et de déploiement de la messagerie unifiée d'Exchange Server 2007. Si vous avez besoin d'aide pour l'installation, la configuration ou le déploiement, contactez l'un de ces spécialistes, également répertoriés dans cet encadré.

Mise en route
Les technologies de messagerie unifiée ne sont pas nouvelles dans Exchange ; de nombreuses organisations proposent des produits de messagerie unifiée qui s'intègrent à Exchange. Toutefois, Exchange Server 2007 est la première version d'Exchange qui prend en charge la messagerie unifiée en mode natif. Depuis son introduction, de nombreux clients ont déployé la messagerie unifiée d'Exchange Server 2007 à de petits groupes au sein de leur organisation. Cependant, pour diverses raisons, ils ne l'ont toujours pas déployée à l'ensemble de leurs utilisateurs. L'un des problèmes est que beaucoup d'administrateurs Exchange connaissent mal les concepts de téléphonie et les technologies nécessaires à l'implémentation des services de messagerie unifiée et éprouvent des difficultés à concevoir et déployer ces solutions dans leur entreprise.
Comme pour n'importe quel projet de déploiement, une approche par phases offre généralement les meilleurs résultats. Un projet de messagerie unifiée comporte cinq étapes (planification de l'architecture, test de la solution, pilote pour une communauté d'utilisateurs, formation et migration des utilisateurs vers le nouveau système) qui doivent toutes faire l'objet d'une égale attention. Il est essentiel d'associer les équipes informatique et de télécommunications de votre organisation lors de la planification du projet.
Bon nombre de fonctionnalités, que les utilisateurs considèrent comme acquises sur les plates-formes de messagerie vocale traditionnelles doivent être dupliquées ou, si cela n'est pas possible, une solution alternative doit être mise en place pour diminuer l'impact sur les communautés d'utilisateurs lors de l'implémentation d'un nouveau système. Il s'agit d'un aspect clé pour lequel votre équipe de télécommunications doit vous aider. Dans le même temps, l'équipe de télécommunications devra acquérir, avec l'aide de l'équipe informatique, les compétences nécessaires pour administrer, dépanner et assurer le support de la nouvelle plate-forme de messagerie vocale pendant le déploiement.

Principes fondamentaux de téléphonie
La planification sera beaucoup plus facile pour vous si vous connaissez bien l'architecture de base, le flux d'appels et les terminologies fondamentales liés à la messagerie unifiée. La figure 1 illustre un exemple une solution de messagerie unifiée intégrée dans un système de téléphonie d'entreprise existant. Examinons maintenant de plus près certains des concepts et technologies les plus courants que vous êtes susceptible de rencontrer dans le cadre d'un déploiement de ce type.
Figure 1 Solution de PBX à messagerie unifiée
Figure 1 Solution de PBX à messagerie unifiée
Un système PBX (Private Branch eXchange) est un réseau téléphonique privé utilisé dans une entreprise. Sur un système de ce type, chaque utilisateur dispose généralement un téléphone de bureau connecté au PBX, qui lui permet de passer des appels aux autres utilisateurs internes en composant une extension (généralement à quatre ou cinq chiffres) et aux téléphones externes.
Lorsque clients d'entreprise possèdent plusieurs sites équipés de PBX, elles décident parfois de connecter les systèmes ensemble par des technologies de mise en réseau spécifiques au fournisseur du PBX. Ceci permet à tous les utilisateurs des PBX en réseau de se contacter en composant juste une extension.
La messagerie unifiée implique l'intégration de deux systèmes différents : la messagerie Exchange et le système de téléphonie physique. Les communications entre le serveur de messagerie unifiée et l'architecture de téléphonie sont établies à l'aide du protocole SIP (Session Initiation Protocol). Certaines technologies PBX peuvent communiquer directement avec le serveur de messagerie unifiée par le biais du SIP ; d'autres nécessiteront une passerelle SIP. Dans la figure 1, le PBX est connecté à une passerelle SIP via une ligne T1. Lorsqu'un appel est transféré à la messagerie unifiée, le PBX envoie les informations (numéro de téléphone de l'appelant, numéro de téléphone de l'appelé et un certain type de code de raison) à la passerelle SIP pour que le serveur de messagerie unifiée comprenne à qui est destiné l'appel.
Certains PBX peuvent être mis en réseau par le biais du réseau IP. La mise en réseau de la téléphonie offre la possibilité de rediriger les appels vers une solution de messagerie vocale centralisée via le réseau IP. Par exemple, si vous examinez la figure 2, vous verrez que Zurich est à son tour connecté à Londres.
Figure 2 Déploiement de messagerie unifiée plus complexe
Figure 2 Déploiement de messagerie unifiée plus complexe

Flux d'appels
Ressources relatives à la messagerie unifiée
  • Répertoire de spécialistes de la messagerie unifiée
  • TechCenter Messagerie unifiée Exchange
  • Passerelles SIP prises en charge
  • Conseils en téléphonie
  • Notes de configuration du PBX

Supposons qu'un appel est passé au téléphone d'un abonné de messagerie unifiée par un appelant externe. Dans le cas présenté, l'abonné de messagerie unifiée n'est pas à son bureau et l'appel reste sans réponse. Vous pouvez suivre le chemin du message à la figure 1.
Le PBX envoie l'appel à la passerelle SIP, qui négocie l'appel avec le serveur de messagerie unifiée via SIP sur TCP. Le serveur reçoit les données d'intégration de la passerelle SIP qui lui indique pour qui était l'appel. Le serveur de messagerie unifiée diffuse ensuite le message d'accueil de l'abonné et autorise l'appelant externe à enregistrer un message. Ce message est ensuite remis à la boîte aux lettres Exchange de l'abonné Messagerie unifiée.
Ce flux d'appel est une description très simplifiée de ce qui se passe réellement. Il est important de comprendre que lorsqu'un message est enregistré, le serveur de messagerie unifiée le transfère au serveur de transport Hub à l'aide du protocole SMTP pour une remise au serveur de boîtes aux lettres.
Á l'instar des abonnés de messagerie unifiée, les utilisateurs ont maintenant accès à leur boîte aux lettres Exchange via téléphone (en utilisant Outlook® Voice Access) ou un ordinateur (en utilisant Outlook 2007 ou Outlook Web Access). Mais les abonnés peuvent également accéder à leurs messages par téléphone en utilisant Outlook 2007 ou Outlook Web Access grâce à une fonctionnalité appelée Émettre au téléphone, qui permet à l'abonné de messagerie unifiée de lire le message sélectionné en appelant un téléphone spécifié au lieu d'y accéder sur un ordinateur. Avec cette méthode, le serveur de messagerie unifiée interagit avec le serveur d'accès client et le serveur de boîtes aux lettres. Ceci est important à savoir parce que si vous placez un serveur de messagerie unifiée dans un bureau distant qui ne dispose pas de serveur d'accès client local, le serveur de messagerie unifiée devra parcourir le réseau WAN pour contacter le serveur d'accès client, ce qui peut affecter les performances.

Conception du système
Les clients se divisent en deux catégories correspondant aux deux conceptions architecturales de base d'Exchange : conception centralisée ou conception décentralisée. En règle générale, l'architecture de messagerie unifiée suivra votre architecture Exchange, ce qui signifie qu'un serveur de messagerie unifiée sera également déployé partout où vous déployez un serveur de boîtes aux lettres. Bien sûr, il y a des exceptions à toute règle.
Lors de la conception de votre architecture de messagerie unifiée, vous devez tenir compte de cinq aspects fondamentaux.
  • Emplacement du serveur
  • Nombre de serveurs de messagerie unifiée
  • Passerelle SIP
  • Stockage des boîtes aux lettres
  • Configuration de site de messagerie unifiée
Il convient par ailleurs de ne pas négliger la continuité de l'activité de l'entreprise. En règle générale, votre plan de récupération après incident relatif à Exchange peut être utilisé pour déterminer les éléments pertinents pour la messagerie unifiée.
Les exemples de scénarios de déploiement peuvent vous aider à comprendre les rôles de serveur de messagerie unifiée. La figure 2 illustre de manière claire un déploiement d'entreprise d'Exchange Server 2007 avec messagerie unifiée de grande ampleur.
Dans cette conception relativement complexe, les centres de données principaux sont Seattle et Londres. Les serveurs de messagerie unifiée sur ces sites desservent leurs communautés d'utilisateurs respectives puisque les serveurs de boîte aux lettres et de transport Hub sont locaux. Les deux sites sont équipés de PBX IP qui assurent la couverture des appels au serveur de messagerie unifiée local pour garantir la réponse aux appels.
Des sites de taille moyenne sont situés à New York et Glasgow. Les serveurs de messagerie unifiée sur ces sites desservent leurs communautés d'utilisateurs respectives puisque les serveurs de boîte aux lettres et de transport Hub sont locaux. Comme pour les centres de données, les deux sites sont équipés de PBX IP qui assurent la couverture des appels au serveur de messagerie unifiée local pour garantir la réponse aux appels.
Les sites plus petits ne disposent pas de serveurs de boîte aux lettres de transport Hub locaux mais offrent des fonctionnalités de messagerie unifiée à partir des centres de données principaux. Austin possède un PBX NEC qui utilise une connexion analogique à une passerelle SIP locale. Les appels aux utilisateurs finaux locaux sont transférés à la passerelle SIP, qui négocie avec le serveur de messagerie unifiée de Seattle pour répondre aux appels sur la messagerie unifiée.
Zurich possède un gestionnaire de communications Avaya connecté au gestionnaire de communications Avaya de Londres via le réseau IP. Les appels aux utilisateurs locaux sont transférés sur le réseau du gestionnaire de communications Avaya, qui négocie avec le serveur de messagerie unifiée de Londres pour répondre aux appels sur la messagerie unifiée.
Dans cet exemple, les serveurs de boîte aux lettres Exchange et les serveurs de messagerie unifiée du site de Seattle partagent un même emplacement physique. Dans le cas d'une architecture à site unique, tous les serveurs (boîte aux lettres, messagerie unifiée, accès client etc.) et l'équipement PBX sont situés sur le même site. La conception devient plus complexe avec les sociétés comptant plusieurs sites. Cette complexité peut sembler insurmontable, mais elle devient parfaitement gérable avec une bonne connaissance de certains principes de messagerie unifiés fondamentaux.
Comme l'illustre la figure 2, si un site contient un serveur de boîtes aux lettres, il est recommandé d'y placer également un serveur de messagerie unifiée. Seattle, Londres, New York et Glasgow entrent tous dans cette conception. Ni Austin ni Zurich ne possèdent de serveur de boîtes aux lettres localement, mais les services de messagerie unifiée peuvent néanmoins être fournis à ces sites à l'aide du réseau IP. Austin possède un PBX analogique local. Dans ce cas, une passerelle SIP doit être utilisée pour fournir la connectivité réseau IP au serveur de messagerie unifiée de Seattle. Zurich est équipé d'un PBX IP local connecté au PBX de Londres par le biais du réseau. Ainsi, les appels à un utilisateur à Zurich traversent le réseau de téléphonie pour revenir au PBX et au serveur de messagerie unifiée de Londres.
Puisque les appels passés aux abonnés de Zurich parcourent le réseau et sont contrôlés par un système de messagerie unifiée centralisé à Londres, si le réseau connaît une panne, les appels à tous les abonnés de Zurich resteront sans réponse jusqu'à ce que le réseau soit réparé. Si les services doivent être assurés même en cas de défaillance du réseau, il serait possible d'installer un serveur de messagerie unifiée à Zurich. En cas de panne du réseau, le serveur de messagerie unifiée continuera de répondre aux appels et les délivrera lorsque le réseau sera réparé.
L'emplacement du serveur est probablement le facteur le plus important à prendre en compte lors de la conception d'une architecture adaptée à votre environnement. L'organigramme présenté à la figure 3 doit vous aider à déterminer l'emplacement correct des serveurs.
Figure 3 Choix de l'emplacement des serveurs
Figure 3 Choix de l'emplacement des serveurs

Évaluation des besoins en termes de serveurs
Le point suivant à étudier est le nombre de serveurs de messagerie unifiée nécessaire pour prendre en charge votre communauté d'utilisateurs. La réponse dépend vraiment de plusieurs facteurs spécifiques aux sites.
L'évolutivité de la messagerie unifiée est déterminée par le nombre d'appels simultanés (appelés ports dans le monde de la téléphonie) que le serveur peut prendre en charge. Chaque appel traité par le système nécessite que le serveur de messagerie unifiée lui dédie des ressources réseau, processeur, mémoire et disque. Plus les ressources sont élevées, plus le nombre d'appels simultanés pouvant être pris en charge par le serveur de messagerie unifiée est élevé. Puisque ces ressources sont toujours limitées, le serveur de messagerie unifiée peut seulement contrôler un certain nombre d'appels simultanés avant que les ressources ne soient épuisées.
Vous pouvez déterminer le nombre de ports nécessaire pour prendre en charge le nombre d'abonnés grâce aux modèles d'analyse de trafic d'Erlang, que je ne détaillerai pas ici. Une méthode plus facile pour déterminer le nombre de ports nécessaire consiste simplement à demander à votre administrateur de téléphonie combien de ports de messagerie vocale sont utilisés sur le système de messagerie vocale existant. D'après mon expérience, les besoins en ports sur un système de messagerie vocale traditionnel et un système de messagerie vocale unifiée devraient être très similaires.
Je recommande généralement de ne pas implémenter plus de 60 ports sur un seul serveur. Ceci n'a rien à voir avec d'éventuelles restrictions logicielles ou matérielles. La raison en est plutôt qu'un serveur unique avec 60 ports peut prendre en charge approximativement 5 000 utilisateurs. Si ce serveur unique connaît une panne, l'ensemble de votre (très vaste) base d'abonnés sera affectée.
Lors de l'implémentation des serveurs de messagerie unifiée, vous voudrez peut-être envisager de concevoir une redondance N+1 dans l'architecture. La figure 4 illustre une conception de serveur et de passerelle SIP entièrement redondante. Grâce à cette conception, si le serveur de messagerie unifiée 1 connaît une panne, les appels provenant de la passerelle SIP 1 négocieront automatiquement les appels avec le serveur de messagerie unifiée 2. Vous pouvez également programmer le PBX pour répartir équitablement la charge d'appels sur les passerelles SIP. Par exemple, le premier appel traité par le système peut être dirigé vers la passerelle SIP 1 et l'appel suivant dirigé vers la passerelle SIP 2. L'alternance des appels entre les passerelles assure une répartition équilibrée des appels et le partage de la charge entre les serveurs de messagerie unifiée.
Figure 4 Répartition des appels entre les serveurs pour assurer la redondance
Figure 4 Répartition des appels entre les serveurs pour assurer la redondance
Deux fournisseurs de passerelle SIP sont actuellement pris en charge pour les solutions de messagerie unifiée d'Exchange Server 2007 : AudioCodes et Dialogic. Si des passerelles SIP sont nécessaires dans votre conception, assurez-vous d'en acheter une qui prend en charge le nombre de sessions (de ports) requis par votre conception. Par exemple, si votre conception exige 32 ports, vous avez besoin d'une passerelle prenant en charge au moins autant de sessions.
Si vous vous demandez si votre PBX fonctionnera avec la messagerie unifiée ou quelle passerelle vous devez utiliser, consultez l'encadré « Ressources relatives à la messagerie unifiée ». Les liens répertoriés vous orienteront vers des aides spécifiques de Microsoft ainsi que vers un répertoire de Spécialistes de la messagerie unifiée, qui pourront vous aider à évaluer les besoins spécifiques de votre organisation. D'après mon expérience personnelle, il n'existe pas beaucoup de PBX que vous ne pouvez pas utiliser avec les passerelles SIP et la messagerie unifiée d'Exchange. Certains PBX peuvent même communiquer avec le serveur de messagerie unifiée en mode natif en utilisant le protocole SIP sur TCP.
La messagerie unifiée d'Exchange prend en charge trois codecs audio pour enregistrer les messages de la messagerie vocale : G.711 PCM Linear, GSM 06.10 et Windows Media® Audio (WMA). Chaque fichier PCM Linear WAV occupe environ 16 Ko par seconde de son enregistrée. WMA est le codec audio par défaut pour la messagerie unifiée, il compresse le son à 1,1 Kbit pour chaque seconde de son avec un en-tête de 7 Ko. GSM 06.10 compresse le son à 1,6 Kbit pour chaque seconde de son, mais il a un plus petit en-tête que le codage WMA.
Les codages WMA et GSM 06.10 offrent tous deux une qualité de son acceptable pour les messages vocaux. D'après mon expérience de l'utilisation des codecs WMA et GSM, vous pouvez supposer une augmentation 10 à 20 % de la taille du stockage de boîtes aux lettres en fonction de l'intensité de l'exploitation de la messagerie vocale par votre organisation.
Lorsque vous choisissez le codec audio à utiliser pour votre environnement, gardez à l'esprit les périphériques mobiles et autres systèmes d'exploitation que vos utilisateurs finaux peuvent utiliser. Les questions sur ce sujet sont surtout de savoir si les utilisateurs peuvent écouter leurs messages vocaux sur leurs périphériques Windows Mobile®. Les autres systèmes d'exploitation doivent également être pris en compte : peut-être avez-vous déployé un grand nombre d'ordinateurs Linux qui ne pourront peut-être pas lire les fichiers WMA. Quoi qu'il en soit, n'oubliez pas que ces facteurs ajouteront aux compétences des ressources de support technique que vous devrez prendre en compte pour la formation.

Configuration et tests
Que l'architecture de messagerie unifiée soit centralisée ou distribuée, il y a de nombreuses exigences de messagerie vocale dont vous devez tenir compte avant de déployer la messagerie unifiée dans votre organisation. Vous trouverez une liste détaillée des sujets devant être abordés par l'équipe de projet dans l'encadré « Liste de contrôle pour la messagerie unifiée ». Vous devez collecter des informations sur tous les sujets pour chaque site où vous envisagez d'implémenter la messagerie unifiée. N'oubliez pas que les équipes informatique et de télécommunications doivent travailler ensemble sur ces questions.
Une fois votre système conçu et la configuration finalisée, un système de test doit être mis en place pour valider la conception. Dans une conception multisite, je conseille de tester au moins deux sites séparés pour valider la conception et vérifier qu'elle fonctionne correctement.
Un plan de test des fonctionnalités doit être élaboré à partir de vos besoins de configuration et doit ensuite être mis en œuvre. Le plan de test des fonctionnalités doit inclure les méthodes d'accès des abonnés (téléphone, Outlook 2007 et Outlook Web Access), les méthodes d'administration et les défaillances du matériel et du réseau.
Une fois les tests terminés et quand tout le monde s'accorde sur le fait que la messagerie unifiée dupliquera les fonctionnalités de l'ancien système de messagerie vocale ou qu'une solution alternative a été conçue pour prendre en charge n'importe quelle configuration ou fonctionnalité qui ne peut pas être dupliquée, un groupe d'utilisateurs pilotes doit être sélectionné pour tester le système. L'utilisation d'un groupe pilote démontrera les étapes requises dans votre environnement pour migrer les abonnés de l'ancien système de messagerie vocale vers la messagerie unifiée. En général, les étapes suivantes sont nécessaires pour migrer un abonné :
  1. Désactiver l'abonné du système de messagerie vocale existant.
  2. Activer l'abonné dans Active Directory pour la messagerie unifiée par le biais de la Console de gestion Exchange.
  3. Modifier le chemin de couverture du téléphone sur un numéro pilote de messagerie unifié.
Il est important de désactiver l'abonné du système de messagerie existant pour qu'aucun message ne soit envoyé sur l'ancienne boîte aux lettres.
Pendant la phase pilote, vous devez consigner toutes les questions que vos abonnés poseront sur les fonctionnalités du système. Cette mesure de documentation vous permettra de traiter les problèmes courants pendant la phase de formation.
La formation est essentielle pour une migration des abonnés réussie. Vos utilisateurs ont l'habitude d'accéder à leur messagerie vocale à partir du téléphone avec une interface utilisateur spécifique. Par exemple, certains systèmes de messagerie vocale demandent que les utilisateurs appuient sur la touche 5 pour écouter leurs messages. Avec la messagerie unifiée d'Exchange, les utilisateurs doivent appuyer sur 1 ou dire « messagerie vocale » (ou utiliser Outlook 2007 ou Outlook Web Access pour lire les messages vocaux). La formation de vos abonnés pour la messagerie unifiée doit inclure la navigation dans l'interface utilisateur de téléphonie, la navigation dans Outlook Voice Access et la navigation dans Outlook/Outlook Web Access.
Avec la messagerie unifiée d'Exchange 2007, la possibilité d'énoncer les commandes est intégrée dans Outlook Voice Access. Certains utilisateurs ont tendance à se montrer enthousiastes face aux nouvelles fonctionnalités du système, et cet enthousiasme peut faciliter la transition d'une interface utilisateur à l'autre.
La messagerie unifiée d'Exchange offre la possibilité d'envoyer un message électronique personnalisé à chaque utilisateur lors de l'activation. Ces messages personnalisés peuvent être utilisés pour fournir des liens Web utiles vers des forums aux questions (FAQ), vers la documentation pour les abonnés, vers les numéros de téléphone du support technique, etc. Ils peuvent également contenir des informations sur la façon d'accéder au système de messagerie vocale et le mot de passe unique de l'abonné. C'est une des fonctionnalités les plus puissantes dont vous pouvez profiter lorsque vous activez vos utilisateurs finaux.

Migration des utilisateurs
Liste de contrôle pour la messagerie unifiée
Les sections suivantes définissent certains éléments fondamentaux d'un système de messagerie unifiée et suggèrent des questions devant être résolues en préparation du déploiement et de la configuration de la messagerie unifiée d'Exchange Server 2007. Utilisez ceci comme une liste de contrôle pour mettre au point un plan de déploiement.
Plan de numérotation – Un plan de numérotation de messagerie unifiée correspond logiquement à un PBX et aux extensions qui y sont associées. Les aspects à prévoir pour votre plan de numérotation sont :
  • Combien de chiffres les numéros d'extension comportent-ils ?
  • Quel est le numéro pilote du système de messagerie unifiée ?
  • Quel numéro les utilisateurs doivent-il composer pour obtenir une ligne extérieure ?
  • Quel codec audio utiliserez-vous pour les messages ?
  • Quel est le numéro d'extension de l'opérateur de l'entreprise ?
Groupements de postes et numéros pilotes – Un groupement de postes est un ensemble d'extensions téléphoniques configurées pour recevoir des appels dans un ordre particulier. Le numéro pilote est l'extension principale qui est appelée pour contacter le groupement de postes. Le nombre d'extensions des membres du groupement de postes doit être identique au nombre de ports de messagerie vocale dans votre conception.
Stratégies de boîte aux lettres – Les stratégies de boîte aux lettres de messagerie vocale ne sont pas très différentes des stratégies de boîte aux lettres Exchange. Voici quelques stratégies que vous voudrez peut-être envisager :
  • Combien de jours les messages vocaux sont-ils conservés avant d'être supprimés ?
  • Quelle est la fréquence requise pour la réinitialisation du mot de passe de messagerie vocale ?
  • Quelle est la stratégie de sauvegarde de la messagerie vocale ?
  • Quelle est la longueur de mot de passe minimale acceptable ?
  • Quel est le nombre maximal de tentatives d'ouverture de session avant le verrouillage de la boîte aux lettres ?
Standard automatique – les standards automatiques répondent aux appels entrants qui ne sont pas destinés à un abonné spécifique. Ils peuvent fournir des informations et diriger les appelants vers différents sites de l'organisation. La messagerie unifiée d'Exchange fournit des fonctionnalités vocales et DTMF pour la navigation dans le standard automatique. Les facteurs à prendre en compte sont notamment :
  • Existe-t-il des invites de standard automatique différentes pour la journée, la nuit et les jours non travaillés ? (Les invites doivent être décrites et enregistrées.)
  • Qui peut être appelé à partir du menu du standard automatique ?
  • La navigation vocale peut-elle être utilisée avec le standard automatique ?
  • L'utilisation du standard automatique nécessite-t-elle plusieurs langues ?
Boîte aux lettres Générale ou Nuit – Certaines organisations ont une boîte de messagerie vocale générale ou de nuit qui permet aux appelants de laisser des messages. Si votre entreprise en possède une, une boîte aux lettres Exchange doit être créée et activée pour la messagerie unifiée.
Indication de message en attente – L'indication de message en attente fait référence au voyant sur votre téléphone, qui vous signale les messages vocaux non lus dans votre boîte aux lettres. L'indication de message en attente sur les combinés téléphoniques est-elle nécessaire pour le déploiement ?
Prise en charge d'extensions multiples – Dans de nombreuses organisations, certains employés utilisent plusieurs téléphones. Quand vous activez ces abonnés pour la messagerie unifiée, vous devez en même temps associer tous leurs numéros d'extension. Avant de commencer, établissez une liste des employés possédant plusieurs extensions.
Prise en charge de la réponse vocale interactive (IVR) – Certains systèmes de messagerie vocale traditionnels prennent en charge des applications IVR, que la messagerie unifiée ne pourra pas dupliquer. Déterminez si le système à remplacer est associé à de telles applications. Ces applications peuvent rester sur le système existant ou devoir être remplacées par des applications IVR alternatives.
Réseau de messagerie vocale – La mise en réseau de la messagerie vocale offre la possibilité d'envoyer un message d'un système à un autre système hétérogène. Par exemple, dans les grandes entreprises, le PDG peut vouloir envoyer un message vocal à l'ensemble de l'organisation, ou vous pouvez avoir des informations générales à annoncer, comme des exercices d'incendie. Avec un réseau de messagerie vocale, le PDG peut enregistrer un message vocal une seule fois et l'envoyer à chaque employé de l'entreprise, quel que soit son système de messagerie vocale. Actuellement, la messagerie unifiée d'Exchange n'a pas la possibilité de se connecter à d'autres systèmes de messagerie vocale traditionnels.
Prise en charge de la télécopie – Certaines plates-formes de messagerie vocale traditionnelles prennent en charge la réception de télécopies, ce qui vous permet d'utiliser votre numéro de téléphone pour les appels vocaux et pour recevoir des télécopies. La messagerie unifiée d'Exchange Server 2007 prend en charge les télécopies entrantes et peut être utilisée pour remplacer cette fonctionnalité. Il s'agit d'une fonctionnalité unidirectionnelle ; le système ne prend pas en charge la fonctionnalité de télécopie sortante. Si vous en avez besoin, vous devrez rechercher un produit tiers pour la prendre en charge.

Il existe de nombreux points de vue différents sur la façon de migrer un système dans l'environnement de production. Les deux méthodes principales sont la migration graduelle et la migration rapide. Quel que soit votre choix, formez votre personnel de support technique aux questions courantes que vous avez reçues de votre groupe pilote. Veillez en outre à leur montrer comment activer un utilisateur, comment vérifier qu'un utilisateur est activé et comment modifier un mot de passe.
La migration des utilisateurs de l'ancien système de messagerie vocale à la messagerie unifiée est relativement simple, mais cela présente une difficulté majeure dont vous devez être conscient : la mise en réseau de la messagerie vocale. Tout comme un système de messagerie vous permet d'envoyer des messages, de transférer des messages et de répondre à d'autres utilisateurs et systèmes de messagerie électronique, la messagerie vocale vous permet d'envoyer des messages, de transférer des messages et de répondre aux autres utilisateurs et systèmes de messagerie vocale.
Imaginez un scénario où Alice et Bertrand utilisent actuellement l'ancien système de messagerie vocale. Bertrand a migré sur la messagerie unifiée et veut envoyer un message à Alice sur l'ancien système de messagerie vocale. Puisque les deux utilisateurs sont sur des systèmes séparés, ils ne peuvent plus envoyer, transférer ou répondre aux messages de messagerie vocale de l'autre ; malheureusement, un îlot de messagerie vocale a été créé.
Avec les systèmes de messagerie vocale traditionnels, ce problème est résolu en utilisant certains types de convertisseurs de protocole réseau permettant à des systèmes hétérogènes de former un réseau ensemble. A l'heure actuelle, il n'existe cependant pas de convertisseur de protocole réseau qui permette à des systèmes hétérogènes à se connecter à la messagerie unifiée d'Exchange Server 2007. Même si ce n'est pas peut-être pas important pour votre organisation, vous devez prendre cet aspect en compte si vous choisissez de migrer des utilisateurs par petits groupes.
Ma préférence va à la migration rapide de tous les utilisateurs site par site. Une migration rapide offre une coupure propre entre un système et l'autre. Elle est souvent réalisée pendant un week-end ; les utilisateurs rentrent chez eux le vendredi et viennent travailler le lundi sur un nouveau système de messagerie vocale. Certains administrateurs disent qu'une migration rapide ne devrait être utilisée que pour les petits clients d'entreprise ou les sites distants. Je ne suis pas d'accord. J'ai participé à des migrations rapides de 7 000 utilisateurs sur un seul site, et moins de 1 % des employés ont dû appeler le support technique pour obtenir de l'aide. Si toutes les autres phases de votre projet ont été correctement planifiées et exécutées, la migration vers un système de production complet doit se passer sans heurt.
Toutefois, si vous effectuez une migration de plusieurs sites sur un système de production complet, envisagez de migrer les plus petits sites distants un par un avant de migrer le plus gros site. Examinez les leçons apprises avec les plus petits sites et implémentez les modifications nécessaires dans votre plan de projet.
Idéalement, toute la formation des utilisateurs doit être terminée et tous les utilisateurs doivent être activés pour la messagerie unifiée avant la mise en service du système. Voici une méthodologie détaillée à utiliser pour préparer une migration rapide d'un système de messagerie vocale.
La première chose à faire est de s'assurer que le système de messagerie unifiée est entièrement installé, configuré et testé.
Dispensez la formation par petits groupes. Expliquez aux utilisateurs que leur boîte aux lettres sera activée avant d'être connectée au système, et qu'ils sont encouragés à se connecter à leur boîte aux lettres et à l'initialiser en modifiant leur mot de passe et en enregistrant leur message d'accueil. Une fois la formation terminée, activez ces utilisateurs immédiatement pour leur permettre d'initialiser leur boîte aux lettres avant la migration.
Enfin, lorsque toute la formation est finie, choisissez un week-end pour désactiver tous les utilisateurs de l'ancien système de messagerie vocale et transférez leurs téléphones vers la messagerie unifiée d'Exchange. Le lundi matin, votre système est opérationnel pour tous les utilisateurs de votre organisation.

Migration
Que vous deviez prendre en charge un site unique ou une grande organisation multisite, les informations de cet article devraient vous être utiles. Les organisations multisite peuvent rendre la conception plus complexe, mais les exigences de base sont les mêmes que vous ayez 50 ou 5 000 utilisateurs.
Je n'insisterai jamais assez sur le fait que les équipes informatique et de télécommunications doivent travailler ensemble au déploiement d'une solution de messagerie unifiée. D'après mon expérience, parmi les nombreux problèmes qui peuvent faire échouer un projet de messagerie unifiée, une mésentente entre l'équipe informatique et l'équipe de télécommunications et un désaccord sur la solution sont synonymes d'échec assuré. La convergence des technologies n'est pas si difficile, mais elle peut nécessiter une personne externe à votre organisation qui connaisse à la fois l'informatique et les télécommunications pour vous aider à faire collaborer les équipes ou à établir un plan de projet pour un déploiement réussi.

Jeff Goodwin est technicien senior chez The VIA Group, spécialisé dans la conception et le déploiement d'Exchange et de messagerie unifiée. Vous pouvez le joindre à l'adresse suivante : jgoodwin@theviagroup.com.


 S&#233;curit&#233;: Guide d'investigation informatique de base
Sécurité Tom Cloward and Frank Simorjay

Guide d'investigation informatique de base
Vue d'ensemble:
  • Guide d'investigation informatique de base pour Windows
  • Starter Kit de désinstallation de logiciels malveillants
  • Création d'un kit d'investigation avec Windows PE
  • Conservation d'informations pour l'analyse forensique

Les méthodes auxquelles peuvent avoir recours les utilisateurs malveillants pour détourner un ordinateur afin d'exécuter des activités illégales telles que le piratage de systèmes, la divulgation de secrets commerciaux, le déclenchement d'attaques avec de nouveaux virus, l'utilisation du hameçonnage pour voler des informations personnelles, etc. sont innombrables. Nous entendons par ailleurs constamment parler de nouveaux programmes malveillants exploitant les failles de sécurité
et de nouvelles techniques. Ce dont nous n'entendons pas souvent parler, ce sont les diverses façons dont les ordinateurs peuvent être utilisés dans le cadre des investigations liées à ces activités.
Certaines investigations s'appuient sur des experts utilisant des outils coûteux et des techniques complexes, mais il existe des méthodes moins chères et plus simples que vous pouvez utiliser dans les investigations et les analyses de base. Dans cet article, nous nous concentrerons sur les techniques inforensiques auxquelles vous pouvez facilement accéder en tant qu'administrateur.
Notre discussion s'appuie sur deux accélérateurs de solution que vous pouvez télécharger gratuitement : Le « Guide d'investigation informatique de base pour Windows » (go.microsoft.com/fwlink/?LinkId=80344) et Le Starter Kit de désinstallation de logiciels malveillants (go.microsoft.com/fwlink/?LinkId=93103). Dans cet article, nous vous montrerons comment combiner ces deux solutions pour créer un environnement de démarrage Windows® PE qui vous permettra de mener une investigation efficace et d'en conserver les résultats pour la création de rapports et l'analyse. Notez que vous ne pouvez pas utiliser la méthode abordée dans cet article pour examiner un disque dur qui a été chiffré ou qui fait partie d'un volume RAID. Et si le disque dur est endommagé, vous devrez prendre d'autres mesures préalables pour restaurer son état.
Bien que notre solution décrive un moyen aisé de recueillir des preuves à partir d'un ordinateur Windows, elle n'en demeure pas moins une solution de base ad hoc. Il existe de nombreuses solutions, plus sophistiquées et disponibles sur le marché, qui peuvent accomplir les tâches décrites dans cet article d'une façon beaucoup plus efficace.
En outre, n'oubliez pas que la technique que nous abordons ici n'est pas une solution normative garantie et n'est pas certifiée par l'ISFCE (International Society of Forensic Computer Examiners). Avant de commencer une investigation, vous devez considérer si les preuves existant sur le disque dur pourraient être utilisées dans le cadre d'un procès. Si cette éventualité existe, un examinateur informatique professionnellement certifié doit être engagé pour mener l'investigation. Selon la nature de l'action en justice, vous devez également envisager de confier directement l'investigation aux services chargés de l'application de la loi. Vous trouverez plus d'informations à ce sujet dans « Le Guide d'investigation informatique de base pour Windows ».

À propos des accélérateurs de solution
Le « Guide d'investigation informatique de base pour Windows » aborde les divers processus et outils que vous pouvez utiliser dans une investigation informatique interne. Ce guide décrit les quatre phases du modèle d'investigation informatique : évaluation, acquisition, analyse et rapport. Il s'agit d'un modèle pratique qui peut aider les professionnels de l'informatique à mener des investigations d'une façon qui conserve les résultats importants.
Ce guide vous indique également quand il est nécessaire d'impliquer les services chargés de l'application de la loi ; vous devez consultez vos conseillers juridiques lorsque vous prenez cette décision. Vous trouverez des informations sur la gestion des crimes informatiques, la façon de contacter les services chargés de l'application de la loi et les outils Windows Sysinternals et autres outils Windows qui vous aideront à mener des investigations.
L'autre accélérateur de solution auquel nous faisons référence dans cet article, le Starter Kit de désinstallation de logiciels malveillants, fournit des conseils sur la façon de créer et d'utiliser un CD-ROM de démarrage Windows PE pour supprimer les logiciels malveillants d'un ordinateur. Ce guide inclut une liste de menaces et certaines atténuations qui peuvent vous aider à minimiser leur impact sur une organisation. Il souligne en outre l'importance de l'élaboration d'un plan de réponse aux incidents pouvant être suivi en cas d'attaque de programmes malveillants. Le Starter Kit de désinstallation de logiciels malveillants inclut également une méthode en quatre étapes visant à aider les professionnels de l'informatique à déterminer la nature des logiciels malveillants en question, limiter leur propagation, les supprimer si possible, vérifier ces suppressions et prendre toute autre mesure pouvant s'avérer nécessaire.

CD-ROM Windows PE
Deux éléments sont nécessaires pour exécuter une investigation de ce genre : un CD-ROM Windows PE et un périphérique de stockage externe (par exemple un lecteur Flash USB).
Vous avez probablement vu suffisamment de films à la télévision pour savoir que la police doit toujours laisser la scène du crime intacte. Vous devez, vous aussi, conserver les données telles qu'elles sont sur le disque dur que vous examinez. Contrairement au disque du Starter Kit de désinstallation de logiciels malveillants, le disque de démarrage Windows PE que nous sommes en train de créer exécutera les outils en ne touchant pas du tout aux données du disque dur.
Le disque de Windows PE lancera le système dans un environnement Windows limité. Lorsque vous créez ce CD de démarrage, vous pouvez inclure des outils (tels que ceux du Starter Kit de désinstallation de logiciels malveillants) qui sont configurés à l'avance pour un objectif spécial. Notez que l'ordinateur doit disposer d'au moins 512 Mo de mémoire vive. Cette configuration est requise par Windows PE.
Le processus de création du CD-ROM Windows PE, détaillé dans le Starter Kit de désinstallation de logiciels malveillants, est assez simple. Avant de créer ce disque de démarrage, vous devez installer le Kit d’installation automatisée (Windows AIK), installer la Suite Sysinternals (disponible à l'adresse microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx), placer les outils Sysinternals dans votre liste d'outils comme indiqué dans la Tâche 2 du Starter Kit de désinstallation de logiciels malveillants et installer les éventuels autres outils et utilitaires d'analyse anti-programme malveillant. Pour obtenir des instructions détaillées sur la création du disque, suivez les étapes décrites dans le document Starter Kit de désinstallation de logiciels malveillants.

Lecteur USB externe
Dans la mesure où ce processus ne modifiera pas le lecteur faisant l'objet d'une investigation, vous aurez également besoin d'un lecteur USB de poche ou autre type de disque dur externe afin d'y enregistrer les fichiers de sortie qui seront créés. (Le lecteur USB de poche est recommandé car Windows PE peut monter les périphériques USB automatiquement). Vous pouvez également utiliser un disque dur externe pour enregistrer une image du disque dur original. Vu toutes ces conditions et options, vous devez absolument prévoir l'espace disque total nécessaire pour l'investigation.
Comme le kit doit être propre lorsque vous démarrez une investigation, vous devez supprimer toutes les données précédentes du lecteur de disque externe que vous utiliserez pour enregistrer les fichiers de l'investigation. Cette opération peut être facilement effectuée avec un utilitaire de nettoyage de disque qui écrase toute la surface inscriptible du disque. Le disque externe peut être ensuite formaté et étiqueté comme nécessaire pour être utilisé au cours de l'investigation. Vous vous assurez ainsi que le périphérique ne contient pas de fichiers qui pourraient contaminer les preuves que vous réunissez durant l'investigation.
Vous devez également inclure un formulaire de chaîne de conservation afin que toutes les personnes ayant manipulé au cours de l'investigation soient officiellement documentées. Le « Guide d'investigation informatique de base pour Windows » comporte un exemple de formulaire de chaîne de conservation. Après avoir terminé d'empaqueter le kit (avec le disque de démarrage Windows PE, le périphérique de stockage externe et un formulaire de chaîne de conservation) vous êtes prêt à commencer.

L'investigation
Vous êtes maintenant prêt à mener une investigation. Tout d'abord, lancez le système impliqué en utilisant le disque Windows PE, en veillant à ce que la commande de démarrage de l'ordinateur identifie le lecteur de CD-ROM comme périphérique de démarrage principal. À l'invite, appuyez sur n'importe quelle touche pour compléter le démarrage du CD-ROM. Vous accédez ainsi aux outils que vous avez installés sur le disque.
Nous utiliserons notre kit sur une machine d'exemple pour démontrer comment vous pouvez recueillir des informations à partir d'un ordinateur (que nous appellerons Testbox1). Le nom du lecteur CD sur Testbox1 est X:\ et l'emplacement par défaut proposé pour les outils du Starter Kit de désinstallation de logiciels malveillants est X:\tools. Pour accéder aux outils du kit, il nous suffit de taper : cd \tools.
Il existe plusieurs outils qui peuvent identifier les lecteurs cibles installés sur un ordinateur. Bginfo.exe, qui se trouve dans le répertoire d'outils Sysinternals, peut fournir ces informations et les placer dans une fenêtre d'arrière-plan, sur le Bureau. Drive Manager peut également identifier tous les lecteurs de l'ordinateur, y compris les lecteurs de disque dur cibles et le périphérique USB externe. La figure 1 affiche les informations sur les disques pour Testbox1. Le lecteur de démarrage est X:\, le disque dur cible est C:\ et notre lecteur USB externe F:\.
Figure 1 Accès aux informations sur disque avec Drive Manager
Figure 1 Accès aux informations sur disque avec Drive Manager

Vérification de la présence de logiciels malveillants
Il est important d'exécuter des outils anti-programme malveillant avant de commencer une investigation afin de s'assurer que cette dernière n'est pas compromise par un virus ou tout autre code malveillant. Le rapport dressé par l'outil anti-programme malveillant peut être utilisé comme preuve, le cas échéant. Toutefois, si vous ne vérifiez pas la présence de logiciels malveillants sur un ordinateur, vous risquez de compromettre l'investigation et la crédibilité de la personne menant l'investigation. Nous vous conseillons d'exécuter les outils anti-programme malveillant fournis en mode lecture seule ou rapport.
Le Starter Kit de désinstallation de logiciels malveillants examine plusieurs outils recommandés, dont l'Outil de suppression des logiciels malveillants et McAfee AVERT Stinger. Lorsque vous exécutez l'Outil de suppression des logiciels malveillants, n'oubliez pas d'inclure l'option de ligne de commande /N pour demander à l'outil de dresser uniquement un rapport sur les logiciels malveillants et pas d'essayer de les supprimer :
x:\tools\windows-KB890830-v1.29.exe /N
Le fichier de rapport résultant sera placé dans %windir%\debug\mrt.log.
De même, lorsque vous exécutez McAfee AVERT Stinger, réglez la préférence sur Rapport only, comme illustré à la figure 2 ; il analysera ainsi l'ordinateur mais n'effectuera aucune modification sur le disque dur. Et n'oubliez pas d'enregistrer un rapport de l'outil une fois l'analyse terminée.
Figure 2 Utilisez le mode Rapport only dans McAfee AVERT Stinger
Figure 2 Utilisez le mode Rapport only dans McAfee AVERT Stinger

Enregistrement des fichiers critiques
Si vous n'avez pas sauvegardé le disque entier avant d'avoir commencé l'investigation, vous devriez au moins sauvegarder les fichiers utilisateur clés. Les informations de configuration peuvent être utilisées pour une consultation future, le cas échéant. Commencez par réunir les fichiers et paramètres de Registre qui contiennent toutes les informations pertinentes à l'utilisation de l'ordinateur et aux logiciels installés sur le système.
Pour enregistrer la ruche du Registre pour Testbox1, nous créons d'abord un dossier sur le lecteur amovible F:\ et enregistrons ensuite la date et l'heure de début de l'investigation à l'aide des commandes suivantes :
f:
Mkdir f:\evidence_files
Date /t >> f:\evidence_files\Evidence_start.txt
Time /t >> f:\evidence_files\Evidence_start.txt
Ensuite, nous enregistrons la ruche du Registre en utilisant la commande xcopy pour copier la totalité du répertoire de configuration et son contenu. Les fichiers de Registre qui vous intéressent se trouvent dans %windows%\system32\config. Dans notre cas, nous exécutons :
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
Cette commande copie toutes les informations de configuration situées dans le dossier config. Textbox1 contient environ 95 Mo d'informations situées dans le dossier config.
Ensuite, concentrez-vous sur les données utilisateur qui peuvent se trouver n'importe où sur le disque dur. Dans le cadre de notre exemple, nous copions uniquement les données d'un répertoire appelé c:\HR. Pour nous assurer que les données sont toutes réunies, nous copions toutes les données du répertoire et de son sous-répertoire en utilisant la commande xcopy suivante :
Mkdir f:\evidence_files\HR_Evidence
Mkdir f:\evidence_files\documents_and_settings
Mkdir f:\evidence_files\users
xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
À présent, vous pouvez porter votre attention sur les informations des dossiers personnels. Là encore, nous voulons copier toutes les données de ces répertoires et leurs sous-répertoires. Pour ce faire, nous utilisons les commandes suivantes :
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
Cet échantillon a recueilli environ 500 Mo de données, que nous pouvons maintenant analyser, le cas échéant. Comme vous le voyez, la quantité de données que vous recueillez peut être énorme, surtout si vous tombez sur des fichiers audio ou vidéo ou sur des photos. Quoi qu'il en soit, il est important de conserver autant de données originales que possible parce qu'une investigation peut nécessiter non seulement les preuves que vous recueillez physiquement, mais aussi l'assurance que ces informations n'ont pas été modifiées au moment où vous les recueillez. Dans l'idéal, vous devez créer une image du disque complète pour votre investigation, mais cette opération peut être difficile en raison de contraintes de taille. Vous comprenez maintenant pourquoi il est important de prévoir à l'avance l'espace de stockage nécessaire pour votre investigation.

Recueil d'informations supplémentaires
Les fichiers système peuvent être également très utiles pour la collecte de preuves, mais pour réunir de telles données, vous devrez peut-être procéder à une exploration de l'ordinateur cible puisque ces fichiers ne sont pas toujours au même endroit. Certains types de fichiers valent la peine d'être analysés car ils peuvent vous fournir des indices très utiles. Les fichiers d'échange, par exemple, contiennent des informations sur les fichiers qui ont été consultés par le biais de la mémoire. En outre, les fichiers d'échange peuvent même vous donner des détails sur les activités d'utilisation. De même, les données et cookies du navigateur Web fournissent des informations sur les comportements et les modèles de navigation.
Vous devrez peut-être faire des recherches pour trouver ces données, surtout si un utilisateur a modifié sa configuration et enregistré des données en dehors des emplacements par défaut. Il existe plusieurs outils Sysinternals qui peuvent vous aider à trouver les fichiers critiques. La figure 3 illustre cinq applications utiles et décrit comment elles peuvent vous aider dans votre investigation.
Figure 3 Outils permettant de trouver les fichiers et données critiques (Close Figure 3)

Application | Description
AccessChk | Affiche l'accès aux fichiers, les clés de Registre et les services Windows de l'utilisateur ou du groupe que vous spécifiez.
AccessEnum | Affiche les utilisateurs ayant accès à tels annuaires, fichiers et clés de Registre sur un ordinateur. Vous pouvez l'utiliser pour trouver des endroits où les autorisations n'ont pas été appliquées convenablement.
Du | Affiche l'utilisation du disque par répertoire.
PsInfo | Affiche les informations sur un ordinateur.
Strings | Recherche les chaînes ANSI et UNICODE dans les images binaires.

Tom Cloward, CCE, CISSP, est responsable de programme chez Microsoft et est chargé de fournir des accélérateurs de solution de sécurité et conformité aux professionnels de l'informatique. Il travaille dans le secteur des logiciels et de l'informatique depuis plus de 15 ans et est passionné de sécurité informatique, d'analyse forensique et de conformité. Frank Simorjay, CISSP, CET, est responsable de programme technique chez Microsoft et expert en matière de sécurité pour le groupe Microsoft Solutions for Security and Compliance (MSSC). Il crée des solutions de sécurité pour les clients de Microsoft. Il est notamment l'autre du Starter Kit de désinstallation de logiciels malveillants, disponible sur Microsoft TechNet.
Frank Simorjay, CISSP, CET, est responsable de programme technique chez Microsoft et expert en matière de sécurité pour le groupe Microsoft Solutions for Security and Compliance (MSSC). Il crée des solutions de sécurité pour les clients de Microsoft. Il est notamment l'autre du Starter Kit de désinstallation de logiciels malveillants, disponible sur Microsoft TechNet.


 Mise en r&#233;seau: Rapport de s&#233;curit&#233; Microsoft
Mise en réseau Tim Rains

Rapport de sécurité Microsoft
Vue d'ensemble:
  • Tendances dans les divulgations des vulnérabilités logicielles , l'exploitation de vulnérabilités et les logiciels malveillants
  • Impact des menaces sur différentes versions Windows
  • Régions du monde les plus et les moins infectées

Des données provenant des centaines de millions de systèmes connectés à Internet et de certains des services en ligne internationaux les plus utilisés offrent à Microsoft une vision unique des menaces auxquelles font face les internautes aujourd'hui.
Microsoft partage ces données deux fois par an dans son rapport de sécurité. Les collaborateurs au rapport incluent le centre MMPC (Centre Microsoft® de protection contre les logiciels malveillants), le centre MSRC, le groupe TwC (Trustworthy Computing), ainsi que de nombreux autres groupes de produit. Le rapport de sécurité offre une vue approfondie de tendances récentes dans les divulgations de vulnérabilités logicielles, les logiciels malveillants et les logiciels potentiellement indésirables tels que les logiciels espions et publicitaires. Ce rapport inclut également des détails sur les performances des diverses versions du système d'exploitation Windows dans le paysage des menaces et sur les régions du monde les plus infectées par les logiciels malveillants et autres logiciels indésirables. La dernière version du rapport, qui porte sur les tendances observées durant la première moitié de l'année 2007, inclut une nouvelle section sur l'exploitation des vulnérabilités logicielles. Si la sécurité informatique est votre responsabilité ou vous intéresse, le rapport de sécurité vous sera d'une grande utilité et vous aidera à bien connaître les menaces de sécurité liées à Internet.
Le dernier rapport de sécurité révèle que les chercheurs qui s'intéressent à la sécurité trouvent de plus en plus de vulnérabilités dans les logiciels tous fournisseurs confondus. En fait, plus de 3 400 nouvelles vulnérabilités logicielles ont été révélées dans la première moitié de l'année 2007 uniquement ! Pourtant, malgré l'importance de ce chiffre, le pourcentage global des vulnérabilités des systèmes d'exploitation révélé est en diminution.
Qu'est-ce que cela signifie ? Il est possible que les chercheurs se concentrent plus sur les applications parce que la sécurité des systèmes d'exploitation continue de s'améliorer. En outre, puisque le nombre de nouvelles applications dépasse largement le nombre de nouveaux systèmes d'exploitation, la prolifération des applications explique probablement ces récentes tendances liées à divulgation des menaces.
Durant l'année 2006, 29,3 % des vulnérabilités connues dans les produits Microsoft avaient un code d'exploitation publiquement disponible, alors qu'au 1er août 2007, 20,9 % seulement des vulnérabilités connues avaient un code d'exploitation disponible publiquement. Bien que le nombre de vulnérabilités continue d'augmenter, le taux de codes d'exploitation reste constant et a même légèrement diminué. Le code d'exploitation pour les nouveaux produits est plus difficile à trouver. Nous avons mené une comparaison produit par produit qui suggère que les plus nouvelles versions de produits sont moins menacées que les versions de produits qui se trouvent sur le marché depuis longtemps. En moyenne, l'exploitabilité diminue en fonction des durées de vie des produits, ce qui signifie que les versions les plus récentes sont généralement moins exploitables. Ceci est particulièrement évident pour Windows et les produits Microsoft Office System. Le nombre de vulnérabilités liées aux versions ultérieures de Windows Server® 2003, Windows Vista®, Office 2003 et Office System 2007 a nettement diminué.
Le rapport de sécurité propose des informations importantes sur les tendances liées aux logiciels malveillants. Ces tendances sont une indication des tactiques actuellement utilisées pour attaquer les utilisateurs. Un examen des données provenant de certaines sources importantes, notamment Microsoft Exchange Hosted Services (EHS), Windows Live® OneCare et le Scanner de sécurité Windows Live OneCare, l'Outil de suppression de logiciels malveillants de Windows (MSRT) et Windows Defender, contribuera à nous donner une idée du paysage des menaces, vu sous différents angles.
L'ingénierie sociale joue un rôle de plus en plus important dans la distribution de logiciels malveillants. Ces attaques consistent souvent à amener les utilisateurs à prendre des mesures qui peuvent affaiblir l'efficacité de leur système de sécurité. Les données provenant d'EHS indiquent que, durant la première moitié de l'année 2006, les vers constituaient la menace véhiculée par courrier électronique la plus importante, représentant 95 % des logiciels malveillants détectés dans les messageries électroniques. Au début de la deuxième moitié de l'année 2006, ce pourcentage est passé à 49 % et n'a pas changé durant toute la première moitié de l'année 2007 (voir la figure 1). Les escroqueries par hameçonnage et les messages électroniques renfermant des attaques IFrame représentaient 27 % des logiciels malveillants détectés dans les messages électroniques durant la deuxième moitié de l'année 2006, pourcentage qui est passé à 37 % au cours de la première moitié de l'année 2007. Les chevaux de Troie téléchargeurs véhiculés par les messages électroniques atteignaient 20 % dans la deuxième moitié de 2006 pour retomber à 7 % durant la première moitié de l'année 2007.
Figure 1 Composition des messages électroniques infectés durant la première moitié de l'année 2007
Figure 1 Composition des messages électroniques infectés durant la première moitié de l'année 2007
Les données de télémétrie recueillies à partir de Windows Live OneCare et du Scanner de sécurité Windows Live OneCare (safety.live.com) indiquent que les taux d'infection par les virus, les portes dérobées, les renifleurs de mots de passe et chevaux de Troie de vol de données ont augmenté durant la première moitié de l'année 2007.
MSRT est conçu pour aider à identifier et supprimer les logiciels malveillants courants des ordinateurs des clients. Il est surtout publié sous forme de mise à jour critique par Windows Update (WU), Microsoft Update (MU), et les Mises à jour automatiques. Au cours des deux dernières années, MSRT a supprimé 50,3 millions d'infections de 20,5 millions d'ordinateurs à travers le monde. Le nombre d'exécutions total de MSRT jusqu'à présent dépasse 7,4 milliards, dont 1,9 milliards d'exécutions durant la première moitié de 2007 seulement.
MSRT est une source de données très utiles pour Microsoft et ses clients. Les taux d'infection observés par MSRT sont beaucoup moins importants dans les systèmes Windows Vista et Windows XP SP2 que dans les systèmes d'exploitation Windows moins récents, comme illustré à la figure 2. MSRT a supprimé des logiciels malveillants sur moins d'ordinateurs exécutant Windows Vista que d'ordinateurs exécutant Windows XP SP2 (60 % de moins), et que d'ordinateurs exécutant Windows XP sans Service Pack (91,5 % de moins). Notez que le nombre de désinfections par ordinateur est resté constant, avec une moyenne de 2,2 désinfections par ordinateur infecté.
Figure 2 Versions de systèmes d'exploitation nettoyées par MSRT durant la première moitié de l'année 2007
Figure 2 Versions de systèmes d'exploitation nettoyées par MSRT durant la première moitié de l'année 2007
En règle générale, MSRT détecte plus de logiciels malveillants dans les pays en développement que dans les pays développés. Par exemple, les pays les plus infectés en Europe sont l'Albanie et la Turquie, tandis que les moins infectés sont l'Italie et la Finlande. Dans la région Asie-Pacifique, les pays les plus infectés sont la Mongolie et la Thaïlande, tandis que les moins infectés sont la Nouvelle-Zélande et le Japon. Les États-Unis sont proportionnellement moins infectés que la plupart des pays et régions d'Amérique, et leur taux d'infection est à peu près identique à la moyenne mondiale. En moyenne, MSRT a nettoyé 1 ordinateur sur 216 durant la première moitié de l'année 2007.
Windows Defender s'exécute sur Windows Vista, Windows XP et Windows Server 2003. En moyenne, 50,7 millions de logiciels potentiellement indésirables ont été détectés pendant la première moitié de l'année 2007, avec 2,8 fois moins de logiciels détectés sur les ordinateurs exécutant Windows Vista que sur ceux qui exécutaient Windows XP SP2. De même, le nombre de détections de logiciels potentiellement indésirables sur les ordinateurs exécutant Windows Vista correspondait à la moitié du nombre de logiciels malveillants détectés sur les ordinateurs exécutant Windows Server 2003.
Vous vous demandez probablement, à présent, comment toutes ces statistiques, aussi intéressantes soient-elles, peuvent vous aider à mieux protéger votre environnement. Dans le dernier rapport de sécurité, chaque section importante est précédée d'un résumé et d'une série de « stratégies, atténuations et contre-mesures ». Vous pouvez utiliser ces listes pour trouver rapidement les points importants de chaque section du rapport.
De plus, vous pouvez utiliser les données, les aperçus et les conseils du rapport de sécurité pour évaluer et améliorer votre sécurité actuelle par rapport aux menaces en constante évolution. Le rapport complet, qui propose des stratégies, atténuations et contre-mesures basées sur des résultats importants, peut être téléchargé du site microsoft.com/sir.

Tim Rainsest responsable de produit au centre de protection contre les logiciels malveillants de Microsoft (MMPC). Il gère la production du Rapport de sécurité Microsoft ou SIR. Les auteurs de ce rapport sont Jeff Jones (directeur du Microsoft Trustworthy Computing Group), Jeff Williams (directeur du MMPC), Mike Reavey (directeur du groupe Microsoft Security Response Center) et Ziv Mador (responsable de programme senior et coordinateur de réponse, MMPC).


 Mise en r&#233;seau: D&#233;pistage des probl&#232;mes r&#233;seau insaisissables
Mise en réseau Christophe Stoneff

Dépistage des problèmes réseau insaisissables
Vue d'ensemble:
  • Causes habituelles de problèmes réseau
  • Voir au-delà des apparences
  • Quand les outils de dépannage sont inutiles
  • Pourquoi configurer les limites de connexion

Ce scénario vous est sans doute familier, votre ordinateur ne peut plus communiquer avec le reste du réseau et vous ne voyez pas pourquoi. Votre système de gestion repose sur un segment de réseau routé connecté à d'autres segments réseau par l'intermédiaire d'un routeur, tel que Microsoft Internet
Security and Acceleration (ISA) Server ou un autre périphérique matériel. La gestion de 10, 20, voire 100 systèmes, se fait sans problèmes. Par contre, lorsque vous passez à 500 systèmes, votre ordinateur est incapable de communiquer sur le réseau, à l'exception des ordinateurs avec lesquels il dispose déjà de connexions ouvertes. Vous ne pouvez communiquer avec aucun autre système, vous ne pouvez pas accéder à Internet, alors que personne d'autre sur le réseau, ce qui inclut votre segment, ne subit ce phénomène. Par où commencer ?

Diagnostic du problème
Dans ce cas, le logiciel de gestion est le principal suspect. De nombreux outils de gestion dynamiques se connectent et gèrent vos systèmes. Cependant, il arrive parfois que ces outils soient à l'origine du problème que vous tentez de dépister. Ceci est dû au fait qu'un outil de gestion dynamique peut créer des milliers de connexions avec vos périphériques au nom d'une meilleure gestion. Windows® laisse ces connexions ouvertes pendant deux minutes par défaut même si les connexions sont inutilisées, sauf si l'outil, l'application ou le service les maintiennent actives plus longtemps. Ceci signifie que même si votre système de gestion n'a pas communiqué avec d'autres ordinateurs pendant deux minutes, vous pouvez avoir plus de 1 000 connexions ouvertes. (Vous pouvez afficher les connexions ouvertes en exécutant NETSTAT à partir de la ligne de commande. La commande NETSTAT affiche toutes les connexions ouvertes, en attente et en cours de fermeture, depuis ou vers votre système, et indique leur état. Les descriptions des messages d'état figurent dans RFC 793 sur tools.ietf.org/html/rfc793.)
Pour écarter tous les logiciels de gestion défaillants, vous pouvez créer un fichier de commandes qui établit des connexions avec les systèmes distants. Si le même problème survient pendant l'exécution du fichier de commandes, ceci signifie que le logiciel de gestion et ses threads ne sont pas à l'origine du problème. Voici un exemple de contenu du fichier de commandes requis :
Net use \\system01\ipc$
Net use \\system02\ipc$
Net use ...
Si le programme de gestion en question mettait en œuvre sa propre mise en réseau et pile d'authentification, il pourrait être à l'origine du problème. Dans les solutions sans agent, comme pour la plupart des packages de gestion, l'outil exploite les fonctionnalités réseau et les piles d'authentification du système d'exploitation pour exécuter les opérations réseau. Si le fichier de commandes crée autant de connexions réseau sans pour autant entraîner de défaillance, ceci indique que le problème ne résulte pas de l'exploitation des fonctionnalités réseau et de la pile d'authentification du système d'exploitation, dans la mesure où le fichier de commandes les utilise aussi.

Journaux et messages d'erreur qui prêtent à confusion
Vous avez probablement constaté que lorsque les connexions ont commencé à échouer, vous avez reçu des messages d'erreur erronés : erreur 53 : chemin réseau n'a pas été trouvé, erreur 64 : le nom réseau a été supprimé et erreur 1203 : aucun logiciel réseau n'a accepté le chemin réseau fourni. Tous ces messages indiquent généralement des problèmes de résolution de nom. Toutefois, tous les autres ordinateurs parviennent à résoudre les noms sans problème et à se connecter aux mêmes systèmes. Pour vous assurer que les paramètres de votre ordinateur ne sont pas en cause, exécutez simplement ipconfig pour confirmer que vos paramètres sont corrects.
Ensuite, si le phénomène semble localisé sur votre système de gestion, consultez les journaux des événements. La recherche dans les journaux d'application est infructueuse, alors que le journal système présente un événement d'avertissement 4226 provenant de la source d'événement TCP/IP, indiquant que le nombre maximum de connexions a été atteint (voir la figure 1).
Figure 1 La limite de connexions TCP a été atteinte
Figure 1 La limite de connexions TCP a été atteinte
Effectuez une recherche dans la base de connaissances de Microsoft® concernant les limites de connexion. Vous verrez alors que des limites de connexion s'appliquent en cas de connexions incomplètes, tandis que les connexions complètes ne sont sujettes à aucune limite. Vous avez la capacité de régler les entrées de Registre suivantes sous HKLM\System\CurrentControlSet\Services\TCPIP pour contrôler les facteurs mentionnés ci-dessus : TcpNumConnections est utilisé pour définir le nombre maximum de connexions que TCP peut ouvrir en même temps (la valeur par défaut est de 10). TCPTimedWaitDelay définit la durée de l'état TIME_WAIT pour la connexion en cours de fermeture. La demi-durée de vie par défaut est de 120 secondes, ce qui signifie qu'une connexion est utilisée pendant 4 minutes. Enfin, MaxFreeTcbs joue également un rôle concernant le nombre maximal de connexions. Si tous les blocs de contrôle TCP sont utilisés, TCP doit libérer les connexions dont l'état est TIME_WAIT pour créer davantage de connexions, même si TCPTimedWaitDelay n'a pas encore expiré. TCPTimedWaitDelay a une plage de valeurs qui va de 30 à 300 secondes (0x1 E – 0x12C).
Dans le cadre de notre scénario, vous pourrez constater une légère amélioration des performances globales en appliquant ces modifications dans le registre. Vous pouvez également essayer de réparer le fichier TCPIP.sys en supprimant ces limites, mais ceci permet uniquement d'améliorer les applications P2P.

Captures réseau
Si vous ne parvenez toujours pas à résoudre les problèmes de connexion, l'exécution d'une capture réseau sur les ordinateurs en cause semble être une bonne solution. Lorsque j'ai exécuté Microsoft Network Monitor (Netmon), il a produit des captures qui reproduisaient exactement ce que je voyais dans les outils de gestion et les scripts de test : tout fonctionne, puis s'arrête, sans indication d'erreur.
La figure 2 affiche le résultat de Netmon, qui indique une communication réussie entre les n premiers systèmes. Vous pouvez constater que j'obtiens des accusés de réception des requêtes RPC. Il s'agit bien du résultat attendu, une communication bidirectionnelle réussie.
Figure 2 Communication réussie dans Netmon
Figure 2 Communication réussie dans Netmon
Vous allez maintenant examiner les captures du système de gestion et les ordinateurs distants qui semblent présenter l'erreur 53/1203. Comme vous pouviez vous y attendre, il n'y a rien à voir, car les ordinateurs ne communiquent pas. Dans la capture réseau de la figure 3, le système de gestion a résolu l'adresse IP et tente de se connecter au système sur le port 445 (le port SMB de Microsoft) sans jamais recevoir de réponse.
Figure 3 La tentative de connexion au système sur le port 445 n'obtient aucune réponse
Figure 3 La tentative de connexion au système sur le port 445 n'obtient aucune réponse
L'erreur que vous recevez lorsque vous disposez d'un nombre de threads supérieur au nombre de connexions possibles sur votre ordinateur n'est pas toujours cohérente. Dans certains cas, le système source renvoie une erreur 53, ce qui indique que vous avez reçu la résolution de nom, tandis que l'adresse IP reste introuvable. Ceci indique que DNS fournit une adresse à laquelle vous ne pouvez pas vous connecter. Vous pouvez recevoir une erreur 1203, ce qui indique qu'aucun ordinateur n'a répondu au nom ou à l'adresse IP que vous avez demandés. L'erreur 1203, dans ce cas, indique que DNS ne vous est pas disponible. Vous verrez que c'est le cas si vous exécutez nslookup.
À ce stade, vous sentirez sans doute une certaine frustration, mais il y a d'autres options à prendre en compte. La plupart des personnes ne pensent même pas à vérifier l'infrastructure de connexion, compte tenu de la manifestation du problème : votre ordinateur est le seul à ne pas pouvoir se connecter au réseau et les journaux d'événements indiquent que votre ordinateur a atteint le nombre maximum de connexions autorisées, ce qui semble écarter les problèmes d'architecture.
Alors que les milliers de connexions créées par votre solution de gestion ne s'activeront pas en même temps, les conservations de transmissions actives et les délais de connexions peuvent signifier que vous avez plus de connexions ouvertes en même temps que vous ne le pensez. Par conséquent, vous devez également examiner les systèmes qui se connectent au reste du réseau.
Je vais essayer de m'expliquer plus clairement. Comme je l'ai mentionné plus haut, lorsque le trafic transite sur le réseau, il passera par des commutateurs, des routeurs, voire des pare-feux. À tous ces points, généralement au niveau du routeur ou du pare-feu, vous risquez de rencontrer des systèmes de détection des intrusions. Les commutateurs et les routeurs gérés peuvent également filtrer le trafic. Vous, ou quiconque a le contrôle de ces périphériques, devez consulter les journaux afin de rechercher les erreurs ou les avertissements éventuels. Le problème de communication peut très bien provenir de l'un de ces systèmes.
Dans la mesure où vous vous connectez depuis un système interne vers d'autres systèmes internes, vous pourrez constater qu'aucune alerte n'a été déclenchée, car la fonctionnalité d'alerte n'est pas configurée sur le périphérique ou parce que le problème ne constitue pas une attaque par intrusion ou déni de service. Encore une fois, vous devez commencer par les journaux. En prenant ISA Server comme exemple, ces journaux figurent dans la console de gestion d'ISA Server sous Arrays\<ArrayName>Monitoring\Logging.
Si cette stratégie est à l'origine du blocage, vous pouvez (dans le cas d'ISA Server) rechercher les codes de résultat suivants où l'IP source correspond à votre ordinateur de gestion :
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
Si vous trouvez ces résultats, vous avez identifié l'origine de vos problèmes de connectivité.

Implémentation de la solution
Maintenant que vous avez identifié le problème, la solution peut être simple, avec comme seul obstacle les éventuels règlements du service dont vous dépendez. Avant d'apporter des modifications, assurez-vous que vous disposez d'autorisations adéquates, dans la mesure où la mise en place d'exclusions dans les configurations de sécurité de vos pare-feux, routeurs et/ou systèmes de détection d'intrusion ne sont pas toujours autorisés.
Toujours en prenant ISA Server comme exemple, les étapes suivantes indiquent comment augmenter le nombre maximal de connexions pour un hôte donné ou pour tous les ordinateurs du réseau (comme indiqué dans la figure 4). Ouvrez la console de gestion d'ISA Server et accédez à Arrays\<ArrayName>\Configuration\General\Configure Flood Mitigation Settings.
Figure 4 Augmentez le nombre maximum de connexions pour un hôte ou tous les ordinateurs avec ISA Server.
Figure 4 Augmentez le nombre maximum de connexions pour un hôte ou tous les ordinateurs avec ISA Server.
Les deux paramètres qui nous intéressent sont le nombre maximum de connexions TCP simultanées par adresse IP et le nombre maximum de requêtes TCP de connexion par minute par adresse IP. Le nombre maximum de connexions TCP simultanées par adresse IP est généralement défini sur une valeur qui serait suffisante en l'absence de toute gestion active, ce qui signifie qu'aucun ordinateur ne se connecte de façon active et rapide à des milliers d'autres ordinateurs. Dans ISA Server, la limite par défaut pour le nombre de connexions TCP simultanées est de 160. Le nombre maximal de demandes de connexions TCP par minute par adresse IP a été conçu pour limiter les dommages et la visibilité des analyses réseau. La limite par défaut est de 600 requêtes de connexion par minute par IP.
Comme indiqué plus haut, Windows préserve une connexion pendant une période par défaut de deux minutes, à condition que rien d'autre ne tente de maintenir la connexion active et même si cette connexion reste inutilisée. Ceci signifie que même si vous avez déjà géré avec succès un ordinateur et n'avez plus besoin de communiquer avec ce dernier, la connexion restera active. Cette connexion ouverte compte dans le total des connexions attribuées. Si vous répétez ce processus plus de 160 fois sans supprimer les connexions ainsi ouvertes, vous constaterez que toutes les tentatives de connexion seront refusées par votre routeur. Même si votre programme de gestion termine une session de façon dynamique, Windows peut très bien conserver la connexion dans un état time_wait en attendant que l'ordinateur cible consente à déconnecter la session.
Procédez à des ajustements sur les principaux suspects : nombre maximum de connexions TCP simultanées par adresse IP. Vous devez définir ceci de façon à ce que votre ordinateur de gestion puisse créer toutes les connexions nécessaires à la gestion de vos systèmes sans avoir à subir de refus d'accès. Cliquez le bouton Modifier près du paramètre et modifiez les valeurs.
L'invite suivante (voir la figure 5) comporte une case Limite qui représente la limite par défaut, qui s'applique à tous les clients. La limite Personnalisée s'applique à tous les ordinateurs, réseaux et ainsi de suite qui sont définis dans l'onglet Exceptions IP de la boîte de dialogue de prévention des attaques par saturation. Pour que chaque ordinateur puisse créer davantage de connexions, modifiez ensuite la valeur de Limite. Pour configurer l'exception uniquement sur votre ordinateur de gestion, réglez la limite Personnalisée et ajoutez votre ordinateur dans l'onglet Exceptions IP. Ceci est généralement préférable pour autoriser l'exception uniquement sur votre propre ordinateur.
Figure 5 Limite de connexion par défaut et limite de connexion personnalisée
Figure 5 Limite de connexion par défaut et limite de connexion personnalisée
Si vous souhaitez utiliser la limite personnalisée pour modifier cette valeur pour des systèmes spécifiques, modifiez la valeur du champ de limite Personnalisée, puis cliquez sur OK. Ajoutez ensuite votre ordinateur dans l'onglet Exceptions IP dans la boîte de dialogue de prévention des attaques par saturation. Pour ajouter votre ordinateur à la liste d'exceptions, dans la section Exceptions IP, cliquez sur Ajouter pour afficher la boîte de dialogue Jeux d'ordinateurs. Cliquez sur Nouveau pour créer un nouveau jeu réseau contenant votre ou vos systèmes si aucun jeu réseau contenant ces ordinateurs n'existe. Sélectionnez ce jeu réseau et cliquez sur Ajouter pour ajouter le jeu réseau Réseaux internes, puis cliquez sur Fermer. Sélectionnez à nouveau le réseau Réseaux internes, puis cliquez sur Modifier. Ceci ouvrira les propriétés de Réseaux internes voir la figure 6). Cliquez sur Ajouter dans cette boîte de dialogue pour afficher un sous-menu permettant d'ajouter un ordinateur, une plage d'adresses ou un sous-réseau. Choisissez la section ordinateur. Tapez un nom pour identifier l'entrée, l'adresse IP de l'ordinateur et une description, de telle façon que toute personne consultant cette entrée par la suite ne se sentira pas obligée par la suite de supprimer votre système (voir la figure 7). Cliquez sur OK pour ajouter votre système, puis cliquez à nouveau pour ajouter l'exception. Une fois ces modifications appliquées, vous devez appliquer les paramètres.
Figure 6 Propriétés des réseaux internes
Figure 6 Propriétés des réseaux internes
Figure 7 Entrez le nom d'ordinateur, l'adresse IP et la description pour vous assurer que le système n'est pas supprimé
Figure 7 Entrez le nom d'ordinateur, l'adresse IP et la description pour vous assurer que le système n'est pas supprimé
Exécutez à nouveau votre outil de gestion dynamique, qui devrait vous indiquer que les performances sont bien meilleures et que la connexion n'échoue pas, du moins pas à cause du trafic réseau. En résumé, le problème ne résidait pas dans le nombre de connexions établies par le logiciel, mais dans l'absence de planification adéquate de ces connexions.

Enseignements tirés
L'un des principaux casse-tête en informatique est la détection et la résolution de problèmes insaisissables. Il s'agit de problèmes que l'utilisateur final n'a pas créés, que l'équipe de serveur n'a pas causé, de problèmes que le centre d'assistance ne connaît pas, et, malheureusement, dont la résolution risque de vous incomber. Vous disposez de myriades d'outils pour vous aider à dépanner, isoler et résoudre des problèmes, mais parfois les outils ne suffisent plus. Parfois ils ont tort. Et parfois vous devez voir plus loin que ces outils.
Ainsi, si à l'avenir la connexion devient impossible entre plusieurs ordinateurs de votre réseau sans raison évidente, essayez les étapes que j'ai décrites ici. Il est alors fort probable qu'en suivant ces étapes, en examinant de plus près votre logiciel de gestion et en définissant les connexions admissibles correctement, vous résolviez le problème avec succès.

Christophe Stoneff est responsable de produit chez Lieberman Software (liebsoft.com), une société de développement de logiciels de gestion de la sécurité et de systèmes. Chris détient un nombre incroyable de certifications techniques. Ce qui le motive n'est pas tant de savoir comment les choses fonctionnent, mais pourquoi.


 Note de l'&#233;diteur: Que la conversation commence&#160;!
Note de l'éditeur
Que la conversation commence !
Joshua Hoffma

Pratiquement toutes les choses importantes qui se sont passées ont commencé avec une conversation.
« Je ne pense pas vraiment que le monde soit plat. Nous devrions essayer de vérifier ça, non » ?
« Pourquoi ne pas envoyer quelqu'un sur la lune » ?
« Puis-je vous parler de ma stratégie concernant ces nouveaux PC » ?
« Discutons-en autour d'une tasse de café ».
(Cette dernière option n'est pas importante, c'est juste que... j'adore le café ! Ceci dit, un bon café peut amener de bonnes idées !)
Ce mois-ci en tout cas, et en ce qui me concerne, l'idée que tout ce qui est important commence généralement avec une conversation est vraie pour deux raisons. La première est liée à une conversation qui se poursuit en ce moment, sur les blogs, dans les coulisses et même dans ce numéro de TechNet Magazine (voir la colonne Sur le terrain de Romi Mahajan, page 91). Il s'agit de la « consumérisation » de l'informatique. Le point central est que nous ne sommes pas uniquement des professionnels de l'informatique au travail. La réalité est que ce que nous faisons dans nos vies quotidiennes (volontariat, karaoké, jouer sur la Xbox) a un impact sur le travail que nous faisons et sur les décisions que nous prenons dans nos vies professionnelles. C'est une conversation que Romi et moi, et quelques invités spéciaux, poursuivrons lors d'une discussion intitulée « Le futur fongible », à la prochaine conférence Windows Connections de Las Vegas. J'espère que vous nous y rejoindrez en personne ou que vous consulterez le site Web WeWantToKnow.net. Et ne manquez pas de participer à la conversation sur notre blog à blogs.technet.com/tnmag car vos suggestions et commentaires nous intéressent !
La seconde raison est que je souhaite aborder la technologie que nous utilisons pour favoriser ces conversations. Dans le numéro de ce mois-ci de TechNet Magazine, nous parlerons des améliorations importantes qui ont été apportées à Exchange Server et qui vous permettent de rester connecté plus facilement, que vous soyez juste de l'autre côté de la rue ou à l'autre bout du monde. Nous vous montrerons les améliorations d'Exchange Server SP1, comment la fonctionnalité de réplication continue SCR (Standby Continuous Replication) peut améliorer de façon spectaculaire vos plans de récupération après incident, comment la plate-forme Exchange sera améliorée par Windows Server 2008 et comment la messagerie renforce la qualité de vos conversations. En guise de cadeau ce mois-ci, l'édition imprimée de TechNet Magazine inclut le dernier d'une série de posters extrêmement populaires des contributeurs Astrid McClean et Martin McClean. Vous avez peut-être vu leur poster puzzle du composant Active Directory® primé ou les posters de Windows Server 2008 qui ont été publiés ici par le passé. Ce mois-ci, ils s'attaquent à Exchange. Que la conversation commence ! —Joshua Hoffman

Remerciements aux experts techniques Microsoft suivants : Ed Banti, Anah Cameron, Chun Yong Chua, Cliff Didcock, Jeremy Kelly, Michael Murgolo, Jon Orton, Jeff Ressler, Kevin Sullivan, Jim Truher, Scot Vidican et Michael Wilson.

Joshua Hoffma


 Lettres: Les lecteurs ont la parole
Lettres
Les lecteurs ont la parole

Utilitaire PageDefrag
J'ai essayé d'exécuter l'utilitaire PageDefrag de SysInternals qui a été abordé dans votre numéro de septembre 2007. Malheureusement, il a échoué sous Windows Vista® x64, affichant l'erreur : « Make sure that you are an administrator. Error loading PageDefrag driver. »(Assurez-vous quie vous êtes un administrateur. Erreur lors du chargement du pilote de PageDefrag.).
—Alex D.

Pour le moment, l'utilitaire PageDefrag n'est pas pris en charge dans Windows Vista. Il fonctionne uniquement avec Windows NT® 4.0, Windows® 2000, Windows XP, et Windows Server® 2003. Nous nous excusons de ne pas avoir mentionné ce point dans l'article du mois de septembre.

Planificateur de sauvegarde
J'ai lu l'article « Guide des technologies de sauvegarde de Windows Vista » du numéro de septembre 2007 avec beaucoup intérêt, mais j'ai quelques questions à vous poser.La figure 2 de l'article affiche la date et l'heure de la prochaine sauvegarde. Comment cela est-il possible si l'outil de sauvegarde ne contient pas son propre planificateur ?
Dans la mesure où les modifications apportées aux blocs de disques servent à déterminer les éléments à sauvegarder, que se passe-t-il si une défragmentation de disque survient ? Cela entraînera-t-il la sauvegarde d'une grande quantité de données parce que les blocs ont été déplacés ou modifiés ? En outre, lors d'une restauration, si les blocs sont restaurés à leur emplacement original, quel est l'effet d'une défragmentation du disque sur cette restauration ?
—Bruce G.

Nous avons été à la source (l'auteur Christine Fok) pour éclaircir ce problème, et voici ce qu'elle nous a dit :
La figure 2 affiche la date et l'heure de la prochaine sauvegarde de fichiers et de dossiers, mais uniquement l'heure de la Sauvegarde de l'ordinateur la plus récente. Vous pouvez planifier une sauvegarde au niveau des fichiers/dossiers, mais, comme vous l'avez noté, la Sauvegarde de l'ordinateur ne contient pas son propre planificateur.
Vous avez raison de dire que l'exécution de Defrag entre deux exécutions de la Sauvegarde d'ordinateur pourrait rendre la seconde plus grande. Et votre observation concernant la restauration après la défragmentation est également correcte. La Sauvegarde de l'ordinateur fonctionne au niveau du volume, sous le système de fichiers. Elle remet chaque bloc exactement là où il était lors de la sauvegarde et aux mêmes emplacements sur le disque, que Defrag ait été exécuté depuis la sauvegarde ou pas. Il est donc possible que vous soyez obligé de défragmenter à nouveau le volume, une fois la restauration terminée.

Outil BGInfo
J'ai apprécié la rubrique Coup de projecteur sur les utilitaires du numéro d'août 2007. L'outil BGInfo de SysInternals qui recueille d'importantes informations sur le processeur et le réseau était exceptionnel. J'adore lire des articles sur des personnes qui développent un nouveau produit, utilitaire, programme ou application. M. Cogswell a-t-il développé d'autres produits logiciels pour Microsoft ?
—Daryl B.

Nous sommes contents de savoir que vous trouvez l'utilitaire BGInfo très utile ! Bryce Cogswell a créé plusieurs utilitaires très pratiques, généralement en collaboration avec Mark Russinovich, dans le cadre de Sysinternals. Heureusement, Microsoft a acquis Sysinternals en 2006, et MM Cogswell et Russinovich travaillent maintenant avec nous. Vous trouverez tous leurs utilitaires sur le site Web de Sysinternals à l'adresse microsoft.com/technet/sysinternals.

RPC et pare-feu
L'article « Dépannage d’erreurs RPC » du numéro de juillet 2007 était très utile mais a oublié de mentionner un point très important : le Pare-feu Windows peut également causer des erreurs RPC. Si le Pare-feu Windows est configuré pour autoriser les requêtes PING mais pas les messages entrants non sollicités, toute tentative visant à gérer une machine à distance est alors vouée à l'échec. Si vous exécutez RPCPING.exe à partir du kit de ressources de Windows, l'erreur renvoyée est 1722 (le serveur RPC n’est pas disponible).
Dans ce cas, le pare-feu fait exactement ce qu'il est supposé faire : il empêche les personnes de l'extérieur d'accéder à un système donné. Malheureusement, il donnera également des crises de nerfs aux administrateurs lorsque ces derniers essaient de gérer des ordinateurs sur un réseau d'entreprise.
—Aaron M.

Merci de nous signaler une autre source potentielle de problèmes RPC. Nous espérons que les outils mentionnés dans l'article contribueront à résoudre ces problèmes.

Licences Windows XP
La rubrique Sur le terrain d'octobre 2007 mentionnait la possibilité d'acheter des licences pour Windows XP pour 5 USD seulement. Nous sommes une maison d'édition à but non lucratif, et nous nous demandons comment obtenir ces licences. Pouvons-nous le faire par téléphone ou par courrier électronique ? J'ai une messagerie électronique, mais je n'ai pas d'accès à Internet.
—Ernest B.

Vous pouvez contacter le partenaire administratif MAR, TechSoup, à communitymar@techsoup.org ou appeler le 800-659-3579, poste 350. Vous pouvez également écrire à : Community MAR Administrator, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107.


 Bo&#238;te &#224; outils: Nouveaux produits pour les professionnels de l’informatique
Boîte à outils
Nouveaux produits pour les professionnels de l’informatique
Greg Steen

Surveillance des systèmes de réseau
ActiveXperts Network Monitor
activexperts.com
Lorsque vous êtes administrateur système, il vaut mieux savoir que quelque chose se passe mal avant que vos utilisateurs ne commencent à sortir la tête de leurs box tels une meute de chiens de prairie étonnés. La surveillance des services est essentielle pour la gestion proactive de votre infrastructure. ActiveXperts Network Monitor est une solution robuste incluant plusieurs vérifications qui s'exécutent sur votre réseau WAN/LAN et vos serveurs Windows®, Novell et *NIX pour vous permettre d'avoir connaissance des problèmes avant que vos utilisateurs ne vous les signalent.
ActiveXperts Network Monitor est une application basée sur Windows qui s'exécute en tant que service sur l'ordinateur que vous avez désigné comme poste de surveillance. Le système d'exploitation de base sur cet ordinateur peut être Windows 2000, Windows Server® 2003, Windows XP ou Windows Vista®. Après l'installation, un Assistant de configuration rapide vous guide tout au long de la configuration des notifications par courrier électronique, des notifications par SMS et de la fréquence d'analyse par défaut ou du seuil de défaillance. Vous pouvez également ajouter une série d'exemples de vérifications que vous pouvez utiliser comme exemples dans votre configuration. Ils sont très utiles pour vous permettre d'être rapidement opérationnel, et vous montrent les principes fondamentaux de la configuration des différentes fonctionnalités de l'application pour l'adapter aux besoins de votre environnement.
L'application est divisée en trois composants : Network Monitor Engine est le service Windows qui exécute en continu vos tâches de surveillance. Network Monitor Manager est une application Windows vous permettant de visualiser l'activité actuelle du moniteur, de consulter les résultats des tâches et de modifier votre configuration. Une interface Web vous offre un accès en lecture seule aux résultats des tâches et aux tâches mêmes.
Outre l'exécution des contrôles de surveillance, Network Monitor Engine gère également les notifications, les actions déclenchées par les résultats et les sessions de l'application. Le moteur de surveillance est multithread, ce qui lui permet de s'adapter à votre environnement. Le service ne nécessite pas d'agent de point de terminaison pour exécuter ses contrôles de surveillance, mais cela signifie que vous devrez fournir des informations d'identification administratives pour surveiller les serveurs ou les postes de travail Windows distants. Heureusement, vous pouvez spécifier plusieurs jeux d'informations d'identification, si bien que la surveillance sur différents domaines et contextes de sécurité ne nécessite pas un compte unique doté de tous les privilèges.
Vous passerez probablement la majeure partie de votre temps dans Network Monitor Manager, qui vous confère un contrôle granulaire sur toutes les fonctions, tous les paramètres de configuration et toutes les fonctionnalités. Vous pouvez organiser vos tâches de surveillance dans une structure d'arborescence de dossiers, ce qui vous permet de situer et d'identifier les éléments plus rapidement dans les environnements de grande taille, ainsi que de filtrer l'affichage actuel de l'interface utilisateur pour obtenir une vue d'ensemble rapide sur un ensemble de tâches de surveillance.
L'ajout d'un nouveau contrôle de surveillance est simple. Network Monitor comprend près de 40 vérifications pré-définies, notamment des vérifications IP et de protocoles (tels qu'ICMP, LDAP, SMTP et HTTP), des vérifications de Windows (telles que le processeur, les processus, la mémoire et les vérifications Terminal Server), la connectivité ODBC, Oracle TnsPing, les vérifications de base de données basées sur les requêtes OLEDB, les vérifications d'appartenance de Novell et les vérifications RSH de *NIX. De plus, vous pouvez surveiller des données environnementales (comme la température et l'humidité) en utilisant un moniteur d'environnement SensaTronics sur votre réseau.
L'application prend en charge les scripts VBScript et Remote Shell personnalisés, ce qui vous permet d'adapter les tâches de surveillance. Un jeu de modèles VBScript inclus avec l'application permet de contrôler les divers services, tels que l'antivirus, Microsoft® ISA Server et les requêtes XML. Vous disposez donc de quelques éléments de base pour créer vos tâches de surveillance personnalisées.
Vous pouvez définir la fréquence de vérification et le seuil de défaillance pour chaque tâche, et vous pouvez planifier l'exécution des vérifications à un jour et à une heure spécifiques lorsque vous souhaitez, par exemple, vérifier les résultats de certains autres processus en cours d'exécution, tels qu'une tâche d'archivage des ouvertures de session ou une réinitialisation de pool d'applications IIS. Vous pouvez également spécifier l'exécution de tâches de fichiers exécutables, de script et de traitement par lots lorsqu'une vérification échoue ou reprend, ou prévoir un redémarrage ou une réinitialisation pour un service spécifié. Enfin, l'interface Web vous offre une vue convertie en XSL des données de résultat au format XML. Les feuilles de style peuvent être facilement modifiées pour créer un affichage personnalisé pour votre Centre d'opérations réseau ou votre périphérique mobile et, puisque les données sont au format XML, vous pouvez les récupérer facilement pour les utiliser dans une autre application ou système collectif.

Prix : 395 USD, prix de départ en vente directe pour une licence de cinq serveurs.
ActiveXperts Network Monitor inclut des exemples de vérifications pour vous aider à démarrer
ActiveXperts Network Monitor inclut des exemples de vérifications pour vous aider à démarrer

Critique
Windows Vista Resource Kit
microsoft.com/mspress/books/9536.aspx
Dans la mesure où de plus en plus d'organisations commencent à intégrer des clients Windows Vista à leur infrastructure, les professionnels de l'informatique doivent connaître les outils disponibles dans le nouveau système d'exploitation. Récemment publié, Windows Vista Resource Kit (Microsoft Press®, 2007) traite une bonne partie des informations et des outils dont vous aurez besoin pour implémenter avec succès les clients Windows Vista dans votre entreprise. Tout y est, de l'automatisation de l'installation et de l'activation en volume à la gestion et la maintenance des ordinateurs de bureau, en passant par l'utilisation des réseaux IPv6 et l'assistance à distance. Outre ses 1 568 pages, ce livre inclut également un DVD de support contenant plus de 100 scripts utiles pour l'administration et le déploiement, un jeu d'outils de débogage, Solution Accelerator for Business Desktop Deployment (BDD) et d'autres petites choses utiles.
Commençant par un aperçu général des nouvelles fonctionnalités de Windows Vista, le livre met l'accent sur les améliorations de la sécurité, telles que le Contrôle de compte utilisateur, le chiffrement de lecteur BitLocker et la Prévention de l'exécution des données. Il aborde également le concept de renforcement des services et de la protection contre les modifications du code du noyau. De là, il passe au déploiement de Windows et détaille les nombreux outils disponibles pour automatiser le processus. Par exemple, le livre explique comment configurer un environnement de préinstallation et de récupération Windows PE 2.0 et plonge dans BDD 2007, qui fournit des aides pour la planification et le déploiement de Windows Vista dans l'entreprise. De plus, il contient des pratiques recommandées pour la création et la configuration d'images de disque, et présente une discussion instructive sur la façon de migrer les données utilisateur à l'aide de Windows Easy Transfer et de l'outil de migration de l'état des utilisateurs (USMT)
Le livre décrit ensuite en détail comment gérer l'environnement de postes de travail à l'aide de la stratégie de groupe, en s'attardant sur les nouveaux fichiers de modèle d'administration (ADMX) basés sur XML. Il traite également la gestion des disques et des systèmes de fichiers et présente les nouvelles améliorations ReadyBoost et BitLocker de Windows Vista. Il explique le fonctionnement des fonctionnalités Versions précédentes, Clichés instantanés et de quotas de disque, puis s'intéresse au déploiement et à la gestion de l'Espace de collaboration Windows dans les groupes de travail, les domaines et les environnements sans fil ad hoc.
La section relative à la maintenance des postes de travail traite les tâches, Rapports d'erreur Windows, la surveillance des performances et les événements Windows. Elle explique également comment vous pouvez utiliser l'Assistance à distance pour votre support technique. La discussion s'attache ensuite aux mises à jour logicielles, au Service de transfert intelligent en arrière-plan et à Windows Update, de même qu'aux outils d’audit.
La section sur les réseaux détaille le fonctionnement du Pare-feu Windows et explique les nouvelles améliorations apportées à la pile réseau. Elle examine également l'utilisation des connexions de Bureau à distance et VPN pour configurer des utilisateurs et des réseaux à distance.
Enfin, le livre vous donne des indications relativement complètes sur le dépannage de problèmes, allant du démarrage sur le réseau, aux erreurs de pilotes et aux problèmes de périphériques. Si l'on sent de temps en temps planer un léger parfum de marketing, il ne s'agit en aucun cas de 1 500 pages de blabla. Il s'agit d'une discussion approfondie et complète sur Windows Vista, ses outils et la gestion du système d'exploitation.

Prix :59,99 USD en vente directe.

Analyser le trafic HTTP
Charles Web Debugging Proxy
xk72.com/charles
Si on considère l'abondance des communications basées sur le HTTP entre les applications et entre vos postes de travail, serveurs et Internet, un bon analyseur de trafic HTTP est un outil incroyablement utile pour les administrateurs systèmes. Il peut vous aider à identifier les problèmes de proxy, les problèmes de sécurité, les erreurs de connectivité, les problèmes de configuration et les problèmes de communication entre les applications. J'affectionne particulièrement l'application Java de Karl von Randow, Charles Web Debugging Proxy.
Á l'instar d’autres proxys de débogage, l'application elle-même se positionne comme « l'intermédiaire », elle se place entre les applications de point de terminaison, interceptant et interprétant le trafic qu'elle voit. Grâce à cette configuration, l'application vous permet également d'afficher le trafic HTTPS chiffré dans sa forme déchiffrée en texte brut. L'interface utilisateur offre une vue claire de la session enregistrée et vous fournit de nombreuses informations, des requêtes basiques d'accès à des pages, des images, des scripts et des feuilles de style, à des détails plus précis sur la taille, la latence et l'horodatage. Vous pouvez également voir quels cookies sont envoyés et reçus à chaque requête et leur contenu ; vous pouvez même choisir de bloquer tous les cookies en bloc.
Vous pouvez dépanner les problèmes de mise en cache des requêtes avec Charles Web Debugging Proxy en vérifiant les dates des dernières modifications sur les réponses « 304 Not Modified » ou en choisissant de désactiver la mise en cache en supprimant les en-têtes liés au cache des requêtes et des réponses pertinentes lorsque ils parcourent l'application. En fait, grâce aux paramètres de réécriture de l'application, vous pouvez définir une série de règles qui récrivent un certain nombre d'en-têtes HTTP ou de contenus de corps de texte lorsque les requêtes et les réponses passent par l'application. Vous pouvez même utiliser les paramètres d'usurpation de DNS de l'application pour remplacer l'adresse IP d'un hôte, ce qui vous permet de tester des requêtes à des éléments qui ne peuvent ne pas être enregistrés dans le DNS. Cette fonctionnalité très utile pour tester, par exemple, un nouveau serveur Web pour s'assurer qu'il écoute et répond correctement à l'en-tête d'hôte avant d'être mis à la disposition des utilisateurs.
Vous pouvez également utiliser cet outil pour déboguer les requêtes et les réponses AJAX et observer les données XML brutes dans la réponse. Dans l'interface utilisateur, vous pouvez même voir les données brutes de requête et de réponse dans le texte pour repérer plus facilement les en-têtes étranges.
L'outil propose deux mises en page des données très agréables qui vous donnent vraiment une bonne vision de la transaction de données : le tableau Summary et le tableau Chart. Le tableau Summary vous permet d'analyser rapidement les données de requête/réponse, en affichant la taille des en-têtes, la taille du corps, le temps de réponse, le code de réponse, le type MIME et la ressource. Le tableau Chart, quant à lui, fournit une chronologie de cycle de vie graphique qui montre où les données de requête/réponse sont apparues dans la séquence et la durée de la transaction.
Vous pouvez sauvegarder vos sessions d'enregistrement pour les relire et les analyser ultérieurement. Cela peut être utile pour capturer le flux complexe de requêtes/réponses qui provoque des erreurs de communication sporadiques ; une fois que vous l'avez, vous pouvez le reproduire. Vous pouvez même importer les fichiers de suivi HTTP dans une nouvelle session, ainsi qu'exporter la session actuelle sous CSV ou au format de suivi HTTP.
Pour les simulations de requête à des bandes passantes réduites (par exemple, pour essayer de découvrir pourquoi une requête échoue sur une ligne modem de 56 k mais pas sur votre réseau d'entreprise), l'application offre une fonctionnalité de limitation de la bande passante qui vous permet de choisir parmi une série de valeurs prédéfinies courantes ou de définir une nouvelle valeur basée sur quatre points de limitation : la bande passante, l'utilisation en pourcentage, la latence de boucle et l'unité de transfert maximale. Vous pouvez également configurer le proxy de débogage pour servir de proxy inversé ou de port redirecteur, en reliant un port local à un point de terminaison (et un port) distant de sorte que tout le trafic envoyé à ce port soit redirigé à l'adresse distante.

Prix : 50 USD, prix de départ en vente directe pour une licence utilisateur.
Charles Web Debugging Proxy analyse le trafic HTTP
Charles Web Debugging Proxy analyse le trafic HTTP

Nettoyage des fichiers inutiles
Wise Disk Cleaner 2
wisecleaner.com
Un disque dur est un peu comme une maison : les choses s'y accumulent progressivement au fil du temps, des choses que vous n'avez pas vraiment besoin de garder. De temps à autre, il est judicieux de prendre un moment pour faire un nettoyage de printemps. Il existe quelques méthodes standard pour nettoyer un disque dur avec les outils intégrés dans Windows, tels que l'outil système Nettoyage de disque et la fonctionnalité de recherche. Mais parfois, un utilitaire rapide et facile à utiliser constitue la meilleure option, surtout lorsque vous pouvez l'obtenir gratuitement. C'est le cas de Wise Disk Cleaner 2, qui recherche sur vos disques durs ces satanés fichiers poussiéreux qui peuvent être supprimés en toute sécurité de votre système.
Une chose que j'aime vraiment dans cet outil est qu'il vous présente tous les fichiers qu'il trouve dans l'interface utilisateur, ce qui permet de repérer facilement les problèmes potentiels. Autre fonctionnalité sympathique, il vous permet d'ajouter facilement des modèles de fichiers supplémentaires à vérifier et à supprimer. Wise Disk Cleaner nettoiera également vos fichiers Internet temporaires si vous le souhaitez, et vous pouvez choisir de conserver des cookies pour ne pas perdre pas les préférences de site qu'ils pourraient contenir. Vous pouvez également supprimer les fichiers de désinstallation Windows Update, ou désactiver la source Windows Update, la liste des fichiers récents et les dossiers temp de Windows et de l'utilisateur. Vous pouvez même exécuter automatiquement l'application, en configurant l'outil pour supprimer les éléments définitivement ou simplement les transférer dans votre Corbeille. L'application consigne également ses propres activités pour pouvoir les consulter plus tard, pas mal pour un outil gratuit.

Prix : Gratuit.
Wise Disk Cleaner 2 recherche les fichiers que vous pouvez supprimer en toute sécurité
Wise Disk Cleaner 2 recherche les fichiers que vous pouvez supprimer en toute sécurité

Gestion des périphériques réseau
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
Si vous utilisez des périphériques réseau, applications ou systèmes compatibles SNMP dans votre infrastructure, iReasoning Networks MIB Browser vous permet de charger un ensemble de fichiers MIB ( iReasoning Networks MIB Browser) et de parcourir une structure hiérarchique dans un affichage très similaire à l'Explorateur Windows. Vous pouvez y voir les détails de l'objet sélectionné, notamment l'identificateur d'objet (OID), la syntaxe, l'accès en lecture/écriture et la description.
Vous pouvez facilement émettre une requête SNMP pour récupérer les données d'un périphérique réseau à l'aide de l'interface utilisateur. Tapez simplement l'adresse IP du périphérique, sélectionnez l'objet MIB et cliquez sur Go. Si nécessaire, vous pouvez également définir le port, la version de requête SNMP et les chaînes de communauté de lecture et d'écriture. Il est tout aussi simple de modifier un agent (à supposer que votre périphérique le permette). Sélectionnez simplement l'OID, le type de données et la valeur, puis cliquez sur OK. En outre, un utilitaire Trap Sender et Trap Receiver (Capturer l'émetteur et Capturer le destinataire) incorporé vous permet d'émettre des interruptions et d'observer l'activité d'interruption (sur laquelle vous pouvez appliquer des filtres pour rendre le périphérique concerné plus visible).
iReasoning Networks MIB Browser Personal Edition est gratuit, mais il ne prend pas en charge SNMPv3 et est limité au chargement simultané de cinq fichiers MIB. Vous pouvez envisager d'acquérir l'édition professionnelle (à 269 USD par licence en vente directe), qui comprend des fonctionnalités supplémentaires et prend en charge SNMPv3, la découverte de réseau et la comparaison de périphériques.

Prix : Gratuit.
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

Greg Steen est un professionnel passionné de technologies constamment à la recherche d'outils et de méthodes permettant de simplifier et d'optimiser les tâches de développement pour les professionnels de l'informatique.


 Forum aux questions sur SQL&amp;: Configuration de la m&#233;moire, profilage des performances, d&#233;finition du facteur de remplissage, et bien plus encore
Forum aux questions sur SQL&
Configuration de la mémoire, profilage des performances, définition du facteur de remplissage, et bien plus encore
Par Nancy Michell

Configuration de la mémoire
Conseil : Création simplifiée de profils
Saviez-vous que vous pouvez désormais corréler PerfMon avec le générateur de profils de SQL Server 2005 ?
Peut-être avez-vous remarqué des pics d'utilisation du processeur, une consommation excessive de la mémoire ou des performances insuffisantes sur l'Analyseur de performances de votre ordinateur SQL Server et vous êtes demandé à quoi étaient dues ces anomalies de performance. Avant SQL Server 2005, vous deviez utiliser le générateur de profils pour capturer une trace, puis consulter les processus système dans Enterprise Manager et enfin capturer les journaux de l'Analyseur de performances, qui, bien sûr, nécessitaient l'activation de PerfMon. Et après tout ce travail avec tous ces outils, vous deviez encore réconcilier manuellement les événements entre les différents outils pour essayer de comprendre la source de cette perte de performances. Et pour cela, il n'y avait qu'une solution possible : passer au crible les différents journaux. Il s'agissait vraiment une tâche ingrate, mais indispensable pour identifier de façon sûre vos problèmes de performances.
Avec SQL Server 2005, vous devez toujours conserver une trace et examiner les journaux PerfMon, mais le générateur de profils vous permet désormais de les joindre. Vous pouvez parcourir vos instructions T-SQL et le générateur de profils affichera automatiquement, de façon graphique, ce qui s'est produit. Si vous cliquez sur l'interface utilisateur de l'Analyseur de performances dans le générateur de profils, vous accédez directement à l'instruction qui correspond à cet horodatage. Ceci permet de gagner beaucoup de temps en termes de dépannage de l'environnement SQL Server.
Voyons comment joindre des journaux PerfMon au générateur de profils :
  1. Lancez l'Analyseur de performances et commencez à capturer les informations à partir du serveur de base de données.
  2. Créez un journal de comptage dans la section Journaux et alertes de performance et nommez ce nouveau journal.
  3. Ajoutez de nouveaux compteurs, tels que % Temps processeur. Vous pouvez également faire débuter la journalisation de façon manuelle ou planifiée à l'aide de l'onglet Planifier.
  4. Cliquez sur OK et, si vous avez retenu l'option manuelle, lancez la journalisation.
  5. Associez une trace à votre instance de SQL Server à l'aide du générateur de profils. Pour ce faire, cliquez sur Nouvelle trace dans le menu Fichier. Incluez l'heure de début et l'heure de fin dans votre trace, puis donnez-lui un nom et configurez-la de façon à l'enregistrer dans un fichier. Enfin, vous devez simuler une certaine activité de transactions sur votre serveur, puis arrêter la capture des données de l'Analyseur de performances et du générateur de profils.
  6. Dans le générateur de profils, sélectionnez Importer les données de performances dans le menu Fichier. Ensuite, choisissez l'emplacement où vous avez enregistré le journal PerfMon et sélectionnez Fichier | Ouvrir | Trace. Enfin, sélectionnez l'emplacement où vous avez enregistré la trace du générateur de profils.
Une fois cette opération terminée, il sera plus facile de comprendre les effets que certaines instructions SQL ont sur le temps de traitement.

Q J'essaie de déterminer la meilleure configuration mémoire pour mes zones SQL Server™. L'administrateur qui m'a précédé a configuré Boot.ini sur chaque ordinateur pour utiliser 12 Go de RAM sur un cluster à deux nœuds de SQL Server 2000 de la façon suivante : Yes /PAE NO /3GB (aucun paramètre AWE défini pour SQL Server). Avec 12 Go de RAM disponibles, dois-je supprimer l'option /3GB de Boot.ini, activer AWE et accorder à SQL Server environ 10 Go sur les 12 Go disponibles ? Les ordinateurs qui exécutent SQL Server ne comportent rien d'autre, donc aucune autre application ne nécessite de la mémoire.
R Oui, vous devez activer les extensions AWE (address windowing extension) et réserver la majeure partie de la mémoire vive à SQL Server. 10 Go me semble une valeur raisonnable pour une zone SQL Server dédiée de 12 Go. (L'affectation préalable est uniquement valide sous SQL Server 2000. À partir de SQL Server 2005, l'utilisation d'AWE n'est plus statique et peut être modifiée à la volée). L'utilisation conjointe des options /3GB et /PAE par rapport à la simple utilisation de l'option /PAE, qui est la seule à être requise, a toujours soulevé de grands débats. Seuls les paramètres /PAE et AWE doivent être activés. Cependant, je suggère d'utiliser les deux commutateurs parce que certains facteurs sont à prendre en considération.
Le paramètre /3GB dépend de votre situation. Êtes-vous à cours de zones de mémoire MemToLeave qui doivent figurer dans les 2 ou 3 premiers Go d'espace d'adressage virtuel ? Si vous activez ce paramètre, consommez-vous la mémoire du système d'exploitation ? (Voir support.microsoft.com/kb/316739 pour plus de détails.) Si vous traitez un cluster, vous pouvez définir /3GB sur un nœud et rien sur l'autre. De cette façon, si vous procédez à un test avec /3GB et subissez des problèmes, vous pouvez relayer l'instance sur l'autre nœud très rapidement. N'oubliez pas que si vous avez plus de 16 Go de mémoire vive, le paramètre /3GB n'est pas pris en charge.
Avec /3GB, vous augmentez l'espace d'adressage virtuel (VAS) de 50 %. Par conséquent, les applications qui contribuent à la pression de mémoire sur VAS et non pas seulement sur le cache de données en bénéficient le plus. Heureusement, les serveurs 64 bits, IA64 et x64, éliminent ce facteur mal compris. Les risques de consommation de la mémoire du système d'exploitation ne s'appliquent que si l'ordinateur est dédié à SQL Server. Le fait de ménager 2 Go pour le système d'exploitation reviendrait à tomber dans l'excès inverse. Si le serveur est dédié à SQL Server avec uniquement les services minimaux standard du système d'exploitation, vous pourrez constater que le serveur dispose d'environ 1,3 Go de mémoire libre sur le serveur. Dans ce cas, il est plus intéressant d'accorder 1 Go supplémentaire à SQL Server. Commencez à 10 Go, utilisez PerfMon pour contrôler la mémoire disponible pendant une longue période pour déterminer la partie inactive, puis réglez-la en conséquence. Tenez compte du fait que vous subirez un fort taux d'échange de pages si vous réservez trop de mémoire sous SQL Server 2000, car AWE n'est pas aussi dynamique que sous SQL Server 2005. Pour déterminer si le paramètre /3GB doit être utilisé, il est essentiel de le tester dans votre environnement.

Noms d'instance pour la réplication
Q Puis-je désormais utiliser l'adresse IP de mon serveur lors de la réplication de SQL Server 2005 pour indiquer l'instance à répliquer ? Sous SQL Server 2000, selon « Réplication entre les ordinateurs exécutant SQL Server dans les domaines non approuvés ou sur Internet » (support.microsoft.com/kb/321822), ceci entraînerait des erreurs, mais je ne sais pas si c'est toujours vrai.
R Lors de la spécification des instances de serveur qui doivent participer à la réplication, vous devez fournir le nom d'instance enregistré de SQL Server. Par exemple, vous devez utiliser le nom d'instance de SQL Server lors de la spécification des paramètres Publisher ou Subscriber dans les procédures de réplication stockées ou dans les paramètres de connexion de l'agent de réplication sur la ligne de commande. Si le nom réseau de l'instance de SQL Server diffère du nom d'instance inscrit, les connexions de réplication des agents échoueront.
Si le nom de réseau de l'instance et le nom d'instance de SQL Server diffèrent, envisagez d'ajouter le nom d'instance de SQL Server en tant que nom réseau valide. L'une des façons de définir un autre nom réseau consiste à l'ajouter au fichier des hôtes locaux. Le fichier des hôtes locaux se trouve par défaut dans WINDOWS\system32\drivers\etc ou WINNT\system32\drivers\etc. Par exemple, si le nom d'ordinateur est comp1, l'ordinateur a une adresse IP de 10.193.17.129 et le nom d'instance est inst1/instname, ajoutez l'entrée suivante dans le fichier d'hôte :
10.193.17.129 inst1

SQL Server Integration Services
Q Je suis en train d'installer un cluster actif/actif pour SQL Server 2005 (Edition Enterprise 64 bits avec deux serveurs) et j'aurai un total de quatre instances de SQL Server 2005. SQL Server Integration Services (SSIS) sera nécessaire pour toutes les instances. Que pouvez-vous me dire sur la mise en cluster SSIS et son effet sur les plans de maintenance ?
R Il est certes possible de mettre en cluster le service SSIS, mais ceci n'est pas nécessaire et vous risquez de subir différents problèmes, notamment l'absence de prise en charge de la délégation (voir msdn2.microsoft.com/aa337083) et d'instances multiples. Vous ne pouvez avoir qu'une seule instance en cours d'exécution par nœud.
Auparavant, SSIS devait être installé, pas exécuté mais simplement installé, pour que l'Assistant de plan de maintenance puisse s'exécuter. Ce n'est toutefois plus le cas dans SQL Server 2005 SP1. Si SSIS ne s'exécute pas, les plans de maintenance peuvent être exécutés par l'agent SQL Server.
Au lieu de mettre SSIS en cluster, vous pouvez envisager de le faire fonctionner en tant que service autonome et de modifier MsDtsSrvr.ini.xml pour pointer vers toutes les instances en cours d'exécution. Ceci vous permet de gérer vos packages à partir de n'importe quel nœud et d'offrir le niveau de disponibilité attendu par la plupart des clients, sans subir les problèmes associés à la mise en cluster du service.
Pour plus d'informations sur les échecs de création de plan de maintenance, consultez l'article de la base de connaissances à l'adresse support.microsoft.com/kb/909036.

Temps d'exécution étranges
Q Pendant mon test de chargement sur ma zone SQL Server 2005 SP1, SQL Server Profiler a enregistré de nombreuses valeurs négatives pour le temps d'exécution de procédure stockée et dans certains cas, le temps d'exécution de procédure stockée ne concordait pas avec le résultat de la soustraction de l'heure de démarrage de l'heure de fin.
R Différents facteurs peuvent affecter la création de rapports sur le temps d'exécution de procédure stockée et autres temps de performance dans SQL Server Profiler. Tenez compte du fait que SQL Server 2005 comptabilise le temps d'exécution en millisecondes, et que si vous utilisez des technologies qui modifient l'unité de mesure, vous obtiendrez des rapports incohérents et des temps d'exécution incorrects.
Par exemple, si vous utilisez d'autres profils d'alimentation, une autre version de processeur ou la technologie AMD Cool 'n Quiet, vous modifiez les fréquences du processeur, qui ne correspondent plus à ce que SQL Server Profiler attend lors du calcul de l'heure d'exécution.
Un article de la base de connaissances, support.microsoft.com/kb/931279, explique les symptômes, différentes causes et certaines solutions.
Conseil : Vérifiez votre facteur de remplissage
Supposons que vous avez verre rempli d'eau et que vous tentez d'y verser un peu plus d'eau. Que se passe-t-il ? L'eau déborde.
La même chose se produit avec SQL Server. Lorsqu'une nouvelle ligne est ajoutée à une page d'index déjà complète, SQL Server déplace la moitié des lignes vers une nouvelle page pour faire de la place à la nouvelle. Cette opération est appelée « fractionnement de page ». Ce processus ménage de la place pour les nouveaux enregistrements, mais il prend du temps et consomme beaucoup de ressources. En outre, il peut provoquer des fragmentations, ce qui peut avoir un impact négatif sur les opérations d'E/S. Comment puis-je l'éviter ?
Pour éviter ce genre de situation, vous devez déterminer de façon dynamique la valeur du facteur de remplissage. Lorsqu'un index est créé ou est reconstitué, la valeur du facteur de remplissage détermine le pourcentage d'espace sur chaque page de niveau feuille à remplir avec des données, en réservant le reste pour la croissance future. Par exemple, la configuration d'un facteur de remplissage de 60 signifie que 40 % de chaque page de niveau feuille reste vide afin de pouvoir prolonger l'index au fur et à mesure que des données sont ajoutées dans la table sous-jacente.
La valeur par défaut du facteur de remplissage est toujours 0, ce qui est correct dans la plupart des cas. En fait, un facteur de remplissage de 0 signifie que le niveau feuille est rempli à son maximum, mais une partie de l'espace est conservé pour au moins une ligne d'index supplémentaire. (Les facteurs de remplissage 0 et de 100 sont semblables.)
Vous pouvez définir la valeur du facteur de remplissage pour les index pendant l'exécution d'une instruction CREATE INDEX ou ALTER INDEX, ou vous pouvez configurer cette valeur directement au niveau du serveur de façon à ce que tous les nouveaux index créés utilisent la valeur par défaut.
L'exemple suivant définit la valeur du facteur de remplissage au niveau du serveur sur 70 %, ce qui signifie que vous disposez de 30 % d'espace libre pour les expansions. Naturellement, vous devez tester en détail cette option avant de l'implémenter dans un environnement de production.
USE Master;
GO
SP_Configure 'show advanced options',1;
GO
SP_Configure 'Fill Factor', 70;
GO
--You must restart SQL Server Engine for changes to take effect.
Que se passe-t-il si vous souhaitez configurer le facteur de remplissage au niveau des index individuels ? Supposons que vous créez la table suivant et souhaitez mettre en place un index unique sur la colonne Col_A avec une valeur de remplissage de 70. La commande se présentera de la façon suivante :
--Create an Item table
USE Item_DB;
GO
CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200));
GO;

--Create a unique index on colum Col_A of Item table with a Fill Factor value of 70
CREATE UNIQUE INDEX AK_Index ON Item (Col_A)
WITH (FillFactor = 70);
GO
Comment pouvez-vous identifier le facteur de remplissage de chaque index ? Vous pouvez interroger sys.index pour obtenir la valeur du facteur de remplissage pour tous les index d'une base de données, de la façon suivante :
USE Item_DB;
GO
SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL;
GO


 Coup de projecteur sur les utilitaires: Outil Microsoft Security Assessment Tool
Coup de projecteur sur les utilitaires
Outil Microsoft Security Assessment Tool
Lance Whitney
Télécharger le code de cet article: Microsoft Security Assessment Tool 3.0 (en anglais uniquement) (10547.2KB)

Le dépistage des problèmes de sécurité réseau peut être difficile et prendre beaucoup de temps. L'outil Microsoft® Security Assessment Tool (MSAT) a été conçu précisément pour tenter d'identifier et d'éliminer les risques de sécurité. Cet utilitaire gratuit présente un questionnaire électronique qui décrit votre environnement de sécurité. Conçu pour les organisations de taille moyenne comptant entre 50 et 500 ordinateurs, ce questionnaire regroupe 172 questions réparties dans des catégories différentes, puis offre une analyse de votre situation et des recommandations susceptibles de l'améliorer.
Le questionnaire commence par une série de questions sur votre modèle d'entreprise, qu'il utilise pour créer un profil de risques métier (BRP) qui évalue vos risques de sécurité par rapport aux entreprises comparables de votre secteur. Ce questionnaire prend généralement deux heures à compléter, et vous pouvez vous interrompre et le reprendre à volonté. Voici les principales catégories avec des exemples de questions :
Informations de base Combien de clients et de serveurs votre organisation compte-t-elle ?
Sécurité de l'infrastructure Vos employés travaillent-ils à distance ? Des fournisseurs externes accèdent-ils à votre réseau ?
Sécurité des applications Votre entreprise développe-t-elle des applications ? Conserve-t-elle les données confidentielles traitées par vos applications ?
Sécurité de l'exploitation Votre réseau d'entreprise se connecte-t-il à des réseaux externes ? Votre organisation reçoit-elle des flux de données provenant de tiers ?
Sécurité des personnes Votre entreprise externalise-t-elle la maintenance informatique ? Autorisez-vous vos employés à télécharger des données confidentielles sur leur poste de travail ?
Environnement Combien de personnes votre organisation compte-t-elle ? Le service informatique est-il soumis à une forte rotation du personnel ?
Ensuite, MSAT effectue une évaluation qui emploie une unité de mesure appelée DiDI (Defense-in-Depth Index), qui porte sur les processus de sécurité en place. En reprenant les mêmes catégories, les questions type sont : Votre organisation emploie-t-elle des pare-feu sur chaque site ? Utilisez-vous des macros personnalisées dans vos applications Microsoft Office ? Vos utilisateurs disposent-ils de droits d'administration sur leur poste de travail ? Disposez-vous d'une stratégie de déploiement de correctifs et de mises à jour sur vos ordinateurs ?
Sur la base de vos réponses, MSAT propose trois rapports. Le rapport récapitulatif affiche un histogramme présentant les résultats. Un score élevé dans le BRP dénote un risque élevé, tandis qu'un score élevé dans DiDI représente davantage de sécurité. Comme cela est indiqué par MSAT, si un faible score en BRP et un score élevé en DiDI est a priori préférable, il est en fait plus important d'analyser les domaines individuellement. Ainsi, pour chaque domaine, le rapport complet indique si vous vous conformez aux meilleures pratiques, si vous devez faire des efforts ou si votre entreprise présente des lacunes graves (voir la figure 1).
Figure 1 Rapport complet
Figure 1 Rapport complet
Enfin, le rapport de comparaison vous demande de télécharger tous vos résultats de façon anonyme sur un site Web sécurisé de MSAT, où vous pourrez comparer vos résultats à ceux d'autres organisations.
Vous pouvez télécharger cet outil à partir du site Web de conseils de sécurité de Microsoft, securityguidance.com, ou sur le site Web de TechNet Magazine à l'adresse technetmagazine.com/code07.aspx.

Lance Whitney est consultant en informatique, formateur et rédacteur technique. Il a passé un nombre d'heures incalculable à affiner des postes de travail et serveurs Windows. Journaliste de formation, Lance s'est reconverti à l'informatique il y a 15 ans.


 Le petit c&#226;bleur: Serveur NPS
Le petit câbleur
Serveur NPS
Joseph Davies
Cette chronique est basée sur une version bêta de Windows Server 2008. Toutes les informations contenues dans cet article sont susceptibles d’être modifiées.

Le service NPS (Network Policy Server) de Windows Server 2008 remplace le service IAS (Internet Authentication Service) utilisé dans Windows Server 2003. NPS permet à un ordinateur exécutant Windows Server 2008 de faire office de serveur et proxy RADIUS (Remote Authentication Dial-In User Service). RADIUS est un protocole IETF (Internet Engineering Task Force)
spécifié dans les RFC 2865 et 2866 qui fournit l'authentification, l'autorisation et la comptabilité centralisées pour les périphériques d'accès réseau tels que les points d’accès sans fil. Les serveurs RADIUS exécutent les opérations AAA (authentification, autorisation et comptabilité) pour les périphériques d'accès réseau. Les proxys RADIUS transfèrent les messages RADIUS entre les clients RADIUS (périphériques d'accès réseau) et les serveurs RADIUS.
NPS inclut de nombreuses améliorations destinées à faciliter le déploiement d'accès réseau authentifié, offrir davantage d'extensibilité aux composants tiers et prendre en charge les dernières technologies et plates-formes réseau. Le nouveau composant logiciel enfichable NPS est illustré à la figure 1.
Figure 1 Nouveau composant logiciel enfichable NPS
Figure 1 Nouveau composant logiciel enfichable NPS

Fonctionnalités du serveur NPS
Dans cet article, j'aborderai les fonctionnalités NPS qui n'étaient pas incluses dans les versions précédentes de Windows®. Pour commencer, j'examinerai la façon dont la protection d'accès réseau (NAP) contribue à l'application des spécifications d'intégrité pour votre réseau. Je me pencherai ensuite sur les questions de gestion, de configuration et de prise en charge IPv6, ainsi que sur d'autres éléments. Je décrirai également les fonctionnalités du nouveau composant logiciel enfichable NPS.
Protection d’accès réseau Introduite dans Windows Server® 2008, la protection NAP est une série de nouvelles technologies qui peuvent vous aider à garantir la conformité de votre système aux spécifications d'intégrité informatique, vous permettant ainsi de mieux protéger votre intranet. Vos stratégies d'intégrité peuvent spécifier, par exemple, qu'un pare-feu doit être installé et activé et que les dernières mises à jour du système d'exploitation doivent être installées sur tous les clients qui se connectent à votre réseau. Avec la protection NAP, vous pouvez créer des stratégies personnalisées pour certifier l'intégrité de vos ordinateurs avant d'autoriser l'accès réseau ou les communications, mettre à jour les ordinateurs automatiquement pour assurer une conformité continue et restreindre les ordinateurs non conformes à un réseau limité jusqu'à ce qu'ils deviennent conformes. Pour plus d’informations, consultez la page microsoft.com/nap.
Dans un déploiement NAP, le serveur NPS est un serveur de stratégies d'intégrité NAP qui évalue l'intégrité des clients NAP pour le compte des points de mise en application NAP tels que les HRA (Health Registration Authority), les points d'accès 802.1X, les serveurs VPN (virtual private network) et les serveurs DHCP (Dynamic Host Configuration Protocol). Le serveur NPS détermine également le type d'accès à intranet à accorder aux clients : total ou restreint. Les stratégies réseau, les stratégies d'intégrité et les paramètres NAP déterminent le comportement de l'évaluation d'intégrité pour NPS.
Prise en charge des stratégies EAPHost et EAP NPS prend en charge EAPHost, la nouvelle architecture des méthodes d'authentification EAP (Extensible Authentication Protocol). Cette nouvelle architecture permet aux fournisseurs de méthodes EAP de développer et installer en toute facilité les nouvelles méthodes EAP pour l'authentification 802.1X ou PPP (point-to-point protocol) sur les ordinateurs clients et les serveurs NPS.
EAPHost peut prendre en charge l'installation et l'utilisation de toutes les méthodes EAP répertoriées dans le Registre EAP sur www.iana.org/assignments/eap-numbers, ainsi que d’autres méthodes d’authentification fréquemment utilisées telles que Lightweight EAP (LEAP) de Cisco Systems. EAPHost permet la coexistence de plusieurs implémentations d'une méthode EAP. Par exemple, vous pouvez installer et sélectionner la version PEAP (Protected EAP) de Microsoft et celle de Cisco Systems.
Pour les fournisseurs de méthodes EAP, EAPHost prend en charge les méthodes EAP déjà développées pour Windows XP et Windows Server 2003, ainsi qu’une méthode plus simple visant au développement de nouvelles méthodes EAP pour Windows Vista® et Windows Server 2008. Après l'installation, vous pouvez configurer les méthodes EAP requises pour un scénario d'accès réseau donné dans une stratégie de réseau. Une stratégie de réseau pour NPS est identique à une stratégie d'accès distant pour IAS.
Pour plus d'informations sur l'architecture EAPHost, consultez l'article technetmagazine.com/issues/2007/05/CableGuy.
Configuration stockée en XML IAS stockait ses informations de configuration dans une base de données Jet. NPS enregistre désormais les informations de configuration au format XML, ce qui facilite l'exportation de la configuration d'un serveur NPS et son importation vers un autre. L'exportation et l'importation des fichiers de configuration est une façon de synchroniser les paramètres de plusieurs serveurs NPS dans une configuration à tolérance de panne. Vous pouvez exporter la configuration NPS avec la commande netsh nps export et l'importer avec la commande netsh nps import.
Conformité aux critères d'ingénierie communs NPS a été mis à jour pour prendre en charge le déploiement dans des environnements qui doivent répondre aux critères d'ingénierie communs (CEC) de Microsoft®. Pour plus d'informations, consultez la page microsoft.com/windowsserversystem/cer/allcriteria.mspx
DLL d'extension NPS robustes Le service NPS peut être étendu par le biais de DLL d'extension et d'autorisation. Contrairement à IAS, ces composants tiers sont isolés dans NPS, si bien que les problèmes qu'ils rencontrent n'ont aucun effet sur le fonctionnement ou l'exécution du service NPS.
Prise en charge d'IPv6 NPS prend en charge IPv6 et le déploiement dans les environnements IPv6 natifs ou par tunnel. Vous pouvez configurer des adresses IPv6 pour des clients RADIUS ou des serveurs RADIUS distants, et le service NPS peut communiquer sur IPv6 pour les opérations d'authentification et d'autorisation des services du domaine Active Directory®.
Comparaison entre IAS et NPS
Si vous êtes déjà familier avec le composant logiciel enfichable IAS pour Windows Server 2003, vous apprécierez les modifications suivantes qu'il a subies :
  • Les stratégies d'accès à distance sont devenues des stratégies de réseau et ont été placées sous le nœud Stratégies.
  • Le nœud RADIUS Clients a été placé sous le nœud Clients et serveurs RADIUS.
  • Il n'existe plus long de nœud Traitement de requête de connexion. Le nœud Stratégies de requête de connexion a été placé sous Stratégies et le nœud Groupes de serveurs RADIUS distants a été placé sous Clients et serveurs RADIUS.
  • Les paramètres de profil et de conditions de stratégie d'accès distant ont été réorganisés sur les onglets Aperçu, Conditions, Contraintes et Paramètres pour les propriétés d'une stratégie de réseau.
  • Les paramètres de profil et de conditions de stratégie de requête de connexion ont été réorganisés sur les onglets Aperçu, Conditions, et Paramètres pour les propriétés d'une stratégie de requête de connexion.
  • Le dossier de journalisation de l'accès distant est devenu le nœud Gestion des comptes et ne possède plus les nœuds Fichier Local ou SQL ServerTM.

Génération automatique de secrets partagés RADIUS renforcés Les secrets partagés RADIUS sont utilisés pour vérifier que des messages RADIUS ont été envoyés par un client, serveur ou proxy RADIUS configuré avec le même secret partagé. Les secrets partagés sont également utilisés pour chiffrer certains attributs RADIUS sensibles tels que les mots de passe et les clés de chiffrement. Les secrets partagés RADIUS renforcés consistent en une longue séquence (plus de 22 caractères) de lettres, nombres et signes de ponctuation aléatoires.
Avec le composant logiciel enfichable NPS, vous pouvez créer un secret partagé RADIUS renforcé automatiquement lorsque vous ajoutez ou modifiez un client RADIUS. Ce secret partagé renforcé peut être copié sur un éditeur de texte tel que le Bloc-notes, ce qui vous permet de configurer le périphérique d'accès réseau ou le point d'application NAP avec le même secret partagé.
Intégration au Gestionnaire de serveur Vous pouvez installer NPS par le biais des outils Tâches de Configuration initiales et Gestionnaire de serveur. Dans les deux cas, vous installez NPS avec le rôle Services de stratégie et d’accès réseau. Pour commencer, cliquez sur l'option Ajouter des rôles dans l'outil Tâches de Configuration initiales, sous Personnaliser ce serveur. Dans l'outil Gestionnaire de serveur, ouvrez Résumé des rôles et cliquez sur Ajouter des rôles.
Une fois NPS installé, vous pouvez cliquer sur Services de stratégie et d’accès réseau sous le nœud Rôles de l'arborescence de la console du Gestionnaire de serveur pour vérifier l'état du service NPS et afficher les événements d'erreur survenus au cours des dernières 24 heures. Lorsque vous développez le nœud Services de stratégie et d’accès réseau dans la console, vous pouvez configurer NPS avec le composant logiciel enfichable NPS.
Prise en charge améliorée de Netsh Windows Server 2003 était doté d'un jeu de commandes limité dans le contexte netsh aaaa pour configurer IAS. Dans Windows Server 2008, le nouveau contexte netsh nps est doté d'une large gamme de commandes permettant de configurer NPS à la ligne de commande ou par le biais d'un script. Désormais, avec les commandes netsh nps, vous pouvez configurer les clients RADIUS et les serveurs RADIUS distants, les stratégies de réseau et les journalisations, et pour NAP, les stratégies d'intégrité, les validateurs d’intégrité du système et les groupes de serveur de mise à jour. Les scripts composés de commandes du contexte netsh nps vous offrent une autre façon de synchroniser les paramètres de plusieurs serveurs NPS dans une configuration à tolérance de panne.
Balises sources pour l'isolation des stratégies de réseau Les stratégies de réseau peuvent être configurées pour un type spécifique de serveur d'accès réseau ou de point d'application NAP, tel qu'un serveur DHCP ou un HRA, lequel devient une balise source qui catégorise la stratégie de réseau. Les serveurs d'accès et points d'application NAP basés sur Windows Server 2008 incluent cette balise source dans leurs messages RADIUS. Lorsqu'un message RADIUS demandant l'accès est reçu, le service NPS tente de trouver une stratégie de réseau correspondante, ayant la même balise source que le message entrant. S'il ne trouve pas de stratégie, NPS tente de trouver une stratégie de réseau correspondante pour les stratégies qui n'ont pas de balise source.
L'utilisation de la balise source dans la stratégie de réseau et les messages RADIUS entrants isole les différents types de stratégies de réseau les uns des autres. Par exemple, les stratégies de réseau pour les serveurs DHCP ne sont pas utilisées pour les connexions VPN.
Intégration au contrôle d'accès réseau de Cisco NPS prend en charge des fonctionnalités permettant une meilleure intégration à un environnement qui utilise le matériel et le contrôle d'accès réseau de Cisco. Ces fonctionnalités incluent la prise en charge du protocole HCAP (Host Credential Authorization Protocol) et des conditions HCAP, la condition d'expiration de stratégie et le paramètre Protection de l'accès réseau de l'état étendu dans les stratégies de réseau.
Nouvelles conditions de stratégie de réseau Les nouvelles stratégies de réseau de NPS disposent de nouvelles conditions dont le but est de spécifier les groupes d'ordinateurs, les groupes d'utilisateurs, les types EAP autorisés et les adresses IPv6 du client et du serveur d'accès. Pour la prise en charge de HCAP, NPS dispose de nouvelles conditions pour les groupes d'emplacement et les groupes d'utilisateurs. Pour la prise en charge de NAP, NPS dispose de nouvelles conditions de stratégie pour le type d'identité, la stratégie d'intégrité, les ordinateurs compatibles NAP, les systèmes d'exploitation et l'expiration de stratégie.
Composant logiciel enfichable NPS Le nouveau composant logiciel enfichable NPS a été sensiblement amélioré, ce qui vous permet de créer et de gérer facilement les clients RADIUS et les serveurs RADIUS distants, les stratégies de réseau pour les scénarios d'accès réseau courants, les stratégies d'intégrité et les paramètres NAP pour les scénarios NAP et les paramètres de journalisation.
Dans le nœud Clients et serveurs RADIUS, vous pouvez configurer les clients RADIUS (serveurs d'accès réseau, points d'application NAP ou autres proxys RADIUS lorsque NPS joue le rôle de serveur RADIUS) et les groupes de serveurs RADIUS distants (autres serveurs RADIUS lorsque NPS fait office de proxy RADIUS).
Dans le nœud Stratégies, vous pouvez configurer les stratégies de demande de connexion (et déterminer si le service NPS jouera le rôle de serveur RADIUS ou proxy), les stratégies de réseau (paramètres et contraintes d'autorisation et connexion lorsque le service NPS joue le rôle de serveur RADIUS) et les stratégies d'intégrité (conformité aux spécifications d’intégrité du système pour les clients NAP). Lorsque vous sélectionnez une stratégie de demande de connexion ou une stratégie de réseau dans le volet d'informations, le composant logiciel enfichable NPS affiche les conditions et les paramètres de la stratégie. La figure 2 en offre un exemple.
Figure 2 Affichage amélioré du composant logiciel enfichable NPS
Figure 2 Affichage amélioré du composant logiciel enfichable NPS
Dans le nœud Protection de l'accès réseau, le nœud Validateurs d’intégrité du système vous permet de configurer les spécifications d’intégrité NAP. Le nœud Groupes de serveur de mise à jour vous permet de configurer la série de serveurs auxquels peuvent accéder les clients NAP soumis à des restrictions pour les méthodes d'application NAP de VPN et DHCP. Enfin, dans le nœud Gestion des comptes, vous pouvez configurer la façon dont NPS stocke les informations liées à la gestion des comptabilités.
Le composant logiciel enfichable NPS inclut une large gamme d'Assistants permettant d'automatiser la configuration initiale des clients RADIUS et les stratégies nécessaires pour les méthodes d'application NAP, les connexions d’accès à distance ou VPN et les connexions sans fil et câblées authentifiées 802.1X. Pour les méthodes d'application NAP, l'Assistant NAP configure automatiquement toutes les stratégies de demande de connexion, les stratégies de réseau et les stratégies d'intégrité.
Ces nouveaux Assistants sont disponibles lorsque vous cliquez sur le nœud NPS du composant logiciel enfichable NPS. Pour configurer des stratégies et des paramètres pour les méthodes d'application NAP, sélectionnez Protection de l'accès réseau dans la liste déroulante Configuration standard et cliquez sur Configurer NAP. Pour configurer des stratégies et paramètres pour l'accès VPN ou l’accès à distance, sélectionnez Serveur RADIUS pour les connexions d’accès à distance ou VPN dans la liste déroulante Configuration standard et cliquez sur Configurer une connexion VPN ou d’accès à distance. Pour configurer des stratégies et paramètres pour l'accès sans fil et câblées authentifié 802.1X, sélectionnez Serveur RADIUS pour les connexions câblées ou sans fil 802.1X dans la liste déroulante Configuration standard et cliquez sur Configurer 802.1X.
Chacun de ces Assistants vous guidera tout au long des éléments de configuration les plus courants pour le scénario que vous avez choisi. Les Assistants pour les méthodes d'application NAP sont particulièrement utiles : L'Assistant NAP pour l'application VPN crée une stratégie de demande de connexion, trois stratégies de réseau (pour les clients conformes à NAP, les clients non conformes à NAP et les clients ne pouvant pas prendre en charge NAP) et deux stratégies d'intégrité (pour les clients conformes ou non conformes à NAP).
Les nouveaux Assistants NAP et autres Assistants servant à créer des clients RADIUS, groupes de serveurs RADIUS distants, stratégies de demande de connexion et stratégies de réseau facilitent énormément la configuration NPS pour une variété de scénarios d'accès réseau.

Joseph Daviesest rédacteur technique chez Microsoft et il enseigne et écrit sur le réseau Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press et on lui doit la chronique en ligne mensuelle Cable Guy de Technet.


 Windows&#160;PowerShell: Approfondissez vos connaissances
Windows PowerShell
Approfondissez vos connaissances
Don Jones

Windows PowerShell offre une multitude de fonctionnalités qui sont souvent négligées par de nombreux administrateurs. En creusant davantage, vous découvrirez des fonctionnalités stupéfiantes. En fait, je trouve souvent moi-même de nouvelles fonctionnalités associées à une applet de commande particulière que je pensais déjà bien connaître.
Dans les cours Windows PowerShellTM que je donne, je recommande aux administrateurs d'établir un calendrier des applets de commande du jour pour eux-mêmes, comparable à un calendrier des mots du jour que l'on peut acheter. Ensuite, chaque matin (excepté le week-end car il faut bien qu'ils se reposent), ils peuvent passer quelques minutes à se familiariser avec les fonctionnalités complètes d'une applet de commande. Windows PowerShell est vendu avec environ 130 applets de commande, ce qui vous permet d'apprendre à connaître pratiquement toutes ses fonctionnalités en six mois environ, si vous respectez ce calendrier. Vous serez alors prêt à gérer toutes les applets de commande d'Exchange Server 2007.
Dans l'article de ce mois-ci, je voudrais vous donner quelques exemples de ce que vous pourriez découvrir et de ce que vous pourriez faire si vous consacriez quelques minutes seulement à l'exploration en profondeur des fonctionnalités de diverses applets de commande.

Des rapports HTML plus attrayants
ConvertTo-HTML est une applet de commande très sous-utilisée. Cette applet de commande intelligente peut accepter une collection d'objets d'entrée, tels que des services, processus, objets WMI (Windows ® Management Instrumentation) ou autres, et les transformer en table HTML. Vous pouvez ensuite canaliser le HTML vers Out-File et vous obtenez une page HTML qui peut être publiée sur un serveur Web d'intranet. Par exemple, vous pouvez planifier l'exécution de cette ligne simple tous les matins :
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML | Out-File C:\ServiceAlert.html
Elle créera un rapport HTML, comme celui illustré à la figure 1, sur les services qui devraient être démarrés automatiquement mais qui ne sont pas exécutés.
Figure 1 Rapport HTML sur les services qui ne sont pas exécutés
Figure 1 Rapport HTML sur les services qui ne sont pas exécutés
Bien sûr, vous pouvez essayer de produire un rapport un peu plus attrayant. Fort heureusement, l'applet de commande ConvertTo-HTML produit un HTML propre, c'est-à dire qu'elle n'intègre pas de formatage au code HTML qu'elle crée. Selon les règles HTML, vous ne devez jamais intégrer de formatage au HTML (ou du moins, vous devez en intégrer le moins possible). Vous devez mettre le formatage dans une feuille CSS (cascading style sheets) externe et la lier au HTML. Et vous pouvez créer ce lien avec ConvertTo-HTML.
CSS est relié à la section <HEAD> d'un fichier HTML. Si vous jetez un coup d'œil sur ConvertTo-HTML, vous verrez que sa syntaxe inclut des paramètres que vous pourriez avoir négligé :
ConvertTo-Html [[-property] <Object[]>]
[-inputObject <psobject>] [-body <string[]>]
[-head <string[]>] [-title <string>] [<CommonParameters>]
Le paramètre –head vous permet de spécifier le code HTML supplémentaire qui doit être inséré dans la section <HEAD> du script. Je peux, à présent, facilement modifier ma ligne de code et la relier à un fichier CSS existant qui contient le formatage que je souhaite appliquer à la table HTML :
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML -title "Services" -head "<link
rel='stylesheet' href='styles.css' type='text/
css' />" | Out-File C:\ServiceAlert.html
Ici, j'ai utilisé le paramètre –head pour insérer un lien dans un fichier CSS situé dans le même dossier que le fichier HTML de sortie. J'ai également utilisé le paramètre –title pour définir le titre de la page Web. Le résultat est illustré à la figure 2. Le texte du fichier Style.CSS que j'ai utilisé ressemble à ceci :
Figure 2 Rapport HTML formaté avec un fichier CSS
Figure 2 Rapport HTML formaté avec un fichier CSS
body { background-color:#EEEEEE; }
body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt }
th { font-weight:bold; background-color:#CCCCCC; }
td { background-color:white; }

Un filtrage plus facile
Applet de commande du mois
Ce mois-ci, je m'intéresse à deux applets de commande : Start-Transcript et Stop-Transcript. Les deux sont utilisées pour contrôler la journalisation des transcriptions Windows PowerShell, c'est-à-dire l'écriture dans un fichier texte que vous avez spécifié de tout ce qui apparaît dans la fenêtre de la console. Cette opération est très simple. Exécutez Start-Transcript et donnez-lui un nom de fichier pour commencer. Ensuite exécutez Stop-Transcript pour mettre fin à la journalisation et fermez le fichier. Il s'agit là d'un bon moyen de passer d'une utilisation ad hoc de l'environnement de ligne de commande au script formel. Une fois que les lignes de commande individuelles fonctionnent dans l'environnement, il vous suffit de les copier et coller à partir du fichier de transcription que vous avez créé. Bien sûr, vous pouvez également modifier la transcription et la limiter au script lui-même. Mon collègue Jeffery Hicks, MVP, a même écrit un script qui analyse les transcriptions et les transforme en fichiers PS1 Windows PowerShell. Vous trouverez ce script à l'adresse blog.sapien.com/current/2006/11/28/powershell-transcripts.html.

Examinons maintenant l'applet de commande Get-WMIObject. Sa syntaxe, comme indiqué dans l'aide de Windows PowerShell, suggère des fonctionnalités inexploitées :
Get-WmiObject [-class] <string> [[-property]
<string[]>] [-namespace <string>]
[-computerName <string[]>] [-filter <string>]
[-credential <PSCredential>]
[<CommonParameters>]
Les nouveaux utilisateurs de Windows PowerShell font souvent l'erreur d'émettre une commande WMI comme suit :
Gwmi Win32_NTLogEvent –comp Server2
Cette commande récupère les entrées des journaux d'événements de Server2, soit toutes les entrées des journaux d'événements. Il faudra du temps à Server2 pour traiter et transmettre cette tâche, et Windows PowerShell mettra beaucoup de temps à organiser une telle collection d'entrées.
Une meilleure approche est celle qui consiste à faire en sorte que Server2 trouve et envoie les événements qui vous intéressent vraiment. Vous pouvez effectuer cette opération à l'aide d'une requête WQL (WMI Query Language). Certains trouvent cette syntaxe de requête difficile, mais Windows PowerShell vous permet de spécifier uniquement la partie de filtrage d'une requête WQL à l'aide du paramètre –filter :
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Vous récupérez ainsi tous les événements de n'importe quel journal portant l’ID d’événement 1024. Remarquez que les critères du filtre utilisent = comme opérateur de comparaison au lieu de l'opérateur –eq de Windows PowerShell. La raison en est que le filtre est transmis au service WMI de l'ordinateur distant pour traitement, et les critères doivent donc être dans la syntaxe WMI et non pas dans la syntaxe Windows PowerShell.
Il existe en fait un paramètre –filter sur d'autres applets de commande telles que Get-ChildItem, l'applet de commande sur laquelle s’appuient les alias tels que Dir et Ls. Dans la plupart des cas, le paramètre –filter transmet vos critères de filtre directement à la technologie sous-jacente, ce qui aboutit à ce que je choisis d'appeler le filtrage source qui est souvent beaucoup plus rapide que le fait d'avoir à réunir tous les objets et à les faire passer ensuite par l'applet de commande Where-Object pour éliminer ceux dont vous n'avez pas besoin.

Applets de commande négligées
Bien sûr, cette méthode d'étude « un par jour » des applets de commande vous aidera à mieux comprendre les applets de commande que vous pensiez déjà connaître. Toutefois, il existe une autre bonne raison d'avoir un calendrier « applet de commande du jour » : éviter d'ignorer complètement les applets de commande que vous n'auriez pas pu découvrir autrement. Une de mes applets de commande préférées que beaucoup de gens n'utilisent pas est Resolve-Path. Avec un chemin d'accès à caractères génériques, cette applet de commande renvoie une collection de noms de fichier et de dossier correspondant à ce chemin. Elle est similaire à l'applet de commande Get-ChildItem (c'est-à-dire les alias bien connus Dir ou Ls), mais au lieu de renvoyer des objets de fichiers et dossiers entiers, elle renvoie de simples chaînes qui peuvent être dirigées vers d'autres applets de commande pour y être filtrées ou traitées. Son utilisation est simple :
Resolve-Path C:\P*
Cette simple ligne renverra des chemins tels que C:\Program Files, C:\Processes.txt, et ainsi de suite. La figure 3 montre deux exemples de cette applet de commande en utilisation.
Figure 3 Utilisation de l'applet de commande Resolve-Path, robuste mais souvent négligée
Figure 3 Utilisation de l'applet de commande Resolve-Path, robuste mais souvent négligée

Commencez au tout début.
Une fois prêt à démarrer votre expérience « applet de commande du jour », exécutez Gcm, alias de Get-Command. Vous obtenez un liste de toutes les applets de commande connues de Windows PowerShell, y compris celles que vous y avez ajoutées au moyen de composants logiciels enfichables tels qu'Exchange Server 2007 Management Shell, PowerShell Community Extensions, etc. Choisissez la première de la liste (la mienne était Add-Content) et lisez son aide :
Help Add-Content –full
Il vous faut l'aide complète, et non pas l'aide par défaut qui est plus concise, afin d'obtenir une description complète de ce que chaque paramètre fait, de voir des exemples d'utilisation de l'applet de commande et de trouver d'autres informations détaillées. Essayez cette applet de commande pendant quelques instants. (Essayez d'utiliser une machine virtuelle pour ne pas avoir à toucher à votre environnement de production). Je vous recommande d'y consacrer 10 minutes tous les jours de semaine et à peu près au même moment de la journée afin que cela devienne une habitude. Vous maîtriserez ainsi, en un temps record, toutes les fonctions et fonctionnalités de Windows PowerShell.

Don Jones est le gourou des scripts chez SAPIEN Technologies et co-auteur de Windows PowerShell: TFM (SAPIEN Press, 2007). Vous pouvez le contacter sur le site www.ScriptingAnswers.com.


 H&#233;, vous le scripteur&#160;!: WinRM, le retour
Hé, vous le scripteur !
WinRM, le retour
Les scripteurs Microsoft

Lorsque les scripteurs ont décidé de créer une série en deux parties sur Windows® Remote Management (WinRM), un problème important leur a tout de suite sauté au visage : la sécurité. Après tout, nous les scripteurs étions bien conscients des problèmes qui ont accompagné la publication du dernier volet de la série Harry Potter : les exemplaires précommandés des livres ont été expédiés en avance par erreur et ont été livrés avant la date officielle de publication du livre. (Cela a-t-il posé problème ? Non, bien sûr que non ; l'éditeur a juste demandé aux gens de ne pas lire le livre jusqu' à sa date de publication).
Et ce n'est qu'une partie de l'histoire. Il y a eu des fuites sur le livre et la fin de la série bien avant la mise en vente du roman. (Si vous ne l'avez pas encore lu, voici ce qui se passe : il s'avère en fait qu'Harry Potter est un genre de sorcier) ! De même, les copies numérisées de toutes les pages étaient instantanément mises à disposition sur Internet, parfois avant même que l'auteur J. K. Rowling ait écrit ces pages. Pour tout dire, ce fut un fiasco en termes de sécurité, et les scripteurs étaient déterminés à ce que cela ne puisse pas leur arriver. Après tout, si des personnes étaient aussi déterminées à dévoiler la fin de la série Harry Potter, imaginez ce qu'elles auraient pu inventer pour pouvoir mettre la main sur la deuxième et dernière partie de la série des Scripteurs sur WinRM.
Heureusement, les Scripteurs ont réussi à tout verrouiller et à garder leurs secrets, heu... secrets. D'accord, c'était essentiellement dû au fait qu'ils n'avaient pas vraiment écrit la deuxième partie de cette série avant bien après la date limite pour remettre l'article. Mais heu... le scripteur qui écrit cet article était en vacances au mois d'août et, contrairement à un pourcentage étonnamment élevé d'employés de Microsoft, il ne regarde jamais, sans parler d'utiliser, un ordinateur pendant ses congés.
Bon d'accord : il regarde rarement, sans parler d'utiliser, un ordinateur même quand il n'est pas en congé. Mais ceci est une autre histoire.
Quoi qu'il en soit, nous savons que beaucoup d'entre vous ont perdu le sommeil au cours des quatre dernières semaines, perdus en conjectures et théories sur le suspense de la fin possible ou probable de la saga WinRM. Hé bien, la bonne nouvelle est que ces longues semaines d'insomnies sont terminées. Voici, pour la toute première fois, la passionnante conclusion de la série en deux parties des Scripteurs sur WinRM. Hmm, en fait, elle est là-bas à la figure 1.
Figure 1 Le dénouement (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"
strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select Name, DisplayName From Win32_Service Where State = 'Running'"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom")
    objXMLDoc.async=False
    objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement
    Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue
    Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue
    Wscript.Echo
Loop
Oui, oui, cette incroyable intrigue nous a nous aussi fait frissonner de partout. objElement.ChildNodes(0).ChildNodes(0).NodeValue ! Qui l'avait vu venir ? Forcément, c'est parce que, dans le cadre de notre verrouillage de sécurité, les scripteurs eux-mêmes ne savaient pas comment l'histoire se terminerait. Mais maintenant le secret est éventé.
Avant de continuer, nous devrions récapituler rapidement la série dans son ensemble, pour le cas très improbable où l'un d'entre vous n'aurait pas lu la 1e partie (disponible à l'adresse technetmagazine.com/issues/2007/11/HeyScriptingGuy). Dans la 1e partie, nous avons présenté WinRM, une nouvelle technologie introduite dans Windows Server® 2003 R2, Windows Vista® et Windows Server 2008, qui facilite considérablement la gestion des ordinateurs via Internet, même en passant par des pare-feu. D'accord, Windows Management Instrumentation (WMI) a toujours offert la possibilité de gérer des ordinateurs à distance. Toutefois, WMI s'appuie sur DCOM (Distributed COM) comme technologie de gestion à distance. C'est bien, sauf que par défaut, un grand nombre de pare-feu bloquent le trafic DCOM. Certes, vous pouvez toujours ouvrir les ports appropriés et autoriser le trafic DCOM, mais de nombreux administrateurs réseau répugnent à le faire. Leur principal souci réside dans le fait qu'en ouvrant la porte à DCOM, ils ouvrent en même temps la porte à toutes sortes de malveillances.
D'où WinRM, « l'implémentation Microsoft du protocole WS-Management, protocole SOAP standard compatible avec les pare-feu qui permet l'interaction entre matériel et systèmes d'exploitation de différents fournisseurs ». Ce qui est juste une façon un peu pompeuse de dire que vous pouvez maintenant assurer la gestion à distance en utilisant des protocoles Internet standard comme HTTP et HTTPS.
Comme nous l'avons dit le mois dernier, WinRM permet de se connecter facilement à des ordinateurs distants et d'y récupérer les informations WMI. Cela veut-il dire qu'il s'agit d'une technologie absolument parfaite ? Hé bien, non, pas exactement. Comme nous l'avons fait remarquer, lorsque WinRM renvoie des données au script d'appel, ces données reviennent au format XML. Inutile de dire que XML peut être un peu difficile à analyser et à exploiter, surtout pour les administrateurs système ayant une expérience limitée dans ce domaine. Pour cette raison, WinRM est fourni avec un convertisseur XSL qui restitue les données renvoyées dans un format plus lisible.
C'est formidable, sauf que cela veut également dire que votre résultat ressemblera toujours à quelque chose de ce type :
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
Ce n'est pas nécessairement une mauvaise chose, mais cela signifie également que votre résultat sera toujours écrit dans la fenêtre de commande : par défaut, vous ne pouvez pas facilement enregistrer des données dans un fichier texte, écrire ces données dans une base de données ou une feuille de calcul Microsoft® Excel®, ni faire grand chose de ces données à part les afficher à l'écran. Cela n'est pas suffisant.
En outre, le problème s'aggrave si vous choisissez de ne renvoyer qu'un certain nombre de propriétés pour une classe WMI (par exemple en vue de réduire le trafic réseau). Lorsque vous travaillez avec seulement quelques propriétés d'une classe (par opposition à toutes les propriétés d'une classe) vous obtenez un résultat semblable à ceci :
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Intéressant, mais d'un point de vue esthétique, ce n'est pas l'affichage d'informations le plus agréable que nous ayons vu (surtout le titre XmlFragment qui apparaît sur le rapport).
Mais que pouvez-vous y faire ? Écrire un code personnalisé pour analyser et mettre en forme ces données XML ? Cela ne ressemble pas à ce qu'un scripteur d'administration de système ferait. Á moins que ?

Si vous voulez que quelque chose soit bien fait, faites-le vous-même
Il s'avère en fait que travailler avec les données XML brutes renvoyées par WinRM n'est finalement pas si insurmontable que cela pourrait paraître de prime abord. Ce mois-ci, nous allons vous présenter une méthode simple pour analyser et mettre en forme les données XML. L'approche que nous utiliserons n'est en aucun cas la seule façon possible de travailler avec XML, mais ce n'est pas grave : notre objectif principal est juste de démontrer que vous ne devez pas obligatoirement vous appuyer sur la transformation XSLT. Une fois que vous aurez saisi cette idée de base, hé bien, votre imagination sera la seule limite à ce que vous pourrez faire avec les données de WinRM.
Il y a cependant un tout petit hic : pour faire rentrer cet article dans l'espace qui nous est attribué, nous allons laisser de côté l'essentiel du script que nous avons reproduit à la figure 1. Cela ne devrait toutefois pas poser trop de problèmes parce que les deux premiers tiers du script ont été décrits en détail dans l'article du mois dernier. Nous allons plutôt nous concentrer sur le dernier tiers du script, qui est la partie où nous travaillons effectivement avec les données renvoyées.
Comme vous pouvez le voir, cet épisode des Chroniques de WinRM se passe après que nous avons créé une instance de l'objet WSMan.Automation, interrogé un ordinateur distant (dans ce cas, atl-fs-01.fabrikam.com) et reçu les informations sur tous les services s'exécutant sur cet ordinateur. Cela nous amène à la ligne du script où nous définissons une boucle Do Until pour lire et traiter les données XML renvoyées ; cette boucle continuera jusqu'à ce qu'il ne reste plus rien à lire et à traiter. (Ou, pour faire croire que nous savons de quoi nous parlons, cette boucle se poursuivra jusqu'au moment où la propriété AtEndOfStream du fichier XML aura la valeur True).
C'est la ligne de code dont nous parlons, et c'est là que commence l'intrigue du mois :
Do Until objResponse.AtEndOfStream
dans la boucle, la première étape consiste à utiliser la méthode ReadItem pour lire la première section de données XML renvoyées. (Comme nous travaillons avec WinRM et que nous récupérons des informations sur les services, cette première section inclura toutes les données renvoyées pour le premier service de notre collection.) Après avoir enregistré ces données (qui, encore une fois, sont au format XML) dans une variable strXML nommée, nous créons une instance de l'objet Microsoft.XMLDom. Dans les faits, cela nous donne un document XML vide avec lequel nous pouvons travailler :
Set objXMLDoc = _
    CreateObject("Microsoft.XMLDom")
Dès que notre document vide est prêt, nous définissons la valeur de la propriété Async sur False, puis nous appelons la méthode loadXML.
Ce qui nous amène à... qu'avez-vous dit ? Pourquoi définir la valeur de la propriété Async sur False ? Et pourquoi appeler la méthode loadXML ? Bonnes questions... si seulement nous y avions nous-mêmes réfléchi !
Pour les débutants, la propriété Async indique si le script autorise un téléchargement asynchrone des informations XML. Si cette propriété est True, le téléchargement démarrera et le contrôle sera renvoyé au script immédiatement, même si le téléchargement n'est pas terminé. D'accord, cela paraît plutôt pas mal. Malheureusement, cependant, votre script se poursuivra alors comme s'il avait toutes les informations dont il a besoin. Si ce n'est pas le cas, vous risquez d'avoir des problèmes. C'est pourquoi nous déterminons la propriété Async sur False.
Remarque : Certes, vous pourriez écrire du code pour contrôler périodiquement l'état du téléchargement, ce qui garantirait que le script ne se termine pas prématurément. Cela fonctionne, mais il est beaucoup plus facile de simplement définir la valeur de la propriété Async sur False. En effet, le script se bloque alors jusqu'à ce que le téléchargement soit terminé. En d'autres termes, une fois le téléchargement démarré, le script attend patiemment qu'il se termine avant de faire quoi que ce soit d'autre.
Quant à la méthode loadXML, sa fonction correspond essentiellement à ce que son nom suggère : elle charge un document XML (ou un fragment de document) correctement formé dans notre document vide. Il nous suffit d'appeler la méthode loadXML, en transmettant la variable strXML comme paramètre unique de la méthode :
objXMLDoc.loadXML(strXML)
Le résultat ? Nous avons maintenant converti nos données WinRM en document XML virtuel. Cela signifie que nous pouvons commencer à utiliser les méthodes XML standard pour traiter ce document virtuel.
À cette fin, nous devons ensuite utiliser la ligne de code suivante pour créer une référence d'objet à l'élément racine du fichier XML :
Set objElement = objXMLDoc.documentElement
À ce stade, nous sommes prêts à nous amuser un peu. (En supposant, bien sûr, que l'analyse d'un fichier XML corresponde à votre vision de l'amusement. Pour nous scripteurs, c'est indéniablement très amusant.)
Comme vous vous en souvenez peut-être, notre requête WQL (WMI Query Language) ou, pour utiliser la terminologie WinRM, notre Filtre, ressemble à ceci :
strFilter = "Select Name, DisplayName " & _
  "From Win32_Service Where State = 'Running'"
Comme vous pouvez le voir, nous avons interrogé deux propriétés de la classe Win32_Service : Name et DisplayName. (Nous avons également inclus une clause Where qui limite nos données renvoyées aux services en cours d'exécution. Mais nous ne devons pas nous en préoccuper ici.) Est-ce important que nous ayons interrogé deux propriétés ? L'ordre de cette requête est-il important ? Peut-être. Comment diable sommes-nous censés le savoir ?
Oh, bien vu. Peut-être, en tant qu'auteurs de cet article, devrions-nous connaître les réponses à ces questions. D'accord. Il se trouve que nous savons que la réponse à ces deux questions est oui. Est-ce important que nous interrogions deux propriétés dans notre requête WQL ? Oui, ça l'est, car après tout, ce seront les seules valeurs de propriétés qui nous seront renvoyées. (À la différence d'une requête Select * From, qui renvoie des valeurs pour toutes les propriétés d'une classe.)
Donc ensuite, l'ordre de ces deux propriétés est-il également important ? Et comment ! L'ordre dans lequel nous spécifions les noms de propriétés est le même ordre que celui dans lequel les valeurs de propriété sont renvoyées. Cela est important parce que chaque valeur de propriété sera renvoyée sous forme de nœud enfant (ou section) de notre élément racine. Quelle valeur de propriété reviendra en tant que premier nœud enfant ? Facile. Dans ce cas-ci, le premier nœud enfant sera la propriété Name, parce qu'elle est la première propriété figurant dans notre requête WQL. Quelle propriété reviendra comme second nœud enfant ? Effectivement, ce sera la propriété DisplayName, parce qu'elle figure en deuxième position dans notre requête.
Attendez un instant. Vous avez trouvé cela tout seul, ou quelqu'un vous a-t-il montré un exemplaire de cet article à l'avance ? Hmmmm...
Quoi qu'il en soit, cette méthode permet de récupérer facilement la valeur de la propriété Name. Il nous suffit de référencer le NodeValue du premier élément (l'élément 0) dans la première collection ChildNodes (l'article 0), comme ceci :
Wscript.Echo "Name: " & _
objElement.ChildNodes(0).ChildNodes(0).NodeValue
Et comment référençons-nous la valeur de la propriété DisplayName ? Dans ce cas-ci, nous référençons le NodeValue du premier élément dans la deuxième collection ChildNodes (l'élément 1) :
Wscript.Echo "Display Name: " & _
objElement.ChildNodes(1).ChildNodes(0).NodeValue
Et que se passe-t-il si nous avons une troisième propriété (disons, Status) dans notre requête WQL ? Dans ce cas, nous référençons simplement le NodeValue du premier élément dans la troisième collection ChildNodes (élément 2) :
Wscript.Echo "Status: " & _
objElement.ChildNodes(2).ChildNodes(0).NodeValue
Et ainsi de suite jusqu'à la dernière propriété.
Donc, à quoi va ressembler notre résultat de script maintenant ? À quelque chose comme ceci :
Display Name: Windows Event Log
Name: EventLog

Display Name: COM+ Event System
Name: EventSystem
D'accord, cela n'a pas l'air très différent du résultat par défaut de WinRM (bien que nous soyons débarrassés de ce stupide titre XmlFragment). La différence tient en ceci : en travaillant avec les valeurs individuelles des propriétés, nous ne sommes plus limités au format par défaut (notez que nous utilisons l'étiquette Display Name au lieu de DisplayName), et nous ne sommes plus obligés d'afficher les informations uniquement dans la fenêtre de commandes.
Vous préféreriez écrire ces données dans une feuille de calcul Excel ? C'est relativement facile. Pour commencer, insérez le bloc de code suivant (qui crée et configure une nouvelle feuille de calcul Excel) immédiatement après la ligne du script WinRM qui appelle la méthode Enumerate :
Set objExcel = _
  CreateObject("Excel.Application")
objExcel.Visible = True
Set objWorkbook = objExcel.Workbooks.Add()
Set objWorksheet = objWorkbook.Worksheets(1)

i = 2
objWorksheet.Cells(1,1) = "Name"
objWorksheet.Cells(1,2) = "Display Name"
Maintenant, remplacez la boucle Do Until par celle illustrée à la figure 2. Faites un essai et voyez ce que vous obtenez.
Figure 2 La nouvelle boucle Do Until (Close Figure 2)
Do Until objResponse.AtEndOfStream
  strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom")
  objXMLDoc.async=False
  objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement
  objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue
  objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue
  i = i + 1
Loop

WinRM, 3e partie ?
Entre l'article de ce mois et le précédent, vous devriez en savoir assez pour démarrer avec WinRM. Nous l'espérons ! WinRM est une nouvelle technologie passionnante qui promet de faciliter considérablement la gestion à distance de vos ordinateurs (tout en maintenant la sûreté et la sécurité). Ce qui, bien sûr, nous amène directement à la question qui obsède tout le monde : ce la signifie-t-il qu'il y aura un troisième volet à la saga WinRM ?
Nous ne pouvons malheureusement pas révéler cette information. Pas à cause de problèmes de sécurité, mais simplement parce qu'en raison de l'agenda normal et du processus de décision des scripteurs, nous ne savons absolument pas si nous allons écrire quoi que ce soit d'autre sur WinRM. Comme on dit, tenez-vous au jus !
Les scripts embrouillés du Dr. Scripto
Docteur Scripto a eu un petit accident. Il a laissé l'un de ses scripts traîner (au lieu de le ranger comme tout bon scripteur) et il a trébuché accidentellement dessus, ce qui a fait voler des morceaux de script partout. Il a réussi à trouver toutes les variables, les mots clés, les symboles et autres, et il les a gentiment rangés par ordre alphabétique, mais maintenant il doit les remettre ensemble pour recréer son script complet. Cela va lui prendre un peu de temps, mais il compte avoir la réponse au moment de la publication du TechNet Magazine du mois prochain. D'ici là, n'hésitez pas à vous y essayer et voyez si vous réussissez à faire rentrer cette série de morceaux de script apparemment aléatoire dans un script correct et complet. Bonne chance !
Petite astuce : OK, voici une petite piste. Le script final supprimera sur l'ordinateur local tous les fichiers antérieurs à une date spécifiée.

Les scripts embrouillés du Dr. Scripto
Réponse : Les maladresses du Dr. Scripto, décembre 2007
Oui, Dr. Scripto a réussi à réassembler son script. Voici le script reconstruit, opérationnel qui supprime sur l'ordinateur local tous les fichiers antérieurs à une date spécifiée :
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

Les scripteurs Microsoft travaillent pour (enfin, sont employés par) Microsoft. Lorsqu’ils ne sont pas en train de jouer au base-ball, d’entraîner une équipe ou de regarder un match (ou de se livrer à de multiples autres activités), ils dirigent le Script Center TechNet. Vous pouvez le vérifier vous-même sur www.scriptingguys.com.


 Vigilance s&#233;curit&#233;: Strat&#233;gies de mots de passe de domaine de Windows
Vigilance sécurité
Stratégies de mots de passe de domaine de Windows
Derek Melber

Si vous êtes administrateur d'un domaine Windows, vous ne connaissez que trop bien les contraintes liées aux stratégies de mot de passe pour les comptes d'utilisateur de domaine. Avec la venue de Windows Server 2008, cependant, certaines de ces restrictions disparaîtront. Examinons comment le nouveau système d'exploitation résout l'un de ces problèmes : l'impossibilité d'implémenter plusieurs stratégies de mot de passe.
Si vous exécutez actuellement une version de domaine Windows® quelconque (Windows NT®, Windows 2000 Active Directory® ou Windows Server® 2003 Active Directory), vous êtes limité à une seule stratégie de mot de passe par domaine. En réalité, la restriction ne vient pas uniquement de la stratégie de mot de passe, mais plutôt de l'ensemble plus large des paramètres entrant dans les stratégies de comptes. La figure 1 illustre ces stratégies et ces paramètres.
Figure 1 Stratégies de comptes (Close Figure 1)

Stratégie de mot de passe
Conserver l’historique des mots de passe
Durée de vie maximale du mot de passe
Durée de vie minimale du mot de passe
Longueur minimale des mots de passe
Le mot de passe doit respecter des exigences de complexité
Enregistrer les mots de passe en utilisant le chiffrement réversible
Stratégie de verrouillage des comptes
Durée de verrouillage des comptes
Seuil de verrouillage des comptes
Réinitialiser le compteur de verrouillages de comptes après...
Stratégie Kerberos
Appliquer les restrictions pour l'ouverture de session
Durée de vie maximale du ticket de service
Durée de vie maximale du ticket utilisateur
Durée de vie maximale pour le renouvellement du ticket utilisateur
Tolérance maximale pour la synchronisation de l'horloge de l'ordinateur
Ces paramètres de stratégie s'appliquent à tous les comptes de domaine et d'utilisateur associés au domaine, par défaut. Cela est dû à la façon dont la stratégie de groupe hérite ses valeurs par le biais de la structure Active Directory. Pour mieux appréhender la façon dont ces stratégies affectent les comptes d'utilisateur de domaine locaux, il est important de comprendre où ces stratégies sont définies et comment l'héritage de la stratégie de groupe affecte tous les comptes utilisateur. (Notez que les paramètres de stratégie Kerberos s'appliquent uniquement aux comptes d'utilisateur de domaine, car eux seuls utilisent Kerberos pour l'authentification. Les comptes d'utilisateur locaux utilisent plutôt NTLMv2, NTLM ou LM pour l'authentification).

Définition des stratégies de comptes
Dans Active Directory, la stratégie de groupe établit et contrôle les stratégies de comptes pour l'ensemble du domaine. Cette opération s'exécute lors de l'installation initiale de votre domaine Active Directory, en liant un objet de stratégie de groupe par défaut au nœud de domaine dans Active Directory. Cet objet de stratégie de groupe, appelé stratégie de domaine par défaut, possède des configurations par défaut pour les trois sections des stratégies de comptes. La figure 2 offre une liste complète des paramètres initiaux pour les éléments de stratégie de mot de passe sur un domaine Windows Server 2003.
Figure 2 Stratégies de mots de passe par défaut pour un domaine Windows Server 2003
Figure 2 Stratégies de mots de passe par défaut pour un domaine Windows Server 2003
Les paramètres de cet objet de stratégie de groupe contrôlent les stratégies de comptes pour tous les comptes d'utilisateur de domaine, ainsi que pour chaque ordinateur du domaine. Il est important de se rappeler que tous les ordinateurs du domaine (postes de travail et serveurs) possèdent un Gestionnaire de comptes de sécurité local. C'est ce Gestionnaire de comptes de sécurité qui est contrôlé par les paramètres de cet objet de stratégie de groupe par défaut. Bien sûr, les Gestionnaires de comptes de sécurité locaux contiennent également des comptes utilisateur locaux pour l'ordinateur concerné.
Les paramètres de la stratégie de domaine par défaut concernent tous les ordinateurs du domaine par l'héritage normal des objets de stratégie de groupe dans toute la structure Active Directory. Puisque cet objet de stratégie de groupe est lié au nœud de domaine, il affectera tous les comptes d'ordinateur du domaine.

Ce qui est impossible avec les stratégies de mot de passe actuelles
Un grand nombre d'idées fausses sur les contrôles de mot de passe entourent l'implémentation actuelle d'Active Directory (dans Windows Server 2003), malgré les années de tests rigoureux et bien qu'aucune preuve ne vienne justifier ces idées. Il est évident, ou cela devrait l'être, que la stratégie ne fonctionnera pas autrement que conformément à sa conception.
Cela a dit, de nombreux administrateurs croient qu'il est possible d'utiliser plusieurs stratégies de mot de passe pour les utilisateurs d'un même domaine. Ils pensent qu'ils peuvent créer un objet de stratégie de groupe et le lier à une Unité d'organisation. L'idée est de déplacer des comptes utilisateur dans l'Unité d'organisation pour que l'objet de stratégie de groupe s'applique à ces objets. Dans l'objet de stratégie de groupe, les stratégies de comptes sont modifiées pour créer une stratégie de mot de passe plus sécurisée, éventuellement en définissant la longueur du mot de passe maximale à 14 caractères. Mais, pour différentes raisons, cette configuration n'offrira jamais le résultat souhaité. Premièrement, les paramètres Stratégies de mots de passe sont basés sur l'ordinateur et non sur l'utilisateur. Par conséquent, ils ne concerneront jamais un compte utilisateur. Deuxièmement, le seul moyen de modifier les paramètres Stratégies de comptes pour un compte d'utilisateur de domaine consiste à utiliser un objet de stratégie de groupe lié au domaine. Les objets de stratégie de groupe liés à l'Unité d'organisation qui sont configurés pour modifier les paramètres Stratégies de comptes modifieront le Gestionnaire de comptes de sécurité local des ordinateurs résidant dans l'Unité d'organisation ou dans des sous-unités de l'Unité d'organisation liée.
Une deuxième idée fausse est que les paramètres Stratégies de comptes établis dans le domaine racine (le domaine initial de la forêt Active Directory) seront répercutés (par héritage) sur les domaines enfants de la forêt. Ceci n'est pas non plus exact et vous ne pouvez pas faire fonctionner les paramètres de cette manière. Les objets de stratégie de groupe liés au domaine et aux Unités d'organisation d'un domaine n'affecteront pas les objets d'un autre domaine, même si le domaine où l'objet de stratégie de groupe est lié est le domaine racine. La seule méthode pour faire en sorte que les paramètres d'objet de stratégie de groupe s'étendent à des objets de domaines différents consiste à lier les objets de stratégie de groupe à des sites Active Directory.

Traitement des mots de passe dans Windows Server 2008
Comme nous venons de le voir, les versions actuelles de Windows traitent les mots de passe de compte d'utilisateur de manière simple et directe. Un seul jeu de règles de mot de passe est utilisé pour tous comptes de domaine, et la gestion des stratégies de comptes s'opère par le biais d'un objet de stratégie de groupe lié au nœud de domaine dans Active Directory. Tout ceci vole en éclat avec de Windows Server 2008.
Windows Server 2008 et son infrastructure Active Directory suivent une approche différente. Au lieu d'avoir des stratégies de comptes dans un objet de stratégie de groupe, ce qui ne permettait de déterminer qu'une seule stratégie pour tous les comptes d'utilisateur de domaine, les paramètres ont été déplacés vers une partie plus profonde d'Active Directory. De plus, les stratégies de comptes ne sont plus basées sur les comptes d'ordinateur. Vous pouvez désormais cibler des utilisateurs individuels et des groupes d'utilisateurs pour contrôler leurs restrictions de mot de passe. Il s'agit d'un concept radicalement nouveau pour les administrateurs Windows, puisque nous utilisons les stratégies de comptes pour les comptes d'ordinateur depuis très longtemps.

Stratégies de comptes dans Windows Server 2008
Dans Windows Server 2008, vous n'établirez pas les stratégies de comptes avec la stratégie de domaine par défaut. En fait, vous n'utiliserez pas les objets de stratégie de groupe pour créer des stratégies de comptes pour les comptes d'utilisateur de domaine. Dans Windows Server 2008, vous serez dirigé vers la base de données Active Directory pour effectuer vos modifications. Plus spécifiquement, vous utiliserez un outil comme ADSIEdit pour modifier l'objet Active Directory et ses attributs associés.
La raison de cette modification est que la stratégie de groupe n'est pas conçue pour plusieurs mots de passe dans le même domaine. L'implémentation de la fonctionnalité de mots de passe multiples par domaine dans Windows Server 2008 est attrayante, mais pas tout à fait aussi conviviale qu'on l'aurait souhaitée. Au fil du temps, cependant, l'interface de configuration des paramètres deviendra plus facile d'accès. Pour le moment, vous devez enfiler votre costume de pirate de base de données Active Directory pour apporter des modifications au système.
Vous n'avez pas besoin d'utiliser ADSIEdit pour modifier les paramètres de stratégie de compte si vous préférez le faire d'une autre façon. Vous pouvez utiliser tout autre outil de modification LDAP capable d'opérer dans la base de données Active Directory ou même écrire un script. En implémentant vos stratégies de mot de passe dans Windows Server 2008, votre approche devra être très différente de celle suivie jusqu'à présent. Avec ces nouvelles fonctionnalités, vous devez déterminer quels utilisateurs et quels groupes recevront quels paramètres de mot de passe.
Vous devez réfléchir non seulement à la longueur des mots de passe mais également aux restrictions supplémentaires qui accompagnent les paramètres Stratégies de mots de passe, notamment l'âge minimal et maximal, l'historique, etc. Les autres difficultés concernent notamment le contrôle des paramètres de stratégie de verrouillage d'utilisateur et les paramètres Kerberos. Il existe une relation d'équivalence entre les paramètres Stratégies de comptes courants et ceux configurés dans la base de données Active Directory dans Windows Server 2008. Toutefois, il est important de noter que les noms de chaque paramètre de stratégie sont différents maintenant qu'ils sont des objets et des attributs Active Directory.
Pour implémenter les nouveaux paramètres de mot de passe, vous devez créer un objet Paramètres de mot de passe intitulé msDS-PasswordSettings sous le conteneur Paramètres de mot de passe, dont le chemin est LDAP de « cn=Password Settings,cn=System,dc=domainname,dc=com ». Notez que le niveau fonctionnel du domaine dans lequel vous travaillez doit être défini sur Windows Server 2008. Sous ce nouvel objet, vous allez fournir des informations pour plusieurs attributs, comme illustré à la figure 3.
Figure 3 Attributs de mots de passe dans Active Directory (Close Figure 3)

Nom de l'attribut Active Directory | Description de l'attribut
msDS-PasswordSettingsPrecedence | Détermine ce qui a priorité dans les situations où un utilisateur est membre de plusieurs groupes avec des stratégies de mot de passe différentes.
msDS-PasswordReversibleEncryptionEnabled | Active ou désactive le chiffrement réversible.
msDS-PasswordHistoryLength | Détermine combien de mots de passe doivent être uniques avant qu'un mot de passe puisse être réutilisé.
msDS-PasswordComplexityEnabled | Détermine le nombre et le type de caractères requis dans un mot de passe.
msDS-MinimumPasswordLength | Détermine la durée minimale d'un mot de passe.
msDS-MinimumPasswordAge | Détermine combien de temps un utilisateur doit utiliser un mot de passe avant de le modifier.
msDS-MaximumPasswordAge | Détermine combien de temps un utilisateur peut utiliser un mot de passe avant de devoir le modifier.
msDS-LockoutThreshold | Détermine combien de tentatives manquées de saisie de mot de passe seront autorisées avant le verrouillage du compte d'utilisateur.
msDS-LockoutObservationWindow | Détermine le délai de réinitialisation du compteur de mots de passe incorrects.
msDS-LockoutDuration | Détermine la durée de verrouillage du compte après un nombre excessif d'échecs de tentatives de saisie de mot de passe.
Comme vous pouvez le voir, tous les paramètres Stratégie de groupe relatifs aux paramètres Stratégie de compte sont dupliqués en tant qu'attributs. Notez également la présence d'un paramètre de priorité. Celui-ci est essentiel pour implémenter plusieurs mots de passe dans le même domaine, car des conflits se présenteront sûrement et nécessitent donc un mécanisme pour les traiter.

Ciblage des paramètres Stratégie de compte
Pour chaque objet que vous créez, vous devrez renseigner tous les attributs pour adapter la stratégie de compte à chaque utilisateur. Un nouvel attribut, msDS-PSOAppliesTo, détermine quels objets recevront le jeu de paramètres de stratégie. C'est l'attribut ultime qui vous permet d'affecter des paramètres spécifiques à certains utilisateurs. La liste sous cet attribut être composée d'utilisateurs ou de groupes mais, comme toujours lorsque vous établissez une liste de contrôle d'accès, il est préférable d'utiliser des groupes plutôt que des utilisateurs. Les groupes sont plus stables, plus lisibles et généralement beaucoup plus faciles à traiter.

Hauts les cœurs !
Pendant des années, nous avons tous voulu pouvoir utiliser plusieurs mots de passe dans le même domaine Active Directory, et maintenant nous le pouvons. Plus jamais les utilisateurs d'un domaine entier ne seront tenus au même niveau de sécurité en termes de mots de passe. Désormais, par exemple, les utilisateurs normaux peuvent avoir un mot de passe de 8 caractères et les professionnels de l'informatique (qui peuvent avoir des droits d'administrateur) un mot de passe plus complexe, de 14 caractères.
Il faudra du temps pour s'habituer à accéder à la base de données Active Directory pour définir ou modifier les paramètres Stratégie de compte. Heureusement, cependant, les nouveaux paramètres s'apparentent à ce que vous connaissez déjà. Veillez à explorer ces nouveaux paramètres dès que vous disposerez de Windows Server 2008, car ils entreront sûrement dans la première série de configurations que vous ferez.

Derek Melber, MCSE, CISM, MVP est consultant et formateur indépendant. Il enseigne et promeut la technologie Microsoft, se concentrant en particulier sur Active Directory, les stratégies de groupes, la sécurité et la gestion des postes de travail. Derek a rédigé plusieurs ouvrages informatiques, notamment Microsoft Windows Group Policy Guide (Microsoft Press, 2005). Vous pouvez le contacter à l'adresse derekm@braincore.net.


 Histoires de Bureau: D&#233;ploiement de Windows dans un monde virtuel
Histoires de Bureau
Déploiement de Windows dans un monde virtuel
Wes Miller

L'informatique virtuelle est partout. Si vous ne l'exploitez pas encore, vous manquez quelque chose. La virtualisation réduit la dépendance matérielle en créant une véritable couche d'abstraction matérielle et en permettant de déplacer un ou plusieurs systèmes invités, tels que Windows Server ou des systèmes d'exploitation clients Windows, ce qui inclut les systèmes hôtes.
La virtualisation est, bien sûr, différente de l'émulation dans la mesure où elle n'imite pas le processeur de l'invité. Il représente simplement les ressources du système hôte de façon à ce que les systèmes invités puissent y accéder. Par conséquent, les systèmes hôtes sont génériques par rapport aux invités. Vous pouvez normalement déplacer un invité virtuel d'un système créé par un OEM vers un système différent, créé par un autre OEM. De manière générale, le matériel de l'hôte est sans importance. Il est cependant essentiel de prendre en compte un certain nombre d'éléments. Par exemple, si vous déplacez un invité d'un matériel avec processeur d'un fabriquant donné, tel qu'AMD, vers un autre, tel qu'Intel, vous risquez d'avoir des problèmes (selon la technologie de virtualisation que vous utilisez). Ceci est dû au fait que la technologie d'informatique virtuelle transmet uniquement des informations de l'hôte vers l'invité et inversement. Elle n'émule pas un processeur spécifique pour l'invité (comme c'est le cas, par exemple, d'une solution Microsoft® Virtual PC s'exécutant sur un Macintosh hérité de type PowerPC).
Toutefois, la virtualisation émule bien les composants matériels clés pour l'invité. Dans la plupart des cas, ceci est limité au réseau, à la vidéo (en général un périphérique très contraint sans GPU émulé avancé) et au stockage de masse. Ceci regroupe toutes les fonctions en présentant un ou plusieurs types de périphériques émulés à l'invité. Si vous avez déjà lu mes articles, vous avez sans doute remarqué qu'il s'agit de la même liste de périphériques que celle qui est traitée par Windows® PE. Dans le domaine de la virtualisation, il s'agit bien des types de périphériques indispensables au bon fonctionnement de Windows. De plus, toute technologie de virtualisation doit émuler un BIOS. Ces technologies pourraient également émuler l'interface EFI (Extensible Firmware Interface), mais l'offre limitée de systèmes d'exploitation EFI rendrait ceci d'un intérêt limité. Toute cette émulation permet aux invités virtuels de démarrer. Le BIOS et chacun des périphériques émulent un périphérique réel et le présentent à des invités. Ceci signifie qu'ils nécessitent les mêmes pilotes (pas nécessairement fournis par Windows) que le véritable périphérique. Il est important de conserver ce concept à l'esprit.
Alors que certaines technologies de virtualisation autorisent également les interfaces de périphériques USB (ou USB 2.0), je ne m'étendrai pas sur ces technologies ici. Hormis ces périphériques USB qui nécessitent des pilotes (imprimantes, cartes réseau sans fil USB, et ainsi de suite) ou une certaine forme de prise en charge DirectX® (généralement absent de la plupart des technologies de virtualisation), vous ne devriez pas avoir grand chose à faire pour les faire fonctionner. N'oubliez pas que la prise en charge des périphériques USB ou de tout autre périphérique non émulé dépend, bien sûr, de la technologie de virtualisation que vous utilisez. Vous devez connaître les limitations du produit de virtualisation avant d'essayer de faire fonctionner de nouveaux périphériques.
Il existe actuellement deux grands fournisseurs de technologie de virtualisation sous Windows : Microsoft et VMware (vmware.com). Il faut également mentionner les nouveaux fournisseurs à l'avenir prometteur, tels que Parallels (parallels.com).
Maintenant que nous avons mieux défini la virtualisation, je vais consacrer le reste de cet article à sa configuration, à l'identification des pièges les plus communs et au déploiement sur les différents ordinateurs de votre environnement.

Déploiement virtuel
Le déploiement des systèmes virtuels n'est pas nécessairement différent de celui des systèmes physiques. Mais comme vous allez le constater, il y a de bonnes raisons de préserver des différences.
Lors des débuts de Windows NT®, le déploiement se faisait sous la forme d'une installation. Vous pouviez créer un script à cet effet, mais vous aviez néanmoins à exécuter tout le processus. Une fois l'installation terminée, le concept de copie de cette image sur plusieurs systèmes, était certes pratique, mais n'était tout simplement pas pris en charge.
Depuis, Microsoft a compris qu'il serait intéressant de prendre en charge les systèmes Windows NT dupliqués sur un disque ou « clonés ». Par conséquent, toute méthode disponible lors du déploiement de systèmes physiques est également disponible pour le déploiement d'un système virtuel. Vous pouvez utiliser : Winnt32 (ou setup.exe dans le cas de Windows Vista® et Windows Server® 2008) ; Windows PE (1. x ou 2. x, selon le client que vous déployez et comme expliqué dans mes articles précédents) ; les services d'installation à distance (RIS) ou les services de déploiement de Windows (WDS) ; ou Sysprep (l'outil de préparation système pour le déploiement introduit avec Windows NT 4.0) et votre technologie de duplication de disques préférée (ImageX, par exemple).
Naturellement, ceci ne peut se faire que la première fois que vous déployez un système d'exploitation spécifique. Ensuite, vous avez la possibilité de le copier simplement. Les méthodes de duplication au niveau du disque, telles que celles que je viens de mentionner, présentent un problème.

Utilisation de Sysprep
Le refus initial de Microsoft concernant la prise en charge de la duplication au niveau du disque dépendait principalement de l'identificateur de sécurité de Windows NT (SID). Heureusement, Sysprep a fourni une solution. Mais examinons tout d'abord le problème qu'il résout. Comme exposé dans support.microsoft.com/kb/314828, le SID consiste en un numéro de révision de structure SID (généralement un identifiant unique global, ou GUID) qui identifie un ordinateur Windows. Cet identifiant est ensuite utilisé en tant que section racine de l'identificateur pour tous les comptes locaux. Les comptes locaux ont leur propre identificateur unique, appelé identificateur relatif (RID). Le RID consiste en un identifiant de compte concaténé à la fin du SID. Par conséquent, la combinaison des deux devient l'identificateur des comptes locaux.
Nous allons voir en quoi il s'agit d'un problème en utilisant le SID d'administrateur S-1-5-21-191058668-193157475-1542849698-500. Ici, S-1- 5 est le descripteur qui définit qu'il s'agit bien d'un SID (le S est omniprésent dans la représentation textuelle d'un SID). 1 et 5 représentent le numéro de révision SID de Windows NT et la valeur d'identificateur d'autorité (ici Windows Security). Le reste correspond au SID en tant que tel, ce qui inclut le numéro 500, qui est le mieux connu étant donné qu'il s'agit du compte administrateur de Windows. Le compte Administrateur créé par défaut (et qui ne peut pas être supprimé) sur toutes les installations Windows a un SID qui se termine par 500. Les comptes utilisateur locaux ajoutés à Windows après l'installation commencent l'itération à partir de 1 000.
PSGetSID, disponible dans Windows Sysinternals (mentionné dans mon article PSTools sur technetmagazine.com/issues/2007/03/DesktopFiles), permet d'énumérer un SID pour un utilisateur donné sur un système ou le SID système. Voir la figure 1 pour la sortie de PSGetSID en relation avec le SID de mon système virtuel et le SID de mon compte utilisateur, 1003.
Figure 1 Sortie de PSGetSID pour un SID de système virtuel et le SID du compte utilisateur 1003
Figure 1 Sortie de PSGetSID pour un SID de système virtuel et le SID du compte utilisateur 1003
Dans la mesure où les RID de comptes locaux reposent sur ce SID, le problème qui survient lorsque vous dupliquez le disque d'un système ou copiez simplement une image de machine virtuelle doit être relativement évident. En ne modifiant pas le SID (la tâche principale, mais non exclusive, de Sysprep), vous finissez par obtenir une copie du composant clé qui rend le système Windows unique. Si les systèmes A et B ont le même SID d'administrateur, les utilisateurs de chacun de ces systèmes s'identifient de façon légitime comme étant le même utilisateur. La même chose s'applique à tous les comptes locaux du système B lors de l'authentification sur le système A, et inversement. Pire, ces systèmes auront le même SID lorsqu'ils seront présentés à Active Directory®. Donc, si vous autorisez le système A à s'identifier auprès d'une ressource de domaine, alors que vous le refusez au système B, vous provoquerez une collision. Si vous demandez le refus de B, A sera également refusé.
Ainsi, il est essentiel de régénérer des SID sur les systèmes recourant à Sysprep, surtout dans les scénarios avec systèmes virtuels, car les images système risquent de se propager trop facilement. N'utilisez pas d'outil tiers de modification du SID, limitez-vous à Sysprep. Sysprep est conçu, testé et pris en charge par Microsoft pour la préparation de systèmes à dupliquer, ce qui inclut les systèmes virtuels. Voir la figure 2 pour consulter un exemple de Sysprep avant la modification du SID sur un système. Assurez-vous maintenant que l'option « Ne pas régénérer les identificateurs de sécurité » reste non cochée si l'étape suivante est une étape de préparation à la duplication du système.
Figure 2 L'option "Ne pas régénérer les identificateurs de sécurité" doit rester désactivée lors de la préparation de la duplication.
Figure 2 L'option "Ne pas régénérer les identificateurs de sécurité" doit rester désactivée lors de la préparation de la duplication.
En outre, pour mettre à jour l'identifiant du SID, Sysprep modifie également les magasins de données privés détectés en fonction du SID et du nom de l'ordinateur ou pour modifier leur chiffrement de façon à ce qu'il fonctionne avec le nouvel SID. Parmi les exemples possibles, citons le magasin de données Tâches planifiées et les valeurs de la métabase IIS (si IIS est installé).
Sysprep supprime également d'office toute les cartes réseau du système et les données de configuration correspondantes. Dans la mesure où la configuration réseau repose sur la carte réseau de la base de registres et que la relation de cette carte dépend de son identifiant matériel (ce qui, à l'exception des déplacements d'un système virtuel à l'autre, est susceptible de se rompre), Sysprep nettoie ces données généralement abandonnées.
Sysprep nettoie également les informations d'appartenance à Active Directory du système. Par conséquent, il doit supprimer un système du domaine dans le cadre de son processus. Ceci permet de s'assurer que les systèmes qui viennent de recevoir les nouveaux SID peuvent être joints au domaine de façon sûre. Certains utilitaires de changement de SID permettent de modifier le SID d'un ordinateur sans le supprimer du domaine, mais cette opération n'est ni fiable, ni sécurisée. Si vous devez absolument exécuter Sysprep sur un ordinateur qui appartient à un domaine, supprimez-le du domaine avant d'exécuter Sysprep ou exécutez Sysprep, puis laissez-le gérer cette tâche pour vous.
Pour rester sur la même note, si vous virtualisez l'un de vos contrôleurs de domaine (DC), vous devez dupliquer des systèmes qui sont simplement des serveurs autonomes qui n'ont pas encore été promus en tant que contrôleurs de domaine et ne sont pas joints au domaine. À l'exception de Windows Server 2003 Small Business Server Edition, vous ne pouvez pas dupliquer un disque de contrôleur de domaine de manière sécurisée. Pour créer de nouveaux contrôleurs de domaine de façon sécurisée, vous devez créer une image de disque à partir d'un serveur qui est prêt à être joint au domaine et être promu au statut de contrôleur de domaine. Sysprep (sauf dans le cas de l'instance SBS, très spécialisée, qui est une forêt/un serveur unique), ne sait pas comment modifier de manière sécurisée des SID sur un contrôleur de domaine.
Enfin, en supplément de la modification des SID et de la suppression de l'ordinateur du domaine, Sysprep change également le nom de l'ordinateur.
Il peut sembler superflu de procéder aux tâches ci-dessus lors de la création d'une image, voire la copie, de systèmes virtuels. Elles sont cependant essentielles. Surtout si vous utilisez ces systèmes sur un réseau avec d'autres systèmes, physiques ou virtuels, dans un domaine, ou avec une autre copie de ces derniers sur le réseau.
Si vous n'utilisez pas Sysprep lors de la duplication de systèmes virtuels, vous allez être confronté à toute une série de problèmes évidents (Active Directory ou toute autre collision réseau) et de problèmes que vous ne pouvez pas prévoir. Par exemple, vos images virtuelles sont très exposées au piratage dans la mesure où l'accès à l'une ouvre la voie vers toutes les autres.

Pilotes et couches d'abstraction matérielle
J'ai indiqué plus haut que les périphériques virtuels inclus dans une image virtuelle peuvent ne pas disposer de pilotes intégrés pour Windows. Assurez-vous que vous disposez des pilotes requis pour vos périphériques lors du déploiement (ou lors du déploiement des images de disque avec Sysprep) en prévision de la tristement célèbre erreur 0x0000007B de pilote, qui peut se manifester tout aussi facilement lors du déplacement d'une image virtuelle d'un pilote de bus de stockage à l'autre, que lors de l'utilisation d'un matériel physique. La même chose s'applique aux cartes réseau. Alors que la plupart des produits de virtualisation ont cherché à fournir un périphérique virtuel plutôt universel, vous devez toujours disposer d'un pilote supplémentaire pour ce dernier.
La couche d'abstraction matérielle (HAL) ne se laissera pas ignorer non plus. Dans l'idéal, vous devez créer des machines virtuelles qui prennent en charge les processeurs multiples ACPI (advanced configuration and power interface) (voir intel.com/technology/iapc/acpi), si c'est ce que votre technologie de virtualisation prend en charge. La conversion entre plusieurs HAL n'est pas généralement prise en charge (voir support.microsoft.com/kb/309283 pour plus de détails). Cependant, certaines technologies de virtualisation ou, de façon plus importante, de nombreuses technologies de migration, promettent qu'elles peuvent déplacer de manière sécurisée une installation Windows « non-ACPI » vers une installation ACPI, ou inversement. C'est faux, et en plus, l'installation Windows qui en résulte n'est pas prise en charge par Microsoft en cas de problèmes. Les restrictions qui sont abordées sur la page Web de prise en charge que je viens de mentionner s'appliquent également aux systèmes virtualisés. Voir la figure 3 pour consulter un exemple de HAL dans le Gestionnaire de périphériques de l'une de mes machines virtuelles, dans ce cas avec la couche HAL monoprocesseur ACPI. Ne confondez pas ceci avec un processeur unique, qui est interchangeable avec la variante à processeurs multiples.
Figure 3 HAL dans le Gestionnaire de périphériques d'une machine virtuelle
Figure 3 HAL dans le Gestionnaire de périphériques d'une machine virtuelle

Diverses modifications
Modifiez ce que vous pouvez et acceptez ce que vous ne pouvez pas modifier
Sous l'optique d'une migration de physique vers virtuel et inversement, vous devez conserver à l'esprit les choses qui peuvent et ne peuvent pas changer. Vous pouvez modifier les aspects suivants d'une installation Windows :
  • La couche HAL (mais uniquement de monoprocesseur vers processeurs multiples ou inversement, à condition de reprendre la même configuration d'alimentation).
  • Les contrôleurs de stockage de masse (c'est difficile, mais la plupart des solutions de migration physique vers virtuel tentent cette opération d'office). La plupart des fournisseurs offrent des solutions de stockage IDE et SCSI. Choisissez avec prudence lors du déploiement, car le déplacement de l'un à l'autre n'est pas très facile. En général, la sélection de SCSI produit un périphérique plus fiable (c'est le cas avec la plupart des fournisseurs de mises en œuvre d'émulation de périphérique SCSI).
  • Contrôleur réseau (dans un scénario de migration virtuel vers virtuel, cependant, ceci sera généralement identique au sein des technologies d'un fournisseur).
Vous ne pouvez pas modifier les aspects suivants d'une installation Windows :
  • La couche HAL (sauf dans les cas mentionnés plus haut, lorsque la même configuration d'alimentation s'applique). Vous ne devez pas croire qu'une solution qui effectue ces opérations permet d'obtenir une installation Windows stable ou fiable (et encore plus important, elle ne sera pas prise en charge par Microsoft).

Outre la modification du SID et du nom de l'ordinateur, vous devez également modifier certaines valeurs qui peuvent être propres à la technologie d'informatique virtuelle que vous utilisez. Notamment, vous devez modifier l'adresse MAC (l'identifiant unique pour les périphériques réseau). De plus, de nombreuses applications virtuelles disposent de leur propre identifiant unique. La plupart stockent ces informations dans leurs propres fichiers de configuration de l'ordinateur. Il est donc important de savoir comment manipuler ces entrées (et les conserver valides). La plupart des produits de virtualisation qui prennent en charge PXE (Pre-Boot Execution Environment) entrent l'UUID SMBIOS en fonction de leur propre identifiant unique, ce qui rend impératif cette modification (ou laissez le logiciel de virtualisation procéder à cette modification à votre place, si cette opération est prise en charge) lorsque vous le joignez à un domaine. Sinon, la gestion des systèmes client WDS ou RIS peut devenir impossible (en cas de conflit des GUID). La plupart des solutions de virtualisation que j'ai utilisées peuvent subir de graves problèmes réseau en cas de doublons d'adresses MAC. Par conséquent, si vous ne vous contentez pas de déplacer une machine virtuelle, il est crucial de modifier l'adresse MAC si le logiciel de virtualisation ne le fait pas automatiquement.
Les autres composants à conserver à l'esprit lors de la préparation du déploiement d'un système virtuel sont les disques ou les instantanés liés. Selon votre solution de virtualisation, ceux-ci pourraient être également appelés disques différentiels ou recevoir un autre nom. Si vous exécutez Sysprep pour préparer un système et disposez d'instantanés (ou tout autre état réversible) correspondant au système virtuel, ces derniers doivent être détruits pour que l'image reste sûre, fiable et sécurisée lorsqu'elle est dupliquée. Dans le cas d'un instantané ou toute autre technologie « d'annulation des modifications de disque », le rétablissement d'un instantané risquerait de faire revenir le système à un point où plusieurs systèmes provenant de la machine virtuelle d'origine sont en conflit entre eux (voire le système source d'origine s'il est rétabli). Par conséquent, Sysprep doit être exécuté sur tout instantané ou toute relation différentielle de disques.

Optimisation
La plupart des technologies de virtualisation incluent des ajouts de machines virtuelles ou des outils qui permettent d'améliorer les performances et la qualité de l'interaction avec l'invité à partir de l'hôte. Ceci implique généralement un travail d'optimisation des entrées de la souris et du clavier, ainsi que d'autres améliorations de performance, et inclut souvent une interaction copier/coller (ou autre hôte vers invité) améliorée. Installez la version la plus récente de ces outils sur vos systèmes virtuels avant le déploiement.
Vous devez également vous assurer que la mémoire du client est configurée de façon optimale pour le système d'exploitation de l'invité, mais également dans le contexte des hôtes sur lequel il sera déployé. La dernière chose à faire consiste à déployer une image de Windows XP définie pour utiliser 1 Go de RAM sur les systèmes hôtes qui ne disposent pas de beaucoup de RAM.
Tenez également compte des restrictions actuelles de la plupart des technologies virtuelles. Vos utilisateurs veulent savoir comment interagir avec les périphériques reliés au système virtuel et les applications qui pourront ou ne pourront pas fonctionner sur le système d'exploitation invité (la plupart ne prennent pas en charge DirectX 9 ou 10, par exemple, ou prennent en charge des versions antérieures de façon limitée). Les utilisateurs peuvent ne pas savoir ce que cela signifie ou la façon dont cela se manifeste (certaines applications ne traitent pas très bien ce type de défaillance).

Problèmes au niveau de l'hôte
De manière générale, le PC hôte qui exécute la technologie de virtualisation ne posera pas beaucoup de problèmes, que ce dernier repose sur un système d'exploitation complet ou sur un hyperviseur de type 1 qui s'exécute directement sur le matériel. La plupart des technologies de virtualisation sont conçues pour s'assurer que le système d'exploitation invité ne nécessite aucune information (ou alors très peu) sur l'hôte. Vous devez toutefois savoir quels hôtes sont en cours d'utilisation, en cas de problème sur un invité qui est déplacé d'un hôte à l'autre. Vous devez également connaître les limitations du produit du fournisseur de virtualisation sur certaines plates-formes. Vous pourrez probablement passer d'une plate-forme à l'autre, mais vous risquez de perdre ou d'ajouter certaines fonctionnalités des hyperviseurs de type 2 du système d'exploitation (l'application de virtualisation) au cours du processus.

Autres mécanismes de déploiement
Liens relatifs à Sysprep
Les documents suivants vous apporteront une aide précieuse concernant Sysprep :
  • Conception d'installations à base d'images avec Sysprep
  • Comment utiliser l'outil Sysprep pour automatiser le déploiement de Windows XP
  • Comment utiliser l'outil de préparation du système (Sysprep.exe) pour procéder à la duplication de disques
  • Utilisation de l'outil de préparation du système sur des ordinateurs différents

Le recours à Sysprep ou à la duplication de disques (voire à la simple exécution de Sysprep et la copie de la machine virtuelle) sont des choix évidents lors du déploiement de systèmes virtuels, mais il y a d'autres possibilités. En fait, que vous procédiez avec des images ou une installation, l'utilisation de Windows PE peut se faire plus facilement avec la technologie de virtualisation qu'avec les machines physiques, dans la mesure où vous manipulez des fichiers ISO et non pas un CD physique. Certaines technologies de virtualisation s'adaptent mal aux DVD. Il est donc important de consulter votre fournisseur de virtualisation pour la prise en charge de ce support. Vous pouvez utiliser winnt32 ou setup.exe (avec Windows Vista ou Windows Server 2008), mais il n'y a pas d'avantages spécifiques. Si vous utilisez d'autres technologies de déploiement Microsoft, telles qu'Automated Deployment Services, votre technologie de virtualisation prend en charge PXE pour amorcer le déploiement à partir du réseau, comme si vous utilisiez RIS ou WDS.

Migration
Enfin, à moins de devoir faire migrer tout un PC, pensez à l'outil USMT (User State Migration Tool). USMT permet de déplacer les paramètres d'un utilisateur d'un client physique vers un nouveau système virtuel facilement. Par conséquent, si vos utilisateurs souhaitent faire migrer leurs anciennes données vers une nouvelle machine virtuelle vous pouvez, par exemple, obtenir facilement les fichiers et les paramètres de Windows XP, les stocker sur une UNC, puis les pousser sur une nouvelle machine virtuelle.

Wes Miller vit à Austin, au Texas. Auparavant, il a travaillé chez Winternals Software à Austin et chez Microsoft en tant que responsable de programme et responsable de produit pour Windows. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.


 Sur le terrain: Le futur fongible
Sur le terrain
Le futur fongible
Romi Mahajan

Karl Marx, philosophe et économiste, a écrit, dans un de ses traités, que « tout ce qui est solide se dissout dans l’air », en parlant de l'évolution des relations entre les catégories sociales liée à la montée de l'industrialisation et du capitalisme dans l'Europe du dix-neuvième siècle. L'idée que les divisions et les catégories ne s'ossifient jamais complètement se manifeste de diverses façons et dans divers contextes, notamment dans le monde de la technologie, monde dans lequel la seule constante est le changement.
L'un des meilleurs exemples illustrant la rapidité du changement (et le défi qu'il représente pour nous) est la montée de la technologie grand public. En fait, l'informatique s'est « consumérisée » et les principaux indicateurs de changement concernent surtout la vie personnelle, avec des effets énormes sur la société et le monde des affaires. Ce phénomène se manifeste sous plusieurs formes :
  1. Le monde du Web 2.0 concerne l'Internet de lecture/écriture ; l'écriture sur Internet est presque exclusivement liée au rôle de l'écrivain en tant que consommateur.
  2. Les applications et technologies grand public créent un effet de « halo » pour les entreprises.
  3. La principaux éléments d'Internet sont étudiés et testés en raison de la « consumérisation » de l'informatique.
  4. Les services informatiques tels que les services de support technique doivent s'accommoder, et tirer les enseignements, de la distinction sans cesse plus floue entre les technologies à usage domestique et les technologies destinées aux entreprises.
  5. Les décideurs sont tout autant des professionnels que des consommateurs.
  6. La technologie « préférée » d'une personne est presque toujours un produit de consommation, et non pas un produit destiné à l'entreprise.
Les implications sont très importantes, et les catégories sont interchangeables, comme vous le feront comprendre ces quelques exemples. Un de mes amis travaillant dans une entreprise technologique m'a avoué que 8 % de tous les appels passés au support technique dans son entreprise sont liés aux mises à jour iTunes. Le livre blanc de Cisco « L'Ère de l'Exaoctet » commence par deux constatations : Internet ne s'effondre pas sous le poids du flux vidéo et YouTube n'en est que le début. D'après un rapport de NDP Group, Apple Corporation s'est accaparé presque 10 % du marché des ventes de portables aux particuliers durant le mois de mars 2007, du fait de l'effet de halo de l'iPod. Microsoft investit lourdement dans les domaines du jeu, de la musique, de la photographie numérique et de l'hébergement vidéo. Enfin, les entreprises organisent aujourd'hui des réunions dans Second Life (portail de jeu).
De plus, par leur entrée dans le vocabulaire courant, les marques technologiques ont atteint un statut de permanence. On « Google » des sujets, on écoute son iPod, on s'expose sur myspace, on joue à la « Xbox® ». Une relation affective s'est créée entre les personnes et leurs technologies, et l'effet se fait sentir au bureau comme à la maison, et dans le respect que l'on éprouve pour les entreprises qui créent ces périphériques, applications, sites Web et communautés. Les perceptions, bonnes, mauvaises ou neutres, que nous créons restent avec nous, dans nos incarnations personnelles aussi bien que professionnelles.
Ce qui importe à une personne est donc quelque chose de complexe. Un changement de culture radical est nécessaire si les entreprises doivent relever les défis simultanés qui consistent à adapter leurs messages, à faire preuve d'intimité et à s'occuper de leurs clients. Auparavant, avant la spécialisation dans les rôles, les messages génériques étaient la substance du marketing. Inversement, depuis quelques années, la messagerie « orientée » fait fureur, et toutes les catégories doivent avoir une précision de laser, qu'il s'agisse d'un intitulé de poste, type d'audience, taille d'entreprise ou technologie spécifique. Ce qui a été perdu, toutefois, est le fait que tout qui est solide se dissout dans l'air, et la seule façon d'établir un contact avec les gens et d'être à la pointe du développement est de faire appel à leurs incarnations en tant que personnes et consommateurs.
Être fongible signifie être interchangeable et ne pas effectuer de distinctions précises entre les catégories. En d'autres termes, nous ne pouvons plus créer de cloisons entre les notions de technologies grand public et technologies d'entreprise. La « consumérisation » de l'informatique est arrivée, et l'avenir est certainement fongible.

Romi Mahajan est directeur marketing pour l'équipe Technical Audience and Platform Marketing chez Microsoft. Romi a publié plusieurs ouvrages dans de nombreux domaines, notamment le domaine de la politique, de l'environnement, de la technologie et de la sociologie.


 La vie secr&#232;te de Windows: Un joystick n'a pas besoin d'&#234;tre un micro-ondes
La vie secrète de Windows
Un joystick n'a pas besoin d'être un micro-ondes
Raymond Chen

Je lisais récemment un blog envoyé par un de mes collègues, The Audio Fool, et il m'a fait penser à une erreur que j'ai faite il y a plusieurs années et qui n'a pas cessé de m'ennuyer depuis. Lorsque l'interface du joystick à retour de force DirectInput® était en conception, les fabricants de ce produit ont été invités au bureau Microsoft de Redmond, dans l'État de Washington, afin d'examiner les détails de l'interface proposée et faire part de leurs commentaires.
Plusieurs points ont été débattus durant ces réunions, mais ce dont je me rappelle le plus, c'était un désaccord sur les forces périodiques et s'il fallait parler de période ou de fréquence. L'un des fournisseurs présents n'était pas du tout content parce que son entreprise avait déjà écrit un pilote qui se référait aux forces périodiques en termes de fréquence, et il ne voulait aucun changement à ce sujet. Étant donné que le but de cette réunion était de s'entendre sur une interface tout neuve, comment un fournisseur, quel qu'il soit, pouvait-il s'attendre à quitter la réunion sans avoir à apporter une modification quelconque à son pilote ?
Ce fournisseur s'est tellement plaint que nous avons fini par consentir à utiliser le terme fréquence au lieu de période pour exprimer le taux des forces périodiques. Après tout, le choix des termes n'était pas vraiment important dans ce cas-là. Une force d'une fréquence de 10 oscillations par seconde est identique à une force d'une période d'un dixième de seconde. La période est exactement l'inverse de la fréquence.
Euh, cela n'est pas tout à fait vrai ! La période a été exprimée en millisecondes, ce qui donne une plage dynamique comprise entre 1 ms et un tout petit moins de 50 jours. Une période de 50 jours est insignifiante sur une échelle de vie humaine, et une période de 1 ms est si rapide qu'elle ne compte même pas comme un phénomène périodique. Elle est plutôt perçue comme un ton de musique.
D'un autre côté, la fréquence a été exprimée en hertz, ce qui donne une plage dynamique comprise entre 1 Hz et 4 milliards de cycles par seconde. Étrange de jouer de la musique sur votre joystick, non ? Imaginez des forces qui équivalent à la bande de fréquences d'un micro-ondes !
Le problème est que la puissance expressive et pratiquement inutile de la bande de fréquence supérieure est obtenue aux dépens de la bande de fréquence inférieure. Il s'avère que les simulateurs de vol raffolent des forces périodiques avec des périodes comparativement longues. Je ne suis pas sûr de la physique derrière la théorie, mais on m'a dit que l'un des problèmes auxquels les pilotes doivent faire face est une force périodique lente, de l'ordre de quelques minutes, sur le joystick. L'avion a une tendance naturelle à voyager en suivant une onde sinusoïdale verticale très lente, et les pilotes doivent prendre des mesures pour neutraliser cette tendance afin de maintenir un vol en palier. Si le taux de la force était exprimé en période, le programme du simulateur de vol pourrait spécifier une période de 120 000 millisecondes. En tant que fréquence, toutefois, elle est de 0,0083 hertz, ce qui est beaucoup plus lent que la plus lente fréquence qui puisse être exprimée dans l'interface du pilote, à savoir 1 Hz. Donc, la force la plus lente qu'un simulateur de vol puisse demander est une force qui se répète toutes les secondes, ce qui est assez rapide par rapport à l'effet physique que le simulateur de vol veut imiter.
Étant donné que ce problème n'a pas cessé de m'importuner durant toutes ces années, j'ai récemment jeté un coup d'œil sur la documentation liée au retour de force. À ma grande surprise, il paraît que la structure BIPÉRIODIQUE utilise le terme période au lieu de fréquence pour exprimer des effets périodiques. (En plus, elle utilise des microsecondes, ce qui signifie que vous pouvez désormais jouer de la musique ou piloter un avion). Ou l'erreur a été corrigée ou je deviens sénile et ma mémoire me joue des tours. De toutes manières, je n'ai plus à me soucier de cette erreur, même si elle ne s'est plus jamais produite !

Raymond Chen, The Old New Thing, et son livre du même titre (Addison-Wesley, 2007) traitent de l’historique de Windows et de la programmation Win32. Cette couleur vous va à merveille.