Support Tip: Some or all Cluster resources are not discovered by the OpsMgr agent

Support Tip: Some or all Cluster resources are not discovered by the OpsMgr agent

  • Comments 8
  • Likes

~ Mihai Sarbulescu

ToolsHere’s an issue we ran into the other day that you might want to be aware of. If a Cluster has orphaned object entries in ClusterHive registry key, the System Center Operations Manager agent may not discover some or all Cluster resources. This can occur with System Center Operations Manager 2007 (OpsMgr 2007) or System Center 2012 Operations Manager (OpsMgr 2012).

NOTE IF you take a TracingGuidsNative.log verbose OM ETL Trace (see http://support.microsoft.com/kb/942864) you will see evidence of this via this string in the trace: Some of the Virtual server critical (or key) properties is (are) NULL.

To resolve this issue we simply need to delete these orphaned resources and/or groups. First, use the Failover Cluster PowerShell commands Get-ClusterResource and Get-ClusterGroup to get the list of Resources and Groups. Then, using the output, check for Resources/Groups that appear as Offline and verify if these can be seen in the Failover Cluster Console. Verify with the Cluster administrator whether these are still valid, then assuming they are not and you’ve identified which ones that are orphaned, delete them using these commands from an elevated CMD Prompt (Run As Administrator):

For orphaned resources: Cluster RES "<RESOURCE_NAME>" /DELETE

For orphaned groups: Cluster GROUP "<GROUP_NAME>" /DELETE

Once this is done the missing cluster resources should now be discovered.

Mihai Sarbulescu | Support Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Is there going to be an update to the management pack to identfy and handle these orphaned entries? If not, will there be an update to Windows Clustering to prevent the orphans in the first place? We don't know for sure if we have any of these in our environment yet (we probably do), but it would be good to know if a permanent solution is coming, as that workaround is tedious in production environments.