The other day I needed to configure a web application check against a web service in a DMZ. This DMZ had its own Active Directory domain with no trust or connection to the internal domain where Operations Manager was installed. One of the criteria of the web application monitoring was to verify that we could log on to the web service. We ran into a challenge when configure the run as account for the web service. Operations Manager is trying to verify the account, as we didn’t have a trust or any connection to the DMZ domain that was not possible. We tried to override only for this account on the watch node, but unfortunately it was all account checks or none.

After some investigation we found that the event generated on the agent (the watch node in this case) included the account that did pass the check.

The solution to this was to disable the monitor for the watch node, then create a new monitor only for the watch node with the same criteria, but with one extra criteria, not to include events where event description includes LITWARE\Administrator. LITWARE\Administrator was the account that we didn’t want an alert on.

I read a question this week about presenting a state based on if a service account was logged on to a machine or not. There are a couple of different ways to do that. We will need a monitor in both of them, as we want to present a state. You could solve it with a monitor running a script, checking current logged on users. You could also solve it with a monitor checking log-on and log-out events.

If you want to do it with two events and running server 2008 you could look at even 4624 (an account was successfully logged on) and 4647 (User initiated log-off). To configure a monitor like that you follow the steps below. This example will configure a monitor to generate an alert if not the CONTOSO\svc-contoso-service account is logged on.

1. In the console, navigate to Authoring/Management Pack Objects
2. Right-click monitors and create a new Simple Event Detection/Windows Event Reset monitor
3. Choose a suitable management pack, not the default management pack. Click Next
4. Input a name, a target and choose a parent monitor. Click Next
5. Event Log (Unhealthy Event). Select Security as event log name. Click Next
6. Event Expression (Unhealthy Event). Select Event ID equals 4647 and EventDescription Contains CONTOSO\svc-contoso-service. Click Next
   
7. Event Log (Healthy Event). Select Security as event log name. Click Next
8. Event Expression (Healthy Event). Select Event ID equals 4624 and EventDescription Contains CONTOSO\svc-contoso-service. Click Next
9. Configure Health. Click Next
10. Configure Alert. Check the “Generate alerts for this monitor” check box. Click Create

By default this new monitor will be forced to healthy state first. This mean we will not get an alert until the account log off. In other words, if there is a machine where this account is not logged on right now, Operations Manager will not notice it. It is only looking for the log-in and log-off event. To generate an alert we first need to log-on with the account, in this example CONTOSO\svc-contoso-service, then log-out again. The monitor will then go into unhealthy state.





The second way to solve this is with a script. To configure a monitor like that you follow the steps below

1. In the console, navigate to Authoring/Management Pack Objects
2. Right-click monitors and create a new Scripting/Generic/Timed Script Two State Monitor
3. Choose a suitable management pack, not the default management pack. Click Next
4. Input a name, a target and choose a parent monitor. Click Next
5. Schedule. Configure how often you want the script to run, to see if the account is logged on. Dont configure it to run to often, check your organization requirements. Click Next
6. Script. Input a script name, for example accountcheck.vbs. Paste the script into the script text field. You can download the script here. One of the first lines in the script configure which account to check. Don’t forget to update it. Click Next
7. Unhealthy Expression. Input
   Property[@Name=’Status’] Does not equal OK
   Click Next
8. Healthy Expression. Input
   Property[@Name=’Status’] Equals OK
   Click Next
9. Health. Click Next
10. Configure Alert. Check the “Generate alerts for this monitor” check-box and input a alert description. Click Create

If you need to display the account status in a distributed application it is easiest if you can target the monitor to a new customer class. The health model of the class will then be only this monitor, in other words the class instance health it will only show the status of the account.  

Thanks to Guy Thomas for his script that I adapted.

In this post I will show you how to build a simple task to send a e-mail to the affected user of a incident. The e-mail will be logged in the action log of the incident.Please note that this will not affect how you handle incoming e-mails, it will only give you a fast way to send a e-mail to the affected user.

1. In the SCSM Console, go to Library, check Tasks
2. In the Tasks pane click Create Task
3. Input the following settings in the “Create a task” wizard
4. General
   • Task name: Contoso – Send e-mail to affected user
   • Target class: Incident
