En revanche, pour de nombreuses opérations courantes qui devraient être réalisées manuellement sur différents objets (boites, banques, connecteurs, serveurs,…), voici un guide des quelques instructions de base et de la méthode à utiliser.

Exemple : on souhaite augmenter la taille des messages autorisés de 10 Mo à 20 Mo sur tous les connecteurs de réception actuellement limités à 10 Mo sans modifier les autres!

Etape 1) Déterminer les objets sur lesquels porte l’action souhaitée.

Get-receiveconnector

=>    Cette instruction vous donne la liste de tous les connecteurs de réception

Etape 2) Déterminer le champ ou les champs qui vous intéressent

Get-receiveconnector “Nom d’un  connecteur”| fl |more

=>     Cette instruction indique tous les champs et valeurs actuelles du connecteur  choisi.

FL affiche un champ par ligne.

MORE bloque l’affichage si le nombre de lignes est trop important et permet d’avancer par ligne ou par page.

Attention, le nom doit être encadré par des guillemets s’il comporte des espaces.

Dans notre cas, c’est la taille qui nous intéresse que l’on retrouve sous le nom  »MaxMessageSize ».

Etape  3) Vérifier les valeurs du champ choisi pour l’ensemble des objets

Get-receiveconnector |ft name,MaxMessageSize

FT affiche un tableau comportant tous les connecteurs et les champs indiqués.

Etape 4) Filtrer le résultat pour toucher que les objets à modifier.

Dans ce notre cas, il y aura 2 filtrages différents à réaliser : Le premier pour supprimer les connecteurs SMTP réservés aux « clients SMTP» utilisant le port 587. Le 2^ème pour ne garder que les connecteurs ne possédant la bonne valeur.

Get-receiveconnector| where  {$_.name –match “default”  }

Get-receiveconnector | where { $_.name –match “default”} |where { $_.MaxMessageSize –eq 10MB }

Etape 5) Modifier la valeur sur les objets sélectionnés.

Enchainer l’instruction de modification à la commande précédente :

Get-receiveconnector | where { $_.name –match “default”} |where { $_.MaxMessageSize –eq 10240 }|set-receiveconnector –MaxMessageSize 20MB

Etape  6) Vérifier le résultat global et comparer rapport à l’étape 3

Get-receiveconnector |ft name, MaxMessageSize

Il est bien entendu très utile de conserver le script obtenu, pas forcément au format PS1, afin de l’adapter aux futurs besoins.

Juniper, via sa gamme WX/WXC fournir offre une réponse alternative à la course au débit via 3 mécanismes :

I) La QOS permet après identification des flux et application prioritaire d’établir un ordonnancement, celui ci  est effectuée par la création de classe (high, medium, low par exemple). Dans chaque les applications seront définies (messagerie, citrix, filer,…).

Plusieurs méthode d’application sont disponible suivant la topologie des applications et des besoins de qualité de service que l’on veut appliquer sur ces liens réseaux.

• Strict Priority (WSP) : avec cette méthode les files d’attente sont créés pour chaque classe. La classe la plus haute obtient toute la bande passante nécessaire, le reste étant alloué en fonction des classes ayant une priorité inférieure.

• Weighted Fair Queuing (WFQ) : avec cette méthode, les files d’attente sont créées pour chaque classe. La classe la plus haute obtient une ration plus important de bande passante que les classes inférieures.

WFQ

Pour plus d’information.

II) Caching : la mise en cache est le fait de re-connaitre une information déjà transmise précédemment. Le cache est stocké sur un disque dur, dont la compression est activée. Les gains trafic sont considérables sur certaine période, mise à jour antivirus, patch sur les postes client, pièce jointe des mails, ….

Pour plus d’information.

III) TCP accélération : valable pour les échanges CIFS, MAPI (Exchange 2003), HTTP, l’axe d’amélioration est l’augmentation de la ‘TCP windows size ».

La mise en place de boitier de compression, de chaque extrémité de la liaison (WAN & MAN), sur votre architecture doit être une réflexion global en abordant :

• les débits
• schéma des ressources et clients
• définition des classes (high, medium, low)
• définition des applications
• la redondance souhaitée

La rentabilité de l’investissement peut être assez court, en effet si vous vous posez la question d’augmenter des débits sur vos liens WAN/MAN.

