How to create a Recovery task in SCOM on a windows service.

When you have the requirement to monitor a windows service through Microsoft’s System Center Operations Manger and have it restarted automatically you can not use the management pack templates. The reason for this is that the templates are stored in locked MP’s that you do not have access too.
Follow the following steps to monitor a service and have it restarted automatically by SCOM if it fails.


Steps

Create a management pack to store the monitor in

Create a group that the monitor will be applied against

Create a monitor that watches the service

Create overrides (apply to group)

Create the recovery task

Step 1: Create the Management Pack

In the managment console under Administration right click on Management Packs and select “Create Management Pack”. Give this new MP a meaningfull name and continue.



Step 2: Create the Group

• In the Authoring Pane right click on “create new group” Give this new group a meaningful name. A description. And select the management pack that you created.

Important: Do not use the default management pack. You can do it. But this will create problems when trying to remove MP in the future. Always use Custom MP’s.

• Say next. Click on Add/remove objects on the Explicit Group Members. Enter a server name and search. Select your computer object and say ok. You can now add dynamic and exclusions. I am not going into that on this post so except all defaults.

Step 3: Create the Monitor

• In the Authoring Pane right click on monitors and select Create a monitor, then Unit Monitor.

• Expand Windows Services, and select “Basic Service Monitor”. Select the custom management pack.

• Provide a name for the monitor. I am going to create this monitor to watch Windows Update services. Select the monitor target as windows Server Operating System. Select the Parent Monitor as Availability.

• Next Browse to the server, or any server with the service running. and select the service.

• The next window shows how the monitor sees the health state. Accept the default.

• The last window is how the alerts are configured.

• uncheck the “Generate alerts for this monitor:” for now. This will prevent any unwanted alerts until we are ready.

Step 4: Apply to group
Lets apply this MP against the group that we created earlier and disable it for all other servers.
Fist disable the rule for all servers

• Find the new rule under Authoring\monitors. The easiest way to do this is to change your scope. Click on the Change scope in the top right corner
• Look for windows server operating System and select it and say ok.

• Expand the monitor, right click on it and select properties.

• Select Disable and “For all objects of type: windows Server Operating System”

• Next Right click on the same monitor and select override, Override the Monitor, for a group

• Start to type the name of the group you created and select it.
  
• Place a check beside “Parameter name”. Change the override setting to True. This will enable the rule for the group.

• Say OK to save.

STEP 5: Create Recovery Task

• In the Authoring Pane right click on monitors and select the monitor you created by right clicking on it and select properties.
• Click on the Diagnostic and Recovery Tab
• Under the configure recovery Tasks select Add… and choose “Recovery for Critical Health State”
  
• Select Run command
• Provide a meaningful name and description
• Select the recovery target as Windows server operating system
• Check run recovery automatically and recalculate monitor state.

• Next, for the full path to the file type C:\WINDOWS\system32\net.exe This will spawn the net command
• for the parameters type start service name. We are starting windows update service. Here is the best way to find the service name. Open services by opening the run box and type services.msc

• now that you have the actual service name lets enter it in the parameters field. so you would type “Start wuauserv”

• Once you have clicked on create you are done.

How to create a SCOM Windows Events Monitor and alert on the Description field

When creating a monitor that alerts on event logs you may want to be able to monitor based on key words in the description field. This is not a default parmater and needs a few extra steps. But is still very easy to accomplish once you now the steps.
here are the two variables you will be adding to the monitor
parameter name: EventDescription
Alert description: $Data/EventDescription$


1. When you are creating the Event Expression click on insert, then click on button “…: under parameter name
2. Select Use Parameter Name not specified above and enter EventDescription

$Data/EventDescription$

Select an Event Property-EventDescription

3. change your operator to Contains
4. under the Value, enter the words you want to find in the desction field.

Build Event Expresion - operator and value

THIS IS NOT DONE!!!!

5. Continue to build your rule until you arrive at the Configure Alerts page. Enter the value $Data/EventDescription$ in the Alert description window. If you do not you will receive errors.

6. Create the rule, and refresh how ever you like. When i am in a hurry i will restart the health service on the server that I am monitoring.
7. To test your rule the OpsMgr Event Creator tool is not going to work. It does not allow you to create custom descriptions. Log onto the server that you want to monitor and open a command window. Using the eventcreate command type the following

eventcreate /t error /ID 1000/d “fieldxu.exe THIS IS JUST A TEST BY Brad Hearn”
/t sets as an error
/ID is the event id
/d is what will be placed into the description field. Remeber to place quotes around your text.

The alerts will look something like this.

Hope this helps out.

Out of date Hardware Inventory sms

Here is a query to create a collection of computers (last hardware scan > 60 days ) that haven't had there HW inventory updated in 60 days, you can change this to what ever time period you want. This will work on both SCCM or SMS

---------------------------------------------
select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,
SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,
SMS_R_System.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Name not in (select SMS_R_System.Name from SMS_R_System inner join SMS_G_System_WORKSTATION_STATUS on SMS_G_System_WORKSTATION_STATUS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_WORKSTATION_STATUS.LastHardwareScan >= DateAdd(dd,-60,GetDate()) )
-----------------------
You could also add a query to this collection to pull all computers with no SMS client then you have all your comptuers in one collection to work with. You could force HW scans on the collection, force Client installs or whatever maintenance you need.

