Scripting Operations Framework

Formation PowerShell #04 : Exchange Management Shell

2009-04-26T11:21:00.001+02:00

Voici la quatrième session de la formation PowerShell en vidéo !
Cette session est un peu spéciale puisqu'elle est dédiée à Exchange Management Shell.

Exchange 2007 étant basé sur PowerShell, nous aborderons dans cette vidéo l'administration de ce serveur de messagerie en ligne de commande.

Vous pouvez retrouver l'ensemble des sessions ICI !

Configuration du portail : Active Directory et SQL

2009-04-22T16:15:00.003+02:00

La partie précédente de cet article se trouve ICI !

Nous arrivons à la dernière phase du déploiement de notre portail Web : la configuration !

Biensûr, la configuration d'un portail dépend du portail lui-même mais aussi de l'environnement dans lequel il est déployé. Le sujet ici est simplement de voir certaines petites astuces en PowerShell autour d'Active Directory et de SQL !

En effet, notre portail Web a besoin d'une unité organisationnelle (OU) dans notre Active Directory afin d'y rassembler les groupes qu'il utilise (par exemple le groupe des Administrateurs du portail !) ou encore d'exécuter certaines procédures stockées de notre base de données !

Bref nous allons nous voir tout celà en détail !

La première chose est de créer notre unité organisationnelle dédiée à notre portail :

### <summary>
### Creates Web portal prerequires in Active Directory.
### </summary>
### <return>True on success, false otherwise</return>
function Configure-ADWebPortal()
{
    trap {
        Display-Info $_.Exception.Message
        $bln = $false
        continue
    }
    $bln = $true
    $CONST_GLOBAL_GRP = 2
    $CONST_UNIV_GRP = 8
    Display-Info 'Creating WebPortal Organizational Unit...'
    $objOU = [ADSI]''
    $objOU = $objOU.Create('OrganizationalUnit', 'OU=WebPortal')
    $objOU.SetInfo()
    
    Create-Group $objOU 'AdmWebPortal' 'WebPortal Administrators' $CONST_UNIV_GRP
    
    return $bln
}

La fonction Configure-ADWebPortal crée notre OU et un groupe dans celle-ci. Si vous avez suivi les formations PowerShell en vidéo, vous ne découvrez rien de neuf !

Remarquez cependant qu'ici nous avons fait une petite fonction permettant de créer un groupe Active Directory dont voici le code :

### <summary>
### Creates an Active Directory group.
### </summary>
### <param name ="objOU">The container (ADSI object)</param>
### <param name ="strName">Group's name</param>
### <param name ="strDescription">Group's description</param>
### <param name ="intGroupType">Group's type</param>
function Create-Group($objOU, $strName, $strDescription, $intGroupType)
{
    trap {
        Display-Error $_.Exception.Message
        continue
    }
    Display-Info "Creating group $strName..."
    $objGroup = $objOU.Create('Group', "CN=$strName")
    $objGroup.Put('SamAccountName', "$strName")
    $objGroup.Put('Description', "$strDescription")
    $objGroup.Put('GroupType', $intGroupType)
    $objGroup.SetInfo()
}

Afin de pouvoir tracer d'éventuels problèmes, nous ajoutons des appels à nos fonctions affichant et loggant les informations.

Dans notre exemple, le groupe créé est Universel. Pourquoi ? Peut-être que nous en ferons une liste de diffusion sous Exchange 2007 (très) prochainement...

C'est très bien, nous avons réussi à créer des objets Active Directory, à exécuter des scripts SQL... et maintenant ?

Nous allons modifier en masse et à la volée notre Active Directory et notre base de données ! En effet, le but de la prochaine fonction va être simple :

Récupération de toutes les OU dont le nom est normé d'une certaine manière
Création d'un groupe dans chacune de ces OU
Insertion du nom de l'OU traitée dans notre base de données en exécutant une procédure stockée !

### <summary>
### Synchronizes SQL database and Active Directory.
### </summary>
### <param name="objSQL">SQL connection object</param>
### <return>True on success, false otherwise</return>
function Synchronize-ADAndSQL($objSQL)
{
    trap {
        Display-Error $_.Exception.Message
        $bln = $false
        continue
    }
    $CST_GLB_GRP = 2
    $bln = $true
    $objEntry = [ADSI]''
    Clean-Database $objSQL
    foreach ($obj in $objEntry.psbase.Children) {
        if ($obj.Name.Value -match "^(\w+\d+)_(\w+)$") {
            $strFullName = $matches[0]
            $strCode = $matches[1]
            $strName = $matches[2]
            $strDN = $obj.psbase.Properties.DistinguishedName.Value
            Display-Info "OU $strFullName discovered"
            $strGroupName = "$strCode" + '_Administrators_WebPortal'
            Create-Group $obj "$strGroupName" "Admins for $strCode" $CST_GLB_GRP

            $objAdapter = New-Object Data.SqlClient.SqlDataAdapter
            $objAdapter.SelectCommand = New-Object Data.SqlClient.SqlCommand
            $objAdapter.SelectCommand.Connection = $objSQL
            $objAdapter.SelectCommand.CommandText = '[PR_ADDOU]'
            $objAdapter.SelectCommand.CommandType =
                [Data.CommandType]::StoredProcedure

            $objSqlParam = Build-SQLParam '@OUCode' $strCode
            [void]$objAdapter.SelectCommand.Parameters.Add($objSqlParam)
            $objSqlParam = Build-SQLParam '@OUName' $strName
            [void]$objAdapter.SelectCommand.Parameters.Add($objSqlParam)
            $objSqlParam = Build-SQLParam '@OUDN' $strDN

            $objAdapter.SelectCommand.ExecuteNonQuery() | Out-Null
        }
    }
    
    return $bln
}

Le nom des OU est formatté en deux parties : un code et le nom de l'OU séparés par le caractère '_'. Notre procédure stockée nommée PR_ADDOU prend en paramère ces informations et est exécutée : un bon moyen de séparer les traitements ; si le traitment côté SQL est modifié, le script PowerShell ne l'est pas !

Ce petit Solution Accelerator de déploiement d'un portail Web n'est biensûr qu'un exemple mais grâce à lui, nous avons vu un cas pratique d'automatisation !

Automatisation de IIS

2009-04-16T20:42:00.001+02:00

La partie précédente de cet article se trouve ICI !

Après avoir déployé notre base de données sur laquelle s'appuiera notre portail Web, nous allons nous occuper du site Web.

En utilisant le deuxième menu...

... Nous découvrons notre interface graphique nous permettant de déployer notre site :

Là encore, l'interface est minimaliste. Les informations demandées sont :

Nom du serveur Web sur lequel déployer notre site,
Le port d'écoute,
Le chemin contenant les sources de notre site Web,
Un identifiant et un mot de passe qui seront utilisés pour le pool d'application.

Biensûr, les trois premiers champs sont pré-remplis.

Intéressons-nous au code PowerShell !

La première chose à faire est de vérifier que les informations renseignées sont correctes :

