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:
- SSL signifie que vous avez besoin d'un certificat.
- 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>
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.