Using certificates SCOM

CA Server – We have a single stand-alone CA server, which only purpose is to create certificates for the SCOM 2007 environment. The root CA is called JAMA00.
Requesting a certificate – From the target server (running the agent), we have no access to the CA server’s web interface. Therefore we must manually generate a certificate request and upload this request to a central file share.


Creating a certificate – We have automated the process of picking up the certificate requests (from the central file share) and generating a certificate file. We also generate an executable installer file, which will install the newly generated certificate on the target server and will configure SCOM to use this certificate for communication with our environment.
Importing a certificate – We support several ways for importing the certificate at the target server. This can be done before, during or after the SCOM agent has been manually installed (as long as our scripted version of the manual installation is used).

---

CA Server – Default a certificate issued by a CA is valid for one year. To prevent us from replacing all certificates after a year we have changed the configuration, so certificates are valid for a period of 100 years. See this Microsoft article on how to make these settings:

But since a certificate can not surpass the lifetime of the root CA, we have also set the expiration date of the root CA certificate to 100 years:

So effectively, all certificates are valid until the expiration date of the root CA certificate.

---

Requesting a certificate – To request a certificate, the certreq.exe application must be available on the system. This is default the case for all versions of Windows, with the exception of Windows 2000.
Remember that we do not have access to the web interface of the CA server, so we make a manual request from the command line.
The certreq.exe must be supplied with a file which describes the required certificate for which a request file must be generated. This file should contain this information:

[Version]
Signature= "$Windows NT$"
[NewRequest]
Subject = "CN="
KeySpec = 1
KeyLength = 1024
KeyUsage = 0xa0
ProviderName = "Microsoft RSA Schannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
Exportable = TRUE
MachineKeySet = TRUE
UseExistingKeySet = FALSE
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1
OID = 1.3.6.1.5.5.7.3.2

must be the FQDN of the server when it is a domain member or the computer name when it is a workgroup server.
It is possible to set the value for “Exportable” to “FALSE”, so the private key is no longer exportable. However Microsoft states that the private key must be exportable (I don’t know why).
When we name this file: certreq.inf, the command to generate a certificate request file will become:

certreq -new -q -f certreq.inf certificate.req

This will generate a request file called: “certificate.req”
We have scripted all of these steps and made sure that the actual name of the request file is set to the FQDN of the computer generating the request. This will prevent any duplicate name issues when copying the request file to the shared location. So in general terms we execute:

certreq –new –q –f certreq.inf .req

And here the part is the FQDN of the computer (or the computer name for workgroup computers). So we now have a certificate request file, which name is unique in the SCOM environment.
This certificate request file can now be placed on the central file share.

---

Creating a certificate – After the certificate request file has been placed on the central file share, the request file will be processed by a script to generate the required certificate file for the target server.
To generate a valid certificate, the following steps are performed:

 Submit the request

To submit the request, the following command is given on the CA server:

certreq -submit -q -config ""

Where equals the FQDN of the CA server and is the request file from the target server.
This command will pass back an Id, which we can use in the next step of processing the certificate request. The certificate is now in the pending state and must be issued before it can be used.

Issue the request

To issue the request, the following command is given on the CA server:

certutil -resubmit

Here is the Id that was passed back from the submit command in the previous step. When completed, the certificate is issued and ready for use. We can now retrieve the certificate and use it at the target server.

Retrieve the certificate

To retrieve the request, the following command is given on the CA server:

certreq -retrieve -q -config "”

Again the equals the FQDN of the CA server, the equals the Id that was passed back from the first step and is the name for the retrieved certificate.
So when all is finished, we have a certificate file called , which can be imported on the target server that generated the certificate request file.
To make life easier we gave the final the same name as the FQDN of the target server, followed with the .cer extension.
So if a server is called “server01.company.local”, the final certificate file that is generated is called “server01.company.local.cer”.

Importing the certificate

To import the certificate, the newly generated certificate must be “accepted” by the machine that generated the certificate request. The following command is given on the target server:

certreq.exe -accept –q “"

This command will make the certificate file available for use on the target machine. Again, is the certificate file generated in the previous step.

Configuring SCOM agent

The final step in this process is to configure the SCOM agent to use this certificate for communication with the SCOM management servers. To do this, this command is given on the target server:

MOMCertImport.exe /SubjectName

Here is the FQDN of the target server and this should be equal to the FQDN used in the certificate.
After a restart of the SCOM agent, the agent will start communicating with the management servers, using the certificate.

Certificate installer package

When the certificate request is generated on the CA server, we also package this certificate file into an installer executable, which contains the certificate and a script that will accept this certificate on the local server and instruct the SCOM agent to start communicating, using this certificate (combining the import and configuring steps mentioned above).

---

The root CA certificate – Now this all works great, as long as both the agent and the management servers use a certificate generated by the same CA and do trust this CA.
The management servers are given a correct certificate and the root CA certificate during installation of the management server.
The target servers (running the agents) must also have the correct root CA certificate in the “Trusted Root Certification Authorities” in the local computer store.

We have completely scripted the (manual) installation of the agent and part of this script is the import of the root CA certificate in the “Trusted Root Certification Authorities” of the local computer.
This is done by running this command on the target server

certutil.exe –addstore root

The must be replaced with the root CA certificate file (JAMA00.cer in our case), which holds the root CA certificate.