### <summary>
### Checks the Web part parameters.
### </summary>
### <return>True if parameters are correct, false otherwise</return>
function Check-WebParameters()
{
    $bln = $false
        
    $bln = ($TxtWebServer.Text.Length -gt 0) -and
           ($TxtWebPort.Text.Length -gt 0) -and
           ($TxtWebPath.Text.Length -gt 0) -and
           ($TxtWebLogin.Text.Length -gt 0) -and
           ($TxtWebPassword.Text.Length -gt 0)
    if ($bln) {
        $bln = ($TxtWebServer.Text -match "^\w[\w\d-_]*$") -or
               ($TxtWebServer.Text -match "^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$")
        if ($bln -eq $false) {
            Display-error 'Specified server name is invalid'
        } else {
            $bln = ($TxtWebPort.Text -match "^\d{1,5}$")
            if ($bln -eq $false) {
                Display-error 'Specified port is invalid'
            } else {
                $bln = Test-Path $TxtWebPath.Text
                if ($bln -eq $false) {
                    Display-error 'Specified Web folder is invalid'
                } else {
                    $strLogin = $TxtWebLogin.Text
                    if ($strLogin.Contains('\')) {
                        $strLogin = $strLogin.Split('\')[1]
                    }
                    $objUser = SearchOne-InDomain '' "(samaccountname=$strLogin)"
                    if ($objUser -eq $null) {
                        Display-error 'Specified user doesn''t exist in the domain'
                        $bln = $false
                    }
                }
            }
        }
    } else {
        Display-error 'All fields are required'
    }
    
    return $bln
}

La fonction Check-WebParameters vérifie :

La validité du nom du serveur ou de l'adresse IP renseignée grâce à une expression régulière,
La validité du port (un nombre de 5 caractères maximum)
L'existence du compte utilisateur Active Directory renseigné. Cette dernière vérification est faite grâce à SearchOne-InDomain qui est une petite fonction dont voici le code :

### <summary>
### Searchs one object in an Active Directory container.
### </summary>
### <param name ="domainName">The container</param>
### <param name ="filter">LDAP filter</param>
### <param name ="scope">The scope for the research (optional)</param>
### <returns>Active Directory object</returns>
function SearchOne-InDomain($container, $filter,
                            $scope = [DirectoryServices.SearchScope]::Subtree)
{
    trap { return $null }
    $entry = New-Object DirectoryServices.DirectoryEntry("$container")
    $searcher = New-Object DirectoryServices.DirectorySearcher($entry)

    $searcher.Filter = $filter
    $searcher.SearchScope = $scope
    $searcher.FindOne()
}

Du déjà vu !

Bref une fois que nous avons vérifié que les informations renseignées sont correctes nous pouvons déployer notre site Web !

### <summary>
### Installs the IIS website.
### </summary>
function Deploy-WebServer()
{
    $bln = Check-WebParameters
    
    if ($bln -eq $false) { return }
    $bln = Copy-Source
    if ($bln -eq $false) { return }
    $LblError.Text = ''
    $strServer = $TxtWebServer.Text
    $strPath = $TxtWebPath.Text
    $strWebSiteName = 'Provisioning'
    $objLocator = New-Object -com WbemScripting.SWbemLocator
    $objProvider = $objLocator.ConnectServer($strServer, 'root/MicrosoftIISv2')
    $objService = $objProvider.Get("IIsWebService='W3SVC'")
    $objBindings = @($objProvider.Get('ServerBinding').SpawnInstance_())
    $objBindings[0].Properties_.Item('Port').value = $TxtWebPort.Text
    $createNewSiteMethod = $objService.Methods_.Item('CreateNewSite')

    $objInParameters = $createNewSiteMethod.InParameters.SpawnInstance_()
    $objInParameters.Properties_.Item('PathOfRootVirtualDir').value = $strPath
    $objInParameters.Properties_.Item('ServerBindings').value = $objBindings
    $objInParameters.Properties_.Item('ServerComment').value = $strWebSiteName
    
    Display-Info "Creating new WebSite '$strWebSiteName'..."
    $objOutParameters = $objService.ExecMethod_("CreateNewSite", $objInParameters)
    Display-Info "WebSite '$strWebSiteName' created"
    $id = ''
    $objOutParameters.properties_ | % {
        $id = $_.Value -match "[^']'([^']+)'.*"
        if ($id) { $id = $matches[1] }
    }
    if ($id.ToUpper() -match "^W3SVC/\d+$") {
        Display-Info "Creating new Application Pool '$strWebSiteName'..."
        $bln = Create-ApplicationPool $strServer $strWebSiteName
        if ($bln) {
            Display-Info "Configuring Website '$strWebSiteName'"
            $objSite = [ADSI]"IIS://$strServer/$id/Root"
            $objSite.Put("DefaultDoc", "Default.aspx")
            $objSite.Put("AppPoolId", $strWebSiteName)
            $objsite.put("AuthFlags", 4)
            $objsite.Put("AppFriendlyName", $strWebSiteName)
            $objsite.Put("AccessFlags", 1)
            $objsite.Put("AccessRead", $true)
            $objsite.Put("AccessScript", $true)
            $objsite.Put("AccessExecute", $true)
            $objSite.SetInfo()
            if ((Get-ChildItem env:COMPUTERNAME).Value -eq $strServer) {
                Set-FrameWorkVersion $id
                Display-Info "WebSite '$strWebSiteName' successfully created"
            } else {
                Display-Info "WebSite '$strWebSiteName' successfully created. " +
                             "You need to manually set up the .Net 2 version"
            }
        } else {
            Display-Error "Error creating Application pool '$strWebSiteName'"
            Display-Info "WebSite '$strWebSiteName' has not been configured"
        }
    } else {
        Display-Error "Invalid WebSite ID ($id)"
        Display-Info "WebSite '$strWebSiteName' has not been configured"
    }
}

La fonction Deploy-WebSite fait le travail ! Nous allons y jeter un petit coup d'oeil car c'est le plus intéressant !

En début de fonction, nous utilisons Copy-Source : c'est une petite fonction qui utilise la Cmdlet Copy-Item pour copier les sources de notre portail vers le dossier de notre futur site ; rien d'exceptionnel, alors nous continuons !

Ensuite, vous pouvez remarquez que nous attaquons notre serveur IIS en ADSI. Celà rend cette fonction utilisable à partir de la version 6 de IIS.

Dans cette fonction nous faisons donc les opérations suivantes :

Création du site Web avec un nom et un port d'écoute donné,
Création d'un pool d'application qu'utilisera notre site. Pour celà nous avons créé la fonction Create-ApplicationPool :

### <summary>
### Creates the IIS application pool.
### </summary>
function Create-ApplicationPool($strServer, $strAppPoolName)
{
    trap [Exception] {
        Display-Info $_.Exception.Message
        $bln = $false
        continue
    }
    $bln = $false
    $objApp = [ADSI]"IIS://$strServer/W3SVC/AppPools/$strAppPoolName"
    if ($objApp.distinguishedname -eq $null) {
        $strDomain = ([ADSI]'').Name.Value
        $objApp = [ADSI]"IIS://$strServer/W3SVC/AppPools"
        $objPool = $objapp.Create("IIsApplicationPool", $strAppPoolName)
        $objPool.Put('AppPoolIdentityType', 3)
        $strLogin = $TxtWebLogin.Text
        if ($strLogin.Contains('\') -eq $false) {
            $TxtWebLogin.Text = "$strDomain\$strLogin"
            $TxtWebLogin.Refresh()
        } else {
            $strLogin = $strLogin.Split('\')[1]
        }
        Display-Info "Setting Application pool credentials to $strLogin..."
        $objPool.Put('WAMUserName', $TxtWebLogin.Text)
        $objPool.Put('WAMUserPass', $TxtWebPassword.Text)
        $objPool.SetInfo()
        Display-Info "Adding user $strLogin to group IIS_WPG..."
        $objGroup = [ADSI]"WinNT://$strServer/IIS_WPG"
        $objGroup.Add("WinNT://$strDomain/$strLogin")
        $bln = $true
    } else {
        Display-Info "Application pool '$strAppPoolName' already exists."
        $bln = $true
    }

    return $bln
}

Cette fonction ajoute également le compte utilisé par le pool d'application dans le groupe local IIS_WPG.
Configuration du site Web :
- Page par défaut paramétrée à la page Default.aspx
- Utilisation du pool d'application précédemment créé
- Paramétrage de l'authentification Windows
- Mise en place des droits de lecture et d'exécution
Utilisation de la version 2 du framework .NET. Cette étape n'est faite que si notre Solution Accelerator est lancé depuis le serveur Web. La fonction Set-FrameworkVersion configure notre site web pour qu'il utilise la version 2 :

### <summary>
### Sets the .NET framework version for a given website.
### </summary>
### <param name="strID">Website ID</param>
function Set-FrameWorkVersion($strID)
{
    $strPath = (Get-ChildItem Env:windir).Value + '\Microsoft.NET\Framework\'

    $objDir = Get-ChildItem $strPath | where {
               ($_.GetType().ToString() -eq 'system.io.directoryinfo') -And
               ($_.name -match "^(v2.[\d\.]+)$")} | sort name
    if ($objDir -ne $null) {
        $strPath += $matches[1]
        $strPath += "\aspnet_regiis.exe"
        $objSI = New-Object System.Diagnostics.ProcessStartInfo
        $objSI.UseShellExecute = $false
        $objSI.FileName = $strPath
        $objSI.Arguments = "-s $strID/Root"
        $objSI.RedirectStandardOutput = $true
        $objP = [System.Diagnostics.Process]::Start($objSI)
        $objP.WaitForExit()
    }
}

Vous pouvez remarquer que nous exécutons le binaire aspnet_regiis.exe !

Biensûr, les erreurs sont affichées en bas de notre fenêtre si elles surviennent !

Nous arrivons à la fin de l'automatisation de IIS... J'espère que ça n'a pas été trop long !

Déploiement de la base de données

2009-04-08T20:16:00.002+02:00

La partie précédente de cet article se trouve ICI.

Avant de déployer notre site Web, nous devons installer la base de données : quel portail Web ne possède pas de base de données aujourd'hui ? :)

Pour celà, notre Solution Accelerator va faire le travail pour nous. Dans l'article précédent, je vous ai présenté l'interface graphique : nous allons donc l'utiliser !

Nous allons cliquer sur notre premier menu afin de pouvoir déployer notre base de données !

Nous découvrons donc l'interface graphique dédiée :

Elle est volontairement sobre !
En effet, nous n'avons qu'à saisir le nom du serveur SQL ainsi que le nom de l'instance et cliquer sur OK...

Dans cette interface, nous avons tout de même prévu de pouvoir spécifier le compte avec lequel faire ce déploiement : visible tout en haut de la fenêtre. En effet, nous avons la possibilité d'utiliser les informations de connexion de l'utilisateur courant ou bien d'en spécifier d'autres.

Vous pouvez remarquer qu'en bas de la fenêtre il y a un grand espace vide... Nous n'allons pas le laisser vide ! En effet, cette zone est en fait réservée à l'affichage des informations et des erreurs !
Chaque étape du script est décrite dans cette zone ainsi que les éventuelles erreurs : ce sont les fonctions Display-Info ou Display-Error qui s'en chargeront :

### <summary>
### Adds a log.
### </summary>
### <param name="str">Message to add</param>
### <param name="strType">Message type</param>
function Log-Message($str, $strType)
{
    $strDate = [DateTime]::Now.ToString('G')
    $strType = $strType.ToUpper()
    $strLine = "[$strDate] $strType: $str"
    Write-Verbose $strLine
    $script:strLog += $strLine + "`r`n"
}

### <summary>
### Displays error message.
### </summary>
### <param name="str">Message to display</param>
function Display-Error($str)
{
    $LblInfo.Text = ''
    $LblError.Text = $str
    $LblError.Refresh()
    Log-Message $str 'Error'
}

### <summary>
### Display information message.
### </summary>
### <param name="str">Message to display</param>
function Display-Info($str)
{
    $LblInfo.Text = $str
    $LblInfo.Refresh()
    Log-Message $str 'Info'
}

Biensûr ces informations et erreurs sont enregistrées dans nos logs, d'où la fonction Log-Message qui ne fait qu'ajouter une date de génération du message (information ou erreur) !

Bref vous l'aurez compris, la traçabilité est importante et doit être présente dans nos scripts !

Maintenant que la présentation de l'interface est faite, nous pouvons passer à la partie la plus interessante : le traitement fait en PowerShell lorsqu'on appuie sur le bouton !

Avant tout, nous devons vérifier que nous avons tous les pré-requis nécessaires pour faire notre déploiement : les scripts SQL que nous exécuterons !

Pour celà, nous allons déclarer quelques variables qui seront visibles dans tout notre script :

### <summary>
### Path to current script.
### </summary>
$script:strPath = $MyInvocation.MyCommand.Path

### <summary>
### SQL scripts to execute during installation step.
### Order is essential.
### </summary>
$script:arrSQLGenerateDBScripts = 'CreateDatabase.sql',
                                  'ProvisioningDatabase.sql'
### <summary>
### Installation logs.
### </summary>
$script:strLog = ''

On peut remarquer ici l'utilisation de la variable $MyInvocation très utile puisqu'elle nous donne des informations sur notre dernière commande : ici on récupère le chemin où se trouve notre script PowerShell !

La variable arrSQLGenerateDBScripts contient une liste ordonnée de nos scripts SQL.

Enfin, strLog est une simple chaîne de caractères qui fera office de log (il faut garder une trace des actions et des erreurs !).

Nous allons dans un premier temps vérifier que les fichiers sont présents :

### <summary>
### Checks SQL files.
### </summary>
### <return>True on success, false otherwise</return>
function Check-SQLFiles()
{
    trap {
        $blnRes = $false
        continue
    }
    $tab = $script:strPath.Split('\')
    $strPath = ''
    for ($i = 0; $i -lt $tab.length - 2; $i++) {
        $strPath += $tab[$i] + '\'
    }
    $blnRes = $true
    $bln = $true
    Display-Info "Checking files in $strPath..."
    if ($script:arrSQLGenerateDBScripts.Length -gt 0) {
        foreach ($strFile in $script:arrSQLGenerateDBScripts) {
            $bln = Test-Path "$strPath\Database\$strFile"
            if ($bln -eq $false) { break }
        }
        $blnRes = $blnRes -and $bln
    }
    if ($blnRes) {
        Display-Info "Installation files successfully checked"
    } else {
        Display-Error "Installation files missing."
    }
    
    return $blnRes
}

Cette fonction vérifie que nos scripts SQL contenus dans la variable de script existent dans le répertoire ../Database.

Maintenant que nous sommes certains de la présence de nos scripts à exécuter nous allons... les exécuter ! :)
Pour celà, nous devons biensûr nous connecter à notre base de données grâce à une chaîne de connexion :

### <summary>
### Generate the SQL connection string.
### </summary>
### <param name="strDB">Database name</param>
### <return>SQL connection string</return>
function Generate-StringConnection($strDB)
{
    $strInstance = $TxtDBServer.Text
    if ($TxtDBInstance.Text.Length -gt 0) {
        $strInstance += '\' + $TxtDBInstance.Text
    }
    $strInstance = $strInstance.ToUpper()
    $objBuilder = New-Object System.Data.SqlClient.SqlConnectionStringBuilder
    $objBuilder['Application Name'] = 'Web Portal'
    $objBuilder['Data Source'] = $strInstance
    $objBuilder['Initial Catalog'] = $strDB

    if ($ChkWindowsAuth.Checked -eq $false) {
        $objBuilder['User Id'] = $TxtLogin.Text
        $objBuilder['Password'] = $TxtPassword.Text
    } else {
        $objBuilder['Integrated Security'] = $true
    }

    return $objBuilder.ConnectionString
}

Cette fonction prend en paramètre le nom de la base de données qui sera affecté au paramètre "Initial Catalog" de notre chaîne de connexion.
Vous pouvez remarquer que si aucun nom d'instance n'est renseigné dans l'interface graphique, nous utilisons le nom du serveur (instance par défaut !).

Ensuite, nous pouvons écrire notre fonction qui va exécuter un script SQL :

### <summary>
### Executes a SQL script.
### </summary>
### <param name="strScript">Script full name</param>
### <param name="objSQL">SQL connection</param>
### <return>True on success, false otherwise</return>
function Execute-SQLScript($objSQL, $strScript)
{
    trap {
        Display-Error $_.Exception.Message
        $bln = $false
        continue
    }
    $bln = Test-Path $strScript
    if ($bln) {
        Display-Info "Executing script $strScript..."
        $objSQLCmd = New-Object System.Data.SqlClient.SqlCommand
        $objSQLCmd.Connection = $objSQL
        $strContent = ''
        foreach ($strLine in Get-Content $strScript) {
            if ($bln -eq $false) { return $bln }
            if ($strLine.ToUpper() -match "^\s*GO\s*$") {
                $objSQLCmd.CommandText = $strContent
                $objSQLCmd.ExecuteNonQuery() | Out-Null
                $strContent = ''
            } else {
                $strContent += $strLine + "`r`n"
            }
        }
    } else {
        $LblError.Text = "File $strScript not found"
    }
    
    return $bln
}

Il y a plusieurs méthodes pour exécuter un script. Ici nous avons choisi de lire le fichier SQL ligne par ligne et exécuter le résultat de notre lecture dès que nous rencontrons l'instruction SQL "GO".

C'est l'occasion de voir une expression régulière !
Rapidement, "^\s*GO\s*$" signifie que nous cherchons à identifier une chaîne de caractères contenant le mot GO entouré ou non d'espaces !

Comme il est toujours intéressant de savoir si notre script s'est bien exécuté, cette fonction retourne un booléen nous donnant cette information :)

Bref, nous avons tous les élements en main pour déployer notre base de données :

### <summary>
### Installs the SQL database.
### </summary>
function Install-Database()
{
    trap {
        Display-Error $_.Exception.Message
        if (($objSQL -ne $null) -and
            ($objSQL.State -eq [Data.ConnectionState]::Open)) {
            $objSQL.Close()
        }
        $bln = $false
        continue
    }
    $LblError.Text = ''
    $objSQL = New-Object System.Data.SqlClient.SqlConnection
    $objSQL.ConnectionString = Generate-StringConnection 'master'
    Display-Info "Opening database connection..."
    $objSQL.Open()
    if ($objSQL.State -eq [Data.ConnectionState]::Open) {
        $strPath = Get-SQLScriptPath
        foreach ($strScript in $script:arrSQLGenerateDBScripts) {
            $bln = Execute-SQLScript $objSQL "$strPath\$strScript"
            if ($bln -eq $false) { break }
        }
        $objSQL.Close()
        Display-Info "Database connection closed"
        if ($bln) {
            Display-Info "Database successfully installed"
        } else {
            Display-Error "Error executing script $strPath\$strScript."
            Display-Info "Database installation aborted"
        }
    }
}

Nous sommes à la fin !

Cette fonction se sert donc de ce que nous avons vu avant et deploie notre base de données en plusieurs étapes :

Création de la chaîne de connexion à la base de données
Ouverture de la connexion à la base de données
Exécution des scripts SQL
Fermeture de la connexion à la base de données

Tout celà en affichant les étapes et les éventuelles erreurs dans notre fenêtre graphique !

Il ne nous reste plus qu'à déployer notre portail web en automatisant IIS ! Rendez-vous donc au prochain article !

Automatisation du déploiement d'un portail Web

2009-03-31T21:28:00.005+02:00

Déployer un portail web n'est pas toujours très simple. Il faut vérifier que tous les pré-requis sont installés, faire le déploiement, vérifier la configuration... et encore, j'en oublie :)

Ce que nous chercherons à faire ici est par contre très simple : déployer un portail Web en appuyant sur un bouton... et tant qu'à faire, le bouton sera joli !

Vous l'aurez compris, c'est une sorte de "Solution Accelerator" (terme à la mode :p) que nous allons créer !

A quoi va ressembler notre interface graphique ? Voyons voir...

L'interface est simple mais efficace ! Elle met en évidence les trois étapes que nous détaillerons dans les articles à venir :

Déploiement de la base de données (exécution de script SQL)
Déploiement du portail Web (automatisation de IIS)
Configuration du portail (interaction avec Active Directory et l'Univers...)

Le décor est planté, il ne reste plus qu'à ouvrir notre session PowerShell !

A très bientôt pour notre première étape !

Niveau Manage

2009-03-18T21:22:00.006+01:00

Nous allons clore notre aperçu des différentes phases constituant le cycle de vie des services de la version 4 de MOF. Une fois ces phases appropriées, j'essaierai de vous présenter les processus intégrés à chacune de ces phases en adoptant une présentation moins théorique. En effet l'objectif de ce blog, outre le fait de vous initier au PowerShell et aux fondamentaux de MOF/ITIL est surtout de vous démontrer l'efficacité de leur association. Pour cela nous (Gregory et moi) vous présenterons des exemples pratiques d'associations de processus MOF et de scripts PowerShell.

Terminons donc notre vue d'ensemble des phases par le niveau Manage.
Bonne lecture.

Le niveau Manage intègre les processus de prise de décisions, de gestion des risques et de gestion du changement qui se produisent tout au long de la durée de vie des services IT. Il contient également les processus liés à la définition des rôles et responsabilités.
Le niveau Manage représente le fondement de toutes les phases du cycle de vie. Le niveau Manage promeut la cohérence dans la planification et la fourniture de services IT et fournit les bases pour le développement et l'exploitation d’un environnement IT résilient.

L'objectif principal du niveau Manage est de mettre en place une approche intégrée des activités de la gestion des services IT. Cette approche permet de coordonner les processus décrits dans les trois phases du cycle de vie: Plan, Deliver, et Operate. Cette coordination est renforcée par:

Le développement du processus de prise de décision

L’utilisation de la gestion des risques et des contrôles dans le cadre de tous les processus

La promotion des processus de changement et de configuration qui sont contrôlés

La division du travail afin que les responsabilités soient claires et ne soient pas en conflit

Des conseils spécifiques sont fournis pour accroître la probabilité que:

L'investissement informatique fournit la valeur business attendue

Les décisions d’investissement et d’allocation des ressources sont associées aux personnes appropriées

Il y a un niveau de risque acceptable

Des processus contrôlés et documentés sont utilisés

Les responsabilités sont communiqués et leur propriétaire mis en évidence

Les politiques et les contrôles internes sont efficaces et fiables

La réalisation de ces objectifs est plus susceptible d'être atteinte si l’informatique travaille à:

Des structures de gouvernance IT explicites et des processus

L'organisation IT et l'organisation des entreprises partagent une approche commune pour la gestion des risques
Planification régulières des revues de gestion des politiques et des contrôles internes

Objectifs de la Phase Operate

2009-03-16T14:46:00.005+01:00

La phase Operate (Exploitation) du cycle de vie des services IT représente l'aboutissement des deux phases qui la précèdent. La phase Operate se concentre sur ce qu'il faut faire après la mise en place des services. Après le déploiement réussi d’un service IT, assumer qu'il fonctionne pour satisfaire les besoins et les attentes business devient la priorité des priorités. C'est l'objet de la phase Operate, qui repose sur quatre initiatives:

Efficacité d’une gestion continue du service

Surveillance proactive et continue de la santé du service

Aide efficace et facilement accessible pour contribuer à l'utilisation du service

Restauration d'un service vers un état fonctionnel lorsque les choses tournent mal

L'objectif principal de la phase Operate est de faire en sorte que les services soient déployés exploités, entretenus, soutenus et en ligne avec les objectifs d'accord de niveau de service (SLA) qui ont été acceptés entre le business et l’IT.

Concrètement, cela signifie de faire en sorte:

Que les services IT sont disponibles par l'amélioration de l'utilisation du personnel et une meilleure gestion de la charge de travail

Que les services informatiques sont surveillés afin de fournir une observation en temps réel des conditions de santé et veiller à ce que les membres de l'équipe sont formés pour traiter les problèmes efficacement et rapidementQue les services IT sont rétablis rapidement et efficacement

Phase Deliver (Fourniture)

2009-03-16T12:18:00.012+01:00

Après un apprentissage Powershell (je suis sûr que vous avez apprécié les 3 vidéos), nous allons reprendre la partie "Processus" avec la présentation de la Phase Deliver (Fourniture) de MOF v4. Allez c'est parti ....

Après avoir acquis une solide planification pour la stratégie de service en place, vous pouvez commencer à créer de nouveaux services ou une mise à jour des services IT. L'objectif de la Phase Deliver est d'aider les professionnels informatiques à travailler au sein d'une discipline de gestion de projet pour construire, stabiliser et déployer des services IT, des applications et des améliorations de l'infrastructure d’une manière la plus efficace possible.

Imaginez le cycle de vie des services informatiques comme un continuum: il débute avec les efforts réalisés par l'informatique pour comprendre les services dont le business a besoin et se termine avec les services opérant dans un environnement de production. La phase Deliver, est la partie du continuum où les changements de services sont prévus, conçus, construits et déployés.

Objectifs et fonctions de la phase Deliver (Fourniture)

Les principaux objectifs de la phase Deliver sont d’assurer que les services IT, les projets d'infrastructure ou les déploiements de produits sont prévus, planifiés, construits, stabilisés, et déployés en fonction des exigences de l'entreprise et des spécifications du client.

Concrètement, cela signifie faire en sorte que l'équipe du projet:

Capture les besoins et les exigences préalables à la planification d'une solution
Prépare une spécification fonctionnelle et une conception de la solution
Élabore des plans de travail, des estimations de coûts et des calendriers pour les livrables
Construit la solution au regard de la spécification du client, de sorte que toutes les fonctions soient complètes, et que la solution soit prête pour les tests externes et la stabilisation
Met en production la solution la plus qualitative en effectuant des tests et un pilote de mise en production
Déploie une solution stable dans l'environnement de production et stabilise la solution en production
Prépare les équipes opérations et support pour gérer et fournir le service client pour la solution.

Formation PowerShell #03 : Automatisation et sécurité

2009-03-11T20:01:00.003+01:00

Voici une nouvelle session de la "formation PowerShell" !

Cette troisième session nous permet d'entrer dans le vif du sujet :

Automatisation d'applications avec les composants COM (exemples avec IE et Word 2007)
Personnalisation du profil
Notion de scripting : script d'audit des journaux d'évènements d'une machine distante
Gestion des erreurs
Création d'interface graphique
Sécurité : signature des scripts

Bref, beaucoup de choses à voir dans cette session :)

Vous pouvez trouver les deux premières sessions ici :

Formation PowerShell #02 : Son SI en ligne de commande

2009-03-06T19:37:00.008+01:00

Après avoir vu les bases dans la vidéo précédente, nous allons voir un aperçu de ce que PowerShell est capable de faire !

Dans cette deuxième session de la "formation PowerShell" nous verrons les points suivants :

Récupération d'informations logicielles et matérielles sur une machine distante
Questionner et peupler un annuaire Active Directory

Vous l'aurez donc compris, cette session est orientée Infrastructure !

Formation PowerShell #01 : les bases

2009-03-01T16:40:00.004+01:00

Je vous propose dans cet article et ceux à venir de découvrir PowerShell sous la forme de petites "formations" en vidéos !

J'aurais pu commencer par ça... mais comme on dit, "mieux vaut tard que jamais" :)

Bref, voici la première vidéo que je vous propose dans laquelle sont abordés les points suivants :

Les bases
Les providers
Framework .Net : notions d’objet
Manipulation et présentation de l’information

PowerShell 2 et Word 2007 : Génération de fiches serveur

2009-02-26T21:54:00.010+01:00

Nous y voilà, nous pouvons générer une fiche serveur en 4 étapes :

Partie 1 : Installation et configuration des pré-requis.
Partie 2 : Création du module PowerShell collectant les informations sur une machine distante.
Partie 3 : Création du document Word 2007 (template).
Partie 4 : Génération de la fiche serveur.

Vous trouverez l'ensemble des sources en libre téléchargement ici : Generate-ServerForm.zip.

Ces sources sont à titre d'exemple, libre à vous d'améliorer les scripts ! Il y a beaucoup de choses à faire... :)

Création de fiche serveur avec Word 2007 et PowerShell (Partie 4)

2009-02-20T14:42:00.006+01:00

La partie précédente de cet article se trouve ICI !

Nous arrivons à la dernière partie. Nous pourrons donc enfin avec PowerShell générer une fiche serveur !

Il ne nous reste plus qu’à écrire les fonctions permettant de mettre à jour du texte dans un document Word.

function Set-OpenXmlText($objNode, $objNsMgr, $strData)
{
    $blnIsCheckBox = $false
    $objNodeT = $null
    $objNodeR = $null

    $objNodeTmp = $objNode.SelectSingleNode('w:tc', $objNsMgr)
    if ($objNodeTmp -ne $null) { $objNode = $objNodeTmp }
    $objNodeTmp = $objNode.SelectSingleNode('w:p', $objNsMgr)
    if ($objNodeTmp -ne $null) { $objNode = $objNodeTmp }
    $objNodes = $objNode.SelectNodes('w:r', $objNsMgr)
    foreach ($objNodeR in $objNodes) {
        $objNodeSYM = $objNodeR.SelectSingleNode('w:sym', $objNsMgr)
        $blnIsCheckBox = $objNodeSYM -ne $null
        if ($blnIsCheckBox) {
            $objAttr = $objNodeSYM.Attributes |
                       where-Object { $_.Name -eq 'w:char'}
            $objAttr.Value = 'F0A8'
            if ($strData -eq $true) { $objAttr.Value = '00FE' }
            break
        }
        $objNodeT = $objNodeR.SelectSingleNode('w:t', $objNsMgr)
        if ($objNodeT -ne $null) { $objNodeT.InnerText = '' }
        # Sinon, il faut créer une balise W:T sous $objNodeR
    }
    if ((-not $blnIsCheckBox) -And ($objNodeT -ne $null)) {
        $objNodeT.InnerText = $strData
    }
}

Le but n’est pas d’étudier de près le format OpenXML… Mais nous avons besoin de quelques notions pour bien comprendre la fonction Set-OpenXmlText. Rien de bien difficile je vous rassure !

Pour cela, nous allons essayer de comprendre ce qui se passe lorsque nous insérons ce contrôle de contenu :

Nous avons vu que lorsque nous modifions notre document Word, nous modifions en faite le fichier /word/document.xml de notre package DOCX. Plus précisément, nous ajoutons dans notre cas les balises suivantes :

Notre contrôle de contenu est représenté par la balise w:sdt. Cette dernière se découpe en deux parties mises en évidence par deux couleurs différentes.

La partie verte (balise w:sdtPr) contient les propriétés de notre contrôle. Ainsi on va pouvoir y trouver son nom. Dans l’exemple, notre contrôle a pour nom FctNetworkInfrastructure. Ce nom est récupéré par la fonction Get-OpenXmlContentCtrlAlias que nous avons vu dans l’article précédent !

La fonction Set-OpenXmlText que nous avons découvert dans cet article va modifier la partie bleue (balise w:sdtContent) qui représente le contenu de notre contrôle de contenu !

Rien de compliqué… non ?!

Je mettrai à votre disposition les sources complètes et commentées de la génération d’une fiche serveur avec PowerShell et Word 2007 très bientôt dans un autre post ; avec des exemples d’utilisation !

Création de fiche serveur avec Word 2007 et PowerShell (Partie 3)

2009-02-13T23:33:00.007+01:00

La partie précédente de cet article se trouve ICI !

Nous avons donc à ce stade récupéré les informations matérielles et logicielles d’une machine distante.

Nous allons donc maintenant créer un document Word 2007 à la main. Pourquoi à la main ? Parce que notre script sera capable de rafraîchir certaines « zones » de notre document. De ce fait, il s’adaptera au template imposé par notre société !

Les « zones » dans lesquelles PowerShell écrira sont en réalité appelées « Contrôles de contenu » et se trouvent dans l’onglet « Développeur » de Word 2007 puis dans le groupe « Contrôles ». Comme dans l’image ci-dessous :

Ainsi, pour chaque information récupérée dans l’article précédent, nous allons insérer dans notre document un contrôle de contenu.

Lorsqu’un contrôle de contenu est inséré, nous pouvons lui donner un nom et nous allons le faire ! Cela permettra à notre script PowerShell qui écrira dans le document Word de savoir dans quel contrôle de contenu écrire en fonction de l’information récupérée sur notre machine distante.

Dans la partie précédente de l’article, nous avons écrit les fonctions Get-ComputerHardware et Get-ComputerSoftware. Si vous avez regardé de prêt ces fonctions, elle retourne un objet dont les propriétés sont les informations récupérées sur la machine distante.

L’astuce est donc de donner à nos contrôles de contenu les mêmes noms que les propriétés de nos objets retournés par les deux fonctions citées précédemment !

Une fois le document créé aux couleurs de notre société et peuplé de nos contrôles de contenu… nous pouvons créer le script qui va rafraîchir ce document : c'est-à-dire écrire dans les contrôles de contenu !

Pour cela, dans un nouveau fichier nommé « Generate-ServerForm.ps1 » nous allons écrire :

function Refresh-OpenXmlDocument($strDocPath, $strComputer)
{
    $objDoc = Get-OpenXmlDocument -Path $strDocPath -SuppressBackups
    if ($objDoc -eq $null) { return }

    $objUri = New-Object Uri('/word/document.xml', [UriKind]::Relative)
    $objPart = $objDoc.Package.GetPart($objUri)

    $script:objXmlDoc = New-Object Xml.XmlDocument
    $script:objXmlDoc.Load($objPart.GetStream())

    $objNsMgr = New-Object Xml.XmlNamespaceManager($objXmlDoc.NameTable)
    $strURL = 'http://schemas.openxmlformats.org'
    $objNsMgr.AddNamespace('w', "$strURL/wordprocessingml/2006/main")

    $objNodes = $script:objXmlDoc.DocumentElement.GetElementsByTagName('w:sdt')
    $objInfo = Get-ComputerInfo $strComputer

    foreach ($objNode in $objNodes) {
        $objN = $objNode.SelectSingleNode('w:sdtPr', $objNsMgr)
        $strAlias = Get-OpenXmlContentCtrlAlias $objN $objNsMgr
        if ($strAlias -ne '') {
            $objProperty = $objInfo | Get-Member -Name $strAlias
            if ($objProperty -ne $null) {
                $objN = $objNode.SelectSingleNode('w:sdtContent', $objNsMgr)
                switch -regex ($objInfo.$strAlias.GetType().Name) {
                    '\[\]$' {
                        Set-OpenXmlTable $objN $objNsMgr $objInfo.$strAlias
                    }
                    default {
                        Set-OpenXmlText $objN $objNsMgr $objInfo.$strAlias
                    }
                }
            }
        }
    }

    $script:objXmlDoc.Save($objPart.GetStream())
    $objDoc.Close()
}

Nous allons essayer d’analyser cette première fonction. Pour commencer… son but est d’écrire dans les contrôles de contenu d’un document Word 2007. Elle prend deux arguments ; le premier : le chemin vers notre template précédemment créé et le second, le nom de la machine dont nous devons récupérer les informations pour faire notre fiche.

Ensuite, nous allons mettre un peu les mains dans le format OpenXML !

La première chose qu’on remarque est l’appel à la Cmdlet Get-OpenXMLDocument. Elle provient des PowerTools. Vous devez donc avoir installé ces outils comme décrit dans cet article !

Nous allons faire une petite parenthèse sur le format OpenXML : un fichier Office 2007 est en réalité un fichier .ZIP renommé en .DOCX, XLSX ou PPTX ! Si vous renommez le fichier avec l’extension .ZIP et que vous le décompressez vous aurez une arborescence de fichiers.

Pour Word, vous aurez notamment un fichier « /word/document.xml » qui n’est rien d’autre que le contenu de notre document Word 2007 au format XML ! C’est précisément ce fichier XML que nous récupérons pour le manipuler. Fin de la parenthèse sur le format OpenXML !

Nous allons donc nous déplacer dans ce fichier XML en repérant nos contrôles de contenu dont la balise est : « w:sdt »

$script:objXmlDoc.DocumentElement.GetElementsByTagName('w:sdt')

Remarque : nous avons écrit $script:objXmlDoc afin de rendre visible notre variable dans tout le script.

Nous pouvons donc naviguer de contrôles de contenu en contrôles de contenu dans notre document en repérant ces balises ! Ensuite, pour chaque contrôle de contenu, nous devons récupérer son nom qui je vous le rappelle est aussi le nom d’une propriété de l’objet retourné par nos fonctions récupérant les informations d’une machine. Dans notre exemple, nous avons utilisé une fonction nommée Get-ComputerInfo. Cette fonction retourne un objet fusionnant le retour de Get-ComputerHardware et Get-ComputerSoftware.

Pour cela vous pouvez rajouter cette fonction dans notre module précédemment créé :

function Merge-Object($objSource, $objDest)
{
    $objSource | Get-Member -MemberType NoteProperty | % {
        Add-Property $objDest $_.Name $objSource.($_.Name)
    }
    
    return $objDest
}

function Get-ComputerInfo($strComputer)
{
    $objHardware = Get-ComputerHardware $strComputer
    $objSoftware = Get-ComputerSoftware $strComputer
    
    return (Merge-Object $objHardware $objSoftware)
}

Remarque : la fonction Merge-Objet fusionne les propriétés que nous avons rajoutées sur nos objets !

Biensûr, il faut modifier dans ce cas la fin de notre module pour rendre visible cette nouvelle fonction :

Export-ModuleMember -Function 'Get-ComputerHardware',
                              'Get-ComputerSoftware',
                              'Get-ComputerInfo'

Mais nous avons oublié une petite chose ! Nous devons dire à notre nouveau script qu’il doit utiliser notre module ! Nous le faisons grâce à la Cmdlet Import-Module que nous ajoutons au tout début de notre script :

Import-Module .\Computer_Info.psm1

Remarque : ici, notre module se situe dans le même répertoire que notre script.

Maintenant que nous avons tous les éléments, pour chaque contrôle de contenu nous récupérons son nom avec la fonction Get-OpenXmlContentCtrlAlias :

function Get-OpenXmlContentCtrlAlias($objNode, $objNsMgr)
{
    $strAlias = ''

    $objNode = $objNode.SelectSingleNode('w:alias', $objNsMgr)
    $strAlias = $objNode.Attributes | where-Object { $_.Name -eq 'w:val'}
    if ($strAlias -ne $null) { $strAlias = $strAlias.Value }
    else { $strAlias = '' }
    
    return $strAlias.Trim()
}

Puis, si les données que nous devons écrire sont contenues dans un tableau nous appelons Set-OpenXmlTable sinon nous appelons Set-OpenXmlText !

Comme nous avons bien avancé, nous allons faire une petite pause ! Je vous donne rendez-vous au prochain article pour la suite de notre petite aventure !

Création de fiche serveur avec Word 2007 et PowerShell (Partie 2)

2009-02-07T14:28:00.017+01:00

La partie précédente de cet article se trouve ici !
Nous voici à la première étape : Identification et récupération des informations pertinentes sur nos serveurs !

Dans cet article nous allons créer un module PowerShell capable de récupérer les informations des serveurs de notre parc informatique. Mais… c’est quoi un module ? C’est tout simplement un ensemble de fonctions : une sorte de librairie que nous pouvons réutiliser et partager !

Remarque : Les modules sont apparus avec PowerShell V2.

Pour faire notre premier module, nous allons créer un fichier nommé « Computer_Info.psm1 ». Remarquez l’extension .PSM1 du fichier ! La seconde chose à faire est d’y écrire nos fonctions qui iront chercher les informations de nos serveurs.

Ensuite, nos futurs scripts pourront faire appel aux fonctions de ce module. Vous l’aurez compris, les modules permettent de réutiliser le code, de faire des librairies ; bref de capitaliser !

Par défaut, PowerShell ira chercher nos modules dans les répertoires listés dans la variable d’environnement PSMODULEPATH ainsi que dans le répertoire courant du script faisant appel à un module. Pour afficher cette variable, exécutez la commande :

PS> $env:PSMODULEPATH

Nous pouvons donc commencer à récupérer les informations pertinentes de nos serveurs. Nous allons pour cela utiliser plusieurs méthodes. La première : WMI !
Cette première fonction que nous allons écrire dans notre module est une petite surcouche à la Cmdlet PowerShell Get-WmiObject. Elle nous permettra uniquement d’économiser quelques lignes de code…

function Get-WmiInfo($strClass, $strComputer)
{
    return Get-WmiObject -Class $strClass -Namespace 'root\cimv2' `
                         -ComputerName $strComputer
}

Nous allons également ajouter une autre petite fonction qui nous facilitera la vie…

function Add-Property($obj, $strProperty, $objValue)
{
    Add-Member -InputObject $obj -Type 'NoteProperty' -Name $strProperty `
               -value $objValue -force
}

La fonction Add-Property est une surcouche à la Cmdlet Add-Member permettant ici d’ajouter une propriété à un objet. Vous comprendrez pourquoi nous l’utiliserons un peu plus bas dans cet article !

Maintenant que nous avons écrit nos deux fonctions « outil », nous pouvons dans un premier temps récupérer les informations matérielles de nos machines :

function Get-ComputerHardware($strComputer)
{
    $objRes = New-Object Object
    $int = 0
    
    # Processors
    $obj = Get-WmiInfo 'Win32_Processor' $strComputer
    foreach ($objInfo in $obj) {
        Add-Property $objRes 'Is32Bit' ($objInfo.Architecture -eq 0x0)
        Add-Property $objRes 'Is64Bit' ($objInfo.Architecture -eq 0x9)
        $int++
    }
    Add-Property $objRes 'NbCPU' $int
    
    # BIOS
    $obj = Get-WmiInfo 'Win32_Bios' $strComputer
    Add-Property $objRes 'BIOS' $obj.Name
    
    # System
    $obj = Get-WmiInfo 'Win32_ComputerSystem' $strComputer
    $int = [int]($obj.TotalPhysicalMemory / 1024 / 1024 / 1024)
    Add-Property $objRes 'TotalMemory' "$int Go"
    Add-Property $objRes 'Manufacturer' $obj.Manufacturer
    Add-Property $objRes 'Model' $obj.Model
    Add-Property $objRes 'Domain' $obj.Domain
    Add-Property $objRes 'DNSName' ($obj.Name + '.' + $obj.Domain)
    Add-Property $objRes 'NetBIOSName' $obj.Name
    
    # Media
    $obj = Get-WmiInfo 'Win32_CDROMDrive' $strComputer
    foreach ($objInfo in $obj) {
        switch ($objInfo.MediaType)
        {
            'CD-ROM' { Add-Property $objRes 'MediaCD' $true }
            'DVD-ROM' { Add-Property $objRes 'MediaDVD' $true }
            'CD Writer' { Add-Property $objRes 'MediaCDRW' $true }
            'DVD Writer' { Add-Property $objRes 'MediaDVDRW' $true }
            default { }
        }
    }
    
    # Physical or virtual
    $obj = Get-WmiInfo 'Win32_BaseBoard' $strComputer
    $bln = ($obj.Manufacturer.Tolower() -contains 'microsoft') -Or
           ($obj.Manufacturer.Tolower() -contains 'vmware')
    Add-Property $objRes 'IsVirtual' $bln
    Add-Property $objRes 'IsPhysical' (-not $bln)
    
    # Network adapters
    Set-StrictMode -Off
    $obj = Get-WmiInfo 'Win32_NetworkAdapter' $strComputer |
           Where-Object { $_.PhysicalAdapter -eq $true } |
           Select-Object ProductName, MACAddress
    Set-StrictMode -Version 2.0
    Add-Property $objRes 'NetworkCards' $obj
    
    # Disks
    $obj = Get-WmiInfo 'Win32_DiskDrive' $strComputer |
           Select-Object Model, Size
    Add-Property $objRes 'Disks' $obj
    
    # Volumes
    $obj = Get-WmiInfo 'Win32_LogicalDisk' $strComputer |
           Where-Object { $_.DriveType -eq 3 } |
           Select-Object VolumeName, DeviceID, Size, FreeSpace
    Add-Property $objRes 'Volumes' $obj

    return $objRes
}

La fonction Get-ComputerHardware retourne un objet dont les propriétés sont les informations matérielles d’un ordinateur récupérées par différentes requêtes WMI !

Nous pouvons également récupérer des informations logicielles :

function Get-ComputerSoftware($strComputer)
{
    $objRes = New-Object Object
    
    # Operating system
    $obj = Get-WmiInfo 'Win32_OperatingSystem' $strComputer
    Add-Property $objRes 'OSName' $Obj.Caption
    Add-Property $objRes 'OSVersion' $Obj.Version
    Add-Property $objRes 'OSServicePack' $obj.CSDVersion
    Add-Property $objRes 'OSArchitecture' $obj.OSArchitecture
    
    # Services
    $obj = Get-Service -ComputerName $strComputer |
           Select-Object DisplayName, ServiceName, Status
    Add-Property $objRes 'Services' $Obj
    
    # KB
    $obj = Get-WmiInfo 'Win32_QuickFixEngineering' $strComputer |
           Sort-Object InstalledOn |
           Select-Object Description, HotFixID, InstalledBy, InstalledOn
    Add-Property $objRes 'KB' $Obj
    
    return $objRes
}

Remarquez ici l’utilisation de la Cmdlet Get-Service avec le paramètre –ComputerName qui existe depuis la V2 !

Maintenant que nous avons récupéré les informations matérielle et logicielle, nous avons presque terminé notre module !

Vous avez remarqué que nous avons écrit des fonctions « outil ». Nous aimerions donc que ces fonctions ne soient pas utilisables dans des scripts car sorties de leur contexte elles peuvent être mal utilisées.

Export-ModuleMember -Function 'Get-ComputerHardware',
                              'Get-ComputerSoftware'

La Cmdlet Export-ModuleMember nous permet d’exposer uniquement nos deux principales fonctions de notre module. Ainsi, les scripts qui utiliseront notre module ne pourront se servir que de ces deux fonctions !

Nous avons donc dans cet article :
1. Créé un module PowerShell V2,
2. Récupéré les informations matérielles et logicielles d’une machine.

Dans le prochain article, nous créerons notre document Word 2007 qui sera utilisé pour générer nos fiches serveurs !

Création de fiche serveur avec Word 2007 et PowerShell (Partie 1)

2009-01-28T19:27:00.009+01:00

Et si en quelques secondes il était possible de récupérer toutes les informations pertinentes de tous les serveurs Windows de notre système d’information, de générer des rapports détaillés et de les envoyer par e-mail à notre responsable tous les mois ?

Nous aurions plus de temps pour prendre notre café ? Certes… ou bien nous aurions plus de temps pour apporter une valeur ajoutée à notre travail !

Quoiqu’il en soit, dans cet article en plusieurs parties, nous allons réaliser cette automatisation !

Pour cela, nous aurons besoin de 2 choses :
1. PowerShell V2 : normal non ? :)
2. OpenXML SDK 1.0 : librairie que nous allons utiliser pour manipuler le format DOCX !

Si vous n’avez pas encore installé PowerShell V2, rendez-vous sur cet article ! Sinon… vous n’avez plus qu’à télécharger OpenXML SDK 1.0 et à l’installer.

Enfin, sachez qu’il existe des Cmdlets (commandes PowerShell) créées pour manipuler le format OpenXML sur lequel s’appuient les documents Office 2007 : les PowerTools. Ces Cmdlets peuvent nous faciliter la vie et le code (en C#) est ouvert à tous : que demander de plus ?

Pour installer les PowerTools, vous aurez besoin des sources et de les compiler avec Visual C# Express par exemple pour générer la DLL… Ou bien, récupérer celle que j’ai générée pour vous ici…

Pour l’installation, dans une fenêtre PowerShell :

PS> cd C:\Windows\Microsoft.NET\Framework64\v2.0.50727
PS> .\InstallUtil.exe C:\OpenXml.PowerTools.dll       
PS> Add-PSSnapin OpenXml.PowerTools

Installutil.exe se trouve dans le répertoire du Framework .Net 2. Dans l’exemple : « C:\Windows\Microsoft.NET\Framework64\v2.0.50727». La DLL PowerTools a été déposée à la racine de notre partition C :.

Maintenant que nous avons tous les pré-requis, nous pouvons entrer dans le vif du sujet : générer un document Word !

Nous allons découper notre travail en plusieurs étapes :

1. Identification et récupération des informations pertinentes sur nos serveurs,
2. Mise en page du document Word,
3. Génération du document avec les données récoltées.

Vous l’aurez sans doute compris, chaque étape fera l’objet d’un article pour plus de clarté et pour entretenir un suspens ! Ok je sors…

A très bientôt pour l’étape 1 ! En attendant, préparez-vous en installant les pré-requis !

PowerShell 2 : Introduction

2009-01-27T21:53:00.019+01:00

PowerShell est un outil en ligne de commande capable d’administrer une machine sous Windows. Voilà une définition très formelle, presque marketing… :)

La théorie c’est fantastique, cependant dans ce blog vous trouverez aussi beaucoup de pratique !

Mais avant, pour mon premier message nous allons mettre en place un environnement simple pour tester nos futurs scripts PowerShell.

Vous le savez sûrement, PowerShell est en version 1.0 ! Et bien nous n’utiliserons pas cette version… Mais la version 2 actuellement en cours de développement (CTP 3) !
Tant qu’à faire, autant s’investir sur la dernière version qui nous offre des possibilités très intéressantes que nous découvrirons au fur et à mesure.

Bref, la première chose à faire est de s’assurer que nous avons Windows XP SP3 ou Windows Server 2003 SP2 minimum comme système d’exploitation. Sachez cependant que certaines fonctionnalités de PowerShell V2 ne sont exploitables qu’à partir de Windows Vista SP1 et Windows Server 2008.

Ensuite, nous devons désinstaller toute version précédente de PowerShell si elles existent sur notre système puis nous pouvons enfin télécharger et installer ce dont nous avons besoin :

1. Framework .NET 2.0 : PowerShell rend accessible cette librairie en ligne de commande !
2. Framework .NET 3.5.1 : Si nous voulons utiliser l’éditeur intégré de PowerShell ; et nous le voulons !
3. PowerShell V2 CTP3 : notre outil en ligne de commande ainsi qu’un éditeur ; tout en un !
4. WinRM 2.0 CTP3 : pour utiliser les fonctionnalités d’administration à distance de PowerShell V2.

Une fois ces 4 composants installés dans l’ordre donné, nous allons commencer à nous amuser avec nos nouveaux jouets qui deviendront très vite indispensables… :)

