PI Services

Bonjour,

Je vous présente un petit script powershell que j'utilise pour réaliser des maquettes ou en production selon le besoin.

Le but de ce script est de pouvoir créer et renseigner des comptes utilisateurs a partir d'un fichier CSV contenant les informations relatives aux comptes.

Ce dernier permet dans un active directory :

• De tester la présence des Unités d'Organisations et les créer si elles n'existent pas.
• De tester si les utilisateurs existent (le test est basé sur le SamAccountName).
• De créer les comptes utilisateurs avec les informations renseignées.
• De définir un de mot passe.
• D'activer les comptes.
• De placer les utilisateurs dans les bonnes Unités d'Organisations.

Présentation du CSV

Dans ce cas de figure je remplis un certain nombre de champs, mais en fonction de ce que l'on souhaite renseigner dans le compte utilisateur il suffit d'incrémenter le fichier CSV et bien sur d'ajouter les paramètres associés dans la ligne de code permettant la création de l'utilisateur.  

Le fichier csv a été réalisé avec l'application excel et contient les informations suivantes :

• GivenName : Le Prénom
• Surname : Le Nom
• Name : Prénom Nom
• SammAccountName : L'identifiant
• DisplayName : Le nom d'affichage
• Description : Une description du compte
• Company : Le nom de la société
• Department : Le nom du Service
• EmailAddress : L'adresse mail
• OfficePhone : Le numéro de téléphone
• Title : L'intitulé du poste
• OrganizationalUnit : L'unité d'organisation dans laquelle sera placé le compte

Une fois le fichier créé, enregistrez le au format "CSV", notez le chemin d'accès au fichier dans un coin il vous servira ultérieurement.

Présentation du Script

 Ci dessous le script Powershell, j'attire votre attention sur le fait qu'il fonctionne pour des Unités d'Organisation de premier niveau si vous possédez ou souhaitez utiliser des sous OU il faudra faire des modifications dans le script (voir la partie Bonus plus bas).

# Script de création d'Utilisateur

#Déclaration des variables
$Domain = "Lab"  # Déclarez ici votre Domaine
$Ext = "info"  # Déclarez ici l'extension (com, info, lan, local....)
$Server ="DC01.lab.info"  # Déclarez ici le serveur d'exécution
$FQDN ="@lab.info"  # Déclarez ici le nom du Domaine précédé de "@" cela servira pour la création du UserPrincipalName
$LogFolder = "C:\LogMathieu" # Déclarez ici l'emplacement du répertoire de Log
$Folder = "LogMathieu" # Déclarez ici le nom du répertoire de Log
$LogFile = "C:\LogMathieu\LogScript.txt" # Déclarez ici l'emplacement du fichiers de Log du script
$File = "LogScript.txt" # Déclarez ici le nom du fichier de Log du script
$LogError = "C:\LogMathieu\LogError.txt" # Déclarez ici l'emplacement du fichier d'erreur global 
$LogCatch = "C:\LogMathieu\LogCatch.txt" # Déclarez ici l'emplacement du fichier de gestion de l'erreur
$FileCatch = "LogCatch.txt" # Déclarez ici le nom du fichier de gestion de l'erreur
$CSV = "C:\Users\Mathieu\Desktop\Import\Utilisateurs_Maquette.csv" # Déclarez ici le chemin d'accès à votre fichier csv


# Avant de commencer nous allons créer un répertoire et un fichier pour les logs


if (!(Test-Path $logfolder)) {

    New-Item -Name $Folder -Path C:\ -type directory
    New-Item -Name $File -Path $LogFolder -type file
    New-Item -Name $FileCatch -Path $LogFolder -type file
    Write-Output "Le dossier $Folder n'existait pas, création du Dossier $Folder, du fichier $File et $FileCatch" | Add-Content $LogFile
                                }
Else {
    Write-Output "Le dossier $Folder existe déjà!" | Add-Content $LogFile
        }

# Import du module Active Directory et import du fichier csv

Import-Module ActiveDirectory

