WMI Warnings when Querying Services

If you've had SCOM running for a bit, you may have noticed a number of WMI warnings, similar to this:

Object enumeration failed

Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "Print Services"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "MSSQL$MGT"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "CLusSvc"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "MSSQL$RCT"

The following Microsoft article provides a foundation for one solution to this issue:
http://support.microsoft.com/kb/2590230

Basically, the Windows Management Instrumentation files (*.mof) have the encryption flag turned on. This is not necessarily the case for all servers. For example, out of 100 servers, 10 exhibited this behavior.

To check on the accessibility of wmi from a remote machine, I connected with the Scriptomatic tool, changing the "WMI Source" to the remote system. When I attempted to do so, the application would error out and a warning would be logged on the remote server as to the offending WMI class.

I had to walk through several classes, repeating the steps in the microsoft article each time. I found, in most cases, the encryption flag had to be set to false in the following files:

C:\Windows\System32\WBEM\win32_tpm.mof
C:\Windows\System32\WBEM\Tscfgwmi.mof
C:\Windows\System32\WBEM\ServiceModel.mof
C:\Windows\System32\WBEM\IISwmi.mof
C:\Windows\System32\InetSrv\WebAdministration.mof
C:\Windows\SysWow64\InetSrv\WebAdministration.mof

After setting the encryption flags to FALSE and recompiling the mof files, I was able to successfully connect to the remote system via Scriptomatic and consequently, the warnings subsided in SCOM as well.

In case the Microsoft Article disappears, the steps are as follows:

1. Open C:\Windows\system32\wbem\.mof for editing and set [RequiresEncryption(FALSE)]
2. Recompile the .mof file by running "mofcomp C:\Windows\system32\wbem\.mof"
3. Restart the winmgmt service

You may have to adjust security on those files in order to make changes in them. They are typically owned by the System or TrustedInstaller and not able to be directly written into.

Adding Red Hat Agents to SCOM 2007

Ok, ok... this is supposed to be all about SCOM 2012. Well, came across a situation with 2007 and there was enough complexity that I wanted to make sure I got it all in one place.

• Similar to the 2012 install, load the appropriate linux agent to the system and install the rpm package.


• Ensure you have the management packs installed in SCOM 2007, usually the Linux and Unix libraries along with the Linux flavors you wan to monitor.


• Now, attempt to discover the Linux computer, enable SSH discover and use the FQDN of the Linux system.


• You will likely receive a certificate signing error. If that is the case, check out the Microsoft Wiki entry on the issue:


• https://social.technet.microsoft.com/wiki/contents/articles/6203.aspx


• Run through the discovery and installation again.


• Things are likely to fail, again


• Now look at the article:


• http://operatingquadrant.com/2012/01/12/opsmgr-unixlinux-heartbeat-failures-after-applying-kb2585542/


• Alternatively, you can add the 32bit DWORD value:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ SendExtraRecord = 2


• The agent should pop into monitoring console at this point. If not, run the discover for a third time.


• Finally, check your ops manager event logs. You may be getting errors about the health service or workflow on the Linux system. Check out the following article for configuring cross platform runas accounts:


• http://technet.microsoft.com/en-us/library/dd788981.aspx

Windows 2008 Core Installation - Change Computer Name

Number of examples out there for how to change a computer name, however, the commands leave something out.

You will see examples of netdom renamecomputer /newname:**new computer name**

Give that a shot, you should see an error along the lines of "The parameter /NewName was unexpected"

The proper format of the command is as follows:

netdom renamecomputer **old computer name** /NewName: **new computer name**

An easy way in the core installation to get your computer name is simply run:
ipconfig /all or hostname

Adding Red Hat Linux 5 client to SCOM 2012

This was a painful, painful journey with a number of obscure errors that turned out to be canards. The first thing to know about adding a Linux client is that your chances of a successful install, straight from the management console are not high. Each and every time on simple test environments, the agent failed during my tests. I could not have made the Linux install more plain than I did. So, start from that perspective. I have embeded a short video of the process I went through. My suggested steps are as follows:

• For your Linux/Unix distro, copy the appropriate rpm package over to your system as step one. I used WinSCP to accomplish this task.



• Go ahead and install the package and then reboot your system



• Check DNS for both forward and reverse records of your Linux/Unix system. If those don't match, you will get certificate errors and start off on a wild goose chase that has nothing to do with certificates.



• Ensure the hostname (hit a terminal window and simply type: hostname) is the same as the records you have in dns.



• Make sure the reverse record has the fully qualified domain name and not just the host name. When my system first came online, it registerd just the host name, and then the FQDN. With both records in DNS, it really confused SCOM.



• Once these points are completed, the agent should install with a high degree of success probability.



• During installation, I would highly recommend adding hosts individually and search for them via FQDN, not IP address. It wasn't until I did this that the error messages pointed me to the correct problem.



• If you do have to make DNS adjustment, ensure you run ipconfig /flushdns on your SCOM server. I also fought with this. Eventhough records were correct, the server still saw the old entries.

• Updated, Oct. 30, 2013 - Had a number of problems adding several old Linux servers recently. Received the errors shown in yellow in this post. The local host name on the Linux server had a different domain address than we thought it did. Adding the server with the old domain name was successful. Alternatively, we could have updated that information locally, but was not an option for us at the time.

If your DNS records are not correct, you may get errors such as these. Check DNS first before checking certificates. There are a lot of examples out there that will lead you farther from the solution if you don't check DNS first.

DNS resolution

Removing SCOM 2012 Management Packs Through Powershell

I got a little overzealous in importing management packs and found myself with a number of management packs that I did not want in my library. Going through one by one and selecting delete from the management window was going to be a nightmare. Enclosed is a powershell script I found and used to remove the various packs I imported. In this case, the management packs had country code extensions, such as .RUS or .KOR, that I didn't need for my installation. I will say, while this reduces the manual nightmare, the process takes exceptionally long, especially when using multiple search strings.

http://technet.microsoft.com/en-us/library/hh545200.aspx

Get-SCManagementPack ?{ $_.name -match ".RUS" } Remove-SCOMManagementPack

In some cases, you might want to delete multiple types of management packs. I've included an example of one using the "logical or" operation.

Get-SCManagementPack ?{ $_.name -match ".CHT" -or ".JPN" } Remove-SCOMManagementPack

Grayed Out Domain Controllers in SCOM 2012

Had a chance to revisit a post for Operations Manager 2007:

http://thoughtsonopsmgr.blogspot.com/2009/09/hslockdown-explained.html

This issue still crops up in Operations Manager 2012. However, I experienced a little twist. In Marnix's post, the "NT Authority\System" account was denied. What I noticed was that the account simply wasn't there at all. In the environment, there were two domain controllers, running Windows 2008 R2 64-bit and both showed up gray after installation of the agent.

Logging into the domain controllers, I ran the HSLockdown tool, adding the local system account as follows:

Browse out to the agent folder in \Program Files\System Center Operations Manager\Agent

Run HSLockdown /L to show the account status. Notice in my example that local system is missing.

Run HSLockdown /A "NT AUTHORITY\SYSTEM" to add the local system account.