Je ne vais pas m’étendre sur comment utiliser PowerShell ou l’environnement de script intégré (que j’ai appelé « éditeur » précédemment), ce n’est pas le but ici !
Cependant je vais tout de même expliquer en quelques mots comment « configurer » PowerShell pour utiliser les fonctionnalités d’administration à distance grâce à WinRM 2.0 !

WinRM est une implémentation faite par Microsoft du protocole WS-Management qui permet d’accéder à des machines distantes en utilisant le protocole HTTP ou HTTPS. Voilà qui est dit…

Bref, en pratique, c’est un service installé sur la machine que l’on doit démarrer… avec PowerShell !

Donc, dans une session PowerShell lancée en tant qu’administrateur local de la machine, taper la commande :

PS> Start-Service WinRM

Nous pouvons à présent utiliser le provider WSMan de PowerShell V2 pour la configuration. Pour administrer une machine distante avec PowerShell V2, la machine distante doit également avoir PowerShell V2 installé ! Dans ce cas, PowerShell agit comme une application client / serveur se connectant sur un port donné (par défaut 80).
Nous allons donc dire à notre PowerShell d’écouter sur un port précis :

PS> cd WSMan:\localhost\Listener                          
PS> New-Item –Path . –Address * -Transport HTTP –Port 8080

