Archive

PowerShell

Two days ago, I used our test installation of System Center App Controller to create a new virtual machine in one of our Windows Azure accounts.

After the successful creation of the VM, I decided to destroy it. App Controller has sent the command to Azure and deleted the VM but left some garbage: the VM VHD disk into the blob container. Then I tried to delete the VHD via Azure Portal. The portal told me that the operation was successful but I continued to see the VHD (and to waste money on it).

After several more attempts, I decided to use PowerShell Azure commandlets and I was able to delete the VHD (and save money).

In the next days, I will investigate more on the problem. Meanwhile it is nice to know that you can continue to trust PowerShell for real management of systems.

Advertisements
<#
.SYNOPSIS
Send a sequence of keys to an application window

.DESCRIPTION
This Send-Keys script send a sequence of keys to an application window.
To have more information about the key representation look at http://msdn.microsoft.com/en-us/library/System.Windows.Forms.SendKeys(v=vs.100).aspx
(C)2013 Massimo A. Santin - Use it at your own risk.

.PARAMETER ApplicationTitle
The title of the application window

.PARAMETER Keys
The sequence of keys to send

.PARAMETER WaitTime
An optional number of seconds to wait after the sending of the keys

.EXAMPLE
Send-Keys "foobar - Notepad" "Hello world"

Send the sequence of keys "Hello world" to the application titled "foobar - Notepad".

.EXAMPLE
Send-Keys "foobar - Notepad" "Hello world" -WaitTime 5

Send the sequence of keys "Hello world" to the application titled "foobar - Notepad" 
and wait 5 seconds.

.EXAMPLE 
    New-Item foobar.txt -ItemType File; notepad foobar.txt ; Send-Keys "foobar - Notepad" "Hello world{ENTER}Ciao mondo{ENTER}" -WaitTime 1; Send-Keys "foobar - Notepad" "^s"

This command sequence creates a new text file called foobar.txt, opens the file using a notepad,
writes some text and saves the file using notepad.

.LINK
http://msdn.microsoft.com/en-us/library/System.Windows.Forms.SendKeys(v=vs.100).aspx
#>

param (
    [Parameter(Mandatory=$True,Position=1)]
    [string]
    $ApplicationTitle,

    [Parameter(Mandatory=$True,Position=2)]
    [string]
    $Keys,

    [Parameter(Mandatory=$false)]
    [int] $WaitTime
    )

