jmbrinkman

Posts Tagged ‘Windows PowerShell’

Battle for Cloud City: Microsoft strikes back? Part II.

In Opalis, Operations Manager, SCOM 2012, SCVMM 2012, Service Manager, System Center, Virtualization, Vmware on November 16, 2011 at 22:28

Part I.

One of biggest advantages of posting on a blog when compared with writing an official proposal or something similar is that I get to ramble on about the things I feel are important. Or peculiar, alienating or just entertaining. Looking at private cloud management solutions in a more trivial way give me the opportunity to talk about factors that might or might not matter for most but do say something about how a product is perceived – a degree of brand value if you wish.

You might wonder where this will lead considering that fact that the more serious part of this series started of with some dubious analogies – but don’t worry I actually intend to make a point here. This is my comparison:

I’ve conjured five topics:

  • Names – If have to explain stuff to my boss and I’ve taken the “cloud” and “virtual” hurdles, I want to have a nice set of abbreviations or a awe inspiring product name to work with
  • Powershell – Very important. Maybe a bit overrated by some – a general sense of logic, a search engine and Powergui are all that are needed to keep you from flipping burgers.
  • “Open” Standards – In what sense can each offering be accessed, extended and customized by both vendors and end-users?
  • Citrix, Emc – Alliances – The cloud and virtualization market seems rather peaceful with what I perceive as a mutually beneficial status-quo between Microsoft and Vmware on the hypervisor front, between Microsoft and Citrix on the SBC/VDI front and Cisco and EMC working with both Microsoft and Vmware to tie everything together. However if we are talking about clouds, unification and abstraction a cloud management solution that provides more integration then the cliche “single-pane-of-glass” everyone seems to be selling might dictate the choice for a hypervisor the next time licenses expire…
  • Monitoring Sprawl? – We consolidated 200 servers into 4 pieces of hardware but need 15 servers to monitor our environment…and we might feel unsure about hosting a monitoring solution on a platform that’s monitored by that solution…or which damn web interface do I need to do this…and of course – how can be VM status be green, my server object in maintenance mode and my email stuck in my outbox?

My conclusion? If you are going “Vendor A unless” Microsoft scores the best on the “trivial” side of things. If you go “best-of-breed” vSphere, vCenter (and PowerCLI/CapacityIQ) are very strong at what they do.

Note Bene:

The success of Powershell, pre-alpha stuff from EMC like project Orion and SMI-S show that there is a need for a universal API and framework for managing infrastructure. The sad part is that those initiatives are not new and many technologies have fallen and entered the eternal cloud – or are still there and are still used by deemed unworthy by some (such as SNMP).

The question that remains is – who will bring balance to the force – the chosen but fallen Anakin or the Light’s side counteraction, Luke ?

Backup TMG configuration using Powershell

In Powershell on September 23, 2011 at 13:08

Unfortunatly TMG doesn’t ship with any specific Powershell cmdlets. However, using COM objects you can export/backup up the TMG (or ISA) configuration to a xml file.

Depending on your environment there are two options, if you have an Enterprise Array use this:

$root= New-Object -ComObject “FPC.Root”

$root.Exporttofile(“[PATH_AND_Filename]”,”0″)

If you have an standalone array use this instead:

$root= New-Object -ComObject “FPC.Root

$array=$root.GetContainingArray()

$array.Exporttofile(“[PATH_AND_Filename]”,”0″)

To give an example, this what a typical script to backup TMG will look like:
$array=$root.GetContainingArray()
$array.exporttofile(“d:\tmgbackup.xml”,”0″)
if ($err)
    {
    write-eventlog -logname Application -source TMGBackup -eventid 9999 -entrytype Warning -message “Backup
failed, cause: $err” -category 0
    }
else
{
write-eventlog -logname Application -source TMGBackup -eventid 9000 -entrytype Information -message “Backup Succeeded” -category 0
}

You should of course first register the eventlog source using new-eventlog to register the TMGBackup eventlog source.

Running Powershell script as SCOM console task and passing named parameters

In Operations Manager, Powershell, System Center on May 19, 2011 at 09:54

We have a ticketing system for which there is no SCOM connector and we wanted to provide a simple way to forward an alert to the ticketing system by email. We already stumbled upon the Alert Forward Task MP by Cameron Fuller but to add some flexibility I decided to rewrite it using a powershell as the application that is being executed. Contrary to agent task there is no default functionality to specifically run a powershell script to it took some time to figure out how I should call the script from the task and how to pass the needed parameters.

The variables I wanted to get from the alert where the MonitoringObjectName,Name,Description,Severity and Time Raised. I would then use those variables as named paramters to the powershell script that actually sends the mail. This is the code for the powershell script:

Param($managedobject,$name,$description,$time,$severity)
# Variables
$recipient= someone@someone.local
$mailserver = mail@someone.local
$sender= someoneelse@someone.local
$body=@"
<html>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<body>
<h1>$name<br></h1>
<b>Managed Object:</b>$managedobject<br>
<b>Description:</b> $description<br>
<b>Time Raised:</b> $time<br>
<b>Severity:</b> $severity
</body>
</html>
"@
$subject="Operations Manager Alert:"+"$name"
# Let's send an email
Send-MailMessage -ErrorVariable $mailerror -From $sender -To $recipient -SmtpServer $mailserver -Subject $subject -Body $body -BodyAsHtml
# If you enable output on the console task use the clause below to give some output.
#"@
#$message=@"
#The alert: $name ,
#has been forwarded.
#"@
#if ($mailerror)
#    {
#    Write-Host $mailerror
#    }
#else
#    {
#    Write-Host $message
#    }

As you can see it is a rather simple script that takes the input from the alert, builds an html message and uses Send-MailMessage to send the message. If you’d like to show output (error, success) you can uncomment that section and set RequireOutput to true in the XML.

Then I created a console task in the SCOM Authoring console and specificed a command line application, the paramters and working directory. Of course it took me some time to find the right syntax and looking at the xml I noticed something peculiar, all the parameters you enter in the gui are put into one <parameter> element inside the XML. Even when you edit the xml by hand and add each parameter as a separate element and open up the pack in the console and change something like the display name and save it it wraps them all up in one element again. Testing showed that with all the arguments in one element in the XML the task doesn’t work.

Here is the XML snippit of the console task:

<ConsoleTask ID="MCSE.AlertForward" Accessibility="Public" Enabled="true" Target="System!System.Entity" RequireOutput="false" Category="Alert">
<Application>%windir%\System32\WindowsPowerShell\v1.0\powershell.exe</Application>
<Parameters>
<Parameter>-noprofile</Parameter>
<Parameter>"&amp; \\someuncpath\forward-alert.ps1"</Parameter>
<Parameter>-ManagedObject '$MonitoringObjectName$'</Parameter>
<Parameter>-Name '$Name$'</Parameter>
<Parameter>-Description '$Description$'</Parameter>
<Parameter>-Severity '$Severity$'</Parameter>
<Parameter>-Time '$TimeRaised$'</Parameter>
</Parameters>
<WorkingDirectory>\\someuncpath\</WorkingDirectory>
</ConsoleTask>

Easiest way to add this task would be to copy/paste the xml into an existing MP and import the MP into your SCOM environment.

I put the powershell script on a share accessible to all our SCOM operators, used powershell.exe as the application and the script path and the variables from SCOM as arguments.Notice the double quotes around the script path and the single quotes around the alert variables.

You can of course create a more elaborate email, for instance using this excellent script by Tao Yang as an example. (Tao creates his own channel to send email notification and set up subscriptions but the code used to collect the data from SCOM can also be used in a console task).