La mise ne place de boitier de compression  peut aussi s’inscrire dans une démarche de centralisation des infrastructures.

Or Windows 20088 R2 n’est à présent uniquement disponible qu’en version 64 bits. Jusque-là aucun problème évident à l’horizon.

Vous décidez donc de créer une nouvelle machine virtuelle pour y installer Windows 2008 R2. La création se réalise sans problème jusqu’à l’installation de l’OS. A cet instant lors du démarrage de l’installation vous récupérez un message d’erreur vous indiquant de manière peu explicite que votre processeur ne peut gérer ce type d’OS.

Je parle ici de message peu explicite car en fait en modifiant un paramètre dans votre BIOS (pour les machines relativement récentes), le problème n’en sera plus un.

Il vous suffit donc de rentrer dans le BIOS de votre machine, ensuite le comportement est différent suivant les constructeurs :

Pour DELL :

1. Depress the F12 key when boot menu text appears at startup
   
2. Select BIOS setup and depress the Enter key
   
3. Using the mouse, expand the Virtualization Support menu item by clicking on the plus to the left of Virtualization Support and select Virtualization
   
4. Check the Enable Intel Virtualization Technology checkbox
   
5. Click Apply
   
6. Click Exit
   
7. Fully shut down (power off), wait a few seconds, and restart your computer
   

Pour HP :

1. Depress Esc key when prompted at startup
   
2. Depress the F10 key to Configure BIOS
   
3. Scroll to System Configuration using the arrow keys
   
4. Select Virtualization Technology and depress the Enter key
   
5. Select Enabled and depress the Enter key
   
6. Depress the F10 key to save and exit
   
7. Select Yes and depress the Enter key
   
8. Fully shut down (power off), wait a few seconds, and restart your computer
   

Pour d’autres constructeurs: http://www.microsoft.com/windows/virtual-pc/support/configure-bios.aspx

Pour Sony Vaio : http://www.presence-pc.com/actualite/vaio-vtx-37178/

Cette option spécifie si un programme de virtualisation (Virtual Machine Monitor ou VMM) peut utiliser ou non des capacités matérielles supplémentaires fournies par la technologie Intel Virtualisation (VT). Cette technologie améliore les performances ainsi que la robustesse des solutions de virtualisation et permet donc la gestion matérielle de la virtualisation.

Une fois redémarré, vous pourrez à présent installer votre machine virtuelle en Windows 2008 R2 64bits

Il existe également un outil vous permettant de savoir si votre PC supporte ce type de virtualisation. Cet outil est téléchargeable à ICI. C’est un outil Microsoft donc valable également pour HYPER V, Virtual PC…..

Bonne virtualisation !

L’option de tout virtualiser  ou presque fait maintenant son chemin et se concrétise dans de nombreuses architectures basées sur cette solution.

Les contraintes

Tout n’est pas virtualisable : Par exemple, le rôle de messagerie unifiée n’est pas supporté par Microsoft. Le support Microsoft n’est pas indispensable pour tous. Néanmoins, à l’usage,  on se rend compte qu’à partir d’un certain nombre d’utilisateurs,  le service n’est pas réellement exploitable (voix saccadée,…).

Pourtant, HyperV installe une couche de communication réseau permettant aux machines d’émuler une carte réseau à 10 Go qui utilise un bus virtuel (VMBUS), mais cette vitesse est purement interne, entre les différentes machines et la machine hôte.

Par ailleurs, tous les rôles ne se virtualisent pas avec la même facilité !

Il est facile et très intéressant de migrer les rôles CAS (frontal d’accès) et HUB (transport SMTP). La configuration peut facilement être dupliquée, les serveurs peuvent être installés en fonction des besoins, des sites, ce qui apporte une souplesse  inégalée.

Les serveurs qui utilisent des espaces disques importants ne sont pas réputés pour être de bons candidats à la virtualisation. Les serveurs de boîtes aux lettres (Rôle MAILBOX) entrent dans cette catégorie.  Lorsque le nombre d’utilisateur et la taille des banques d’information restent raisonnables, il n’y a aucun problème à migrer le serveur Mailbox sur HyperV.  Plusieurs solutions permettent de lever en grande partie ce problème :