A ce stade, PowerShell utilisera le protocole HTTP et le port 8080 sur toutes les interfaces réseaux pour écouter et envoyer les requêtes provenant ou à destination d’autres machines ayant PowerShell V2.

Cette opération est donc à répéter sur toutes les machines que nous voulons administrer à distance.

Nous avons donc maintenant un petit environnement dans lequel nous exercer un peu…
Biensûr, je n’ai fait qu’effleurer le sujet pour le moment mais nous aurons l’occasion de découvrir plus en détail PowerShell V2 dans les prochains jours. Cependant, nous avons vu le minimum pour commencer à nous amuser avec notre outil !

Objectifs et fonctions de la phase Planification

2009-01-24T20:17:00.004+01:00

Au cours de la phase de Planification (Plan), les équipes métiers et techniques travaillent ensemble afin de déterminer comment l’informatique va offrir des services à valeurs ajoutées qui permettent à l'entreprise de réussir. Pour se faire, cela exige de:

Comprendre la stratégie business et ses exigences ainsi que la façon dont les actuels services informatiques supportent le business
Comprendre ce que la fiabilité représente pour l’entreprise et comment elle sera mesurée et améliorée, ainsi que les revues et les mesures permettant d’améliorer l'état actuel si besoin
Comprendre la stratégie de l'entreprise et comment elle affecte sa politique
Fournir la structure financière pour supporter les travaux informatiques et prendre les bonnes décisions

