前几天部署BugTracker，领导看了下运行效果觉得不满意，让我换个免费产品来做错误跟踪系统并推荐了下windows sharepoint services（以下简称wss）以及bugdatabase模板,由此我踏上了一条充满着荆棘的道路。安装wss本身倒是没什么难度，不过看网上看到有个帖子说要最好在第一个选项对话框的第一个页签勾选第二个选项（就是全部安装），我照办了，这还算顺利，我也在安装过程中看了小小的休息了下。
wss安装完后，就准备部署模板了。照惯例，我先搜索了下网络，按照前人经验选择了先部署applicationcore那个模板，第一个addsolution命令执行成功，不过接下来由于我的鲁莽行事当使用deploysolution的时候没有加上相关参数，也没执行时间机去执行部署任务，而是直接就忽略deploy那个命令执行copy***那个命令，当然在安装bugdatabase模板的时候发现了这个问题，安装bugdatabase倒是成功了，于是我也没多想直接去创建网页了，选择好bug模板，点击“确定”，终于报错了。去wss的管理页看原来core模板的部署是error状态。于是我又卸载了wss，再重新装；可是执行addsolution命令的时候就报错“解决方案存储区已经存在该方案*****”。在网上搜索了，无论是国外的还是国内的，对于解决方案存储区都没有与我的问题相关的网页，看来我只能靠自己来摸索了。
首先沉下心来思考，卸载后显然有些东西并未被同时删除。
于是我将wss安装文件夹的东西在又一次卸载后删除干净，然后再安装仍然报同样的错误，疯了。。。。。。。看来没找准位置。
接下来我考虑temp，internet temp 文件，卸载wss后删除干净了，可惜结果仍然是残酷的
最后只能不断的看微软的相关文档先是msdn后来是technet，在阅读文章的过程中总算发现一点线索：有个网页在提到解决方案存储区的同时也提到了配置存储区，并且说后者包含前者。
我赶紧google配置存储区还有wss安装文件位置，一顿狂找，总算找到了：配置存储区原来在一个sql server桌面数据库里（由wss创建，但是卸载的时候并不删除它），可是找遍了program files和添加删除程序对话框硬是没找到有数据库服务器特征的程序文件夹。我k，怎么藏的这么严实啊？突然想到不是说sqlserver数据库么，那么数据库的后缀名不是mdf么？那俺们就搜索下这类文件，正好我的机器在此之前也没装sqlserver这种数据库。
等待若干分钟后，看到出现在眼前的搜索结果中赫然有了“sharepoint 。。。config”字样的mdf文件，我忍不住热泪盈眶：mlgbd，微软咋把这数据库藏在了windows下一个sysmsi的文件夹中，还好我rp出众，总算把它给逮到了。看来只要把和sharepoint相关的数据库删除掉就应该可以了，我想到这些就马上出手了。
卸载wss后，重启机器，将含有sharepoingt字符串的数据库都删除掉了，再安装wss，在安装成功后进行环境配置的时候跳出个“找不到恢复sharepoint。。。config数据库的。。。，配置失败”。看了下安装日志，然后想想：看来删除带有sharepoint字样的数据库仍然是不够的！这些数据库还在其他数据库有信息备份着，不然怎么出现“恢复”这样了？现在只能想办法将这个桌面数据库程序卸载掉再删除掉这些数据库了。但是添加删除程序里面没有相关链接，程序本身所在文件夹也没有任何带有uninstall字样的可执行程序，我猛然想吼一下：微软真贱！
还是回到网上搜索，总算知道了用MsiExec.exe能够删除该类bt的程序（参考吹雪的卸载wss3.0自带的ssee数据库的文章）
剩下来的工作就相当简单了。模板也部署成功了，我也终于透了口气。
最后总结一下得失：
1. 通常安装不熟悉的东西前最好不仅能看看产品本身的安装说明也要在网上搜索其他人的安装过程。
2. 程序的日志文件对于开发者和使用者来说都是有力的解决问题的辅助工具，所以请给自己的程序加上日志吧！
3. google真好，msdn真好，technet真好，微软列？唉。。。。。
ps：在发布前，对于发布到首页还是发到新手区徘徊很久...但是为了帮助更多碰到类似问题的人能够找到解决思路，也能让更多的依赖csdn解决问题的人重新树立“靠个人也能解决问题的信念”，我还是忍不住了。。。有质疑该不该发到首页的兄弟手（口）下留情，我只是想帮助人。如果论述中有错误的地方，欢迎指正。