这一周, 我有点纠结我的团队得到简单的两个服务器场中安装的苔藓. 经历了它, 我有问题的人报告的种类更好地了解 MSDN 论坛和其他地方.
最后服务器场配置:
- 在防火墙内的 SQL 索引/内联网 WFE.
- 在 DMZ WFE.
- 某种类型的 DMZ 和内部服务器之间的防火墙.
我们开始项目之前, 我们让客户知道需要打开哪些端口. 在互谅互让, 来回以上,, 我们从来没有明确说了两个重要的事情:
- SSL 意味着您需要一个证书.
- DMZ 服务器必须是域的一部分.
第一天, 我们到场安装苔藓和学没已创建数据库和苔藓的域帐户. 搬东西, 我们走在前面,和安装一切与 intranet 服务器上的本地帐户.
在这一点, 我们发现混乱的 SSL 证书和, 可悲的是, 决定要我们基础设施的家伙回来之后的一个星期继续安装 DMZ 服务器. 在平均时间, 我们的解决方案建筑师向前处理业务的东西.
一个周末的流逝,客户端获取证书.
我们的基础设施的人出现,并发现 DMZ 服务器未加入到任何域 (有限的信任与外围域或内联网域). 我们浪费了近 1/2 在那一天. 如果我们没有让我们停滞不前的失踪 SSL 证书, 我们发现这早些时候. 哦好吧….
另一天通行证和各种安全委员会, 有关各方和 (不是这样) 无辜的旁观者都同意,确定以与内联网的域的 DMZ 服务器联接 (这是 POC, 毕竟, 不是生产解决方案).
基础设施的家伙来东西包起来. 这次我们成功地通过现代天挑战亲切地称为"SharePoint 配置向导。" 我们有聚醚醚酮在管理中心和 … 怡山楂! … DMZ 服务器列出服务器场中. 我们靠近一点看,实现我们破开香槟螨有点早. WSS 服务陷入"开始" 状态.
长话短, 原来,我们忘记了通过管理中心的服务帐户的身份从原始的本地帐户更改为新的域帐户. 我们那样做, 重新运行配置向导和瞧! 我们在业务.
</结束>
Technorati 标签: SharePoint 管理
我几乎可以打败你 SSL 证书问题. 我们拥有了一切创建和准备扩展 web 应用程序使用 SSL (然后将端口重定向 80 在 IIS 中). 管理员已准备好去.cer 文件的步骤. 但没有任何选项或疯狂扭曲,适用在 IIS 中将工作–该网站总是显示一个空白页,像网站集不存在.
后多敲头, 我们学到了,这造成的不来自该服务器的证书请求. 管理员只需 问 证书是通过电子邮件发送产生的密钥. 与没有私钥, 不能获取 SSL 隧道建造 WFE 和浏览器之间. 我们浪费了 1/2 在那一天.