-          L’utilisation de disque virtuel VHD de taille fixe. Le fait de bloquer l’espace utilisé pour le stockage des bases Exchange permet d’éviter la fragmentation sur le disque du serveur hôte.

-          L’utilisation directe d’un volume (partition) du serveur hôte, qui sera dédié à la machine virtuelle Exchange.

-          L’utilisation de disques iSCSI proposés par Windows Storage Server ou par des baies iSCSI.  L’augmentation croissante des systèmes utilisant le iSCSI pour accéder à des disques distants permet maintenant d’envisager des configurations de toute taille, avec des possibilités de reprises (Avec ou sans cluster) de manière inouïe. La fourniture par Microsoft du composant (Driver) iSCSI initiator dans tous les nouveaux systèmes (Windows 7, Windows 2008 et Windows 2008 R2) facilite largement cette adoption.

Les disques iSCSI permettent aussi de dépasser la limite des 2040 GO (2 TO) des fichiers VHD.

Les contraintes spécifiques liées à HyperV et Exchange 2007 sont bien décrites sur le site Microsoft. En revanche, il est important de savoir qu’il ne faut pas utiliser simultanément le clustering de HyperV et le clustering de Exchange 2007. Par ailleurs, l’utilisation des systèmes de captures en temps réel et de migration « live » ne sont pas non plus supportés par Exchange!

Les avantages

La virtualisation permet d’éliminer tous les problèmes liés à juxtaposition de plusieurs logiciels ou fonctions sur un seul ordinateur physique qui parfois ne sont mêmes pas compatibles.

Par ailleurs, la séparation permet de configurer, contrôler et optimiser chaque système en fonction du logiciel installé. L’ensemble permet d’utiliser une machine plus puissante qui profite globalement à toutes les machines, pour une consommation et un encombrement bien moindre.

L’application des patchs s’appliqueront à moins de machine, provoquant moins de redémarrage.

Les calculs à prendre en compte.

Idéalement, le nombre de processeurs alloués aux machines virtuelles ne devrait pas dépasser le double de ceux présents dans la machine hôte. Une machine bi-quad possédant 8 processeurs logiques ne devrait pas gérer plus de 16 processeurs sur l’ensemble des machines virtuelles.

On utilisera le mêmes calculs pour un serveur Exchange virtuel que pour un serveur physique. La taille minimale fonctionnelle tourne autour de 1,5 GO, mais 2 GO sont conseillés quels que soit les rôles définis. Les rôles CAS, HUB et EDGE se contenteront souvent de cette mémoire. Le rôle Mailbox sera lui plus gourmand selon le nombre d’utilisateurs. Le nombre de groupe de stockage (donc des banques) peut lui aussi impliquer de la mémoire supplémentaire (jusqu’à 32 GO), sachant qu’il n’y a plus de gains en vitesse au-delà de 16 GO de mémoire.

Pour des informations détaillées : http://technet.microsoft.com/en-us/library/bb738124.aspx

Cache et IOPS(Nombre d’entrées/sorties) estimés par utilisateur selon son profil utilisateur et son activité de messagerie

Pour des informations détaillées : http://technet.microsoft.com/en-us/library/bb738147.aspx

Le nombre d’opérations d’entrée/sortie permettra d’évaluer le nombre de disques nécessaires pour supporter le pic d’activité des utilisateurs.

Selon les disques utilisés, il sera nécessaire d’utiliser plusieurs disques en RAID5, RAID10 voire plusieurs ensembles afin d’obtenir le niveau d’IOPS nécessaire.

Pour information,

-          Un disque de 10 KTPM supporte environ 130 IOPS

-          Un disque de 15 KTPM supporte environ 180 IOPS.

Dans le cas d’utilisation de disques iSCSI, le trafic disque passera par le réseau. Plusieurs points sont donc à prévoir afin d’optimiser le débit.

-          Une carte réseau dédiée à la communication iSCSI

-          Un réseau dédié à la communication entre la baie iSCSI et  les différents clients iSCSI

La solution iSCSI permet aussi d’envisager des clusters de type CCR ou SCC.

Pour éviter tout risque de congestion du réseau, la communication de chaque machine virtuelle avec ses clients supposera une carte réseau physique qui sera liée uniquement à la machine virtuelle autorisée.

