Domain renaming

Provides better support for reverse proxies

Adds administrator supplied domain and protocol information for links

Administrators are able to map incoming URLs to specific outbound URLs

Solves top WSS deployment issues

Permits reverse proxy configurations that change the inbound URL

Enables SSL termination once data hits switches or routers

Static IP load-balancing capable

No Disabling of Kerberos

The one-click installation of WSS will no longer disable Kerberos

For server farm installations, the security configuration behavior is modified

Stsadm will no longer disable Kerberos by default

The object model default behavior is unchanged, but a new method is added to allow Kerberos to be used

The UI is changed to allow users to choose Kerberos or NTLM

非常感谢Microsoft的XML大师Chris Lovett为我们带来的SgmlReader这个开源的项目。我们知道，XML和HTML都是Sgml的子集。通过SgmlReader，能够将HTML转换生成格式规范的HTML（Well-Formed HTML，虽然没有这个称呼，但这里暂且这么说），从而可以使用XML的XPath语法读取网页的数据了。那么在.NET Framework下，我们遇到的问题变得如此轻松。

简单写了一个示例程序，用来抓取QQ网站的天气信息，通过更改城市名称和XPath获得网页内容。

代码：下载

PS

我一直以来都是SharePoint技术的追随者，从SharePoint 1.0开始到Office System 2003的Beta阶段，一直延续到现在，1年前成为了专职SharePoint的开发和管理工作者。我所在的公司，能够准确的定位需求，使用SharePoint作为企业门户的开发平台，将企业门户定位为提供统一用户入口、集成企业知识和信息、提供用户协作办公的基础，其实这三点也正是SharePoint的准确定位。公司的企业门户现在已经发展到了4.0版本，之前的三个版本每个都有不同的尝试，走过弯路，遇到过困难，也总结了很多经验。现在，我更多的关注了一些企业知识管理的理论。因为SharePoint作为一个企业知识管理平台，仅靠软件是无法达成目的的，还缺少执行和企业自身状况的方面。

可以总结，Windows SharePoint Services的是一个知识管理和协作平台，请注意，它是一个平台，而SharePoint Portal Server 2003是一个知识管理和协作系统。

企业的知识都有哪些？该如何管理呢？

企业的知识是企业的员工在日常工作中总结出来的各类文档、表格、日志、邮件等等，和经验不同，经验需要总结成知识，在现代化的企业中，知识大多数都是电子化的，那么文档和列表可以概括之。SharePoint的基础架构有三方面组成——文档库、列表库和人。同时提供的服务有：企业搜索和企业单点登陆，而WebPart技术则提供了优秀的表现层架构。

企业需要门户（Portal），当一个企业发展到一定规模的时候，如我们的企业有近1500员工，各种类型的办公系统差不多有近40个，没有Portal的工作是痛苦的，你要使用的系统地址如何记忆，各类系统的数据如何统一展现。

SharePoint不是文档管理系统，准确地说，他甚至不适合来做文档管理。知识本身是应该Share的，而文档不是，企业的文档应该有保密性。SharePoint 2.0取消了原本1.0中的对每篇文档的权限控制能力，依我所见有几个原因：1、不符合知识管理和共享的本意。2、Microsoft有专门的Information Right Management Services产品。

另一个不能忽略的方面是协作能力，和其他的Portal产品最大的区别和优势是SharePoint与Office System 2003其他产品之间的协作能力。更远的应该看到Information Bridge Framework、Smart Document、SharePoint、BizTalk这些产品协同带来的优势互补，多么伟大的一个蓝图，难怪Gates也频频提及SharePoint了。

企业信息化与企业的生存、发展息息相关，这已成为人们的共识，企业信息化规划和建设是各类企业特别关注的重点和难点。现而今，信息化建设已不是仅仅停留在表面的理论论证层次上，而是注重究竟怎样信息化，信息化之后怎样提升企业的生存能力、竞争能力和发展能力，以及怎样提高企业信息化带来的管理效率、效果。企业信息化之后所带来的更为重要的效益，才是企业需求的关键。鉴于此，《msdn开发精选》策划了以“企业信息化规划与设计”为主题的在线聊天活动，具体内容如下：

主题：企业信息化规划与设计

时间：2004.12.28（星期二）下午2：00~~3：30

地点：CSDN 嘉宾聊天室（http://chat.csdn.net）

嘉宾：滕远方(Ted Teng)

主持人：刘彦博（loverP，《msdn开发精选》技术编辑）

更多信息：http://event.csdn.net/ActDetails.aspx?AID=ffe91a11-65f2-4bfc-a643-4a9c128ab0da

我没有这个领域的经验，但总的来说，一个强大的企业搜索服务决不像www.google.com这样能够用爬虫爬到所有的地方。我想桌面搜索必然会成为一个优秀的企业搜索的先行军。从宏观方面讲，所有的搜索服务都是先爬内容、再编录、再整理，最后才提供用户搜索的，Longhorn中是否能够提供这样一个强大的桌面搜索会决定MS的企业搜索是否能够打败Google，让人担忧的是，Google的桌面搜索PreView也已经有了，不过好像大家的反应更多的是它有可能暴露的安全问题J。

