PI Services

Le blog des collaborateurs de PI Services

Lync 2013 – Meeting personnalisés

Lors de la création d’un meeting Lync (via Outlook), le contenu de la demande peut paraitre très simpliste. Surtout quand l’intégration à la téléphonie n’est pas réalisée:

image Dans lync 2013, de nouvelles options sont disponibles pour rendre la demande de meeting plus personnalisé et adapté via des “meeting configuration” particulière. Voici les 4 nouveaux paramètres:

    • Logo URL
    • Help URL
    • Legal Text URL
    • Custom Footer Text

      Pour configurer ses élément il suffit d’éditer la configuration des meeting par default ou encore de certaines politiques appliquer a un partie des utilisateurs:

      image
    Il est aussi possible d’utiliser le Lync Management Shell via la commande:

      set-CsmeetingConfiguration avec les paramètres –LogoURL –Legalurl –helpURL –CustomFooterText.
      Une fois la configuration réaliser, les champs sont appliquer et les demandes de meeting prennent en compte les paramètres fixés:
    image Vous pouvez stocker les images directement sur le server FrontEnd Lync Server.

Interaction Powershell - Exchange Web Services

Introduction

Avec Exchange 2010, pour certains besoins bien spécifiques, il se peut que les cmdlets Powershell soit limitées. Cependant, il existe aussi les Exchanges Web Services. Bien entendu, quand on parle des Exchange Web Services, on pense au C# et à un développement complexe. Cependant, on n'oublie souvent que Powershell permet d'exécuter du C#.
Il sera donc question d'accéder aux EWS via Powershell. Il s'agit surtout d'une introduction car les possibilités de scripting sont infinies. L'exemple mis en œuvre dans cet article montrera comment accéder à un dossier bien spécifique pour le purger suivant les dates de réception des emails. Cela permettra entre autres de voir le langage AQS permettant la recherche d'objets dans une boîte aux lettres Exchange.

Prérequis

Avant toute chose, pour manipuler l'API Exchange Web Services, il est nécessaire d'installer le package correspondant sur le poste qui exécutera le script. Il est trouvable en suivant ce lien : http://www.microsoft.com/en-us/download/details.aspx?id=28952

Attention si vous utilisez, Exchange 2013, il faut prendre cette version :
http://www.microsoft.com/en-us/download/details.aspx?id=35371

Il sera ensuite nécessaire d'ajouter dans chacun des scripts qui sera réalisé la dll permettant d'interagir avec les Web Services. Pour rappel, cela se réalise via la commande Powershell Add-Type :

001
002
003
Add-Type -path "C:\Program Files\Microsoft\Exchange\Web Services\1.2\Microsoft.Exchange.WebServices.dll"


AQS ou Advanced Query Syntax:

Le langage AQS permet de réaliser des recherches dans les objets d'une boîte aux lettres Exchange. Il est très simple à prendre en main.

Pour comprendre toutes les possibilités de ce langage voici le lien MSDN dédié :
http://msdn.microsoft.com/en-us/library/ee693615.aspx

Grâce à ce langage il va être possible de rechercher des éléments :
- par type (emails, réunions, notes, contacts, ...)
- par date (réception ou envoi)
- par propriété d'un email (champ from, to, cc, subject, body, ...)

L'exemple suivant permet de rechercher des emails ayant été reçu le 3 Septembre 2013 :
"Kind:email AND Received:03/09/2013"

On remarque l'opérateur AND qui permet de prendre en compte 2 propositions. Il en existe d'autres comme le OU (l'une ou l'autre des propositions) et le NOT (l'inverse d'une proposition).

Script commenté

Il s'agit ici d'un script où l'utilisateur se connecte à une boîte aux lettres sur laquelle il possède des droits et dont les messages du dossier nommé Personnel seront supprimées s'ils datent de plus de 30 jours. Aussi, pour chaque dossier, il affiche la taille de celui-ci en Ko. Cette dernière opération est aussi faisable via la commande EMS Get-MailboxFolderStatistics mais avec cette exemple nous n'aurons pas besoin d'installer ces outils mais seulement l'API EWS beaucoup plus légère.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
069
070
071
072
#Mailbox à traiter
$MailboxName = 'j.dupont@myenterprise.fr'

# A installer avant : www.microsoft.com/en-us/download/details.aspx?id=28952
try{
    Add-Type -path "C:\Program Files\Microsoft\Exchange\Web Services\1.2\Microsoft.Exchange.WebServices.dll"
}catch{

}

#On spécifie la version des web services
$Version = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($version)

#On utilise les credentials avec lesquels on est connecté
$Service.UseDefaultCredentials = $true

#On récupère la configuration Autodiscover pour se connecter à la BAL
$Service.AutodiscoverUrl($MailboxName,{$true})

#On récupère l'ID du dossier
$RootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)

#On se connecte au dossier via la connexion que l'on a initialisé
$RootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service,$RootFolderID)

#On limite le nombre de dossier à analyser à 1000 (sinon problème de throttling)
$FolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)

#On définit un ensemble de propriété à récupérer en même temps que nos dossiers
$PropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
#On crée une propriété de type taille de dossier
$SizeObject = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(3592,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long)
#On l'ajouter à notre vue de dossier afin que la taille soit aussi récupérée.
$PropertySet.Add($SizeObject); 
$FolderView.PropertySet = $PropertySet;

#On spécifie qu'on analyse l'intégralité de la hiérarchie
$FolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep

#On calcule la date d'il y a 30 jours et on la met au format dd/MM/yyyy
$DateOld = ((Get-Date).AddDays(-30)).ToString("dd/MM/yyyy")

