微软中国 TechNet 团队博客

SCSM 数据仓库中的 OLAP 多维数据集：OLAP 多维数据集处理

微软中国TechNet — Wed, 22 May 2013 09:13:00 GMT

本文是详述数据仓库中 OLAP 多维数据集功能博文系列中的第五篇，OLAP 多维数据集是一项全新的功能，其可启用 SCSM 2012 中添加的自助报告功能。

OLAP 多维数据集处理

当系统部署完一个多维数据集，并创建了其所有分区后，则该多维数据集就已处于处理就绪状态，并可供用户浏览。处理多维数据集是在执行完 ETL 后的最后一个步骤。以下数据流图说明了整个过程：

图：说明源数据如何最终流入 OLAP 多维数据集的数据流图

当系统为多维数据集计算了所有聚合操作，且多维数据集加载了这些聚合和数据时，系统就将处理多维数据集。系统将读取维度表和事实数据表，计算该数据，并将该数据加载到多维数据集中。

由于处理过程可能对存在数百万条记录的生产环境形成重大影响，因此必须小心对待整个处理过程。处理此类环境中的所有分区可能随处发生，并有可能持续数天，甚至数周，因而导致最终用户无法使用系统和多维数据集。我们所提供的一项建议是针对当前未使用的任何多维数据集，禁用其处理计划，以降低系统的开销。

多维数据集的处理将被分解为两项独立的任务：

1) 维度处理

2) 分区处理

每个多维数据集将在 DW UI 中增加一个处理作业，并将根据用户配置的计划执行该作业。让我们一起来看一下如何处理每种类型的处理任务。

维度处理

当 AS DB 中被添加了一个新的维度时，系统必须在该维度上执行一项“Process Full MUST”处理，以将其调整为完全处理的状态。然而，在系统处理完一个维度后，系统并不能保证避免当处理针对相同维度的另一多维数据集时该维度会被再次处理。这是为了避免不必要的处理开销，我们希望避免重复处理每个多维数据集的每个维度，特别是在系统已经在最近处理过该维度的情况下，更是应避免重复处理，因为系统中不大可能存在尚未被处理过的新数据。为了优化处理效率，MP Microsoft.SystemCenter.Datawarehouse.OLAP.Base 中定义了一个名为 Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval 的单独类：

<ClassType ID="Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval" Accessibility="Public" Abstract="false" Base="AdminItem!System.AdminItem" Singleton="true">
<Property ID="IntervalInMinutes" Type="int" Required="true" DefaultValue="60"/>
</ClassType>

该单独类包含“IntervalInMinutes”属性，该属性描述了处理某一维度的频率，默认频率为每 60 分钟一次。例如，如果系统在下午 3:05 处理了一个维度，而且在下午 3:45 处理了针对相同维度的另一多维数据集，那么该维度将不会被重复处理。然而，这一方法有一个缺点，即其可能会增加维度键错误的可能性。系统实施了一个重试机制来处理将在实质上重新处理维度，然后进行多维数据集分区的维度键错误。有关更多信息，请参阅“调试与故障排除中的常见问题”章节中的“处理错误”部分。

当系统完整处理完一个维度后，系统将执行通过 ProcessUpdate 进行的增量处理。系统将执行 ProcessFull 的唯一其他时间是在某一维度架构发生更改时，这是因为这将导致维度返回到未处理的状态。用户需要注意，如果系统在某一维度上执行 ProcessFull，那么所有受影响的多维数据集（及其分区）随后将以未处理的状态存在，并需要在其下一次计划运行时进行完全处理。

分区处理

由于重复处理较大分区的速度较慢，并将消耗 AS 计算机中的大量 CPU 资源，因此必须小心对待整个分区处理过程。一般来说，分区处理所耗时间将长于维度处理过程。与维度处理不同的是处理分区对其他对象没有任何副作用。SCSM 2012 多维数据集上仅将执行两类处理，即 ProcessFull 和 ProcessAdd。

与维度类似，创建任何一个新分区都需要一个 ProcessFull，以使分区处于可查询状态。

由于 ProcessFull 是一个耗费较多资源的操作，因此我们的理念是仅在必要时执行 ProcessFull（即创建分区，更新某一行时）。当我们知道系统添加了行，或没有更新任何行时，我们可执行 ProcessAdd。为了进行这一操作，我们将使用水印，并利用其它元数据。更具体来说，系统需要查询 etl.cubepartition 和 the etl.tablepartition 表以确定执行哪类处理。下面的图中显示了来自这些表中的一些示例数据：

图：来自 etl.TablePartition 表的示例数据，其中多维数据集水印使用了 InsertedBatchId 和 UpdatedBatchId 列

图：来自 etl.CubePartition 表的示例数据，其中包含 WatermarkBatchId

以下关系图说明了我们如何基于水印数据确定执行哪类处理：

请注意，我们将在执行 ProcessAdd 时限制通过水印进行查询的范围。例如，如果 InsertedBatchId 为 100，而 WatermarkBatchId 为 50，那么查询仅将从 InsertedBatchId 大于 50，小于 100 的数据集市中加载数据。

最后，应注意在当前阶段，我们并不支持通过 AS 或 BIDS 来手动处理多维数据集。使用非 SCSM 2012 提供的方法（UI 或 cmdlet）来处理多维数据集将不会更新水印表，因而有可能导致数据完整性问题。如果某用户已经在意外情况下手动重复处理了多维数据集，那么您可采用的解决方法是使用相同的方式手动停止处理多维数据集，由于分区将处于未处理的状态，因此当下一次 SCSM 处理该多维数据集时，系统将自动执行 ProcessFull。这将正确更新所有水印和元数据，因此任何可能发生的数据完整性问题都将得以解决。

SCSM 数据仓库中的 OLAP 多维数据集：故障排除

微软中国TechNet — Tue, 21 May 2013 03:37:00 GMT

本文是详述数据仓库中 OLAP 多维数据集功能博文系列中的第七篇，OLAP 多维数据集是一项全新的功能，其可启用 SCSM 2012 中添加的自助报告功能。

调试与故障排除中的常见问题

处理失败：

尽管 DWRepository 中存在保护功能以确保数据的完整性，但这并不能完全排除发生处理错误的可能性。最常见的处理错误是 DimensionKeyNotFound 异常。由于默认情况下系统将每 60 分钟处理一次 AS 维度（该频率为用户可配置的值），因此在处理事实的度量值组的过程中，维度键有可能尚不存在。在这一情况下，默认的处理逻辑将通过 ProcessUpdate 重新处理 AS 维度，然后最多处理两次重新该事实，以解决键错误。

在一些罕见的应用场景中，重复处理操作可能失败。导致这一失败的原因有两个：

只有 DW 库将强制执行外键以确保数据的完整性。数据集市中并没有任何出于性能考虑的外键。由于加载批量处理将数据通过 ADO 从库移动到集市，因此事实数据有可能因为计时问题而在维度键之前已经被加载。为了解决这一应用场景中的问题，加载过程必须在后续时间中执行，以引出现有维度键。
在多集市的应用场景中，每个集市中的所有维度都将指向主 DW 数据集市。这是为了减少多维数据集的尺寸和处理时间。然而，OM 或 CM 集市中的事实有可能以尚不存在于主 DW 数据集市中的维度键为目标。在这一情况下，尽管这与您的直觉相反，但是您必须在主集市中实际运行加载作业，以解决指向 OM 或 CM 集市的多维数据集的处理失败。

排除多维数据集中 MDX 自定义的故障

由于很多多维数据集的自定义需要运用到 MDX 的使用知识，因此用户经常将在初始表达式中遇到语法错误，而且需要进行多次尝试才能编写出符合用户需求的表达式。我们建议通过 BIDS 或 SSAS 来测试 MDX 表达式（且不保存更改），然后再尝试将其通过 CubeExtension 添加到多维数据集，或在 SystemCenterCube 元素中定义该表达式。

但是，如果用户在将 MDX 表达式通过 CubeExtension 包含于 MP 中时在 MDX 表达式中遇到了错误，那么他们可卸载多维数据集扩展来还原对多维数据集进行的更改。如果这些表达式是通过 SystemCenterCube 元素定义，那么很遗憾，用户必须得卸载 MP，然后将多维数据集手动从分析服务中删除，然后才能进行修正和重新部署多维数据集 MP。基于这一原因，我们可以建议用户通过 CubeExtension 元素来定义多维数据集的自定义项。

多维数据集 MP 部署失败或更改/更新未显示于多维数据集中：

多维数据集 MP 部署失败的处理与替代 2010 DW MP 的当前系统十分相似。用户可始终通过重新尝试部署来查看造成这一问题的根本原因是否为连接失败或数据访问服务的临时中断（重试即可成功）等临时问题。由于我们允许诸如自定义 MDX 脚本（该脚本无法在导入时间内验证语法的正确性）等某些多维数据集的自定义行为，因此有人预计这将会是造成部署失败的一个常见原因。在这一应用场景中，用户可卸载，然后重新安装包含正确的 MDX 脚本的 MP。跟往常一样，您可在数据仓库或部署源下的事件日志中找到有关失败的更多信息。

所有多维数据集的部署更改都属于原子事务，因此在更改任何 AS 组件（数据源、DSV、维度、多维数据集）的过程中所遇到的任何错误都可回滚��有进行的更改，以确保系统始终处于一致的状态。换句话说，对数据库所进行的更改要么“全部”生效，要么“全不”生效。

请记住现在尚没有方法能够防止用户对多维数据集本身进行手动更改。当发生这一情况时，由于多维数据集的结构可能被破坏，因此我们无法保证多维数据集的完整性，或无法保证其自动维护能够成功进行。如果用户决定手动操作某一多维数据集，那么最好卸载所有相关的多维数据集 MP。卸载一个多维数据集 MP 将“永远不会”将多维数据集从 AS 删除，但是存储于 CMDB 中的多维数据集元数据将被删除，因此系统将不会再自动处理或分区该多维数据集。但用户仍可从 DW 工作区查看该多维数据集，并打开 Excel 来浏览该多维数据集。

按维度筛选不能切片或分割多维数据集：

