配置 SharePoint Web 应用程序

　　创建新的 SharePoint Web 应用程序的时候，全部接受默认的选项也是可以的。

　　或者，你也可以面对这么多选项，做出很多“艰难”的决策来对 SharePoint 做更多的了解。

　　身份验证方式

　　有“经典”和“基于声明”的两种。

　　“经典”的里面，又可以选身份验证提供程序：NTML 或者 Kerberos。
　　“基于声明”的，原理和 Kerberos 的有点儿像，都引入了 Token Issuer 的角色（SharePoint 拿到验证 Token，还要用 Security Token Service 再转换一次才能使用）。不同的是，声明 Claims 引入了证书签名加密、基于 SAML 协议，适用于非 Windows 系统的互信授权，从而可以跨过企业间的异构界限，实现联合身份验证 Federation。Form Based 身份验证也划入了“基于声明”的行列。

　　微软有个帮助你规划应用的图 Design Sample: Corporate Portal with Claims-based Authentication。

　　配置 Form Based 身份验证： Sharepoint 2010 Form 身份认证的实现（基于SQL） 和 Configuring Forms Based Authentication for SharePoint 2010 using IIS7。

　　配置 Federation 身份验证：端对端配置 SharePoint 2010 和 ADFS v2 版本。配置到最后，会用到配置“信任”：SharePoint 2010管理中心管理信任。　

　　主机头、端口

　　端口，别和默认端口（21 什么的）冲突即可。HTTPS 协议默认 443 端口，如果已经占用了，就换别的。不想换？那就申请通配符证书吧。

　　IIS 应用程序池及其管理账户

　　建议挑一个非域管理员、非本机管理员的账号试试，会很好玩的。用这个账号登录网站，就会显示“系统账户”或者“System Account”。

　　第一个内容数据库的名称

　　这个名称，其实无所谓，不重名即可。不过，我喜欢在 WSS_Content 后面加上 “_端口”，看上去好区分。

        SharePoint Web 应用程序

　　我个人的理解，SharePoint Web 应用程序（SharePoint Web Application）代表的是 SharePoint 网站（集）的物理容器。

　　SharePoint Web 应用程序需要制定内容数据库、宿主 IIS 应用程序池、应用程序池管理员账号等信息，这些都是 SharePoint 网站（集）的物理容器属性。从这以后（网站集，网站，列表。。。）都是在数据库里面操作，是为逻辑容器。（姑且让我这么区分吧）

　　所以，像下面这样解释 Web Application 和 Site Collection, Web Site 之间的关系就是比较准确的了。

　　关联的服务应用程序

　　即 SharePoint Service Application，姑且可以看做是 SharePoint 的 Web 版公共程序库，提供各种服务供各个 Web 应用调用。

　　没把握的话，全部选上，否则在学习、测试的时候会有各种各样的错误。

　　熟悉的话，你就麻烦了，这里又牵涉到一个服务应用程序规划的问题，取决于服务器场中每台 SharePoint Instance 的角色定位问题。

　　微软有个图可以帮助你决定（当然，你也可以被这个图扰乱），到底要怎么样分配 SharePoint Web 应用程序关联的服务应用程序 Cross-farm Services in SharePoint 2010 Products。

　　上面这些决策，显然不是（纯）程序员或者网站管理员、网站用户应该（以及能够）考虑的，这些明显是给另外一拨人去思考的。所以呢，单枪匹马的搞 SharePoint 项目的时代，不说已经过去，大概从来就没有到来过吧。

　　这些问题，个人在单机上面搞研究是不会遇到的，所以，弄个拟真的环境很有必要。不仅仅是 SharePoint，其它的技术平台都应该会有这个问题。