文武之道，一张一弛

客户用MOSS2007重新创建了门户网站，但是又不想丢弃原来2003上面的数据。则需要一个将2003的数据迁移到2007的方案。

客户的SPS2003里面主要是文档库和列表。这些文档库和列表都有大量的自定义视图。SPS2003里面的数据有大约50G。

我是如下做的：我确定了客户的SPS2003的补丁情况，创建了一个和客户环境相同的中间环境。再请客户备份出一个典型的网站，交给我恢复到中间环境。中间环境按照“in-place”的模式升级到MOSS2007，然后再备份出一个新的备份数据，恢复到新建的MOSS2007里面。之所以选择备份而不是导出，是发现导出会丢失视图信息，而客户有大量的视图。

这个方法也有不足。主要是备份只支持站点集，不支持某一个具体的网站。

“in-place”模式的安装过程：

1. 把SPS2003的环境升级到SP2。
2. 安装.NET Framework 2.0和3.0。
3. 做“预扫描”操作。
4. 使用MOSS2007的安装文件，安装程序会自动进入升级模式。
5. 运行设置向导。

这个过程需要在服务器场的每一个服务器上面执行。

参考：http://technet2.microsoft.com/Office/en-us/library/8a911115-de8a-4cf3-9701-f5ba78fa8bfc1033.mspx?mfr=true

使用WSS3.0构建了一个Wiki和Blog站点。

Just4Fun的Wiki

Just4Fun的Blog

用WSS3.0做Blog是不是很酷阿？

2月份以来事情相当的多，没有更新。最近的技术试验工作比较多，估计会有比较多的文档上来，但是我的小孩快出生了，不知道能高出多少文档上来...

第二天几乎没有什么进展，上来就碰见了问题。

我是一台服务器上面做的服务器场模式安装的WSS3.0，SQL使用本机的2005标准版。服务器上带DC和DNS。

在安装完毕初始化以后，按照联机的帮助，启动搜索服务。服务帐号和内容访问帐号都是域administrator，但是出现错误提示信息“此服务器不是该搜索应用程序的索引器”。我找了一下，没有发现WSS里面配置应用程序的索引器的地方。

我接下来创建了Web应用程序，在创建站点集的时候，出现“因为服务器当前的配置不支持，所以无法显示该页。若要执行此任务，请使用Stsadm.exe中的命令行操作”。我在命令帐号测试了命令“stsadm -o createsite -url http://s1.zc.intra -owneremail wss@zc.intra”，提示错误“指定的域不存在，或无法联系。<异常来自 HRESULT:0x8007054B>”

问题发给了一些朋友，都还没有遇见过这样的问题。郁闷阿，在网上在搜搜看吧！

昨天微软网站上面终于可以下载正式版的WSS3.0的SDK了，我的WSS之旅也开始了。学MOSS（SPS）是要先学的WSS的，这个是我的在SPS学完的体会。WSS是MOSS和SPS的基础，同时WSS的免费也使WSS的使用面积更大。

这次不是第一次安装WSS3.0。在WSS3.0刚发布的时候，就装了一次，朋友们翻看前面的Blog会看到。第一次安装的时候使用的是简单模式，也就是安装程序会自动地使用独立服务器的模式，同时还会安装一个Micro版的SQL Server2005。但是那种方式好像默认不能使用域帐号，自动使用本地帐号了，除非你在没有本地帐号的系统上面来安装（比如域控制器）。

这一次我是用的高级安装，之后会提示是Web前端服务器还是独立模式。我想上次按照独立模式安装了，这次就选的Web前端服务器模式安装的。Web前端模式开始会提示运行服务的账号是什么，为了避免麻烦，使用管理员账号。接着提示选择创建服务器场，还是使用存在的服务器场，这一点根据SPS2003的经验，应该是创建服务器场。然后填数据库服务器，我的VPC里面装了一个SQL 2005的标准版，就使用本机的SQL Server。在之后就使验证模式，我选的NTLM，这主要是我开分不清两种的区别，看提示以及SPS2003的经验，NTLM似乎会简单一些，那就选简单的。再往下会让人选择本地账号模式还是域帐号模式。我选择的域帐号模式，我把这个VPC做成域控制器了，他接下来会提示用于WSS的帐号会放在哪一个OU里面，我创建了一个SharePointOU。这里说句题外话，这点看似体贴的服务，实际也不是很好，如果域控制器上面的要使用的WSS的帐户在不同的OU怎么办？也许后面还有解决的办法，但是现在看起来有点莫名其妙。再后面安装还有什么步骤想不起来了，应该是就开始那9个安装步骤了。