让我们看一个用户浏览度量值组“分配给用户的工作项”的应用场景，他希望分割某一特定部门中的所有用户。然而，当他试图执行对 UserDim 的筛选操作时，系统未运行任何内容或返回任何数据。由于用户知道 UserDim 与该特定度量值组有关系，因此这让用户感到十分疑惑。

在这一应用场景中，我们必须记住相同的数据库维度可在多维模型中扮演多个角色。我们将这些维度称为“角色扮演维度”。例如，时间维度可在描述航班信息的多维数据集中使用多次。这一情形中的不同角色扮演维度可以是“离港时间”和“达到时间”，二者均以时间维度为目标。

在“分配给用户的工作项”示例中，用户维度给定的角色扮演名称实际上是“AssignedToUser”。如果用户根据该特定维度而非“UserDim”筛选，那么系统将为他们返回正确的信息。

BIDS 拥有一个极其有用的功能，名为“维度使用选项卡”，该功能可显示维度与多维数据集之间的关系，因此用户能够确定他们可使用哪些维度来切片和分割多维数据集。下图进一步解释了“分配给用户的工作项”示例，您可看到“UserDim”与“WorkItemAssignedToUser”度量值组之间没有任何关系，而 UserDim (AssignedToUser) 与度量值组有关系，其中联接属性为 UserDimKey。在这一示例中，角色扮演名称已在括号内突出显示。

图：WorkItemAssignedToUser 度量值组的维度使用视图

此时，SCSM 并不存在本机维度使用选项卡功能，因此最终用户需要查看 BIDS 来精确确定应在特定的多维数据集上筛选哪些维度。

远程分析服务服务器上的多维数据集的处理故障

在某些情况下，远程 AS 服务器上的多维数据集处理将由于防火墙未正确配置而失败。AS 的默认实例将使用 TCP/IP 端口 2383，用户应在防火墙中解除阻止该端口以允许访问。

要解除阻止该端口，请运行以下命令行指令：

C:\Windows\system32>set port=2383
C:\Windows\system32>netsh advfirewall firewall add rule name="Analysis Services" protocol=TCP dir=in localport=2383 action=allow

处理被挂起

导致处理被挂起的原因有很多。当 DW 和 AS 服务器位于同一计算机时，系统管理员必须确保系统拥有足够的 RAM，且计算机中有足够的内存来并行运行 DW ETL 和多维数据集处理作业。我们在下方提供了一些可能的解决方案：

1) 2008 AS 服务器中有一些已知的死锁问题。该情况下的解决方法是在处理挂起操作之前提高处理线程池中的线程数量。如果系统已经挂起，那么解决方法是重启 System Center Management 服务和 AS 服务，并将多维数据集处理工作项重设为状态 3（未启动），从而工作流引擎可重新启动它。

要获得相关的多维数据集处理工作项，您可在 DWStagingAndConfig 中运行以下查询（为向用户说明，以下逐条显示了这些查询，您可轻松将这些查询结合成一条查询）

select processId from infra.process where processname like ‘Process.{CubeName}’

select batchid from infra.batch where processId = {ProcessId from previous query}

select * from infra.workitem(nolock) where BatchId = {BatchId from previous query}

update infra.workitem set statusid = 3 where workitemId = {workitemId from previous query)

2) 查看 AS 服务上的 CoordinatorExecutionMode 属性，并确保其设置正确。以下论坛线程突出显示了一些已知的问题：http://social.msdn.microsoft.com/Forums/zh-CN/sqlanalysisservices/thread/78feaf33-a64d-49e6-a04a-3058d5e58f42

DWMaintenance 在 ManageCubePartitions/ManageCubeTranslations 步骤中被挂起

在这一应用场景中，最常见的原因还是 AS 服务器未响应。解决方法与上述挂起操作处理（步骤 1）的方法一样，即重启 System Center Management 服务和 AS 服务，然后将工作项重设为状态 3（未启动），之后其即可重新运行。

要获得相关的 DW 维护工作项，您可在 DWStagingAndConfig 中运行以下查询（为向用户说明，以下逐条显示了这些查询，您可轻松将这些查询结合成一条查询）

select processid from infra.process where processname = 'DWMaintenance'

select * from infra.ProcessModule where ProcessId = {ProcessId from previous query} (Note the ProcessModuleId where the VertexName is ManageCubePartitions/ManageCubeTranslaions)

Select * from infra.batch where ProcessId = {ProcessId from previous query} (Note the BatchId from the largest batch)

select * from infra.WorkItem where BatchId = {BatchId from previous query}

update infra.workitem set statusid = 3 where workitemId = {workitemId for the step that is hung with the corresponding processmoduleid for ManageCubePartitions/ManageCubeTranslations)

SCSM 数据仓库中的 OLAP 多维数据集：在管理包中为 OLAP 多维数据集建模

微软中国TechNet — Mon, 20 May 2013 10:05:00 GMT

本文是详述数据仓库中 OLAP 多维数据集功能博文系列中的第三篇，OLAP 多维数据集是一项全新的功能，其可启用 SCSM 2012 中添加的自助报告功能。

在管理包中为 OLAP 多维数据集建模

为了为 SCSM 2012 中引入的新的多维数据集 MP 元素建模，用户应利用定义自定义 MP 元素的功能。这些 MP 元素可让用户以声明的方式在一个更高的抽象级别上定义和自定义一个 OLAP 多维数据集。基于该定义，这些 MP 元素的部署将在一个更高的详细粒度级别上创建多维数据集的正确关系、组件和基础构建块，而无需进一步的用户指导。OLAP 多维数据集中引入了两大主要 MP 元素：

SystemCenterCube
CubeExtension

SystemCenterCube

SystemCenterCube 元素根据用户的特定需要在多个详细层级上定义 OLAP 多维数据集。该元素包含以下子元素：

MeasureGroups
替换
CustomMDX
NamedCalculations
度量值
KPI
操作（目前仅支持钻取操作）
ManyToManyRelationships

MeasureGroupss:

每个多维数据集都包含一个存在于数据集市中的事实集合，该集合中的每个成员都对应一个度量值组。每个度量值组必须具有其在多维数据集中自有的唯一名称，但是某个单一的事实可能对应一个多维数据集中的多个度量值组。例如，抽象关系“WorkItemAssignedToUser”可能将在一个多维数据集中被定义三次，每次都有唯一的度量值组名称“ChangeRequestAssignedToUser”、“IncidentAssignedToUser”和“ProblemAssignedToUser”。正如我们将在“替换”部分所看到的，用户可自定义事实，因此多维数据集的各个度量值组中仅包含更改请求、事件和问题。

以下示例阐释了针对 IncidentAssignedToUser 度量值组的 MP 元素。

<MeasureGroup DateDimAlias="IncidentAssignedToUserDateDim" MeasureGroupName-"IncidentAssignedTouser" Fact="DWBase!WorkItemAssignedToUserFact"/>

当多维数据集被部署后，维度、子维度和外键关系将自动计算，DSV 将使用这些新元素进行更新。

属性	是否必需	值	定义
DateDimAlias	否	字符串	将在此度量值组筛选的日期维度的角色扮演名称。如果未定义别名，那么日期维度角色扮演名称将自动为“(MeasureGroupName)_DateDim”
MeasureGroupName	是	字符串	多维数据集中的度量值组的名称。该名称必须在多维数据集中是唯一的。
Fact	是	Relationship 或 CustomFact	度量值组的目标，必须是数据仓库中的一个事实。

替换：

由于数据仓库中的关系事实可能以抽象关系和维度为目标，因此存在让用户替换具体维度的需求，从而度量值组将只包含用户希望浏览的特定实例。

以下示例说明了这一点：

在本示例中，“IncidentAssignedToUser”度量值组指向“WorkitemAssignedToUser”关系。然而，该关系将不仅包含事件，还将包含被分配到任何用户的更改请求和问题。为了确保该度量值组只包含事件，我们将使用“IncidentDim”替换“WorkItemDim”。这在实质上意味着在 DSV 中为该度量值组创建的表将自动执行一个将 WorkItemDim 与 IncidentDim 内联的操作，并基于 EntityDimKey 或 BaseManagedEntityId 仅返回联接有效的实例。

请注意，用户必须定义关系端点，用户将希望在这些端点上执行替换操作。由于源��度和端点维度有可能是相同的，而且我们需要一种方法来唯一识别应替换的维度，因此我们需要这一元素。“WorkItemRelates to WorkItem”便是该关系的一个示例。

替换元素也将用于定义多维数据集的角色扮演维度。换句话说，用户可定义某一维度的角色扮演名称，但不需要实际替换一个维度。实际上，这一情形中的替换操作并非面向维度进行，而是针对多维数据集维度或角色扮演维度名称。以下显示了一个示例：

在此示例中，角色扮演多维数据集维度名为“AssignedToUserDim”。这是将用于实际筛选该多维数据集的维度的名称。通过让用户定义角色扮演的名称，名称可经特殊定制，以在能够获得更高级的筛选和分析功能的多维数据集中启用需要的多对多关系。

最后，替换不仅对关系事实有效，对于自定义事实同样有效。在本应用场景中，关系端点将被设置为“无”。

属性	是否必需	值	定义
MeasureGroupName	是	字符串	用于执行替换的度量值组的名称
RelationshipEndPoint	是	(Target, Source, None)	执行替换的关系的端点。默认情况下，（针对自定义事实的）值为 None
Relationship	否	ManagementPackRelationship	用于替换的关系。
AliasTargetDimensionAs	否	字符串	原始目标维度的角色扮演名称
AliasReplacementDimensionsAs	否	字符串	替换维度的角色扮演名称
DimensionAlias	否	ManagementPackDimension	来自自定义事实的维度别名（如存在）

自定义的 MDX：

自定义的 MDX（多维度表达式）脚本可让用户根据具体规范修改和定制多维数据集，以满足其具体需求。由于 SCSM 多维数据集是基于模型的，因此其无法在为某一特定用户的域特定业务需求而考虑大量要求和准确规范时，确定用户所有可能的语义需求。自定义的 MDX 可让用户定义 MDX 脚本，该脚本将在多维数据集顶部应用，以突出它们需要度量值和检测的特定应用场景。

