空空的BLOG

当在SCOM 2007 SP1环境下遭遇SQLSERVER进程持续占用CPU 100%的解决办法

错误日志：

在数据仓库中存储数据失败。将重试操作。
异常“SqlException”: 超时时间已到。在操作完成之前超时时间已过或服务器未响应。

一个或多个工作流受此影响。

工作流名称: Microsoft.SystemCenter.DataWarehouse.Synchronization.TypedManagedEntity
实例名称: server-mom-ltd.beijing.cnooc.corp
实例 ID: {1335BCEE-3DB3-30E0-6C16-7AD94C352253}
管理组: scom2007

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持

报表部署过程从 Data Warehouse 请求管理包列表失败。将重试操作。
异常“SqlException”: 超时时间已到。在操作完成之前超时时间已过或服务器未响应。

一个或多个工作流受此影响。

工作流名称: Microsoft.SystemCenter.DataWarehouse.Deployment.Report
实例名称: server-mom-ltd.beijing.cnooc.corp
实例 ID: {1335BCEE-3DB3-30E0-6C16-7AD94C352253}
管理组: scom2007

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持

在数据仓库中存储数据失败。将重试操作。
异常“SqlException”: 超时时间已到。在操作完成之前超时时间已过或服务器未响应。

一个或多个工作流受此影响。

工作流名称: Microsoft.SystemCenter.DataWarehouse.Synchronization.TypedManagedEntity
实例名称: server-mom-ltd.beijing.cnooc.corp
实例 ID: {1335BCEE-3DB3-30E0-6C16-7AD94C352253}
管理组: scom2007

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持

监视 Application 事件日志的 Windows 事件日志提供程序处理事件时 延迟了 406 分钟。当提供程序脱机一段时间后重新启动时，或当工作流要处理的事件太多时， 可能会发生这种情况。

一个或多个工作流受此影响。

工作流名称: Microsoft.Windows.Server.2003.OperatingSystem.WindowsActivation
实例名称: Microsoft(R) Windows(R) Server 2003, Enterprise Edition
实例 ID: {D603B69C-7B2A-D6E0-1CFC-F19334A58E7B}
管理组: scom2007

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。

对管理组“scom2007”中 ID 为“{D603B69C-7B2A-D6E0-1CFC-F19334A58E7B}”的实例“Microsoft(R) Windows(R) Server 2003, Enterprise Edition”运行的规则“Microsoft.Windows.Server.2003.OperatingSystem.CheckingFileSystemOccuredOnStartup.Collection”中，由于未处理的数据太多而丢弃数据。

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持

原因：SCOM 2007 SP1的DW数据库缺少必要的索引

解决办法：

使用SQL 2005查询分析器运行如下命令：

use operationsmanagerdw
sp_updatestats

…is not a good idea.  In a production deployment a second server should be built using the desired server name, and then all OCS users moved over to it.  Or a temporary staging server can be stood up in order to rebuild the original server.  Either way, simply renaming an Office Communications Standard Server 2007 can be painful.

Shortly after deploying a standard server in my lab I noticed during server configuration that I had fat-fingered the server's hostname and was not to happy about that. I decided to see what would happen if I just renamed the server without any preparation in OCS.  After renaming my virtual guest from JDSSOCS01 to JDSOCS01 I was welcomed with a standard Windows startup message alerting me to a service failure.

A quick scan of the Application event log uncovers event ID 12291 explaining that "the Communications service is registered for a different machine."  Microsoft Knowledgebase Article ID 830535 covers this error, but in reference to LCS 2003, and states that changing the FQDN of a Live Communications Server is not supported.  So it doesn't appear to be supported in OCS 2007 either.

The article's resolution suggests exporting the RTC SQL database to a file, removing the OCS services, and re-installing the product.  Because I had already renamed the server I was unable to deactivate the pool/server using the previous name and was presented with a couple warnings during the uninstall that some configuration information will be left in the Active Directory domain; I took note of this for later troubleshooting. I also completely removed the SQL 2005 Express components in order to wipe the OCS install from the server.