Import-Csv -Delimiter ";" -Path $CSV | ForEach-Object {
    $OU =$_."OrganizationalUnit"

    # Test de la présence de l'unité d'organisation et création si elle n'existe pas

    if ((Get-ADOrganizationalUnit -Filter {Name -eq $OU}) -eq $null) {
        Write-Output "l'unité d'organisation $OU n'existe pas, création de la nouvelle Unité d'organisation" | Add-Content $LogFile
        Try {
            New-ADOrganizationalUnit -Name $OU -Path "DC=$Domain,DC=$Ext" -ErrorAction Stop -ErrorVariable eOU
                }
        Catch{
            "Une erreur $eOU a eu lieu à $((Get-Date).DateTime)"  | Add-Content $LogCatch
                }
        Finally{
            "Fin de l'opération Ajout d'une OU"
                }
                                                                        }
    Else {
        Write-Output "l'unité d'organisation $OU existe déjà" | Add-Content $LogFile
            }
    $User =$_."SamAccountName"
    $DisplayName =$_."DisplayName"
    $GivenName =$_."GivenName"
    $Name =$_."Name"
    $SamAccountName =$_."SamAccountName"
    $Surname =$_."Surname"
    $Description =$_."Description"
    $Company = $_."Company"
    $Department = $_."Department"
    $EmailAddress =$_."EmailAdress"
    $OfficePhone  =$_."OfficePhone"
    $Title =$_."Title"

    # Test de la présence de l'utilisateur et création si il n'existe pas

    if ((Get-ADUser -Filter {SamAccountName -eq $User}) -eq $null) {
        Write-Output "l'utilisateur $User n'existe pas, création du nouvel utilisateur" | Add-Content $LogFile
        Try {
            New-ADUser -Company:$Company -Department:$Department -DisplayName:$DisplayName -GivenName:$GivenName -Name:$Name -Description:$Description -EmailAddress:$EmailAddress -OfficePhone:$OfficePhone -Title:$Title -Path:"OU=$OU,DC=$Domain,DC=$Ext" -SamAccountName:$SamAccountName -Server:"$Server" -Surname:$Surname -Type:"user" -UserPrincipalName:"$SamAccountName$FQDN"  -AccountPassword:(ConvertTo-SecureString -AsPlainText "p@ssw0rd" -Force) -Enabled:$true -AccountNotDelegated:$false -AllowReversiblePasswordEncryption:$false -CannotChangePassword:$false -PasswordNeverExpires:$false -ChangePasswordAtLogon:$true -ErrorAction Stop -ErrorVariable eUser
                }
    Catch{
        "L'erreur $eUser s'est produite à $((Get-Date).DateTime)" | Add-Content $LogCatch
            }
    Finally{
        "Fin de l'opération Ajout d'un Utilisateur"
            }
                                                                        }
    Else {
        Write-Output "l'utilisateur existe déjà" | Add-Content $LogFile
            }
                                                                                                                    }

# Récupérations des erreurs

$Error > $LogError

Bonus :

 Si vous souhaitez utiliser des "sous OU" il vous faudra modifier des éléments dans le fichier csv et le script.

Dans le fichier csv: 

Créez de nouvelles colonnes "OrganizationalUnit" et incrémentez les avec un numéro soit par exemple : OrganizationalUnit1,OrganizationalUnit2,OrganizationalUnit3.

Ensuite placez y les noms des untiés d'organistation de la plus basse à la plus haute, par exemple : 

1.  LAB.INFO\IT\Réseau\Prestataires\PI Services
2. LAB.INFO\IT\Systèmes\Windows\Stagiaire

Dans le fichier Script:

Il ne vous restera plus qu'à faire les modifications suivantes :

1. Déclarez les nouvelles variables "OrganizationalUnit1,OrganizationalUnit2,OrganizationalUnit3" (Ligne 38 dans le script avant modification).
2. Modifier le "path" en ajoutant "OU=$OU1,OU=$OU2,OU=$OU3" devant "DC=$Domain,DC=$Ext" (ligne 44 dans le script avant modification).
3. Modifier le "path" en ajoutant "OU=$OU,OU=$OU1,OU=$OU2,OU=$OU3" devant "DC=$Domain,DC=$Ext" (ligne 74 dans le script avant modification) attention ici ce n'est pas tout à fait pareil que l'étape 3.

Ceci n'est qu'un exemple bien sur, il vous est tout à fait possible de créer directement une variable $Path et renseigner le chemin complet dans votre csv.

