VMware: Read VirtualCenter Events in MOM 2005

Challenged with a MOM 2005 project, I have been trying to figure out how to get VirtualCenter alerts into MOM.

I didn’t want to address using forwarded SNMP traps, as not everyone seems to compile the VMware MIBs too well.

VirtualCenter 1.x had the ability to run scripts, but it didn’t pass any information. VirtualCenter 2.0.x still runs scripts, but also includes additional information. According to the VirtualCenter help, the following variables can be passed to a script:

{eventDescription} full formatted message for alarm triggering event

{entityName} name of the entity name where the alarm is triggered

{alarmName} name of the alarm that is triggered

{triggeringSummary} summary info of the alarm with triggering values

{declaringSummary} summary info of the alarm declaration

{oldStatus} alarm status before it is triggered

{newStatus} alarm status after it is triggered

{entityObject} inventory object as triggering alarm

Unfortunately, {entityName} and {entityObject} don’t seem to work right now, but you can parse the {eventDescription} to get the object’s name.

So with a little help from a .NET guy here at work, I was off, on my first VB.NET application. To be honest, it looks more like .vbs to me, but put it in VB.NET, and I guess it is VB.NET.

First, well need to compile the application. You can find a copy of it here. You’ll need WinZip, or some other zip application to unzip it.

I’ve included the .exe in the zip, but feel free to delete it and recompile it. (I don’t always trust everyone else’s code).

Here’s the basic contents of the VB application, a file called MakeEventCall.vb, and it includes the following code:

Imports System.Diagnostics

Module MakeEventCall

‘* MomApp.exe – 12/12/06
‘* Jase McCarty
‘* My first VB.NET application for the purpose of
‘* sending VMware VirtualCenter alerts to the
‘* Application Event Log of a VirtualCenter system
‘* that has a Microsoft Operations Manager Agent
‘* installed on it.
‘* This code may be redistributed, but must have
‘* this disclaimer included. Agreement to use
‘* this code, absolves me from any liability.

Sub Main()

‘Variables for doing our work
Dim separators As String = “-“
Dim strIncoming As String = Microsoft.VisualBasic.Command()
Dim argCount As Integer
Dim args() As String = strIncoming.Split(separators.ToCharArray)
Dim MessageOutStart As Integer
Dim strMessageOut As String
Dim strFullMessage As String = strIncoming
Dim strApplicationName As String = “VMware VirtualCenter”
Dim objName As String

‘Variables for our potential input parameters
Dim eventDescription As String
Dim entityName As String
Dim alarmName As String
Dim triggeringSummary As String
Dim declaringSummary As String
Dim oldStatus As String
Dim newStatus As String
Dim entityObject As String

‘Don’t do anything, unless we get at least one argument
If UBound(args) > 0 Then

‘Blank our Output Message
strMessageOut = “”

‘Loop through all our arguments, and process them
‘Each argument should read something like this in
‘the VirtualCenter Alert settings:

‘momapp.exe -ed:{eventdescription} -ns:{newstatus} -an:{alarmname}

‘Where the 2 letter argument prefix matches up with
‘the appropriate event item.

For argCount = 0 To UBound(args)

Select Case Left(args(argCount), 2)
Case “ed”
eventDescription = Right(args(argCount), Len(args(argCount)) – 3)
Case “en”
entityName = Right(args(argCount), Len(args(argCount)) – 3)
Case “an”
alarmName = Right(args(argCount), Len(args(argCount)) – 3)
Case “ts”
triggeringSummary = Right(args(argCount), Len(args(argCount)) – 3)
Case “ds”
declaringSummary = Right(args(argCount), Len(args(argCount)) – 3)
Case “os”
oldStatus = Right(args(argCount), Len(args(argCount)) – 3)
Case “ns”
newStatus = Right(args(argCount), Len(args(argCount)) – 3)
Case “eo”
entityObject = Right(args(argCount), Len(args(argCount)) – 3)
End Select

Dim objEventLog As New EventLog

‘Register the App as an Event Source
If Not objEventLog.SourceExists(strApplicationName) Then
objEventLog.CreateEventSource(strApplicationName, “Application”)
End If

objEventLog.Source = strApplicationName

‘This could be modified to include other information from above
strMessageOut = “Alarm: ” & alarmName & vbCrLf & _
“Event: ” & eventDescription & vbCrLf

‘Include the appropriate warning level. If the -ns:{newstatus}
‘parameter is omitted, an Informational entry will be written to
‘the application log
Select Case Trim(Trim(newStatus))
Case “Green”
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Information)
Case “Yellow”
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Warning)
Case “Red”
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Error)
Case Else
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Information)
End Select

