【Troubleshooting Case】Exchange Server 组件状态应用排错？

vivion32

　　在Exchange 2013中，引入了“服务器组件状态”的概念。服务器组件状态从运行环境的角度提供对组成Exchange Server的组件的状态的精细控制。 日常排错时，常常会把Exchange 服务器可被放置成一种的维护模式时，不仅通过临时暂停集群中DAG节点，而且往往会通过Set-ServerComponentState 命令来修改服务器组件不活跃状态。问题原因可能某一个服务脱机，导致服务器组件异常。
　　另外一种情况 就是在做补丁CU升级，升级后，你把服务器回“在线”通过改变组件的状态恢复为“有效”。然而，在运行时的Get-ServerComponentState cmdlet时，您会注意到一个或多个组件仍然不活跃。那我们如何去解决呢..
　　在Exchange PowerShell中显示所有服务器组件的当前状态，
　　Get-ServerComponentState –Identity <ServerID> cmdlet:
　　
　　从图可以看到，包含许多组件，列出的服务器组件不会以1:1映射到服务器上运行的Exchange服务或进程。相反，它们提供了一个抽象层和显示“组件”，它们一起组成Exchange Server为其环境提供的接口。大多数组件具有类似“* Proxy”的名称。它们特定用于CAS角色，而其他组件（如“HubTransport”和“UMCallRouter”是邮箱服务器角色的一部分，“Monitoring”和“RecoveryActionsEnabled”是同时属于这两个角色）除了可以单独管理的单个组件之外，还有一个名为“ServerWideOffline”的组件，除了“Monitoring”和“RecoveryActionsEnabled”之外，用于一起管理所有组件的状态。为此“ServerWideOffline”将覆盖所有其他组件的各个设置。
　　通常，服务器组件处于两个状态之一：“活动”或“非活动”。第三个状态，称为“排除”，这个仅与组件“FrontendTransport”和“HubTransport”相关。每当组件的状态被改变时，它必须由“请求者”完成。例如，当您运行cmdlet Set-ServerComponentState时，参数-Requester是必需的：常见请求参数 HealthAPI 、Maintenance、Sidelined、Functional、Deployment
　　例:
　　“ServerWideOffline”已被两个不同的请求者设置为“非活动”，例如“功能”和“维护”：
　　
　　然后，使用两个请求者之一将“ServerWideOffline”设置为“活动”
　　因此，“ServerWideOffline”和所有相关组件仍保持在“非活动”状态：
　　
　　为了再次将其设置为“活动”，需要与第二请求者一起执行Set-ServerComponentState ... -State Active。
　　
　　显然，管理员很少有目的地配置这样的组合。然而，我们已经看到它们是由于在后台运行的进程和手动配置的结果而发生的
　　事实上，每当有人（或某事），使组件不活动，条目被添加到本地服务器在以下位置的注册表
　　HKLM\SOFTWARE\Microsoft\Exchange Server\v15\ServerComponentStates\<componentname>
　　
　　每个条目包括以下信息，由冒号分隔：[未知值]：[状态]：[时间戳]
　　
　　正如我们所看到的，组件有多个条目。如果其中一个条目会显示该组件是无效的，这将有效无效。即使最近的条目将该组件置于活动状态，它会到同一请求切换回主动保持无效。
　　可以通过脚本来获取组件状态，时间戳等