我有理由今天玩 codeplex 多面搜索 今天的项目.
到处都有一段时间, 但犹豫了一下下载和使用它的通常理由 (主要缺乏时间), plus outright fear 🙂
如果你想提高你的搜索和探索新的选项, 下载并安装它，当你有一个小时左右的空闲时间. 遵照安装手册 》 和我花了不到 20 分钟要安装和工作. 它提供了价值分钟零.
它看起来很难扩展. 作者为一个复杂的 BDC 场景提供一个详细的演练. 我可能会丢失它, 但愿他们还将提供一个简单的场景，涉及一个预先存在的属性或可能会添加一个新的托管的属性. 我将试着写下了自己在未来一段时间.
底线 — 以分钟为单位, 您可以安装, 对其进行配置, use it and add some pretty cool functionality to your vanilla MOSS search and be a hero 🙂
</结束>
在过去的一周期间, 我 同事 和我在为一个客户端在纽约做一些工作. 我们测试实现使用其"标准的 MOSS 的不同的方面" 工作站版本 (相对于我们的笔记本电脑). 在这样做时, 我们碰到了几个错误按照下面的步骤:
我们是来实现那几次 (通常第一次) 我们将该文档保存, 保存"粘在一起。" 保存未保存. 我们将把该文件拉回上来和我们的改变只是并不存在.
我们此时不理解根问题, 但我们想，我们应该确保，在该工作站上已安装了最新的微软办公软件服务包. IT 人员去那样做了. 我们又通过测试，我们发现了一个新的问题. 当我们保存它, 我们现在有此错误:
这一次, 好像每个更改是, 事实上, 保存, 我们回答是还是不到脚本问题.
我们终于有看看实际版本的 Office 和原来工作站运行 MS Office 2000 与服务包 3 其中显示帮助-下> 关于作为"Office 2002".
这个故事的寓意: 我将始终使用办公室 2003 作为我最低限度基准 office 版本时使用 WebDAV 和苔藓.
</结束>
(为搜索引擎目的, 这是错误的文本):
线: 11807
Char: 2
错误: 对象不支持此属性或方法
代码; 0
您要继续在这个页面上运行脚本?
在一个或我 第一次的博客文章, 我描述我们遵循从 SPS 迁移客户的整个过程 2003 对青苔. 一位读者留下评论问更多的细节和它在这儿.
为该迁移项目, 我们还需要找到移动大量的 SPS 的好方法 2003 文件在对青苔. 初始荷载很容易. 在 MOSS 中创建一个新的目标文档库并使用 windows 资源管理器中移动文件.
这是新的文档库:
打开两个窗口的探险家. SPS 点第一次 2003 第二次在 MOSS 中的新文档库. 下面的屏幕快照显示了这. 请注意，顶级浏览器实际上指向我 c:\临时驱动器, 但是你可以想象它指向 SP 2003 文档库:
那之后拖放式操作, 我目标看起来就像这样:
现在是时间来处理元数据. 假设我们有只有一列的元数据为这些文件命名为"位置。" 我们可以看到从上面的"所有文档" 查看位置为空. 很容易使用数据工作表视图中输入的位置, 或甚至进入每个文档属性一个一个地添加位置. 让我们假设最终用户必须用手这样做，是有没有切实可行的办法来分配位置列的值自动. 此外, 让我们假设有数百个文档 (或许是上千) 和许多天更新元数据，它会把很多. 我们都知道, 没有人会坐下来和工作四五天直更新文件的元数据. 相反, 他们将在几个星期甚至更长的时间内爆发，. 为了促进这一进程, 我们能创造出一种"未加标签的数据" 如图所示的视图:
现在, 当一个人坐下来花他们分配每天一两个小时来标记已迁移的文件, 他们可以使用"未加标签的文档" 视图，以集中他们的努力:
作为用户标记文档, 他们下车此列表.
这种未加标签的数据视图的概念还可以帮助一类人在论坛询问的数据验证问题. 开箱即用, 有是没有办法阻止用户将文件上载到苔藓，然后不输入元数据. 我们可以指定一个特定站点列是强制性的和不应允许用户保存按钮. 不过, 如果用户上传，然后关闭浏览器 (或使用 windows 资源管理器将该文档上载), 我们不能强迫用户输入的元数据 (再次, 开箱即用).
这种方法可以用于帮助这种状况. 我们可以用"差已标记的数据" 查看来轻松地识别这些文档并改正. 这夫妇与 KPI，你有良好的能见度对-向下钻取来管理这些特殊情况下的数据.
</结束>
MSDN 搜索论坛, 人们经常问这样的问题:
"我有一份名为 ' 编程指南’ 但当我搜索临’ 搜索没有找到它。"
它可能不喜欢它, 但这等于是通配符搜索. 苔藓/WSS 用户界面不支持通配符搜索开箱即用.
如果你挖进搜索 web 部件, 你会发现一个复选框, "启用搜索词词干". 词干是人类语言术语. 它不是一个计算机语言子字符串() 类型函数.
这些都是一些茎:
这些都不是茎:
WSS/苔藓搜索引擎不支持通配符搜索通过 API. 这里是一个描述如何做到这一点的博客文章: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2008/03/06/how-to-use-the-moss-enterprise-search-fulltextsqlquery-class.aspx
第三方产品, Ontolica, 提供通配符搜索. 我没有使用该产品.
</结束>
上个星期, 我就在想如何 循环并实现状态机 使用 SharePoint 设计器，并提到, 顺便提一句, 我大概会有关日志记录工作流更好写一篇博客文章.
井, 桑吉拉其普特抢先. 看看.
将日志数据保存到一个自定义列表中似乎比使用常规工作流历史记录:
有一些风险 / 不好的一面:
</结束>
这过去的一周我完了概念项目证明客户端在曼哈顿. 同时实施的解决方案, 我跑进了 MOSS Kpi 的另一个弊端 (在这里看到一个以前的 KPI 问题和我的解决方法).
背景: 用于设计器 SharePoint 工作流模型相当复杂多月长业务流程. 作为它突突地前进, 它将更新列表中的一些状态信息. Kpi 使用此数据来做他们的魔力.
我们决定要创建一个新的网站每次一个新的这些业务流程揭开序幕. 工作流本身的旁白, 这些网站主机几个文档库, 使用访问群体设定等等等等. 只是一堆的东西，帮助内部员工之间的协作, 出差旅行的员工和客户端参与商业伙伴.
我们还想要展示一些 Kpi，监视的整体健康状况这一特定的业务进程所提倡的工作流状态数据并使用 Kpi 查看.
最后, 我们用做对网站中的列表视图上计数的 KPI 列表项 (而不是从另一个数据源, 像 excel 或 SQL).
问题: 你可以想象, 假设我们都携带进入生产世界前进的基本思想, 我们想要的网站模板. 提供基于"业务流程的新网站" 模板.
问题是你似乎无法得到这种方式运作的 KPI. 在创建基于模板的 KPI 列表与 KPI web 部件的新网站时, 新网站 KPI 数据都破了. 无论源新网站 KPI 列表点你定义当你第一次保存它作为一个模板.
举个例子:
实例化过程不正确的 URL.
我试着解决这个问题通过指定相对 URL 定义 KPI 列表项时. 不过, 我不能任何变化的为了工作.
我总是想要配对这些"问题" 博客文章具有某种解决方案, 但在这种情况下，我没有一个好. 最好的我可以图是你需要转到新调配的站点和手动修复一切. 这种界面使得这更难的因为更改的源列表中的 URL 会导致刷新, 所以你真的要重新定义整件事从零开始.
如果有人知道更好的方法来处理这, 请张贴评论.
</结束>
这一周, 我有点纠结我的团队得到简单的两个服务器场中安装的苔藓. 经历了它, 我有问题的人报告的种类更好地了解 MSDN 论坛和其他地方.
最后服务器场配置:
我们开始项目之前, 我们让客户知道需要打开哪些端口. 在互谅互让, 来回以上，, 我们从来没有明确说了两个重要的事情:
第一天, 我们到场安装苔藓和学没已创建数据库和苔藓的域帐户. 搬东西, 我们走在前面，和安装一切与 intranet 服务器上的本地帐户.
在这一点, 我们发现混乱的 SSL 证书和, 可悲的是, 决定要我们基础设施的家伙回来之后的一个星期继续安装 DMZ 服务器. 在平均时间, 我们的解决方案建筑师向前处理业务的东西.
一个周末的流逝，客户端获取证书.
我们的基础设施的人出现，并发现 DMZ 服务器未加入到任何域 (有限的信任与外围域或内联网域). 我们浪费了近 1/2 在那一天. 如果我们没有让我们停滞不前的失踪 SSL 证书, 我们发现这早些时候. 哦好吧….
另一天通行证和各种安全委员会, 有关各方和 (不是这样) 无辜的旁观者都同意，确定以与内联网的域的 DMZ 服务器联接 (这是 POC, 毕竟, 不是生产解决方案).
基础设施的家伙来东西包起来. 这次我们成功地通过现代天挑战亲切地称为"SharePoint 配置向导。" 我们有聚醚醚酮在管理中心和 … 怡山楂! … DMZ 服务器列出服务器场中. 我们靠近一点看，实现我们破开香槟螨有点早. WSS 服务陷入"开始" 状态.
长话短, 原来，我们忘记了通过管理中心的服务帐户的身份从原始的本地帐户更改为新的域帐户. 我们那样做, 重新运行配置向导和瞧! 我们在业务.
</结束>
最近学会它是可能，甚至相当轻松地创建使用 SharePoint 设计器的状态机工作流. 必要性是发明和所有的好东西的母亲又寻找发明需要这个星期. 巧合的是, 我偶然 这个 MSDN 论坛帖子 以及. 我个人的经验这周和那"独立确认" 借给我的信念的力量. 我打算写关于这在更大的长度，一个完整的例子, 但这里是它的要点:
若要配置它:
每个状态工作流遵循这粗糙的模式:
除了显而易见的好处那一个可以创建声明性状态机工作流, 所有状态信息太棒了建立 Kpi 和有趣的意见.
它有一个相当大的缺点 — 标准的工作流程历史记录跟踪比正常情况下更加无用🙂很容易解决, 然而. 将您所有的审计类型信息存储在自定义列表. 这可能是一个好的主意，甚至为香草的顺序工作流, 但这是另一篇博客文章🙂
我称之为"过失" 因为我有, 不幸的是, 不止一次在论坛上表示，和其他地方那个必须使用 visual studio 创建状态机工作流. 那只是不是真的.
</结束>
虽然这不是字面上真的, 作为一个实际问题, 面向 internet 的 web 前端在 DMZ 中必须在域中 (e 小节. 一些不在自己小小的工作组中的独立服务器). 它并不需要在同一个域作为内部 WFE(s) 服务器和其他服务器 (也许不该), 但它必须是一个域.
我和我的同事花费大量的时间对一项提案，其中包括 SharePoint 的先决条件. 这包括将启用 DMZ 服务器等等加入农场的防火墙配置的全面列表. 不幸的是, 我们未能添加某个地方说的句子, 对影响, "这种配置的整个血腥点是允许您 DMZ WFE 服务器, 在一个域中, 要加入内部的农场。"
一场完美风暴的事件, 在我们基本上看左时我们可能看上去正确, 若要隐藏这个问题可以从我们直到相当晚在进程中串谋, 从而防止我援引我 "早告诉坏消息" 规则.
叹息.
Twitter 是一个非常奇怪的鸭子. 我一直使用 Twitter 为有点超过一个月，一些莫名的方式, 它是几乎一样重要对我的电子邮件. 我发现自己模模糊糊地不安稳了，如果我等得太久，再看其他人叽叽喳喳谈论. 我会在 Twitter 的偶尔的性能问题很恼火，因为这意味着我错过了. 我得到一小股的兴奋，当我看到一个新的 Woot 公告.
它是真的补充了博客、 论坛和甚至个人面对面会议的方式的真正的社区生成器.
上个月, 尝试管理 Seder 时摇晃感冒一人企图追随了。.
我学会了许多乡亲我主要是"知道有关个人详细信息" 通过博客 — 他们住在哪里, 这种他们工作的项目, 他们有一项工作 / 家庭问题，就像我一样管理.
一个人的母亲去世了 … 伤心的事件肯定. 但共享这一事实发生变化，提高了整体体验的字符.
这是只是个人的东西.
还有比这更. 它也是另一种介质为分享想法, 或者我认为更多, 寻求帮助. 把一个问题在 Twitter 和你永远不会留下挂和反应通常在几分钟内到达.
如果你还没有试, 你是应该放手一搏.
我抬头看 http://www.twitter.com/pagalvin