Ce petit script va vous permettre de récupérer dans une variable un tableau de l’ensemble des process tournant sur le poste avec leurs ID et leurs propriétaire

$process=gwmi win32_process
$array=@()
foreach ($p in $Process)
{
    $temp=new-object psobject
    $temp |add-member -MemberType NoteProperty -name "ProcessName" -Value $p.name
    $temp |add-member -MemberType NoteProperty -name "ProcessID" -Value $p.ProcessID
    $temp |add-member -MemberType NoteProperty -name "User" -Value $p.getowner().user
    $array+=$temp
}

Exemple :

Ainsi, pour killer des processus, vous pouvez maintenant ajouter la contrainte par identification du propriétaire du Processus.

Exemple :

Nous allons killer les process Spotify de l’utilisateur ato

Tout d’abord on récupère les Processus respectant cette contrainte dans notre variable:

$array |? {$_.processname -eq "Spotify.exe" -and $_.user -eq "ato"}

Et ensuite, on les Kill grâce à leurs identifiants :

$array |? {$_.processname -eq "Spotify.exe" -and $_.user -eq "ato"} |%{stop-process -Id $_.processID}

Résultat : Plus de musique   (les processus Spotify de l’utilisateur ato ont été arrêtés).

Il peut être utile de disposer du nom d’utilisateur qui exécute un Processus.

Exemple en GUI :

Cependant en PowerShell, à l’aide de la commande Get-Process, nous ne disposons pas des utilisateurs.

Exemple en PS :

Il existe différente méthodes pour voir les processus sous PS.

Nous allons maintenant utiliser un appel wmi pour afficher les processus via la commande :

gwmi win32_process

Exemple :

En utilisant l’appel wmi, nous avons une propriété nous permettant de connaitre l’utilisateur propriétaire du processus que nous n’avons pas via la commande get-process

Exemple de récupération du propriétaire du processus Spotify à l’aide de la propriétée getowner :

(gwmi win32_process |? {$_.name -match "spotify"} |select -index 0).getowner().user

Nous avons maintenant récupéré le propriétaire du processus.

Le script ci-dessous interroge le psdrive dédié au magasin de certificat local a la machine pour lister les certificats dont la date d’expiration approche (paramètre $expireInDays) et alerter si le nombre de certificats concernés depasse le seuil donné (Paramètre $NbThreshold).

Le parametre $blacklist permet d’exclure les certificats dont l'expiration est considéré OK (root & co, on Windows Server 2003, 2008 & 2012)

Ce script génère un rapport texte des erreurs 500 en parsant les logs IIS d’une liste de serveurs. (Lien du script plus bas).

Introduction

Dans Office 365, il existe plusieurs méthodes pour ajouter des licences à un utilisateur :

• Via l'interface d'administration manuellement sur chaque utilisateur.
• Via l'interface d'administration manuellement sur plusieurs utilisateurs.
• Avec les cmdlets Powershell Office 365.

Dans cet article, nous allons nous intéresser à l'ajout/suppression de licences via Powershell. Le but est d'automatiser cette opération. On peut facilement imaginer des scénarios conjoints avec Dirsync. Ce dernier provisionne un compte, puis, une tâche ajoute automatiquement les licences nécessaires à l'utilisateur.

D'autre part, il est possible d'ajouter pour chaque utilisateur :

• Une licence complète incluant tout les services de l'abonnement souscrit.
• Certains services d'une licence afin de limiter les accès aux utilisateurs (par exemple : ne donner qu'une licence Exchange sans donner les accès à la suite Office).

Nous nous attarderons sur ces différentes possibilités dans l'un des paragraphes suivants.

Nous ferons un rappel sur les prérequis nécessaires à l'utilisation des cmdlets Powershell avant d'appréhender leur attribution. Nous verrons enfin un script permettant d'automatiser le processus d'ajout/suppression de services via l'utilisation des groupes de sécurité Office 365.

Pré requis

L'administration des utilisateurs Office 365 via Powershell a besoin de l'installation d'un module spécifique. Ce dernier nécessite un prérequis : Microsoft Online Services Sign-In Assistant. Ci dessous, vous trouverez le lien de téléchargement de ce dernier :

http://www.microsoft.com/en-us/download/details.aspx?id=41950