Quelques exemples de solutions

La combinaison la plus classique consiste à installer sur chaque site 2 serveurs HyperV. Cette solution correspond à la sécurité maximale pour les sites principaux.

Chaque serveur HyperV héberge les machines suivantes :

-          Un contrôleur de domaine (et DNS)

-          Un serveur Exchange 2007 Standard HUB+CAS

-          Un serveur Exchange 2007 Enterprise CCR

Cette architecture permet d’obtenir la tolérance de panne par NLB entre les 2 machines CAS+HUB, ainsi que le cluster de type CCR entre les 2 machines Mailbox. On remarquera que seulement 2 machines physiques sont nécessaires.

Dans le cas de sites plus petits, il est possible de n’installer qu’un seul serveur HyperV.

Ce serveur HyperV contiendra :

-          Un contrôleur de domaine et DNS

-          Un serveur Exchange 2007 HUB+CAS+MAILBOX

Les rôles supplémentaires « partages de fichiers », « partages d’imprimantes » pourront être ajoutés dans une machine virtuelle supplémentaire.

Dans tous les cas, ce type de configuration suppose de bien ordonner le démarrage des différentes machines virtuelles. Les serveurs HyperVs, qui doivent faire partie du domaine, devraient trouver un contrôleur de domaine au moment de leur démarrage. Le contrôleur de domaine hébergé n’étant pas accessible, un autre DC/DNS devra être configuré. Si un 2^ème DC est hébergé sur le 2^ème serveur HyperV, celui-ci sera choisi.

Pour les machines virtuelles, qui seront effectivement utilisées par les clients du site, c’est le contrôleur de domaine hébergé qui doit être utilisé. Un délai de démarrage (d’au moins 4 minutes) sera donc configuré sur tous les serveurs Exchange hébergés, et sur les autres machines virtuelles nécessitant ce contrôleur de domaine. En effet, les principaux services d’Exchange ne démarrent pas si un catalogue global n’est pas trouvé sur le site.

A noter qu’un délai de démarrage doit aussi être configuré sur les serveurs SQL hébergés !

Pour ce type de services essentiels, le démarrage  sera bien entendu toujours en automatique.

Concernant les rôles DC, DHCP, …, ces machines virtuelles peuvent être basées sur la version CORE de Windows 2008. Cette version permet de diminuer notablement la mémoire dédiée à chaque de ces machines. J’ai affecté 256 Mo à un serveur hébergeant les rôles contrôleur de domaine, DNS, DHCP, DFS… et il reste 50 Mo de mémoire physique non utilisée.

Conclusions

Ces solutions font rêver ou réfléchir mais ne laissent personne indifférent. L’écueil principal n’est plus le matériel (serveurs 64 bits), ni la mémoire vive qui n’est plus très chère, mais plutôt le coût des licences nécessaires à l’installation des différents serveurs Windows et Exchange.

La version Enterprise de Windows 2008 qui autorise l’installation de 4 machines virtuelles (Windows standard ou Enterprise), représente souvent le meilleur choix.

La version Standard n’autorise qu’une seule machine virtuelle. Une licence Windows sera nécessaire pour chaque machine virtuelle supplémentaire (sous Windows).

A l’usage, la solution HyperV s’avère très stable et ne provoque que peu d’administration. L’évolution vers la version HyperV R2 devrait encore améliorer la prise en compte de la solution Microsoft de virtualisation dans de nombreuses architectures.

Le thème de la cohabitation avec Exchange 2003 (encore très présent) est bien abordé. La migration depuis une infrastructure 2007 est aussi traitée dans le chapitre 3. La partie couvrant la haute disponibilité (et les nouveautés associées à Exchange 2010) est une bonne introduction (sur ce thème de la haute disponibilité, je rappelle qu’une autre présentation est disponible ici écrite par Neil Hobson).

En fait les droits sur les journaux d’évènements sont affectés pour chaque type d’évènements dans le registre. La liste de contrôle d’accès (ACL) est stockée comme une chaine SDDL (Security Descriptor Definition Language) dans une valeur REG_SZ « CustomSD »

Afin de simplifier la gestion de ses droits, il conviendra de passer par une GPO et donc de modifier un fichier .inf pour voir apparaitre de nouveaux paramètres de GPO.

