最近几件比较烦心的事儿

--

     数落下最近几件比较烦心的事儿，

1. MOSS 2007迁移的问题：在工作组中做好所有的定制和开发，使用stsadm -o backup备份成dat文件包，部署到生产环境中，从页面访问一切正常，按照惯例到管理中心将网站集管理员更改成域帐号，工作组模式下一般是：YouServerName\Administrator，打开管理中后提示找不到该用户，正常，删掉之后添加spsadmin之类的域用户，正常；本以为一切搞定，可随后一个小问题吓了我一身冷汗： 在用Designer打开如何一个aspx或者masterpage时候提示没有权限访问，需要联系管理员更改凭据之类的话，死活不能打开服务器端页面，html的倒可以，重启IIS，服务器，清空所有缓存，Cookies,照旧阿，一阵狂抓之后，看到了一些端倪：
   
   转：SharePoint站点中用户信息与AD用户信息的“不一致”问题 
   
   先把问题描述一下：已把AD用户“User1”加到SharePoint站点中，然后进行如下类似操作：将“User1”从SharePoint站点中删除，将“User1”从AD中删除，在AD中增加一个新用户“User1”，在SharePoint站点中增加一个用户“User1”，这时，您会发现很有意思的问题：可能可以成功增加这个用户，但是这个用户始终无法登录到SharePoint站点中；或者根本增加不了这个用户到SharePoint站点中，提示您站点中已经存在这个用户了。
   
   在上次CSDN站点的SharePoint技术聊天活动中，有参与的网友询问了类似的问题，由于当时我在聊天活动中无法给出非常详细的解释，所以只是给出了一个相关的链接。今天用这篇文章详细解释一下。
   
   这个问题出现的原因，是出自SharePoint对于站点用户的存储机制所造成的。SharePoint站点用户信息保存在站点对应的内容数据库的UserInfo表中，如果站点管理员删除了站点中的某个用户，您可能会惊奇的发现，这个用户相应的记录并未从UserInfo表中删除，而只是将“tp_Deleted”这个列的数据进行了设置。（这种机制的原因所在是这条记录可能已经通过外键关联了其他表的其他记录，比如此用户编写的文档，所以将此记录直接删除是不可取的。）
   
   在以后，如果站点管理员将一个同名的用户增加到这个站点中，由于UserInfo表中已经有这条用户记录的存在，所以SharePoint也只是将这条记录的“tp_Deleted”列的数据再进行设置。
   
   这时候，问题就来了。在UserInfo表中，有一个“td_SystemID”列，这个列是用来记录这个用户的Security Identification Number（SID）的。我们在AD中删除一个用户，再新增一个同名用户，这先后两个用户的SID肯定是不同的。而SharePoint使用了这个“td_SystemID”列来识别用户，由于前后两个用户的SID肯定不同，所以SharePoint站点就“不认”在AD中重新增加的这个用户了。
   
   解决方法就是把UserInfo表的“td_SystemID”列的数据和当前AD中的用户信息进行同步。在SqlServer中有一个SUSER_SID()函数，可以返回某用户的SID信息。在Dean的Blog上，他已经给出了一个完整的Sql语句，大家可以直接使用。
   
   顺便题一下，在Deam的Blog上，他也描述了这个问题所造成的另外一个问题：如果我们备份站点的时候，将用户信息也一起备份了下来，在恢复到另外一个AD中时，如果站点用户有同名的现象，也同样会造成SharePoint“不认”这个AD用户。
   
   Sql语句：
   
   
   DECLARE @login varchar(40), @systemid varbinary(128)
   
   DECLARE curUsers CURSOR LOCAL FOR 
   SELECT tp_login, tp_systemid FROM userinfo where tp_deleted = 0
   
   OPEN curUsers
   
       FETCH NEXT FROM curUsers INTO @login, @systemid
   
   WHILE @@FETCH_STATUS = 0
   BEGIN
       PRINT 'Resetting user ' + @login + ' to new SID '
       PRINT suser_sid(@login)
       UPDATE UserInfo
           SET tp_systemid = suser_sid(tp_login) WHERE CURRENT OF curUsers
       FETCH NEXT FROM curUsers INTO @login, @systemid
   END
   
   CLOSE curUsers
   DEALLOCATE curUsers
   
   GO
         看来已有先人遇到此问题，可和我的问题有点不一致，仔细分析分析，决定试一试，如是备份，执行脚本，提示不能将null插入system\sharepoint sip列之类的信息，其它的用户都执行成功，匆匆打开designer，结果照旧，我疯。看来最下策是一点一点来部署了，样式，模板页，Theme，wsp，UC等等，好大的体力劳动哦 ，还是将dat文件restore到当前环境中覆盖最快最省事。天生比较懒，决定再试一试，死马当活马 医了，既然页面能打开（使用domian\spsadmin），那么designer肯定没有问题，一阵狂抓与滥点鼠标之下，搞定！
   
   使用SharePoint新建内容 功能，选择使用现有母板页新建aspx页面，随便搞个名字，保存，嘿嘿，成功了一半，再双击打开，成功了大半，再双击masterpage，成功了。
    太假了吧，看来还是缓存搞的鬼，但也不能这么折腾我啊，差点耽搁工期，唉。。。。几下一笔，希望筒子们碰到此问题后找出根本原因来Share下，感激不尽，本人实在不想去寻根究底了。
2. OBA & VSTO 2007 的部署：开发的时候那个爽阿，部署的时候问题全部来了：
   
       曾经在一个 VSTO 2008 的讨论会上听到一些小型软件开发商的担忧：我们本来使用 C++ 为 Office 开发插件，然后通过互联网给用户下载，并且收取费用。现在我们想用 VSTO，但是发布插件的时候，居然要用户下载 200MB 的 .NET Framework？？？我的插件本身才 50K 哎！我的很多用户现在依然使用低速网络接入，200MB 的内容够他们下载整整一天的了，这样我的产品怎么卖得出去？
   
   　　发布，很现实的问题，开发人员使用 VSTO 强大的功能，可以快速做出以前很难实现的功能，可是如果最后却很难把产品分发给用户，那前面的工作又有什么意义呢？在企业内部，我们可以通过“推送”的方法把 .NET Framework 方便地部署到每个客户端 PC，接下来再部署基于 VSTO 的解决方案就不是那么困难了；但是对于 ISV 呢，难道他们就注定和 VSTO 无缘了？
    分析的很贴切啊，来自：VSTO 先瘦身再发布：客户端配置文件  

   Deploying a VSTO 3.0 solution for the Office 2007 using Windows Installers

        正在研究解决之道。。。。。

3. MOSS数据库CPU利用率动不动就100%，白天工作日也没有配置爬网呢，计划都是夜里1点开始，倒不是因为MOSS不能用，而是数据库上还有其他应用系统的数据库，导致其它系统响应缓慢阿，数据库是DELL的8CPU，16G内存，硬盘15K的64位机器，赶紧去解决问题。。。。。