命名计算：

命名的计算允许用户在某一自定义度量值稍后可采用的维度上定义新属性。这可让最终用户在实质上扩展维度架构，并自定义架构以满足其具体需求。让我们看一个 SystemCenterWorkItemsCube 中的示例。

<NamedCalculation ID="IncidentsPastTargetResolutionTime" Target="IncidentDW!IncidentDim" ColumnType="Int">
<Calculation>(case when ( (([Status] = 'IncidentStatusEnum.Resolved' OR [Status] = 'IncidentStatusEnum.Closed') AND ResolvedDate > TargetResolutionTime) OR (([Status] != 'IncidentStatusEnum.Resolved' AND [Status] != 'IncidentStatusEnum.Closed') AND GETUTCDATE() > TargetResolutionTime)) then 1 else 0 end )</Calculation>
</NamedCalculation>

在本示例中，事件维度包含诸如事件状态和目标解析时间等数据。然而，该维度中不存在计算未达到目标解析时间的事件数量的本机度量值。该数据对于系统管理员十分有用。我们可使用命名计算来枚举所需的应用场景，并聚合数据，从而自定义的度量值可以定位新属性，并向最终用户呈现此信息。

请注意，此时的 NamedCalculation 支持仅针对维度。当前将不存在针对事实的支持。

属性	是否必需	值	定义
ID	是	字符串	命名计算的名称。
Target	是	ManagementPackDimension	度量值的目标维度
ColumnType	是	(Int, Double)	列的 SQL 类型
Type	否	(Count, Sum)	度量值的类型

子元素 <Calculation> 包含命名计算的定义，并将其作为 MDX 表达式的值。

度量值：

自定义的度量值可让用户基于维度的数值属性聚合并显示数据。此时尚不存在基于事实的针对自定义的度量值的支持。继续上述来自命名计算的示例，我们定义了一个关于 IncidentsPastTargetResolutionTime 的自定义的度量值：

<Measure ID="IncidentsPastTargetResolutionTimeCount" Target="IncidentDW!IncidentDim" Type="Sum" Property="IncidentsPastTargetResolutionTime"/>

查看上述 xml，该度量值的目标是 IncidentDimension，特定属性为“IncidentsPastTargetResolutionTime”。这是一个在上述命名计算中定义的自定义属性。自定义的度量值可能将针对度量值中的本机属性或计算属性。

最后，度量值类型将被定义为一个求和。一个度量值类型的可能值包括求和与计数。此时，出于对性能的考虑，用户尚不可使用非重复计数度量值类型。

属性	是否必需	值	定义
ID	是	字符串	度量值的名称
Target	是	ManagementPackDimension	度量值的目标维度
Property	是	字符串	已设定目标的维度属性
Type	否	(Count, Sum)	度量值的类型

ManyToManyRelationship：

ManyToManyRelationship 可让多维数据集设计人员向多维数据集添加自定义的多对多维度，以启用高级的分析应用场景。定义多对多的关系已经超出了本篇博文的范围，但是我强烈建议用户阅读并理解这一相对较新的概念，及其诸多优势。以下链接所含信息十分有用，其向初级用户介绍了这些概念：多对多解析

在多维数据集的部署过程中，我们将自动为“单一跃点”关系的多维数据集添加多对多的维度，而无需任何用户指导。然而，我们并未向级联（多跃点）关系添加多对多维度，这是因为可能被添加的关系将提高指数。由于聚合多对多的关系通常不会在处理期间计数，而且系统将在浏览多维数据集时评估联接，因此添加所有这些关系将在浏览多维数据集时对性能产生重大影响。如果用户希望获得特定的级联多对多关系，那么他们可使用该 MP 元素来定义一个此类关系，该关系将被相应地添加到多维数据集中。相反地，他们可覆盖一个自动生成的多对多关系来在存在多个中间组的位置使用不同的中间度量值组（在这些情况中，我们将自动选用首个遇到的组）。以下列出了一个多对多关系 MP 元素的示例：

<ManyToManyRelationship CubeDimension="ServiceDim" TargetMeasureGroup="AlertAboutConfigItem" IntermediateMeasureGroup="ServiceContainsConfigItem" />

属性	是否必需	值	定义
CubeDimension	是	字符串	多对多的多维数据集维度的名称
TargetMeasureGroup	是	字符串	创建多对多关系的目标度量值组
IntermediateMeasureGroup	是	字符串	创建多对多关系的中间度量值组

KPI：

关键绩效指标 (KPI) 可让企业通过衡量针对预定目标的完成进度而迅速评估企业的运行状况。每个 KPI ��有一个目标值和实际值。目标值是一个对于组织成功至关重要的定量目标。大量数据经过筛选后基本上都是一个离散值，这一离散值可用于监视针对目标和基准的性能和进度。举一个 KPI 的例子，某个学院的目标是其 90% 的学生将在 4 年内毕业，或者说一个篮球队的目标是让对方在某场比赛中的投篮命中率低于 50%。记分卡可用于显示一组 KPI，提供整个企业运行状况的一个瞬时快照。以下显示了一个示例：

<KPI ID="IncidentResolutiuonKpi" >
<Caption> The ratio of incidents resolved </Caption>
<Value>IIF(([Measures].[IncidentDimCount])> 0,([Measures].[IncidentsResolvedCount]/[Measures].[IncidentDimCount]),null)</Value>
<Goal>1.0</Goal>
<GreenThreshold> 0.75</GreenThreshold>
<YellowThreshold>0.5 </YellowThreshold>
<Direction>Up</Direction>
<StatusGraphic>Thermometer</StatusGraphic>
</KPI>

属性	是否必需	值	定义
ID	是	字符串	KPI 的名称
Caption	是	字符串	KPI 的描述
Value	是	字符串	定义 KPI 数值的 MDX 脚本
Goal	是	字符串	KPI 的目标值
GreenThreshold	是	字符串（介于 0.1 和 1 之间）	在本阈值以上或以下的任何数字（取决于方向）将在状态图中标记为绿色。
YellowThreshold	是	字符串（介于 0.1 和 1 之间）	在本阈值以上或以下，但又未达到绿色阈值的任何数字（取决于方向）将被标记为黄色。未达到黄色阈值的数字将在状态图中被标记为红色。
Direction	是	(Up, Down)	如果方向朝上，那么绿色或黄色阈值以上的任何数字将按照该颜色代码标记。方向朝下的情形与朝上时类似，绿色或黄色阈值以下的数字将按照该颜色代码标记。
StatusGraphic	是	（形状、交通灯、路标、测量仪表、反向测量仪表、温度计、柱形、朝向、变形箭头）	将代表 KPI 的图形。

下面显示了一个测量仪表状态图的示例，其描述了已按时完成的更改请求的百分比：

图：显示了按时完成的更改请求的测量 KPI 状态图

操作：

操作是用户在访问多维数据集内的数据时能够在 OLAP 多维数据集上触发的事件。对于 SCSM 2012 而言，目前仅支持钻取操作。以下显示了一个示例：

属性	是否必需	值	定义
ID	是	字符串	钻取操作的名称
MeasureGroupName	是	字符串	操作的目标度量值组
ActionType	是	(DrillThrough)	操作类型（SCSM 2012 中仅支持钻取）
CubeDimension	是	字符串	多维数据集维度是操作的目标（必须是度量值组中的一个切片程序）
PropertyName	是	字符串	执行钻取操作时所显示的维度的属性

CubeExtension：

CubeExtension 元素的主要目的是让用户在将多维数据集部署到分析服务后修改多维数据集，而无需卸载和重新安装多维数据集。在多维数据集处理多年数据的应用场景中，由于重新创建多维数据集需要完整地重新处理所有分区，因此这将是一项需要耗费大量资源的操作。

CubeExtension 元素可定义以下元素：

NamedCalculation
ManyToManyRelationship
KPI
度量值
操作
CustomMdx

请注意，每个在 CubeExtension 中定义的自定义项还可在 SystemCenterCube 对象中定义。唯一不允许在该对象中定义的自定义项是向多维数据集添加事实/度量值组以及替换。

SCSM 数据仓库中的 OLAP 多维数据集：主要概念

微软中国TechNet — Fri, 17 May 2013 03:29:00 GMT

本文是详细介绍数据仓库中的 OLAP 多维数据集功能系列博文的第二篇博文，OLAP 多维数据集是实现 SCSM 2012 中新增自助报表功能的一项新功能。

体系结构概述

在下图中，SQL Server Business Intelligence Development Studio (BIDS) 的屏幕截图描绘了 OLAP 多维数据集所需的主要组件。这些组件是数据源、数据源视图、多维数据集和维度。

图：BIDS 分析服务的 DWANalysisData DB 视图

数据源：

数据源是 OLAP 多维数据集中包含的所有数据的来源。OLAP 多维数据集将连接到数据源以读取和处理原始数据，从而执行相关度量值的聚合和计算。所有 SCSM 多维数据集的数据源均为 SCSM 数据市场，其中包括针对 Operations Manager 和 Configuration Manager 的数据市场。有关数据源的身份验证信息必须存储在 Analysis Services 中，才能建立正确的权限级别。

数据源视图：

数据源视图 (DSV) 是表示数据源（例如 SCSM 数据市场）的维度、事实和支架维度表的视图集合。DSV 将包含主键和外键等数据表之间的所有关系。换句话说，DSV 将指定 Analysis Services DB 如何映射到关系架构，并在关系数据库上提供一个抽象层。利用这个抽象层，可以定义事实和维度数据表之间的关系，即使数据源关系数据库中不存在任何数据表。在 DSV 中也可以定义 DW 维度架构中原本不存在的指定的计算、自定义度量值和新属性。例如，如果事件的状态为已解决或已关闭，则为“Incidents Resolved”定义布尔值的指定计算将该值计算为“正确”。现在，我们可以使用指定的计算定义一个度量值，以便显示已解决事件的百分比、已解决事件的总数和未解决事件的总数等有用信息。

指定计算的另一个简单示例是“ReleasesImplementedOnSchedule”，它提供对实际结束日期小于或等于计划结束日期的发布数量记录的快速健康状态检查。

