SCOM F5 Objects Not Consistent with Objects on F5

A couple things comes to mind -- the case sensitivity issue you were having is the root cause of many of the issues you've been having and it may still be causing trouble. I've fixed this already for the next release which is coming up soon.

 

 

Second, you probably are aware of this but when pool members are added or removed you need to refresh the diagram view for those changes to show up unlike changes to an existing pool member's health state.

 

 

If you'd like to send the logs I can see if there is something else going on.

 

 

I have also seen several SQL connection failures in previous logs you've sent. For some reason the SQL server is occasionally rejecting connections or the network route to the SQL server gets broken. While certainly not a good thing, we do have recovery logic which keeps trying to recreate the connection and generally succeeds from the logs I've seen. If there is a problem with SQL server that could affect OpsMgr as well though.

 

 

The error at 5:30 pm means we tried to do a basic TCP connect to port 443 (iControl) during a discovery on the BIG-IP and it timed out without a response. The next error is another discovery that had a certificate problem. Do you still have the connection analyzer tool that I sent about 3 months ago? There seems to be some connectivity/certificate problems with discovery. I believe last time it was due to the clock getting off on the BIG-IP. These discovery issues should not affect pool member state however.

 

 

The "Service Logging" message just means the the "f5mpsvc.exe.config" file got updated (probably you turning on verbose logging?). Should not affect pool member health either.

 

 

Finally, the last error is due to a discovery where the "Update Big3D" checkbox was not checked on the discovery dialog box, or if using command line, the "/d:UpdateBig3d" switch was not specified. We require the user to authorize this explicitly since it's changing that binary on the BIG-IP. Again, no effect on pool members.

 

 

 

 

 

 

 

 

I'll look into the SQL connection problems.

 

 

I did find the connection analyizer tool. Originally, you had sent me two copies: one for iControl 1.5.0.0 and then for iControl 1.3.0.0. We now have iControl 1.5.1.0 on our SCOM machine. I need a version of the tool that is compiled against 1.5.1.0.

 

 

For future reference, it would be nice if this tool was shipped with the F5 management pack. That way, it would be matched to the version of iControl that shipped with the pack.

 

 

I did not check the "Update Big3D" option. I didn't think that was neccessary. Should I rediscover the device with the option checked?

 

 

You explainations of the other messages make sense. No more questions there.

I'll send the updated connection analyzer via email. We have since integrated this tool into our build process so that it is sync'd with releases.

 

 

Checking the "update big3d" option is necessary if the big3d version on the BIG-IP is older than the one that we ship with the management pack, so yes you should rediscover with that option checked. I think I mentioned this before but we have also made a fix for long discovery/rediscovery times for large numbers of objects such as you have and this will be released soon.

 

 

Thanks, joel

Here is what the Analyzer found:

 

 

Starting Tests

 

 

====================

 

 

Testing ping to management address...

 

Ping Succeeded

 

 

====================

 

 

Trying connection to BIG-IP using explicit iControl credentials...

 

Success

 

 

====================

 

 

Retrieving iControl management interfaces...

 

mgmt

 

1.1

 

1.2

 

1.3

 

1.4

 

2.1

 

2.2

 

 

====================

 

 

Retrieving BIG-IP time...

 

BIG-IP Time: 6:45:48 PM

 

 

====================

 

 

Retrieving BIG-IP version...

 

BIG-IP Version: 10.0.1

 

 

====================

 

 

Checking if the BIG-IP is a virtual machine...

 

The BIG-IP is NOT a virtual machine.

 

 

====================

 

 

Getting installed registry values...

 

DB Server: lv2devsql01

 

DB Name: F5_ManagementPack

 

Success - got registry values

 

 

====================

 

 

Getting connection to sql_dbInfo. using: Data Source=lv2devsql01;Initial Catalog=F5_ManagementPack;Integrated Security=True

 

 

====================

 

 

Getting connection to sql_dbInfo. using: Data Source=lv2devsql01;Initial Catalog=F5_ManagementPack;Integrated Security=True

 

ClockSkew: -1461654

 

KeyFile: C:\Windows\system32\F5MP\F50.key

 

AdminUserName: 10.41.52.27

 

MgmtAddress: jeremy

 

Success - got connection info from sql_dbInfo.

 

 

====================

 

 

Trying to connect to device using iControl token...

 

Generating token

 

Token: NMwl4huJ8JGaA472GPECEzs6+pMfiTEpEs/50LKxlwDbuEQRuiXM73lLJcfRdSjCbSDMgKt6DZ/JK4uZ07d8dry2F6sfrsx9HAF0Tdq3YwHZqGHQ9/bJcj2f43CAi1GBnX7f9yIgPi479XyFH6iWbX2i8Z5jM4yOZUWggaSx8y4=

 

Getting host ip...

 

Host name: KFDDEVSCOM01

 

Host IP: 10.41.55.20

 

Success - connected with token

 

 

====================

 

 

Verifying that local cert file is uploaded to BIG-IP...

 

Found file in F5MP directory:C:\WINDOWS\system32\F5MP\F50.cer

 

Found file in F5MP directory:C:\WINDOWS\system32\F5MP\F50.key

 