Modification du fichier Sceregvl.inf

Ce fichier est situé dans WK3/inf , il faut modifier le fichier INF du serveur sur lequel vous allez afficher la GPO.

La modification est la suivante :

• Rajouter les lignes suivantes dans la section [Register Registry Values] :
  

MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD,1,%AppCustomSD%,2

MACHINE\System\CurrentControlSet\Services\Eventlog\Security\CustomSD,1,%SecCustomSD%,2

MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD,1,%SysCustomSD%,2

MACHINE\System\CurrentControlSet\Services\Eventlog\Directory Service\CustomSD,1,%DSCustomSD%,2

MACHINE\System\CurrentControlSet\Services\Eventlog\DNS Server\CustomSD,1,%DNSCustomSD%,2

MACHINE\System\CurrentControlSet\Services\Eventlog\File Replication Service\CustomSD,1,%FRSCustomSD%,2

• Rajouter les lignes suivantes dans la section [Strings] :
  

AppCustomSD= »Eventlog: Security descriptor for Application event log »
SecCustomSD= »Eventlog: Security descriptor for Security event log »
SysCustomSD= »Eventlog: Security descriptor for System event log »
DSCustomSD= »Eventlog: Security descriptor for Directory Service event log »
DNSCustomSD= »Eventlog: Security descriptor for DNS Server event log »
FRSCustomSD= »Eventlog: Security descriptor for File Replication Service event log »

Sauvegarder le fichier et lancer la commande « regsvr32 scecli.dll »

Les nouveaux paramètres pour l’ « event logs » apparaissent maintenant dans les GPOs au niveau de :

Computer Configuration /Windows Settings/Security Settings/Local Policies/Security Options

Configuration des nouveaux paramètres

Dans la GPO, développez:

Computer Configuration /Windows Settings/Security Settings/Local Policies/Security Options

Puis double cliquer sur « Eventlog : Security descriptor for System event log

CustomSD

Ensuite il faut copier le CustomSD (Security Descriptor)

Le CustomSD est configuré localement dans la valeur de registre suivante :

• Pour le journal SYSTEM :
  

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD

• Pour le journal Application:
  

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

Vous devez utiliser la syntaxe SDDL (Security Descriptor Definition Language) pour spécifier le descripteur de sécurité de chaque journal.

Pour créer une chaîne SDDL, notez qu’il existe trois droits distincts en rapport avec les journaux des événements : Lecture, Écriture et Effacement. Ces droits correspondent aux bits suivants du champ droits d’accès de la chaîne ACE :

• 1= Lecture
  
• 2 = Écriture
  
• 4 = Effacement
  

Voici un exemple de syntaxe SDDL montrant la chaîne SDDL par défaut pour le journal d’application. Les droits d’accès (en hexadécimal) sont en caractères gras à des fins d’illustration :

O:BAG:SYD:(D;; 0xf0007;;;AN)(D;; 0xf0007;;;BG)(A;; 0xf0007;;;SY)(A;; 0×5;;;BA)(A;; 0×7;;;SO)(A;; 0×3;;;IU)(A;; 0×2;;;BA)(A;; 0×2;;;LS)(A;; 0×2;;;NS)

Pour affecter un droit à un groupe particulier, il suffit de copier une chaîne « (A;; 0×2;;;NS) » puis de définir le droit et de l’associer au SID du groupe.

Ex : (A;;0×1;;;S-1-5-21-2413859769-3038102453-1019812117-40824) : droit en lecture (0×1) sur le SID S-1-5…….

Récupération du SID du groupe

On utilise l’utilitaire :getSID avec la syntaxe suivante :

Getsid \\nomDC nomduGroupe \\nomDC nomduGroupe

getsid \\swpdcv0011.directory.root.local RDINXS-GSD-SystemEventLog \\swpdcv0013 RDINXS-GSD-SystemEventLog

Référence : http://support.microsoft.com/?scid=kb%3Ben-us%3B323076&x=11&y=9

KB : Q323076

Filtering and categorization is also performing on https site, by setup a trusted authority on computer. Web 2.0 can be monitor but it’s in option.