Voici maintenant les liens pour récupérer le module Powershell :

http://go.microsoft.com/fwlink/p/?linkid=236298

A titre informatif, la version 32 bits de ces composants n'est plus pris en charge et ne sera plus mis à jour par Microsoft.

Connexion à Office 365 et permission

Pour se connecter à Office 365, il est nécessaire d'exécuter la commande suivante :

Les informations d'authentification fourni doivent correspondre à un utilisateur possédant à minima le rôle de gestion des utilisateurs. Cette attribution permettra d'affecter les licences.

Licences et abonnements

Tout d'abord, nous allons commencer par récupérer les différents abonnements disponibles sur un tenant Office 365. Il s'agit de la commande :

Le résultat obtenu permet aussi de voir les licences disponibles (ActiveUnits) et utilisées. (ConsumedUnits)

Pour chacun des abonnements, il est possible d'accéder aux services disponibles. Exemple avec le premier abonnement de la liste :

Chaque service Office 365 possède donc un identifiant qui est utilise lors de l'affectation de licences à certains utilisateurs. Les services étant différents d'un plan à un autre, voici un tableau récapitulant les identifiants et les services auxquels ils donnent accès pour un abonnement de type E3 :

Pour les autres abonnements, les services ont des noms identiques ou similaires (exemple : SHAREPOINT_S_DEVELOPER au lieu de SHAREPOINTENTERPRISE pour un abonnement développeur).

NB : J'ai noté deux spécificités sur certains services. Premièrement, la licence Office Online doit être attribué conjointement à une licence Sharepoint (on peut facilement s'en rendre compte via le portail d'administration Office 365). Enfin, les licences Yammer n'ont pas besoin d'être attribués. Cela est sans doute dû au fait que l'intégration du service dans l'offre Office 365 n'est pas terminée. Il se peut aussi que cela soit pensé pour simplifier le système. Néanmoins, il apparaît que le nombre d'utilisateurs peut dépasser le nombre de licences sans avoir de réduction de services (Il faut donc faire un suivi régulier du nombre de licences afin d'être en règle).

Gestion des licences utilisateurs

Attribution d'une licence complète

L'attribution d'une licence utilisateur se fait via la commande Powershell "Set-MSOLUserLicence". Il est possible d'utiliser cette commande pour un ou plusieurs utilisateurs. Le paramètre AddLicenses permet d'ajouter une licence correspondant à un plan Office 365.

Exemple d'attribution d'une licence :

NB : Il est nécessaire de fournir l'attribut AccountSkuId de l'objet obtenu avec la commande Get-MsolAccountSku.

NB2 : Si vous attribuez des licences à plusieurs utilisateurs et que le nombre restants est insuffisant, alors la cmdlet affectera quand même des licences jusqu'à épuisement de celles-ci.

Attention, avant d'attribuer une licence, il est nécessaire d'ajouter une localisation à l'utilisateur. Cette opération est automatisable avec la commande suviante :

La location est à remplacer par la valeur voulue (ici : FR).

Attribution d'une licence partielle

Pour l'instant nous avons vu, l'attribution d'une licence donnant accès à tous les services offert par l'abonnement Office 365. Dans certains cas, il peut être voulu de n'autoriser un utilisateur qu'à un certain nombre de services. Pour se faire, il faut créer un objet du type MsolLicenceOption. Celui-ci est une licence à laquelle on a désactivé certains services.

Exemple :

Cette cmdlet crée une licence avec un pack de service désactivant Azure Right Management Services et Lync Online.

La commande crée les options de licencing à partir d'un abonnement (AccountSkuId) et une liste de services sous forme de tableau. Les noms des services à fournir sont ceux définis dans le tableau du paragraphe "Licences et abonnements". On peut ensuite attribuer ces options de licencing via la même commande que précédemment mais en changeant de paramètre :

Script

Présentation