多维数据集：

上面的 OLAP 多维数据集简介部分中提供了 OLAP 多维数据集的定义。

维度：

Analysis Services 中的维度引用 SCSM DW 的维度。在 SCSM 中，维度大体上与 ManagementPackClass 类似。每个 MP 类具有一个属性列表，而每个维度包含一个特性列表，并且每个特性映射到类中的一个属性。维度允许筛选、分组和标记数据。例如，您可以按照已安装的操作系统来筛选计算机，以及按性别或年龄将人员分入各个类别。然后，可以按照数据被自然地细分为这些层次结构和类别的格式呈现数据，以便进行更深入的分析。维度也可以包含自然的层次结构，以便使用户能够“深化”至更多的详细粒度级别。例如，日期维度具有“年度 → 季度 → 月份 → 星期 → 日期”层次结构。

下图中提供了包含日期、地区和产品维度的多维数据集的示意图：

图：包含日期、地区和产品维度的多维数据集

例如，Microsoft 可能需要 Xbox 360 游戏控制台 2010 年销售情况的快速、高级摘要。他们可以进一步深化，以获取更具针对性的时间框架内的销售数字。业务分析师可能希望考核推出全新控制台设计和无 Kinect 控制器游戏体验对 Xbox 360 销售的影响。这有助于他们确定出现何种销售趋势，以及需要对业务战略进行哪些潜在的修正。通过按照日期维度进行筛选，可以迅速提供和利用这方面的信息。由于维度在设计方面可以使客户轻松地筛选和分组属性和数据，因此只能对数据进行这种切片和切块。

在 SCSM 2012 中，所有多维数据集将共享一组共同的维度。所有维度均使用主 DW 数据市场作为数据源，甚至在多市场应用场景中也同样如此。在多市场应用场景中，这可能导致在处理多维数据集时出现维度键错误。请参阅下面有关处理的故障排除部分，了解如何解决这一问题的更多详细信息。

多维数据集的分解

此部分将定义界定 Analysis Services 中实际多维数据集对象的元素：

度量值组

度量值组是与 DW 术语中的事实完全相同的概念。正如 DW 中的事实包含数字度量值一样，度量值组包含多维数据集的度量值。多维数据集中源自数据源视图中的单一事实数据表的所有度量值，也可以被视为一个度量值组。但是，存在这样一种情形，即多维数据集中的度量值源自多个事实数据表。相同粒度的度量值统一为一个度量值组。度量值组定义哪些数据将被载入系统、如何加载数据，以及如何将数据绑定到多维度多维数据集。

每个度量值组还包含一组分区，这些分区在单独的非重叠部分中保留实际数据。度量值组还包含聚合设计，它定义为每个度量值组计算的预汇总的数据集，以便提高用户查询的性能。

度量值

度量值是用户希望切片、切块、聚合和分析的数字值；这是用户不希望在数据仓库基础结构上构建多维数据集的其中一个根本原因。通过使用 Analysis Services，用户可以构建应用业务规则和计算来格式化和显示可自定义格式的度量值的多维数据集。多维数据集的许多开发时间花费在将显示哪些度量值和如何计算度量值方面。

度量值通常是映射到 DW 事实数据表中的数字列的值，但也可以在维度和退化维度属性上创建度量值。这些度量值是所分析的多维数据集的最重要的值，而且主要对浏览多维数据集的最终用户具有意义。DW 中存在的一个现有度量值的示例是 ActivityTotalTimeMeasure。ActivityTotalTimeMeasure 是 ActivityStatusDurationFact 中表示每项活动处于特定状态的时间的度量值。度量值的粒度由引用的所有维度组成。例如，关系事实“ComputerHostsOperatingSystem”的粒度包括计算机和操作系统维度。

根据度量值计算聚合函数，以便进一步进行数据分析。最常见的聚合函数是 Sum。例如，常见的多维数据集查询是对处于“进行中”状态的所有活动的总时间进行求和。其他常见的聚合函数包括 Min、Max 和 Count。

处理多维数据集中的原始数据之后，用户可以使用多维表达式 (MDX) 来定义自己的度量值表达式或已计算的成员，从而执行更复杂的计算和查询。MDX 是查询和访问存储在 OLAP 系统中数据的行业标准，因为 SQL 并非针对使用受多维数据库支持的数据模型而设计。

深化

当用户深化多维数据集中的数据时，他们在不同的摘要级别分析数据。数据粒度随用户深化而改变，基本上在层次结构中的不同级别检查数据。随着用户进一步深化，它们从摘要信息移至具有更窄重点的数据。

下面是一些示例：

1) 深化数据以了解美国的人口统计信息，然后了解华盛顿州、西雅图大都市区、雷德蒙德市的人口统计信息，最后了解 Microsoft 的人口统计信息。

2) Zune 便携式媒体播放器 2010 年度的销售数字，接着是该年度第四季度、十二月份、圣诞节前一周的销售数字，最后是平安夜的销售数字。（另请参见上述的 Microsoft Xbox 360 示例。）

下图说明了将六月份 Jaguar 的销售数据深化至每一天的销售信息。

图：深化数据以了解六月份 Jaguar 销售详情的示例

钻取

当用户“钻取”数据时，他们希望了解构成多维数据集聚合数据的所有单个事务。换句话说，用户可以在最低的粒度级别检索数据，获取指定的度量值。例如，当指定特定月份和产品类别的销售数据时，可以钻取该数据，以查看数据单元格中包含的每个数据表行的列表。

术语“深化”和“钻取”非常容易混淆。主要区别在于深化是针对多维数据集中预定义的数据层次结构（美国 → 华盛顿 → 西雅图）的操作，而钻取直接进入最低的数据粒度，从聚合在单个单元格的数据源检索一组行。

关键绩效指标

KPI 使企业能够通过衡量实现预定义目标的进度而衡量企业及其绩效的健康状况。KPI 是为了监测实现特定目的和目标的进度而定义的业务指标。KPI 通常具有目标和实际值，它表示对组织的成功至关重要的量化目标。KPI 通常显示在记分卡上，该记分卡包含一组 KPI，以便在一个快照中表明业务的总体健康状况。

KPI 的一个示例是在 48 小时内完成所有更改请求。KPI 可用于衡量在该时间范围内解决更改请求的百分比。SM 仪表板以视觉方式表示 KPI。在下图中，在 48 小时内完成所有更改请求的 KPI 目标值是 75%。

分区

分区是在一个度量值组中保留其中一些数据或全部数据的一种数据结构。每个度量值组分为多个分区，定义载入度量值组的事实数据的子集。Analysis Services 标准版仅允许每个度量值组一个分区，而企业版允许一个度量值组包含多个分区。分区是一种对最终用户透明的功能，但它主要影响多维数据集的性能和可扩展性。度量值组的所有分区始终存在于相同的物理 DB 中。

分区使管理员能够更好地管理多维数据集和提高多维数据集的性能。例如，您可以删除或重新处理度量值组的一个分区中的数据，而且不影响其余的度量值组。在将新数据载入事实数据表时，只有包含新数据的分区受到影响。

分区还可以提高对多维数据集的处理和查询性能。Analysis Services 可以并行处理多个分区，从而更有效地使用服务器的 CPU 和内存资源。在运行查询时，Analysis Services 还将从多个分区提取、处理和聚合数据。仅扫描包含与查询相关数据的分区，从而减少了所需的总体 IO 数量。

分区策略的一个示例是将每个月的事实数据表置入每月的分区。在每月结束时，所有新数据将进入新的分区，这将导致自然分发具有非重叠值的数据。

聚合

多维数据集中的聚合是预汇总的数据集，它们与具有 GROUP BY 子句的 SQL SELECT 语句类似。Analysis Services 可以在回答查询时使用这些聚合，以减少所需的计算量，从而迅速地向用户返回结果。多维数据集中内置的聚合可以减少 Analysis Services 在查询时间必须执行的聚合数量。构建正确的聚合可以提高查询性能，而且在多维数据集的整个生存期，常常随着查询和使用情况的变化而不断发展。

通常创建对大多数多维数据集的查询非常有用的一组基本的聚合。为度量值组中多维数据集的每个分区构建聚合。构建聚合之后，预汇总数据集中包括特定的维度属性。然后，用户在浏览多维数据集时，可以根据这些聚合快速查询数据。聚合必须认真加以设计，因为潜在聚合的数量非常大，构建所有聚合会占用极不合理的时间量和存储空间。

SCSM DW 团队在构建和设计 SCSM OLAP 多维数据集中的聚合时可以利用两个选项：

1) 设置“性能提升达到”选项

2) 基于使用情况的优化

性能提升达到选项

“性能提升达到”选项定义构建聚合的百分比。例如，将此选项设为默认值并采用 30% 的推荐值，意味着构建的聚合可以使多维数据集的估计性能提升 30%。请注意，这并不意味着将构建 30% 的可能聚合。

基于使用情况的优化

基于使用情况的优化允许 Analysis Services 记录数据请求，从而在运行查询时，将信息馈入聚合设计流程。然后，Analysis Services 将审核数据，并建议应构建哪些聚合，以便提供最佳的估计性能提升。

—— Danny H Chen

粒度警报的自定义 APM 规则

微软中国TechNet — Thu, 16 May 2013 10:28:00 GMT

八月份，Michael 撰写了一篇有关使用警报的博文。该博文的其中一个关键要点是 – 对于每个应用程序和每个应用程序组件 – 我们有四项警报规则，这些规则可以从 APM 模板打开或关闭。下面是引用的原文：

警报规则

对于我们提醒的每种类型的事件都有一项规则：性能、连接性、安全性和应用程序故障。当在被监控的应用程序中检测到这些类型的事件时，我们发出单独的警报。由于单个性能事件或异常事件并不意味着应用程序不健康，因此，这些警报并不影响被监控的应用程序的健康状况。

以上博文是在测试版期间撰写，UI 在此之后已经有所改进，但这些规则仍然存在，并且按照与描述相同的方法发挥作用。

在预发布版本中，模板 UI 中的选项如下所示：

