SCOM 1807 Universal Linux Monitoring

Recently discovered that some of the CentOS boxes that I've pushed the agent into came up as “Version Unknown” at the UNIX/Linux Computers within the Administration space in the SCOM console.

Checking further, there’s no monitoring data for the usual CPU / Memory / Logical Disk and Network from the servers.

Did a bit of troubleshooting and realized that from the “Microsoft System Center 1807 MP for UNIX and Linux” downloaded here, it seems to be missing the “Microsoft.Linux.Universal.Monitoring.mp”

Once imported the relevant mp from the SCOM 1801 media (notice the version difference), all started to work again

Monitoring SNMP v1 Trap

Creating a post on some work I'd done couple of year ago so that it won’t be forgotten.

I know SNMPv1 is definitely obsolete by now but what if there are still some requirements to monitor SNMPv1 traps with SCOM ?

One of the way is to

1. Create a custom MP on the trap you are going monitor with SCOM
2. Export that custom MP as an XML
3. Within the XML file, locate the version tag (<version>…</version>)
4. Replace the string within the tag to 1, refer samples below

Before

After

and that should do the trick

SCCM 2012 R2 Clients failed downloading content

Was required to manage clients in untrusted domain in a recent SCCM deployment and one of pilot machine (Windows 7) was not able to have the published app successfully installed, while the other got installed successfully.

Checking on the DataTransferService.log, it includes log saying “DAV request. HTTP code 401, status 'Unauthorized'”

Checked and verified that the network access account for SCCM has been configured and there’s no firewall restriction between the client and SCCM server.

Googled around and found out that KB2522623 might be able to fix the problem, and it really did once the patch was applied.

SCOM Run As Account - Specific Cast Is Not Valid

Got the following error when i tried to add new servers into my SQL MP RunaAs account distribution

Once you click “Close”, you won’t get to see any other computers which this run as account has been distributed previously.

Well, the cause of this is actually due to agents are manually removed from the “Agent Managed” within the SCOM console, but without cleaning up the distribution of the RunAs Account.

In order to resolve this, i had deleted the specific entry from the OperationsManager database based on the solution found in http://www.ssistalk.com/2014/03/03/scom-2012-r2-specified-cast-is-not-valid-error/ 

Once done, the server which this account is distributed is visible again

p/s: updating the data directly in SCOM databases might impact the supportability from Microsoft. So do it at your own risk

Agent Installation Error (Error Code : 80072971)

At times,we might experience another frequently seen error as below, where the agent management task status displays something like “….failed to acquire lock to remote computer….”

 

This is due to when SCOM agent is pushed from the SCOM Management Server, the MS will first copy the install (& the patches) to the target machine at c:\windows\422C3AB1-32E0-4411-BF66-A84FEEFCC8E2 folder, and if you managed to browse to the folder,there should be a file named LockTimeFile. This file is to determine which SCOM MS is attending the target server at the moment.

By default, once the installation is completed, the folder will be automatically deleted when the installation completes, however there is changes that the folder / files are not successfully removed.

In order to resolve this, one of the way is to delete the LockTimeFile and the SCOM agent was successfully installed

SCOM SharePoint 2010 MP troubleshooting

Encountered the following error message in SCOM event viewer for one of the SharePoint 2010 servers. Searching around the net, found 2 links with valuable information on resolving it.

http://www.scom2k7.com/advanced-troubleshooting-of-the-sharepoint-2010-mp/

http://thoughtsonopsmgr.blogspot.com.au/2013/04/troubleshooting-sharepoint-server-2013.html

Basically it seemed might have to do with PowerShell 3.0 (for Sharepoint 2010), and one of the solution was to uninstall the PowerShell 3.0, but before doing so, you might want to verify it further by granting the SCOM SharePoint MP account to have SP farm admin rights, to see if it is able to launch the SP cmdlets.

Hope this helps :)

Agent Installation Error (Error Code :80004005)

Faced a problem recently when trying to upgrade the version of the SCOM agent to the latest 2012 R2.
Error message is similar to the below
The Operations Manager Server could not execute WMI Query "Select * from Win32_Environment where NAME='PROCESSOR_ARCHITECTURE'"
Operation: Agent Install
Install account: <SCOM runAs>
Error Code: 80004005
Error Description: Unspecified error This is due the 'PROCESSOR_ARCHITECTURE' variable, does not return a value, which causes agent push to failed. (the manual installation seemed to work though) Checking on the web and it does not seemed to have a permanent solution, however, there is a workaround which should help to complete the agent installation via push method. Many thanks to stefanroth.net for such sharing

