1. Using SCOM for VMware monitoring: Experts’ Tips Cameron Fuller Microsoft System Center MVP Alec King Product Management Director at Veeam Software Pete Zerger Microsoft System Center MVP

2. What’s in?  Monitoring with the “virtualization stack” in mind  Data sources and solution architectures  Actionable alerts vs. “alert noise”  Creating a dynamic user experience  Reporting for trending, capacity planning and forecasting  Override behavior and 4 Tips for proper override tuning

3. Storage monitoring Storage monitoring solutions can be very esoteric and expensive. A virtualization monitoring solution that points SCOM and VMware administrators to problems at this layer is a welcome addition indeed.

4. When SCOM is blind There are aspects of the virtual infrastructure that are not visible to SCOM through its agents:  vSphere ‐ specific metrics for the VM such as balloon memory and CPU wait time;  Important components of vSphere including ESX(i) hosts, clusters and vCenter Server;  Automation within vSphere directly affecting VMs, such as Distributed Resource Scheduler (DRS), vMotion and High Availability (HA)

5. Continuous Visibility Without visibility of vSphere as a whole, it is impossible to monitor such critical aspects of vSphere as: Physical hardware status VM status and location ESX(i) host performance

6. “Virtualization stack” By you can effectively combine the power of SCOM and vSphere monitoring to provide a more comprehensive monitoring solution. monitoring with the virtualization stack in mind,

7. Data sources and solution architectures You can get information on vSphere performance from different data sources, including:  SNMP;  Syslog;  VMcontrol-based APIs;  Web Service SDK; It is important to understand which sources expose the data needed to quickly identify and isolate common issues and to understand the PROs & CONs of each approach.

8. SNMP & Syslog: PROs & CONs SNMPSyslog vSphere is SNMP-enabled, and SNMP monitoring is configurable through the System Center Operations Console UI (user interface). Syslog messages from vSphere are a rich source of hardware monitoring data, and rules that utilize Syslog can be configured using the UI wizards in the System Center Operations Console. Many VMware Infrastructure 3 (VI3), vSphere4 and vSphere 4.1 events and performance metrics are not exposed via SNMP. VMware is no longer focusing on management via SNMP. Messages tend to be cryptic, and most are of little use to most operators without time-consuming translation to a human interpretable error message.

9. vmcontrol-based APIs & Web Service SDK vmcontrol-based APIs (including vmPerl / vmCOM) Web Service SDK (requires vCenter Server) COM was deprecated some time ago, so you should avoid using this altogether. While vSphere does offer an SDK for Perl, Perl is not a Windows-friendly option, and is probably the least documented in terms of samples on the Internet. This is the richest source of vSphere performance data with the lowest impact on host and guest performance. It provides the most complete picture of infrastructure and application performance and health with the best scalability from a vSphere perspective.

10. Other methods There are also various methods available for monitoring servers in the virtual infrastructure. For more practical information on the other monitoring methods and the PROs & CONs of each of them, please, refer to the full version of Veeam’s featured White-Paper “Best Practices for Monitoring VMware with SCOM” available at www.veeam.com/whitepapers.htmlwww.veeam.com/whitepapers.html

11. Catch the problem before it grows The best thing to keep in mind for productive VMware monitoring is: “catch the little problems before they become major issues that cause service interruptions” To bring this principle into reality you should set critical alerts appropriately.

12. “One Man’s Trash Is Another Man’s Treasure”  The goal of SCOM is to notify administrators of issues before they become a major problem.  But with all the alerts SCOM is way too “noisy” (at least in some environments).  “Noise” is generated when alerts (usually sent via email) are created by SCOM for situations that are not actionable, relevant or unique.

13. When SCOM is “noisy” When someone tells you SCOM is “noisy” you should remember, that… 1.…you can generate alerts that are only displayed in the SCOM console and are not necessarily sent by emails. 2.…the SCOM management packs are designed to be used by organizations that range from relatively small to large-scale enterprise environments and thus should be configured accordingly. 3.…SCOM requires a proper tuning to match the requirements of an organization fully — and it’s perfectly tunable (See slide 15 for a hint)!