L'objectif de cette phase est de prendre les bonnes décisions sur la politique IT et le portefeuille de projets, en veillant à ce que les services fournis aient les attributs et résultats suivants:

convainquant en termes d'objectifs business
prévisible et fiable
efficace économiquement
en conformité avec les stratégies
adaptable à l'évolution des besoins de l'entreprise.

Revues de Gestion

2009-01-24T18:44:00.005+01:00

Pour chaque phase du cycle de vie, des revues de gestion (MR) servent à rassembler des informations et des personnes afin de déterminer le statut des services informatiques et de mettre en place les éléments préparatoires permettant d’avancer dans le cycle de vie. Les MRs sont des contrôles internes qui assurent des contrôles de validation de gestion, en veillant à ce que les objectifs soient atteints de façon adéquate, et que la valeur business soit considérée dans l'ensemble du cycle de vie des services IT. Les objectifs des revues de gestion, peu importe où elles se produisent dans le cycle de vie, sont simples:

Fournir un guide et une supervision de la gestion
Agir en tant que contrôles internes au niveau de la phase du cycle de vie
Évaluer l'état des activités et prévenir proactivement dans les phases suivantes
Capitaliser les notions organisationnelles
Améliorer les processus

Au cours d'une revue de gestion, les critères auxquels un service doit répondre pour se déplacer à travers le cycle de vie sont évalués par rapport à l’actuelle progression. Le MR permet de s'assurer que les objectifs sont atteints, et que les services informatiques sont en bonne voie pour livrer la valeur attendue.

