Exchange 2010 Service Pack 2 et hébergement

Article d’origine publié le mardi 6 décembre 2011

Avec les modifications de stratégie que nous avons annoncées dans Avenir du mode /hosting il y a quelques mois, nous souhaitions exprimer clairement les actions prises en charge dans les scénarios d’hébergement.

Nous avons annoncé que les hébergeurs pourraient utiliser Exchange 2010 SP2 pour proposer des services Exchange hébergés. Le Service Pack SP2 est désormais disponible, au même titre que le Guide d’architecture mutualisée et d’hébergement pour Exchange Server 2010 SP2 pour aider les clients à configurer leurs solutions d’une façon autorisée. Nous avons créé un site Web sur les conseils et les solutions en matière d’architecture mutualisée pour identifier les fournisseurs de panneau de configuration qui ont proposé les détails appropriés sur leurs solutions afin que nous puissions les recenser comme ayant une solution compatible. Le guide s’adresse à la fois aux hébergeurs et aux fournisseurs de panneau de configuration, mais sera aussi utile à quiconque souhaite créer un système de type architecture mutualisée (parfois appelé Cloud privé), avec Exchange 2010 SP2.

Mise à jour du 20 décembre : nous venons de publier le Guide d’évolution vers une architecture mutualisée Exchange 2010 SP2, qui contient des instructions pour la mise à l’échelle et le déploiement d’une solution partagée au sein d’une architecture mutualisée Exchange 2010 SP2.

Le point le plus important à comprendre est qu’un hébergeur, un fournisseur de panneau de configuration ou quiconque utilise et suit le guide que nous avons publié pour développer sa solution n’est pas différent de tout autre client qui déploie Exchange, mais choisit de ne modifier aucun des paramètres par défaut. Le support que nous proposons ne diffèrera en rien de celui proposé à tout autre client.

Par exemple, si vous êtes un client d’entreprise typique et que vous souhaitez déployer Exchange, configurer certaines stratégies de carnet d’adresses, modifier les autorisations de calendrier et ajouter quelques milliers de domaines acceptés, vous aurez le même support que celui que vous avez toujours eu, dans la mesure où votre configuration utilise seulement les outils et processus pris en charge. En tant qu’hébergeur ou développeur de Cloud privé, la situation ne sera pas différente. Vous aussi créez des objets, configurez certaines stratégies de carnet d’adresses et vous retrouvez peut-être avec une configuration inhabituelle aux yeux d’un client Exchange moyen ; le résultat est bien une configuration insolite, personnalisée pour satisfaire vos impératifs, mais bel et bien prise en charge.

Voici quelques exemples pour clarifier ce que nous voulons dire :

• Vous nous appelez pour un problème d’agent de transport Exchange et il apparaît clairement que votre solution ne respecte aucun des conseils du guide de développement publié. Nous vous recommandons de modifier votre solution pour qu’elle respecte notre guide, et ce conseil sera le même que vous soyez un hébergeur, un développeur d’un Cloud privé ou une grande entreprise.
• Vous êtes un hébergeur et appelez parce que vous ne parvenez pas à empêcher que les messages internes Absent(e) du bureau soient remis entre clients de votre propre plateforme d’hébergement. Nous vous renvoyons à notre guide d’hébergement où nous indiquons clairement qu’il s’agit d’un problème connu dans ce type de configuration et que le document propose aussi la bonne approche pour résoudre ce type de problème. Si vous désirez alors ouvrir un cas développeur distinct pour bénéficier d’une aide à la création de la solution, cela est également possible.

Comme vous le constatez, si vous êtes un hébergeur ou une entreprise, ou une personne qui développe une solution pour héberger plusieurs clients, et que vous avez utilisé les outils et méthodes pris en charge pour configurer votre système, nous pourrons effectivement le prendre en charge. La situation n’est pas réellement différente de ce qu’elle est aujourd’hui : si vous choisissez d’apporter des modifications inhabituelles à votre système, nous ne vous demandons pas de valider le système de bout en bout avant que nous vous aidions à restaurer la base de données. Si, en revanche, la défaillance de la base de données est due à cette modification plutôt inhabituelle, nous vous demanderons alors pourquoi vous avez procédé à ces modifications et établirons si elles peuvent ou non être prises en charge.

Si un fournisseur de panneau de configuration souhaite vendre sa solution ET que celle-ci est mentionnée sur notre site Web, il doit nous adresser une confirmation écrite selon laquelle la solution est conforme à la TOTALITÉ du Guide. Si elle n’est conforme qu’à 90 %, elle ne sera pas répertoriée. Cela n’empêchera pas le fournisseur de vendre sa solution, car il peut agir ainsi sans que nous examinions la solution elle-même, mais un client qui souhaite l’acheter ne la verra pas recensée sur notre site Web.

En résumé, pour les clients qui utilisent Exchange 2010 SP2, nous traitons les hébergeurs et les clients professionnels de la même façon – si la racine du problème est une modification ou un paramètre non pris en charge, nous vous le signalerons et vous recommanderons de le modifier. Comme hébergeur, vous pouvez réellement créer un système d’architecture mutualisée sans effectuer des modifications non prises en charge. Le guide que nous avons publié vous aidera à agir dans ce sens, et nous vous recommandons de le suivre.

J’aime à penser ainsi : notre objectif, quant à proposer un guide et permettre aux hébergeurs d’utiliser Exchange Server 2010 SP2, est de s’assurer qu’ils aient une solution fondée sur une configuration prise en charge, et jouissent ainsi d’un système identique à tout autre. Je souhaite sincèrement que vous bénéficiez de notre support chaque fois que nécessaire, et qu’à cette fin vous nous apportiez votre contribution.

Greg Taylor

Ce billet de blog a été traduit de l’anglais. Vous pouvez consulter la version originale à la page Exchange 2010 Service Pack 2 and Hosting