Forum Discussion
Jeremy_Bridges_
Nimbostratus
NimbostratusSCOM F5 Objects Not Consistent with Objects on F5
We have been working with the F5 management pack for a while in our DEV environment and have just set it up in QA. In both environments, we have noticed that the objects that are discovered in SCOM are not always consistent with the objects that have been added to the F5.
For instance, there are Virtual Servers and pools that are on the F5 and are taking traffic that aren't discovered in SCOM. Other Virtual Servers are discovered but their status is forever "Unmonitored". We have also found pools in SCOM that contain old pool members that use to be in pool on the F5 but aren't any more.
We are using management pack 1.5.1.287.
We want to get this fixed. It is not acceptable for us to put this management pack into our production environment if it is going to produce unreliable results. Please get back to us a your earliest convienence.
- The 'Refresh Health' task is available from the F5 tasks pane if you click on the POOL that the pool member is in. This will refresh the health of the pool and all of its pool members.
The health explorer is definitely showing different events than I saw in the logs -- I don't see the state changes from 12/09 and 12/10 that I detailed in the last post. Do you see any events from those days at all for the pool member? 
Jeremy_Bridges_I will try the Refresh Health task in a little while.
As we had discussed on the phone, I am trying to get a full trace log of the re-discovery of the application. Unfortunately, I keep getting a "The operation has timed out" error. I should probabaly install the latest management pack (v 1.6.0.138), correct? You had mentioned that it solved some timeout issues.
Also, should I install just the Core pack or the "Pro-enabled" pack?- Jeremy -- I think it's likely that SCOM is timing out the command as we have a default timeout set at 15 minutes (900 seconds). You can override this timeout when you run the task -- just set the "Timeout Seconds" parameter to 10000 or something like that.
Installing the new pack will probably not help with the timeout, and no you do not need the "Pro=-Enabled" pack. - Jeremy_Bridges_I don't see a timeout parameter anywhere. I am using the Discover Devices Wizard (see screenshot). Should I use something else?
- Ah, ok I assumed you were using the Rediscover task. Can you send me the screenshot or text that you're seeing when the timeout happens?
- Jeremy_Bridges_The discovery worked this time. I have set the trace level back to Warning and restarted the F5 monitoring service. I have sent the trace logs.
- Jeremy, just thought I would check in after being out for holidays. I've taken another look at the performance issues you were having with discovery and rediscovery of your BIG-IP. I've found some ways to dramatically improve performance of certain functions for large configurations such as you have. I'll have to double check when our next release to the web is -- I'll let you know.
Are you blocked by anything right now?
Happy holidays! Joel - Jeremy_Bridges_One extra bit of information for you: the object names were corrected by deleting the object with the wrong name, then creating a new object with the same properties as the old one (except for the name, of course). So, the old virtual server had the same IP and port as the new one. Don't know if that affects your diagnosis, but just wanted to let you know.
- Thanks for the summary -- I did some local testing with case-sensitivity of objects and we do definitely have a bug there. Operations manager handles things in a case sensitive way but somewhere in our code we apparently do not. I even reproduced the "failed to find existing entity" issue while testing this. Fixing your issues is my top priority and we will be letting you know soon when we can get new bits in your hands. Thanks!
Joel - Jeremy_Bridges_Not to complicate the matter, but I have found an additional problem. If pool members are changed on a pool member, it seems to stop reporting its status correctly. Here is how I discovered this issue:
At the time of the re-discovery, a pool by the name of GinnyE-DEV had three pool members:
10.41.53.216:80 (Up, Disabled)
10.41.54.82:80 (Up, Enabled)
10.41.54.83:80 (Up, Enabled)
Later, I removed the first node and added a different node:
10.41.53.92:80 (Up, Enabled)
10.41.54.82:80 (Up, Enabled)
10.41.54.83:80 (Up, Enabled)
For some other testing, I shut down the web service on the first two of these machines. So, it looked like this:
10.41.53.92:80 (Down, Enabled)
10.41.54.82:80 (Down, Enabled)
10.41.54.83:80 (Up, Enabled)
However, after all of this, the SCOM status still represented the first state of the pool members. See the attachments for the final state of the F5 and SCOM.
