MOUSSE petite ferme Installation et Configuration guerre histoire

Cette semaine, J'ai lutté un peu avec mon équipe pour obtenir MOSS installé dans une ferme de deux serveurs simple. Après avoir passé par là, J'ai une meilleure appréciation dans ce genre de rapport de problèmes les gens sur les forums MSDN et ailleurs.

La configuration finale ferme:

  • SQL/Index/Intranet EPE à l'intérieur du pare-feu.
  • WFE dans la zone démilitarisée.
  • Une sorte de pare-feu entre la DMZ et le serveur interne.

Avant de commencer le projet, nous permettre au client de savoir quels ports doivent être ouverts. Au cours de la donner et recevoir, en allers retours sur celle, Nous avons jamais explicitement dit deux choses importantes:

  1. SSL signifie que vous avez besoin d'un certificat.
  2. Le serveur DMZ doit faire partie d'un domaine.

Premier jour, nous a montré à installer MOSS et appris que les comptes de domaine pour la base de données et la mousse n'avait pas été créés. Pour bouger les choses, Nous sommes allés à venir et tout installé avec un compte local sur le serveur intranet.

À ce point, Nous avons découvert la confusion sur le certificat SSL et, Malheureusement, décidé d'avoir notre gars infrastructure y revenir plus tard cette semaine pour poursuivre l'installation du serveur DMZ. Pendant ce temps, nous, les architectes de la solution a progressé avec les trucs d'affaires.

Une fin de semaine ne se passe, et le client obtient le certificat.

Nos gars de l'infrastructure se présente et découvre que le serveur DMZ n'est pas joint à n'importe quel domaine (soit un domaine de périmètre avec une confiance limitée, soit du domaine intranet). Nous avons perdu presque un 1/2 journée là-dessus. Si nous n'avions pas laisser le certificat SSL manquant nous embourber, on aurait découvert cela plus tôt. Eh bien….

Un autre jour passe et les différentes commissions de sécurité, les parties intéressées et (pas si) des passants innocents tous d'accord que c'est OK pour rejoindre le serveur DMZ avec le domaine de l'intranet (Il s'agit d'un CEP, Après tout, pas une solution de production).

Infrastructure mec vient envelopper les choses. Cette fois nous passons avec succès par le le gant de moderne-jour affectueusement surnommé le "Assistant de Configuration SharePoint." Nous avons un coup d'oeil dans l'administration centrale et … Yee haw! … DMZ serveur est répertorié dans la ferme. Nous regarder un peu plus près et réaliser que nous avons cassé ouvert le Champagne, un peu d'acariens au début. Services WSS est coincé dans un "démarrage" statut.

Longue histoire courte, Il s'avère que nous avons oublié de changer l'identité du compte de service par l'intermédiaire de l'administration centrale de compte local d'origine vers le nouveau compte de domaine. Nous l'avons fait, ré-exécution de l'Assistant de configuration et voila! Nous avons été en affaires.

</fin>

S'abonner à mon blog.

5 réflexions sur "MOUSSE petite ferme Installation et Configuration guerre histoire

  1. Cimares
    Il est parfaitement autorisé d'avoir votre SQL dans un Vlan/sous-réseau différent de celui de votre WFEs. En fait, il est recommandé, Après tout, comme mentionné précédemment, quel expert en sécurité va vous laisser coller SQL dans la zone démilitarisée? La recommandation est que votre trafic SQL n'utilise pas les mêmes cartes d'interface que le trafic de l'utilisateur, mais même cette connexion peut pas via un pare-feu pour une protection supplémentaire.
    Concerne la restriction liée à WFEs multiples dans un environnement de batterie de serveurs si vous utilisez l'équilibrage de la charge Microsoft, Ensuite, ils doivent tous être dans le même VLan.
    Réponse
  2. Paul

    Je peux presque battre votre numéro de certificat SSL. Nous avons eu tout créé et étaient prêts à étendre l'application web avec SSL (puis rediriger le port 80 dans IIS). L'administrateur avait un fichier .cer prêt à aller. Mais aucune des options ou des contorsions folles de l'appliquer dans IIS ne fonctionnera–le site affiche toujours une page blanche comme la collection de sites n'existe pas.

    Après avoir beaucoup frapper des chefs, Nous avons appris que cela était dû à la demande de cert ne provenant ne pas de ce serveur. L'administrateur simplement demandé pour un cert et a été envoyé la clé résultante. Avec aucune clé privée, le tunnel SSL n'a pas pu être généré entre le navigateur et le WFE. Nous avons perdu 1/2 journée là-dessus.

    Réponse
  3. Christian a écrit:
    Très intéressant! Je doute fort qu'il ne devrait pas être soutenu pour héberger le WFE dans un VLAN/DMZ et APP/SQL dans une autre VLAN/DMZ.
    Les articles de TechNet sur prise en charge des scénarios Extranet aucune réserve n'a pas, ou l'autre – but TechNet could be incorrect 🙂 None of our clients would allow their SQL Servers to sit on the same VLAN/DMZ as the WFE, alors j'espère sincèrement que les États membres sont trompés.
    Pouvez-vous préciser sur quel devrait être le problème avec la configuration de cracher? Raisons de performances uniquement? Ou ils en fait signifier que le De WFE devrait être sur le même VLAN/DMZ? Cela ferait plus de sens pour moi.
    Sincèrement,
    Christian
    Réponse
  4. Paul Galvin
    C'est une très bonne question.
    Nous sommes suivi de très près à la documentation de MS, donc je ne peux pas imaginer comment ils refuseraient de le soutenir. Cela dit, Je ne suis pas une personne de l'infrastructure, Il est donc possible que je suis abuser des termes dans mon post.
    Si je comprends bien, la bonne approche est d'avoir (au moins) deux domaines AD. Un domaine interne et l'autre dans le réseau de périmètre. Le réseau de périmètre AD aurait un "nombre limité d'affectation spéciale" relation avec la publicité interne.
    But you probably already know all that 🙂
    Ligne de fond, Je ne sais pas. On n'a pas recevoir ou recherchez directement à Microsoft orientation sur celui-ci.
    –Paul G
    Réponse
  5. Tom Dietz
    Cette configuration est prise en charge? Lors de la Conférence SharePoint à Seattle en mars, Je discutais avec certains Engineers Microsoft et ils ont dit que les configurations prises en charge ne permettent pas WFEs à traverser les routeurs ou VLAN. Je suppose que puisque le WFE est dans une zone démilitarisée, elle traverse une sorte de pare-feu/routeur ou dans son propre réseau local virtuel.
    Donc en gros la DB et les serveurs WFE/App tous doivent être sur le même VLAN.
    Ils étaient vraiment catégoriques à ce sujet–C'est en réalité une diapositive dans le ' géographique’ session de déploiement si vous avez accès au pont.
    J'ai lu les articles TechNet qui illustrent des configurations d'échantillon qui contredisent leurs déclarations, mais les gars de MS a dit essentiellement que TechNet est faux.
    Réponse

Laisser une réponse

Votre adresse email ne sera pas publiée. les champs requis sont indiqués *