SMH Trust Status - True to False

[T. Rectenwald]

By default, SIM has a scheduled task called 'Daily System Identification' that runs the 'Identify Systems' tool against all systems daily, at 4:05 PM. For some reason, every time this job is run, it seems to set the SMH trust status to false on most systems.

The odd thing is that if I then run 'Identify Systems' against any of those systems manually, it sets the trust status back to true. The end result is when I'm testing communications through 'Manage Communications' I have to constantly either update the server, or re-run 'Identify Systems' against it to fix the SMH trust status.

Has anyone else had this issue? I'm depending on 'Manage Communications' to tell me the health of each system's ability to talk with SIM, and this odd behavior seems to be giving me false negatives.

My thoughts may be that the daily job is timing out on some systems. But all task instance results tend to show 'Complete' so they appear to be completing okay. My next steps here are to remove some extraneous systems from the polling list (i.e. HP-UX MP's, zero partition complexes, MC/SG clusters), perhaps change the time the job runs to a less busy time, network wise (middle of the night, morning)... or perhaps even disable it altogether and just run it manually from time to time.

I was just wondering if anyone else has experienced this behavior and if there is a known workaround, or explanation. I'm still in the process of learning SIM, so am not overly excited to tweak the defaults on these jobs unless there is good reason.

Best Regards,
Tom

[Rob Buxton]

I'm not sure if it's the same but I have tracked issues to this task in the past.
So now I disable this as a task.

[T. Rectenwald]

Thanks for the information. That's what I ended up doing earlier. I really think it must be some sort of timeout issue. That job tends to kick off Identify Systems on literally everything. One thing I'm wondering is if it pulls in the server a second time when it identifies the iLO device.

Anyway, it seems that disabling it is the best option. What I'll probably do is create several smaller jobs similar to it that run at different times during the week against subsets of the systems out there.