février 2011 - Posts

[Service Packs] - Le SP1 de Windows 7 et Windows Server 2008 R2 est en RTM!

   

 

Le SP1 (Service Pack 1) de Windows 7 et Windows Server 2008 R2 est disponible en RTM (Release To Manufacturing) depuis le 16 février dernier pour les abonnés MSDN, Technet et programme TAP (Technical Adoption Program) et depuis le 22 février pour le grand public (diffusé via Windows Update!) ou en le téléchargeant manuellement.

Note : Ce programme TAP est un nouveau programme créé par la firme de Redmond. Les clients français sélectionnés pour le TAP bénéficieront d'une assistance technique sur le produit, sur son mode de déploiement et sur les problématiques de compatibilité applicative. Ils auront aussi accès - en avance de phase - aux informations techniques sur Windows 7 et se verront invités à cinq sessions d'information et d'échanges sur Windows 7. En France, Osiatis a été retenu par Microsoft en tant que 'Preferred Partner Integrator' pour le nouveau programme TAP (Technical Adoption Program) Windows 7. Dans ce cadre, la SSII française accompagne Microsoft pour faire découvrir à une trentaine de grandes entreprises hexagonales les apports de Windows 7, dans le but d'obtenir des premiers retours d'expérience et de parachever les nombreuses innovations de ce produit pour les entreprises.

Ce SP1 (commun aux deux systèmes d'exploitation) comprend pas moins de 800 hotfix et patchs de sécurité. Il intégre 2 nouvelles fonctionnalités de virtualisation s'appuyant sur Windows Server 2008 R2.

 

  • Côté Windows 7

Même si l'utilisateur a son système à jour, l'application du SP1 pour Windows 7 via Windows Update prend environ 30 minutes avec le téléchargement de 44 Mo pour la version 32-bit du système d'exploitation et 74 Mo pour la version 64-bit.

 * Quelles sont les changements côté clients (en sus des MAJ cumulatives) ?

     - Amélioration des performances avec du matériel audio HDMI.

     - Amélioration des impressions XPS (Via la visionneuse XPS présente par défaut dans Windows 7, l'impression pouvait ne se faire qu'en tenant compte d'un seul mode d'affichage - portrait - et non des deux).

     - Modification du comportement de la fonction "Restaurer les versions précédentes" des dossiers de l'explorateur Windows (Avant le SP1, les dossiers pouvaient être restaurés dans une position en cascade basée sur l'emplacement du dossier actif le plus récent. Avec le SP1, tous les dossiers sont restaurés dans leurs positions précédentes).

 

  • Côté Windows Server 2008 R2

 * Amélioration de la prise en charge des processeurs Itanium

 * Dynamic Memory

Cette fonctionnalité utilise la technique de "balloning" (déjà présente chez VMware ESX - vSphere). Le ballooning est une technique qui permet de "gonfler" ou de "dégonfler" un "ballon" dans la mémoire de la machine virtuelle de façon à recycler la mémoire non utilisée. Cette mémoire récupérée est alors disponible pour d'autres machines.

Si la machine nécessite de nouveau de la mémoire, le "ballon" est alors "dégonflé".

Lors de la création de votre machine virtuelles, vous aurez la possibilité de définir la quantité de mémoire minimale allouée ainsi que la quantité de mémoire maximale adressable. Dans le cas ou la machine nécessite plus de mémoire que ce qui aura été définit à minima, celle ci pourra agrandir son espace adressable en récupérant la mémoire physique soit directement dans la mémoire libre du serveur Hyper-V, soit en récupérant celle inutilisée des autres machines virtuelles présentes sur le même serveur.

Cette technique qui permet d'augmenter la densité des machines virtuelles à l'avantage d'être simple et peut coûteuse en ressources pour l'hyperviseur (OverHead réduit). L'OverHead désigne le temps passé par un système à ne rien faire d'autre que de se gérer.

Les VMs (Virtual Machines) qui supporteront cette fonctionnalité côté client sont;

  - Windows 7 Enterprise (32-bit & 64-bit)

  - Windows 7 Ultimate (32-bit & 64-bit)

  - Windows Vista Enterprise (32-bit & 64-bit)

  - Windows Vista Ultimate (32-bit & 64-bit)

