由于最近的SharePoint项目需要部署到多台服务器构成的large server farm，项目组成员的开发环境大都基于x86的32位系统，三台专门用于部署测试的服务器也是32bit的Windows Server 2003，但正式生产环境肯定要用x64的windows server 2003（客户暂未采购windows 2008），由于测试服务器和正式生产服务器的操作系统版本差异，在部署的过程中出现了不一致的问题。

　　因此想在自己的开发环境（32bit的windows Server 2003 R2 x86）中弄一个x64的Windows Server 2003模拟生产环境。我们都清楚，在主系统为32bit的系统中是不能通过Microsoft Virtual PC来虚拟出x64的虚机的，因此考虑干掉现有主系统再重新安装64bit的主系统，旦转念一想，与其再安装windows Server 2003，还不如趁此机会直接升级到Windows Server 2008，还可以用眼馋多日的Microsoft Hyper-V还替代轻量级的Microsoft Virtual PC，嘿嘿

　　哈哈，恰好手头有Windows Server 2008的安装盘，备份好数据，又前后琢磨了一下利弊，说干就干！

　　由今天开始，将Windows Server 2008作为偶的主系统！

　　这篇是废话日志，下次说点实际的，讲讲Windows 2008的Hyper-V的使用！

　　最近，一直频繁使用SPQuery或SPSiteDataQuery做SharePoint前后台开发，在基于SPUser的Field进行查询时发现一些比较奇怪的、让人莫名其妙的问题：SPWeb.Users、SPWeb.AllUsers和SPWeb.SiteUsers在不同的域环境和本地环境中出现一些让人不可理解的事情。甚至我都直接怀疑SharePoint设计者在设计开发SPUser这一部分时没考虑周全。下面详述：

　　（先画个图，改天补上描述）

　　经过反复排查、试验过程如下：

　　（我晕，上图画了我半个多小时，明天继续更新）

　　试验结果如下：

　　使用过Microsoft SharePoint Portal Server 2003(简称SPS2003)或Windows SharePoint Services 2.0(简称WSS v2)的朋友可能还会记得，在SPS2003及WSS2.0的管理中心（或使用命令行）可以管理路径：管理包含的路径和排除的路径。通过这种方式可以明确把一些路径标识为可由SharePoint 负责管理(路径包含)；也可以明确让SharePoint将忽略某些路径(路径排除)，排除的路径可由其他应用程序使用，比如普通的asp.net应用程序可使用路径排序的功能来实现。

　　但从最近几年对SharePoint2007(很多时候我用“SharePoint2007”来代替MOSS2007或WSS3.0，如果所述内容在两者中有区别我会明确使用MOSS2007或WSS3.0)的使用来看，并没有发现在MOSS2007(或WSS3.0)中发现路径排除的功能，本周五下午与微软某一SharePoint技术人员交流，被告知“设计sharepoint2003中的‘路径排除功能’的人的脑子就有毛病，压根不需要排除……”，呵呵，偶对此话不敢苟同，今天晚上经过一段时间研究，发现虽然在SharePoint2007的默认管理界面和命令行不能实现“路径排除”的功能，但通过一定的配置就可以轻松达到此目的。

　　那么如何做呢？

　　想实现一个目的：
　　在不改变现在SharePoint站点的默认登陆机制（域用户验证、不开启匿名登陆）的基础上，想把原有的存于SharePoint内容数据库中的Default.aspx换为本地（物理磁盘下）站点对应根目录的某个文件，以实现给SharePoint增加不需要验证的欢迎页面等需要

　　试验结果：
　　在SharePoint对应的本地路径下（如C:\Inetpub\wwwroot\wss\VirtualDirectories\80）下添加一个文件比如Index.aspx，那么直接通过http://moss.webplat.net/Index.aspx肯定不能解析到！为什么呢？

　　原因是：
　　默认情况下SharePoint站点在web.config中完全remove掉所有动作为"GET,HEAD,POST"的httpHandlers，见下面的代码

　　然后把URL请求的文件重新使用Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler进行解构。所有不管在本地如何添加文件（这里的“本地”指未被SharePoint排除的位置，wpresources、LAYOUTS等除外），是不可能通过看似正确的URL来访问到本地页面文件。

　　那么如何解决呢？