#On récupère tous les dossiers
$Response = $RootFolder.FindFolders($FolderView)
#Pour chaque dossier
ForEach ($Folder in $Response.Folders) {
   
    $FolderSize = $null
    #Si la taille est disponible alors on l'export dans la variable $FolderSize
    if($Folder.TryGetProperty($SizeObject,[ref] $FolderSize)){
        $FolderSizeValue = ([Int64]$FolderSize)/1000 
        #On affiche la taille du dossier
        $Message = "Le dossier " + $Folder.DisplayName + " a une taille de $FolderSizeValue Ko"
        Write-Host $Message
    }else{
        $Message = "Taille du dossier " + $Folder.DisplayName +" introuvable."
        Write-host $Message
    }

    #On compare le display name avec la valeur recherchée
    if($Folder.DisplayName -eq "Personnel"){
        #Si le dossier est bien Personnel alors on récupère tous les mails selon les critères de date définies
        $Items = $Folder.FindItems("Kind:email AND Received:<$DateOld",$ItemView) 
        #Pour chaque email trouvée
        ForEach($Item in $Items){
            #On le supprime définitivement (à décommenter pour que ce soit effectif)
            #$Item.Delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::HardDelete)
        }
    }
}

 

On remarque l’opérateur “<” (inférieur à) dans la requête AQS qui permet de spécifier tout ce qui se trouve avant cette date.

On peut accéder aux dossiers publics, modifier, supprimer, créer, tout type d'objet y compris des dossiers. Il est aussi possible de récupérer différentes informations comme la taille d'un dossier. Il est aussi possible d'analyser les pièces jointes pour supprimer celle dont l'extension est d'un certain type. Il est donc possible d'imaginer plein de scripts comme des tâches planifiées effectuant des traitement sur des boîtes aux lettres.

Manipuler les enregistrements DNS en Powershell 2

Problème rencontré

Lors d'un changement complet du plan d'adressage des serveurs d’un datacenter, il était nécessaire de changer les enregistrements DNS. Au delà des enregistrements NS des serveurs DNS, il fallait aussi mettre à jour l'intégralité des enregistrements statiques A et PTR. Il était nécessaire de proposer une solution qui soit simple à mettre en œuvre (peu d’intervention utilisateur), puisque près de 600 enregistrements était à modifier. Il n'était pas faisable de faire cela manuellement.

Solution proposée

Comme indiqué dans l'intitulé, il a été choisi que cette opération serait réalisée par un script Powershell. Actuellement, il y a encore peu de parcs informatique utilisant Powershell 3 avec le module DNS pour Windows 8/2012. Le module DNS fournit par Powershell 3 peut donc seulement être utilisé dans des cas très limités. La solution proposée utilisait les classes WMI. Il s'agissait ensuite de loguer un maximum d'informations pour avoir un maximum de contrôle sur les modifications apportées.

Les classes WMI

Voici un listing des classes WMI pour les enregistrements DNS les plus courants :
- Enregistrements PTR : MicrosoftDNS_PTRType
- Enregistrements A : MicrosoftDNS_AType
- Enregistrements CNAME : MicrosoftDNS_CNAMEType
- Enregistrements MX : MicrosoftDNS_MXType
- Enregistrements NS : MicrosoftDNS_NSType

Récupération d'enregistrements DNS

Voici un exemple de récupération d'un enregistrement A.

On déclare la zone dans laquelle on veut effectuer la recherche.

001
002
$DNSZone = "myenterprise.lan"

 

On définit le serveur DNS sur lequel on effectue la recherche.

001
002
$DNSServer = "SRVDNS01" 

 

On cherche l'enregistrement via l'attribut OwnerName qui est le nom DNS complet.

001
002
$OwnerName = "SRV01.$DNSZone" 

 

On utilise une requête WMI sur le serveur DNS avec un filtre sur la zone et l'enregistrement à chercher.

001
002
003
004
$Record = Get-WMIObject -Computer $DNSServer `
-Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_AType" `
-Filter "ContainerName='$DNSZone' AND OwnerName='$OwnerName'" 

Si l'on souhaite obtenir toutes les propriétés de cet enregistrement et notamment voir les autres attributs sur lesquels on peut effectuer une recherche il suffit d'appeler la variable : $Record

Mis à jour d'enregistrements DNS :

En reprenant l'enregistrement précédent, on peut rapidement modifier son addresse IP (ou TTL) via la méthode Modify().

001
002
$NewRecord = $Record.Modify($Record.TTL, "10.0.1.1") 

 

Détecter si un enregistrement est dynamique :

Aussi, il peut être intéressant de ne mettre à jour que les enregistrements statiques. On peut détecter les enregistrements dynamiques via leur timestamp qui n'est pas nulle :

001
002
003
004
if($Record.Timestamp -ne 0){ 
    $NewRecord = $Record.Modify($Record.TTL, "$newRecordAddress") 
} 

Il suffit donc juste d'utiliser une structure conditionnelle si sinon sur l'attribut timestamp de notre enregistrement DNS.

Exemple avec un enregistrement PTR :

Pour réaliser cette opération on réutilise les variables $DNSServer, $DNSZone et $OwnerName déclarées plus haut et définir la zone où chercher l'enregistrement PTR.

001
002
$DNSZonePTR = "10.in-addr.arpa" 

 

La syntaxe pour rechercher un enregistrement PTR est similaire. Seuls la classe WMI et le champ de recherche (PTRDomainName au lieu de Ownername).

001
002
003
004
$PTRRecord = Get-WMIObject -Computer $DNSServer `
-Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_PTRType" `
-Filter "ContainerName='$ZonePTR' AND PTRDomainName='$OwnerName.'" 

 

Attention, il n'est pas possible de modifier l'IP d'un enregistrement PTR, il faut d'abord supprimer l'enregistrement puis le recréer.

Avant, on récupère la TTL pour la réutiliser afin qu'elle soit identique lors du nouvel enregistrement :

001
002
$TTL = $PTRRecord.TTL 

 

On supprime l'enregistrement DNS en supprimant l'objet WMI

001
002
$PTRRecord | Remove-WmiObject 

 

On déclare la nouvelle valeur de notre enregistrement. Si IP vaut 10.B.C.D dans la zone "10.in-addr.arpa" alors celui-ci vaudra D.C.B.10.in-addr.arpa