Le but du script ci-dessous est d'effectuer un provisioning automatique des licences Office 365 pour les utilisateurs synchronisés avec Dirsync. Celui-ci est basé sur l'utilisation des groupes de sécurité Office 365 (ce dernier peut être synchronisé via Dirsync). Chaque groupe correspond à l'attribution d'un ou plusieurs accès à des services Office 365.Ce script peut aussi bien gérer l'ajout que la suppression d'accès. Afin de ne pas perturber les accès déjà affectés à un utilisateur sont réattribués (tant qu'ils ne sont pas concerné par le script). Afin de mieux comprendre le comportement du script, voici un scénario d'exemple :

• USER1 appartient au groupe GRP-SharepointOnline
• GRP-SharepointOnline attribue les accès SHAREPOINTENTERPRISE et SHAREPOINTWAC
• USER1 possède déjà un accès à Lync (via MCOSTANDARD)
• Le script s'exécute et donne les accès à SHAREPOINT Online et Office Online à USER1
• USER1 conserve également son accès à Lync Online.

Pour obtenir ce résultat, l'algorithme recalcule les accès de chaque utilisateur. Cette opération est réalisé en récupérant l'attribut DisabledServices de la licence utilisateur (avec Get-MsolUserLicense).

Il permet aussi de ne pas gérer certains services. Cela peut être notamment utile pour Yammer dont l'attribution de licence n'est pas à administrer.

Celui-ci a été utilisé au travers d'un runbook dans System Center Orchestrator mais il peut aussi être utilisé dans une tâche planifié. Il est possible d'imaginer des variantes de ce script. Par exemple, les licences à attribuer pourraient être stockée dans un attribut du groupe. On peut aussi supprimer l'exigence d'être un utilisateur synchronisé par Dirsync (dans ce cas le groupe devra être alimenté via la console Office 365 et non dans Active Directory).

Script

Nous allons voir dans ce blog comment générer un VHD Windows Server 2016 Nano TP3 depuis l’iso de Windows Server 2016 Technical Preview 3.

Récupération des sources Windows Server 2016 TP3

Récupérer l’ISO de Win 2016 TP3 :

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Une fois l’ISO récupéré, monter la dans votre explorateur Windows.

A la racine du lecteur est présent un répertoire nommé NanoServer.

Celui-ci contient l’image WIM que nous allons utiliser durant la construction de notre VHD Nano.

Dans le répertoire NanoServer est présent deux scripts PowerShell dont : new-nanoserverimage.ps1 permettant d’obtenir une image VHD à partir de l’image WIM.

Cependant, nous n’allons pas utiliser ici ce script pour la génération de l’image VHD Nano.

L’outil GUI qui sera utilisé est : DISM_64bits_Mount-Unmount_1.0.exe

Disponible à cette adresse :

https://onedrive.live.com/?cid=b370cc46ea3ab572&id=B370CC46EA3AB572%21137&ithint=folder,exe&authkey=!ANkLug_PPC-kh-8

Rappel :

Présentation de l’outil DISM_64bits_Mount-Unmount_1.0.exe

http://blog.piservices.fr/post/DISM_64bits_Mount-Unmount.aspx

Création du VHD Windows Server 2016 Nano

Lancer l’outil en tant que administrateur.

L’interface se lance

Créer votre VHD Nano

Le VHD est maintenant monté dans votre explorateur Windows

Dans la section WIM, sélectionner l’image NanoServer.wim présent dans les binaires du DVD Windows Server 2016 Technical Preview 3 et sélectionner l’index 1.

Sélectionner le volume du VHD et cliquer sur le bouton Apply

L’image WIM est maintenant décompressée dans le VHD.

Si ce message intervient, cliquer sur Non

Ouvrez maintenant une invite de commande en tant que administrateur et taper la commande bcdboot X:\Windows /s X: ou X correspond à la lettre du volume du VHD.

Exemple:

Ajout des fonctionnalités au VHD Nano

Dans le répertoire NanoServer sur le DVD d’installation, vous pouvez trouver un certains nombres de packages disponible pour notre image Nano.

Dans la section Mount, sélectionner le volume du VHD.

Dans la section Add Package, cochez cab et sélectionner le fichier .cab à intégrer. Cliquer sur Add.

Le package a été ajouté au VHD.

Faites de même pour les autres packages que vous souhaitez intégrer.

Vous pouvez maintenant démonter votre VHD de l’explorateur Windows.

Intégration dans Hyper-V

Dans la MMC Hyper-V cliquer sur Nouveau è Ordinateur virtuel

Donner un nom à votre VM

Sélectionner Génération 1

Sélectionner votre VHD Nano.

Votre VM sous Windows Server 2016 TP3 Nano est maintenant créé.

Vous pouvez maintenant démarrer votre VM Nano.

Vous avez besoin de connaitre la différence entre deux variables de temps différente

Exemple :

$source="23/06/2015 11:43:50"

$dest="23/06/2015 18:42:38"

La commande New-TimeSpan nous permet de calculer cette différence.

Cependant, les valeurs de nos 2 variables ont été récupérées sur un ordinateur ou la culture était fr-FR.

L’interprétation de la commande New-TimeSpan ne posera pas de problème si celle-ci est exécutée sur un poste ayant une culture fr-Fr

Exemple :

Cependant, si la culture du poste est différente de fr-FR. Cela peut poser problème.

Exemple : avec un poste ayant une culture en-US, la commande New-TimeSpan n’est pas capable de bien interprété la valeur de nos 2 variables qui sont formatés dans une culture fr-FR.

Si nous voulons que la commande New-TimeSpan puisse interpréter correctement la valeur de nos 2 variables, il va donc falloir les formater correctement.

[System.Globalization.CultureInfo]$French = 'fr-FR'

[System.Globalization.CultureInfo]$English = 'en-US'

$DateTime = [datetime]::Parse($source, $French)

$source = $DateTime.ToString($English)

$DateTime = [datetime]::Parse($dest, $French)

$dest = $DateTime.ToString($English)

Résultats :

New-TimeSpan peut maintenant calculer la différence des deux variables

Introduction

Les Exchanges Web Services (EWS) sont très pratiques pour manipuler le contenu d'une boite aux lettres. Ceux-ci ont été créés pour s'intégrer dans des applications en C# mais peuvent aussi être utilisés dans un script Powershell. Grâce aux EWS, nous pouvons manipuler des dossiers, des messages, le calendrier. Il est possible de réaliser des opérations de créations (comme l'envoi d'un email), suppressions et modifications. Cependant, nous verrons qu'il est nécessaire d'avoir des droits sur la boite aux lettres d'un utilisateur ou d'utiliser un mécanisme d'impersonation pour réaliser ces opérations.

Contexte

Cet article est basé sur un retour d'expérience d'utilisation des EWS dans un environnement Exchange 2010 SP3. Le système de réservation de ressources d'une entreprise (salle, équipements) devait migrer vers Exchange. Un mécanisme de reprise de l'existant a dû être mis en place pour créer les réservations dans les calendriers des ressources et des personnes réservant la ressource.

EWS

Afin d'utiliser les Exchange Web Services dans un script Powershell, il faut installer le package permettant d'interagir avec ceux-ci.

Ce dernier est actuellement en version 2.2 et peuvent s'interfacer avec toutes les versions d'Exchange de 2007 SP1 à la dernière en date : 2013 SP1 (Les cumulatives updates n'ont pas d'importance).

Il est disponible en suivant le lien ci-dessous :

http://www.microsoft.com/en-us/download/details.aspx?id=42951

Impersonation

Les Exchange Web Services utilisent l'autodiscover pour communiquer avec une boite aux lettres spécifique.

Exemple de connexion aux EWS :

Cependant, dès que j'effectuerai une opération sur la boite aux lettres, il me faudra des droits sur cette boite aux lettres comme le contrôle total. Dans le cas contraire, j'obtiendrai des erreurs.

Donner des droits sur un grand nombre de boites aux lettres n'est pas recommandable car cela complexifie l'administration. il existe donc une seconde option permettant de se faire passer pour le compte utilisateur de la boite aux lettres. Il s'agit de l'impersonation. C’est un rôle à attribuer à un compte de service (via le mécanisme RBAC). Cette solution offre plusieurs avantages :

• Simplicité d'administration : on peut rapidement ajouter ou supprimer les droits d'impersonation à un compte.
• Contrôle des comptes visés : le scope des utilisateurs pouvant être "remplacer" par un compte de service peut facilement être modifié sans devoir changer les propriétés de chaque boite aux lettres.
• Décoreller des délégations : le processus d'impersonation n'apparait pas dans les délégations et il est ainsi plus simple de faire la différence entre les deux mécanismes et les différentes autorisations.

Implémentation RBAC

Le rôle permettant l'impersonation est nommé ApplicationImpersonation. Pour l'implémenter, nous allons d'abord créer un scope, c’est-à-dire définir les utilisateurs sur lesquels le compte de service pourra faire de l'impersonation.

Dans l'exemple ci-dessous, nous créons un scope contenant toutes les boites aux lettres utilisateurs :

Puis, nous ajoutons le rôle ApplicationImpersonation à l'utilisateur souhaité en spécifiant le scope créé précédemment.

NB : Pensez à changer la valeur MYUSER par le nom d'utilisateur de du compte réalisant de l'impersonation.

Script

Ci-dessous vous trouverez différentes fonctions Powershell commentées permettant la création d’une réunion avec la possibilité de réserver une salle mais aussi la validation que ces réunions ont bien été créées. Ces fonctions gèrent l’impersonation tant que le compte avec lequel la connexion aux EWS possède ce droit sur les boites aux lettres visées.

Fonction de création de réunions :

Fonction de validation de la réunion dans le calendrier utilisateur :

Cette fonction valide qu’une réunion possédant les bonnes ressources ainsi que les bonnes dates de début et de fin existe dans le calendrier de l’utilisateur.

Elle permet aussi de vérifier qu’il n’y a pas eu de création de doublons dans le calendrier (utile si un script de création de réunion à été exécuté plusieurs fois).

Fonction de validation de la réunion dans le calendrier de la boîte aux lettres de ressources :

Cette fonction cherche une réservation de la ressource en validant les dates et heures ainsi que le nom de la personne ayant créé cet objet. Cette vérifications s‘effectue sur le calendrier de la boite aux lettres de ressource. Le statut de la réservation est aussi vérifié (valeur attendue : Accept) afin d’être certain que la ressource n’ait pas été réservée pas une autre personne.

Tips

La création de nombreuses réservations peut engendrer un grand nombre d'envoi d'email aux utilisateurs ayant réservés ces ressources. En effet, ils vont recevoir des réponses des ressources (acquittement ou refus de la demande) si le système de réservation automatique a été activé (Resource booking attendant). Une solution de contournement peut être mise en place pendant la phase de migration. Elle consiste à limiter le nombre de destinataires à 0 lors de l'envoi d'un mail par la boite aux lettres de ressources.

Pour réaliser cette opération, il suffit de lancer une invite de commande Powershell Exchange (EMS) et d'exécuter la commande suivante :

Ou bien, si l'on souhaite changer la valeur sur toutes les boites aux lettres de salles en une seule commande (on peut remplacer RoomMailbox par EquipmentMailbox pour les boites aux lettres d'équipements).