User database can be done by AD synchronization, open LDAP, or Zscaler can store a local database. The authentication method is providing by a cookie flash store in the local user folder (compatible with profile store on share or Vdesk). The password policy can be hardness as your internal policy.

Remote user can also use Zscaler at home, and use the same restriction &protection anywhere.

The real force of this solution is to provide a fail over on their gateway by DNS mechanism, and the datacenter around the world.

The reporting is managed on global console so international company can have data from every user from every location. The reporting can be done by internet gateway (location), departement (sales, IT, ..) or per user.

The competitors of this solution are Messagelabs, scansafe (cisco), webroot and websense.

I) Les évolutions technologiques :

• Les capacités des disques évoluent énormément (Disques 1 To SATA),  durablement, abaissant globalement le coût du stockage. Ces capacités s’accompagnent de taux de transferts très rapides mais uniquement en lectures séquentielles sans changement de piste. Pour avoir une idée de la progression, une analyse se trouve sur le site http://www.erenumerique.fr/disques_durs_evolution_de_la_capacite-art-1474-6.html)
• En revanche, la vitesse lors de recherches aléatoires sur les disques ne progresse quasiment pas, et les possibilités d’évolution sont faibles (http://www.erenumerique.fr/disques_durs_evolution_de_la_capacite-art-1474-7.html) .

Ces 2 points ont orienté Microsoft sur un nouveau schéma de base de données totalement remis à « plat »,  c’est le cas de le dire.  Chaque boîte aux lettres, chaque dossier représente maintenant une table spécifique. La lecture de ce type d’informations est donc maintenant séquentielle, la présentation des données (L’ordre, filtrage, etc) n’est réalisée que lorsque l’utilisateur provoque cette requête.  Cette philosophie appelée « Pay for view » consiste à ne réaliser la vue que si elle est demandée et éviter ainsi toutes les mises à jour intermédiaires inutiles. Dans l’ancien schéma de base Exchange 2007 et avant, tous les messages étaient rangés dans de grandes tables, les mises à jour des index et des vues étaient donc permanentes, par exemple lors de l’arrivée de messages.

Cette augmentation de capacité des disques permet de proposer de réintégrer les (nombreux) fichiers d’archivage (PST) des utilisateurs à côté de la boîte principale. Dans ce nouveau cadre, les boîtes à lettre sont maintenant optimisées pour une taille moyenne de 10 GO.

L’utilisation de baies de type SAN disposant d’espaces disques importants  est toujours possible, mais n’est plus un passage obligé pour les entreprises désirant fiabiliser l’accès à la messagerie par la technologie de cluster.

• La simplification des différents modes de cluster !

Exchange 2007 permettait déjà de réaliser des différents types de clusters : LCR, CCR, SCR, SCC. Mais, ces solutions étaient souvent complexes à mettre en place (SCR), nécessitaient du matériel spécifique (SCC) ou ne semblaient pas utiles (LCR). Microsoft a remplacé l’ensemble de ces technologies par une méthode unique de réplication « logicielle » des banques d’information appelée DAG. Ce mode remplace avec brio (et sans casse-tête) les modes CCR (réplication sur des nœuds en local) et SCR (Réplication sur des nœuds distants). Ceci ne règle pas tous les problèmes et ne permet pas toujours de diminuer le nombre de serveurs réellement nécessaires.

• La technologie Azure

Cette technologique permet à tous les nouveaux développements basés sur cette technologie de fonctionner sur les ressources internes ou externes (hébergées) de manière identique. L’entreprise peut choisir d’utiliser l’application soit en totalité sur son réseau, soit sur Internet, soit un mixte des 2. Les serveurs de bases SQL, les serveurs de messagerie peuvent ainsi basculer vers l’hébergement en fonction des coûts réels à un moment donné.

Exchange 2010 fonctionne sur ce modèle : l’administration permet de gérer dans la même console les serveurs « on premises » (internes) et les serveurs « on line » (On the Cloud).  Les boîtes peuvent ainsi être basculées entre les 2 types de serveurs.

• L’accès Internet est banalisé avec un accès rapide et généralement peu couteux. Les utilisateurs s’habituent à consulter/modifier/déposer des informations sur les sites webs de plus en plus collaboratifs.

 II) L’évolution du marché et de la concurrence :

