The question of how to manage the logical disk free space monitor comes up time and time again. Just about every customer I’ve worked with, and all over the forums, people express their disdain for and frustration of managing overrides related to this monitor – and for good reason. It’s one of those monitors that touch every type of logical disk on every computer in the environment, and of course there are going to be different threshold requirements that require overrides – even the out-of-box flexibility of using both types of thresholds (mb and %) usually isn’t enough for us to “set it and forget it”.
This a great opportunity to reduce administrative overhead by enabling local administrators to change monitoring thresholds directly on the local machine, without having to login to the console and create overrides.
Because this is such a popular request, I’ve extended the Logical Disk Free Space monitor and added it to the Windows Monitoring (Extended) community pack.
Download the community pack from GitHub.
NOTE 1 – There are overrides defined in the pack that disable the vendor Logical Disk Free Space unit monitor. Once this pack is installed, that monitor will be replaced by this monitor. If you have overrides applied to the vendor monitors that you want to keep, those will need to be applied to this new unit monitor.
NOTE 2 – The unit monitor works out of the box exactly the same say as the original Logical Disk Free Space unit monitor. It will only behave differently if you implement the extended features of the unit monitor.
NOTE 3 – I chose to target Microsoft.Windows.LogicalDisk because the script data source, according to library documentation, should run fine against all versions of Windows. This reduces it from three monitors to just one.
Product knowledge has also been extended to include usage instructions:
An alert generated by this monitor will look like this:
A state change event (health explorer) for this monitor will look like this:
Last year I helped a customer integrate System Center Operations Manager 2012, BlueStripe (FactFinder), and Savision Live Maps. Contact me if your company is planning to integrate these products – there are several things to consider to get the most out of this integration and make it a huge success.
I developed an enhanced integration pack that was integral in the success of this project. Read more in this case study written by BlueStripe:
(I am not affiliated with BlueStripe or Savision. I consulted on this project through SCOMskills.)
Some companies setup their user accounts and then provide an administrator account, and maybe only the administrator account is a member of the Operations Manager Administrator user role. The Operations Console provides a login screen, so it’s not a problem authenticating to the management group. But the Operations Shell does not provide a login option – it will automatically attempt to login using the context of the current user.
This results in an access denied message:
New-SCOMManagementGroupConnection : The user does not have sufficient permission to perform the operation.
One way to get around this is to use the Powershell Get-Credential cmdlet. Add this to the beginning of administrative scripts or start your console sessions with:
$Credentials = Get-Credential –UserName [domain\username] -Message "Enter password"
$MS = [your management server name]
New-SCOMManagementGroupConnection -ComputerName $MS -Credential $Credentials
I ran into an issue while helping a customer install reporting services. I haven’t seen this problem before, so thought it might be helpful to share with the community.
After installing SQL Reporting Services 2012, and choosing to automatically configure the default instance during the setup process, the main SRS page displayed an error:
“The underlying connection was closed. Could not establish trust relationship for the ssl/tls secure channel.”
Choosing to have the SQL installation wizard to configure SRS automatically has always resulted in success for me until now, so this was a bit disconcerting. Long story short, the issue was fixed by updating the rsreportserver.xml config file SecureConnectionLevel value from 2 to 0. I don’t know why the wizard set this value to 2, assuming SSL would be used, but explicitly disabling this solved the problem in this case.
Additionally, when installing the SCOM Report Server role, the wizard failed after selecting the SRS instance. Removing the SSL bindings completely in the Reporting Services Configuration Management tool solved that problem as well.
I was looking at referrer statistics for this blog, and noticed that many people still arrive here by clicking on a link in the very last blog post from my previous Microsoft Technet blog. It’s been a while since I’ve visited the old blog, but I do actually still refer to it from time to time – and looking at the archive list I noticed that I am coming up on a 7 year anniversary.
That’s right – I cannot believe I’ve been blogging about Operations Manager since December, 2007!
My very first blog post was about a bug in the UI that didn’t add a reference to the management pack. LOL – it can be fun looking back on history sometimes! I get a sense of satisfaction that I have contributed so much to the Operations Manager community – through my blogs, the Technet forums, the Unleashed book, my projects site, etc…
I encourage you all to share your knowledge in your own way, because this body of work is quite literally the first knowledge base anyone will check before pioneering there own solution.