概述:

Windows SharePoint 服务开发自定义功能时，调试很难 3.0 (WSS) 或 Microsoft Office SharePoint 服务器 (苔藓). 罪魁祸首是 SharePoint 发生错误时，通常表面上的 web 浏览器的很少的诊断信息. 这篇博客介绍了如何查找其他系统生成的诊断信息，通常可以提供额外的细节，一个需要以确定根本原因. 这能导致解决问题.

我用这种技术取得了巨大成功解决否则为神秘的错误.

方法:

SharePoint 将大量的信息保存到一个诊断日志中的日志文件中 12 配置单元.

"12 蜂巢" 通常位于"C:\程序不数值 SharedWeb 服务器 Extensions12". (我不确定是不是可能的 12 蜂巢，别处过活, 事实上).

这个想法是要查找当前的日志文件, 强制错误，然后快速打开日志文件. 这些日志文件的特点是:

• 大量的信息. SharePoint 生成非常大量的诊断信息，并很快将它写入到该日志文件. 你需要用手指来捕捉它快速.
• 多重性. SharePoint 不向单个日志文件写入，但宁可在序列中生成多个日志文件.
• 复制并粘贴到 MS Excel 的很好.

我最喜欢的方法:

1. 打开 windows 资源管理器指向 12 hivelogs.
2. 视图显示按修改日期排序 (最新第一).
3. 突出显示最新的日志文件.
4. 在 web 浏览器窗口中, 强制出现错误.
5. 快速打开当前的日志文件并将其内容复制到 MS Excel.
6. 跳转到结束和分析有关条目.

其他说明:

默认情况下, 诊断日志位于 12 hiveLOGS 目录.

MS 的最佳做法 (根据麦克 T. 微软的) 应将日志文件保存到一个单独的硬盘的状态. 其中一个就是这样通过中央管理员. 您的系统管理员可能已经这样做, 在这种情况下你会明显地需要找到日志文件那里不是默认 12 配置单元位置).

此条目如解决问题:

• SharePoint 工作流启动失败，由于内部错误.
• (随着时间的推移添加更多)
• 此条目是有所帮助诊断工作流错误 (例如：. "工作流由于启动失败内部错误").

