PI Services

Problématique

Sur certains smartphones (BlackBerry et Windows Phone) lors de la connexion à une boite mail Exchange 2010 (via ActiveSync) le mot de passe est demandé alors qu’il est enregistré.

Une resynchronisation de la BAL sans indiquer le mot de passe suffit au smartphone pour se reconnecter.

Contexte

L’architecture en place lors du problème se compose de plusieurs serveurs Exchange 2010 (plusieurs serveurs CAS/HUB, plusieurs MBX en DAG) et de deux serveurs TMG 2010 pour la publication des flux.

Après avoir fait des traces sur TMG, l’erreur suivante est présente à chaque demande de mot de passe :

• Log Type : Web Proxy (Forward)
• Status : 10054 An existing connection was forcibly closed by the remote host.

Solution

Le problème provient de TMG. En effet ce dernier possède un timeout sur la session ActiveSync entre le Smartphone et Exchange.

Pour résoudre ce problème il faut changer un paramètre dans TMG. Depuis la console TMG faites un clic droit sur le listener qui publie ActiveSync, ensuite dans Properties, Forms tab, Advanced décochez la case “apply session timeout to non-browser client” (http://technet.microsoft.com/en-us/library/cc995246.aspx).

L’interaction Orchestrator-Scom est intéressante sous réserve d’introduire dans les runbooks concernés un peu de corrélation afin de ne pas générer trop d’alerte et de pouvoir les clôturer automatiquement.

L’exemple ci-dessous est un peu limité. En effet:

1/ Le runbook ne détecte pas si une alerte précédente est présente.

2/ Il ne prévoit pas de cas OK associé a une fermeture automatique de l’alerte potentiellement générée avant. (sous réserve que l’on veuille cette clôture automatique)

Ajoutons a ce runbook quelques éléments:

Si le programme sort OK (Exit = 0) , le nœud “Get Not Closed Alert” cherche les alertes précédemment générées et toujours dans un état autre que Closed, puis si une plusieurs alerte sont trouvées, le nœud Close Alert les clôtures.

Si le programme sort KO (Exit <> 0), le nœud “Get Not Closed Alert” cherche les alertes précédemment générées. Si une alerte est présente, inutile d’en générer une autre pour le même problème, sinon elle est crée par le nœud Create Alerte.

L’idéal, serait dans le second cas d’incrémenter le champ Repeat count de l’alerte existante mais on attends que l’Integration Pack de SCOM intègre cette possibilité dans une prochaine version  .

Il n’est pas possible directement dans la console Orchestrator de faire le lien entre une instance de runbook et son process policymodule.exe.

Pour cela il faut faire le lien entre le PID du job effectivement en cours d’exécution, dans la base Orchestrator et le PID du process apparent dans le gestionnaire de tache.

Le script suivant prend en paramètre le nom du runbook.

Il est nécessaire de modifier le nom de l’instance SQL ($SQLServer)

Le script renvoi la mémoire (Private Working Set (Ko)) car cette info est particulièrement intéressante mais d’autre compteur peuvent bien sur être récupérés.

Param(
#[parameter(Mandatory=$true)]
[string]$Runbook
)

$Global:Runbook = $args[0]

$Scriptname = "getRunbookJobPid"
$SQLServer = ""
$SQLDBName = "Orchestrator"
$SQLTempDB= "Temp_$Runbook"+"_$Scriptname"

#FUNCTIONS
function GetProcessInfoById
{
    param
    ([int]$processId)

    Get-WmiObject -class Win32_PerfFormattedData_PerfProc_Process | where-object {$_.idprocess -eq $processId} | select `
    @{Name="Process Id"; Expression = {$_.idprocess}},`
    @{Name="Private Working Set (Ko)"; Expression = {$_.workingSetPrivate / 1kb}}        
}

#END_FUNCTIONS


$SqlQuery = "
SELECT MAX(DATEADD(HOUR,2,TimeStarted)) as TimeStart
      ,ProcessID as ProcessId
      ,Name as Name
      ,j.Status as Jstatus
      ,RI.status as RIStatus
      
      INTO $SQLTempDB
      
  FROM [Orchestrator].[dbo].[POLICYINSTANCES] as p WITH (NOLOCK)
  inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].[Jobs] as j on j.id=p.JobId
  inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator].[Runbooks] as R on R.Id=j.RunbookId
  inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI on RI.RunbookId=R.Id
  
  WHERE RI.status = 'InProgress'
  AND j.Status = 'Running'
  AND R.Name = '$Runbook'
  
  
  GROUP BY TimeStarted
      ,ProcessID
      ,Name
      ,j.Status
      ,RI.status
      
        