Catch Ex As Exception

End Try

End If

End Sub

End Module

Once you have compiled the app, drop it off somewhere on your VirtualCenter server that is in the path. This will make it easier to run it, and will help with an issue with the “Run A Script” alert function in VC 2.0.x.

When you set it up in VC, it should look something like this:
When an event happens, it will look something like this:
And the individual item will look something like this:

Keep in mind, this is not a complete solution, but more of a starting point to get VC events into MOM 2005.

Additionally, because this application simply writes to the event log, any monitoring software that reads the Application Event Log, will be able to pick up this information.


Read more


Windows: Need to Seize Roles during DR?

In an environment that needs to come up quickly, I found a little trick that can be helpful.

NTDSUTIL.exe lets you manage which domain controllers handle which roles in your domain.

According to kb article 243267, you can script this. So in a DR situation, if you have a virtual DC (in a VM) and you want to have it seize all roles, it can be simple with the following script.

The following script will allow you to seize all roles from a batch file (seizeroles1.bat):
**********BEGIN HERE**********
ntdsutil roles connections “connect to server %1” quit “seize domain naming master” quit quit
ntdsutil roles connections “connect to server %1” quit “seize infrastructure master” quit quit
ntdsutil roles connections “connect to server %1” quit “seize PDC” quit quit
ntdsutil roles connections “connect to server %1” quit “seize RID master” quit quit
ntdsutil roles connections “connect to server %1” quit “seize schema master” quit quit
***********END HERE***********

Save the batch file as seizeroles.bat and call it from a cmd prompt with “seizeroles.bat servername.domain”

Additionally, some of this can be abbreviated (seizeroles2.bat):
**********BEGIN HERE**********
ntdsutil r c “co t s %1” q “seize domain naming master” q q
ntdsutil r c “co t s %1” q “seize infrastructure master” q q
ntdsutil r c “co t s %1” q “seize PDC” q q
ntdsutil r c “co t s %1” q “seize RID master” q q
ntdsutil r c “co t s %1” q “seize schema master” q q
***********END HERE***********

And if you really want it to shorten up, you can enter a single line to do what you want (seizeroles3.bat):
**********BEGIN HERE**********
ntdsutil r c “co t s %1” q “seize domain naming master” “seize infrastructure master” “seize PDC” “seize RID master” “seize schema master” q q
***********END HERE***********

Also I like to add a “popups off” or “p off” before the r c to keep it from prompting me as to whether I wish to perform this action or not.


Read more


VMware: Extending a Cloned (Deployed) Windows VM’s root partition without using any 3rd party tools

In the dynamic environment we have at work any day of the week, we could need some test VM’s with any number of different disk sizes.

I would clone a “Golden Master” and then resize the disk, going through many different tools to be able to resize the C: drive to the full size of the .vmdk.

So, I wondered if there was any way to automate this. Well, there partially is.

If you add the “ExtendOEMPartition = 1” entry to the sysprep.inf file that VMware “drops off” on the vmdk before the customization process, it will resize to the full size (within the limits of the Windows OS you are cloning).

Keep in mind, this doesn’t work for shrinking, but it certainly does for extending.

So my task was to deploy a VM, resize the disk, and have the customization process extend to the new (bigger) .vmdk size.

Well, after some deductive reasoning, I figured out which file generated the sysprep.inf. I wasn’t so concerned with the “dropping off” process, as I was the generation process.

If this file is modified, to include the “ExtendOEMPartition = 1” entry in the [Unattended] section, the magic will happen. That is if you extend the .vmdk before the VM powers on for the first time.

Now, the modifications aren’t difficult by any means. I will mention however, that the files to be modified are encoded, and they will have to be decoded. I will not go through the process of decoding them. But once decoded, you should be good to go.

And as everyone else who posts tweaks/ enhancements/ mods/ etc., I cannot be held responsible (or liable) for any changes you make to your configuration or your environment.

Click here to download the paper I put together. (Apparently my provider is having some web issues, possibly compression or something, so I’ve changed the .pdf to a .zip link. I’ll post the whole article as a web page to help with this issue.)

I’ve tested this in VC 1.4 with ESX 2.5.x and VC 2.0 with ESX 3.0.0 and it works successfully with Windows 2000 and Windows 2003 guests. Updated: VC 2.0.1 and ESX 3.0.1 also perform flawlessly.

Another note: The mentioned files only have to be modified once. They will not affect the normal cloning/template deployment process if you do not resize the .vmdk’s. I would recommend that if you upgrade your VC install, you check these files, and potentially update them if they have been replaced.

Read more