安装好之后看了一下SQL里面的表，比SPS要好得多，除了配置数据库之外，管理中心网站只创建一个数据库。这样使得直接从数据库备份简单了许多。

打开WSS3.0管理中心，我没有继续深入做配置，而是先打开了帮助文档。根据WSS3.0beta2时候的经验，WSS3.0的服务器场还是和SPS2003的服务器场有相当的区别的。简单看了一下，需要做的配置如下：

• 启动搜索服务
• 创建Web应用程序和网站集
• 创建备用访问映射（如果只有一个Web前端就不必了）
• 配置传入电子邮件设置
• 配置传出电子邮件设置
• 配置工作流设置
• 配置诊断日志记录设置
• 配置防病毒保护设置

现在的WSS3.0真是和WSS2.0不可同日而语，简直就是一个SPS2003的.NET3.0加WF的版本了，有服务器场，有索引服务，还有搜索，了不起。今天的时间不早了，明天再慢慢消化WSS3.0的文档，消化完以后继续写...

中文SPS2003发布的时候，正值2003年，.NET Framework 1.1和Windows Server 2003刚刚发布不久。但是随着.NET Framework 1.1的补丁不断出来，以及Windows Server 2003的补丁不断推出，即使SPS2003也不断推出补丁，但是还是有一些著名的小问题。比如中文的SPS2003的管理界面都变成了英文的界面。

这个问题估计可能不是SPS2003的问题，因为SQL Server 2000 Reporting Service也有类似的问题，解决的办法也是一样的。我最早发现这个问题是在2004年，当时.NET Framework 1.1 SP1刚刚发布。咨询微软的工程师，得到了support网站的一篇文章。文章里面讲由于.NET Framework 1.1 SP1的某些安全改进影响了.NET Framework 1.1的i18n解决方案，导致SPS2003的管理界面变成了中文。解决办法很简单，在创建的网站的web.config文件属性的“安全”里面，添加一个“Everyone”，并赋予“完全”的权限。这个方法在某种程度上会降低安全性，但是具体会带来什么危险，我也不清楚了。

最近，客户和我反映管理界面还是经常变成英文的，用上述的方法改一下，过一段时间就又会自己的变成英文的。我自己试了一下，发现上述的方法好像跟本不起作用了。我向客户了解了一下，最近对SPS2003做过什么处理，结果是客户最近部署过自己开发的WebPart，在web.config里面添加过SafeControl。我看了一下，发现web.config文件的编码被改成ANSI的编码了，修改为UTF-8编码以后，不用修改权限，管理界面就恢复中文了。再仔细研究了一下用户的使用习惯，她总是先下载web.config文件，用UltraEdit编辑以后，在上传回去。问题就出在UltraEdit，它在保存文件的时候，并不保持文件原来的编码格式，而是默认使用当前系统的默认编码(GB2312)来保存。不知道这个是UltraEdit的功能还是缺陷，或者其他人汉化导致的。

Reporting Service的问题也是类似的，我们做过一个安全插件，编辑过他的两个虚拟目录的config文件。把这些congfig文件的编码和权限调整过来以后，Reporting Service的管理界面也恢复正常了......

我在这里向大家推荐Editplus2编辑器，韩国人开发的，相当不错，支持在ftp里面直接打开，还可以另存到ftp上面。只不过好像国内没有代理商......