Les VMs (Virtual Machines) qui supporteront cette fonctionnalité côté serveur sont;

  - Windows 2008 R2 Web Edition SP1

  - Windows 2008 R2 Standard Edition SP1

  - Windows 2008 R2 Enterprise Edition (support natif)

  - Windows 2008 R2 Datacenter Edition (support natif)

  - Windows 2008 (toutes éditions - avec hotfix)

  - Windows 2003 & 2003 R2 (toutes éditions - support natif)

 

 * RemoteFX

Cette technologie virtualise le GPU (Graphic Processor Unit) à la manière des CPU, permettant du coup aux machines virtuelles d'accéder à des fonctions d'accélération graphiques. L'intégration des technologies issues du rachat de Calista apportent une expérience "riche" aux clients RDP qui accèdent à leur machine virtuelles hébergées sur Hyper-V.

Deux façons d'utiliser la fonctionnalité RemoteFX;

  • en mode Remote Desktop Services amélioration du transfert des bitmaps (applications Flash, Silverlight, 3D etc…)
  • en mode VDI - Virtual Desktop Infrastructure avec Hyper-V, mise à disposition d’une carte 3D au sein des machines virtuelles ou bien la redirection des périphériques USB


Si l'expérience utilisateur est l'un des éléments clefs dans l'adoption des postes de travail virtualisés, Microsoft consolide son partenariat avec Citrix en annonçant l'intégration de RemoteFX avec Xen Desktop et HDX (qui viendra compléter RemoteFX pour les réseaux à faible débit et forte latence).

 

Quelques commandes & outils utiles :

  - Désinstallation du SP1 - wusa.exe /uninstall /kb:976932

  - Suppression des packages d'installation - dism /online /cleanup-image /spsuperseded

  - Empêcher l'installation du SP1 de Windows 7 - Windows 7 Service Pack Blocker ToolKit (Windows 7 Service Pack Blocker Tool Kit est un outil proposé par Microsoft. Le fichier téléchargé est une achive auto-extractible contenant trois fichiers différents. Un exécutable pour tous les utilisateurs, un script à utiliser en ligne de commande et un template ADM. Le blocage de l'installation du service pack par Windows Update fonctionnera jusqu'à an après la mise à disposition de le version finale de Windows 7 SP1, soit jusqu'au 22 Février 2012.)

 

Ressources :

Documentation de Windows 7 et Windows Server 2008 R2 Service Pack 1

Mise en oeuvre de RemoteFX dans un environnement VDI

Windows Server 2008 R2 Hyper-V Component Architecture (with Service Pack 1)

Hyper-V - Demo - Dynamic Memory & RemoteFX

 

Téléchargements :

Windows 7 and Windows Server 2008 R2 Service Pack 1

Windows Server 2008 R2 Service Pack 1 Multilingual User Interface Language Packs

Windows Server 2008 R2 with Service Pack 1 for Itanium-Based Systems Evaluation (180 days)

 

Support Microsoft - Technologie RemoteFX :

Erreur « pilote d'affichage ne répond plus mais a récupéré » dans un ordinateur basé sur Windows 7 SP1 virtuel qui possède une carte vidéo RemoteFX

A RemoteFX VM does not start, and you receive the error "Microsoft Synthetic 3D Display Controller: Failed to Power on" when you try to add the RemoteFX 3D Video adapter from Hyper-V settings

Dans Windows Server 2008 R2 Service Pack 1, les machines virtuelles RemoteFX ne peut pas démarrer et vous recevez une erreur: « Échec d'alimentation sur avec l'erreur « ressources système insuffisantes existent pour terminer le service demandé » »

Error message when you try to start a RemoteFX-enabled virtual machine: "Microsoft Synthetic 3D Display Controller : Failed to Power on with Error 'Insufficient system resources exist to complete the requested service'"

Dans Windows Server 2008 R2 Service Pack 1, les machines virtuelles RemoteFX ne peut pas démarrer si la carte serveur Hyper-V a été modifiée

