【Troubleshooting Case】Exchange Server 组件状态应用排错?
2017-03-20 10:33
513 查看
在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>
每个条目包括以下信息,由冒号分隔:[未知值]:[状态]:[时间戳]
正如我们所看到的,组件有多个条目。如果其中一个条目会显示该组件是无效的,这将有效无效。即使最近的条目将该组件置于活动状态,它会到同一请求切换回主动保持无效。
可以通过脚本来获取组件状态,时间戳等
另外一种情况 就是在做补丁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>
每个条目包括以下信息,由冒号分隔:[未知值]:[状态]:[时间戳]
正如我们所看到的,组件有多个条目。如果其中一个条目会显示该组件是无效的,这将有效无效。即使最近的条目将该组件置于活动状态,它会到同一请求切换回主动保持无效。
可以通过脚本来获取组件状态,时间戳等
相关文章推荐
- 【Troubleshooting Case】无法删除Exchange 数据库DB 排错?
- Troubleshooting Case :2台DC同步问题
- A trouble shooting case - Background job ZABC failed
- WebSphere Class Loaders and Shared Library, Part 4 (Answer to case scenario + troubleshooting)
- 设置组件状态--如何动态关闭manifest中的Receiver (设置应用状态为不可用)
- CRM Middleware: BDoc basic knowledge and troubleshooting case study
- DB2 Linux, Unix and Windows HADR Simulator use case and troubleshooting guid
- CloudFoundry Troubleshooting Wardenized Services 排错
- Troubleshooting Methodology(排错方法学)
- one troubleshooting case about em access issue
- COM 组件设计与应用(一)起源及复合文件
- 一个可应用在ASP 标记加密文件的MD5的DLL组件 {81K}
- 巧用FileSystem组件实现WEB应用中的本地特定打印
- COM 组件设计与应用(六)
- 在基于对话框的应用中执行空闲状态处理(比如用ON_UPDATE_COMMAND_UI更新控件)
- COM 组件设计与应用(十七)——持续性
- Topics for Troubleshooting and Tuning
- 正在开发一个非.net得数据表格组件,用到.net应用中去……
- 存取程序状态的几种方法--Java I/O应用杂谈
- COM 组件设计与应用(五)