虽然创作指南描述了选项的使用目标，但在这里，我想向大家更多地介绍一些促进“深入了解”的设置。

顶部有两个打开和关闭以下选项的复选框：

提醒“性能”事件（“打开性能事件警报”）
提醒“异��”事件（“打开异常事件警报”）－当启用此复选框时，允许您配置另外三个选项（异常类型细分）：
- 安全警报
- 连接警报
- 应用程序故障警报

总之，这些复选框的作用是启用和禁用前面提到的警报规则。您可以在“操作控制台”的“创作”窗格中的“规则”下找到这些规则：

规则名称应完全一目了解，以便理解哪项规则与哪个选项相对应。

虽然这种机制足够灵活，适合最常见的使用情形，但我想向大家介绍一下完整的端到端工作机制，并说明该解决方案如何强大和灵活，以及如何进一步利用 APM 配置超出 UI 所允许的更多的粒度警报－同时只需少量的 XML 编辑。

如果注意一下这些规则（在“操作控制台”中，或者通过开启 MP 并查看其 XML），它们都非常相似：它们具有查找入站 APM 事件的“数据源”，以及将这些事件转变为警报的“写入操作”。

数据源具有如下所示的配置：

正如在上面的屏幕截图中可以看到的那样，相同的数据源用于所有四项规则，而“AspectType”用于区分不同的性能、连接性、安全性和应用程序故障事件。

这非常适合大多数情形，而且我们选择默认设置的假设前提是操作人员会对性能、连接性和安全性事件更感兴趣－这些是他们能够操作的事件－但不一定与“应用程序故障”事件有关，因为这些事件（往往）是由于代码中存在缺陷，而且（通常）只有开发人员才能修复这些异常。

即使这一模型相当不错，但我发现，在某些情况下，人们可能希望定义更精细的警报规则。特别是，我认为我们的 APM 默认配置中已经非常充分地定义了连接性和安全性事件，而且这些事件通常无关痛痒，除非真的发生错误。对于性能事件和应用程序故障，这一点并不一定总是正确的。例如，您可能希望收到：

仅针对特定网页或方法的性能事件警报（这也可以通过定义一项事务来实现，但具体取决于选择了哪种首选方法－我将在以后的博文中说明这些事务）
针对所有情形的性能事件警报，但不包括“众所周知”访问缓慢而又无法修复/优化的特定页面/方法（这属于甚至无法通过一项事务而得以实现的情况）
仅针对特定类型的异常而非其他异常类型的应用程序故障事件警报
针对所有异常的应用程序故障事件警报，但不包括已知会引发未处理的异常、但不会导致不良用户体验或无法修复的特定页面
针对所有异常的应用程序故障事件警报，但不包括开发人员无法修复的特定异常类型
- 第 5 项所指的一种特定情况是，当某人调用 ASP.NET 应用程序上不存在的页面时，导致引发“System.Web.HttpException”并显示 HTTP 404 错误（未找到页面）代码 – 这是 ASP.NET 中的一项设计：如果调用一个 .aspx 页面，ASP.NET 引擎将尝试检索该页面并引发 HTTP 错误；当爬网程序或漏洞评估工具访问站点，并搜索“众所周知”但并不存在的页面时，这会导致许多问题（实际上我们在 microsoft.com 网站的生产部署监控部分观察到这种情况）

对于所有这些情形（以及更多情形），存在一种相当简单的解决方案：通过添加表达式筛选器编写新的 APM 警报规则。我们基本上将获得类似下面的工作流程：

下面粘贴的是一项样本规则：它看起来与之前描述的“默认”APM 警报规则非常相似（而且事实上源自该规则）– 仅仅添加了高亮显示的条件检测。这一项规则代表以上列表的第 5 项示例－从根本上来说，它应筛选出那些“页面不存在”的 404 错误，但仍然对每个其他异常发出警报。

<Rule ID="Apm.AlertAppFailureAspectRule.Exclude404.message.Sample" Enabled="false" ConfirmDelivery="true" Target="APM!Microsoft.SystemCenter.Apm.ApplicationInstance" Remotable="false"> <Category>Alert</Category> <DataSources> <DataSource ID="LOBProvider" TypeID="APM!Microsoft.SystemCenter.Apm.LobDataProvider"> <Name>$Target/Property[Type="APM!Microsoft.SystemCenter.Apm.ApplicationInstanceBase"]/ApplicationName$</Name> <AspectType>applicationfailure</AspectType> </DataSource> </DataSources> <ConditionDetection ID="FilterExceptionClass" TypeID="System!System.ExpressionFilter"> <Expression> <Not> <Expression> <And> <Expression> <SimpleExpression> <ValueExpression> <XPathQuery Type="String">EventData/exceptionclass</XPathQuery> </ValueExpression> <Operator>Equal</Operator> <ValueExpression> <Value Type="String">System.Web.HttpException</Value> </ValueExpression> </SimpleExpression> </Expression> <Expression> <RegExExpression> <ValueExpression> <XPathQuery Type="String">EventData/message</XPathQuery> </ValueExpression> <Operator>ContainsSubstring</Operator> <Pattern>does not exist</Pattern> </RegExExpression> </Expression> </And> </Expression> </Not> </Expression> </ConditionDetection> <WriteActions> <WriteAction ID="AlertWriteAction" TypeID="Health!System.Health.GenerateAlert"> <Priority>1</Priority> <Severity>1</Severity> <AlertMessageId>$MPElement[Name='Apm.AlertAppFailureAspectRule.Exclude404.message.Sample.AlertMessage']$</AlertMessageId> <AlertParameters> <AlertParameter1>$Target/Property[Type="APM!Microsoft.SystemCenter.Apm.ApplicationInstanceBase"]/ApplicationName$</AlertParameter1> <AlertParameter2>$Target/Host/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</AlertParameter2> <AlertParameter3>$Data/EventData/exceptionclass$</AlertParameter3> <AlertParameter4>$Data/EventData/message$</AlertParameter4> <AlertParameter5>$Data/EventData/name$</AlertParameter5> <AlertParameter6>$Data/EventData/ViewDetail$</AlertParameter6> </AlertParameters> <Suppression> <SuppressionValue>$Data/EventData/eventConsolidationHash$</SuppressionValue> </Suppression> <Custom1>ApplicationFailure</Custom1> </WriteAction> </WriteActions> </Rule>

这项规则仍然对“外观”与内置规则非常相似的其他异常生成警报，但不会引发针对 HTTP 404 的“文件不存在”错误的警报。应注意的是，上面的示例对 .NET Framework/Windows 本地化版本不起作用，因为我搜索的是错误消息中的英文字符串 (“does not exist”)。这并不真的意味着生产质量 MP 考虑了所有情形，它只是作为您如何能够通过添加筛选条件构建自己的工作流程的简单示例，而且我的目标主要是帮助大家了解如何将 APM 组件在 Operations Manager 2012 中拼接在一起，从而凭借这方面的经验知识，可以变得具有创造性并令其适合您的需要。

总之，还有另外一种方法是挖掘实际的 HTTP 错误代码，该代码同样隐藏在 DataItem 中。为此，我们可以重新编写表达式筛选器，如下所示：

<ConditionDetection ID="FilterExceptionClass" TypeID="System!System.ExpressionFilter"> <Expression> <Not> <Expression> <And> <Expression> <SimpleExpression> <ValueExpression> <XPathQuery Type="String">EventData/exceptionclass</XPathQuery> </ValueExpression> <Operator>Equal</Operator> <ValueExpression> <Value Type="String">System.Web.HttpException</Value> </ValueExpression> </SimpleExpression> </Expression> <Expression> <SimpleExpression> <ValueExpression> <XPathQuery Type="String">EventData/log/events/event[1]/variable[1]/variables/variable[name='_httpCode']/value</XPathQuery> </ValueExpression> <Operator>Equal</Operator> <ValueExpression> <Value Type="String">404</Value> </ValueExpression> </SimpleExpression> </Expression> </And> </Expression> </Not> </Expression> </ConditionDetection>

由于博客布局的原因，上面的代码不便阅读（但应可以完整地复制/粘贴），因此我在本文的末尾附上了一个包含此规则的两种变体的管理包。它还包含另外两个（非常相似的）示例，共计三项规则针对“应用程序故障”事件，一项规则针对“性能”事件。默认情况下禁用所有规则，以防止在导入 MP 时，您的环境中出现重复警报－如果使用这些规则，可能需要首先禁用模板中针对“内置”规则的复选框。然后，您可以决定默认情况下打开这些新规则，或者选择性地覆盖这些规则，如同您对任何其他规则执行的操作那样。

另外请注意，条件检测筛选器中包含的一些条件无法从操作控制台进行编辑，而且通过 GUI 编辑的标记替换警报消息也很可能中断。这些内容最好是在 XML 中进行编辑。

此外，这些条件可能需要作为调试的一部分而经常调整－已知问题可能值得重新考虑，新问题可能会出现，而您需要开始筛选等等。

这些规则及其筛选器仅影响警报；数据库中仍然收集所有 APM 事件，而且可以通过 AppDiagnostics 控制台看到这些事件－因此实际的事件插入由不同的规则驱动（使用相同的数据源模块和不同的写入操作）。

AppDiagnostics 中存储事件并且可以看到这些事件之后，我们还提供各种方法以便从数据库中自动删除这些事件，或者将那些不认为有用或有趣，或可能增加问题的事件标记为“有意设计”(by design)。这是 AppDiagnostics（规则管理向导）中的一项问题管理功能 – 虽然它不能防止存储这些事件，或者第一时间引发警报 - 但有助于保持数据库“干净”，我喜欢将其视为一种“智能”整理。对于问题管理功能，要说的还有很多－在以后的博文中，我会尽量再次讲述这一功能及其规则。

.Net 监控，其乐无穷！

免责声明

本文按“原样”提供，不包含任何保证，而且不授予任何权利。使用文中包含的实用程序受 http://www.microsoft.com/info/copyright.htm 中指定的条款约束。

使用 Configuration Manager OSD 任务序列部署 Windows Server 2008 时，其他磁盘可能在任务序列完成时显示为脱机

微软中国TechNet — Wed, 15 May 2013 06:09:00 GMT