(此条目之间交叉张贴 http://paulgalvin.spaces.live.com/blog/ 和 http://blogs.conchango.com)

在本网站上的张贴是我自己并不一定代表 Conchango 的立场, 战略或意见.

概述:

此条目描述一个大一些背景信息 (3,000 用户) Microsoft Office SharePoint 服务器 (苔藓) 铺设和我们做了什么使计划得以推展方式客户端是快乐和坚定地走上的道路，以全面通过 MOSS 功能集的结束. 条目的写作, 我们大约是 50% 完成该项目的第一阶段. 随着事情的进展, 我会更新此条目和/或写入新条目.

在这个具体案例, 该公司已经安装 SharePoint 门户服务器 2003. IT 组安装中的"让我们看看是否谁会关心一种产品" 时尚. 它迅速通过了许多业务用户，并且成为了在大型企业中很受欢迎. 你可以想象, 这不是最好的产品推出战略 (其中客户端欣然承认) 和苔藓赶到现场的时候, 客户端解析"这样做的权利" 和雇佣我们去帮助他们.

当我们开始实施这一项目时我们所面临的中心问题之一是: 我们是如何向此客户端介绍 MOSS 的? 给出了客户端已经与 SharePoint 的经验, 我们想知道 — 我们需要做"差吗" 培训或做我们从地面开始了? 后与关键用户一起工作, 我们决定，将此视为更有意义的绿色的外地项目.

这一决定提供了一个起点，但仍然给我们留下的找出一个好的策略，为向企业推出苔藓主要要求. 青苔是这样大的动物 … 它包括内容管理, 文档管理, 搜索, 安全, 访问群体设定, 项目管理, "神话般四十一" 模板, 工作流, 业务数据连接器, 等. 这结合的事实，它是一个大的组织， 可以 真正使几乎每个主要的苔藓的使用功能和你有一个伟大项目与企业的覆盖范围和多好的事情发生的气质.

我们一次又一次面对这个问题 … 青苔已达到它的企业的功能集与企业, 然而甚至有点复杂客户端很难精神上吸收那些功能, 让独自一人将可观的分数，他们融入他们的日常生活.

我没有魔法解决问题. 我转而处理只是第一步，我们一直采取与客户他们沿着小路走向成功的长期通过.

范围:

就像我想要的团队来制定项目计划，其中包括这种里程碑作为"PoepleSoft 集成通过 BDC 已完成", "新跨部门产品启动工作流完成" 和"行政管理 KPI 接受", 只好用东西少. 这并不是说那"少" 是坏. 事实上, "越少" 我们决定为初始部署了他们在那里在我们开始之前遥遥领先. 在我们的例子, "越少" 变成了:

• 使用文档库的简单的文档管理, 版本控制和内容类型.
• 有效的搜索基于内容类型和自定义高级搜索 (通过托管属性, XSLT 来产生漂亮的结果, 等).

除了上述的企业级功能 (也就是说他们要向所有部门和用户推出), 我们添加了以下的单身人士范围内迷你-项目:

• BDC 一体化概念的证明.
• 通过 SPD 创建的多步骤、 多分支的工作流过程.
• 复杂的 InfoPath 表单.
• 堆焊 KPI 的一些业务流程 (可能在我们的案例来 HR 人才的获得, 虽然这有可能改变).

这里的范围并不是 100% 准确但代表我们的方法，足以达到我的目的, 这是为了解释我认为是一种"有效" 将设置客户端牢固地下来的金色的路径完全苔藓采用的苔藓的介绍.

我不会写更多关于单身人士在此条目. 我想指出，这些是我们首要的战略的一部分. 这样做是为了实现核心文档管理和搜索功能对所有用户尚未提供高度功能, 其他的核心莫斯特点，基本上是超越了大多数用户能够在这个早期阶段吸收高可见和极具代表性的例子. 不过, 他们将"在那里" 和一个希望其他业务单位会知道或了解他们，希望这些功能为自己的, 导致更大的通过. 这些单身人士的成功故事也有助于提供我们的销售团队"弹药" 为成功地赢得了第二, 第三次和 n 阶段项目.

我们介绍了什么和为什么?

在确定为文档管理和搜索作为比较基准的企业范围要求, 我们需要开始收集详细信息. 作为一个实际问题, 这被围绕着理解他们的文档和最终映射到理解的内容类型.

我发现很难解释无视觉助手的内容类型. 更多的技术民间可以走出浅谈内容类型时 CT 的介绍了在数据库术语中. "CT 是类似于数据库表, 它有的列和数据类型定义的列, 但 CT 的数据类型包括更多简单的整数/日期, 但也"选择" 和"查找" 及类似品。" 我们可以谈论"扩展" 内容类型, 就像一个可以功能类从基类继承在面向对象的语言. 然而这显然不利于运输部管理员有的人没有技术背景. 即, 几乎每个人的事情在苔藓推出.

使用白板是玄乎. 我所介绍的内容类型和绘制的辉煌的想法 (或者他们看起来如此) 内容类型和他们为你做什么的搜索和如何可以扩展他们的图片, 等. 在结束, 它感觉像一些灯泡已经打开了, 但由此产生的白板图片是一团糟.

这把我们带到我们当前，所以到目前为止最有效的着陆的地方: MOSS 沙盒站点配置为显示这些功能.

使用沙盒网站, 我们证明:

• 内容类型:
  • 使用多个数据类型创建一个 CT (文本, 日期, 选择, 布尔值, 查找, 等).
  • 通过创建一个新的 CT 基于父延长 CT.
  • 搜索文档使用 CT 元数据.
• 文档库:
  • 将一个单一的 CT 与库相关联.
  • 当我们向那图书馆上载文档时，会发生什么?
  • 将多个 CT 与文档库关联.
  • 当我们向那图书馆上载文档时，会发生什么?
  • 筛选和排序通过文档库中的列标题.
  • 文档库视图:
    • 排序
    • 分组
    • "快速进入" (数据工作表视图)
    • "未加标签的数据" (协助办理迁移到苔藓从其他内容源; 更多关于这下面).

沙盒网站:

我们设计我们的沙盒网站是一个永久的特点，在开发环境中，用于培训目的长后我们完成这项工程，包括几个工件所述:

内容类型:

我们定义以下内容类型: 发票, 采购订单, 服务发票.

我们所选发票和采购订单，因为他们是更多或更少普遍下
站在的实体. 在业务的每个人都明白，发票是支付给需求 客户 为 金额 以某一发布 日期 根据一些支付 付款条件. 这将导致一个自然的定义一个 ct，我们称之为"培训发票" (以区别于其他任何种类的发票). 同样轻松定义采购订单. 我们还创建了一个"培训服务发票" 通过创建一个新的 CT，基于"培训发票" CT 和添加一列, "提供服务".

与上述, 我们现在可以证明 CT 的一些关键特征而不陷入试图解释一个抽象的概念第一次; 每个人都已经明白我们所说的"发票" 和"采购订单" ，而能够集中在力学 CT 的本身.

自定义列表:

CT 与类型"查找的列" 指向自定义列表或文档库. 我们使用此广泛和为沙盒, 我们创建了一个支持自定义的列表，其中包含客户. 我们挑选客户，因为它是一个简单的概念需要理解和容易证明. 发票 CT 有一列, "客户" 这被定义的类型"查找" 这点在此列表中.

我们创建了一个类似的自定义列表来管理"供应商" "采购订单" CT.

文档库:

我们创建了两个文档库: "发票" 和"混合文档".

我们配置了发票文档库来管理唯一类型的文档的 CT"发票".

我们配置了"混合文档" 库来管理所有三个 CT.

创建显示排序的几点看法, 过滤, 数据工作表和分组.

搜索:

我们定义两个新的托管的属性，并将它们映射到发票编号和客户.

我们创建了一个新的自定义的预先搜索站点和修改，以使用户能够搜索"发票" 使用这两个映射的属性.

修改 XSLT 这样的发票和客户的数量, 当存在时, 显示在 HTML 表中明亮的颜色. 这里的目的是证明这种格式是可能.

放在一起:

我们安排为关键用户参与一个演示.

我们按照这个简单的脚本:

1. 描述的意义和目的的 CT, 使用发票和采购订单为例.
2. 显示发票 CT 定义时同时向他们保证他们不需要使用这些屏幕本身, 只是拿这两个概念.
3. 转到发票文档库.
4. 上传文档.
5. 显示下拉客户真的来自自定义列表.
6. 在客户列表中添加一个新的客户，然后使用新创建的客户更新最近上传的发票的元数据.
7. 切换到"混合文档" 图书馆和上载文档. 解释如何系统提示为文档类型.
8. 回过头去发票文档库和显示如何单击列名称更改排序顺序.
9. 显示列级过滤.
10. 显示展示多层次排序的不同视图, 筛选和分组.
11. 显示数据工作表视图.
12. 解释"未加标签的文档的目的" 视图.
13. 切换到自定义高级搜索.
14. 现在, 最近上传的文档应该有抓取和编制索引, 所以执行搜索的演示能力来定位该发票通过映射属性.
15. 我们演示通过映射的属性 vs 搜索之间的差异. 只是文本搜索.

在这一点, 我们或多或少都与演示. 它似乎采取关于 30 自 45 分钟, 根据多少问题人们问.

我们然后把他们送回办公桌前带"家庭作业". 这包括一个简单的 excel 电子表格在哪里我们问他们如何定义对我们来说他们认为他们需要在 CT 的, 在高一级 (只是名称及业务的目的) 以及列和数据类型的他们要将存储在列. 我们不要求他们在苔藓条款中定义的列数据类型, 但业务术语.

在摘要:

我们已经创建一个沙盒环境，我们可以用来演示其上诉是整个企业一些核心苔藓功能.

我们已经建模易于理解和共同的业务实体，以便用户可以专注于苔藓和不拘泥的实体 / 自己的例子.

业务用户走从"作业与论文会话" 他们现在主管填写，用于设计他们自己第一次剪切的内容类型的 excel 文件的形式.

最后, 因为随着时间的推移，我们执行的演示, 客户端的团队成员自己变得更能够发扬, 做演示的自己和一般释放了其余的我们来进行更复杂的问题, 如全球分类学, 复杂的工作流, BDC 和类似.