最近一直在做一个项目，以SOA为理念基于SPS2003的三个应用系统。后端以WebService提供服务，前端为嵌入SPS的UserControl，WebService与UserControl之间由序列化的对象进行通讯。由于开发环境是VS.NET 2003，所以就直接使用VSS6d来管理代码了，结果问题就跟着来了：VSS6d不支持UTF-8编码的程序文件以文本方式储存，否则就只能二进制方式存储。在开始阶段主要是开发WebService并没有什么问题，但是随着大量的UserControl开发出来并部署到SPS2003当中的时候，测试人员报告界面乱码。手工把ascx文件转换成UTF-8编码后，问题消失。

这样貌似问题解决了，但是以后每次重新编译部署的时候，都要把上百的ascx文件的编码手工修改一遍。修改编码成了一个极其繁琐的体力劳动......自己研究了一下，又请教了一下微软的工程师，有三个解决方法：

1. 在备份以后，重新把代码加入VSS的代码库，使用二进制方式存储代码。这会带来两个问题：一是二进制方式存储，在不同的代码版本之间不能做Different操作，二是二进制方式存储不再是层量存储，每签入一次，保存的都是一个完整的副本。
2. 使用VS2005 TFS来做代码管理。这需要在VS.NET2003内安装TFS的插件。这种方法微软网站上面介绍过，没有实践过。
3. 使用批量转换工具将ascx的编码转换过来。

我的项目现在只好使用第三种方式，但是找不到有批量的GB2312转UTF-8编码的工具，我只好自己写了一个。这个工具内部的转换引擎是GNU的libiconv，大家可以下载我编译好的版本直接使用，或者下载源代码自己研究。这个工具用.NET2.0写的，所以运行需要.Net Framework 2.0 Runtime。

细心的朋友会问我，为什么我只强调了ascx为什么没有提asmx呢？我当初也奇怪这个问题，后来研究了web.config文件里面的system.web段的globalization的fileEncoding属性约束了ASP.NET从本地读取程序文件的编码。在默认的ASP.NET项目的web.config里面是没有这个属性的，ASP.NET默认会以Windows的默认代码页来读取程序。而我们的asmx文件内部没有中文，即使有中文，ASP.NET也可以识别出来。

但是SPS2003创建的站点里面的web.config文件里面的system.web段的globalization的fileEncoding属性为"utf-8"。我测试了一下，这个属性删除以后，SPS也会有莫名其妙的错误，看来还是不能删除的。

今天访问一个朋友的TFS站点，也就是一个Windows Sharepoint Service v2的站点，在创建文件的时候，突然发现在WSS的文档库里面点击“新建”的时候提示：

---------------------------
Windows Internet Explorer
---------------------------
“新建文档”需要使用与 Windows SharePoint Services 兼容的应用程序和 Microsoft Internet Explorer 5.0 或更高版本。若要向此文档库添加文档，请单击“上载文档”按钮。
---------------------------
确定
---------------------------

正在郁闷的时候，发现ie7提示要安装一个微软的插件，是owssupp.dll。怀疑了一下，就大胆子装上了，结果又提示一个微软的插件owsctl.dll。已经装了一个了，索性这个也装了。这个时候突然发现“新建”恢复正常了，再检查ie7里面的已经使用的加载项中多了一个如下两个条目：

 也许这就是ie7标榜的安全性？还是WSS不认识ie7的版本，得当作ie5处理了？

今天上午WSS3.0提供下载了，中文版也一同发布了。正好手头有一个.NET Framework 3.0的虚拟机，立刻就把这个东西装上了。感觉不错。安装过程很顺畅，没有BETA2时候安装不长的问题了。安装过程和MOSS2007 BETA2的安装过程很像，但是缺一些东西，估计这些就是区别。