以下文章最初发布于 Configuration Manager 支持团队博客网站。然而我们最近发现文中所描述的方法仅在从“操作系统安装包”部署（从 Windows 安装源文件部署）时有效。基于这一原因，我们最近更新了本文，以向用户介绍在从“操作系统映像”部署时所应进行的操作。

此外，在需要复制和粘贴针对无人参与文件的 XML 代码的部分中也存在一些问题。首个问题是 XML 代码曾环绕显示于博文中，这使得用户无法正确复制和粘贴 XML 代码。第二个问题是如果系统已经使用了一个现有的无人参与文件，但是系统并不需要该 XML 代码中的所有行。因此这使系统难以确定需要 XML 代码中的哪些行，以及这些行应粘贴到何处。因此，我更改了使用 Windows 系统映像管理器 (WISM) 来创建/编辑无人参与文件的指令。使用 WISM 可以确保无人参与文件将被正确创建/编辑。

请查看下面的已更新博文。

在使用 Configuration Manager OSD 任务序列部署 Windows Server 2008 时，其他磁盘可能在任务序列完成时显示为脱机

症状

当使用 Configuration Manager 2007 OSD 任务序列来将 Windows Server 2008 或 Windows Server R2 部署到包含非本地磁盘（如 SAN 或 SAS 磁盘）的服务器时，其他任务可能无法在任务序列完成时恢复联机，并可能显示为脱机。特别是在磁盘管理中，其他磁盘可能显示为脱机，并显示如下消息：

Disk is offline due to a policy set by an administrator

原因

这一问题通常出现于 Windows Server 2008 和 Windows Server 2008 R2 的企业版和数据中心版中，但是也有可能出现于标准版中。在 Windows Server 2008 和 Windows Server 2008 R2 的企业版和数据中心版中，默认的 SAN 策略是将磁盘设置为脱机。请参阅以下内容了解更多信息：

您可能在将 Windows Server 2008 中的 SAN 磁盘通过 Diskpart 恢复联机时看到“媒体受写入保护”错误或 VDS 错误 80070013
http://support.microsoft.com/kb/971436/

VDS_SAN_POLICY 枚举
http://msdn.microsoft.com/zh-cn/library/bb525577(VS.85).aspx

配置 SAN 策略
http://technet.microsoft.com/zh-cn/library/dd799290(WS.10).aspx

SanPolicy
http://technet.microsoft.com/zh-cn/library/ff715663(WS.10).aspx

解决方法

要解决这一问题，对于 WinPE 阶段，需要将来自 KB971436 的步骤添加到任务序列中。此外，对于从“操作系统安装包”（Windows 源文件）部署的情形而言，需要将 SanPolicy TechNet 文章中所描述的组件和设置添加到 unattend.xml 文件中。对于从“操作系统映像”部署的情形而言，注册表项值需要更新为正确的 SAN 策略值。

WinPE

将 SAN 联机，并使其在 WinPE 中可读取/写入：

打开记事本
在记事本中复制以下行：
select disk <disk#>
online disk noerr
attribute disk clear readonly noerr
将 <disk#> 替换为 SAN/SAS 磁盘的磁盘号（不需要括号 <>）。noerr 选项被用于防止磁盘已经联机，且只读属性已经清除的情形中的错误消息。
使用以下名称保存该记事本文件
sanpolicy.txt
在 Configuration Manager 2007 管理控制台中，在“计算机管理” -->“软件分发”--> “软件包”节点下，创建一个包含在第 2 和 3 步中创建的 sanpolicy.txt 文件的软件包。无需为该软件包创建程序。在创建完软件包后，请确保将该软件包复制到分发点。
在 Configuration Manager 2007 管理控制台中，在“计算机管理”-->“操作系统部署”-->“任务序列”节点下，右键单击受影响的任务序列，并选择“属性”。
在完成“格式化和分区磁盘”任务后，添加一项“运行命令行”任务。
在新创建的“运行命令行”任务中：

勾选“软件包”选项，并单击“浏览...”按钮，然后选择在第 4 步创建的软件包。
在“名称：”框中，键入：
Set SAN Policy
在“命令行：”框中，输入
diskpart /s sanpolicy.txt

单击“应用”按钮，以保存任务序列。

完整 Windows 操作系统 - 操作系统安装包

如果是从“操作系统安装包”（Windows 安装源文件）部署，要更改完整 Windows 操作系统的默认 SAN 策略，则需要添加一个自定义的 unattend.xml 文件，以更改设置。如果自定义的 unattend.xml 文件已在使用，那么需要修改现有的自定义 unattend.xml 文件，以添加为完整 Windows 操作系统更改默认 SAN 策略的设置：

在 Configuration Manager 2007 管理控制台中，在“计算机管理”-->“操作系统部署”-->“任务序列”节点下，右键单击受影响的任务序列，并选择“属性”。
在“应用操作系统”任务中，通过查看是否选中“使用无人参与或 sysprep 应答文件进行自定义安装”选项，确定是否正在使用现有的无人参与文件。如果选中该选项，则确定软件包和无人参与文件的文件名。完成后，单击“取消”按钮。
打开含于 Windows 自动安装工具包 (WAIK) 中的 Windows 系统映像管理器 (WISM)。默认情况下，任何 ConfigMgr 站点服务器上都将安装 WAIK，而且用户可在“开始”菜单中的“Microsoft Windows AIK”菜单内找到 WAIK。
当 WISM 打开后，在“Windows 映像”窗格中，查看是否已经打开一个 Windows 映像。如果已有，则通过右键单击此窗格中的顶部节点，并选择“��闭 Windows 映像”来关闭该映像。
在“Windows 映像”窗格中，右键单击“选择一个 Windows 映像或目录文件”并选择“选择 Windows 映像...”。
在“选择一个 Windows 映像”文件打开框中，导航到存储 Windows 安装源文件的文件夹位置。进入 Windows 安装源文件的文件夹后，导航到“源”文件夹，选择安装的 Windows 版本相应的 .CLG 目录文件，然后单击“打开”按钮。
在“应答文件”窗格中，查看是否已有打开的无人参与文件。如果已有，则通过右键单击此窗格中的顶部节点，并选择“关闭应答文件”。
在“应答文件”窗格中，右键单击“创建或打开一个应答文件”。
从第 2 步开始，基于是否已有正在使用的无人参与文件，执行以下操作：

如果不存在正在使用的无人参与文件，则选择选项“新建应答文件...”，以创建一个新的应答文件。
如果已有一个正在使用的无人参与文件，则选择选项“打开应答文件...”，导航到第 2 步中软件包/文件名所确定的应答文件包源位置，然后单击“打开”按钮。

在“Windows 映像”窗格中，展开“组件”。
滚动并定位组件“amd64_Microsoft-Windows-PartitionManager”（x64 操作系统）或“x86_Microsoft-Windows-PartitionManager”（x86 操作系统），然后右键单击该组件，并选择“向 Pass 2 OfflineServing 添加设置”。
在“应答文件”中的“2 offlineServicing”节点下，请确保选中“amd64_Microsoft-Windows-PartitionManager”（x64 操作系统）或“x86_Microsoft-Windows-PartitionManager”（x86 操作系统）。
在“Microsoft-Windows-PartitionManager 属性”窗格中的“设置”部分下，将“SanPolicy”从 2 更改为 1。
在“文件”菜单下，选择“保存应答文件”。

对于现有的应答文件，应答文件将被自动保存。
对于新的应答文件，系统将打开“另存为”对话框，提示用户保存应答文件的位置。使用 unattend.xml 作为保存文件的名称，并将其保存到所需位置（即软件包源文件夹）。

当保存应答文件后，关闭 WISM。
如果第 9 步创建了新的无人参与文件，则跳至第 18 步。
如果第 9 步中使用了现有的无人参与文件，则在 Configuration Manager 管理控制台中更新包含从第 14 步获得的无人参与文件的软件包的分发点。当分发点更新后，无需进一步采取其他步骤，剩余步骤可跳过。
在 Configuration Manager 2007 管理控制台中，在“计算机管理” -->“软件分发 -->“软件包”节点下，创建一个包含在第 14 步中保存的 unattend.xml 文件的新软件包。无需为该软件包创建程序。在创建完软件包后，请确保将软件包复制到分发点。
在 Configuration Manager 2007 管理控制台中，在“计算机管理”-->“操作系统部署”-->“任务序列”节点下，右键单击受影响的任务序列，并选择“属性”。
在“应用操作系统”任务中，勾选“使用一个无人参与或 sysprep 应答文件进行自定义安装”选项。接着进入“软件包：”字段，单击“浏览...”按钮，并选择在第 18 步中创建的软件包。接着进入“文件名称：”字段，输入 unattend.xml
单击“应用”按钮，以保存任务序列。

完整 Windows 操作系统 - 操作系统映像

如果是从“操作系统映像”部署，那么无人参与文件无法被用于更改完整 Windows 操作系统的默认 SAN 策略。当使用 Configuration Manager OSD 任务序列从一个映像部署时，Windows 安装将始终不会在 WinPE 分区部署期间运行。因此，系统将始终不会处理传送 offlineServicing 的设置。由于 Microsoft-Windows-PartitionManager 组件和 SanPolicy 策略仅可被添加到 offlineServicing 传送设置，因此用户需使用一个非使用无人参与文件的方法。等效注册表项值可在操作系统映像被应用后修改，而无需通过无人参与文件更改 SanPolicy 设置。要在从映像部署时更改完整 Windows 操作系统的默认 SAN 策略，请遵循以下步骤：

在 Configuration Manager 2007 管理控制台中，在“计算机管理”-->“操作系统部署”-->“任务序列”节点下，右键单击受影响的任务序列，并选择“属性”。
在任务序列中，定位并选择“格式化和分区磁盘”任务，该任务将准备安装 Windows 操作系统的驱动器。
在“格式化和分区磁盘”任务中，在“卷：”部分中，双击 Windows 操作系统将安装到的卷。
在“分区属性”窗口中，如果“变量：”字段旁尚无变量名称，则输入：
OSDPART
如果该字段中已有一个变量名称，则记录下该变量，但不要替换它。
在“分区属性”窗口，单击“确定”按钮。
在任务序列中，定位并选择“应用操作系统映像”任务。
单击“添加”菜单，并选择“常规”-->“运行命令行”。这应该在“应用操作系统映像”任务后立即添加一个“运行命令行”任务。
在新创建的“运行命令行”任务中：