14. Crucial Alerts vs. “Alert Noise”  Tune up the SCOM alert system to provide only actionable alerting matching the needs of your business.  That way you ensure that the notifications that are sent will be acted upon and not regarded as “alert noise”.

15. Customize your User Experience The SCOM console needs to be targeted to show only the information that is relevant to the specific user, including the user’s servers and applications.

16. Dynamic User Experience Using user groups is a great way to ensure that every operator is getting information relevant to his\her responsibilities. There are 2 general categories of groups in SCOM:  Static groups are created by adding specific entities to the group as explicit members. Static groups are useful when there are no specific criteria that define group membership.  Dynamic groups are created by setting criteria that define what entities are members of the group. Entities matching those criteria are automatically added to the group.

17. Capacity Trends  The SCOM Data Warehouse provides reports on the trends over a significant period of time that is customizable to your business requirements.  By integrating performance data into SCOM we can generate trend reports on custom metrics (such as CPU Wait Time) to see if additional capacity is currently required.

18. Capacity Planning & Forecasting In order to identify and resolve an issue before it affects the users, SCOM should be able to not only see trends on performance metrics but also to forecast on metrics based upon the history of the data. However, SCOM lacks an off-the-shelf report for forecasting and capacity planning. To make projections of future resource consumption you need to integrate an additional reporting software, such as, e.g., Veeam Reporter ™.

19. Veeam Reporting Solution Veeam Reporter, now available as a part of Veeam ONE ™ solution, provides extensive capacity planning & change management functionality.  It discovers, documents and analyzes your entire virtual infrastructure and maintains a complete history of all objects, settings and changes.  Armed with knowledge of your virtual environment’s configuration and its past and current utilization, it makes recommendations for resource allocations and acquisitions.

20. Overrides When customizing SCOM for VMware monitoring don’t forget about the overrides:  Overrides are used to enable, disable or modify monitoring elements in a management pack (rules, monitors, discoveries, and so on);  Override precedence is a “rule of the road” regarding override behavior with multiple overrides present on a single rule, monitor or discovery.

21. Override precedence: rules of the road Take these “rules of the road” into consideration to control override precedence:  The most specific override takes precedence.  An enforced override takes precedence.  Overrides in unsealed management packs take precedence.  Class overrides from contained or hosted instances take precedence over class overrides of the instance.  Instance overrides with the higher relative depth take precedence over those with a lower depth.

22. Taking full control over Overrides Override precedence is just one thing. To take full control over overrides, keep the following 4 tips in mind when tuning your SCOM environment: 1.Use classes where possible 2. Target overrides to a group VS. an entity 3.Use dynamic groups when possible 4.Create relevant groups for entities

23. If a class already exists that meets your requirements, use the class instead of a custom group (unless you need to create the group for other reasons such as customizing the user experience). Tip #1. Use classes where possible

24. Tip #2. Target overrides to a group VS. an entity Using groups allows these overrides to be portable so that they can be moved between SCOM environments. This approach also minimizes the number of overrides required by gathering similar systems and applying a single override to the group.

25. Tip #3. Use dynamic groups when possible Static groups require maintenance to add and remove members of the group as agents are deployed or removed from the environment. Dynamic groups do not require this added maintenance.

26. Tip #4. Create relevant groups for entities Groups can contain any type of entity, not just servers. SCOM automatically provides an alert when the default application pool or default website is not running. While removal of these websites and application pools are the recommended approach, you can instead generate a group that contains the entities that match the name and then disable the monitor for that group of entities.

27. Got more questions? If you need more details related to this subject, please, refer to Veeam’s featured White Paper “Best Practices for Monitoring VMware with SCOM” http://go.veeam.com/wp- best-practices-monitoring- vmware-with-scom-fuller- king-zerger.html

28. Thanks for your attention!