As enterprise grade software, the BlackBerry Enterprise Server software can be installed on a single server, or the BlackBerry Enterprise Server roles/components can be installed on multiple separate servers. When monitoring the BlackBerry roles/components with the OpsLogix Management Pack for BES, the Management Pack is licensed per BlackBerry server. The overview below shows if/when a license is needed for the BES Management Pack, when the BlackBerry Enterprise Server roles/components are installed over multiple servers.
List of possible services (BlackBerry components) that need to be licensed when installed on a BlackBerry server:
- Attachment Service
- Enterprise Server (service)
- MDS Service
- Router Service
If one of the above services is installed on a BlackBerry server, the BlackBerry server with the service installed always needs to be licensed. If multiple services are combined on one server only one license is needed for that particular server.
List of possible services (BlackBerry components) that DO NOT need to be licensed:
- Administration Service
- Collaboration Service
- BAS (BlackBerry Administration Service)
- BMS (BlackBerry Monitoring Service)
If one or more of the above services that do not need licensing is installed on a BlackBerry server (and none of the services are installed on the same server that do need licensing), no license is required for the BlackBerry server.
Just a quick word on the scaling/sizing of the free Ping Management Pack.
From all the feedback we have received over the years on the sizing of the Ping Management Pack, the following can be used as a rule of thumb:
- A physical Windows based machine (Windows 2003/2008/2012) with a SCOM agent (2007 R2 / 2012 SP1/R2) installed, will be able to handle a maximum of about 800 ping targets.
- The Windows based machine should have 4 GB RAM and at least 1 CPU.
- When running the Ping Management Pack from a Virtual Windows based machine, depending on its resource configuration, the maximum number of ping targets per Ping Host might far smaller than 800.
Finally, the Ping Management Pack demands resources from SCOM. When only a few Ping targets are configured, SCOM will probably be able to handle the additional workflows with ease. By default the Ping Management Pack only runs two workflows per Ping Target. If you are planning to configure hundreds or even thousands of Ping Targets, you will need to size your SCOM environment to cope with the workload accordingly.
As usual the disclaimer: OpsLogix will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
“The OpsLogix Capacity Intelligent Management Pack (IMP) provides administrators with a forecasting tool in the System Center Operations Manager™ console that enables accurate strategic prediction of the enterprise IT capacity.”
In 2012, Microsoft updated the SCOM 2007 R2 platform and SCOM 2012 added new features for High Availability (HA), application performance monitoring, network device monitoring, Java Application server monitoring and dashboards. Parallel to the release of SCOM 2012, OpsLogix began working on the capacity MP for System Center Operations Manager basing this on the dashboard technology that was added in the new 2012 version of Operations Manager.
OpsLogix has always maintained the core principle of making an MP as “natively true” as possible. That is to say that OpsLogix Management Packs should be as simple as possible to set-up, configure and fully integrate into the existing System Center framework. Management Packs should directly contribute to easier systems manageability without compromising security or increasing the size of the system’s footprint by having to add additional components.
The first iterations of the capacity MP looked very promising and worked very well in small environments. Unfortunately scalability and sizing quickly became an issue when the capacity MP was imported into larger environments. Its behavior became erratic. In the best case scenario retrieving data and displaying it was extremely sluggish, in the worst case scenario it caused the SCOM console to freeze or even crash.
After a series of tests in our own lab and in the QA environment of some of our larger beta testing partners it was concluded that the primary reason for this was because of the dashboard technology of Operations Manager itself. This is noticeable even without any management packs when trying to utilize out-of-the-box SCOM dashboard views and a large number of objects are added. The Object Picker runs into stability issues when trying to add too many objects.
Microsoft has since tweaked the dashboard technology in SCOM 2012 R2. Once again, after some code rewriting of their own, OpsLogix went into a new round of testing. Unfortunately, the SCOM performance (coding) improvements were nowhere near the point they needed to be to leverage consistent stable usage through the capacity MP. Since the OpsLogix capacity dashboards relied heavily on the SCOM dashboarding technology, the capacity MP dashboards performed far below the expected performance point.
We had hoped that the dashboarding performance would have improved dramatically with the release of SCOM 2012 R2, but this is not yet the case. Because of all the setbacks, for the time being, OpsLogix decided to abandoned the approach of building a capacity MP on the Operations Manager dashboarding technology.
The multiple rounds of testing have not been in vain and OpsLogix has listened to the community and have gone back to the drawing board to completely rework the capacity MP. The main point of feedback that we got was that having capacity dashboards that can be played around with are fun and nice to have but they are not in any way essential to the daily activities of a system administrator or operator.
Capacity management is something that is needed and looked at by system architects, analysts, consultants and of course, IT managers and CTOs. In all of these cases periodic reports are considered mandatory and as result a start has been made to leverage and expand the SCOM reporting technology.
As can be seen in the above screenshot, we have an alpha version of a capacity reporting MP but this still needs some work before we can release it for beta testing with customers.