NB : Pensez à remplacer IDENTIFIANT_BAL par l'identifiant de la boite aux lettres de ressources (Alias par exemple).

A la suite de la récupération d’un dataset issu d’une requête a une base sql on veut exporter et transférer les données vers un système Unix.

Comme indiqué dans le code, a la suite de la validation du fait que le résultat de la requête contienne des données (RequestSQL OK),  on converti le dataset en csv vers un fichier local ($FullLocalFile):

($DataSet.Tables[0] | convertto-csv -Delimiter ";" -NoTypeInformation)  | Out-File -FilePath $FullLocalFile

Puis on récupère le contenu du fichier pour ensuite le convertir au format UTF8 (au passage on écrase le fichier d’origine):

$content=get-content $FullLocalFile
Set-Content -value $content -Encoding UTF8 -Path $FullLocalFile –Force

Enfin on envoi en ftp le fichier vers le système Unix (en construisant dynamiquement le fichier de commande):

N.B: Il est possible que le mode de transfert (ascii ou binary) ait une influence sur le résultat du transfert. N’hésitez pas a tester les deux cas.

#construction fichier ftpcommands
New-Item -Path "$LocalDirectory\ftpcommands.txt" -ItemType file -Force -value `
"open monserverunix
user1
password
ascii
cd /monappli/data
lcd $LocalDirectory
mput $FileName
Y
bye"

#Envoi FTP et verification
ftp.exe -s:$LocalDirectory\ftpcommands.txt > "$LocalDirectory\resultatftp.txt"

(...)

#suppression du fichier ftpcommands
Remove-Item -Path "$LocalDirectory\ftpcommands.txt"
Remove-Item -Path "$LocalDirectory\resultatftp.txt"