001
002
$PTROwnerName = "1.1.0.10.in-addr.arpa"

 

On déclare le type de notre enregistrement, ici PTR :

001
002
003
$PTRTypeClass = [WMIClass]"\\$DNSServer\root\MicrosoftDNS:MicrosoftDNS_PTRType" 

$PTRNewRecord = $PTRTypeClass.CreateInstanceFromPropertyData("$DNSServer.myenterprise.lan",$ZonePTR,$PTROwnerName,$null,$TTL,"$OwnerName.") 

 

Le 4ème attribut est dénommé record class : par défaut il s'agit de IN. La valeur à insérer est 1 ou $null.

Exemple sous Powershell v3 avec module DNS :

Pour terminer, voici comment réaliser les mêmes opérations (Récupération/Mis à jour d'enregistrements DNS) avec le module DNS Powershell v3. Il faut posséder un poste sous Windows 8/2012 pour exécuter ses commandes et avoir installé l'outil de gestion des serveurs DNS (via les outils d'administration).

On commence par déclarer la zone, le serveur DNS et le nom de l'enregistrement :

001
002
003
004
005
$DNSZone = "myenterprise.lan" 
$DNSServer = "DNS01" 
$RecordName = "SERV01" 
$NewRecordAddress = "10.0.1.1" 

 

Le type est renseigné dans le paramètre RRType. Attention, il est important de stocker l'objet dans une variable car nous allons le réutiliser pour le modifier.

001
002
003
$Record = Get-DnsServerResourceRecord -ZoneName "$DNSZone" -Name "$RecordName" `
-RRType "A" -ComputerName "$DNSServer" 

 

Pour valider les modifications nous aurons besoin de l'enregistrement DNS avant et après sa mise à jour. Il faut donc réaliser une deuxième récupération de l'enregistrement DNS dans une autre variable.

001
002
003
$NewRecord = Get-DnsServerResourceRecord -ZoneName "$DNSZone" -Name "$RecordName" `
-RRType "A" -ComputerName "$DNSServer" 

 

Ensuite, il faut modifier la propriété qui nous intéresse, ici l'adresse IP.

001
002
$NewRecord.RecordData.IPv4Address.IPAddressToString = "$NewRecordAddress" 

 

Enfin, on enregistre les modifications en passant les 2 objets (avant et après modification), la zone et le nom du serveur DNS :

001
002
003
Set-DnsServerResourceRecord -NewInputObject $NewRecord -OldInputObject $Record -ZoneName "$DNSZone" `
-ComputerName "$DNSServer" 

Windows – Powershell Gestion des groupes d’un ordinateur.

 

Dans la gestion des groupes dont est un ordinateur est membre un administrateur doit parfois ajouter les groupes de cet ordinateur vers un second.

Voici une ligne de commande réalisée avec l’outil Quest Activeroles qui permet de réaliser cette action.

Get-QADComputer SRVPROD -searchroot 'DC=source,DC=com' | Get-QADMemberOf | where name -ne 'Domain Computers ' | Add-QADGroupMember -Member 'TESTSERV' -Service DCSYS001.target.com

Dans cet exemple on extrait les groupes dont le serveur SRVPROD est membre du domaine source.com .On exclu le groupe « Domain Computers » et pour finir on ajoute les groupes au serveur TESTPROD du domaine target.com.

On peut également avoir besoin d’exporter les groupes dans un fichier CSV.

L’attribute ‘MemberOf’ est de type « multivalued »

Get-QADComputer SRVPROD -searchroot 'DC=source,DC=com' | select-object @{n='memberOf';e={$_.MemberOf -join ';'}} | export-csv d:\"$server"_2.csv -NoTypeInformation -Force -Delimiter ";"

Afin d’extraire tous les groupes on doit utiliser une syntaxe particulière on utilisant la fonction JOIN : @{n='memberOf';e={$_.MemberOf -join ';'}} .

Powershell v3.0 : Les Workflows

Introduction

L'une des grandes nouveautés de Powershell 3.0 est l'intégration des Workflows. Pour généraliser ceux-ci représente une série d'action sur lesquels on va pouvoir effectuer des actions pendant l'exécution. Concrètement, grâce à ceux-ci nous pouvons désormais :
- Paralléliser l'exécution d'actions indépendantes les unes des autres. Cela était déjà faisable via les jobs mais la syntaxe des Workflow est orientée pour les traitements lourds.
- Interrompre puis reprendre des tâches.
- Placer des checkpoints permettant de reprendre des traitements à un endroit donné. Par exemple, si le workflow crashe, nous pouvons reprendre son exécution à partir du checkpoint et non dès le début.

Exemple d’utilisation

On peut imaginer toute sorte d'utilisation :
- Réaliser des pings en parallèle sur des ordinateurs (Traitement sur de multiples postes en même temps).
- Renommer un ordinateur puis reprendre l'exécution du workflow une fois le poste redémarré pour qu'il envoi un mail de confirmation à un administrateur (ou qu'il effectue un traitement).
- La création de machines virtuelles en parallèle.  Puis, on réalise un checkpoint, puisqu'elles n'auront plus à être recréées. Enfin on démarre les machines virtuelles en parallèle et on leurs fait rejoindre le domaine de l'entreprise.
- Créer parallèlement de nombreux ordres de déplacement de boîtes aux lettres dans le cas d'une migration Exchange.
- Créer un workflow contenant d'autres workflows tous exécuté en parallèle (Récupération en même temps, des comptes Active Directory désactivés, expiré, et verrouillé).

Tests et syntaxe

Ici, nous verrons comment implémentés les concepts que l'on a énoncé dans nos scripts. Les différents exemples se veulent simples afin de se focaliser sur la syntaxe.

La syntaxe est similaire au fonction. En effet, seul le mot clé diffère. Il s'agit de "workflow". L'appel au workflow se fait de la même façon que les fonctions.

Tout d'abord, nous allons comparer le temps d'exécution d'un workflow qui exécute 2 pauses d'une seconde en parallèle et une fonction qui réalise la même opération les unes à la suite des autres. Aussi au niveau de la syntaxe, on remarque que ce qui est parallélisé se trouve dans un block de code (entre accolades) précédé du mot clé "parallel".

03

Le résultat montre bien la différence entre les 2 modes d'exécution, puisque le workflow se réalise en un peu plus d'une seconde contre 2 pour la fonction.

04

A l'intérieur d'un bloc "parallel", il est possible d'insérer un bloc "sequence" pour être certain que les actions contenu dans celui-ci ne seront pas parallélisées. 

01

Le résultat obtenu permet de constater que les actions en parallèle s'exécute dans un ordre indéterminable (ici, le résultat de la ligne 9 s'affiche avant celui de la ligne 6 par exemple).

02

Il est aussi possible de gérer une boucle "ForEach" au travers de multiples exécution simultanées. Il suffit d'ajouter le paramètre "parallel".

09

Certaines commandes ne peuvent être traitées par le framework Workflow, il faut donc les inscrire dans un bloc "inlinescript". En voici un exemple avec "Get-ChildItem".

05

Pour qu'une variable déclaré dans un workflow soit accessible dans un bloc "inlinescript", il faut le préfixer par le mot clé "using:". Ci ce n'est pas le cas, alors Powershell est incapable de retrouver la valeur.

0607

Il en est de même si l'on souhaite modifier une valeur déclarer en dehors d'un bloc "parallel". Il faudra que celui-ci soit préfixé du mot "workflow:".

08

Enfin, le dernier thème abordé, sera celui de la sauvegarde, de la mise en pause et de la reprise d'un workflow.

Tout d'abord, la commande "Checkpoint-Workflow" permet de sauvegarder l'état d'un workflow. Ainsi, si celui-ci s'arrête à cause d'une erreur notamment, il pourra être repris à l'endroit où il s'est arrêté. Cela peut être intéressant pour éviter de ré exécuter des traitements lourds.

"Suspend Workflow" permet quant à elle de mettre en pause un traitement. Cette commande intègre automatiquement un checkpoint implicite afin de reprendre plus tard le workflow où il s'est arrêté.

Lorsqu'un workflow est suspendu via "Suspend-Workflow" ou une autre commande comme "Restart-Computer", il est possible de reprendre un traitement en cours via 2 méthodes. La première est manuelle.Lorsque l'on exécute le code ci-dessous, un job est créé. Grâce à l'un de ces attributs comme le nom ou l'ID , il est possible de redémarrer le workflow.

11

10

Pour l'exemple ci-dessous la commande à exécuter serait :

Get-Job -Name Job2 | Resume-Job -Wait

Afin de réaliser la même chose de façon automatisée, on crée un nouveau "job trigger". Celui-ci va nous permettre de gérer de l'évènementiel (lancer une tâche automatiquement à un moment donné).

L'exemple ci-dessous montre la création d'un "job trigger" qui lancera une tâche au démarrage. Cette dernière récupère le Workflow en suspend (ici "Myjob"), et le reprend. Contrairement à l'exemple précédent, on remarque qu'il est possible de définir le nom du job que prendre le workflow. En effet, lorsque l'on invoke un workflow, il existe le paramètre "JobName" qui permet de spécifier ce nom. Ce dernier est un paramètre qui existera pour n'importe quel workflow qui sera créé.

12

Powershell : Définir la liste d'adresse par défaut d'Outlook

Problème rencontré

Lors d'une migration Exchange inter organisation visant à la consolidation des infrastructure de messagerie des filiales d'une entreprise, il s'est présenté la problématique suivante. Il fallait que les utilisateurs aient accès dans leur client Outlook à une liste d'adresse correspondant à leur filiale. Cette dernière devait être la liste visible par défaut.

Solution proposée

Pour se faire, il est nécessaire de modifier une clé de registre sur les postes clients.
Dans la ruche : "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\", sont listés les profiles du client Outlook. Une ruche est présente dans chacun de ceux-ci : "9207f3e0a3b11019908b08002b2a56c2". Celle-ci contient la clé "01023d06" qui définit la liste d'adresse qui sera affiché par défaut à l'ouverture du carnet d'adresse. Attention la valeur est encodé au format Bytes HEX. Nous verrons comment la définir.

S'agissant d'appliquer une modification du registre à l'ensemble des postes clients d'une filiale, la solution la plus simple était d'implémenter cela dans le login script. Cela sera fait en Powershell. Il est bien entendu aussi possible de réaliser cette opération en VBS.
 
Il est à savoir que la vue par défaut du carnet d'adresse est la "Global Address List". De plus, si une valeur erronée est inscrite dans la clé de registre (ne correspondant à aucune liste d'adresse) alors Outlook repositionnera automatiquement le carnet d'adresse sur la liste d'adresse globale.

Récupération des paramètres

Afin de connaitre la valeur que nous devons positionner sur la clé "01023d06", il faut paramétrer manuellement Outlook afin de récupérer la valeur que l’on devra positionner. Pour cela, on définit la liste d’adresse sur laquelle on souhaite que nos utilisateurs se trouvent par défaut.

3

Ensuite, on peut ouvrir la clé de registre qui nous intéresse et observer sa valeur.

1

Si l'on modifie plusieurs fois cette valeur, on remarque le phénomène suivant. Elle se découpe en 3 parties :
- Une première qui est généré dynamiquement par utilisateur (avant le trait rouge)
- Une seconde qui est fixe qui va nous être utile pour récupérer la partie dynamique (entre le trait rouge et vert).
- Une troisième partie fixe (après le trait vert).

Ces trois éléments ont toujours une longueur fixe.

Il faut ensuite reformater les deux dernières parties sous forme de tableau de bytes. Il suffit devant chaque valeur en byte d’ajouter “0x” et de mettre une virgule entre toutes les bytes (syntaxe d'un tableau en Powershell).
Exemple :

01 00 00 00 00 01 00 00 2F devient 0x01,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x2F. Dans le script cette valeur sera définit par la variable $GALSuffix.

67 75 69 64 3D 38 42 34 39 43 31 36 34 45 44 35 41 36 34 30 39 34 42 30 42 4236 35 43 34 45 38 46 39 42 39 00 devient 0x67,0x75,0x69,0x64,0x3D,0x34,0x38,0x42,0x34,0x39,0x43, 0x31,0x36,0x34,0x45,0x44,0x35,0x41,0x36,0x34,0x30,0x39,0x34,0x42,0x30,0x42,0x42, 0x36,0x35,0x43,0x34,0x45,0x38,0x46,0x39,0x42,0x39,0x00.

Dans le script cette valeur sera définit par la variable $GALDefaultValue.

Script

Ci-dessous, le script commenté, où l'on va appliquer les paramètres que l'on a récupéré précédemment. Ceux-ci seront comparés avec ceux que l'on retrouve dans la clé de registre "11023d05" qui contient une configuration de sauvegarde. Cela permet de récupérer la première partie qui est dynamique.

2

Entre la ligne 37 et 47 on compare un à un les bytes rencontrés dans la clé de registre "11023d05" afin de retrouver l’index ou se trouve le tableau de bytes contenu dans $GALSuffix. Une fois cette valeur obtenue, on sait que la partie dynamique à rechercher est définie dans les 20 bytes précédentes.

Contrôle à distance de Sharepoint via Powershell

Introduction

L'une des forces de Powershell est de pouvoir administrer des produits directement depuis un poste client sans avoir à installer des outils d'administration. Hormis dans certains cas particuliers comme Exchange Online, il n'est pas non plus nécessaire d'ajouter des modules ou snapin Powershell sur notre ordinateur. Ceux-ci sont déjà présents sur le serveur distant, il est donc possible de les réutiliser. Dans cet article nous verrons le cas de Sharepoint pour lequel j'ai rencontré une petite subtilité.

Connexion à distance

Tout d'abord nous allons initier une nouvelle PSSession. Pour rappel, ce sont elles qui nous permettent d'interagir avec un serveur à distance. Elles ont été introduites à partir de Powershell v2.0.

On commence par stocker les paramètres d'authentification dans une variable.

$Credential = Get-Credential

On crée une variable avec le serveur sur lequel on souhaite se connecter

$Server =  "XXXXXXXXXX"

On génère une nouvelle PSSession en spécifiant les deux paramètres précédents. Celle-ci est stocké dans une variable car nous allons la réutiliser.

$Session = New-PSSession –ComputerName $Server -Credential $Credential

Ensuite, nous allons utiliser, la Cmdlet Invoke-Command afin d'exécuter une commande dans la session distante que nous venons de créer.

Invoke-Command -ScriptBlock {$ver = $host | select version; if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = "ReuseThread"}; Add-PSSnapin Microsoft.SharePoint.PowerShell;} -Session $Session

Il est nécessaire de préciser la session sur lequel va être réalisé le bloc de commandes. Un scriptblock est exécuté. Si la version de Powershell est supérieur à 1 alors on positionne l'interpréteur pour réutilisé constamment le même thread. Ceci est une configuration obligatoire si l'on souhaite ajouter le snapin Sharepoint. Nous pouvons le retrouver dans le fichier “sharepoint.ps1” qui est lancé par le Sharepoint Management Shell.

Enfin nous pouvons importer la session. Avec cette méthode l'intégralité des commandes sera utilisable directement depuis le poste client.

Import-PSSession $Session -AllowClobber

Erreur rencontrée

Lorsque l'on effectue une connexion a distance il se peut que l'on obtienne l'erreur suivante :

Import-PSSession : L’exécution de la commande Get-Command dans la session à distance a signalé l’erreur suivante: Le traitement de données pour une commande distante
a échoué avec le message d'erreur suivant: <f:WSManFault xmlns:f="
http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="3762507597"
Machine="XXXXXXXXXXXXXXXXXXX"><f:Message><f:ProviderFault provider="microsoft.powershell"
path="C:\Windows\system32\pwrshplugin.dll"></f:ProviderFault></f:Message></f:WSManFault> Pour plus d'informations, voir la rubrique d'aide
about_Remote_Troubleshooting...

Cette dernière signifie qu'il n'y a pas assez de mémoire disponible pour charger les commandes. En effet, les commandes Sharepoint sont très consommatrice en mémoire. Bien entendu, il existe un paramétrage pour pallier à ce problème.

Paramétrage serveur

Afin de corriger cette erreur, il faut augmenter la quantité de mémoire maximum allouée pour un shell distant. Il est recommandé pour Sharepoint de définir cette valeur à 1000 MB.

Pour réaliser cette étape il suffit de modifier la valeur MaxMemoryPerShellMB via le provider WSMan permetant d'accéder à la configuration des connexions distantes. Par défaut la valeur est à 100 MB.

Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000

Powershell : Modifier l'affichage d'un compte sous Outlook 2010

Introduction

Dans le cadre d'une migration inter-organization Exchange 2003 vers Exchange 2010, il fallait reconfigurer le profil pour que le nom de compte dans Outlook 2010 soit mis à jour avec la nouvelle adresse email (ainsi que le nom des arborescences des emails et de dossiers publics associées).

Blog1blog2

Afin de répondre à cette problématique en impactant le moins d'utilisateurs possibles, la solution proposée réalisait des modifications via un script déployer en GPO (logon script).
Ci-dessous vous trouverez les informations nécessaires à ce paramétrage via Powershell.

Récupération des informations de comptes

Afin d'effectuer ces modifications il faut aller les chercher dans le registre.
Ainsi, la ruche "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\" liste tout les profiles Outlook enregistré (par défaut le premier profil est appelé Outlook) pour l'utilisateur connecté.
Dans les ruches enfantes, si la clé de registre 001f6620 est présente c'est qu'il s'agit d'un compte Outlook. Cette dernière définit le nom du compte.

De plus, toujours dans les ruches sous-jacentes au nom d'un profile, si la clé 0003660a est positionné alors il s'agit d'une arborescence de emails ou de dossiers publics (ce sont celles qui nous intéressent dans le cas d'un changement de nom).
Si elle a la valeur "0x03,0x00,0x00,0x00" c'est qu'elle représente une arborescence de dossiers publics tandis que "0x01,0x00,0x00,0x00" représente la même chose pour des emails.
Le nom de l'arborescence est contenu dans la clé 001f3001.

Avec ces informations nous pouvons donc facilement retrouver le nom d'un compte et le profile associé pour le modifier. Pour modifier les noms des arborescences, nous avons les clés de registres à changer.

Modification du nom de compte

Pour modifier le nom du compte il n'existe actuellement qu'une seule méthode puisque la propriété du accessible via la librairie Interop (permettant d'interagir avec Outlook) n'est accessible qu'en lecture seule. Un module Powershell a été développé pour gérer les comptes Outlook : Outlook Account Manager. Il est disponible à cette adresse : http://psoutlookmanager.codeplex.com/

Il propose un jeu de commandes permettant de récupérer les profiles (Get-Profile), les comptes (Get-MAPIAccount) et de modifier ces derniers (Set-MAPIAccount).

Voici un exemple permettant le modification du nom d'un compte :

On récupère le compte Outlook que l'on souhaite renommer (Il faut spécifier le profil)
$Account = Get-MAPIAccount -ProfileName "Nom du profil" | Where-Object `   {$_.AccountName -eq "Mon compte à modifier"}
On change l'attribut AccountName avec le nouveau nom que l'on souhaite obtenir.
$Account.AccountName = "Nouveau nom"
On enregistre les changements sur le compte que l'on a mis à jour.
Set-MAPIAccount $Account

Il est à noter que le module Outlook Account Manager ne s'exécute qu'avec Powershell 32 bits. On peut donc lancer le script via la commande ci-dessous :
&"$env:windir\syswow64\windowspowershell\v1.0\powershell.exe" $Path
$Path représente ici le chemin du script.

Cette méthode peut être exécuter pendant qu'Outlook est lancé. Le résultat sera visible dès l'exécution du script (sans avoir à redémarrer Outlook).

Modification du nom d'affichage

Pour mettre à jour le nom d'affichage dans l'arborescence Outlook, il existe plusieurs méthodes.

La première, consiste à utiliser les classes Interop Outlook. Cela va lancer un processus Outlook en tâche de fond.
Tout d'abord on invoque une instance d'Outlook
$Outlook = New-Object -comObject Outlook.Application
$Namespace = $Outlook.GetNamespace("MAPI")

Permet d'obtenir tous les comptes.
$Accounts = $Namespace.Accounts

Cette méthode présente l'avantage d'obtenir un résultat visible même si Outlook est lancé (sans avoir à le redémarrer). Cependant, l'utilisateur sera prompté pour lui dire qu'un autre processus souhaite accéder à Outlook, et cela nécessitera donc une intervention manuelle. Il peut aussi être concevable de fermer toutes les instances d'Outlook avant d'exécuter ce script, ce qui peut être déroutant pour l'utilisateur.

Voici un exemple de code permettant la dernière proposition :
$OutlookProcesses = Get-Process | Where-Object {$_.Name -like "Outlook"}
ForEach($Outlook in $OutlookProcesses){
    Stop-Process $Outlook.Id
}

A la fin du script on n'oublie pas de fermer le processus ouvert par la création de l'objet COM :
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($Outlook)

La seconde méthode consiste à modifier directement la clé de registre. Pour mettre en œuvre cette opération il faut changer la valeur de la clé "001f3001" que l'on a identifier au préalable. Attention, le type de cette clé est un tableau de bytes. Bien qu'il soit possible de donner une chaine de caractère classique (String), tout en impactant pas le fonctionnement d'Outlook, cela va modifier le type. Voici donc un exemple pour créer un tableau de bytes à partir d'une chaine de caractère :

Exemple de résultat à obtenir :
blog4

On encode une String  en tableau de bytes
$enc = [system.Text.Encoding]::UTF8
$mystring = "This is a string"
$data = $enc.GetBytes($mystring)

Chaque caractère est séparé par une valeur en byte équivalente à un zéro. Pour que notre tableau soit correct il faut ajouter ce zéro après chaque caractère.
On crée un tableau modifiable (ArrayList)
$ArrayBytes = New-Object System.Collections.ArrayList
Entre chaque byte on ajoute un zéro.
foreach($d in $data){
    $ArrayBytes.Add($d)
    $ArrayBytes.Add(0)
}

Enfin on peut modifier la valeur de la clé de registre :

Set-ItemProperty "$RegistryPath" -Name 001f3001 -Value $ArrayBytes
$RegistryPath représente le chemin vers la clé de registre.

L'avantage de cette méthode est de n'avoir pas à exécuter de processus Outlook et l'utilisateur ne se rend pas compte du changement (pas de prompt ni de fermetures intempestives d'Outlook). Cependant si Outlook est lancé, le résultat ne sera visible qu'au prochain démarrage de celui-ci.

Powershell : Générer des fichiers Excel

Introduction

En Powershell, lorsque l'on souhaite exporter des données, le format de fichier le plus couramment prisé et le CSV (comma separated value). Cependant, il arrive souvent que ce fichier soit retravaillé avec de la mise en forme notamment. A ce moment là, il faut donc utiliser Excel et faire quelques clics... Heureusement, Microsoft fournit des classes C# accessibles en Powershell pour toute la suite Office. Il va donc être question de réaliser ces exports de façon automatisée avec la mise en page que l'on souhaite.

Utilisation d'Excel via Interop

Nous verrons ici les principales fonctions pour généré un fichier Excel et le mettre en forme. La totalité des fonctionnalités proposées étant disponible ici : 
http://msdn.microsoft.com/fr-fr/library/microsoft.office.interop.excel(v=office.11).aspx

Tout d'abord il faut appeler Excel en créant un nouvel.
$objExcel = new-object -comobject excel.application
On remarque que cette commande crée un processus Excel.
Pour accéder à un classeur il suffit d'utiliser cette commande (pour un fichier existant) :
$finalWorkBook = $objExcel.WorkBooks.Open($ExcelFilePath)
"$ExcelFilePath" représente le chemin du fichier que l'on souhaite ouvrir
S'il s'agit d'un nouveau fichier :
$finalWorkBook = $objExcel.Workbooks.Add()

Ensuite il est possible d'accéder à chaque onglet en précisant l'index dans la commande ci-dessous :
$finalWorkSheet = $finalWorkBook.Worksheets.Item(1)
Mais on peut aussi le renommer :
$finalWorkBook.Worksheets.Item(1).Name = "MyPSTab"

On peut ensuite accéder aux cellules de l'onglet :
$finalWorkSheet.Cells.Item(4,5) = "MyCell01"
Le premier chiffre est le numéro de la ligne et le second le numéro de la colonne (ci-dessus, ligne 4 - colonne 5). On peut donc facilement réaliser des boucles sur ces index pour changer de cellule.

Pour récupérer la valeur d'une cellule dans le cas où on se sert d'un fichier Excel en entrée d'un script :
myValue = $finalWorkSheet.Cells.Item(1,1).Text

Voici quelques commandes de mise en forme :
Pour mettre un texte en gras :
$finalWorkSheet.Cells.Item(1,4).Font.Bold
Pour surligner une cellule :
$finalWorkSheet.Cells.Item(3,2).Interior.ColorIndex = 42
Le nombre passé en paramètre correpond à une couleur.
Enfin pour ajuster la taille des colonnes automatiquement :
Pour une colonne spécifique (1 est l'index de la colonne):
$finalWorkSheet.Columns.Item(1).Autofit()
Pour l'intégralité du tableau :
$UR = $finalWorkSheet.UsedRange
$UR.EntireColumn.AutoFit()

Lorsque l'on souhaite sauvegarder un classeur Excel il existe deux méthodes. Dans le cas où le fichier existe :
$finalWorkBook.Save()
Si ce n'est pas le cas alors on utilise la méthode SaveAs avec le chemin du fichier :
$finalWorkBook.SaveAs(C:\TestExcelPS.xlsx)

Enfin, on n'oublie pas de fermer le processus ouvert par la création de l'objet COM :
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($objExcel)

Astuce : Si l'on souhaite voir le résultat pendant que le script s'exécute il suffit de rendre l'objet Excel visible en changeant la valeur de l'attribut éponyme :
$objExcel.Visible =$true

Script d'exemple

Ci-dessous un script réalisant un export des comptes désactivés d'un annuaire Active Directory. Ensuite, les comptes sont triés par unité d'organisation puis exporté dans un fichier Excel. A l'affichage chaque utilisateur est surligné d'une couleur différente en fonction de son unité d'organisation.

##################################################################

# Help                                                                                                        #

##################################################################

<#

    .SYNOPSIS

    Get Disabled Accounts      

    .DESCRIPTION

    Get Disabled Accounts, sort them by OU and Export by Excel or CSV

    .EXAMPLE

    01-Get-DisabledAccounts.ps1

    Description

    -----------

    Get Disabled Accounts, sort them by OU and Export by Excel or CSV

#>

##################################################################

# Main                                                                                                       #

##################################################################

# Récupération du chemin du fichier du script

$RootFolder = Split-Path -Path $MyInvocation.MyCommand.Definition

# Test de la présence du module Active Directory

if((Get-Module ActiveDirectory) -eq $null){

    try{

        Import-Module ActiveDirectory

    }catch{

        Write-Host "The execution computer doesn't have ActiveDirectory Powershell Module. The script can't continue." -ForegroundColor Red

        return

    }

}

# Création de l'objet application Excel sinon on réalise un export au format CSV

try{

    $objExcel = new-object -comobject excel.application

    Write-Host "Excel is installed on this Computer, disabled Users will be export in a fashioned excel file."

    $ExcelTest = $true

}catch{

    Write-Host "Excel is not installed on this Computer, disabled Users will be export in a plain old CSV file."

    $ExcelTest = $false

}

# Génération de la date du jour pour le nom du fichier d'export

$Date = Get-Date -Format ddMMyyyy

# Si Excel est disponible

if($ExcelTest){

    # Génération du chemin du fichier d'export

    Write-Host "Create Excel file"

    $ExcelPath = "$RootFolder\DisabledAccounts_$Date.xlsx"

   # Si le fichier Existe on l'ouvre

    if (Test-Path $ExcelPath) {

        $finalWorkBook = $objExcel.WorkBooks.Open($ExcelPath)

       # On choisi l'onglet sur lequel on travaille

        $finalWorkSheet = $finalWorkBook.Worksheets.Item(1)

        # Donne un nom au à l'onglet

        $finalWorkBook.Worksheets.Item(1).Name = "DisabledAccounts"

    }else{

        # Création d'un nouveau fichier

        $finalWorkBook = $objExcel.Workbooks.Add()

        $finalWorkSheet = $finalWorkBook.Worksheets.Item(1)

        $finalWorkBook.Worksheets.Item(1).Name = "DisabledAccounts"

    }

    #$objExcel.Visible =$true

    Write-Host "Create header"

   # Rempli la première ligne

    $finalWorkSheet.Cells.Item(1,1) = "SamAccountName"

    # Met le texte en gras

    $finalWorkSheet.Cells.Item(1,1).Font.Bold = $True

    $finalWorkSheet.Cells.Item(1,2) = "FirstName";

    $finalWorkSheet.Cells.Item(1,2).Font.Bold = $True

    $finalWorkSheet.Cells.Item(1,3) = "LastName"

    $finalWorkSheet.Cells.Item(1,3).Font.Bold = $True

    $finalWorkSheet.Cells.Item(1,4) = "LastLogonDate"

    $finalWorkSheet.Cells.Item(1,4).Font.Bold = $True

    $finalWorkSheet.Cells.Item(1,5) = "DistinguishedName"

    $finalWorkSheet.Cells.Item(1,5).Font.Bold = $True

}else{

    # Création du chemin du fichier CSV

    $CSVPath = "$RootFolder\DisabledAccounts_$Date.csv"

    # Création du header du fichier CSV

    $Header = "SamAccountName;FirstName;LastName;LastLogonDate;DistinguishedName"

    # Ecriture du header

    $Header | Out-File -FilePath $CSVPath

}

Write-Host "Rrieving data..." -ForegroundColor Green

# Récupération des utilisateurs désactivées

$ListUser = Get-ADUser -Filter {Enabled -eq $false} -Properties * | Select CanonicalName, CN, DistinguishedName, SamAccountName, GivenName, SurName, LastLogonDate, `

@{Name="OU";Expression={(($_.CanonicalName).Substring($_.CanonicalName.IndexOf("/")+1)).replace("/$($_.CN)","")}} `

| Sort-Object OU

Write-Host "Writing data..." -ForegroundColor Green

# On commence à la seconde ligne (la 1ère est consacrée au Header)

$FinalExcelRow = 2

# Choix d'une couleur pour surligner la ligne

$ColorIndex = 41

# Récupéraiton de l'OU du premier utilisateur

if($ListUser.Count -gt 0){

    $OU = $ListUser[0].OU

}

$i = 0

#On boucle sur chaque utilisateur

ForEach($User in $ListUser){

    #On affiche une barre de progression montrant le nombre d'utilisateur déjà traités

    $PercentComplete = [System.Math]::Round($($i*100/($ListUser.Count)),2)

    Write-Progress -Activity "Exporting data to Excel" -status "Effectué : $PercentComplete %" -percentcomplete $($i*100/($ListUser.Count))

    $i++

    if($ExcelTest){

        # Si l'OU est à changé on change aussi l'index de la couleur

        if($OU -ne $User.OU){

            $ColorIndex++

            if($ColorIndex -ge 56){

                $ColorIndex = 3

            }

        }

       # Récupéraiton de l'OU de l'utilisateur en cours

        $OU = $User.OU

        #On stocke les différentes valeurs

        $finalWorkSheet.Cells.Item($FinalExcelRow,1) = $User.SamAccountName

        #On attribut la couleur définit plus haut pour la case concerné

        $finalWorkSheet.Cells.Item($FinalExcelRow,1).Interior.ColorIndex = $ColorIndex

        $finalWorkSheet.Cells.Item($FinalExcelRow,2) = $User.GivenName

        $finalWorkSheet.Cells.Item($FinalExcelRow,2).Interior.ColorIndex = $ColorIndex

        $finalWorkSheet.Cells.Item($FinalExcelRow,3) = $User.SurName

        $finalWorkSheet.Cells.Item($FinalExcelRow,3).Interior.ColorIndex = $ColorIndex

        $finalWorkSheet.Cells.Item($FinalExcelRow,4) = $User.LastLogonDate

        $finalWorkSheet.Cells.Item($FinalExcelRow,4).Interior.ColorIndex = $ColorIndex

        $finalWorkSheet.Cells.Item($FinalExcelRow,5) = $User.DistinguishedName

        $finalWorkSheet.Cells.Item($FinalExcelRow,5).Interior.ColorIndex = $ColorIndex

        # On incrémente le numéro de la ligne en cours d'écriture

       $FinalExcelRow++

    }else{

        $Result = $User.SamAccountName+";"+$User.GivenName+";"+ `                            $User.SurName+ ";"+$User.LastLogonDate+";"+$User.DistinguishedName

        $Result | Out-File -FilePath $CSVPath -Append 

    } 

}

Write-Host "Saving data and closing Excel." -ForegroundColor Green

if($ExcelTest){

    # Sélectionne les cellules utilisées

    $UR = $finalWorkSheet.UsedRange

   # Auto ajustement de la taille de la colonne    

    $null = $UR.EntireColumn.AutoFit()

    if (Test-Path $ExcelPath) {

        # Si le fichier existe déjà, on le sauvegarde

        $finalWorkBook.Save()

    }else{

        # Sinon on lui donne un nom de fichier au moment de la sauvegarde

        $finalWorkBook.SaveAs($ExcelPath)

    }

    # On ferme le fichier

    $finalWorkBook.Close()

}

# Le processus Excel utilisé pour traiter l'opération est arrêté

[System.Runtime.Interopservices.Marshal]::ReleaseComObject($objExcel)

MDT 2012 – Powershell : Intégrer des drivers non extractibles dans un master.

Lors de la création d’un master dans MDT, l’une des des étapes est l��intégration des pilotes. En principes ceux-ci sont généralement extractibles et il est possible de retrouver le .inf permettant l’installation du périphérique. Cependant dans quelques cas, cela n’est pas possible.

Pour pallier à ce problème, l’une des solutions est d’ajouter l’exécution d’un script Powershell dans la séquence de tâches.

Récupération des valeurs sur les postes cibles :

Tout d’abord il est nécessaire de récupérer certaines valeurs sur le modèle d’ordinateur concerné :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

Celles-ci vont nous permettre de détecter au moment du déploiement le modèle.

Script à intégrer dans la séquence de tâches :

Le script suivant est celui qui est intégré à la séquence de tâches (ici, le déploiement a été effectué sur un Elitebook 8440p de Hewlett-Packard) :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

$ModelName = $ModelName[2].replace(" ", "")

$VendorName = $VendorName[2].replace(" ", "")

if(($ModelName -eq "HPEliteBook8440p") -and ($VendorName -eq "Hewlett-Packard") ){

    Invoke-Expression "ligne_de_commande"

}

On récupère les mêmes valeurs que précédemment et ci ces dernières correspondent aux valeurs récupérées alors on exécute une commande permettant l’installation silencieuse du pilote.