在“名称：”文本框中，输入：
Load System Hive
在“命令行：”文本框中，输入以下注册命令：
reg load HKU\temp "%OSPART%\Windows\System32\Config\System"
如果已经存在一个在第 4 步中输入的变量名称，则在上述命令行中将“OSPART”替换为来自第 4 步的变量名称。

在任务序列中，选择新创建的“加载系统配置单元”任务。
单击“添加”菜单，并选择“常规”-->“运行命令行”。这应该在“加载系统配置单元”任务后立即添加一个“运行命令行”任务。
在新创建的“运行命令行”任务中：

在“名称：”文本框中，输入：
Change default SAN policy
在“命令行：”文本框中，输入以下注册命令：
reg add HKU\temp\ControlSet001\HKLM\System\CurrentControlSet\Services\partmgr\Parameters /v SanPolicy /t REG_DWORD /d 1 /f

在任务序列中，选择新创建的“更改默认 SAN 策略”任务。
单击“添加”菜单，并选择“常规”-->“运行命令行”。这应该在“更改默认 SAN 策略”任务后立即添加一个“运行命令行”任务。
在新创建的“运行命令行”任务中：

在“名称：”文本框中，输入：
Unload System Hive
在“命令行：”文本框中，输入以下注册命令：
reg unload HKU\temp

单击“确定”或“应用”按钮来保存任务序列。

APM 对象模式

微软中国TechNet — Tue, 14 May 2013 08:48:00 GMT

自我们发表有关 APM in OpsMgr 2012 的一些全新信息之后已有一段时间。Michael 在八月份撰写了一篇有关使用警报的博文，在此之前，我们相继发表了数篇有关如何正确进行操作、APM 的工作原理和如何模拟用于测试的错误的博文。另外，Sergey 随后在九月份发表了有关 APM in OM12 安装更轻松、配置更简单、维护更廉价的博文，Adam 则在 11 月份（RC 发布之后不久）撰写了配置真的如同 1…2…3…那样简单的博文。

最近，我一直向 TAP 客户、执行内部测试的同事等许多人谈起一个有关理解方面的问题，即当您通过 APM 模板/向导运行时，模板实际上创建了哪些对�� －换句话说，我在向导中选择的选项如何影响监控应用程序的方法？设置 APM 监控之后，应用程序在 OpsMgr 中“看起来”会是什么样子？

为了彻底弄清楚这个问题，我们在 Technet for APM 上发表了大量的正式文档，以指导用户了解整个流程，并详细地描述各种设置和阈值。特别是，您应参考以下两个网址的内容：

创作指南中描述的 APM 模板的创作/配置体验 - http://technet.microsoft.com/zh-cn/library/hh457578.aspx
操作指南中的操作活动（使用应用程序警报等）– http://technet.microsoft.com/zh-cn/library/hh212856.aspx

总之，为了更清楚地了解对象模型实际上看起来是什么样子（对于奇客），我制作了下面的图表，大体上将向导元素映射到了模板创建的对象中：

正如大家可以看到的那样，通过运行向导创建的每个模板实例代表一个单独的应用程序－这称为“应用程序组”，而且是一个单一对象－这与分布式应用程序相似，尽管由于具有不同的基类而不显示在“分布式应用程序”视图中。

您可以通过右击应用，然后选择该对象对应的图表视图，从“受监控的应用程序”状态视图（显示通过 APM 模板配置的所有应用程序）访问上面的图表：

该模板还遵循相同的层次结构创建“文件夹”和“视图”：

因此，正如前面已经撰写的那样，“顶层”对象称为“应用程序组”，而且是一个单一对象－与分布式应用程序相似。它托管其他单一对象 –“应用程序组件”– 通常代表 SOA 应用程序的“层”。在当前的 (RC) 实施中，它们可以是 Web 应用程序或 Web 服务（IIS 中托管的 .asmx Web 服务和 WCF 服务），但以后可能出现更多的“类型”。某些组件（Web 应用程序）被视为适合客户端监控 – 某些组件并不适合，而仅适合服务器端监控，因为它们可能执行后台处理，或者提供与 HTML 网页相对的 XML 文件等等。为组件启用服务器端或客户端监控可以启用“第三”层 – 上面示意图中的绿色矩形 – 这些属于“组件角色”– 它们表示组件（“层”）是否托管 Web 应用程序、Web 服务、IIS 托管的 WCF 服务，以及是否已为客户端监控启用。您还可以在“应用程序组”的第一个状态视图中看到“应用程序组件”的细目，以及它们托管/监控哪些“组件角色”：

到目前为止描述的所有对象（上述示意图中深蓝色、红色和绿色矩形中的对象）均属于在管理服务器上创建的单一类 – 与其他单一对象一样，它们处于“所有管理服务器”资源库中。创建这些对象是为了区分可以在水平扩展的服务器场中的多个机器上运行同一组件的应用程序的“组”或“层”。

最后，图表中的第四层是代理上实际受监控的实例 – 这些对象是从 APM 服务收集数据并通过 OM 通道馈入数据的“工蜂”，正如我在本博客的第一篇博文中所描述。这些实例包含在上面的组件角色中，同时，它们由 APM 代理对象托管。

我们在上面显示的“per component”文件夹是您可以查看这些代理实例的状态和警报（受 Michael 以前描述的规则和监控驱动），以及收集的性能数据的地方：

这样，我们又从控制台中的高级配置到代理绕了整整一圈。平心而论，我在这里没有介绍在定义事务时涉及的另外一组对象。由于需要了解事务在 APM 术语中的含义，我可能会在单独的博文中谈及。现在，我希望本文有助于阐明 APM in OM12 的基本/公用对象是什么样子，并使您能够更清楚地了解您所看到的一切！

.NET 监控，其乐无穷！

Daniele Muscetta

排查从辅助站点到另一个林的 ConfigMgr Active Directory 发现失败的问题

微软中国TechNet — Mon, 13 May 2013 07:12:00 GMT

Hi, 我和章艳非常兴奋的同大家分享 2012 年 1月发布在微软 TechNet 英文博客上的 System Center 相关的原创文章。请注意，这些博客中的一些链接可能导向英文博客页面。如果您想观看这些英文博客的中文译文，您可以把感兴趣的文章添加到评论告诉我们。我们会非常重视大家的意见，想知道大家感兴趣的主题。同时，在文章内容的右边，我们提供了翻译控件，您可以选择相应的语言对本页内容进行翻译。希望这些文章能给大家带来帮助,谢谢！

大家好，我是 Tyler Franke，今天我将再次向您介绍另一条疑难解答提示。您在使用 System Center Configuration Manager 2007 管理控制台，并试图为更新列表下载软件更新时，有可能发生操作失败，并收到以如下消息开头的错误提示：

无法找到请求的标头

此外，如果您利用了 PatchDownloader.log，您将看到一条与以下内容类似的条目：

Downloading content for ContentID = 27377, FileName = windowsserver2003.windowsxp-kb2621440-x64-enu.exe. Software Updates Patch Downloader 3/22/2012 3:34:37 PM 1337928 (0x146A48)
HttpQueryInfo HTTP_QUERY_CONTENT_LENGTH failed 12150 Software Updates Patch Downloader 3/22/2012 3:34:37 PM 1335744 (0x1461C0)
Download http://download.windowsupdate.com/msdownload/update/software/secu/2012/02/windowsserver2003.windowsxp-kb2621440-x64-enu_337d75494557b29c69230ca182054ad65489847b.exe to C:\Users\SJSIMM~1\AppData\Local\Temp\2\CAB161.tmp returns 12150 Software Updates Patch Downloader 3/22/2012 3:34:37 PM 1335744 (0x1461C0)
ERROR: DownloadContentFiles() failed with hr=0x80072f76 Software Updates Patch Downloader 3/22/2012 3:34:37 PM 1337928 (0x146A48)

原因

一个内容筛选设备正在关闭会话。请注意，在以下 Netmon 框架中，连接是由 IPv4 地址为 192.168.1.100 的站点服务器启动，但是 IPv4 地址为 192.168.1.200 的设备将首先发送流量，以设法实际发送信号和启动下载。您将发现，我们需要将会话保持为连接状态（即 ProxyConnection:Keep-Alive），并将其作为由站点服务器启动的 HTTP 连接中的一部分，但是 IPv4 站点地址为 192.168.1.200 的设备将在实际上解构数据包，并关闭连接（即 ProxyConnection:close），从而消除站点服务器下载软件更新的可能。

用户应重点关注我在以下 Netmon 框架中加粗的项目/行，这些项目/行表示了关闭连接的筛选设备。