Nouvelles et existantes les machines virtuelles utilisant RemoteFX ne démarrent pas sur un contrôleur de domaine qui exécute le service hôte de virtualisation Bureau à distance dans Windows Server 2008 R2 Service Pack 1

 

[Active Directory] - Active Directory et la synchronisation temporelle de forêt

Pour que la réplication se passe sans encombre, Active Directory requiert que tous ses contrôleurs de domaine se mettent plus ou moins d'accord sur une référence de date et d'horaire...ils ne doivent pas être absolument synchronisés (comme on pourrait le penser!) mais doivent être assez proches. En effet, Kerberos échouera si un contrôleur de domaine et le système qui tente de communiquer (et donc l'utiliser) pour s'authentifier ne s'accordent pas sur l'heure à moins de cinq minutes près!!

Note : Sous NT4 (et les versions antérieures), l'établissement d'une synchronisation temporelle dans un domaine était difficile à accomplir. Windows 2000 et supérieur incluent un service appelé "Service de temps Windows" qui synchronise toutes vos stations de travail et tous vos serveurs.

 

Les ordinateurs dans un annuaire Active Directory restent synchronisés de cette manière. Le maître d'opérations (FSMO en anglais) - émulateur PDC de la racine de la forêt (premier contrôleur de domaine du premier domaine créé) est le serveur de temps maître. Tous les autres serveurs créent automatiquement une hiérarchie pour convoyer les informations de synchronisation temporelle. Ils sont donc synchronisés par le serveur qui se trouve directement au dessus d'eux.

Note : Nous nous basons ici entièrement sur l'architecture Active Directory, votre infrastructure peut également se reposer sur des serveurs de temps UNIX ou autre qui synchronisera alors votre annuaire AD.


Quelques points fondamentaux;

* Les serveurs membres et stations de travail se synchronisent avec les DC (Domain Controller) qui les ont authentifiés.

* Les DC se tournent tous vers le DC de leur domaine qui prend en charge le rôle FSMO - PDC.

* S'il y a plusieurs domaines dans la forêt, il y a plusieurs émulateurs PDC (1 par domaine). Les émulateurs doivent donc se mettre d'accord sur le temps et choisissent l'un des leurs comme "source" - l'émulateur PDC du premier domaine de la forêt (donc du domaine racine). C'est donc l'émulateur PDC du domaine racine de la forêt qui représente l'autorité ultime pour la synchronisation temporelle.

Note : Pour connaître et comprendre l'utilité de chaque FSMO dans une architecture Active Directory, vous pouvez consulter mon article ici.

 

  • Mais qui synchronise alors l'émulateur PDC de la racine de la forêt?

Aussi étrange que cela puisse paraître; vous n'êtes pas obligé de synchroniser ce rôle FSMO! Tout ce qui compte pour AD, c'est que l'ensemble des serveurs se fixe un même repère temporel (donc notre fameux FSMO - PDC du domaine racine de la forêt).

Certes, on peut trouver plus plaisant qu'il s'agisse de l'heure effective mais ce n'est pas nécessaire. Si la totalité de votre entreprise possède 10 minutes d'avance sur le reste du monde :D cela ne posera aucun problème à AD!

  Il est toutefois très important que vous définissiez correctement les zones temporelles sur tous vos systèmes! AD stocke et synchronise les données temporelles en "temps universel". Ainsi, AD s'articule toujours sur l'axe temporel de Londres (notre bon et vieux Greenwich GMT - Greenwich Mean Time! qui a servit de référence temporelle au 20e siècle avant d'être remplacé par le temps universel coordonné - UTC au début des années 70. Par abus de langage, GMT est souvent employé comme synonyme du fuseau horaire UTC+0. A savoir que GMT est basé sur la rotation terrestre alors que UTC est basé sur le temps atomique international...mais revenons sur Active Directory et notre synchronisation temporelle! - juste pour finir il y a environ 340 horloges atomiques dans le monde dont 20 en France...maintenant que vous savez tout ça vous n'avez plus le droit d'être en retard :) ).

Depuis Windows 2000, les systèmes d'exploitations Microsoft utilisent le système des zones de temps pour décoder les données de temps de l'horloge système et afficher les informations temporelles sous une forme qui soit compréhensible. Si vous deviez abandonner la zone de temps universelle et vous caler sur les horaires du Pacifique en réglant l'horloge système sur l'heure locale, chacun de ces systèmes considérerait que le temps est décalé de plusieurs heures et la synchronisation échouerait. En pratique, vous observeriez un DC et un client dont les données temporelles sembleraient parfaitement identiques (seules leurs zones de temps étant paramétrées différemment) et leur impossibilité à communiquer paraîtrait un joli mystère.

Pour vérifier la zone temporelle d'un système, ouvrez l'invite de commande et tapez w32tm/tz

 

Autant faire les choses correctement jusqu'au bout, donc, et synchroniser notre PDC racine depuis une source fiable. Vous pourriez très bien utiliser une horloge atomique, l'une de celle qui coûtent aux alentours de 100€ l'unité... et lire l'heure officielle à partir de signaux de Paris ou économiser et gagner du temps en exploitant une autre source...Internet!

 

  • Outils Windows Time

La suite de standards Internet propose un moyen de partager des informations de temps à travers le protocole SNTP (Simple Network Time Protocol - actuellement en version 4 - RFC 4330). Un très grand nombre d'ordinateurs sur Internet font office de serveurs SNTP et fournissent des informations de temps à n'importe quel ordinateur exécutant un client SNTP. Les systèmes depuis Windows 2000 incluent justement un client SNTP, AD utilise ce protocole pour synchroniser ses clients.

 * Clients Windows XP/2003/Vista/2008/7/2008 R2

Win32 Time Client - w32tm

 * Clients Windows 2000

Net Time

 * Clients Windows NT

Ressource Kit

 * Clients Windows 95/98

ClockWatch Client

 

Note : Sous Windows 7 et 2008, les commandes net time /querysntp et net time /setsntp sont obsolètes.

Pour synchroniser votre client avec le serveur de temps sur un domaine Active Directory, ouvrez l'invite de commande et tapez w32tm /resync

Pour synchroniser votre client avec des serveurs de temps externe, ouvez l'invite de commande et tapez w32tm /config /syncfromflags:manual /manualpeerlist: NOM_DNS

Pour que vos commandes retournent un résultat, le service "Temps Windows" doit être démarré à l'aide de la commande net start w32time

 

 

Le service NTP requiert que le port 123 soit ouvert sur votre firewall. La réponse est alors envoyée sous forme d'un paquet de données UDP/IP au format NTP.

Par défaut, le FSMO PDC de la racine de la forêt tentera de se synchroniser avec sa source de temps une fois toutes les 45 minutes jusqu'à ce qu'il y parvienne. Il reprend cette opération 45 minutes plus tard, et encore 45 minutes après. Il continue de se synchroniser toutes les 45 minutes jusqu'à ce qu'il y soit parvenu 3 fois d'affilée. Ensuite, il réduit se fréquence de connexion pour un intervalle de 8 heures.

Ce paramètre est modifiable via le registre. Tous les paramètres sont stockés dans HKLM\System\CurrentControlSet\services\W32Time\Parameters

 

Si vous souhaitez activer l'enregistrement de débogage pour le service de temps Windows, vous devez modifier quelques paramètres au niveau de la branche de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config et créé 3 nouvelles clés de registres;

 * Value Name: FileLogSize        //Taille du fichier de log en octets
   Data Type: DWORD
   Value data: 10000000

 * Value name: FileLogName     //Emplacement du fichier de log
   Data Type: String
   Value data: C:\Windows\Temp\w32time.log

 * Value name: FileLogEntries   //Niveau de détails du fichier de log (0-300)
   Data Type: String
   Value: 0-116

 

Autres paramètres Win32Time

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time   //Paramètres globaux du service W32Time

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NTPClient\SpecialPollInterval   //Intervalle de temps de communication entre le client et le serveur NTP (900 secondes recommandées soit 15 minutes)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer   //Liste des serveurs de temps externe