5. Categories: Incident Support Group Folder Tasks
6. Command Line
   • Full path to command: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
   • Parameters: .\emailenduser.ps1 Property/WorkItem/ID Property/AffectedUser/Username Property/WorkItem/Title Property/AffectedUser/Firstname
   • Please note that each property is inserted with the “Insert Property” button
   • Check both “Log in action log when this task is run” and “Show output when this task is run”
   • Working Directory: C:\Scripts\
7. Save your new task

As you can see in the task we are using a script here, C:\Scripts\emailenduser.ps1. It is a powershell script that you can download here, emailenduser. Please note that you will need to modify the script to work in your environment, there are some notes about that in the script.

Now, if you select a incident in a incident view you will have a new task in the tasks pane, “Contoso – Send e-mail to affected user”. If you click it you can input a text. This text will be in the e-mail. The e-mail will also add a “Hi affect user name” and “thanks, br service desk…”. Don’t forget to modify that part to in the script.

The operator will see the e-mail and it will also be inserted into the action log of the incident.

In Operations Manager 2007, Audit Collection Services (ACS) provides a means to collect records generated by an audit policy and store them in a centralized database. More info about ACS here.

If you enable ACS gradually or as you install agents it is easy to forget a agent or two. Then you need a view that shows you all agents where you have not enable ACS. I was looking for that kind of view a couple of days ago. Unfortunaly I could not find it so I created it myself instead. My idea was to show all machines where the AdtAgent service, the ACS agent service, is disable. To get this to work we need to do a discovery of a registry value on all machines with a health service. The discovery will tell us the start-up configuration of the AdtAgent service (ACS agent). The result of the discovery will shown as a extra property of the health service.

1. In the Operations Manager console navigate to the Authoring workspace.
2. Expand management pack objects and right-click attributes, select Create a New Attribute
3. In the Create Attribute Wizard, General Properties page, input a name for example Contoso – noACSAgent
4. In the Create Attribute Wizard, Discovery Method page, input
   • Discovery Type: Registry
   • Target: Health Service
   • Management Pack: Select one of your unsealed MPs or create a new MP
5. In the Create Attribute Wizard, input
   • Key or Value Type: Value
   • Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AdtAgent\Start
   • Attribute Type: Int
6. Click Finish to save your new attribute
7. Navigate to the Monitoring workspace, right-click the management pack where you stored the attribute, select create new state view
8. Name the view “Contoso – Agents without ACS” and configure
   • Show data related to: Health Service_Extended
   • with specific Contoso – noACSAgent , configure it with 4 (Show all state with 4 Contoso – noACSAgent) A service configured with startup to 4 means that the service is disable.
9. Click OK to save your new view

This view will now show you all agents with a disabled ACS (AdtAgent) service.

A common questions in the forums is “how to export a list of all agents to Excel?” You can do that with Operations Manager shell. The Operations Manager command shell is built on Windows PowerShell. The Operations Manager command shell extends the Windows command shell with over 80 additional small utility programs, called cmdlets, which can either be run directly from the command shell prompt or called from within a batch file or script. To export a list of all agents and some info about them run the following command

get-agent | select Displayname,InstallTime,InstalledBy,Version | export-csv -notype c:\agents.csv

That will give you a CSV file, C:\agents.csv. Open the file with Excel, select all the data, click the “text to columns” button and choose comma delimeter. That will convert your data into nice columns.

…and there you have your list in Excel with nice columns

With default settings cross-platform agents in Operations Manager 2007 R2 don’t fail-over to another management server if the primary management server goes offline. If the primary management server goes offline you will loose monitoring of all cross-platform machines communicating through that management server. The System Center Cross platform and Interop team blog has a couple of scripts that can help you manage cross-platform machines. One of these scripts is used to to change the current management server monitoring a UNIX/Linux server (or group of UNIX/Linux servers) to a new management server.

But if you move a cross-platform over to another management server you will get an alert like this

A simple explanation to this is that the new management server don’t trust the CA which have issue the certificate that the cross-platform machine is communicating with. You can solve this by copy the certificate from the management server that first discover the cross-platform machine over to the second management server. Store the certificate under Local Computer/Trusted Root Certification Authorities (in the certificates MMC). The certificate is named SCX-Certificate, issued by the primary management server.

When the new management server has the certificate installed it will start communicate with the cross platform machine. You could build a timed script two state monitor to check if the first management server is working, else run the script to move all cross-platform agents.