Paul Gregory is one of QA’s principal technologists – specialising in delivering training around Microsoft Server operating systems, virtualisation and systems management. During a 29-year career within IT, Paul has helped many international organisations develop infrastructure solutions based on Microsoft technologies, as well as supply training services during the last 14 years. Paul has helped QA deliver numerous Microsoft partner training skilling programmes for Microsoft – particularly around the areas of Microsoft Server operating systems, virtualisation and System Center. Paul was also heavily involved in the recent Microsoft Windows 8 / Server 2012 TAP programme where he played a key role in the testing of core Windows Server 2012 technologies and positioning this information back to product specialists in Redmond. With the advent of the Microsoft Private Cloud solutions based on System Center 2010 & 2012 Paul have been responsible in helping Microsoft prepare the Partner channel both in the US and Europe for these technologies.
Often customers I come across install SCOM and panic the main reasons for this are:
1) Trying to do too much too soon
2) Not fully understanding their environment
3) Not understanding SCOM tries to predict issues
There are a few other reasons but we do not need to worry about them here. But this gets me to where I want to be the noise. Starting with item (3) it is important that SCOM tries to predict events so there is always a balance between being noisy and missing events which need to be reported to predict a future event and where that line needs to be drawn will vary from one organisation to another.
One area I see people struggle with this is managing basic hardware capacity issues. For example monitoring free disk space. The main problem is most systems today will have fairly small OS drives and much larger data volumes so different thresholds need to be set. However the default rules for managing free disk space apply to all drives in a computer. To be able to manage this correctly a number of things need to be put in place for best practise.
1) Standardize Server Builds – I often here that server builds are a bit random, it is never too late to standardize the build.
2) Create SCOM Groups for each drive (steps below)
3) Set Overrides for each drive group and for each OS type.
This model will then allow different disk space thresholds to be set for each group of hard drives.
SCOM Drive Groups
1) From within the SCOM administration console select the Authoring panel
2) Select Groups and choose Create Group on the right
3) Give the group a name and description and create a new management pack for storing Windows Server Hardware Monitoring Overrides in if one does not exist
4) Press Next until on the Dynamic Members page
5) Press the Create/Edit button
6) In the drop down box choose either “Windows Logical Hardware Component” or “Logical Drive (Server)”. These allow you to select drives based on name or other properties. Press Add
7) In the table change the first Drop Down box to “Display Name” in the third box enter C: Press OK
8) Complete the wizard
9) Repeat to create any other groups for other Drive letters you wish to set separate rules for.