Blackberry Exchange Server (BES) Version 5.0.1.58 Component Issues

From what I’ve been able to find, RIM removed several WMI / PerfMon classes in BES V5.0.1. That includes all of the components that are included in the Thwack templates. (Service monitoring is fine, but components are a no go)

So have I missed something? Is there an alternate method to get component / Perf stats? Has anyone heard RIM’s plan to address performance monitoring?

Any direction here would be appreciated!

Find more posts tagged with

blackberry_enterprise_server

performance_counter_monitor

rim

bes_5.0_sp1

5.0.1

bes

bes_5.0.1

Accepted answers

chris.lapoint

Please open a support ticket on this and we'll look into this.

All comments

chris.lapoint

Please open a support ticket on this and we'll look into this.

Alminair

With assistance from support, I found that while performance counters are now out, I could fill the gap with SNMP. In order to help anyone else using 5.0 SP1, here’s the pertinent info from my support ticket:

I found a reference (Which happens to be a SW site) that was extremely helpful.

https://support.ipmonitor.com/mibs/BLACKBERRYSERVER-MIB/info.aspx

The main difference between what you have listed and the MIB on my 5.0.1 server is they appended a .20 to the end. So where the above site lists a MIB OID of 1.3.6.1.4.1.3530.5.25.1.10, the new MIB for BES 5.0.1 is now 1.3.6.1.4.1.3530.5.25.1.10.20. The data appears to be consistent with the descriptions listed in the above info. The MIB name is also the same, but the mib list names also have the .20 appended. (Not all of those appear to be consistent, but the OID’s are)

I will upload the modified template I created, but by using the info above you can tweak a template for whatever you need. (Mine is paired down a bit since we are a smaller company with a light user load)

aLTeReGo

Here's the link to Alminair's Blackberry Enterprise Server (BES) 5.0 SP1 APM template based on SNMP. Thanks Alminair for your contribution!

Alminair

Thank you

FormerMember

How do I figure out what the values should be for 5.03 mr1?

Alminair

That depends on what you are actually asking. (I’ll answer both just for grins though)

We are still running on Version: 5.0.2.28, but the MIB’s haven’t changed for our version. If the MIB’s changed in 5.03 the easiest way to deal with that would be to use the MIB crawler to find what they changed and repoint to the new MIBs. (Which is essentially what I did) If they follow the same pattern of you should be able to use the previous info to find them.

If you are referring to what the data value OF those points should be set to for alarms and such*, that is much harder for me to tell you. In a nutshell it depends on the size of your system. The main reason I didn’t take much time in setting alarm points is because everyone has a different user load and hardware. Something that would be appropriate for our company (Which has a small number of BB users compared to most) wouldn’t be worth anything for a larger company with 50 times my users. It also wouldn’t be worthwhile for a smaller company running BES on a minimum spec system.

The best way to figure your monitor alarms is to set the points, run them for 2 weeks to a month. (Or perhaps longer if you have intermittent usage cycles). Once you have some historical data to look at, cross that against when you’ve had issues, user complaints, or times when you wished you knew the server was straining, and set things low enough to catch those while being high enough to ignore the daily noise. It does take some adjustment to get things ‘right’, and it’s a good idea to do that any time you make a significant change to the hardware or install.

*And if you are not, disregard this section J

DirtySouth

Were you able to get Messages Queued for Devliery and Messages Reeived/Sent per minute?

Alminair

Keeping in mind that we are on Version: 5.0.2.28:

For those that just want a quick answer:

· Use the Generic SNMP component for these -

o Messages Pending: OID 1.3.6.1.4.1.3530.5.25.1.202.20

o Messages Sent per Minute: OID 1.3.6.1.4.1.3530.5.25.1.207.20

o Messages Received per Minute: OID 1.3.6.1.4.1.3530.5.25.1.208.20

For those who want to know HOW to get that information, here’s my process:

Using the MIB resource I linked in the posts above I got the starting point for the MIB’s. That happens to be 1.3.6.1.4.1.3530.5 (for version 5)

Then I used the Engineering toolkit MIB Browser, went to MIBs toolbar, Search MIB Database. I entered the root 1.3.6.1.4.1.3530.5, and clicked the ‘Show in MIB tree’. From there I was able to browse the various OID’s available. The entries you want were nested in the blackBerryServer > besSysHealthTable >besSysHealthEntry path.