不过话说回来，竞争才是进步，Google专注于搜索，MS专注于操作系统，对于一个最好的企业搜索而言结合才是最好的。

大战又一次拉开了序幕，刚刚看到的消息，Yahoo也参战了！

WSS应该已经成为Windows平台上门户应用的主流了，很奇怪的是MS至今还将下载的软件包命名为STSV2，当然，感到奇怪的还有Point2Share。

更早一些时候，12/3/2004，MS提供了SharePointPSSearch SQL Syntax（Preview），这个预览版的文档描述了SharePoint Portal Server 2003全文检索的SQL语法。

首先，还是Page Ghosting的问题。要了解什么是Page Ghosting，Barry Kouda发表在MSD2D的这篇《What you don't know about Front Page 2003 can hurt you》会告诉你。当初次建立好一个WSS/SPS站点之后，用户访问一个具体的页面，此时的页面内容来自两个位置，一个是Page Ghosting，它的位置是在X:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE目录下，它定义了页面的框架、样式、Web部件区域，而页面的内容则存储在数据库中。用户的请求被Sharepoint ISAPI接收到以后服务器端会从数据库中取出具体的内容，和Page Ghosting编译后的Assembly组装整个页面，然后返回HTML给客户端。整个WSS/SPS的页面都是基于Page Ghosting的（除了自己建立的Web部件页），那么页面外观框架的重用性就比较高，多个页面共享一个Page Ghosting的时候会带来不少性能方面的益处。然而Frontpage会破坏这一切（当然，有的时候他也必不可少），它会使使用它编辑过的页面部在使用Page Ghosting，而是将整个页面保存在了数据库中。在用户再次请求访问的时候，执行的工作就大不相同了，整个页面的框架和内容都需要从数据库中载入，而且不会再有重用。因此提高Sharepoint站点访问速度的第一个建议就是尽可能避免破坏Page Ghosting。

第二个方面还是颇具争议的XHTML，下面的图是使用PowerBand查看的一个WSS页面的结构。

整个页面被包围在一个Table中，然后是众多Table的嵌套。浏览器对HTML的解析和显示方式我们很清楚，当一个表格没有全部下载完成之前是不会显示出任何内容的。这样的代价是等待，等待所有的页面元素全部下载完。你只能看着进度条发呆了J。XHTML的所有标准确实苛刻，况且IE浏览器也并非对XHTML绝对有好，我也不再强调完全的HTML，但我喜欢拆分页面的一个Table为多个，就像Sina的结构，多个表格，让Title部分可以优先页面载入完成前显示出来，然后依次向下。用户不必再毫无指望的发呆，总有一些期盼展示给他了。

第三个建议和WebPart的开发有关了。按照需求，我需要开发一些WebPart用于显示公司内其他OA系统的数据在我们的Portal上，有人事的信息，有财务的数据，还有工作流程的审批过程。我们的数据源来自其他系统提供的友好接口或Web Services。还有，我还需要从Internet上面请求一些新闻、天气之类的HTTP回来做成WebPart来使用J。那么问题又出现了！每个WebPart就像一个UserControl，页面按照一个顺序进行Render。取回人事数据花了2秒，Web Servers花了3秒，HTTP请求可能会等待5秒甚至更慢一些，这时候，我要访问的Sharepoint页面就至少需要10秒才能打开，当然这还是比较乐观的。你知道我要说什么了，是的，异步！具备异步机制的WebPart不再会让页面的Render事件累加，而必然小于那个我们不希望的时间。Microsoft.Sharepoint.dll本身支持异步数据获取，仔细读一下《Asynchronous Data Fetching》。其实实现起来蛮简单。一个最简单的例子：

public class AsyncWebPart1 : WebPart 
{
  bool m_AsyncWorkComplete = false;
  string m_Data = string.Empty;
  public override bool GetRequiresData()
{
    return (m_AsyncWorkComplete==true);
  }
  public override void GetData()
{
    RegisterWorkItemCallback(new WaitCallback(AsyncTask), "pass any call-specific data here");
  }
  public void AsyncTask(object state)
{
    // call across network
    // assign data retreive to m_Data field
    m_ AsyncWorkComplete = true;
  }
}

另外，你还可以在Sharepoint Customization这个网站上找到一个实现的更精巧的例子“Asynchronous Web Part Sample”。

还有最后一点没有被我遗忘，Cache。使用Cache保存数据和请求的外部对象。使用合理的序列化保存WebPart的用户定义参数。这一点对所有的ASP.NET应用都是有效的提速方案。

没有力气再向下写了，就算一个RC1的版本吧J，贴出来给大家砸，欢迎补充，欢迎指正。

首先，你需要在数据库中建立一个链接服务器，打开SQL Server Enterprise Manager Console，展开Security节点，然后是Linked Servers，右键New Linked Server…。在Linked Server文本框中输入一个ADSI，Provider name