SCOM Servers not “Remotely Manageable”? – Automation

Few posts ago, I blogged on how you can change your manually installed SCOM agents to actually appear as console-deployed. Although this solution is essentially a one time work-around, the solution below is intended for on-going manual installs. The solution below using the same SQL query and creating an automated SQL tasks that runs on a user-defined interval. Following the steps below, you can set this to run every month (or week, or quarter, etc.) and any manually installed will back their “Change Primary Management Server” enabled again.

In my solution below, I was working with SQL Server 2012SP1. This should work for previous iterations of SQL Server as well, 2012, 2008R2, etc.

Following the steps below, and using the SQL query used in a previous POST, you can automate this as well!

 

image001

image002

image003

 

image004

Advertisements

SCOM Servers not “Remotely Manageable”?

Odds are you probably will have some machines where you can’t deploy the SCOM agent via SCOM console, or PowerShell, or some automated way, and you must install and configure the agent manually. Days/weeks/years go by and now you need to decommission that troublesome, manually installed agents Primary Managed Server. You go to the console and right click, and notice you cannot change the machines primary management server.  Well that is because any manually installed agents SCOM/SQL disables this feature. Well, there is a workaround!

Launch SQL and run the following query against the OperationsManager database to get a list of all manually installed servers:

select bme.DisplayName from MT_HealthService mths
INNER JOIN BaseManagedEntity bme on bme.BaseManagedEntityId = mths.BaseManagedEntityId
where IsManuallyInstalled = 1

Now that you have determined which servers were manually installed, to re-enable the remotely manageable feature, run the following SQL query (against the OpsMgr DB).

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1

You should note, this will re-enable this feature for all servers.

Now you should be able to change your machine or any manually installed machines primary management server!

 

Happy SCOM’ing =)

SCOM 2012R2 IIS Prerequisites

If you’re like me, a System Center Operations Manager consultant, then I am sure you have already ‘googled’ this a few times by now. I constantly find myself looking this up, so I figured I would write my very own blog post on this.

It should be noted, the following code below was found on various sites, and I have now pieced it together to suite my own needs.

For starters, when installing SCOM 2012R2 and its Web Console, you are required to meet certain IIS prerequisites. You can either do Option 1, the manual way, or Option 2, the PowerShell way.

If you go with Option 1, you will need to install the following IIS features:

  • Static Content
  • Default Document
  • Directory Browsing
  • HTTP Errors
  • HTTP Logging
  • Request Monitor
  • Request Filtering
  • Static Content Compression
  • Web Server (IIS) Support
  • IIS 6 Metabase Compatibility
  • ASP.NET
  • Windows Authentication

Or, Option 2, you can use PowerShell to automate this for you…. (Note, you will need to launch PowerShell console as an Administrator)

Import-Module ServerManager
Add-WindowsFeature NET-Framework-Core,AS-HTTP-Activation,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering,Web-Stat-Compression,AS-Web-Support,Web-Metabase,Web-Asp-Net,Web-Windows-Auth –restart

scom preq PS capture RT

Pesky UNIX/Linux SCOM Agents (Gray State) – RETURN CODE: 1

This is a post I was meant to post quite some time ago, but forgot. Nevertheless…

If you have administrated a SCOM environment with both Wintel and UNIX/Linux machines, I am betting you have experienced some gray agents, specifically for UNIX/Linux machines.

The issue was, the server was definitely online, however according the SCOM, the server was offline or at least in a gray state. Below are the steps below I took resolve the gray agent for the machine, the server was Red Hat (RHEL) 6.x.


Steps to diagnose the issue:

  1. Could I ping the server from any of the SCOM management servers? Yes.
  2. Could I ping the server from its resource pool? Yes.
  3. Was there communication between ports 22 and 1270? Yes.
  4. Was I able to establish a Putty session via port 22? Yes.
  5. Was the SCOM process running on the server? Hmm, that’s a funny error…

1


Next are the steps I took to resolve the issue:

  1. Restart SCOM process, “sxcadmin” … Cannot, “RETURN CODE: 1”
  2. Googling, many members in the community have also had this error, and have isolated the issue to a corrupted CIM.Socket and SCX-CMID.PID file(s).
  3. Delete the files:

2

4. Let’s restart the SCX Agent…

3

5. Well that did not work either, check to see if port 1270 is evening listening…

4

6. Okay, let’s kill all processes associated scxadmin service…

5

7. Now let’s start the scxadmin process, and check again to see if port 1270 is listening…

6

8. Perfect! And what does SCOM say?

7

 

