1 votes

Google Apps comme hôte de messagerie (externe) pour Exchange 2007 (interne)

Je suis sûr que cela a déjà été fait, mais après environ deux jours de recherche, je n'arrive pas à trouver ce dont j'ai besoin.

Nous utilisons Google Apps pour notre messagerie électronique (les serveurs MX sont dirigés vers Google Apps) et je télécharge la boîte aux lettres de chaque utilisateur (username@domain.net comme hébergé sur Google Apps) par le biais du connecteur POP3 sur SBS 2008 Exchange. Je peux envoyer des e-mails à d'autres domaines sans problème via le smart host de notre FAI.

Mon problème est le suivant : J'ai configuré un compte utilisateur sur SBS pour l'utilisateur 1 (user1@domain.net) et elle a donc une boîte aux lettres locale sur Exchange. Je n'ai pas de compte utilisateur pour M. Président (president@domain.net) car il veut continuer à utiliser IMAP de GApps pour son Mac. L'utilisateur 1 ne peut pas envoyer d'e-mails au président. Mais l'utilisateur 1 peut envoyer des e-mails à tout autre utilisateur ayant un compte sur SBS 2008.

J'ai essayé de régler le domaine accepté par Hub Transport pour domain.net sur "Internal Relay" alors que domain.local est réglé sur "Authoritative" et comme domaine accepté par défaut.

Exchange me donne cette erreur : L'adresse électronique du destinataire n'a pas été trouvée dans le système de messagerie du destinataire. Microsoft Exchange n'essaiera pas de réexpédier ce message pour vous. Veuillez vérifier l'adresse électronique et essayer de renvoyer ce message, ou fournir le texte de diagnostic suivant à votre administrateur système.

550 5.1.1 RESOLVER.ADR.RecipNotFound ; non trouvé

Avez-vous une idée de l'origine de ce problème ? Je préférerais que même le courrier envoyé à User1@domain.net soit envoyé par l'hôte intelligent et soit reçu par GApps, puis soit tiré par POP3 pour Exchange...

Je comprends que ce que je veux risque de nier l'utilité d'Exchange et d'augmenter les besoins en bande passante, mais mon argumentaire est le suivant : si Exchange devait tomber en panne, nous aurions TOUTES nos boîtes de réception intactes sur Google Apps. Et bien sûr, si un virus était envoyé depuis l'un de nos postes de travail, il serait préférable qu'il passe par Google Apps avant d'arriver à Exchange (alors que dans la configuration par défaut, il l'envoie directement à la boîte aux lettres Exchange et ne passe jamais par Internet).

2voto

joeqwerty Points 106914

@Jared : Je ne veux pas manquer de respect, mais honnêtement, je ne sais pas pourquoi les entreprises se donnent la peine de payer et d'utiliser Exchange si elles ne l'utilisent pas de la manière prévue. Vous avez une configuration qui est plus lourde à mettre en place, à gérer et à dépanner, tout cela sous le prétexte que vous vous "protégez" d'une panne future imprévue qui, selon toute vraisemblance, ne se produira pas. Si vous ne faites pas confiance à Exchange, au serveur, à votre infrastructure interne ou à vous-même, alors débarrassez-vous complètement d'Exchange et arrêtez de vous flageller avec ce scénario insoutenable.

Je sais que le connecteur POP vient de MS mais je pense que c'était une mauvaise idée de leur part car cela a donné aux entreprises une raison de mettre en œuvre des scénarios comme le vôtre, qui, à mon avis, sont plus de problèmes qu'ils n'en valent la peine.

Avez-vous envisagé d'internaliser "entièrement" votre messagerie électronique et de supprimer l'implémentation actuelle ? L'administration en serait grandement facilitée et vous pourriez toujours intégrer le niveau de redondance et de disponibilité requis.

Vous avez passé deux jours à chercher une solution à un problème qui n'existerait pas si vous utilisiez Exchange de la façon dont il est censé être utilisé. Toutes les raisons que vous avez invoquées pour mettre en œuvre ce scénario peuvent être traitées en interne.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X