During reinstallation of the OCS Standard Server the setup wizard reported a failure and viewing the install log showed that the server could not be activated for a pool due to a conflict. At this point I decided to just delete the VM and rebuild the server from a fresh image as deploying a clean lab environment was my overall goal.  Before creating a new server with the desired server name of JDSOCS01 I went to delete the existing computer object in Active Directory, but oddly enough I was warned that deletion of that object would result in all child objects also being removed from AD.  I checked out the existing computer object using ADSIedit and apparently the OCS installation inserts additional objects under the server:

I deleted the computer object and imaged a new virtual guest using the correct server name.  This time the OCS Standard Server installation completed successfully, but  I received another error after validating the front-end server configuration:

Failure: [0xC3FC200D] One or more errors were detected

 Diagnose Server

   Check Configuration

      Checking all trusted servers

         Internal Server JDSSOCS01.lab.schertz.local

DNS Resolution failure: No such host is known

Suggested Resolution: Make sure there are no typos in the Server name. Make sure that the Server name is published in the DNS (A or SRV record) or hosts file entry is configured correctly.

This is the part where I spent some time digging through AD looking for where the old server name was hiding.   After running some LDAP queries using the string *pool* I discovered where OCS stores it's configuration data in AD:

CN=RTC Service,CN=Microsoft,CN=System.DC=domain,DC=com

I located and deleted the Pool object for the old server:

CN=JDSSOCS01,CN=Pools,CN=RTC Service,CN=Microsoft,CN=System,DC=schertz,DC=local

But that didn't resolve the validation errors after rebooting the OCS server.  I dug deeper and found both the old and new server FQDNs referenced in multiple objects under Global Settings, MCU Factories, Trusted MCUs, and Trusted WebComponentsServers.  Using the command ldifde -f output.txt -d "dc=schertz,dc=local" is was able to search the text export file for all the objects with attributes referring to "jdssocs01":

CN=Global Settings,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN:  CN={DB1226B0-B04E-494F-BF44-6C365A2A4CF1}

objectCategory:  CN=ms-RTC-SIP-TrustedServer

msRTCSIP-TrustedServerFQDN:  JDSSOCS01.schertz.local

CN=MCU Factories,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN:  CN={0AAB2557-E5AA-4229-8F43-600554BAE453}

objectCategory:  CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData:  FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

DN:  CN={55753891-89EA-4F18-B020-5FA5928BE97F}

objectCategory:  CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData:  FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

DN:  CN={56B7C1C4-1961-461A-B40F-3ABB3C62BE31}

objectCategory:  CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData:  FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

DN:  CN={E1F6A173-E15D-427A-8E2A-87DD1CAAD947}

objectCategory:  CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData:  FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

CN=Trusted MCUs,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN:  CN={459B434F-3099-4049-8A2E-56D0524AFAD4}

objectCategory:  CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN:  JDSSOCS01.schertz.local

DN:  CN={51D7A033-A074-4285-9589-FB78AAB6A460}

objectCategory:  CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN:  JDSSOCS01.schertz.local

DN:  CN={9DE8BC35-D15A-4F8F-8BCD-A819014420F0}

objectCategory:  CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN:  JDSSOCS01.schertz.local

DN:  CN={C5677C4C-7BE6-484D-9CD4-878F1F8427BE}

objectCategory:  CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN:  JDSSOCS01.schertz.local

CN=Trusted WebComponentsServers,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN:  CN={93A1A739-3B44-4F0B-935A-170EAAA63026}

objectCategory:  CN=ms-RTC-SIP-TrustedWebComponentsServer

msRTCSIP-TrustedWebComponentsServerFQDN:  JDSSOCS01.schertz.local

I deleted all objects above and then removed the invalid ServicePrincipalName entries from the RTCService and RTCComponentService user accounts.

I forced AD replication between both domain controllers and rebooted the OCS server, and the validation check no longer reports any failures.

下载地址：
http://office.microsoft.com/en-us/help/HA101733831033.aspx
关于更新内容：
http://support.microsoft.com/kb/950050