现在发现的和MOSS2007的区别是MOSS2007独立模式安装的时候，会安装一个SQL Server 2005的Express版的引擎，这个引擎可以通过标准的SQL Server 2005的管理工作室进行管理。而WSS3.0独立模式安装的时候，数据库引擎是一个SQL Server 2005的嵌入版。在使用SQL Server 2005的管理工作室的实例列表当中可以看到他创建的实例，但是不能连接，提示“引擎不提供远程连接功能”。估计这就是SQL Server 2005的Express版和嵌入版的区别所在，还有就是嵌入版默认的安装位置是%windir%\SYSMSI目录。我是第一次知道有这样一个SQL Server 2005的版本存在，需要研究一下这个版本的特性。

WSS3.0的内存消耗堪称一流，我的机器上除了企业版的SQL Server 2005以外，就是这个WSS3.0和其附带的嵌入版的SQL Server 2005了，这个时候内存占用达到了850兆。不知道MS怎么想的，这个内存的消耗是在太大了，虽然现在内存便宜，工作组服务器也不贵，但是这样的内存消耗也太大了点...在虚拟机里面有点实在吃不消了。

在前两天随.NET Framework 3.0一起发布的VS.NET 2005的WSS3.0扩展是个很不错的东西，除了带有Webpart模板意外，还能创建站点定义。这个可以看看陈曦的blog里面的描述。

前面一段时间我的blog里面的文章少了，但是随着.NET Framework 3.0和MOSS2007的到来，各样的文章会如潮涌一样上来的...敬请关注

详见Keith Richie在MSDN的Blog

下载地址：http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=SPUS&ReleaseId=614

这样的事情在生产环境很少见，但是在我们搭建演示平台的时候，还是比较常见的。我们首先安装SPS2003，在SPS安装成功以后再安装Exchange2003。

安装成功以后，我们要将Web访问Exchange需要的几个虚拟目录加到SPS当中，我们知道SPS2003的会把站点的文件存储转向，没有这一步，我们就没有办法通过web来访问Exchange的web功能。

这一步需要C:\Program Files\Common Files\Microsoft shared\web server extensions\60\bin中的STSADM程序。具体的格式为：
STSADM -o addpath -url http://localhost/<你的Exchange> -type exclusion

需要加的虚拟目录包括：
Exadmin   Exchange的Web管理端
Exchange Exchange的Web访问入口
ExchWeb  
Microsoft-Server-ActiveSync   Exchange用以远程同步移动设备的接口
Public      Exchange的公共文件夹

这个方法也适合我们部署ASP.NET应用到SPS2003所安装的服务器：
在我们创建WebApplication之前，先在C:\Inetpub\wwwroot创建和你WebApplication同名的文件，然后在IIS当中的这个文件上创建应用。之后使用上面的命令。再在VS2003里面在http://localhost 创建那个名字的WebApplication就不会有问题了。

SharepointChina应该算是国内最专业了Sharepoint的站点了，它由Kaneboy创立。应该国内最有潜力的Sharepoint社区了。

大都是2004年的时候写在http://blog.aspcool.com/fatiao 上面的。总共13篇，涵盖当时在FreeBSD5上面实践Mono和SPS的一些文章。可以从首页上面选择2004年的几个分类来查看。

这几天一直写一个在SPS当中修改AD用户密码的Webpart。我向鞠海洋大哥要来了他写的代码，仔细研究了，自己也动手写了一个。但是包括鞠大哥写的和我写的都不用正确运行，总是捕捉到异常信息。不同的是，鞠大哥的代码可以显示用户的displayName属性，而我的显示不了。

昨天就想起来在ASP.NET中测试一下吧，毕竟ASP.NET当中条是要容易些。我有在写Webpart之前，先用ASP.NET预演的习惯。但是却发现ASP.NET当中不仅可以显示displayName属性，连密码也可以修改了。于是又仔细看了鞠大哥的代码，发现他并不是从AD用户的displayName属性显示的用户名称，而是通过SPS的CurrentUser对象来获取的用户名称。这样在仔细测试后可以发现，在SPS的Webpart当中是没有办法读取AD内数据的，即使将SPS网站的安全信任级别提高到了“Full”也是不行的。

详细的错误信息：
System.Runtime.InteropServices.COMException (0x80070035): 找不到网络路径。 at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_NativeObject() at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args) at nChi.WebParts.Utility.UserCtrl.chgPwd()