La figure suivante illustre les phases du cycle de vie des services IT et les MR qui les relient :

Fonctions de gestion de services

2009-01-24T18:36:00.005+01:00

Chaque phase du cycle de vie des services informatiques contient des fonctions de gestion de service (Service Management Functions) qui définissent des processus, des personnes, et des activités requis pour aligner les services informatiques aux exigences du business. Chaque SMF a son propre guide pour expliquer le flux des fonctions et les détails des processus et activités qu’elle contient.

La figure suivante montre les phases du cycle de vie du service informatique et les SMFs intégrées à chacune des phases :

Bien que chaque SMF puisse être pensée comme un seul ensemble de processus, il est important de comprendre comment les SMFs, dans toutes les phases, fonctionnent pour s’assurer que la fourniture des prestations de services est au niveau de qualité et au niveau de risque attendus. Dans certaines phases (telle que Deliver), les SMFs sont exécutées de façon séquentielle, alors que dans d'autres phases (telle que Operate), les SMFs peuvent être réalisées simultanément pour créer les livrables de la phase.

Cycle de vie des services IT

2009-01-11T20:15:00.007+01:00

Le cycle de vie des services IT décrit la vie d'un service informatique, de la planification et l'optimisation des services IT pour les aligner sur la stratégie de l'entreprise, en passant par la conception et la livraison des services informatiques, ainsi que les opérations et le support. Sous-jacent à tout cela se trouvent les fondements de la gouvernance des technologies de l’information, de la gestion des risques, de la conformité, de l’organisation des équipes et de la gestion du changement.