• Microsoft a gagné l’essentiel du marché côté intra-entreprise
• La concurrence se situe maintenant sur les messageries hébergées (Google,..)

Sur ce type de marché, Microsoft se devait de proposer une offre globale et crédible.  En effet, le système de ventes indirectes proposées par les partenaires Microsoft ne convient pas. Il ne permet pas aux partenaires existants  de proposer une offre mondiale de qualité.

L’infrastructure d’hébergement de Microsoft permet de fédérer la plupart des outils nécessaires à l’entreprise mais aussi différentes entités (Partenaires, Filiales,..) en réalisant l’équivalent des approbations entre forêts.

Néanmoins, ce système a provoqué la disparition de fonctionnalités qui étaient proposées par Exchange 2007 : l’accès aux serveurs de fichiers et de gestions documentaires (Sharepoint) de l’entreprise à travers OWA. Heureusement, peu de clients utilisaient cette fonction.

Dans le cadre de l’hébergement, comme dans le cas des grandes entreprises, le nombre de domaines de messagerie et d’utilisateurs à gérer est très important. Microsoft continue à simplifier l’administration à l’aide de commandes Powershells.

III) L’évolution des pratiques et des mentalités

Lorsque Microsoft  examine l’usage de ses produits, et notamment la sauvegarde Exchange, le constat suivant est fait :

• La sauvegarde de la messagerie est longue (Créneau horaire,  multi-sites). Chez certains clients, les sauvegardes complètes – souvent préférées – par les administrateurs deviennent impossibles à réaliser dans le temps imparti.
• Elle coûte cher : Les logiciels de sauvegarde, le matériel spécifique et le support de stockage reviennent généralement 2 fois plus chers que la messagerie elle-même.
• Elle est (très) rarement utilisée : les contraintes de restauration, l’espace disque nécessaire, la complexité des procédures, les risques d’erreurs de manipulation, le temps passé. Par ailleurs, dans de nombreux cas,  l’utilisateur peut récupérer lui-même  l’élément supprimé à partir de l’outil de récupération des éléments supprimés de l’utilisateur, l’administrateur peut réexpédier le message à partir de la fonctionnalité « Dumpster ».

En résumé, la sauvegarde ne sert donc qu’à se prémunir d’un crash « complet » des serveurs nécessitant le rechargement de la totalité des informations.

Pour ces différentes raisons, et parce qu’il est maintenant facile de se prémunir de risques majeurs au niveau des disques et des serveurs grâce à Exchange 2010 et les DAGs, Microsoft propose carrément de ne plus sauvegarder la messagerie Exchange, ce qui peut sembler audacieux. Mais, les risques majeurs sont couverts par les DAGs qui permettent jusqu’à 16 copies sur  16 serveurs différents d’une même banque.  Les risques mineurs sont couverts par une augmentation de la période de conservation des éléments supprimés (par exemple, 3 mois au niveau du système), une augmentation de la durée de conservation des messages entrants/sortants au niveau du rôle HUB et un système d’archivage. Par ailleurs, depuis Outlook 2007, en cas de crash d’un serveur et reconfiguration d’une boîte vide, les données sont alors resynchronisées depuis la copie locale (OST) de la boîte, ce qui en fait l’équivalent d’une copie supplémentaire.

Par ailleurs, les solutions d’archivage et de recherche deviennent de plus en plus courantes. Exchange 2010 facilite donc maintenant le stockage et la recherche, et un premier niveau d’archivage qui peut suffire à de nombreuses entreprises. L’intégration ou la réintégration des fichiers d’archivage permet de centraliser ce type d’information ainsi que sa recherche. De nouveaux outils spécialisés sont maintenant fournis pour autoriser et aider les personnes habilitées à réaliser des recherches dans les banques d’informations qui deviennent maintenant des bases de « connaissance ».

Les prochaines évolutions du logiciel Exchange dépendront fortement de la technologie Azure et de l’engouement pour la philosophie « Cloud Computing ». Microsoft fournit maintenant une passerelle simple entre l’informatique locale et l’informatique hébergée. Bien entendu, d’autres améliorations sont toujours possibles et même attendues.

L’ajout d’une langue supplémentaire permettra à chaque utilisateur (administrateur) de choisir la langue préférée, sachant que l’administration, mais aussi les messages d’erreurs se feront dans la langue choisie.

