discovery problem!!!

Hi Fabrizio,

 

 

Thank you for the detailed error report. For some reason the error log(s) that you were referring to have not been attached to your post. From what you are describing, I would assume your discovery fails because of device related connectivity, authorization, etc, issues. Please enable verbose logging support (see http://devcentral.f5.com/wiki/default.aspx/MgmtPack/GeneralTroubleshooting.html) and try discovery again. Gather the following logs (to have as much information as we can possibly have) to expedite troubleshooting:

 

 

- trace.log file (in \Program Files\F5 Networks\Management Pack\log folder)

 

- F5 Monitoring Log (in Event Viewer)

 

- OperationsManager log (in Event Viewer)

 

 

Zip the logs to managementpack(at)f5(dot)com.

 

 

Also, please consider the following important prerequisites for a successful F5 device discovery:

 

 

- admin credentials for the F5 device account specified in discovery.

 

- enable TCP port 4353 through the firewall for bi-directional [iQuery] communication with the F5 device.

 

- enable the 'Authorize big3d agent update' [checkbox] in the F5 Discovery wizard.

 

 

Here are some relevant links detailing these prerequisites for F5 Management Pack discovery:

 

 

- http://devcentral.f5.com/wiki/default.aspx/MgmtPack/F5DeviceUserRoleSecurity.html

 

- http://devcentral.f5.com/wiki/default.aspx/MgmtPack/TroubleShootingDiscovery.html

 

 

Let us know.

 

 

Thank you!

 

Julian

 

 

 

Hi Julian,

 

sorry for the late reply, the customer we are testing the BIGIP Virtual with SCOM monitoring, and he correct integrate BIGIP with AD authentication (because probably for performing discovery it should be needed a service AD account).

 

 

I think it isn't possible this because the discovery tool needs the BIGIP administrator granted account. Also, into SCOM interface we saw the task correctly performed, but we can't see the appliance and the data.

 

 

So, I ask requested log to customer, I'll send you asap.

 

 

Thanks a lot

 

Best Regards

 

Fabrizio

 

 

Hi Fabrizio,

 

 

If I understand correctly, you're concerned if the account used in the F5 Management Pack discovery wizard needs to be an Active Directory account. No, not at all. It could be just a local device account (used for basic authentication). But it needs to have an admin role on the F5 device. On the other hand, you could use the Active Directory integrated authentication mapping through the 'Remote Directory Tree' configuration (on the F5 device): Users :: Authentication :: User Directory :: Remote Active Directory :: Remote Directory Tree, where you would enter the AD organizational group (OU) which contains the user accounts for accessing the F5 device. You can have this OU / user group have admin rights on your F5 device.

 

 

Julian

Fabrizio,

 

 

I'll split this forum post here, to better track your two existing issues now:

 

 

1. The initial discovery problem, which I'm not sure if you were able to resolve yet.

 

2. Using Active Directory / LDAP integrated authentication for the user account used by the F5 Management Pack discovery wizard.

 

 

We'll track issue 2 here:

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/54/afv/topic/aft/1177053/aff/59/showtab/groupforums/Default.aspx1224599

 

 

Feel free to post there any related topic on the user account / LDAP integration.

 

 

These two problems could very well be closely related, but for now having the two posts focusing on each individual issue makes better sense for our issue tracking process.

 

 

Thank you!

 

 

Julian

 

(F5 Management Pack)

Hi Julian,

 

in first thanks for support. I think the customer wanted to try the AD integration because we can't performing discovery with Local Admin account, but it isn't correct and it isn't necessary.

 

 

However the strange thing is that on SCOM interface we saw the correct task performed, but is seem that SCOM can't read the BIGIP objects.

 

 

1) Is this Management Pack (2.1.5.440) compliant with the LTM version? (now is 10.0.1 HF4, probably it will be 10.2.0 HF2).

 

2) How users in SCOM must be configured for discovery task?

 

 

Thanks a lot

 

Regards

 

Fabrizio.

Hi Fabrizio,

 

 

To first answer your questions:

 

 

1. The current release of the F5 Management Pack (v2.1.5.440) does support LTM platform versions 9.4 and higher, up to the latest.

 

2. Most importantly, the account running the F5 Monitoring Service should be part of the SCOM Administrators group/role. Also, see issue 5 in the following article, explaining some other SCOM related security permissions required: http://devcentral.f5.com/wiki/default.aspx/MgmtPack/InstallationTroubleshooting.html

 

 

Now coming back to your discovery problem, which we try to track on this forum post (apart from the one tracking the Active Directory integration for the F5 Device discovery account, for which I opened up a new post, mentioned in my previous reply), make sure you comply with the requirements suggested in the following articles:

 

 

F5 Device User Role Security Requirements:

 