Frame: Number = 28900, Captured Frame Length = 361, MediaType = ETHERNET
- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[06-7A-8B-9C-10-11],SourceAddress:[00-1A-2B-3C-04-05]
- DestinationAddress: BROADCOM CORPORATION BCE088 [06-7A-8B-9C-10-11]
Rsv: (000000..)
UL: (......0.) Universally Administered Address
IG: (.......0) Individual address (unicast)
+ SourceAddress: Hewlett Packard D89A3B [00-1A-2B-3C-04-05]
EthernetType: Internet IP (IPv4), 2048(0x800)
- Ipv4: Src = 192.168.1.100, Dest = 192.168.1.200, Next Protocol = TCP, Packet ID = 17864, Total IP Length = 347
+ Versions: IPv4, Internet Protocol; Header Length = 20
+ DifferentiatedServicesField: DSCP: 0, ECN: 0
TotalLength: 347 (0x15B)
Identification: 17864 (0x45C8)
+ FragmentFlags: 16384 (0x4000)
TimeToLive: 128 (0x80)
NextProtocol: TCP, 6(0x6)
Checksum: 0 (0x0)
SourceAddress: 192.168.1.100
DestinationAddress: 192.168.1.200
- Tcp: Flags=...AP..., SrcPort=50355, DstPort=HTTP Alternate(8080), PayloadLen=307, Seq=1611337238 - 1611337545, Ack=2596688289, Win=16425 (scale factor 0x2) = 65700
SrcPort: 50355
DstPort: HTTP Alternate(8080)
SequenceNumber: 1611337238 (0x600B0E16)
AcknowledgementNumber: 2596688289 (0x9AC651A1)
+ DataOffset: 80 (0x50)
+ Flags: ...AP...
Window: 16425 (scale factor 0x2) = 65700
Checksum: 0x2251, Disregarded
UrgentPointer: 0 (0x0)
TCPPayload: SourcePort = 50355, DestinationPort = 8080
- Http: Request, GET http://download.windowsupdate.com/msdownload/update/software/secu/2012/02/windowsserver2003.windowsx
Command: GET
- URI: http://download.windowsupdate.com/msdownload/update/software/secu/2012/02/windowsserver2003.windowsxp-kb2621440-x64-enu_337d75494557b29c69230ca182054ad65489847b.exe
Location: http://download.windowsupdate.com/msdownload/update/software/secu/2012/02/windowsserver2003.windowsxp-kb2621440-x64-enu_337d75494557b29c69230ca182054ad65489847b.exe
ProtocolVersion: HTTP/1.1
Accept: */*
UserAgent: Download Progress
Host: download.windowsupdate.com
ProxyConnection: Keep-Alive
Pragma: no-cache
HeaderEnd: CRLF

Frame: Number = 28969, Captured Frame Length = 364, MediaType = ETHERNET
- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-1A-2B-3C-04-05],SourceAddress:[06-7A-8B-9C-10-11]
- DestinationAddress: Hewlett Packard D89A3B [00-1A-2B-3C-04-05]
Rsv: (000000..)
UL: (......0.) Universally Administered Address
IG: (.......0) Individual address (unicast)
+ SourceAddress: BROADCOM CORPORATION BCE088 [06-7A-8B-9C-10-11]
EthernetType: Internet IP (IPv4), 2048(0x800)
- Ipv4: Src = 192.168.1.200, Dest = 192.168.1.100, Next Protocol = TCP, Packet ID = 3683, Total IP Length = 350
+ Versions: IPv4, Internet Protocol; Header Length = 20
+ DifferentiatedServicesField: DSCP: 0, ECN: 0
TotalLength: 350 (0x15E)
Identification: 3683 (0xE63)
+ FragmentFlags: 16384 (0x4000)
TimeToLive: 64 (0x40)
NextProtocol: TCP, 6(0x6)
Checksum: 2612 (0xA34)
SourceAddress: 192.168.1.200
DestinationAddress: 192.168.1.100
- Tcp: Flags=...AP..., SrcPort=HTTP Alternate(8080), DstPort=50355, PayloadLen=310, Seq=2596688289 - 2596688599, Ack=1611337545, Win=54 (scale factor 0x7) = 6912
SrcPort: HTTP Alternate(8080)
DstPort: 50355
SequenceNumber: 2596688289 (0x9AC651A1)
AcknowledgementNumber: 1611337545 (0x600B0F49)
+ DataOffset: 80 (0x50)
+ Flags: ...AP...
Window: 54 (scale factor 0x7) = 6912
Checksum: 0xB4CF, Good
UrgentPointer: 0 (0x0)
TCPPayload: SourcePort = 8080, DestinationPort = 50355
- Http: Response, HTTP/1.1, Status: Ok, URL: http://download.windowsupdate.com/msdownload/update/software/secu/2012/02/windowsserver2003.windowsx
ProtocolVersion: HTTP/1.1
StatusCode: 200, Ok
Reason: OK
Date: Fri, 06 Apr 2012 18:56:46 GMT
Last-Modified: Wed, 22 Feb 2012 21:36:04 GMT
+ ContentType: application/octet-stream
ETag: "03a6bfaa9f1cc1:0"
Accept-Ranges: bytes
Server: Microsoft-IIS/7.5
XPoweredBy: ASP.NET
Age: 261162
ProxyConnection: close
Via: 1.1 localhost.localdomain
HeaderEnd: CRLF

注意: 在特定的情况中，该设备将是一个 Websense 内容筛选设备，但是可执行类似功能的任何设备都可引起同样的问题。

解决方法

要解决这一问题，您需要配置该内容筛选设备，以使其 Configuration Manager 站点服务器至少可访问以下 KB885819 中提及的一系列网站。

用户也需经常清除 Web 筛选设备的缓存，或在进行了必要的更改后清除 Web 筛选设备的缓存，以使站点服务器能够访问所需的 Web 地址。如果用户未能这样做，那么系统将保留缓存，从而无法成功建立连接。

允许的网站：

http://download.windowsupdate.com
http://*.download.windowsupdate.com
http://download.microsoft.com
https://*.update.microsoft.com
http://*.update.microsoft.com
https://update.microsoft.com
http://update.microsoft.com
http://*.windowsupdate.com
http://*.windowsupdate.microsoft.com
http://windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://ntservicepack.microsoft.com
http://wustat.windows.com

详细信息

885819 - 当您通过运行 ISA Server 的服务器来访问 Windows Update 版本 6 时，您将遇到问题。
（http://support.microsoft.com/default.aspx?scid=kb;ZH-CN;885819）

Tyler Franke | 高级支持升级工程师

在 Facebook 和 Twitter 上获取 System Center 的最新新闻：

Forefront Server Protection 博客：http://blogs.technet.com/b/fss/
Forefront Endpoint Security 博客：http://blogs.technet.com/b/clientsecurity/
Forefront Identity Manager 博客：http://blogs.msdn.com/b/ms-identity-support/
Forefront TMG 博客：http://blogs.technet.com/b/isablog/
Forefront UAG 博客：http://blogs.technet.com/b/edgeaccessblog/

微软启用全新中文技术博客网站，全面升级技术博文阅读体验

微软中国TechNet — Mon, 05 Nov 2012 01:00:00 GMT

为了更好的满足用户对微软中文技术内容日益增加的需求，微软中文技术博客网站http://blogs.technet.com/b/microsoft-china/，经过历时三个月的网站建设和历时一周的测试，终于正式启动了。网站将带给IT专家和开发人员丰富的博客博文和智能的导航系统，以帮助大家方便获取中文微软技术内容。

此次发布的微软中文技术博客网站是微软为中国技术博客阅读者量身订做的博客平台。网站收录了微软技术团队和专家的热门博客，其内容涵盖众多微软产品和技术，包括 Visual Studio、Microsoft Azure、System Center、Windows Server、Windows 8 等。

值得一提的是，微软中文技术博客网站采用了以解决方案为导向的导航系统，为用户提供6大主目录和21 个子目录的清晰分类。用户可以通过导航系统在站内轻松定位博客和博文，更可以便捷地完成目录之前的转换。不仅如此，在网站首页，用户还可以找到最新最热的微软中文技术博文、技术视频和活动信息等。

下面，就让我带大家一睹为快：

微软此次启动全新的中文技术博客网站旨在全面提升IT专家和开发人员对微软中文技术博客的阅读体验。今后，网站更将根据用户的需求和反馈，不断拓展内容、完善结构，成为IT专家和开发人员最有价值的微软技术信息平台。

现在，点击http://blogs.technet.com/b/microsoft-china/，开始亲身体验网站吧。

私有云成本效益及许可比较：Microsoft vs VMware

微软中国TechNet — Thu, 23 Aug 2012 08:48:00 GMT

随着越来越多的企业走向虚拟化，以及虚拟化比例越来越高，企业会逐渐走向云解决方案以达到最佳的投资回报率。目前客户使用 VMware 的比例约为 60%，Hyper-V 约为 25%。去年 VMware 因为 V-Tax 的问题引发客户不满，但随即 VMware 马上调宽许可模式以便缓解客户的不满。但我们可以看出，VMware 在掌握住整个虚拟化市场后，接着就是想尽办法调高许可费用，企业整体支出只会逐年增高，到了云服务呢? VMwware 更是昂贵并且费用高到匪夷所思的地步。接下来，我们来探讨当企业未来逐步向私有云的方向发展时，微软与 VMware 的整个 ROI 及许可的比较。

首先，我们先来比较一下微软私有云与 VMware 私有云解决方案的差别：

简单来说，企业只需要 Windows Server 2008 R2/2012 + System Center 即可构建企业私有云，但客户如果使用 VMware 解决方案，则需要结合非常多复杂且昂贵的产品才能实现私有云，其中包括 VMware Management Suites –vCOPS、vFabric、vCloud Director 等。这些都是额外附加的产品线，让整个 VMware 私有云解决方案变得非常复杂难懂。

我们再来看看要实现私有云，客户选择微软与选择 VMware 的价格差异：

首先，微软在 ECI 许可模式下没有 VM 数量的限制，平均每个 CPU 大约 5056 美元。

微软私有云许可和价格 - Datacenter

如果使用 VMware，可以看到以下两种许可模式，VMware 不但要额外增加许多模块，更重要的是，实现私有云后的计价模式将会以 VM 计价，所以当客户的 VM 越来越多时，VMware 的价格也成倍提高。
VMware 私有云许可和价格：w vCOPS Advanced

VMware 私有云许可和价格：w vCOPS E+

再以曲线图形式看一下，客户使用 vCOPS Enterprise Plus 时，可以看到随着每台主机服务器上 VM 密度的增加，VMware 的整体软件费用从一开始在密度为 6:1 时是微软的 5 倍，一直到当密度达 15:1 时近 10 倍的费用，而微软则是从头至尾都是固定费用，因为在 ECI Data Center 许可模式下，微软不会随 VM 数量增加而增加整体软件费用。

结论

在私有云下，微软与 VMware 在软件费用上的比较可以用下面图表表示：

当企业因为私有云及虚拟化效率提升时，也就是 ROI 提升时，同样的硬件将可以运行更多 VM。此时 VMware 软件费用随 VM 数量激增，而微软则是维持不变，因此使用 VMware 解决方案将使企业整体 ROI 大幅降低，选择微软 ECI 方案是企业提升 ROI 的最佳选择。