DECLARE @MaxDate DateTime
SET @MaxDate = (SELECT MAX(TimeStart) FROM $SQLTempDB)

SELECT ProcessId from $SQLTempDB
WHERE TimeStart = @MaxDate

DROP TABLE $SQLTempDB"


if (-not($Runbook))
{
throw "Nom du runbook requis"
}

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server = $SQLServer; Database = $SQLDBName; Integrated Security = True" 
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $SqlQuery
$SqlCmd.Connection = $SqlConnection 
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd 
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet) 
$SqlConnection.Close() 
#clear 
$ProcessId= $DataSet.Tables[0] | Select-Object -Property ProcessId -ExpandProperty ProcessId

write-host "RUNBOOK: $Runbook"
GetProcessInfoById $ProcessId | fl

Dans certains cas un runbook nouvellement crée peux ne pas apparaitre dans la console Web ou dans les applications tierces recevant le nom du runbook (SCOM – SCSM).

Pour débuguer ce problème:

- Ouvrez SQL Management Studio et connectez vous a l’instance de la base Orchestrator.

- Exécutez la requête suivante:

Use Orchestrator

TRUNCATE TABLE
[Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache

- Rafraichissez l’affichage de la console Web pour faire apparaitre le runbook

Pour automatiser la réponse a ce problème, vous pouvez automatiser via un job sql l’exécution de la requête suivante afin de forcer un vidage du cache des autorisations:

Use Orchestrator

EXEC [Microsoft.SystemCenter.Orchestrator.Maintenance].EnqueueRecurrentTask ‘ClearAuthorizationCache’

Contexte

Suite au déploiement de Lync Server 2013, certains clients souhaitent améliorer la visibilité du produit au sein d’Outlook en rajoutant une icône dans la page d’accueil Outlook (par défaut pour créer une réunion Lync, il faut aller dans la partie calendrier).

Problématique

Cette personnalisation d’Outlook n’existe pas dans les modèles d’administration / personnalisation  d’Office (http://www.microsoft.com/en-us/download/details.aspx?id=35554). Cependant il est possible de déployer ce paramètre par GPO.

Solution

N.B : Cette solution a été testée sous Outlook 2010 et 2013.

Lors de la personnalisation du ruban d’Outlook ce dernier créer le fichier olkexplorer.officeUI. Ce fichier se trouve à l’emplacement suivant :

• Sous Windows XP : %Userprofile%\Local Settings\Application Data\Microsoft\Office\
• Sous Windows 7/8/8.1 :  %userprofile%\AppData\Local\Microsoft\Office\

Il suffit alors de personnaliser le ruban depuis un poste et de récupérer le fichier olkexplorer.officeUI.

Le déploiement du fichier se fait ensuite via un script lancé au démarrage du poste via GPO.

Avant :

Après :

Si l’on s’en fie à Technet, ( http://technet.microsoft.com/en-us/library/hh457546.aspx ), l’utilisation d’IE 10 (et par extension IE 11) n’est pas supportée pour réaliser l’enregistrement d’une session de navigation Web dans SCOM.

Un test rapide le confirme : le plugin Web Recorder ne se charge pas.

On pourrait croire qu’il s’agit du problème bien connu de compatibilité du plugin avec IE x86/x64 (http://social.technet.microsoft.com/wiki/contents/articles/1307.scom-howto-use-the-webrecorder-on-windows-64bit.aspx), mais il n’en est rien…

Fort heureusement, il reste possible de faire fonctionner l’enregistrement dans IE 10 et 11 moyennant quelques ajustements.

Dans Internet Explorer, ouvrir le menu Outils > Options Internet, onglet Avancé.
Vérifier que les cases Activer les extensions tierce partie du navigateur (Enable third party browser extensions) et Activer le mode protégé amélioré (Enable Enhanced Protected Mode) sont cochées et les cocher si elles ne le sont pas.

Quitter IE et ouvrir l’éditeur de registre regedit.

Naviguer jusqu'à la clé de registre suivante : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main
Ajouter une entrée de type DWORD nommée TabProcGrowth et lui donner la valeur 0

Puis naviguer jusqu’à la clé HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories64\
Supprimer les deux sous-clés {00021493-0000-0000-C000-000000000046} et {00021494-0000-0000-C000-000000000046} . Ces clés correspondent à un cache d’information concernant le plugin WebRecorder, les supprimer force donc IE à remettre en cache ces informations.

Redémarrer l’ordinateur sur lequel est effectuée la capture si des modifications ont été apportées aux paramétrages avancés d’Internet Explorer.

Relancer une capture depuis SCOM. Au lancement d’IE, la barre apparait :

Alternativement, un prompt d’activation du plugin peut apparaitre au lancement d’IE (accepter l’activation) et il peut être nécessaire d’afficher la barre Web Recorder via le menu Affichage > Volets d’Exploration.

Introduction

Le thème abordé est la gestion d'événements sous Powershell. Il s'agit d'une notion peu connue dans ce langage de scripting mais permettant d'interagir automatiquement avec le système si un événement est détecté. Ceux-ci peuvent être : 

• Le démarrage d'un process
• Un changement sur un dossier
• La fin d'un timer
• Un changement d'état dans un job Powershell
• ...

Dans un premier, nous verrons comment connaître les objets pouvant être observés et comment gérer les événements via la Cmdlet Register-ObjectEvent, ensuite nous traiterons le cas particulier des événements WMI, puis celui des événements liés à la console Powershell. Enfin, un exemple d'utilisation sera montré (détection des changements dans un dossier).

Avant de débuter, il faut savoir que les événéments gérés, ne le sont que dans la session Powershell en cours (c'est à dire que la remontée d'événements s'arrête dès qu'on quitte la session Powershell). Il existe toutefois une méthode pour créer une gestion d'événements permanente, mais elle ne fonctionne que pour les événements en WMI. Pour faciliter sa mise en place, je vous invite à vous tourner vers l'excellent module PowerEvents : http://powerevents.codeplex.com/.

Les événements des objets Powershell

Pour connaître si un objet Powershell peut être géré via des événements, il suffit d'utiliser la commande Get-Member.

En exécutant la commande suivante :

Il est aussi possible de les obtenir via la méthode GetEvents :

On obtient le résultat :

On remarque que 2 de ces membres sont de type Event (Elapsed et disposed). Ces derniers vont donc pouvoir être utilisé via la cmdlet Register-ObjectEvent.

Exemple pour l’événement Elapsed (fin d’un timer) :

Lorsque l'on lance cette commande, elle crée un job Powershell (similaire à ceux lancés par la commande Start-Job). Dans cet exemple nous voulons monitorer la fin d'un timer pour récupérer les données transmises par un job Powershell à chaque seconde. On crée un objet de type Timer qui a un interval de 1 seconde (en millisecondes). Ce dernier tourne en boucle grâce à l'attribut autoreset. L'événements à surveiller est "Elapsed". On le retrouve dans la commande Register-ObjectEvent avec le paramètre EventName. Le paramètre Action définit le processus exécuté lorsque l'événment est détecté. Il s'agit d'un scriptblock (entre accolades, ici notre variable “ActionTimer”).

Il est possible de passer des données pour qu'elles soient traiter dans l'action. Cela se fait via le paramètre MessageData (N'importe quel type d'objet peut être consommé). Ces données sont ensuite accessible via la variable $event.MessageData. Nous récupérons donc la propriété Id de l'objet Job Powershell afin de recevoir les données via la commande Receive-Job. Pour que l'événement soit remonté , il est obligatoire de fournir l'objet Timer en tant qu'InputObject. Enfin, SourceIdentifier est simplement le nom du job.

Si l'on souhaite arrêter d'observer les événements d'un objet Powershell, il faut utiliser la commande Unregister-ObjectEvent conjointement à Get-EventSubscriber qui récupère l'ensemble des événements observés.

Cette commande arrête la remontée de tous les événements. On peut bien entendu filtrer les événements à ne plus gérer via la cmdlet Where-Object par exemple.

Les événements en WMI

On remarque entre autre des classes pour récupérer :

• les changements dans les clés de registre
• les démarrages et arrêts de processus
• l'arrêt ou la fermeture de session d'un utilisateur
• l'ajout d'un lecteur (disque dur, clé usb)
• ...

Pour surveiller un événements en WMI on utilise cette fois la commande Register-WMIEvent.

La requête effectue une recherche toutes les 2 secondes sur la classe __InstanceCreationEvent. Elle est basé sur le langage WQL dont on peut retrouvé la syntaxe sur le lien suivant :
http://msdn.microsoft.com/en-us/library/windows/desktop/aa394606(v=vs.85).aspx

On retrouve les paramètres sourceIdentifier et Action vues précédemment avec la commande Register-ObjectEvent.

Les événements de la console Powershell

On peux écouter deux événements sur la console Powershell. Lorsqu'elle est fermée (Exiting) et lorsqu'elle est en état Idle (OnIdle). Ainsi, on peut exécuter des actions quand l'un de ces états est atteint. Cette opération s'effectue via la commande Register-EngineEvent :

La syntaxe est semblable à celle de la commande Register-ObjectEvent sauf que c'est le paramètre SourceIdentifier qui contient le non de l'événement (on aura donc 2 SourceIdentifier possibles : Powershell.Exiting et Powershell.OnIdle).

NB : Depuis Powershell 3.0, un troisième événement semble exister : WorkflowJobStartEvent. Cependant, il n'est à l'heure actuelle (au 23/05/2014) pas documenté.

Exemple d'utilisation :

Le script commenté ci-dessous déplace les fichiers d'un répertoire à un autre lorsqu'un nouveau fichier apparaît. Un premier événement sur l'objet de type FileSystemWatcher est récupéré : Created. Lors de la remontée de cet événement (à chaque création de fichier) le chemin du fichier est retourné. Un second objet de type Timer est surveillé. A chaque seconde, il récupère les résultats du Job précédent (les chemins de fichiers). Il les ajoute à une liste puis il traîte cette liste en essayant de déplacer les fichiers. Deux résultats sont alors possibles :

• Si le transfert réussi, alors le chemin initial est supprimé de la liste des fichiers à transférer.
• Si le déplacement échoue (fichier en cours d'écriture par exemple) alors il retentera de le déplacer au prochain déclenchement de l'événement (après 60 tentatives le transfert n'est plus réalisé).

Les différentes opérations sont logguées dans l'observateur d'événements.

NB : Si le fichier existe déjà à la destination, un horodatage est ajouté en suffixe du nom du fichier.

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Windows 2012/8 et Windows 2008 R2/7.

Lors du précédent article nous avons vu le fonctionnement du mode Pull puis son implémentation. Cette dernière se base sur un partage SMB permettant à tous les clients d'aller récupérer leur configuration par ce biais.

Dans cette quatrième partie, nous aborderons l'implémentation du mode Pull via un web service.

Fonctionnement

Le fonctionnement du mode Pull est expliqué dans la Partie 2 de ce guide sur DSC. Dans le mode Pull via web services, seul la façon de publier les fichiers de configurations et l'implémentation changent. Au lieu d'utiliser un partage, les clients DSC interrogerons à intervalle régulier une URL pour récupérer leur configuration :
“http://PullServerName:8080/PSDSCPullServer/PSDSCPullServer.svc" où PullServerName représente le nom du serveur Pull.

Contrairement au mode Pull via partage SMB, il n'est possible de déployer le Web Services que sur une version Serveur de Windows. Celui-ci se base sur la fonctionnalité Windows Powershell Desired State Configuration Service. Cependant, via le web service, il est possible de sécuriser la connexion avec l'usage de certificat.

Nous retrouvons les mêmes étapes que pour un serveur Pull via partage. Les clients ont un GUID unique de configuration. Ils récupèrent le fichier .mof portant ce GUID. Une vérification d'intégrité du fichier est effectuée grâce à un fichier portant le même GUID avec l'extension .mof.checksum.

Implémentation du web service

Dans cette section, j'explique comment mettre en place un serveur Pull avec Web Service de façon manuelle afin de comprendre les différentes briques de cette fonctionnalité. Dans le dernier paragraphe, vous trouverez des liens vers des ressources Desired State Configuration permettant de réaliser toute cette configuration beaucoup plus rapidement.

Tout d'abord, on installe le service DSC en graphique ou via la commande :

Toute une série de dépendance est ainsi installée dont notamment IIS et le Windows Process Activation Service.

Puis dans IIS, on crée un nouveau pool d'application (DSCApplicationPool) qui sera lancé avec le compte Local System (Sur le pool d’application choisir “Advanced Settings” puis “Identity”).

On crée un nouveau site (Exemple : DSCPullSite) utilisant notre pool d’application nouvellement créé et on le fait pointer vers un dossier de son choix. Ce dernier contiendra les sources du web service.

Dans le dossier du site web IIS, on crée un répertoire bin dans lequel on copie le fichier Microsoft.Powershell.DesiredStateConfiguration.Service.dll contenu dans $pshome/modules/psdesiredstateconfiguration/pullserver ($pshome correpond à C:\Windows\System32\WindowsPowerShell\v1.0 si vous avez une installation classique de Windows). 

Il faut ensuite copier les fichiers suivants contenu dans le dossier  $pshome/modules/psdesiredstateconfiguration/pullserver à la racine du site web :

• Global.asax 
• PSDSCPullServer.mof 
• PSDSCPullServer.svc 
• PSDSCPullServer.xml 
• PSDSCPullServer.config : il doit être renommé en web.config

L'arborescence doit être identique à celle ci-dessous :

Il faut ensuite autoriser les différentes méthodes d'authentification en réalisant un "unlock" sur les sections adéquate du fichier web.config que nous avons copié (anciennement PSDSCPullServer.config).

Le résultat peut être vérifié dans le fichier C:\Windows\System32\inetsrv\config\applicationHost.config 

Lors de l'installation du service DSC, une hiérarchie de dossier a été créée dans C:\Program Files\WindowsPowerShell\DscService :

• Configuration : dans ce dossier, il faut placer les fichiers .mof et .mof.checksum (renommé avec un GUID, voir Partie 2).
• Modules : Contient les éventuels modules dont on pourrait avoir besoin.

Pour terminer la configuration du serveur Pull, il faut copier le fichier $pshome/modules/psdesiredstateconfiguration/pullserver/Devices.mdb vers le dossier C:\Program Files\WindowsPowerShell\DscService

L'url du web service (http://PullServerName/PSDSCPullServer.svc) est maintenant opérationnelle !

Ressource LocalConfigurationManager

La ressource LocalConfigurationManager (déjà rencontrée dans les autres articles sur DSC) doit être configurée pour utiliser le web service.

Cette configuration est similaire à celle de la Partie 2 et 3. On retrouve le ConfigurationID permettant de récupérer les bons fichiers .mof. Les paramètres à changer sont :

• DownloadManagerName : Il prend la valeur WebDownloadManager. 
  DownloadManagerCustomData : Il contient un hashtable avec l'url du web service et un second paramètre AllowUnsecureConnection utile si vous n'utilisez pas de certificat.

Annexe

Depuis la sortie de Powershell V4.0, Microsoft s'est employé à fournir de nombreuses nouvelles ressources pour DSC. Celles-ci sont disponibles en suivant le lien ci-dessous :
http://gallery.technet.microsoft.com/scriptcenter/DSC-Resource-Kit-All-c449312d

Ces ressources sont précédées d'un "x" car elles sont encore considérées comme expérimentales. Parmis toutes ces nouvelles ressources (plus d'une cinquantaine !), il y en a une pour déployer un server Pull facilement (xDscWebService). Cette dernière permet d'effectuer toutes les opérations fastidieuses que l'on a mis en place dans la section précédente (création d'un pool d'application, d'un site web, copie des différents fichiers,...).

On retrouve les paramètres tel que le nom du pool d'application (EndpointName), le chemin vers le site web (PhysicalPath),... Cela nous permet aussi de pouvoir customiser simplement les chemins qui vont contenir nos fichiers .mof et .mof.checksum ainsi que les ports utilisés par DSC et l'intégration d'un certificat.

Contexte

Dans certains cas, il faut déployer un patch Microsoft sur plusieurs serveurs. Mais comment savoir simplement et rapidement si le patch est bien installé, surtout si vous ne disposez pas de la solution System Center ?

Tout simplement avec un script Powershell. Voyons comment faire.

Dans mon exemple ci dessous, je veux savoir si un KB est installé sur tous les contrôleurs de domaine de tous les domaines de toute ma forêt Active Directory.

Compatibilité

Tout d’abord, ce script s’appuie sur des cmdlets (Get-Job et Get-Hotfix notamment) qui ne sont disponibles qu’avec Powershell version 2 minimum. Pensez à vérifier votre version de Powershell.

Fonctionnement

Dans un premier temps, il faut passer le paramètre “hotfix” au script.

Lors du lancement du script, voici les étapes :

1. 1- Vérification de la syntaxe du paramètre. Il doit être au format “KBxxxxxx”.
2. 2- Récupération de la liste de tous les domaines de la forêt Active Directory.
3. 3- Interroge Active Directory pour récupérer la liste des contrôleurs de domaines en demandant les membres du groupe 'Domain Controllers' pour chaque domaine.
4. 4- Récupération des identifiants pour se connecter à tous les DC.
5. 5- Création des jobs, avec un job par serveur et maximum 15 jobs simultanés (paramètre $MaxThreads ligne 9).
6. 6- Récupération des résultats des jobs.
7. 7- Affichage d'un résumé.
8. 8- Exportation des résultats.

Les jobs Powershell sont utilisés ici afin d’augmenter la rapidité d’exécution. Sinon, les serveurs serait interrogés les uns après les autres. Cette solution fonctionne tout aussi bien, mais demande beaucoup de temps. L’intérêt des jobs est de pouvoir lancer plusieurs requêtes en parallèle. Toutefois, attention à la consommation mémoire car il y’a autant de processus Powershell en mémoire, qu’il y’a de jobs.

Script

Utilisation

Il faut sauvegarder le script ci dessus avec le nom “Check_Hotfix_Installation.ps1”. Ensuite il suffit d’appeler le script dans une console Powershell (en Administrateur) comme ceci : “Check_Hotfix_Installation –Hotfix KB2413670”

Conclusion

Avec un simple script Powershell et l’utilisation des jobs, on peut vérifier énormément de serveurs et très rapidement. Rien empêche de modifier le script pour déclencher l’installation du hotfix avant la vérification, ou encore de cibler des serveurs plutôt que des contrôleurs de domaine.

Libre à vous d’adapter ce script selon vos besoins !

Introduction

Après le Management Framework 4.0 qui apportait Desired State Configuration, la Powershell Team vient de publier Management Framework 5.0 Preview (le 03/04/2014). Cette nouvelle version intervient seulement 6 mois après la sortie de la V4.0. Microsoft accélère son cycle de développement avec des versions contenant moins de nouveautés mais celles-ci restent tout de même importantes.

Le Management Framework 5.0 est pour l'instant compatible uniquement avec Windows Server 2012 R2, Windows 8.1 Pro et Enterprise mais Microsoft parle d'une rétrocompatibilité avec d'autres versions à venir.

Voici le lien vers l'update a installé :
http://www.microsoft.com/en-us/download/details.aspx?id=42316

Il contient Powershell V5.0 et Powershell ISE.

Il est temps de faire le tour des nouveautés !

Générales

Comme à chaque nouvelle version de Powershell, on nous annonce moins de bugs, de meilleures performances et des nouvelles Cmdlets.

Desired State Configuration

Des corrections de bug et des améliorations de performances sont au programme. La Team Powershell indique que Desired State Configuration est une technologie importante pour eux. C'est logique quand on voit le nombre de ressources (plus de 50) qui a été développé depuis la sortie de Powershell V4.0 : http://blogs.msdn.com/b/powershell/archive/2014/03/28/dsc-resource-kit-wave-3.aspx . Ils indiquent que la stratégie de Microsoft est de pousser l'intégration de DSC avec les outils de gestion de configuration (SCCM ?) et que lors d'un choix de ce type de solution, il sera important qu'elle soit compatible avec DSC.

Switch

Powershell V5.0 propose un module natif permettant de manipuler ses switchs. Microsoft a travaillé avec les leaders de l'industrie afin d'élaborer un standard. Les équipements compatibles porteront la certification "Certified for Windows". Au delà de Powershell, ce standard est utilisé dans SCVMM 2012. Cette technologie fait partie de la politique "Datacenter Abstraction Layer" de Microsoft. Elle vise à gérer l'intégralité d'un Datacenter via un même outil de management au lieu d'avoir une vision réduite à un équipement. Elle permettra d'éviter la multiplication des outils de gestion.

Le module qui permet de manipuler les switchs est : NetworkSwitch. Pour être compatible avec ce standard, le switch devra supporté les sessions distantes CIM. Pour rappel, c'est un standard ouvert développé par la DMTF (Distributed Management Task Force) qui définit les interractions entre des équipements ainsi que leur gestion, supervision, etc sous la forme d'un schéma. Ce schéma est orienté objet. WMI est notamment compatible avec ce standard (depuis Powershell V3.0 via les Cmdlets comme Get-CIMClass, Set-CIMInstance, ...).

Voici la liste des commandes de ce module :

Parmi les fonctionnalités, il est ainsi possible de :

• réaliser la configuration générale du switch : nom d’hôte, bannière, activation/désactivation de fonctionnalités
• gérer les vlan : création, suppression, activation, désactivation, listing
• configurer les ports : activation, désactivation, listing, définition des propriétés

OneGet

On termine ce tour des nouveautés, avec la fonctionnalité qui va sans doute faire le plus parlée d'elle : OneGet. C'est tout simplement un gestionnaire de paquet comme on peut en rencontrer sur Unix !

Pour obtenir la liste des commandes disponibles :

On peut utiliser la commande Find-Package pour chercher 7zip par exemple :

Puis-on l'installe (Install-Package) :

Bien entendu, comme tout gestionnaire de paquet, il s’occupe également d’installer automatiquement les dépendances.

La commande Get-Package permet de récupérer les packages déjà installé. Le package apparaît dorénavant dans le Start Screen (ou dans Program Files) comme n’importe quel autre programme :

Dans cette version preview, OneGet ne possède qu'une seule source (ou repository) : Chocolatey (https://chocolatey.org/packages) qui contient actuellement plus de 1700 package. Ce dernier est basé sur NuGet (connu des utilisateurs de Visual Studio) qui est justement un gestionnaire de package. Microsoft ajoutera le support d'autres repositories ultérieurement. On peut même imaginer qu'il sera possible de créer sa propre source et de l'ajouter via la commande Add-PackageSource. Certaines personnes ont d'ailleurs déjà commencé à le faire : http://learn-powershell.net/2014/04/11/setting-up-a-nuget-feed-for-use-with-oneget/.