自动化 – MVP 聚焦系列 – SharePoint：DFS 共享创建请求演练（第 1 部分）
大家好 – 我们回来了！
以下是 MVP 自动化跟踪聚焦系列六篇文章中的第二篇…
–MVP 聚焦系列 –
SharePoint：DFS 共享创建请求演练（第 1 部分）
作者： Mike Roberts （ Ryan Andorfer 的同事）
使用 SharePoint 构建自助服务请求
本文并未明确侧重介绍自动化，而是重点说明对于衔接自动请求与需要执行自动请求的最终用户至关重要的相关主题。在本文中，我将会详细介绍如何构建自助服务请求门户，从而最终用户能够访问我们使用 Service Management Automation 自动创建的流程。
以下（彩色部分）是本文在整个示例解决方案体系结构中的位置：
在我们深入介绍实施的各个技术细节之前，需要仔细思考我们发布本文的目标和动机。本项目的主要目标是在无需 IT 人员直接干预的情况下，帮助用户解决自身面临的问题。解决此问题的简便方法是授予用户更高的权限和访问权限，使他们能够直接配置资源，如 Active Directory 组、DFS 文件共享和服务器。很显然，这可以实现某种短期的效益，但必将导致各种各样的技术和治理问题。关键在于寻求折中方案，自助服务门户允许我们为用户授权，但需要采用适当的控制手段才能做到，继而确保不会违反策略及导致系统不稳定。
要求
本着这项原则，我们针对实现技术制定了以下一系列要求：
- 输入框表单 - 此组件非常基础。自助服务门户必须为其用户提供方法，来提交将要通过后端自动化引擎处理的请求。由于该解决方案旨在供 IT 专业人员使用，Web 开发体验不一定包含创建表单。此外，还应提供各种输入控件以及用户输入验证方法。
- 安全性 - 自助服务门户必须根据 Active Directory 组成员资格，设法限制用户可以访问哪些请求。应当部署适当的控制手段，以确保无法规避各项请求的验证逻辑和业务流程。
- 通过 API 实现可访问性 - 必须设法“连接”自助服务门户与 SMA（我们的自动化引擎）。由于 SMA Runbook 均使用 PowerShell 工作流创作，因此重要的是要思考通过 PowerShell cmdlet 访问门户的 API 有多么容易。
- 人工工作流程- 该门户应用提供实施业务流程及应用于各请求流程的治理方法。通常，这意味着路由请求进行审批，然后再使用 SMA Runbook 进行处理。
- 良好的用户体验- 最后，重要的是保障最终用户的体验。如果系统使用起来过于混乱或困难，将不会得到广泛应用，用户将无法实现自动自助服务请求的价值。
我们根据上述标准对大量不同技术进行了评估，最终确定运用 SharePoint 技术作为我们的自助服务门户。我们的企业已经实施大规模 SharePoint 部署项目，因此业务用户熟悉并且习惯使用这项技术。SharePoint 可以使我们通过配置设计引人入胜的 Web 窗体，具有各种 API 用于从 PowerShell 访问数据，而且拥有强大的工作流自动化功能。
请求表单的创建
出于本文的需要，我将会以请求新 DFS 共享为例。此请求是说明 SharePoint 如何满足我们的请求的有效示例：其中包含各种需要执行验证和审批流程的输入，从而确保请求适当有效。以下是创建新 DFS 共享必须收集的信息：
字段 |
类型 |
描述 |
Department |
选项 |
顶级部门文件共享，将包含正在请求的新项目。 |
Share Name |
文本 |
要创建的文件共享名称。输入内容应严格限定于字母数字字符和短划线 (-) 符号。 |
Owner |
人员 |
具有完全控制权限的共享所有者。 |
Secure Share |
复选框 |
如果选中，则表明应严格限制访问文件共享。 |
Initial Members |
个人（多人） |
如果选中安全共享，将显示此字段，向应被授予共享访问权限的用户显示提示。 |
Status |
选项 |
此字段将跟踪独立请求的状态。Service Management Automation 中运行的脚本将查找 "Approved" 状态的请求以提取进行处理。有效选项包括：New、Approved、Rejected、In Progress 和 Complete。此字段将默认为 New，且应对请求者不可见。 |
首先，在我们的站点中创建一个新的 SharePoint 列表。单击页面右上角的齿轮以打开 Site Settings 菜单，然后选择 Add an app。
在下一屏幕中，选择 Custom List 应用程序。
选择新请求列表的名称，然后单击 Create 。
现在，SharePoint 会将您定向至 Site Contents 页面，您将会发现刚刚创建的列表以绿色标记突出显示并显示为 "New"。单击此图标以打开列表。
此时，我们的 SharePoint 列表非常基础。其中仅包含一个默认字段，名为 "Title"。我们希望添加字段以匹配我们之前查看的 DFS 共享创建的必要输入列表。为此，请单击功能区中的 List tab，然后单击 List Settings 按钮。
此屏幕允许您管理 SharePoint 列表。如果略微向下滚动，将可以查看当前列表列的列表，这些列均为新 SharePoint 列表中创建的默认设置。标题列无法删除，因此我们将进行重用。单击 Title 编辑该列，将名称更改为 "Share Name"。另外，您还可以添加描述，该描述将在输入控件旁边显示，从而为用户提供更多内容输入指导。
接下来，我们需要为其他输入字段创建列。单击 Create Column 按钮以转至创建对话框。在这里，您需要为新字段输入标题，选择其数据类型并进行配置。
在 SharePoint 列表上配置这些字段后，我们可以打开新的项目表单以查看我们所拥有的项目。
这是一个良好的开端，但显然还需要完成其他一些工作，而后才能向我们的用户进行呈现。
我们需要向 Share Name 字段添加验证，配置Initial Members 字段仅在选中Secure Share 框的情况下显示，然后从表单中删除 Status 字段，从而使用户无法创建除 "New" 状态以外的其他请求。
用户可通过在 SharePoint list 中配置字段来完成某种基本验证。但是，为了满足 UI 需求，我们将必须使用另外一种工具，称为 InfoPath。InfoPath 是一款富客户端应用程序，是 Microsoft Office 套件的一部分。用户无需具备 Web 开发技能，即可通过它自定义 SharePoint 表单及添加复杂的验证逻辑。
此时需要注意的是，微软计划在未来版本的SharePoint 中不再继续支持InfoPath。但是，在未来的数年中，微软将继续依据软件支持生命周期支持 InfoPath 和 SharePoint 2013。
要启动 InfoPath，请导航至 SharePoint list，单击功能区中的 List 选项卡，然后单击 Customize Form。
这将启动 InfoPath 客户端应用程序，并准备好 SharePoint 列表的输入框表单副本进行编辑。
我们的首项 UI 修改是删除 Status 字段。只需突出显示包含 Status 输入的表中的对应行，然后单击 delete。现在，用户无权更改除默认值 New 以外的任何值。您可以对显示在 Share Name 下的 Attachments 行执行相同的操作，因为我们无法在此列表上使用附件。
接下来，我们要将可在 Share Name 字段中输入的文本限定为字母数字字符和短划线 (-)。单击 Share Name 字段，以便进行聚焦。
接着，单击功能区中的 Manage Rules。
这将打开屏幕右侧的 Rules 窗格，从而允许我们为输入控件定义验证规则。从 New 下拉列表中选择 Validation。
现在，为您的验证规则输入名称，这样当违反此规则时，就会向用户显示屏幕提示。要定义该规则，请单击 "Condition:" 下的文本 None。
在弹出的 Condition 对话框中，更改中间的下拉列表以选择 matches pattern。这将允许我们定义 regular expression 以便与预期输入相匹配。选择 Custom Pattern，然后输入以下正则表达式：
[a-zA-z][a-zA-Z0-9\-]+
最后，需要确保仅在选中 Secure Share 框的情况下，提示用户选择 Share Members。为此，将光标移动到 Share Members 字段下，从功能区的 Input 菜单中插入 Section。
Section 只是一个容器控件，我们将用它来有条件地显示/隐藏整个表行。接下来，突出显示表中的 Share Members 行，通过按 Ctrl-X 进行剪切。
然后，将表行粘贴至 Section 控件内。现在，我们将创建一项规则，在未选中 Secure Share 的情况下，有条件地隐藏整个 Section 控件，从而确保突出显示 Section 控件。
为您的规则键入描述性名称，然后选中 Hide this control 复选框。单击 None 以定义隐藏控件的相应规则。
使用 Condition 对话框，仅在取消选中 Secure Share 或者将布尔值设置为 FALSE 的情况下隐藏 Section。完成所有相关修改后，将会获得完成后的输入框表单，从而使用户能够请求 DFS 共享。
保护请求表单安全
SharePoint 的一大优势在于，它可以为用户提供大量方式与列表和库中存储的数据进行交互。用户可以选择使用 Web 窗体中的数据、数据表视图，甚至使用各种 Web 服务调用。但是，这可能会使尝试限制用户可以执行的操作时变得更加复杂。为确保解决方案安全，我们需要确保满足以下需求：
· 用户仅可查看其自身请求。其他用户提交的请求可能包含不得公开的敏感信息。
· 用户无法修改 InfoPath 表单外的请求，也不得绕过验证。
· 用户无法访问未授权使用的请求。
我们将会做出以下配置更改，以确保强制执行这些限制。但是，依据“深度防御”原则，同时建议验证自动脚本内的所有输入。如果恶意用户试图绕过我们部署的控制措施，这将为我们提供双重保护。
我们满足解决的第一项需求是防止用户访问彼此的请求。这可以通过快速更改列表设置来完成。我们需要像从前一样导航至 List Settings 页面，以向列表中添加列。我们需要配置的选项均可在 "General Settings" 列左侧的 Advanced Settings 下找到。为限制用户仅可访问自身的列表项，我们将选择如下所示的选项，以防止他们查看或编辑其他用户的列表项。
我们已向 InfoPath 表单的输入字段中添加验证以防止用户提交有害或潜在恶意数据。但是，SharePoint 的灵活性可能会让您的工作变得十分困难。用户可以直接通过 SharePoint Web 服务提交列表项，来规避我们的输入验证。我们需要设法禁止。另外，还应在用户提交列表项后禁止编辑列表项，因为他们可以在运行审批工作流后进行更改。
为此，我们将创建一个新的权限级别。在 SharePoint 中，权限级别用于定义安全对象上可以为用户或组授予的一组权利。我们希望定义一组权利，允许用户提交新项目，但不能编辑或删除项目，也不能使用 SharePoint 的 Web 服务操作列表中的数据。我们首先从 Site Settings 菜单（页面右上角的齿轮）导航至 Site Settings。
从 Site Setting 导航至 Site Permissions 页面。
接着，单击 Site Permissions 页面功能区中的 Permission Levels 按钮。
要创建新的权限级别，我们可以启动一个现有级别，复制，然后做出必要修改。与我们的场景最匹配的选项是 Read，因此单击该项以打开权限级别。
接着，向下滚动至屏幕底部，然后单击 Copy Permission Level 。
为新的权限级别添加标题和描述。
接着，确保选中 Add Items 框以允许用户提交新项目。
同时，取消选中 Use Remote Interfaces 和 Use Client Integration Features 旁边的复选框，以从此权限级别中排除 Web 服务访问权限。
单击 Create 以提交表单，完成新权限级别的定义过程。由于我们已经定义希望用户具备的一组权限，我们需要为他们授予对请求列表的相应访问权限。为此，导航回 List Settings 页面，然后单击 Permissions for this list 。
默认情况下，SharePoint 中的所有列表均继承站点级别的权限。由于希望为列表分配一个独特的权限集，我们需要通过单击功能区中的 Stop Inheriting Permissions 按钮打破继承机制。
现在，我们可以为列表中的站点访问者设置权限，方法是选中 Self Service Portal Visitors 组旁边的框，然后单击功能区中的 Edit User Permissions 按钮。
选中 Submit Only 框为访问者授予访问权限以提交新项目，然后单击 Ok 。
这将完成我们的列表配置，以便用户安全提交请求。
希望本文充分展示了 SharePoint 的配置方法，以便用户能够提交 IT 服务自助服务请求。在本系列接下来的几篇博客文章中，我们将了解如何配置请求目录以组织和显示自助服务请求，以及如何使用 SharePoint 工作流自动执行审批流程。接着，我们将说明如何通过 Service Management Automation 自动发出请求，从而实现真正的自助 IT 服务。
现在我 (Charles) 要向大家提几点注意事项 …
请务必查阅Ryan 在 TechEd North America 2014 的发言。
DCIM-B363 通过 Microsoft System Center 2012 R2 发出自动服务请求[View:https://video.ch9.ms/ch9/cc3e/fa2912bb-4c34-4743-9f6e-a237a8e0cc3e/DCIM-B363_mid.mp4:0:0] 5 月 15 日（星期四）上午 8:30 – 上午 9:45，Hilton L2 Ballroom D 在本次会议中，我们介绍一家《财富》 500 强企业为提供自助服务请求支持而开发的全自动 IT 服务目录实际实施过程。此服务目录基于Microsoft SharePoint ，利用最新发布的Service Management Automation (SMA) 引擎。在本次会议期间，我们将仔细认识解决方案的设计模式，介绍SMA 与SharePoint 间的集成、从头开始构建新的服务产品，并分享我们在开展SMA 工作的过程中开发的一些最佳实践。哪个部分最有意义？您将有权访问我们创建的解决方案，因此当会议结束时，您将获得一项行之有效的解决方案，从而帮助您启动工作！ 演讲人： Ryan Andorfer 和 Mike Roberts TechEd NA 2014 站点链接（需要登录）： DCIM-B363 通过Microsoft System Center 2012 R2 发出自动服务请求 |
最后 – 有关 System Center、Windows Azure Pack、Windows Azure 等自动化功能的详细信息、提示/窍门和示例解决方案，请查阅 自动化跟踪（和 https://aka.ms/IntroToSMA）构建云系列的其他博客文章、 System Center Orchestrator 设计博客的优秀文章，当然还有 Ryan 的博客 https://opalis.wordpress.com！
敬请查阅！