以此猜测这可能是SPS把有关的COM调用给屏蔽到了...

前两天SPS的数据库服务器坏了，数据被迁移到了备用数据库。这两天把原来在SPS上做的应用都检查了一遍，发现一个使用SSO的Webpart不能正常工作了，表现就是SSO不能正常取出数据，成脱机状。

找不到原因，有怀疑是迁移数据库或者安装了SPS2003的SP2造成的，于是重新安装了SPS2003而且没有安装其SP2。但是问题依旧，于是开始分析我的代码。最终发现是我的Webpart的问题：界面上显示从SSO当中获取的帐号，是在调用一个WebService并得到正常返回以后才显示，而当数据库迁移以后，WebService的数据连结没有更改过来，WebService没有返回一般性的错误代码；而我的代码只对WebService正常返回和一般性错误信息进行捕获。这样造成了我的Webpart的假脱机状态。

最终可以确定SPS2003的SP2不会对SSO造成这样的影响，但是不能确定数据库的迁移会不会对SSO造成影响。

在以前的Blog上面曾经对这个方法曾经进行过描述，但是当时没有验证。这次服务器坏了，终于有机会进行验证了。只不过这次不是服务器升级，而是服务器坏了，要换成新的服务器。

下面是引用的原来Blog内容。
场景：
用户的SQL Server 2000服务器需要扩容，原本想做SQL Server服务器群，后来客户决定从新建SQL Server服务器，SPS使用新的SQL Server 2000服务器。
方法：
1．在“配置服务器场拓扑结构”中去掉服务器场中所有的服务器角色的设置。
2．在“指定配置数据库服务器”中断开与当前的数据库服务器的连接。
3．将旧的数据库实例暂停，复制SPS的配置数据库和内容数据库的数据文件和事务日志文件到新的数据库实例上面上。
4．在新的数据库实例上面创建配置数据库和内容数据库。数据库的名称不能改变。
5．在新的数据库实例上配置新的帐号。帐号应使用原来的数据库帐号。
6．回到SPS的“指定配置数据库服务器”，当中按照“连接到现有的配置数据库”进行配置。
7．重新启动“SSO”服务，并将服务改为“自动”。
8．重新启动SPS服务器。
说明：
第8步，不知道什么服务需要新启动，所以干脆重新启动了服务器。各位同学可以试试看，到底是哪个服务器需要重新启动。

此外需要说明的是，除了SPS的以外，WSS的配置数据库和内容数据库也需要调整。在调整完成以后，需要把旧的服务器从服务器列表中删除。

最近在忙着研究SPS，在定制首页的时候发现页面里用了大量的SPSWC的控件，提笔总结一下。这些好象都是MSDN里面没有的。

<SPSWC:CollaborationServerMetaTag>

这个标签将服务器上定制的<meta>标签写到页面。不需要页面中有HtmlForm的存在。

<SPSWC:ShowMessageToNonScriptableClients>

这个标签会在不支持脚本的浏览器上显示警示信息。不需要页面中有HtmlForm的存在。

<SPSWC:WebProperty>

这个标签会显示网站的属性例如：

<SPSWC:WebProperty Property=“SiteTitle“>

不需要页面中有HtmlForm的存在。

<SPSWC:CategoryProperty>

这个标签会显示子区域的属性例如：

<SPSWC:CategoryProperty Property=“Name“>

不需要页面中有HtmlForm的存在。

<SPSWC:CustomCSSResourceElement>

这个可以把定制的样式表写到标签的位置。不需要页面中有HtmlForm的存在。

<SPSWC:PageHeader>

这个标签可以输出设置里面设置的Logo。不需要页面中有HtmlForm的存在。

<SPSWC:CategoryNavigationWebPart>

这个标签可以输出子区域导航菜单。不需要页面中有HtmlForm的存在。