http://devcentral.f5.com/wiki/default.aspx/MgmtPack/F5DeviceUserRoleSecurity.html

 

 

Discovering F5 Networks Devices:

 

http://devcentral.f5.com/wiki/default.aspx/MgmtPack/DiscoveringF5NetworksDevices.html

 

 

Troubleshooting Discovery:

 

http://devcentral.f5.com/wiki/default.aspx/MgmtPack/TroubleShootingDiscovery.html

 

 

* * *

 

 

Next I'd suggest attempting a new discovery (for the same F5 device), just to make sure the device configuration is properly discovered/cached/updated. In anticipation of possible discovery errors, I'd recommend enabling the verbose trace logs (see the "Verbose Logging Support" section in http://devcentral.f5.com/wiki/default.aspx/MgmtPack/GeneralTroubleshooting.html) and then proceed with the F5 device discovery.

 

 

Let us know if you see any errors or if the F5 device health is still not showing up in SCOM. In this case please archive and email the following to managementpack(at)f5(dot)com:

 

 

- trace.log file in \Program Files\F5 Networks\Management Pack\log folder.

 

- F5 Monitoring Log and Operations Manager log (in the Event Viewer).

 

 

Thank you!

 

Julian

 

 

 

 

Hi Julian,

 

I sent you the file required.

 

 

Thanks a lot

 

Fabrizio.

 

Hi Fabrizio,

 

 

The logs you've sent us are relatively old (~2 weeks), so I assume you haven't tried to rediscover the F5 device as I've suggested in my previous post. I'd like to start a clean slate in troubleshooting your issue, so that we can make some progress towards a quick resolution. From your current logs I can only see that the F5 Monitoring Service (the actual F5 device monitoring agent) cannot communicate with the SCOM Health Service. This could have multiple reasons and I would like you to first check the following (and please post back here the results/answers):

 

 

1. The account running the F5 Monitoring Service is part of the Operations Manager Administrators group. You can verify this in the SCOM Management Console :: Administration :: Security :: User Roles :: Operations Manager Administrators :: General Properties.

 

2. Tell us more about your SCOM deployment: is it a single RMS or do you have multiple management servers? If you do have multiple management servers, did you first install the F5 MP on the RMS and then on the other management server(s)?

 

 

Let's start and build our troubleshooting case from here. Please email us the setup.log file, found in Program Files\F5 Networks\Management Pack\log folder.

 

 

Thank you.

 

Julian

Hi Julian,

 

I reply to you on below:

 

 

1. Yes, it is. There is one AD user service account (scom) insert into Operations Manager Administrators group. The same user is used for lauch the F5 Monitoring Service.

 

The F5 Monitoring Service is started on the same RMS server.

 

 

2. There is only one RMS installed in the environment.

 

 

I sent you the new log file, today we reinstall the MP and we tried again a discovery attempts. You can find it into log file.

 

 

Thanks a lot

 

Regards

 

Fabrizio.

 

 

Hi Fabrizio,

 

 

The new logs are showing no relevant errors about the F5 Management Pack. I'm not sure if the snapshot of the logs has been taken before or after you attempted to discover the F5 device(s). The setup.log shows that the F5 Data Source and Condition Detection modules have been successfully loaded. This was my main concern about your deployment, judging from your earlier logs that you sent us, which were showing that the F5 data sources are not loading.

 

 

So, I'm not sure exactly what kind of errors are you getting now, while trying to discover F5 device(s).

 

 

Looking at the setup.log file, it shows that you have deployed the F5 Management Pack on the SCOM RMS. By default, the F5 MP setup will disable the F5 Monitoring Service on the RMS. Is this condition true in your environment? According to Microsoft's best practices in a distributed SCOM management server environment, monitoring on the RMS should be avoided when possible. This is why the F5 Monitoring Service should be disabled. So, if you try to discover from the RMS when the F5 Monitoring Service is disabled, you will be getting an error about not being able to connect to the monitoring service. Is this the error that you are seeing?

 

 

It looks like you have multiple management servers in your SCOM environment. I would encourage you to deploy the F5 Management Pack on at least one of those management servers and perform the F5 device monitoring from there (and leave the F5 Monitoring Service disabled on the RMS). Please check out the following article on how to deploy the F5 Management Pack:

 

 

http://devcentral.f5.com/wiki/default.aspx/MgmtPack/InstallingTheF5ManagementPack.html

 

 

If you are seeing any errors in the F5 Monitoring Log, on the management server where you have the F5 Monitoring Service enabled, and those errors are pointing to the F5 data sources and condition detection module not loading let us know. For this particular error you can check out the following post on this forum, on a similar behavior, and see if any of the suggestions mentioned there would help you:

 

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/54/afv/topic/aft/1176691/aff/59/showtab/groupforums/Default.aspx1224856

 

 

Julian