Using local cert file: C:\Windows\system32\F5MP\F50.cer

 

Local cert:

 

-----BEGIN CERTIFICATE-----

 

MIICoDCCAgmgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBlTELMAkGA1UEBhMCVVMx

 

CzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMRowGAYDVQQKExFGNSBOZXR3

 

b3JrcywgSW5jLjELMAkGA1UECxMCRU0xPjA8BgNVBAMTNUY1TWFuYWdlbWVudFBh

 

Y2stY2RmYTgzYjUtNDUxYS00MGIwLWI5MGQtOTE2MGM2ZWEzODMwMB4XDTA5MDYy

 

NTE1NDQxNloXDTEwMDYyNjE1NDQxNlowgZUxCzAJBgNVBAYTAlVTMQswCQYDVQQI

 

EwJXQTEQMA4GA1UEBxMHU2VhdHRsZTEaMBgGA1UEChMRRjUgTmV0d29ya3MsIElu

 

Yy4xCzAJBgNVBAsTAkVNMT4wPAYDVQQDEzVGNU1hbmFnZW1lbnRQYWNrLWNkZmE4

 

M2I1LTQ1MWEtNDBiMC1iOTBkLTkxNjBjNmVhMzgzMDCBnzANBgkqhkiG9w0BAQEF

 

AAOBjQAwgYkCgYEAqvAwlcipHkBWxpNPGnYcql8edjhnFPFO+jc1HU/UGEtANAy9

 

0k5f/tWJxlNpBF6L0N6Br5ItUJpsAwGW+eAsJ/Qgyx3TcpWoDF8fzYbsICYfCbCs

 

GDukAKx8JyqPwn8HQTTrpQNZ2NLw5g7VwAWAwCnGgoHkmFBhjGYG21GWVxcCAwEA

 

ATANBgkqhkiG9w0BAQUFAAOBgQCeKHJ0ZJ5Gxru4yztn9MdrW2VMsza6CIwrIlln

 

uaY/DxtKCKeI5TSo6zyGRk52sfD0SBidtDVo1O6eBGe5yJAM/1eXo4cELgRdVjO7

 

UfIXaO2UVCMK3RZ3+9tohdNVu3E8JVtbnVRcXKsHV/cqKpw5PEiBk7AXLu6PRmg6

 

AFe4lw==

 

-----END CERTIFICATE-----

 

 

 

Looking for remote cert: /shared/em/ssl.crt/10.41.55.20.crt

 

Remote cert:

 

-----BEGIN CERTIFICATE-----

 

MIICoDCCAgmgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBlTELMAkGA1UEBhMCVVMx

 

CzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMRowGAYDVQQKExFGNSBOZXR3

 

b3JrcywgSW5jLjELMAkGA1UECxMCRU0xPjA8BgNVBAMTNUY1TWFuYWdlbWVudFBh

 

Y2stY2RmYTgzYjUtNDUxYS00MGIwLWI5MGQtOTE2MGM2ZWEzODMwMB4XDTA5MDYy

 

NTE1NDQxNloXDTEwMDYyNjE1NDQxNlowgZUxCzAJBgNVBAYTAlVTMQswCQYDVQQI

 

EwJXQTEQMA4GA1UEBxMHU2VhdHRsZTEaMBgGA1UEChMRRjUgTmV0d29ya3MsIElu

 

Yy4xCzAJBgNVBAsTAkVNMT4wPAYDVQQDEzVGNU1hbmFnZW1lbnRQYWNrLWNkZmE4

 

M2I1LTQ1MWEtNDBiMC1iOTBkLTkxNjBjNmVhMzgzMDCBnzANBgkqhkiG9w0BAQEF

 

AAOBjQAwgYkCgYEAqvAwlcipHkBWxpNPGnYcql8edjhnFPFO+jc1HU/UGEtANAy9

 

0k5f/tWJxlNpBF6L0N6Br5ItUJpsAwGW+eAsJ/Qgyx3TcpWoDF8fzYbsICYfCbCs

 

GDukAKx8JyqPwn8HQTTrpQNZ2NLw5g7VwAWAwCnGgoHkmFBhjGYG21GWVxcCAwEA

 

ATANBgkqhkiG9w0BAQUFAAOBgQCeKHJ0ZJ5Gxru4yztn9MdrW2VMsza6CIwrIlln

 

uaY/DxtKCKeI5TSo6zyGRk52sfD0SBidtDVo1O6eBGe5yJAM/1eXo4cELgRdVjO7

 

UfIXaO2UVCMK3RZ3+9tohdNVu3E8JVtbnVRcXKsHV/cqKpw5PEiBk7AXLu6PRmg6

 

AFe4lw==

 

-----END CERTIFICATE-----

 

 

 

Success: local and remote certs are the same

 

 

====================

 

 

Verifying clock skew...

 

Local Time: 6:45:53 PM

 

Difference in seconds: -5.6881663

 

Stored difference in seconds:-0.1461654

 

Difference between stored and actual in seconds:5.5420009

 

Success - stored clock skew is within tolerance of actual clock skew

 

 

====================

 

 

OVERALL: PASS

 

Everything looks good... if there was a connectivity problem is was temporary.