2007年11月4日
#
客户用MOSS2007重新创建了门户网站，但是又不想丢弃原来2003上面的数据。则需要一个将2003的数据迁移到2007的方案。
客户的SPS2003里面主要是文档库和列表。这些文档库和列表都有大量的自定义视图。SPS2003里面的数据有大约50G。
我是如下做的：我确定了客户的SPS2003的补丁情况，创建了一个和客户环境相同的中间环境。再请客户备份出一个典型的网站，交给我恢复到中间环境。中间环境按照“in-place”的模式升级到MOSS2007，然后再备份出一个新的备份数据，恢复到新建的MOSS2007里面。之所以选择备份而不是导出，是发现导出会丢失视图信息，而客户有大量的视图。
这个方法也有不足。主要是备份只支持站点集，不支持某一个具体的网站。
“in-place”模式的安装过程：
- 把SPS2003的环境升级到SP2。
- 安装.NET Framework 2.0和3.0。
- 做“预扫描”操作。
- 使用MOSS2007的安装文件，安装程序会自动进入升级模式。
- 运行设置向导。
这个过程需要在服务器场的每一个服务器上面执行。
参考：http://technet2.microsoft.com/Office/en-us/library/8a911115-de8a-4cf3-9701-f5ba78fa8bfc1033.mspx?mfr=true
2007年5月20日
#
Longhorn beta3英文版里面服务器的角色被称为Role。在Longhorn的beta3里面一共有17种角色：
- Active Directory Certificate Services(AD证书服务)
- Active Directory Domain Services(AD域服务)
- Active Directory Federation Services(AD联合服务)
- Active Directory Lightweight Directory Services(AD轻量目录服务)
- Active Directory Rights Management Services(AD权限管理服务)
- Application Server(应用服务器)
- DHCP Server(DHCP服务器)
- DNS Server(DNS服务器)
- Fax Server(传真服务器)
- File Services(文件服务)
- Network Policy and Access Services
- Print Services(打印服务)
- Terminal Services(中断服务)
- UDDI Services(UDDI服务)
- Web Service(IIS)
- Windows Deployment Services(Windows部署服务)
- Windows SharePoint Services(WSS)
这里面有不少我们熟悉的面孔，还有我们非常熟悉但是需要自己手动安装的服务，还有几个确实全新的。别的不说，单说Longhorn集成了这写服务，方面我们安装配置，这一点来说还是很方便的。
Feature是Longhorn里面最新提供的特性，这不仅让我们想起了WSS 3.0和MOSS2007里面的feature。Longhorn beta3的"Server Manager"里面一共提供了35个feature以及每个feature下属的更小的feature：
可以看出，feature是对原来"Windows组件"的替代（Longhorn beta3已经没有了"添加/删除程序"，以"Programs and Features"代替）。
最近在研究EntLib2.0的DAAB。DAAB的特性之一是可以使我们在编写代码的时候不必关心数据库到底是什么，也就是DAAB可以当作数据库抽象层。但是你得有你要使用的数据库在这个抽象层之下的驱动。
我们知道现在开源关系数据库主要有两个，一个是MySQL，一个是PostgreSQL。这两个数据库现在都有现成的开源.NET Data Provider。由于微软也提供了EntLib2.0的源代码，这样我们很容易仿照其SQL Server的DAAB Database Provider写出他们在抽象层之下的驱动。我试着写了一下，MySQL的部分实现了，PostgreSQL的完全没有实现。
MySQL的DAAB Database Provider除了XmlReader相关的部分，其他部分都实现了。这是由于MySQL的.net connecter虽然是仿照SQLServer的.NET Database Provider来定义的接口，但是.NET Framework 2.0新增的一些内容还没有实现，MySQL对于XML的支持也不如SQL Server那么完善。
PostgreSQL的DAAB Database Provider完全没有实现。和MySQL的.NET Database Provider类似，PostgreSQL的Npgsql也没实现XmlRaeder的功能，除此以外，Npgsql的NpgsqlCommand对象竟然没有继承DbCommand, ICloneable，导致在一些NpgsqlCommand强制转换的情景下会失败。这个情况导致了PostgreSQL的DAAB Database Provider没办法实现。
比较MySQL和PostgreSQL对.NET的支持，看来是MySQL更胜一筹。
为了解决使用Entlib的DAAB来访问PostgreSQL的问题，估计可能得写一个ODBC的DAAB Database Provider了。研究了一下ODBC的.NET Database Provider的情况，似乎ODBC和MySQL的情况类似，在.NET Framework2.0的类库里面并没有对XmlReader支持，估计仍然不能实现ODBC的DAAB Database Provider的XmlReader部分。
下载
2007年4月20日
#
最近的Blog都是使用Word2007来写了。好处不少：
- 不需要在线写，写不完可以随时保存。写的时候体验比在线写要好的多。
- 写完以后可以把内容保存成DOCX文件，方便保存备份。
比较麻烦的是：
- 不支持图文混排的Blog，只能自己手动上传图片，手动重新编辑。
- 不支持分类APi的Blog，只能自己手动修改Blog分类。
由于Word2007的这些特性，我在想，是不是可以用Word2007来备份所有的Blog内容呢？要是Word2007可以备份Blog里面所有的内容，那就太Happy了。
安装独立的根CA服务
- 以管理员身份登录系统，如果有AD目录服务的话，使用与管理员登录系统。
- 点击"开始"，打开"控制面板"。
- 双击"添加或删除程序"，并点击"添加\删除Windows组件"。
- 在Windows部件向导里面，选择"证书服务"。这时会出现一个对话框提示："安装证书服务后，计算机名和域成员身份都不能更改，因为计算机名到 CA 信息的绑定存储在 Active Directory 中。更改计算机名或域成员身份将使此 CA 颁发的证书无效。在安装证书服务前请确认配置了正确的计算机名和域成员身份。您想继续吗?"。点击"是"，并点击"下一步"。
- 选择"独立根CA"。
- （可选）选择"用自定义设置生成密钥对和CA证书"，点击"下一步"指定下面的内容：
设置 | 操作 |
CSP，
密码服务提供人（Cryptographic Service Provider） | 在CSP里面选择想使用的密码服务提供人。默认的CSP是Microsoft Strong Cryptographic Provider。证书服务支持第三方的CSP，但是必须参考CSP服务商的关于在证书服务中使用他们的CSP的信息文档。 |
散列算法，
Hash algorithm | 在散列算法中，点击选择项使用的散列算法。默认是SHA-1。 |
使用现有的密钥，
Use an existing key | 选择"使用现有的密钥"，点击"导入"，然后在"打开PFX文件"中写入公私密钥对文件的名字和密码。这可以帮助你在重新部署的时候恢复以前安装的CA。但是使用存在的密钥时，仍然会生成新的证书。
提示
- 确定选择存在的密钥是安全的可信的。使用不安全和不可信的密钥，会导致CA和发放的证书时不可靠的。
|
密钥长度，
Key length | 在"密钥长度"，敲入或者选择一个密钥长度。默认使用Microsoft Strong Cryptographic Provider的密钥长度为2048位。其他CSP的默认密钥长度是不一样的。一般来讲，密钥长度越长越安全。同样，越长的密码长度在签名、加密和验证的时候需要更多的系统资源。做为根CA，你需要使用至少2048位的密钥长度。这个选项对于现有的密钥不可用。 |
允许此CSP与桌面交互，
Allow this CSP to interact with the Desktop | 选择"允许此CSP与桌面交互"。如果不选择这项，系统服务将不能于当前登录用户桌面交互。 |
导入，
Import | 点击"导入"。这个将导入一个现有的PKCS #12 PFX格式的密钥。 |
查看证书，
View certificate | 点击"查看证书"，这将允许你常看安装过程中生成或者选择的证书。 |
如果配置完成，点击"下一步"。
- 输入一个CA的公用名称。在CA设置完成以后可以修改这个信息。
- 在"有效期限"，指定根CA的有效性期限。考虑这个设置的时候，可以参考下面的注释。点击"下一步"。
- 指定证书数据库、证书数据库日志和共享文件夹的存储位置。点击"下一步"。
- 如果IIS正在运行，你将受到一个安全前停止服务的请求。点击"是"。
- 如果有提示，输入证书服务安装文件的位置。
注意：
- 要打开控制面板内的条目，点击"开始"，点击"控制面板"，双击适当的图标。
- 如果AD可用，并且你有写AD的权限，那么指定共享文件夹是可选的。
- 如果IIS的ASP功能没有被激活，将会被提示激活ASP。CA的Web接口需要ASP可用。
- 有效期限决定CA的终止时间。更新CA的信息，请参考相应的主题。
2007年4月11日
#
找到一个SharePoint的MVP站点列表，里面除了MVP的站点列表以外还有区分了英文与非英文的站点。另外在页面上还有一个这些网站的最新文章列表，估计是RSS汇集到一起做的。
网址：http://sharepoint.microsoft.com/sharepoint/mvps/default.aspx
2007年1月25日
#
第二天几乎没有什么进展，上来就碰见了问题。
我是一台服务器上面做的服务器场模式安装的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的文档，消化完以后继续写...
2007年1月17日
#
我是在用javascript生成Unix时间戳的时候发现的问题。
你可以在c:\创建一个test.js文件，然后把下面的代码粘贴进去，然后在命令行直接执行c:\test.js：
theDate=new Date("January 1, 1970 8:00");
WScript.Echo(theDate);
WScript.Echo(Date.parse(theDate));
secondDate=new Date(1969,12,1,8,0,0,0);
WScript.Echo(secondDate);
WScript.Echo(Date.parse(secondDate));
thirdDate=new Date(1970,1,1,8,0,0,0);
WScript.Echo(thirdDate);
WScript.Echo(Date.parse(thirdDate));
代码说明：这段代码是使用js的Date对象的两个构造函数构造了三个Date对象。第一个Date对象和第三个Date对象以不同的构造方式创建了同一个时间。第二和第三个Date对象使用相同的构造函数创建了不同的时间。
但是结果是：
Thu Jan 1 08:00:00 UTC+0800 1970
0
Thu Jan 1 08:00:00 UTC+0800 1970
0
Thu Jan 1 08:00:00 UTC+0800 1970
2678400000
这明显是矛盾的。我怀疑这是一个js解释器的问题。另外Date的UTC方法也有类似的问题。