Exchange MP and PowerShell 2.0

Normally after you imported the Management Pack, once all the discoveries had completed, you will begin to see the health status begin to appear in the SCOM console, following by SCOM periodically executing the scripts defined within the MP to capture performance data and this includes the Exchange MP.

In a particular assignment, after the Exchange 2007 MP has been imported, servers with the Exchange roles are successfully discovered, but lacking on certain information and one of the them is the number of mailbox for each of the mailbox servers. At first i thought it might be due to MS is still collecting the data but after some time (or even days) the value is still not out yet.

With the help from the SCOM guru and checking on the mailbox servers, only we found that there are quite a number of errors in the OperationsManager event log, with the following message.

Checked further from the net only to deduce that the servers hosting the Exchange roles (which is running on windows server 2003) needs to be installed with PowerShell 2.0. Fortunately there is a DR server which we can try to prove our point. Once PowerShell 2.0 was installed, things just started to work as expected.

Error in installing additional SCOM Management Server

Not to say an expert, even though I had been working with SCOM for quite some time, error below was the first time I encountered during a recent engagement. Error below occurred when I tried to install a third SCOM management server which was totally unexpected, since the installation for the first and the second MS was done successfully without much hiccup.

Tried to repeat the installation again but the failure rate was 100%. Check out the internet and it seems that this might have something to do with the SQL connection time out, while the installation was trying to connect to the SCOM DB server to register the new Management Server.

One of the way you could possibly try is to extend the duration before the connection is timed out, and this requires updating the registry key of the server before the installation is re-started. Following will be the key that needs to be created.

Once created, reboot the server and try to reinstall the SCOM Management Server again. It should work this time (well at least it worked for me )

note: one thing to take note about before you reinstall the MS is that, you must remove that particular server from the management server list via the Operations Console. If not, you will not able to select the OpsMgr database during the MS installation.

SCOM Installation Headache !!! (pt.2)

In my previous post, I was not able to test out the kb974886 hotfix since I was not able to reproduce the error in my lab environment. Well as of today, I got the luxury of simulating the problem using a live data.

A few things to keep note before applying the fix in the DC is that, firstly it is better for you to check out the version of the samsrv.dll file in the DC (under %systemroot%\system32 directory.) The current version should be less than 5.2.3790.4250.

Next, proceed to install the hotfix. Installing the hotfix should be straight forward whereby the installation wizard will leave you an option “not to reboot the server” after the installation completes. But if you do no check this option, the wizard will automatically reboots your DC, once the installation completes.

When the DC is back online, you may check the version number of the samsrv.dll again. By this time, the version number should be 5.2.3790.4250.

Now, proceed with the SCOM installation. At first you might be hitting the same old authentication problem again, when the SCOM installation wizard prompts you for the SCOM action account credential. If you have the similar experience, what you need to do is to relogin to the SCOM server again and re-initiate the SCOM installation. By this time, your credential should be successfully authenticated.

The same goes to other SCOM servers, if you are installing the components in different servers.

SCOM Installation Headache !!!

I am now slowly picking up my SCOM skills and what i can say is that, it never fails to surprise me each time , where chances are, you might get stuck in the simplest thing you can imagine.

In another posting which i was supposed to implement SCOM 2012 infrastructure, installation of the SCOM servers should be straight forward, but in end, it took me almost 3 days to find out what’s wrong. I got hit by the error below.

With the error message like this, you might think that it is probably due to incorrect passwords or the length of the password might be a bit too long. Had made sure that the passwords are correct and even reduce its length for testing. In the end it still won’t work.
Sensing something is not very right, i opened up the SCOM installation logs located in  “C:\users\<SCOM installation account>\AppData\Local\SCOM\LOGS” , which shows you the below

Open up the “OpsMgrSetupWizard”, try to see if the following entries are logged,

If it is, chances are you might want to check with your client to see if there was any “Authoritative Restore” done to their AD recently.
You may want to refer to this kb974886 article. Since i was not able to re-produce the problem in the lab environment, i am not able to comment if this hotfix does resolve the issue. If anyone of you out there who had the similar problem as mine and tested this hotfix, appreciate your valuable comments.
The reason why it took me a while before realizing this was because there isn’t much documentation on this, and I've decide to make a post for this so that this could be for reference in the future.