Les phases du cycle de vie Le cycle de vie des services IT est composé de trois phases courantes et d’un niveau de base qui fonctionne avec l'ensemble des autres phases. Ces phases sont les suivantes:

Phase de Planification (Plan)
Phase de Fourniture (Delivery)
Phase d’Exploitation (Operate)
Niveau de Gestion (Manage)

Votre organisation gère sans doute de nombreux services IT à tout moment, et ces services IT peuvent se situer dans différentes phases du cycle de vie des services IT. Par conséquent, MOF vous sera profitable si vous comprenez la façon dont toutes les phases du cycle de vie fonctionnent et la façon dont elles travaillent ensemble.

La phase de Planification est généralement la phase préliminaire. L'objectif de cette phase est de planifier et optimiser une stratégie de services IT afin de soutenir les buts et objectifs métiers.
La phase de Fourniture est la suivante. L'objectif de cette phase est de faire en sorte que les services soient développés de manière efficace, soient déployés avec succès, et soient prêts pour l’exploitation.
La suivante est la phase d’Exploitation. L'objectif de cette phase est de s'assurer que les services IT soient gérés, entretenus et supportés d'une manière qui réponde aux besoins et exigences métiers.
Le niveau de Gestion est la base du cycle de vie des services IT. Son objectif est de fournir des principes de fonctionnement et les meilleures pratiques visant à assurer que l'investissement dans les Technologies de l’Information (TI) fournit la valeur attendue à un niveau acceptable de risque. Cette phase concerne la gouvernance des TI, les risques, la conformité, les rôles et les responsabilités, la gestion du changement et la gestion des configurations. Les processus de cette phase prennent place à toutes les phases du cycle de vie.