# load assembly cotaining class System.Windows.Forms.SendKeys
[void] [Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
#Add-Type -AssemblyName System.Windows.Forms

# add a C# class to access the WIN32 API SetForegroundWindow
Add-Type @"
    using System;
    using System.Runtime.InteropServices;
    public class StartActivateProgramClass {
        [DllImport("user32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        public static extern bool SetForegroundWindow(IntPtr hWnd);
    }
"@

# get the applications with the specified title
$p = Get-Process | Where-Object { $_.MainWindowTitle -eq $ApplicationTitle }
if ($p) 
{
    # get the window handle of the first application
    $h = $p[0].MainWindowHandle
    # set the application to foreground
    [void] [StartActivateProgramClass]::SetForegroundWindow($h)

    # send the keys sequence
    # more info on MSDN at http://msdn.microsoft.com/en-us/library/System.Windows.Forms.SendKeys(v=vs.100).aspx
    [System.Windows.Forms.SendKeys]::SendWait($Keys)
    if ($WaitTime) 
    {
        Start-Sleep -Seconds $WaitTime
    }
}

Oggi ero dal cliente con i nuovi 1000 utenti che sono partiti con il nuovo sistema di posta elettronica. Come al solito qualche problema minimale facilmente gestibile.

Visto che sono in fase di relax volevo accennare alla console grafica di gestione di Exchange 2007. In pratica si tratta di un wrapper su alcune funzionalità delle Cmdlet PowerShell (non sono tutte le funzionalità quindi i comandi è bene impararli). La particolarità più interessante è che, una volta eseguito il comando, la console mostra quello che si dovrebbe digitare sul prompt per ottenere lo stesso risultato.

La console diventa anche un grande strumento didattico.

La prima volta che ho usato una cosa del genere è stato ai tempi dell’IBM AIX 3.x con SMIT. Inutile dire che anche allora questo aspetto mi aveva impressionato. Probabilmente sarà colpa della mia passione per le interfacce utente!

Un nostro cliente ha acquistato un’altra azienda e si è reso quindi necessario migrare un migliaio di utenti di posta della nuova azienda sul sistema di posta del gruppo basato su cluster Exchange 2007 distribuendoli equamente sui database e sui nodi. Per questione di politiche aziendali abbiamo dovuto cambiare gli indirizzi di posta ma mantenendo i vecchi come alias. E’ poi stata cambiata in modo massiccio la gestione delle caselle comuni. Tutto questo condito con una discreta dose di eccezioni alle regole e complicato dal fatto che le caselle sono associate ad utenti definiti in una foresta diversa.

Exchange 2007 è un sistema molto potente con la possibilità di definire parecchie cose in modo automatico. Questi automatismi però non permettono di indirizzare tutte le problematiche definite sopra (in special modo le eccezioni). L’integrazione di Exchange 2007 con PowerShell lo rende assolutamente interessante. La possibilità di agire con le cmdlet dedicate sugli oggetti che ne rappresentano le entità gestite permette di raggiungere una flessibilità molto alta. Per indirizzare tutti i problemi abbiamo combinato quindi un certo numero di script ottenendo un ottimo risultato

Personalmente conosco shell come ksh o bash (e persino csh) e ho utilizzato spesso script in Perl e VBScript. Però questi strumenti non raggiungono la flessibilità di PowerShell dove si accede ai sistemi sottostanti mediante un modello uniforme integrato con l’accesso alla maggior parte del .NET framework. Se ancora non l’avete guardata è ora di farlo.

PowerShell è una delle chicche dell’ultima generazione dei sistemi Microsoft e sono arrivato a pensare che da sola può essere il motivo di aggiornamento da una vecchia versione di un prodotto alla nuova versione integrata con essa. Microsoft sarà arrivata tardi alla festa delle shell ma ci è arrivata veramente con stile e, a buon diritto, oggi è uno degli attori di riferimento.

Oggi e domani sono impegnato nella partenza di un sistema complesso ma che lavora con le persone e quindi con tempi umani. Ho quindi dei tempi morti: quale migliore occasione per leggere un po’ di roba su Internet?

Sfogliando qua è la mi è capitato di leggere questo post che vi indico: si tratta di una interessante elucubrazione su PowerShell partita da un’altro post riguardante i toolkit Perl e PowerShell per la gestione delle macchine virtuali.

IBM ha rilasciato PowerShell for WebSphere MQ, un Support Pac per MQ sulla piattaforma Windows che ne permette la gestione tramite PowerShell. MQ è un middleware IBM che permette la comunicazione di differenti programmi su differenti piattaforme tramite un sistema a code distribuite. E’ un software estremamente affidabile e longevo che abbiamo usato con successo in molteplici scenari multipiattaforma. Ovviamente è un ottimo software utile in scenari di integrazione di sistemi (o in certe implementazioni di architetture SOA).

Non è la prima volta che IBM si integra egregiamente con Windows (il DB2, per esempio) e non è neppure la prima volta che si avventura sulle nuove caratteristiche rese disponibili da Microsoft. Ma, riguardo MQ,  molto interessante è il canale MQ per WCF. Questo software integra il Windows Communications Framework con MQ utilizzando SOAP per JMS. In altri termini rende facile la comunicazione fra sistemi .NET 3.x (e in ultima analisi Windows) e sistemi collegabili a WebSphere MQ come WebSphere Application Server o il CICS. Significa che si potrebbero integrare queste potenti tecnologie IBM (legacy e non) con i nuovi potenti framework di Microsoft. Peccato sia solo un proof of concept e per di più con alcune mancanze fondamentali e quindi non utilizzabile in produzione.