上次向飞鹰推荐了Yet Another Forum论坛，但是飞鹰没有用。他不用没关系，我用。我在现在实施SPS的项目中，客户不满意SPS的讨论版。我本来想使用ASP.NET Forum 2，但是现在发现她变成商业的了，于是我们决定使用Yet Another Forum，它是GPL的。开源+免费有什么不好？

YetAnotherForum的域整合非常简单，首先要在安装一个非域验证的实例，在选择管理员账号的时候比较有技巧：帐号最好和将来域里面准备作为论坛管理员的账号一致。这样做是为了在与域整合以后不用再调整论坛的管理员了。其他的安装可以按照软件包里面的说明进行。

在非域验证配置完成以后，我们开始进行域整合的配置。我们需要修改Web.Config，将验证方式改为

<authentication mode="Windows">
</authentication>

然后修改IIS关于这个应用的验证方式为Windows域服务器的摘要式身份验证，同时将你论坛程序所在的目录赋予读/执行/列表权限给相应的域用户。

这样在你再次访问的时候，你就会发现已经能像SPS一样整合使用与账号了。而你当初指定的那个账号会自动变成管理员了。这样你就可以开始你的其他论坛配置了。

我现在的项目是一个电信企业的企业门户，使用SPS2003来搭建。为此项目专门申请调配了一个内存1GB+256MB的PC做服务器。

做这个开发环境有两个方案，一个方案是所有的软件安装都安装在这个物理服务器上面，另一种方案是在这个PC上面做若干个虚拟机，模拟真实的环境。

首先说说第一个方案。第一个方案需要将这个PC安装win2003系统，并建成主域控制器。安装应用服务器(IIS+ASP.NET)，之后还要代开SMTP和NNTP，然后再安装Exchange2003、SQL2000+sp3。最后就可以安装SPS2003了。值得注意的是，安装应用服务器的时候不能安装Frontpage扩展，这个扩展和SPS2003有冲突。

这个方案的优点是速度快、一台服务器便于移动，然而缺点却比较多，。这个PC应为自己作为主域控制器，所以不适合（不等于不能）再加入现有的域。同时这个PC不容易管理，Win2003的终端服务器必须有终端授权证书服务器才可以不限时间的运行，但是即使是免激活的开放许可Win2003里面的终端证书服务器也是需要激活的，电话激活或者互联网激活都比较麻烦（需要开放授权的ID）。否则就要使用其它的远程管理软件，会产生其它的费用。如果将来有新的服务器或者PC调配过来，软件迁移到其它的服务器很麻烦。

再说第二个方案。这个方案的是将所有的软件都安装在虚拟机里面。宿主服务器的操作系统可以选择Win2003或者Linux。如果宿主服务器是Win2003，那么虚拟机软件必须是Visual Server 2005。如果想要宿主服务器使用Linux，可以直接使用VMware ESX Server，它内置一个定制的Linux系统，可以安装在无系统的主机上面。VMware ESX Server和Visual Server 2005比较，主要是强在VMware可以设置虚拟机具体使用几个CPU，和具体使用哪个CPU。

我现在使用的就是第二个方案。建了两个虚拟PC，第一个虚拟PC作为域控制器，安装了Exchange2003和SQL2000+sp3，分配了256MB内存。第二个虚拟PC只安装了SPS2003，分配了512内存。

这样做的优点是都可以通过Web远程管理，同时自带远程管理工具和虚拟终端。VMware ESX Server的虚拟终端可以是任何VNC软件，而Visual Server 2005的虚拟终端叫 VMRC（Virtual Nachine Remote Control Client），不需要单独的授权。虚拟机搬迁起来也很方便，将虚拟机的配置文件和相应的虚拟硬盘文件搬迁到新的服务器然后导入虚拟机就可以了。缺点就是速度比物理服务器实现的慢，相应对宿主服务器的硬件要求要高！

这两种方案各有千秋，可以用在不同的时候。比如我在去帮助市场人员做售前给客户演示门户系统的时候就是使用的第一种方案，将所有的软件装在了一个1G内存的笔记本电脑上面。而我们在内部开发的时候使用的就是第二种方案，毕竟服务器的速度要比笔记本电脑快的多。