En suivant les guides contenus dans MOF cela peut vous aider à:

Diminuer les risques par une meilleure coordination entre les équipes
Reconnaître l’implication de conformité quand les stratégies sont passées en revue
Anticiper et atténuer les impacts
Découvrir les potentiels problèmes d'intégration, avant une mise en production
Prévenir les problèmes de performance grâce à une anticipation des seuils
Vous adapter efficacement à de nouveaux besoins métiers

Quand un service informatique est mis en production pour la première fois, il est généralement le résultat d'une nouvelle initiative: conduite par l’informatique ou les métiers. Tout au long du cycle de vie du service, chaque fois que des modifications mineures, majeures ou importantes, sont réalisées, les phases du cycle de vie des services IT MOF doivent être appliquées.
Utilisez les phases du cycle de vie des services IT MOF, quelle que soit la taille ou l'impact d'un changement. Les formalités avec lesquelles vous appliquerez le cycle de vie sont proportionnelles aux risques du changement. Vous devez faire ce qui est requis, ni plus ni moins. Par exemple, une nouvelle initiative d'envergure, comme un nouveau service sur lequel une fonction métier dépend, doit passer par, une analyse en profondeur et une revue dans la phase de planification, un plan projet formel dans la phase de fourniture, et une préparation ainsi qu’ une revue de la façon dont le service sera mis en œuvre, supporté et supervisé dans la phase d’exploitation.
Dans la phase de Planification, les exigences sont définies avec les métiers, les stratégies sont vérifiées et des arbitrages fiables sont faits. Dans la phase de Fourniture, le changement est conçu et testé. Dans la phase d’Exploitation, le changement est réalisé dans l'environnement de production, le service est alors supervisé et si besoin, des ajustements sont faits, un support est fourni pour aider les utilisateurs et répondre aux questions qu’ils se posent sur les problèmes qui peuvent se poser suite au changement. Tout cela peut être réalisé très rapidement pour des changements mineurs à faible risque, en utilisant un minimum de processus MOF.

Introduction à MOF

2009-01-11T18:36:00.007+01:00

Tout d'abord et avant de mixer des opérations permettant d'automatiser des opérations IT suivants les processus MOF et utilisant du code PowerShell, je vais au fil de l'eau traduire et vous faire partager le contenu des guides MOF fournit gratruitement par Microsoft.

Microsoft ® Operations Framework (MOF) se compose de bonnes pratiques intégrées, de principes et d’activités qui fournissent des directives détaillées pour la réalisation de solutions et de services fiables. MOF fournit des guides basés sur des questions qui vous permettent de déterminer ce qui est actuellement nécessaire à votre organisation, ainsi que des activités qui permettront d'assurer le fonctionnement informatique de manière efficiente et efficace.

MOF intègre toutes les activités et les processus impliqués dans la gestion des services IT : conception, déploiement, exploitation, maintenance, et retrait. MOF organise ses activités et ses processus sous forme de fonctions de gestion de services (Service Management Functions), qui sont regroupées ensemble dans des phases qui reflètent le cycle de vie des services IT.
Chaque SMF est intégrée dans une phase du cycle de vie et contient un ensemble d'objectifs et de résultats. Un audit de service informatique permettant de passer d'une phase à l'autre est confirmé par des revues de gestion, qui veillent à ce que les objectifs soient atteints de façon appropriés et que les objectifs soient alignés avec les objectifs de l'entreprise.

L'objectif de MOF est de fournir des guides aux organisations informatiques afin de les aider à créer, exploiter et supporter des services tout en veillant à ce que l’investissement informatique fournisse la valeur attendue à un niveau acceptable de risque.
MOF a pour but de créer un environnement où les services métiers et informatique peuvent travailler ensemble, en utilisant un modèle dynamique, qui définit les processus et les procédures standards pour gagner en efficience et en efficacité. MOF favorise une approche logique pour la prise de décision, la communication ainsi que la planification, le déploiement et le support des services informatique.

Bienvenue

2009-01-08T23:50:00.005+01:00

Bonjour et bienvenue sur ce Blog dédié au développement PowerShell orienté Processus et Bonnes Pratiques. Vous y trouverez des informations sur les bonnes pratiques ITIL associées aux technologies Microsoft ainsi que des idées de mises en oeuvre automatisées d'opérations IT, ces informations se baseront sur les éléments suivants :

Microsoft Operations Framework (MOF)
Microsoft PowerShell
Guides opérationnels Microsoft

Ce blog est principalement destiné aux architectes, administrateurs, et ingénieurs système souhaitant trouver des informations et solutions simples permettant d'optimiser et simplifier leurs opérations techniques récurrentes de gestion des infrastructures Microsoft.

Bonnes lectures
Mouloud