Problem solved! There are ways to automate this process, and this was achieved with the use of SCORCH and Runbooks. I will post that solution soon. Stay tuned.

 

Happy SCOM’ing! =)

(more…)

Creating certificates for Azure authorization

So let’s say you want monitor your Azure environment using your on-premises SCOM, you would think all you need is an Azure environment and an Azure Management Pack and SCOM. Well for the most part that is true, but to authenticate Azure and SCOM, you will require a certificated based authentication to bind the two environments. For starters, you will need the tools below, and can follow the steps I have outlined below.

Prerequisites

  1. Azure subscription
  2. Azure (SCOM) Management Pack
  3. Local SCOM environment (with Internet access)
  4. Windows 8.1 SDK or Visual Studio

I used my Windows 8.1 machine, therefore I needed the Windows 8 SDK. If you do not already have the SDK, it can be downloaded from HERE. Once you have installed the SDK, we will then need to create the certificate.

I used PowerShell, but you could probably use Command Prompt just as well. Please note, run as Administrator.

First browse to the SDK directory, “C:\Program Files (x86)\Windows Kits\8.1\bin\x86

1

Then, using the following code below, this will create a self-signed certificate. Please note, your certificate name should match in both places here.

makecert -sky exchange -r -n "CN=yourCERTnameHERE" -pe -a sha1 -len 2048 -ss My "yourCERTnameHERE.cer"

2

Now, I don’t know what all these switches meant so I did look it up. Also, I used the links below as reference:

If the step above, you should have got “Succeeded”.

Next, we will generate the PFX with a private key. Use the code below in squence, again in Administrator mode, PowerShell or Command Prompt.

$MyPwd = ConvertTo-SecureString -String "yourPASSWORDhere" -Force –AsPlainText

$AzureCert = Get-ChildItem -Path Cert:\CurrentUser\My | where {$_.Subject -match "yourCERTnameHERE”}

Export-PfxCertificate -FilePath C:\yourCERTnameHERE.pfx -Password $MyPwd -Cert $AzureCert

 

3

If all went well, you can now import your PFX certificate. Go into the Certificate Store (launch MMC services, add the Certificate snap-in, run as Local Computer), and right click on Personal > Certificates > Import. Browse to your *.pfx certificate and import. You will be required for the Private Key (password to complete).

If all went well you should now be able to see the certificate within your Certificate Store, under Personal.

6

Now, Azure will want a *.cer based certificate, so we will now need to export our *.pfx certificate from the Certificate Store. This is pretty straight forward, export on the certificate, and save as a *.cer file.

Once you have export the PFX as a CER file, you can now go back to Azure, and import/upload the certificate we have just created!

7

Configuring Office 365 (O365) Management Pack in SCOM

For starters, I am assuming you have a valid Office 365 account, a SCOM environment (with Internet access), and the Office 365 Management Pack.

Once you have imported the MP, next within the Administrations tab, you will need to add your O365 subscription. I used the “All Management Servers Resource Pool” for my Server Pool.

1

2

Once successful, you should have your Office 365 Subscription within the Office 365 Overview:

3

If you go back to the Monitoring tab, you should now see the Office 365 folder along with some native views.

5

 

I went a step further and added the, “Message Center” webpage, same view you would see within an browser.

I copied the two views from the MP into My Workspace, and added a new Web Page view, with the URL here, https://portal.office.com/MessageCenter/MessageCenter.aspx.

When you launch the view the first time, you will be required to sign-in. I also check marked “stay logged in” to avoid this down the road.

6

7

8

 

And that is it! Pretty easy!

Azure Runbook Limitiation

Here I am testing my Runbooks in my Azure lab, and all of a sudden I get the following alert, “The job failed. The quota for the monthly total job run time has been reached for this subscription. To get more job run time you can change to a different Automation plan or wait until next month when the quota will reset.

Whaaaaat!!?

1

Well that sucks… I don’t wait to wait another month! And I certainly do not want to upgrade my Azure subscription plan.

I contact Microsoft, and they advised me the same, I will need to either wait until next month, or upgrade my subscription plan.

“…using a Free account, then it is limited to 500 job minutes per calendar month. You can change to the Basic pricing tier and get unlimited job minutes for just $0.002 / minute.”

Turns out, with the Free account, I am limited to 500 job (Runbook) minutes per calendar month. If I upgrade then I get unlimited job minutes, but at a cost of $0.002 per minute.

Well this is certainly good to know, also good to know, when creating Runbooks, we should code efficiently, otherwise our 500 minutes will but gone soon. =)

Thanks to Chris Sanders, Program Manager @ Microsoft for the helpful information!