When you select the one you want, it displays the OID information in the pane below the tree in the following format:

BLACKBERRYSERVER-MIB:besSysHealthV1MsgsPending

OID 1.3.6.1.4.1.3530.5.25.1.202

Type INTEGER

Units

Access read-only

Status mandatory

Total number of messages queued for delivery to handhelds.

However as mentioned above, Rim changed these so that you have to add .20 to the OID for it to work correctly. Once you add the .20 it picks up as you can see below:

The other 2 OID's and the tested components are provided for your example pleasure:

BLACKBERRYSERVER-MIB:besSysHealthV1MsgsSentPerMin

OID 1.3.6.1.4.1.3530.5.25.1.207

Type INTEGER

Units

Access read-only

Status mandatory

Total number of messages sent from handhelds per min.

BLACKBERRYSERVER-MIB:besSysHealthV1MsgsRecvdPerMin

OID 1.3.6.1.4.1.3530.5.25.1.208

Type INTEGER

Units

Access read-only

Status mandatory

Total number of messages delivered to handhelds per min.

Hope that clarifies things a bit.

Alminair

I did want to mention that we should be updating to 5.03 shortly (Within a few weeks most likely), so if I find a significant difference I'll be updating to account for it. I'll also wind up reposting my template as well. Someone might beat me to the punch, but I gotta go with the upgrade timelines.

FormerMember

You guys are awesome I will play around with this today and report back.

FormerMember

I must be doing soemthing wrong here. When I "walk" the server that the Bes is located on I do not see anything for 1.3.6.1.4.1.3530.5 when I load the mib from C:\program files\blackberry enterprise server\monitoring service\ I can browse them and for example see the besSysHealthMsgPending has a value of 1.3.6.1.4.1.3530.5.25.1.25 but when I put that in the template and test I still get a response of: Testing on node AFAPPS.afarber.com: failed with 'Undefined' status

No such name error. Check whether OID is valid.

I assume when I "walk" I should see something about the BES right?

Marlbs

Did you find any difference updating to 5.0.3?

I am still having difficulty getting BES Connection to Exchange, Seconds that BES has failed connection to Exchange since last reboot, and Message Delivery Pending.

Do you still have to add the .20 to OIDs with 5.0.3 or do you have to add another value?

Bronx

Think this may help.

Alminair

I’m afraid I’ve been remiss in not updating this thread as I planned.

We have updated to the latest revision and the OID’s are the same with the .20. However note a few posts above from DirtySouth indicates that the number increments if you have multiple exchange servers in your org, and it may will increment if you have had one and move to another. (i.e. you may only have one working exchange server, but if others have existed in the past that .20 might actually be .21 or higher. I do not know what the correlation is on the increment and judging from the OID’s that DirtySouth reported it might not be linier. He reported data at 23, 24, 25, 30, and 31. This was matching to the 5 servers he currently has, but the gaps may have been caused by servers brought online and then retired.

I would love it if someone could check their counters and chime in to pin this down, but here is what I suspect: The first exchange server BES sees is going to be .20. Each unique exchange server will get an increment so that the first 5 servers would span .20 to .24. If 23 were decommissioned or otherwise changed so that BES couldn’t match it to an existing sever it would them decommission .23 (Since it’s not seeing the server there anymore) and add a new increment of .25. Again note that it’s a working theory that would require knowing the exact system changes in a larger system.

DirtySouth’s first post on the second page illustrates the range I’m talking about. My post right below it show the point in the MIB browser. Checking that point in the MIB should show you what the appended numbers are. (.20 for me in my post) and it will show you the range of instances if you do have more than one. (Such as in DirtySouth’s post) Now if you do have multiples I wouldn’t know how to tell them apart unless you shut off all your exchange servers but 1, see where the message pending are going, then booting up one at a time to see which queue picks up as you go. (REALLY likely in a larger system I’m sure J)

Alminair

Bronx replied on Wed, Aug 31 2011 12:37 PM

Whoa! My template linked in a KB?! Very cool!

Bronx

You bet! We like our customers. :-)