Cliquer sur l’image « Etape 1 » pour démarrer la procédure.

Dans cet article, vous trouverez deux méthodes pour créer une clef USB bootable dans l’optique d’installer Windows 7. Une première méthode très GEEK en pas en pas, et une seconde vraiment enfantine ne nécessitant aucune compétence.

1) LA METHODE GEEK

Avant de commencer la méthode Geek, voici ce dont vous avez besoin pour créer la clef USB de boot Windows Seven:

• Une clef USB de 4Go, celle-ci sera formatée donc prenez soin de sauvegarder vos données avant.
• Le média de Windows 7 ou son image ISO, dans ce cas vous aurez besoin d’un outil permettant de lire les fichiers ISO de type Daemon Tools.
• Un poste de travail avec Windows Vista minimum (et se connecter en administrateur)

Etape 1 : Le formatage de la clef
Nous allons formater la clef USB « à la Geek », c’est à dire en ne choisissant pas la méthode la plus répandue. Pour se faire suivez les étapes suivantes :

1) Connectez votre clef USB à l’un des ports USB de votre ordinateur

2) Cliquez sur Démarrer  / Tous les programmes / Accessoires / Invite de commande

3) Repérer ensuite le numéro de votre lecteur à l’aide de l’utilitaire diskpart :

diskpart
list disk

Nous prendrons comme numéro de disque le disque 1 (ce qui est le cas si vous avez un disque plus votre clef USB dans votre ordinateur). Ce numéro de disque devra être noté car il sera utilisé dans l’opération suivante.

4) Nous allons formater maintenant le disque 1 toujours à l’aide de diskpart en saisissant les commandes suivantes :
select disk 1
clean
create partition primary
select partition 1
active
format fs=NTFS
assign
exit

Nous voila avec un clef USB formatée en NTFS, il nous reste plus qu’a rendre cette clef bootable, sinon vous ne pourrez pas démarrer avec votre ordinateur dans l’objectif d’installer Windows 7.

Etape 2 : Rendre la clef bootable

Ouvrez à nouveau l’invite de commande pour lancer l’utilitaire bootsect qui permettra de rendre bootable notre clef. Nous allons utilisez la version présente dans les sources de Windows Seven.
1) Mettez votre DVD de Windows 7 dans votre lecteur, ou montez votre image ISO de Windows 7 afin que vous puissiez accéder aux sources d’installation.

2) Modifier votre lecteur en saisissant :
d: Attention de saisir la lettre de lecteur correspondant à votre environnement
cd d:\boot

3) nous allons maintenant rendre nos clef USB bootable (nous supposons que la la lettre de lecteur de notre clef USB est Z:)

bootsect /nt60 Z:

Etape 3 : Copier vos sources sur la clef USB

Votre clef USB est enfin bootable, il ne reste plus qu’à copier l’intégralité de votre média Windows 7 à partir du DVD ou du contenu de l’image ISO que vous avez téléchargé.

Une fois la copie terminée, votre clef est utilisable pour installer Seven à condition que votre ordinateur accepte (et soit configuré) sur un périphérique USB.

Etape 4 : Paramétré le BIOS de votre ordinateur pour démarrer à partir d’un périphérique de stockage USB

Comme les ordinateurs sont différents au niveau de BIOS, il n’y a pas de détail de la configuration ici, reportez-vous à la documentation de votre ordinateur.

2) LA METHODE FACILE

Même s’il est sympa de pouvoir créer notre clef USB bootable à la Geek, moi je préfère la méthode simple… Il vous suffit de télécharger sur le site Microsoft l’utilitaire gratuit : Windows 7 USB DVD Download Tool

Une fois cet utilitaire téléchargé, vous pouvez créer votre clef USB bootable en 4 clics de souris,

1) Lancez Windows 7 USB DVD Download Tool

2) Sélectionnez votre image ISO de Windows 7

3) Choisissez USB Device (DVD étant réservé pour la gravure de votre image ISO)

4) Sélectionner la lettre de lecteur correspondant à votre clef USB et cliquez sur Beging copying

Le temps d’aller chercher un petit café et hop voici votre clef USB Bootable prête à être utilisée pour déployer Windows Seven

Bon déploiement,