This time I needed to build a two-state script monitor to test several file shares for availability. The script works in multiple steps…
- Try to access the shared folder
- Create a file within the share
- Check if the file exists
- Delete the file
If one of the tests above would fail, we need to get an alert. Well, this is actually not that hard to create and don’t worry I am not going to publish another VBScript. What is more interesting is to create a meaningful alert. It makes sense to have the file share name in the alert name e.g. “Failed to access share \\server01\temp”. But how are we going to achieve this?
During a recent install of SCOM the health state of 4 management servers turned suddenly to critical and the 2 others stayed healthy. The setup consists of totally 6 management servers split up into 3 Resource Pools (Windows, Unix/Linux, Network/SNMP) and several gateway servers. It was somewhat suspicious, because for a long time the management group stayed healthy and didn’t have any issues. The alert I received looked like this…
The interesting part is here…
Run As Profile: Microsoft.SystemCenter.Omonline.OutsideIn.RunAsProfile.Configuration
Account SSID: 007EFD0C5AC560C1B24DF51301135E7F0C415DC48B0000000000000000
This alert tells us, that there must be a Run As Profile which contains a Run As Account that is not distributed to all Health Services, in this case the 4 unhealthy management servers. We get here a pretty go hint as we see the SSID of the account, but not how can find out which Run As account is hiding behind this long number?
I have so many ideas from other products which I would like to blog about, but somehow I get stuck with SCOM all the time, like an addict. Well, today I implemented the SQL Server management pack for a large customer and as you might know you need to configure a Run as account and associate this Run as account with the SQL Server Run As Profiles. If you don’t know what I am talking about, check Kevin Holman’s excellent SQL Server MP capabilities and configuration.
The Run as account is going to be configured with distribution security option More Secure. This results in a problem, that we have to add all Health Service objects to the distribution tab – manually. It is not very sexy to do such tasks manually, that’s why we were blessed with PowerShell.
Ok just to show you what I am talking about. When you don’t add any Health Service (agents) object to the distribution tab of the SQL Run as account, there will be no way for the management pack to use this account to discover or monitor SQL Server via Run As Profile. SCOM will send an alert which informs you, that the discovery did not run because of missing credentials…
Today I had a very cool idea, which I like to share. A customer of mine had trouble with his SQL Server 2008 R2. Because of that, he needed to open SQL Server Management Studio for troubleshooting and then he realized that he was not able to login into SQL server neither with his domain accounts nor with service accounts. The company which installed the SQL Server has simply forgotten to set permission for the SQL Server administrator group correctly and additionally they didn’t write down any of the passwords for service nor SA accounts. There was no way of accessing the SQL Server application at all.
Well, not a very comfortable situation at all, unless you are THE SCOM GUY. What? Yes, THE SCOM GUY. Why? Ok, let me explain. As SCOM guy you probably have already installed the SQL Server management pack and if you remember how the things needed to be setup, then you might know, that up to SQL Server 2008 R2, Local System has full SQL Server access per default. This was needed by the SCOM agent, which runs unsually under Local System to be able, to fully monitor the SQL Server. This information you must know when you need to decided how to setup your RunAs accounts. Check the post from Kevin Holman about the SQL Server management pack about this topic. Because Local System includes the NT AUTHORITY\SYSTEM token, which has sysadmin permission per default, allows you to have unrestricted access to the SQL Server right out of the box.
How does this help? Ok, let’s find a way to get Local System respectively NT AUTHORITY\SYSTEM access. I remembered a tool called psexec from Sysinternals and after some binging I found the correct syntax.
Update: I was just wondering after publishing this quick post during my train ride back from work, if someone else already figured out this kind of “security hole”. Surprisingly I found many blogs about this kind of solution I was not aware of. This of course takes away some coolness of this post .
Today I ran into a problem which is not new to SCOM cross-platform monitoring but since this problem will hit you sooner or later it makes sense to write about it. This issue applies to all SCOM versions.
It could well be that when you are deploying SCOM agents to your UNIX/Linux server you will hit this error dialog…
SCOM uses SSL Certificates to communicate via WS-Management between the SCOM management server and the monitored server. The problem here is, that the server01 just has a “flat” common name (CN) “server01”. In order to authenticate successfully the CN name MUST match the FQDN (fully qualified domain name) of the name that is resolved by SCOM for this server e.g. server01.domain.com.